Meinung und konstruktive Kritik erwünscht...
Christoph Gärtner
- design/layout
Hallo SELFler!
Ich stehe kurz vor der Fertigstellung der geschäftlichen Internetseite eines Bekannten und würde diesbezüglich gerne noch weitere Meinungen einholen.
Die Adresse lautet http://xypher.host.sk/energie/, das Thema der Seite sollte hoffentlich auf den ersten oder zweiten Blick ersichtlich sein. Der Server ist jedoch nicht immer der schnellste, sollte es etwas länger dauern - nur Geduld, das wird schon...
Wenn ihr meint, dass ich an Aufbau, Konzeption und Aussehen der Seite noch etwas verbessern sollte - tut euch keinen Zwang an.
Die Seite ist zwar nicht wirklich was Besonderes, aber auch über Lob wäre ich nicht unglücklich ;-)
Gruß,
Christoph
ps noch etwas in eigener Sache: Da ich als armer Schüler eigentlich immer unter Geldnot leide, suche ich noch einen Teilzeitjob im Bereich Webdesign in Frankfurt und (näherer) Umgebung, wo ich mir in den Schulferien und eventuell auch sonst (zwei- oder dreimal die Woche, falls es zeitlich hinkommt auch häufiger) ein Bisschen was dazuverdienen kann.
Sollte hier also zufällig ein Frankfurter Webdesigner vorbeikommen, der noch etwas Unterstützung braucht - bitte melden!
Hallo Christoph,
da du ja ausdrücklich um Kritik gebeten hast, hier MHO:
Bitte nimm etwas Rücksicht auf Nutzer mit älteren Netscape-Browsern, die Links zu den einzelnen Seiten sind hier nur mit
geübtem Nutzertum ("da muß doch irgendwo eine Navigation sein??") zu finden. Mir ist zwar auf diversen, auch hier verwiesenen Seiten aufgefallen,
das Benutzer mit Netscape 4.x nicht mal eine abgespeckte Version sehen dürfen, aber gerade bei dem wahrscheinlich konservativem Zielpublikum deiner Seite
dürften auch ältere Browser vertreten sein.
Ansonsten finde ich das Design ganz angenehm schlicht, wobei ich gegen einen leicht getönten Hintergrund oder Schrift nichts einzuwenden hätte.
Das Bild oben springt je nach Seite immer mal von rechts nach links, ist das Absicht?
Weiterhin viel Erfolg,
Susanne
Hallo Christoph,
Hallo Susanne
Bitte nimm etwas Rücksicht auf Nutzer mit älteren Netscape-Browsern, die Links zu den einzelnen Seiten sind hier nur mit
geübtem Nutzertum ("da muß doch irgendwo eine Navigation sein??") zu finden. Mir ist zwar auf diversen, auch hier verwiesenen Seiten aufgefallen,
das Benutzer mit Netscape 4.x nicht mal eine abgespeckte Version sehen dürfen, aber gerade bei dem wahrscheinlich konservativem Zielpublikum deiner Seite
dürften auch ältere Browser vertreten sein.
Habe die Seite tatsächlich nicht im 4er Netscape getestet - sie sah im Amaya so hübsch aus, da dachte ich mir das wird schon klappen...
Nunja, jetzt sollte wenigstens die Navigation funktionieren, wenn auch sonst nicht alles Stylesheets interpretiert werden.
btw: kann es sein, dass NS4.x keine b-tags kennt?
Ansonsten finde ich das Design ganz angenehm schlicht, wobei ich gegen einen leicht getönten Hintergrund oder Schrift nichts einzuwenden hätte.
Werde ich mir noch mal durch den Kopf gehen lassen...
Das Bild oben springt je nach Seite immer mal von rechts nach links, ist das Absicht?
Die Stylesheets liegen jetzt in einer seperaten Datei, das Bild steht in einem div mit text-align:center - da sollte eigentlich nix springen...
Eventuell liegt das Problem an den Scrollbars - bei langen Seiten wird so das Bild um einige Pixel nach links verrutscht.
Weiterhin viel Erfolg,
Mal abwarten, wie es läuft.
Susanne
Christoph
Hallo Christoph,
NS 4.x versteht auf jeden Fall <strong>.
-----------
Mfg: Harry
Hallo Christoph,
Hallo Harry,
NS 4.x versteht auf jeden Fall <strong>.
Also, meiner tut es nicht - hab trotzdem mal alles bs durch strongs ersetzt. Wenn man denen dann per css noch font-weight:bold verpasst, dann klappt's auch mit der Darstellung...
Mfg: Harry
s'long
Christoph
Hallo,
eine ganz andere Frage:
Wieso hat denn der Doktor unter "Kontaktadresse" eine ganz andere Homepage mit dem gleichen Thema angegeben?
...Palme
Hallo,
Hallo auch,
Wieso hat denn der Doktor unter "Kontaktadresse" eine ganz andere Homepage mit dem gleichen Thema angegeben?
Wenn, dann unter "Impressum" und nicht unter "Kontaktadresse".
Wer dem Link dann mal folgt und auch die Texte liest, der wird bemerken, dass es die gleichen sind...
Ich sollte die Seite etwas überarbeiten, die aktualisierten Texte fehlen jedoch noch.
Ob die hp dann mal eine eigene Domäne spendiert bekommt, steht noch in den Sternen, ansonsten bleibt sie bei T-Online.
Bei der Slowak-Adresse handelt es sich nur um meinen Testspeicherplatz, die Dateien werden nach Fertigstellung auf den T-Online-Server wandern.
...Palme
In der Hoffnung, Klarheit geschaffen zu haben
Christoph
Sieht ganz gut aus.
Die Links würde ich allerdings nicht Rot Unterstreichen, das kommt zu krass und das paßt nicht zu den grünen Farben oben. Du solltest Komplimetär kontraste verwenden. Das heißt:
helle rot - dunkles grün
dunkles blau - helles gelb
schwarz - weiß
orange - lila bis blau
Sieht aber schon ganz gut aus.
Unter 800 x 600 dürfte es aber wahrscheinlich auch nicht mehr so aussehen wie du willst ... probier da mal.
Lieber einen Linke weniger und einen Unterpunkt mehr. Allerdings sollte jede Seite von jeder Seite mit zwei klicks erreischbar sein
MfG
Recardo
Sieht ganz gut aus.
Freut mich.
Unter 800 x 600 dürfte es aber wahrscheinlich auch nicht mehr so aussehen wie du willst ... probier da mal.
Die Navigationsleiste wird dann halt auf mehrere Zeile aufgeteilt, das sollte aber nicht SOOOO schlimm sein...
Irgendwie unterschlägt er allerdings auch bei den Links der oberen Zeile die roten Unterstriche - weiß jemand Rat?
MfG
Recardo
Christoph
Hallo
Irgendwie unterschlägt er allerdings auch bei den Links der oberen Zeile die roten Unterstriche - weiß jemand Rat?
Kann es sein, dass die Link-Klasse (welche man leider nicht einsehen kann, da ja externes Stylesheet) nicht ganz richtig ist?
:link {color:#ffffff; text-decoration:none;}
:visited {color:#ffffff; text-decoration:none;}
:hover {color:#ff0000; text-decoration:underline;}
:active {color:#ffffff; text-decoration:none;}
:focus {color:#ffffff; text-decoration:none;}
Gruß
André
Hallo
Hallo auch
Kann es sein, dass die Link-Klasse (welche man leider nicht einsehen kann, da ja externes Stylesheet) nicht ganz richtig ist?
Auch externe Stylesheets kann man einsehen - aber nein, daran liegt es nicht, auch wenn als einzige Pseudo-Klasse :hover definiert ist.
Die Unterstriche werden übrigens als border und nicht als text-decoration erzeugt, da sie eine andere Farbe als die Schrift besitzen.
Das Problem ergibt sich wahrscheinlich daraus, dass ich inline-Element mit einer border versehe - wenn nun zwei inline-Elemenente untereinander stehen, unterschlägt er mir die gewünschte Linie.
Gruß
André
Gruß
Christoph
Hallo,
naja, mir als "visueller" mensch (viele anderen streiten dies ja für sich selbst ab, aber ich denke, wenn ich mir unsere Medienlandschaft so ansehe, täuschen sich einige ;-)), also, mir visueller Mensch wird etwas wenig Themenbezogenes geboten. Ich muß wirklich lesen (und dann das wichtige erst mal finden) um zu wissen, wo ich gerade bin. Natürlich ist lesen ja nicht schlecht, aber so klapts eben erst mit dem zweiten Blick da Thema zu erkennen. Dem ersten Blick erschliest sich das Thema nicht.
Der Text auf dem Logo ist schwer zu lesen, da Text auf strukturiertem Hintergrund immer schwer zu lesen ist. Das aber das Logo der einzige Ort ist, wo steht, um was es der Firma geht, würd ich das ändern. "Hier gehts zu den Titten" mag zwar etwas plakativ sein, aber es gibt viele Seiten, die damit funktionieren...;-))))
Ich würde unbedingt die Laufweite des Fließtextes einschränken. Es ist extrem mühselig, lange Textzeilen am Monitor zu verfolgen. Man muß eine ganze lange Linie lang seine Augen auf Kurs halten. Finger darf man nicht als Hilfestellung nehmen, dann gibts Flecken auf den monitor. Und am Ende der Zeile muß man auch noch mit den Augen eins runter und ganz nach links, dabei die Sitzposition und den dadurch resultierenden Sichtwinkel mit einkalkulieren.... klingt pingelig, strengt aber an. Ich würde die Texte wenigstens auf die Breite des Logos oben reduzieren.
Dabei: findest Du Banner im Netz wirklich schön? ;-)))
Chräcker
Hallo Chräcker,
[...] Finger darf man nicht als Hilfestellung nehmen, dann
gibts Flecken auf den monitor.
Ach *deshalb* ist mein Monitor immer so versifft.
Gruesse,
C*scnr*K
Hallo, Christian,
[...] Finger darf man nicht als Hilfestellung nehmen, dann
gibts Flecken auf den monitor.Ach *deshalb* ist mein Monitor immer so versifft.
Dein Monitor ist sicher nicht versiffter als andere, nur aus dem Grund weil du ständig an der Konsole mit neongrün flimmerndem Text auf schwarzem Grund arbeitest (Gott habe meinen Hercules-Monitor selig), beginnt der durch das Pfotenfett samt Bölkstoffspritzern gebundene Staub durch unaufhörlichen Elektronenbeschuss zu fluoreszieren. Ha jo, so isch es! (Nein, nicht du, Cheatah.)
Grüße,
Mathias
Hallo Chräcker,
Ich würde unbedingt die Laufweite des Fließtextes einschränken. Es ist extrem mühselig, lange Textzeilen am Monitor zu verfolgen. Man muß eine ganze lange Linie lang seine Augen auf Kurs halten. Finger darf man nicht als Hilfestellung nehmen, dann gibts Flecken auf den monitor. Und am Ende der Zeile muß man auch noch mit den Augen eins runter und ganz nach links, dabei die Sitzposition und den dadurch resultierenden Sichtwinkel mit einkalkulieren.... klingt pingelig, strengt aber an. Ich würde die Texte wenigstens auf die Breite des Logos oben reduzieren.
Dazu eine Rückfrage: Habe deinen Hinweis so verstanden, dass der main-div-Bereich eine feste Breite bekommen sollte,um die Zeilenlänge zu beschränken. War das so gemeint?
Relativ kurze Zeilenlängen vorzugeben ist sicherlich im Nutzersinn, zumal der das Problem wohl oft nicht bewusst wahrnimmt oder? Dennoch frage ich mich manchmal, wie es mit dem Gegenargument(?) der Skalierbarkeit aussieht und ob nicht auch der Standpunkt vertretbar ist, der Nutzer könne das doch über die Breite des Browserfensters regeln?!
Sorry, wenn darüber im Grundsatz schon diskutiert wurde -
deutet darauf hin. Habe aber zur Zeit keinen Zugriff auf z. B.:
http://forum.de.selfhtml.org/archiv/2001/7/26438/
Gruß Reyk
Hallo, Reyk,
Ich würde unbedingt die Laufweite des Fließtextes einschränken. Es ist extrem mühselig, lange Textzeilen am Monitor zu verfolgen.
Relativ kurze Zeilenlängen vorzugeben ist sicherlich im Nutzersinn, zumal der das Problem wohl oft nicht bewusst wahrnimmt oder?
Es ist eine Grundregel der Typographie, dass eine Zeile nicht mehr als eine bestimmte Anzahl an Wörtern/Zeichen beinhalten darf, sonst wird sie, wie Chräcker sagt, unlesbar. Diese einfache Regel muss meiner Meinung nach auf das Web übertragen werden, auch wenn dem Benutzer generell Möglichkeiten gegeben sind, die Webseite nachträglich lesbarer zu machen. In wie weit diese genutzt werden, ist die Frage, generell würde ich das Ändern der Fensterbreite als fragwürdige Methode bezeichnen. Normalerweise argumentiere ich nicht damit, dass der Benutzer dumm ist und ihm deshalb die Entscheidungsfreiheit abgenommen werden sollte, aber in diesem Fall ist es meiner Meinung nach eindeutig eine Pflicht des Webautors, den Text grundlegend lesbar zu formatieren - die Option, dass der Benutzer diese Einstellungen aushebelt, besteht zudem.
Das Web ist insofern trügerisch, da eine vollkommene Skalierbarkeit nur bedingt möglich und oft wenig nützlich ist (wie in diesem Fall).
Dennoch frage ich mich manchmal, wie es mit dem Gegenargument(?) der Skalierbarkeit aussieht und ob nicht auch der Standpunkt vertretbar ist, der Nutzer könne das doch über die Breite des Browserfensters regeln?!
Ja, ständig reden wir von Skalierbarkeit, aber ab einem gewissen Punkt macht man sich etwas vor. Denn tatsächlich ist die volle Skalierbarkeit einer Seite Humbug, da zwar immer gepredigt wird, dass vom Autor nichts vorausgesetzt wird (beispielsweise Bildschirmauflösung und -proportionen), aber dies implizit ständig gemacht wird - auch auf der gerade diskutierten Seite, welche du *ohne* Zeilenbegrenzung als skalierbarer darstellen willst.
Im Grunde genommen kann eine Webseite, wenn man grundsätzlich mit der Skalierbarkeit argumentiert, nahezu keine Formatierungen geschweige denn ein »Layout« besitzen, welches die Seitenelemente zueinander in Kontext setzt. Jegliche gestalterische Komposition wäre nichtig, da der blanke Text schlichtweg frei fließen würde und nur erst am Fensterende umbricht. Damit wäre jegliches ein Spaltenlayout nicht möglich, vor allem wenn es mit Prozent arbeitet (was immer als das Nonplusultra für Skalierbarkeit gehandelt wird, ich halte es einen Tod für die Benutzbarkeit), denn irgendwann würden die Zeilen ewig lang oder verschwindend kurz (ein bis zwei Wörter pro Zeile), wenn der Benutzer beispielsweise eine Bildschirmlupe oder extensiv die Zoomfunktion verwendet. Jedes horizontale Nebeneinander (ich gehe von links-nach-rechts-Texten aus) wäre nicht möglich, da dies eine Festlegung der absoluten oder relativen Breite beinhaltet, welche je nach Benutzer eine negative Wirkung auf die Lesbarkeit haben könnte. Ich bin einmal zu dem Schluss gekommen, dass der Autor nichts voraussetzen kann (vom radikalen Standpunkt der Interoperabilität), es aber zwingend muss, um die Seite zuerst nützlich zu formatieren (Funktion, Struktur und Semantik optisch unterstreichen, dazu gehört auch Layout) und zudem danach oder im gleichen Schritt ein ansehnliches (passendes! auch das ist reiner Pragmatismus) Interface zu gestalten. Als einzigen veränderlichen bekannten Skalierungsfaktor wird em oder Prozent angenommen, letzteres setzt aber mehr voraus als em, da zwischen em und der Breite eines em breiten Absatzes in Wörtern eine Verbindung besteht, sofern die Schriftart und die Sperrung einigermaßen bekannt sind. Dies ist bei Prozent auf höchster Ebene nur bedingt der Fall.
Auch wenn es ständig verleugnet wird, wird eine »voll skalierbare Seite« durchaus für eine ganz bestimmte Anzeigeart »optimiert«. Alleine der Gebrauch von Pixelgrafiken - welcher meiner Meinung nach für eine Seite in einem Gewissen Maß unersetzlich ist - beinhaltet die Voraussetzung, dass das Benutzer zur Anzeige dieser fähig ist und die Grafik in ihrer Größe überhaupt wahrgenommen werde kann. Genauso wird beim Arbeiten mit horizontal prozentualen Werten davon ausgegangen, dass der Bildschirm ein 4:3-Format hat und somit die Zeilenlänge natürlich begrenzt ist. Abstrahiert gesehen ist alles, was irgendwie mit dem Formatieren und »Layouten« einer Webseite zu tun hat, eine Bevormundung des Benutzers - das Eine explizit, das Andere hinterrücks; beides könnte man mit dem Argument Einschränkung der Skalierbarkeit kaputtreden. Von dieser Seite kann man aber nicht *ausschließlich* argumentieren (ich würde primär von Chräckers Seite, der Benutzbarkeit, argumentieren, natürlich mit der Skalierbarkeit im Hinterkopf).
Ein max-width beeinträchtigt die Skalierbarkeit meiner Meinung nach gar nicht, da, wenn sie sich an der eingestellten Schriftgröße des Benutzers orientiert, die Zeichenanzahl pro Zeile in jeder Bildschirmauflösung bei jeder Einstellung mehr oder weniger gleich bleibt, da diese Proportionen von einer Änderungen der Umgebungsparameter nicht betroffen sind. Woher der Autor weiß, welche Zeilenlänge die Beste für den Benutzer ist? Er *kann* es nicht wissen. Er kann wie gesagt *gar nichts* wissen, er kann nur annehmen, aus Usability-Tests und Jahrhunderte alter Typografie-Erfahrung schließen, dass er dem Benutzer damit einen Gefallen tut. Und ja, er stellt dutzende Voraussetzungen, welche der Benutzer erfüllen muss, womit auch zwangsläufig selektiert wird.
Ich will dir im Grunde gar nicht widersprechen, dann wenn deine These lautet, dass das Verzichten auf max-width im optimalsten Falle die Skalierbarkeit fördert und dem Benutzer mehr Freiheit gibt, kann ich diese nur unterstreichen.
Skalierbarkeit ist meiner Meinung nach aber auch das Beibehalten von Proportionen, siehe beispielsweise die Zoomfunktion von Opera (zugegeben, der Text fließt bei einem »fluiden« Spaltenlayout auch nicht aus dem Bildschirm, weil es mindestens ein in der Breite variable Spalte gibt), da diese zu dem grundlegenden, nötigen Layout gehören, durch welche erst überhaupt eine Benutzbarkeit, Übersichtlichkeit und Gestaltung ermöglicht wird. Generell wird jedes Programm, was Hypertext mit einem Standardstylesheet darstellt, den Text fehlformatieren für den einen oder anderen Benutzer.
Habe aber zur Zeit keinen Zugriff auf z. B.:
http://forum.de.selfhtml.org/archiv/2001/7/26438/
Christian werkelt wohl momentan an der Archivanzeige herum. Der Thread behandelt aber ein anderes Thema (siehe Google-Archiv). Google führt auch nicht alle Threads, verwende besser die Selfsuche, der passende Suchbegriff wäre eher »Skalierbarkeit«. Hier wurde schon oft darüber diskutiert und ich habe auch nicht selten etwas dazu geschrieben, vielleicht interessiert dich http://forum.de.selfhtml.org/archiv/2002/6/13460/#m77683 ff., wenn der Archivzugriff wieder funktioniert.
Grüße,
Mathias
Hallo Mathias,
vielen Dank für deine ausführliche Antwort und die interessanten Anregungen.
Ja, ständig reden wir von Skalierbarkeit, aber ab einem gewissen Punkt macht man sich etwas vor. Denn tatsächlich ist die volle Skalierbarkeit einer Seite Humbug, da zwar immer gepredigt wird, dass vom Autor nichts vorausgesetzt wird (beispielsweise Bildschirmauflösung und -proportionen), aber dies implizit ständig gemacht wird - auch auf der gerade diskutierten Seite, welche du *ohne* Zeilenbegrenzung als skalierbarer darstellen willst.
Das wollte ich eigentlich nicht. Ich habe mich ja selbst auch dafür entschieden, die Zeilenlänge zu begrenzen und wollte nur meine Restbedenken zum Ausdruck bringen. Vielleicht rühren die Zweifel aber auch daher, dass meine Umsetzung (erste Versuche mit css-Layout und generell wenig Erfahrung) einfach nicht optimal ist:
Ich habe rechts neben einem ca. 200px breiten Navigationsbereich den Inhaltsbereich in der Regel auf 540px begrenzt und zwar über width, z. B. für <p>. Bei Verdana/13px (ich weiß, px-Angaben für Schrift sind auch nicht in jedem Fall Freunde der Skalierbarkeit - habe mich hier noch nicht endgültig entschieden) komme ich so auf ca. 70-80 Zeichen pro Zeile. Bei nur leicht schmalerem Browserfenster als die nun nötigen ca. 750px muss man dank der width-Angabe horizontal scrollen. Dieser Umstand war eigentlicher Anstoß zu meinem Posting.
Bei Verwendung von max-width anstelle von width ist in Mozilla, Opera aus meiner Sicht alles bestens. Zeilenlänge entspricht per default typographischen Vorgaben und bei schmaleren Fenstern muss nicht gescrollt werden. Allerdings intepretiert der IE das ja nicht, so dass hier gerade das Hauptanliegen Zeilenlänge scheitert. Oder unterliege ich einem grundlegenden Irrtum?
Gibt man width und max-width in px an (wobei max-width nach meinen Beobachtungen den width-Wert außer Kraft setzt), ist zunächst allen Browsern geholfen, aber das Scroll-Problem bei schmaleren Fenstern bleibt. Meinen nächtlichen Ansatz sollte ich vielleicht nicht öffentlich spinnen, da er möglicherweise naiv oder überflüssig ist - egal:
Abstrahiert gesehen ist alles, was irgendwie mit dem Formatieren und »Layouten« einer Webseite zu tun hat, eine Bevormundung des Benutzers - das Eine explizit, das Andere hinterrücks; beides könnte man mit dem Argument Einschränkung der Skalierbarkeit kaputtreden. Von dieser Seite kann man aber nicht *ausschließlich* argumentieren (ich würde primär von Chräckers Seite, der Benutzbarkeit, argumentieren, natürlich mit der Skalierbarkeit im Hinterkopf).
Da wollte ich wie gesagt auch gar nicht widersprechen.
Google führt auch nicht alle Threads, verwende besser die Selfsuche,
Klar, funktionierte nur gerade nicht, der Google-Link wegen
[pref:t=32212&m=174318]
In meinem ersten Posting wollte ich nicht "doch Steine" riskieren.
Gruß Reyk
Hallo, Reyk,
Ich habe rechts neben einem ca. 200px breiten Navigationsbereich den Inhaltsbereich in der Regel auf 540px begrenzt und zwar über width, z. B. für <p>. Bei Verdana/13px (ich weiß, px-Angaben für Schrift sind auch nicht in jedem Fall Freunde der Skalierbarkeit - habe mich hier noch nicht endgültig entschieden) komme ich so auf ca. 70-80 Zeichen pro Zeile. Bei nur leicht schmalerem Browserfenster als die nun nötigen ca. 750px muss man dank der width-Angabe horizontal scrollen. Dieser Umstand war eigentlicher Anstoß zu meinem Posting.
Hm, ein pixelgenaues Layout fordert dies auch mehr oder weniger heraus, wenn du konsequent »em« als vom Benutzer veränderberen Skalierungsfaktor verwenden würdest, würde dem Benutzer zumindest durch Änderung der Schriftgröße ein Verkleinern möglich. Das ist nicht das Optimum, aber mit Sicherheit eine Verbesserung.
Bei Verwendung von max-width anstelle von width ist in Mozilla, Opera aus meiner Sicht alles bestens. Zeilenlänge entspricht per default typographischen Vorgaben und bei schmaleren Fenstern muss nicht gescrollt werden. Allerdings intepretiert der IE das ja nicht, so dass hier gerade das Hauptanliegen Zeilenlänge scheitert. Oder unterliege ich einem grundlegenden Irrtum?
Nein, du hast Recht, das ist leider das große Problem. Bei meiner privaten Seite leiste ich mir Einiges, zum Beispiel auch dass ich max-width *anstatt* width benutze. Damit ist die Seite im MSIE auf großen Auflösungen und vergleichsweise klein eingestellter Schrift wegen der langen Zeilen schlecht lesbar, aber dafür muss auf kleinen Auflösungen nicht horizontal gescrollt werden. Da die Mehrheit MSIE benutzt und ich in keinem Fall riskieren will, dass gescrollt werden muss. Die andere Möglichkeit wäre tatsächlich nur ein pixelgenaues Layout, welches erst und nur bei 800x600 perfekt den Bildschirm füllt, natürlich im optimalsten Falle, ohne Taskleisten oder ähnliches an den Schirmrändern.
Gibt man width und max-width in px an (wobei max-width nach meinen Beobachtungen den width-Wert außer Kraft setzt),
Ja, das habe ich auch beobachtet.
ist zunächst allen Browsern geholfen, aber das Scroll-Problem bei schmaleren Fenstern bleibt. Meinen nächtlichen Ansatz sollte ich vielleicht nicht öffentlich spinnen, da er möglicherweise naiv oder überflüssig ist - egal:
- width und max-width in px angeben
- width über Selektoren auf 100% setzen etwa so:
.main {width:540px; max-width:540px;}
p[class=main] {width:100%;}
Damit würde m. E. die Scrollleiste in Mozilla, Opera entfallen und die Zeilenlänge im IE auch wie gewünscht ausfallen (Scroll-Problem bleibt hier).
Ja, das ist tatsächlich in Hilfe. Das max-width könnte auch in die zweite Deklaration übernommen werden, aber das ist gleich. Damit wird zumindest allen Browser, welche max-width verstehen, eine halbwegs variable Breite angeboten. Da momentan die meisten Seiten starre Layouts verwenden, ist dies ein Schritt in die richtige Richtung.
Möglicherweise ist das Problem aber gar nicht schwerwiegend, und mit dem "Aushebeln der Autorenvorgaben durch den Nutzer" beziehst du dich vermutlich auf deaktivierte Stylesheets?
Ja. Leider erlaubt nur Opera dies auf eine einfache Weise, in den anderen Browsern muss man CSS-Kenntnisse haben, Plugins installieren oder durch umständliche Menüs hangeln, die ein gemeiner Netzbenutzer nie finden wird.
Du hast in deiner .css-Datei max-width verwendet. Den Einsatz auf deinen Seiten finde ich auf die Schnelle leider nicht - bin auch nicht mehr hellwach.
Hm? Welche meinst du, http://home.t-online.de/home/dj5nu/? Doch, dort verwende ich max-width, was im Mozilla und Opera auch erkennbar ist, siehe http://home.t-online.de/home/dj5nu/molily.css. Ich wende es auf das body-Element an, da ich nicht jede Seite durch ein überflüssiges zusätzliches div umrahmen möchte, deshalb werden auch die Randeffekte über html und body gelöst, was der MSIE auch nicht ganz packt, vor allem darf ich keine XML-Deklaratinonen einfügen, da er dadurch in den Quirks-Modus gerät und die Seite komplett verhaut.
Grüße,
Mathias
Moin!
Meinen nächtlichen Ansatz sollte ich vielleicht nicht öffentlich spinnen, da er möglicherweise naiv oder überflüssig ist - egal:
- width und max-width in px angeben
- width über Selektoren auf 100% setzen etwa so:
.main {width:540px; max-width:540px;}
p[class=main] {width:100%;}
Damit würde m. E. die Scrollleiste in Mozilla, Opera entfallen und die Zeilenlänge im IE auch wie gewünscht ausfallen (Scroll-Problem bleibt hier).Ja, das ist tatsächlich in Hilfe. Das max-width könnte auch in die zweite Deklaration übernommen werden, aber das ist gleich. Damit wird zumindest allen Browser, welche max-width verstehen, eine halbwegs variable Breite angeboten. Da momentan die meisten Seiten starre Layouts verwenden, ist dies ein Schritt in die richtige Richtung.
Nein, das ist _kein_ ordentlicher Ansatz. Denn damit wird die Breite _festgelegt_ auf 540 Pixel. Schmalere Breiten sind nicht zulässig. Entweder man legt die Breite mit max-width (und min-width) in einem gewissen Rahmen fest, oder exakt mit width. Beides zusammen geht nicht.
Ach, wäre das schön, wenn CSS endlich mehrspaltigen Text könnte. Dann hätte man die Möglichkeit, die Breite einer Textspalte exakt festzulegen, und wenn mehr Platz ist, würde sich eine zweite Spalte daneben auftun. Das wäre für einige Sachen eine sehr gute Lösung. Aber es würde für den IE natürlich nichts helfen - der kann ja min/max-width schon jetzt nicht.
- Sven Rautenberg
Hallo Sven,
Nein, das ist _kein_ ordentlicher Ansatz. Denn damit wird die Breite _festgelegt_ auf 540 Pixel. Schmalere Breiten sind nicht zulässig. Entweder man legt die Breite mit max-width (und min-width) in einem gewissen Rahmen fest, oder exakt mit width. Beides zusammen geht nicht.
Bin nicht sicher, ob ich dich richtig verstanden habe. Jedenfalls sollte der Ansatz ja gerade schmalere Breiten zulassen (für Mozilla, Opera etc.) _und_ eine brauchbare Default-Zeilenlänge liefern (wobei man sich über die Länge selbst sicher streiten kann) Die width-Angabe 540px soll im IE für eine angenehme Default-Zeilenlänge sorgen und wird dann durch den Selektor für Mozilla & Co wieder aufgehoben. Aber du hast natürlich recht: Für den IE sind schmalere Spalten dann nicht zulässig. Molily hat sich ja wohl auch aus diesem Grund dagegen entschieden.
Gruß Reyk
Hallo, Sven,
[Workaround für variable Zeilenlängen]
Das max-width könnte auch in die zweite Deklaration übernommen werden, aber das ist gleich. Damit wird zumindest allen Browser, welche max-width verstehen, eine halbwegs variable Breite angeboten. Da momentan die meisten Seiten starre Layouts verwenden, ist dies ein Schritt in die richtige Richtung.
Nein, das ist _kein_ ordentlicher Ansatz.
Das habe ich nicht behauptet. Es ist nicht mehr als ein Workaround, keine endgültige Lösung des Problems.
Die wenigsten werden sich damit abfinden, dass die Zeilenlänge gar nicht bei der Mehrheit der Browser limitiert werden kann. Der Workaround ist das kleinere Übel. Mehr wollte ich nicht damit ausdrücken.
Denn damit wird die Breite _festgelegt_ auf 540 Pixel. Schmalere Breiten sind nicht zulässig.
Jein. Nur in Browsern, welche max-width nicht kennen. In diesen Browsern bleibt dem Autor nichts anderes übrig, als width zu benutzen, wenn er die Zeilenlängen lesbar gestalten will.
Entweder man legt die Breite mit max-width (und min-width) in einem gewissen Rahmen fest, oder exakt mit width. Beides zusammen geht nicht.
Doch, wieso nicht? Der Workaround funktioniert.
In Browsern, welche max-width verstehen, ist die Zeilenlänge nach oben begrenzt aber nach unten variabel.
In Browsern, welche max-width nicht verstehen, ist die Zeilenlänge fest.
Dies scheint mir eine vertretbarere Übergangslösung als nur max-width und unlesbar lange Zeilen in vielen Browsern. Wie ich bereits schrieb, verwende ich persönlich auf meiner Netzseite nur max-width, weil ich auch nicht von diesem Workaround überzeugt bin. Dennoch wird er für die meisten Autoren, welche eine einigermaßen gestaltete Seite haben wollen, eine gute Alternative sein.
Der Großteil des Webs ist pixelgenau auf 800x600 »optimiert«, ich würde es sehr begrüßen, wenn ein Autor zumindest diesen »Schritt in die richtige Richtung« vollziehen würde. Mit Sicherheit wird er nicht davon zu überzeugen sein, sein Layout komplett aufzugeben, weil der Großteil der Benutzer keinen richtigen[tm] Browser benutzt.
Ach, wäre das schön, wenn CSS endlich mehrspaltigen Text könnte. Dann hätte man die Möglichkeit, die Breite einer Textspalte exakt festzulegen, und wenn mehr Platz ist, würde sich eine zweite Spalte daneben auftun.
Hm, ich finde das gar nicht so gut. Liest du im Usenet? Vielleicht hat dein Server noch news:arr2f3$moc$1@valiant.koehntopp.de, Kristian Köhntopp nutzt immer X-No-Archive, weshalb das Posting nicht bei Google Groups archiviert ist. Followup wäre http://groups.google.at/groups?selm=arr6ue%24esa%241%40ariadne.rz.tu-clausthal.de&output=gplain.
Grüße,
Mathias
Hallo Mathias,
Hm, ein pixelgenaues Layout fordert dies auch mehr oder weniger heraus, wenn du konsequent »em« als vom Benutzer veränderberen Skalierungsfaktor verwenden würdest, würde dem Benutzer zumindest durch Änderung der Schriftgröße ein Verkleinern möglich. Das ist nicht das Optimum, aber mit Sicherheit eine Verbesserung.
Bin gedanklich wohl noch nicht so weit. Die Abhängigkeit der Schriftgrößen von anderen Elementen (Grafiken etc.), die pixelgenau positioniert sind, wurde ja schon mehrfach diskutiert. Vermutlich muss man dafür die Seite ganz anders aufteilen und nicht einfach Frame-Layouts mit css nachbauen?!
Hm? Welche meinst du, http://home.t-online.de/home/dj5nu/? Doch, dort verwende ich max-width, was im Mozilla und Opera auch erkennbar ist, siehe http://home.t-online.de/home/dj5nu/molily.css.
Die meinte ich, ja. Hast mir mit deinem Entscheidungskriterium "Nicht scrollen im IE" schon wesentlich weiter geholfen. 50 em sind ein Testwert? Gibt es eine Faustformel in Abhängigkeit von der Schriftgröße?
Gruß Reyk
Hallo, Reyk,
Hm, ein pixelgenaues Layout fordert dies auch mehr oder weniger heraus, wenn du konsequent »em« als vom Benutzer veränderberen Skalierungsfaktor verwenden würdest, würde dem Benutzer zumindest durch Änderung der Schriftgröße ein Verkleinern möglich. Das ist nicht das Optimum, aber mit Sicherheit eine Verbesserung.
Bin gedanklich wohl noch nicht so weit. Die Abhängigkeit der Schriftgrößen von anderen Elementen (Grafiken etc.), die pixelgenau positioniert sind, wurde ja schon mehrfach diskutiert.
Ja, wie ich sagte, mitunter muss man natürlich damit rechnen, dass die Komposition unter der Skalierbarkeit leidet, da zwischen der Textgröße und den zwangsläufig nicht skalierbaren Pixelgrafiken kein vorhersehbarer Bezug mehr besteht.
Vermutlich muss man dafür die Seite ganz anders aufteilen und nicht einfach Frame-Layouts mit css nachbauen?!
Ähm, nein, eigentlich nicht. Wenn man davon absieht, dass jeder Versuch, ein »Frame-Layouts mit CSS nachzubauen« (über die frame-typischen Schaufenstereffekte, position:fixed etc.) nicht von den Problemen von Frames wegführt, dann lässt sich die Anordnung der vorher in Frames untergebrachten Layoutelementen durchaus ohne Weiteres mittels eines CSS-Layouts nachbilden - es sei denn, dass Frameset war schon logisch strukturiert (Navigationsframe / Inhaltsframe o.ä.).
50 em sind ein Testwert?
Ja, das ist ein ziemlich willkürlicher Wert, der auch vergleichsweise hoch angesetzt ist, da die Zeilen doch vergleichsweise lang sind und schon unter Annahme der Standardgrößen bei 800x600 die Breite nach unten hin korrigiert wird.
Das Problem ist, dass meine Navigation momentan zu lang ist, weshalb ich den Wert nach oben korrigiert hatte, als ich die Sektion »Literarisches« von »Durcheinander« getrennt hatte.
Bei 800x600 und Standardschriftgrößen wird die Navigation bei »Die« und »Sterne« umgebrochen... Vielleicht wäre ein nowrap hilfreich, würe aber nicht das Problem der zweizeiligen Navigation lösen.
Gibt es eine Faustformel in Abhängigkeit von der Schriftgröße?
Ja und nein. In der Typographie gibt es die Faustregel, dass eine Zeile zwischen 25 und 75 Zeichen enthalten sollte, um gut lesbar zu sein. Im Web findest du verschiedene Seiten, welche unterschiedliche Wert empfehlen. Je nach Schriftbild kann dies aber deutlich variieren, beispielsweise ist auch die Zeilenhöhe/der Durchschuss entscheidend.
Im Web existiert zusätzlich das Problem, dass über die tatsächlich verwendete Schrift keine Informationen vorliegen. Entscheidend ist nämlich nicht nur die Größe (Höhe) einer Schrift, sondern auch deren Breite sowie deren Verhältnis. Bei gleicher Schriftgröße kann derselbe Text in zwei Schriften völlig unterschiedlich lang sein, siehe http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust. Die CSS2-Eigenschaft font-size-ajust, welche diese Unterschiede korrigieren soll, wird jedoch bisher von keinem Browser unterstützt.
Aus diesem Grund ist für einen Webautor nicht sicher, wieviel Wörter beziehungweise Zeichen in einer Zeile mit der Länge Xem und der Schriftgröße Yem untergebracht sind - er kann höchstens darüber mutmaßen, indem er eine font-family angibt, aber im Endeffekt, falls die angegebenen Schriften nicht zur Verfügung stehen, sind nur die generischen Schriftfamilien entscheidend. Da ich in meinem Browser für sans-serif Verdana eingestellt habe, wird das Aussehen eines Xem breiten Absatzes mit 1em Schriftgröße völlig anders aussehen als wenn ich Arial eingestellt hätte...
Kurz gesagt, es ist nicht sicher, wieviele Wörter/Zeichen im Endeffekt genau in der Spalte angezeigt werden, aber falls dir ein guter Mittelwert gelingt, bist du damit gut beraten. Es ist nunmal eine logische Konsequenz, dass sich so etwas im Web nicht festlegen lässt.
Grüße,
Mathias
Hallo, Christoph,
Okay... erst einmal die technischen Dinge.
XHTML 1.1 ist schön und gut, aber nicht kompatibel. Da du es still und klammheimlich als text/html auslieferst, weiß ich nicht, ob du dir der Probleme bewusst bist. Deshalb verweise ich schlichtweg auf [pref:t=30976&m=172198] ff., wo das Problem gerade diskutiert wird.
Argh - dein Layout ist pixelgenau, inklusive der Schriftgrößen. Damit ist die Schrift im Internet Explorer nicht skalierbar und generell auf eine Aufösung gemünzt, zudem ist die Schrift viel zu klein und für mich erst bei 130% Skalierung lesbar. Hier herrscht mehr oder weniger der Konsens, dass keine Angabe für Fließtext gemacht werden sollte und der Benutzereinstellung vertraut wird (1em) oder zumindest eine relativ große px-Schriftgröße gewählt wird (12px ist definitiv zu klein).
Anstatt <div id="title"> solltest du ein h1-Element benutzen. Die Suchmaschinen werden es dir danken, denn der Alternativtext des Bildes wird als normaler Text interpretiert.
Die Klasse navi ist redundant. #nav a ist der Selektor deiner Wahl.
Der id="top" im body-Element ist auch nicht nötig. Im Stylesheet verwendest du ihn offensichtlich auch nicht, der Selektor body reicht ja auch.
<h3>Energiesparen - ein Gebot der Vernunft!</h3> --> Logisch gesehen wäre es dann h2. Je nachdem was du als Dokumentüberschrift deklarieren willst vielleicht auch h1.
<p>...</p>
<br />
<h3>...</h3>
Das br-Element hat keine Bedeutung, es ist rein »presentational«. Stattdessen kannst du margin-top für h3 bzw. h2 vergeben.
Zum Inhalt und zur Gestaltung.
Das Aussehen ist generell - meiner persönlichen, ehrlichen, subjektiven und bescheidenen Meinung nach :) - nicht sehr ansehnlich oder passt zum Thema, vielleicht weil es ein wenig eintönig ist. Zu der Kopfgrafik hat Chräcker schon einiges gesagt, diese Kritik würde ich unterstreichen. Generell stehen die drei Hauptbereiche (Kopf / Navigation / Inhalt) in einem Missverhältnis zueinander, da meiner Auffassung nach die Navigationsleiste nicht hoch genug ist, was auch übrigens zu dem Problem führt, dass im Opera durch zuwenig padding oben und unten (Mutmaßung) der Unterstrich (border-bottom) außerhalb des schwarzen Bereichs gezeigt wird, nämlich knapp unter dem Ende des schwarzen divs. Vielleicht musst du da sogar mit line-height nachhelfen.
Naja, der Text... eine Bleiwüste. Einrückungen, veranschaulichende und dekorierende Grafiken und/oder Fotos, Hervorhebungen, grafische Listenpunkte und stärkere visuelle Strukturierung (u.a. durch Überschriftsformatierungen, andere Farben) würden abhelfen. Auch natürlich die genannte Zeilenbreite, mehr Durchschuss und größere Schrift, den Text »öffnen«. Vielleicht Tahoma, Verdana oder Trebuchet MS (vielleicht nur für einige Bereiche) - ich persönlich mag Arial nicht sehr, beziehungsweise nicht in dieser Laufweite, Größe und Linienhöhe.
In der Navigationsleiste wird nicht hervorgehoben, welche Seite momentan aufgerufen ist. Nach ein wenig Lektüre von Nielsen kommt man darauf, dass Links zur aktuellen Seite nicht hilfreich sind und die Navigation die Orientierung, den Lebensfaden geben könnte.
Impressum und Kontakt finde ich redundant. Kannst du das nicht irgendwie zusammenfassen unter Kontakt? Ein Kontaktformular mit bitte um Rückruf u.ä. kommt immer gut. »Internet« ist irreführend, schreibe besser »World Wide Web«, »WWW«, »Webadresse« oder ähnliches, siehe http://kbs.cs.tu-berlin.de/~jutta/ht/writing/words.html.
Fuchstanzstraß 97
^ Dort fehlt ein »e«, nehme ich an.
Das Impressum würde ich an das Ende der Navigationsliste setzen. »Aktuelles« ist in der jetzigen Form mehr oder weniger nutzlos - wenn dort auf Dauer nicht mehr kommt als Änderungen an der Seite, würde ich es herausnehmen. Vielleicht könnten aktuelle große Projekte vorgestellt werden (im Stil von Referenzen)?
Ich persönlich wünschte mir einen gewissen Abschluss am Ende jedes Dokuments... eine Fußzeile, eine bildschirmbreite Grafik, oder ... den Link zum Impressum vielleicht. Der Haftungshinweis ist übrigens in der Form nicht mehr sinnvoll als der »Landgericht Hamburg«-Disclaimer. Du kannst dich nicht von verlinkten Seiten generell distanzieren, höchstens, dass du die Links innerhalb deinen Möglichkeiten überwachst und es deines Wissens keine strafbaren Inhalte auf den verlinkten Seiten zum Zeitpunkt der Verlinkung und späterer Überprüfungen gibt.
Vielleicht wäre ein weiterer Bereich links vom Text passend, eine Spalte, welche vielleicht ein helleres Hintergrundmuster enthält, mit einem durchgehenden rechten Rand. Also links eine frei Fläche, dann ein vertikaler Trennstrich und erst dann der Text. Wenn der Text zudem wie beschrieben aufgelockert wird, würde dem recht eintönigem Layout ein wenig Leben eingehaucht... Auf der Startseite wäre ein Aufmacher nicht schlecht (man wird momentan sofort von einem Wust an Text begrüßt), außerdem könntst du eye-catchende Teasertexte verwenden (Anglizismenrekord! ;)).
Bitte verstehe diese Kritik als konstruktive (konstruktiv gemeinte) Anregung und persönliche Meinung (»I meant no insult«, siehe Michaels Signatur ;)).
Grüße,
Mathias
Hallo.
Erstmal Danke an alle, die sich die Mühe gemacht haben, sich hier zu meiner Seite zu äußern.
Ich habe mich bemüht, die vorgeschlagenen Verbesserungen so weit es geht zu beachten und das Ergebnis meiner Arbeit findet ihr unter http://xypher.host.sk/energie/.
Um auch den IE-Nutzern Skalierbarkeit trotz pixelgenauem Layout zu ermöglichen, ist es jetzt möglich, die Schriftgröße per JavaScript in 2px-Schritten zwischen 8 und 20px zu variieren (die Symbole befinden sich bei Mozilla in der rechten oberen, beim IE in der unteren Ecke).
Solltet ihr weitere Änderungsvorschläge haben, tut euch keinen Zwang an und äußert euch.
Vorweihnachtliche Grüße
Christoph
Hallo,
ich bin immer wieder erstaunt, und hier extrem, wie wenige kleine Veränderungen eine Seite in ein komplett anderes Licht stellen. Sie sieht einfach und schlicht jetzt viel anders und vor allem besser aus und es sind doch nur die Details, die geändert wurden. Zeigt: auf Details kommt es an ;-)
besonders gut gefallen mir die beiden Lupen oben rechts, klein, sofort erkennbar und funktionell....
(vielleicht noch durch Testsurfer prüfen lassen, ob durch die schwarzen "dekorahmen-Balken" nicht ein zu hoher Trauerreflex ausgelöst wird ;-)))
Chräcker
Hallo, Christoph
Ich habe mich bemüht, die vorgeschlagenen Verbesserungen so weit es geht zu beachten und das Ergebnis meiner Arbeit findet ihr unter http://xypher.host.sk/energie/.
Ich muss mich Chräcker voll anschließen, ich hatte gestern schon hineingeschaut und war wirklich positiv überrascht, die Seite ist viel offener, lockerer und der Text atmet und hat Freiraum. Die Grafiken finde ich richtig gut gelungen, genauso die zweite Navigation und der vertikale Schriftzug in der linken unteren Ecke.
Einige Sachen, die mich noch stören:
Das Logo - du hast es schon verbessert, ich erinnere mich nicht mehr genau, wie es vorher war, aber jetzt erscheint es mir zu »abweisend«, und steht damit in völligem Kontrast zu den Grafiken im Text.
Die Schrift verschwindet fast im Hintergrund durch wenig Kontrast (schwarze Schrift) oder wenig Opazität (weiße Schrift). Der Hintergrund lässt etwas Gegenständliches ahnen, in der Gesamtheit ist es aber ein schwarzgrünes Wirrwarr (horizontaler schwarzer Strich von »ö« bis »Dr.«).
(Ich treibe mich öfters bei Deviantart (http://www.deviantart.com/, tut aber nichts zur Sache) herum, dort gibt es viele »Dark Artists«, welche solche düsteren und verworrenen Bilder am laufenden Band produzieren, nicht dass ich es nicht mag, ich finde nur, dass es hier nicht passt... ;))
Ich würde jeweils ein wenig mehr seitlichen Abstand zwischen Text und Bilder verwenden, beispielsweise:
.rfloat {float:left; margin-right:5px;}
^^^ Ich fände 10px angenehmer... rein subjektiv.
Auf einige andere Sachen würde ich auch »bestehen« - da verweise ich einfach auf mein voriges Posting; ein Kontaktformular fände ich schon sehr hilfreich. Es aber natürlich deine Entscheidung.
Ich finde *äußerst* problematisch, dass du das XHTML als application/xhtml+xml auslieferst - ich hatte dir zwar angekreidet, dass du text/html verwendest, aber das war nicht mein Kernkritikpunkt. Ich meinte, dass XHTML 1.1 selbst als text/html nicht kompatibel ist (man denke an lang und name), insofern ist es nicht falsch, text/html zu verwenden - etwas anderes bleibt dir momentan nicht übrig - sondern XHTML 1.1 zu verwenden. Wenn du schon XHTML verwendest, dann am besten XHTML 1.0 im Rahmen der Kompatibilitätsrichtlinien, alles andere ist im breiten Einsatz momentan kontraproduktiv.
Mit application/xhtml+xml handelst du dir schwerwiegende Probleme ein, viele alte, aber noch breit verwendete Browser (mit IE6sp1 geht es scheinbar, mit IE5.x bin ich mir nicht sicher) werden anstatt der Seite einen Downloaddialog anzeigen. Im verlinkten Thread wird auch ausdrücklich gesagt, dass application/xhtml+xml momentan nichts als eine Zukunftsvision ist (es wurde auch erst Anfang dieses Jahres offiziell registriert, alte Browser können den Inhaltstyp gar nicht kennen, wenn sie ihn nicht schon auf Verdacht eingebaut haben).
Um auch den IE-Nutzern Skalierbarkeit trotz pixelgenauem Layout zu ermöglichen, ist es jetzt möglich, die Schriftgröße per JavaScript in 2px-Schritten zwischen 8 und 20px zu variieren (die Symbole befinden sich bei Mozilla in der rechten oberen, beim IE in der unteren Ecke).
Das gefällt mir vorzüglich.
Ich arbeite nicht viel mit JavaScript, aber wäre anstatt
document.body.style.fontSize
vielleicht auch eher
document.getElementsByTagName('body')[0].style.fontSize
oder ähnliches besser? Vielleicht irre ich mich, weil Opera 6.05 dies nicht interpretiert. Es dürfte aber auf dasselbe herauskommen, nur meines Wissens ist die Standard-DOM-Methode die »richtigere«. Wahrscheinlich irre ich mich, denn im Opera 7b1 geht es, wenn auch fehlerhaft (der Text wird nicht umgebrochen, sondern staut und stapelt sich).
Grüße,
Mathias
Hallo, Christoph
Hallo Mathias.
Ich würde jeweils ein wenig mehr seitlichen Abstand zwischen Text und Bilder verwenden, beispielsweise:
.rfloat {float:left; margin-right:5px;}
Deal.
Mit application/xhtml+xml handelst du dir schwerwiegende Probleme ein, viele alte, aber noch breit verwendete Browser (mit IE6sp1 geht es scheinbar, mit IE5.x bin ich mir nicht sicher) werden anstatt der Seite einen Downloaddialog anzeigen. Im verlinkten Thread wird auch ausdrücklich gesagt, dass application/xhtml+xml momentan nichts als eine Zukunftsvision ist (es wurde auch erst Anfang dieses Jahres offiziell registriert, alte Browser können den Inhaltstyp gar nicht kennen, wenn sie ihn nicht schon auf Verdacht eingebaut haben).
Das stimmt so nicht ganz - sofern ich die (xhtml-)Dateien per http als html auslieferte, kam es in keinem der (bei mir installierten) Browser (IE6.0, Opera 6.05, Mozilla 1.2.1) zu Darstellungsproblemen - bei anderen Browser könntest du recht haben. Als ich jedoch versuchte, die Dateien als xhtml auszuliefern, streikte der IE nach dem Motto "xml mit Stylesheets - wolln mer net". Deshalb war ich bei text/html geblieben - wieso ändern wenn's doch funktioniert?
Dennoch sehe ich ein, dass es beim derzeitigen Stand der Dinge wohl am Besten ist, die Dateien gleich als html zu generieren, was ich hiermit (http://xypher.host.sk/energie/) erledigt habe.
Ich arbeite nicht viel mit JavaScript, aber wäre anstatt
document.body.style.fontSize
vielleicht auch eher
document.getElementsByTagName('body')[0].style.fontSize
oder ähnliches besser? Vielleicht irre ich mich, weil Opera 6.05 dies nicht interpretiert.
Im Opera 6.05 funktioniert es generell nicht, aber ich hatte das schon vorher ändern müssen, da bei der Umstellung auf *echtes* xhtml das Objekt document.body seine Existenz einbüßte - war ursprünglich sowieso einfach aus Faulheit benutzt worden - immerhin sind's ein paar Buchstaben weniger ;-)
Was deine anderen Vorschläge betrifft - mal sehn, was sich da machen lässt - da ich von Grafikbearbeitung jedoch wenig bis gar keine Ahnung habe und einfach nur ein Bisschen mit Filtern und Ebenen herumspiele, kannst du leider keine Wunder erwarten. Ein Kontaktformular halte jedoch auch ich für sinnvoll.
Eine Frage hab ich aber noch: wieso ist das einzige, was mir der IE zeigt, wenn ich das Dokument als HTML4.01/strict deklariere folgendes:
Das Zeichen '>' wurde erwartet. Fehler beim Bearbeiten der Ressource 'http://www.w3.org/TR/html4/strict.dtd'. Zeile 81, Position 5
-- media type, as per [RFC2045]
----^
Das Problem ist jedoch nicht reproduzierbar - als ich beim Schreiben der Nachricht das ganze eben noch mal ausprobieren wollte, trat der Fehler nicht mehr auf - versteh' einer die moderne Technik...
Grüße,
Mathias
Gruß
Christoph