CSS macht keinen Spass, Tabellen sind besser.

[FrankieB]

Hallo,

eigentlich wollte ich in meinem letzten Thraed antworten, aber der ist leider schon im Forums-Nirwana ...

Besonderen Dank für die Scrennshots an:

wahsaga, ingo, stonie.

In meinem vorangegangen Thread ging es darum, daß ich meine Seite mit CSS gestalten wollte.

Beim Versuch meine Seite auf CSS zu trimmen mußte ich aber leider feststellen, daß CSS von gängigen Browsern nicht ausreichend unterstützt wird.

Die hier oft verbreite Meinung CSS statt Tabellen fürs Seitenlayout zu vewenden geht also absolut an der Realität vorbei.

Insbesondere Anfängern (so wie mich) rate ich daher dringenst davon ab, das Seitenlayout komplett mit CSS zu gestalten. Formatieren des Schriftgrads oder ähnliche Dinge mit CSS zu bewerkstelligen ist natürlich absolut ok.

Also liebe Anfänger, benutzt Tabellen! Glaubt nicht was die "Gurus" euch erzählen. Die "Gurus" haben andere Browser.

Gruß
Frankie

http://www.brasilieninformation.de/test/upload_2003_11_18/index2.php
(Zwischenstufe: Tabelle mit ein bisschen CSS)

[Bio]

Sup!

Was haben denn die Gurus für Browser?

Gruesse,

Bio

[FrankieB]

Hi Bio,

Was haben denn die Gurus für Browser?

*LOL* ... auf jeden Fall einen anderen als ich ,-)

Grüsse
Frankie

[Cheatah]

Hi,

Die hier oft verbreite Meinung CSS statt Tabellen fürs Seitenlayout zu vewenden geht also absolut an der Realität vorbei.

nein, nur an der Unfähigkeit mancher Leute, ihre Denkweise zu reparieren.

Insbesondere Anfängern (so wie mich) rate ich daher dringenst davon ab, das Seitenlayout komplett mit CSS zu gestalten.

Wenn Du gar nicht erst mit dem Tabellen-Blödsinn angefangen hättest, hättest Du niemals ein Problem gehabt.

Cheatah

[FrankieB]

Hi, Cheatah,

nein, nur an der Unfähigkeit mancher Leute, ihre Denkweise zu reparieren.

Gut, ich mag nicht sonderlich fähig sein, aber das Denken in seiner Grundform traue ich mir schon noch zu.

Wenn Du gar nicht erst mit dem Tabellen-Blödsinn angefangen hättest, hättest Du niemals ein Problem gehabt.

... das stimmt wohl ... aber vor 2-3 Jahren wurde das (auch hier) als Stand der Dinge verzapft ...

Gruß

Frankie

[Cheatah]

Hi,

nein, nur an der Unfähigkeit mancher Leute, ihre Denkweise zu reparieren.
Gut, ich mag nicht sonderlich fähig sein, aber das Denken in seiner Grundform traue ich mir schon noch zu.

der Mensch ist ein Gewohnheitstier: Wenn er sich eine Art zu denken angewöhnt hat, kommt er schwer davon ab. Die Denkweise, die zur (missbräuchlichen) Nutzung von Tabellen für Layoutzwecke führt, ist jedoch eine falsche - daher muss sie repariert werden.

Wenn Du gar nicht erst mit dem Tabellen-Blödsinn angefangen hättest, hättest Du niemals ein Problem gehabt.
... das stimmt wohl ... aber vor 2-3 Jahren wurde das (auch hier) als Stand der Dinge verzapft ...

Ja, damals gewöhnte "man" sich gerade erst an den Gedanken, dass CSS das einzige Mittel der Darstellung ist und begann, Tabellen so zu verstehen, wie sie gedacht sind. Niemand hat behauptet, der "Umstieg" von Tabellen auf CSS[1] sei einfach - sondern nur wichtig und richtig.

Cheatah

[1] Bescheuerte Formulierung. Selbstverständlich wird auch die Darstellung von Tabellen nur über CSS geregelt.

[Cyx23]

Hallo,

der Mensch ist ein Gewohnheitstier: Wenn er sich eine Art zu denken angewöhnt hat, kommt er schwer davon ab. Die Denkweise, die zur (missbräuchlichen) Nutzung von Tabellen für Layoutzwecke führt, ist jedoch eine falsche - daher muss sie repariert werden.

Wenn Du gar nicht erst mit dem Tabellen-Blödsinn angefangen hättest, hättest Du niemals ein Problem gehabt.
... das stimmt wohl ... aber vor 2-3 Jahren wurde das (auch hier) als Stand der Dinge verzapft ...
Ja, damals gewöhnte "man" sich gerade erst an den Gedanken, dass CSS das einzige Mittel der Darstellung ist und begann, Tabellen so zu verstehen, wie sie gedacht sind. Niemand hat behauptet, der "Umstieg" von Tabellen auf CSS[1] sei einfach - sondern nur wichtig und richtig.
[1] Bescheuerte Formulierung. Selbstverständlich wird auch die Darstellung von Tabellen nur über CSS geregelt.

den 2-3 Jahren möchte ich, unabhängig vom Ort, so bzgl. Tabellen widersprechen.

Die oft nicht sinnvolle Vermengung von richtiger Auszeichnung/ 'richtiges HTML', CSS, tableless layout mit den w3c-papperln oder Barrierefreiheit ist allerdings neu, und erinnert als Anwendung industrieller Normen auch mal an die Einführung der EU-Banane mit vorgeschriebenem Krümmungswinkel.

Interessant bei deinem Posting die deutlich werdenden Defizite von CSS. Deswegen m.E. auch die "Bescheuerte Formulierung".
Abgesehen von den Unfähigkeiten von CSS selbst möchtest du vmtl. diese durch den Verzicht auf Tabellen entstehenden Probleme als Argument für ein layoutfreies Internet mißbrauchen (wird "mißbrauchen" übrigens hier im Forum mal Unwort des Jahres?).

CSS heute ist ja wohl die Umsetzung von Vorschlägen aus 1997 oder gar 1996. Keiner der CSS-Entwickler dürfte vom Verzicht des "Tabellen-Blödsinns" ausgegangen sein, entsprechende Mängel von CSS -es geht ja nicht nur um Browser- erklären sich so und sind nach deiner Argumentation zwingend.
Wenn bzw. wo CSS doch stärker Layoutaufgaben wie Tabellen nach den Plänen der Entwickler übernehmen sollte, hatten sowohl MS als auch NC ein Konzept eines mächtigeren dynamischen CSS mit JavaScript vorgesehen und bei NC4 (dynamische HTML-Attribute) und den IE ab 5 (expression) realisiert.
Jetzt bestehen also bei reinem CSS in deinem Sinne bereits mindestens zwei Defizite, das von DHTML bzw ähnlichen CSS-Techniken und das der Tabellen. Wenn jetzt noch auf Browserweichen verzichtet wird können wir die Beschäftgung mit CSS gleich durch den ultimativen Browser namens Lynx ersetzen.

Grüsse

Cyx23

[at]

Hallo.

Die oft nicht sinnvolle Vermengung von richtiger Auszeichnung/ 'richtiges HTML', CSS, tableless layout mit den w3c-papperln oder Barrierefreiheit ist allerdings neu, und erinnert als Anwendung industrieller Normen auch mal an die Einführung der EU-Banane mit vorgeschriebenem Krümmungswinkel.

Wie in den meisten Fällen dient die Norm auch hier nicht dem Selbstzweck.

(wird "mißbrauchen" übrigens hier im Forum mal Unwort des Jahres?).

Nur wegen der vermeintlich veralteten Schreibweise? ;-)

CSS heute ist ja wohl die Umsetzung von Vorschlägen aus 1997 oder gar 1996.

Das ist nicht unwahrscheinlich, womit diese Vorschläge vergleichsweise neu wären, wenn man sie mit anderen im Web gebräuchlichen Techniken vergleicht.

Wenn bzw. wo CSS doch stärker Layoutaufgaben wie Tabellen nach den Plänen der Entwickler übernehmen sollte, hatten sowohl MS als auch NC ein Konzept eines mächtigeren dynamischen CSS mit JavaScript vorgesehen und bei NC4 (dynamische HTML-Attribute) und den IE ab 5 (expression) realisiert.

MS und NC (NS?) hatten nicht _ein_ Konzept, sondern _jeweils_ein_ Konzept. Wohin dies führt, lehrt uns der Aufwand, den viele noch immer für den NC 4.x betreiben.

Jetzt bestehen also bei reinem CSS in deinem Sinne bereits mindestens zwei Defizite, das von DHTML bzw ähnlichen CSS-Techniken und das der Tabellen.

DHTML leidet meines Erachtens am meisten darunter, dass JavaScript erstens oft fehlerbehaftet und offenbar ungetestet eingesetzt wird, zweitens oftmals für groben Unfug eingesetzt wird und drittens eine große Sicherheitslücke in den meistverbreiteten Browsern darstellt.

Wenn jetzt noch auf Browserweichen verzichtet wird können wir die Beschäftgung mit CSS gleich durch den ultimativen Browser namens Lynx ersetzen.

Das ist doch zumindest mal ein konstruktiver Vorschlag ;-)
MfG, at

[Cyx23]

Hallo,

(wird "mißbrauchen" übrigens hier im Forum mal Unwort des Jahres?).

Nur wegen der vermeintlich veralteten Schreibweise? ;-)

nun, vielleicht sollten wir mal das Archiv entspechend befragen, wie oft gerade dieses Wort miszbraucht wurde...

MS und NC (NS?) hatten nicht _ein_ Konzept, sondern _jeweils_ein_ Konzept. Wohin dies führt, lehrt uns der Aufwand, den viele noch immer für den NC 4.x betreiben.

Nein, sie hatten _ein_ Defizit zu lösen gesucht, wohin das führt sehen wir heute an Fehlern des IE 6 und eben auch zukünftig an der Problematik überhaupt Layout per CSS zu realisieren.

Jetzt bestehen also bei reinem CSS in deinem Sinne bereits mindestens zwei Defizite, das von DHTML bzw ähnlichen CSS-Techniken und das der Tabellen.

DHTML leidet meines Erachtens am meisten darunter, dass [...]

Klar, aber die Defizite bei CSS bleiben uns wie auch die vielseitigen Tabellen dennoch erhalten.

Grüsse

Cyx23

[at]

Hallo.

MS und NC (NS?) hatten nicht _ein_ Konzept, sondern _jeweils_ein_ Konzept. Wohin dies führt, lehrt uns der Aufwand, den viele noch immer für den NC 4.x betreiben.

Nein, sie hatten _ein_ Defizit zu lösen gesucht, wohin das führt sehen wir heute an Fehlern des IE 6 und eben auch zukünftig an der Problematik überhaupt Layout per CSS zu realisieren.

Das einzige, was ich an deiner Aussage nicht verstehe, ist das "Nein", da du mir gar nicht widersprichst :-)
MfG, at

[Stefan Muenz]

Hallo Cheatah,

nein, nur an der Unfähigkeit mancher Leute, ihre Denkweise zu reparieren.

Dein Fundamentalismus in allen Ehren - aber meinst du, du schaffst es mittlerweile, das SELF-Layout 1:1 in ein CSS-Layout umzubauen, welches zumindest in Mozilla 1.x, MS IE 6.x, Opera ab 6.x und vielleicht noch Konqueror ziemlich gleich aussieht (von NS 4.x rede ich gar nicht mehr)? Obwohl das SELF-Layout gar nicht so aufwaendig ist, wirst du vermutlich trotzdem ziemlich ins Schwitzen kommen, diverse Workarounds brauchen und tricksen muessen, was die reine Lehre doch arg aufweicht. Oder du sagst einfach, das SELF-Layout sei eben kein typisches CSS-Layout. Damit stellst du dir dann aber ein logisches Bein. Denn form follows function, und wenn die Form technisch nicht flexibel genug ist, allen nun mal gewuenschten Wegen zu folgen, dann ist sie eben technisch noch nicht befriedigend.

Die reine CSS-Lehre verbreitet sich auch nicht dadurch, dass sie nur propagiert wird. Es muessten einfach all die armen Leute durch Tatsachen ueberzeugt werden, die ein mit Photoshop oder Illustrator erstelltes Bild mit einem Layoutentwurf vor sich haben und diesen nun in HTML und CSS umsetzen sollen. Eine idiotische Vorgehensweise? Vielleicht - aber so laeufts nun mal in der Praxis, wo nicht der kleine Webdesigner das Design bestimmt, sondern wo lauter wichtige Leute, die null Ahnung von HTML und CSS haben, irgendwelche wichtigen Vorstellungen vom Aussehen so einer Seite haben, und wo es schliesslich ein Grafiker mit Muehe geschafft hat, all diese Vorstellungen in ein EPS-File zu bringen, welches nun umgesetzt werden soll ...

viele Gruesse
  Stefan Muenz

[Struppi]

Hallo Cheatah,

nein, nur an der Unfähigkeit mancher Leute, ihre Denkweise zu reparieren.

Dein Fundamentalismus in allen Ehren - aber meinst du, du schaffst es mittlerweile, das SELF-Layout 1:1 in ein CSS-Layout umzubauen, welches zumindest in Mozilla 1.x, MS IE 6.x, Opera ab 6.x und vielleicht noch Konqueror ziemlich gleich aussieht (von NS 4.x rede ich gar nicht mehr)? Obwohl das SELF-Layout gar nicht so aufwaendig ist, wirst du vermutlich trotzdem ziemlich ins Schwitzen kommen, diverse Workarounds brauchen und tricksen muessen, was die reine Lehre doch arg aufweicht. Oder du sagst einfach, das SELF-Layout sei eben kein typisches CSS-Layout. Damit stellst du dir dann aber ein logisches Bein. Denn form follows function, und wenn die Form technisch nicht flexibel genug ist, allen nun mal gewuenschten Wegen zu folgen, dann ist sie eben technisch noch nicht befriedigend.

Ich seh das mit den Tabellen zwar nicht so eng wie Cheatah, ganz im gegenteil halte ich Tabellen auch für eine Möglichkeit den Inhalt in Spalten anzuordnen, da es dafür (noch) keine bessere Möglichkeit gibt, aber das self Layout sollte doch ohne Probleme ohne Tabellen umzusetzten sein.

Wo sind denn da die Probleme?

Zumal die Tabellen wirklich nur farbige Bereich beschreiben (wenn ich das beim kurzen drüberblicken richitg sehe)

Struppi.

[wahsaga]

hi,

aber das self Layout sollte doch ohne Probleme ohne Tabellen umzusetzten sein.

Wo sind denn da die Probleme?

ganz so einfach ist es nicht, sieh dir mal diesen thread an: [pref:t=63823&m=362307].

gruss,
wahsaga

[Cheatah]

Hi,

meinst du, du schaffst es mittlerweile, das SELF-Layout 1:1 in ein CSS-Layout umzubauen, welches zumindest in Mozilla 1.x, MS IE 6.x, Opera ab 6.x und vielleicht noch Konqueror ziemlich gleich aussieht (von NS 4.x rede ich gar nicht mehr)?

keine Ahnung, ich hab's noch nicht probiert. Mein Fundamentalismus zwingt mich aber auch zu den Fragen, ob a) eine 1:1-Umsetzung sinnvoll ist, und warum b) das (wenn auch ziemlich) gleiche Aussehen von Bedeutung sein soll.

Obwohl das SELF-Layout gar nicht so aufwaendig ist, wirst du vermutlich trotzdem ziemlich ins Schwitzen kommen,

Vermutlich.

diverse Workarounds brauchen

Andere Entscheidungen fällen, die rein auf Optik basierende (denk-)strukturelle Fehler zu annulieren suchen.

und tricksen muessen, was die reine Lehre doch arg aufweicht.

An dieser Stelle möchte ich noch einmal auf die "Dirty Notes" hinweisen, zu denen ich dereinst etwas schrieb.

Oder du sagst einfach, das SELF-Layout sei eben kein typisches CSS-Layout.

Hm, was verstehst Du hier unter "typisches CSS-Layout", auch ohne "typisch"?

Es muessten einfach all die armen Leute durch Tatsachen ueberzeugt werden, die ein mit Photoshop oder Illustrator erstelltes Bild mit einem Layoutentwurf vor sich haben und diesen nun in HTML und CSS umsetzen sollen.

Eben diese Leute lassen sich leider, leider nur sehr schlecht überzeugen, weil sie potentiell ihr Hauptaugenmerk auf den IE lenken (bzw. nicht davon weg), der ja nun in Sachen CSS eher 'ne Niete ist.

Eine idiotische Vorgehensweise? Vielleicht - aber so laeufts nun mal in der Praxis, wo nicht der kleine Webdesigner das Design bestimmt, sondern wo lauter wichtige Leute, die null Ahnung von HTML und CSS haben, irgendwelche wichtigen Vorstellungen vom Aussehen so einer Seite haben, und wo es schliesslich ein Grafiker mit Muehe geschafft hat, all diese Vorstellungen in ein EPS-File zu bringen, welches nun umgesetzt werden soll ...

Selbst in Firmen, wo der Entscheidungsträger selbst ein erfahrener Webentwickler ist, sind die Vorgaben noch hoffnungsfrei veraltet. Aber mittlerweile werden auch bei uns die Stimmen immer lauter ... :-)

Cheatah

[JanH.]

Hallo an alle,

Was haltet Ihr davon, nochmals das bestehende SELFHTML Layout unter die Finge zu nehmen und eine Konstruktion ohne Layouttabellen zu entwerfen.

Ich denke, dass das eine recht interesante Angelegenheit werden könnte.
Mich persönlich würde vorallem interessieren wie viele verschiedenen herangehensweisen dabei herauskommen, sprich, wie mit <div> und <p> und <table> und <ul> etc "jongliert" wird um letztendlich ein ähnlich optisches Ergebnis zu erreichen.

Der Anfang:

http://fractatulum.net/kram/templates/self-layout/index.htm
SELFHTML Layouttest

Ich habe nur unter Windows geteste in Mozilla1.5, Netscape6, Oper5+ und IE6. Für NN4 wäre halt noch ein anders bzw kein CSS nötig. Obwohl, glaube ich, für NN4 gar nicht soviel geändert werden muss, hauptsächlich die margins.

Ja, ich würde mich freuen wenn einige Beispiele zusammenkommen, vieleicht wäre das ja auch eine Basis für einen Featureartikel:
"Die vielen Wege nach Rom oder wie kann man an ein CSS-Layout herangehen"
oder so :)

Gruss, Jan aus Dresden

[Ingo Turski]

Hi,

für den Anfang ja nicht schlecht, aber der Netscape 4 bräuchte wohl noch etwas mehr Korrekturen ..;-)

Allerdings auch nicht sonderlich flexibel; wenn man das Fenster verkleinert,
verkleinern sich lediglich die Spalten, wie man das von prozentual definierten Tabellen kennt.

CSS kann doch wesentlich mehr - mal ein Beispiel von mir:
  http://www.1ngo.de/web/selfhtml.html

100%-ig flexibel, sowohl was den Schriftgrad betrifft, als auch die Fenstergröße
(bei zu kleinem Fenster wird sinnvoller Weise erst mal das Layout auf eine Spalte reduziert).
Und es wird sogar - mit ein paar Abstrichen - im Netscape 4 vernünftig dargestellt;
ohne CSS-Hacks oder Verstecken von Styles.

Also ich finde, das ist ein Beispiel, das das Tabellen-Layout deutlich schlägt.

freundliche Grüße
Ingo

[Stefan Muenz]

Hallo Ingo,

http://www.1ngo.de/web/selfhtml.html

Kompliment: ich habe in Firebird 0.7, MS IE 6.0 und Opera 7.0 keine markanten Unterschiede feststellen koennen. Fenster-Resize funktionierte in allen Browsern einwandfrei. Die Aufteilung der div-Bereiche ist logisch nachvollziehbar und keine sinnlose "div-Suppe". XHTML strict ist auch prima, nur bei einigen Anzeigebeispielen wird man davon wohl abruecken muessen. Die em's bei den Schriftgroessen sind mir allerdings gleich aufgefallen - in Firebird wirken die Schriften bei mir kleiner. Mit px waer das nicht passiert ;-)
Auf jeden Fall die beste Loesung, die ich bislang gesehen habe! Da revidiere ich doch gerne, was ich Cheatah geantwortet habe ;-)

viele Gruesse
  Stefan Muenz

[Ingo Turski]

Hi Stefan,

danke für's Kompliment.
Ich hätte es sogar noch etwas strukturierter und mit noch weniger DIVs hinbekommen,
aber dann wären einige CSS-Hacks für den IE erforderlich gewesen und die wollte ich ja vermeiden.
Schade - aber vertretbar - finde ich, daß der Netscape 4 den Hintergrund nicht darstellt
und den Inhaltsbereich zu weit rechts setzt. Was hat er bei
  .inhalt { margin-left:9em; background:white; padding:0.7em 1em 0; }
an dem margin-left auszusetzen? Muß man diese Anweisung echt vor ihm verstecken?

Die em's bei den Schriftgroessen sind mir allerdings gleich aufgefallen - in Firebird wirken die Schriften bei mir kleiner. Mit px waer das nicht passiert ;-)

Das stimmt natürlich.
Ich war bisher immer davon ausgegangen, daß Firebird eine ähnliche Darstellung wie Mozilla hat.
Da allerdings noch etwas "Luft" in den EMs ist, bevor die Schrift um 1px in den anderen Browsern vergrößert wird, habe ich jetzt aus 0.8em (von 101%) 0.83em gemacht.
Schau' mal mit Firebird, ob der Schriftgrad jetzt passt.
Ich finde EMs wirklich wesentlich besser geeignet als feste Größenangaben, auch für Abstände und manchmal sogar - wie hier - für die Breite von Elementen.

Auf jeden Fall die beste Loesung, die ich bislang gesehen habe! Da revidiere ich doch gerne, was ich Cheatah geantwortet habe ;-)

Das freut mich. Und wenn auch der Ausgangsposter seine Meinung zu CSS überdenkt, dann hat sich die Arbeit doppelt gelohnt ;-)

Als ich vor einem guten Jahr mit reinen CSS-Layouts begonnen hatte, war ich zunächst auch auf etliche Hürden gestoßen. Fast hätte ich es schon aufgegeben und wäre bei den Tabellen geblieben, aber mit etwas Suchen, Ausprobieren und Hilfe in Foren wie diesem hatte ich dann schließlich doch meine ersten CSS-Layouts browserübergreifend hinbekommen. Man muß sich nach meiner Erfahrung nur etwas mehr Mühe geben, aber es lohnt sich.

freundliche Grüße
Ingo

[Jan H.]

Hallo Ingo,

Schade - aber vertretbar - finde ich, daß der Netscape 4 den Hintergrund nicht darstellt

Versehe die bereiche mit hintergrundfarben mit border:none; für den NN4 dass wirkt wunder!

n aus Dresden

[Kristof Lipfert]

Hallo Stefan,

' .. welches zumindest in Mozilla 1.x, MS IE 6.x, Opera ab 6.x und vielleicht noch Konqueror ziemlich gleich aussieht (von NS 4.x rede ich gar nicht mehr)?'

.. Die Aufteilung der div-Bereiche ist logisch nachvollziehbar und keine sinnlose "div-Suppe"

Konqueror wäre schon empfehlenswert, und IE 5 und IE 5.5 sind ja auch noch unterwegs..

Für Netscape 4 gibt es valide Möglichkeiten, ob JSSS oder weniger exotisch eine CSS-Weiche per 'Kommentar' wie diese mit Massnahmen für Opera 5 http://www.lipfert-malik.de/webdesign/tutorial/bsp/kristof-lipfert-nc4-crossover.html, die vor allem die Option bieten für Netscape 4 auch nach der eigentlichen Entwicklung noch nachhelfenden oder alternativen CSS-Code im Kommentar des Stylesheets einzubauen. Also bis auf notfalls mal ein *-Selektor um NC4 auszuschliessen im eigentlichen CSS wie auch im HTML keine Klimmzüge für diesen Browser.
So kann die Frage wie NC4 zu bedienen ist auch noch spät geklärt werden, besonders wenn bei den verschiedenen Methoden auch eine CSS-Weiche per Kommentar usw. im Stylesheet nicht ausgeschlossen wird.

Beim Beispiel von Ingo ist mir die häufige Verwendung von <p> augefallen, wäre hier nicht u.U. <li> besser oder ist <p> nötig um etwa Probleme bei mehreren Spalten zu vermeiden?
<p ? li><img src="http://selfhtml.teamone.de/src/kap.gif" alt="Kapitel" /> <a href="#">HTML/XHTML</a></p ? li>

Auch '<p id="header">' könnte ich mir als <h6> vorstellen, gar nicht dass es besser "funktionieren" würde, aber vielleicht hätte es Vorteile hier zuerst ein HTML-Grundgerüst festzulegen- hoffentlich ohne damit angesichts der Unzulänglichkeiten von Browsern+CSS zuviele alternative Lösungen auszuschliessen.

Grüße,
Kristof

[Christian Kruse]

Hallo Kristof,

Beim Beispiel von Ingo ist mir die häufige
Verwendung von <p> augefallen, wäre hier nicht
u.U. <li> besser oder ist <p> nötig um etwa
Probleme bei mehreren Spalten zu vermeiden?
<p ? li><img src="http://selfhtml.teamone.de/src/kap.gif" alt="Kapitel" /> <a href="#">HTML/XHTML</a></p ? li>

ich wuerde eher

<li style="list-style-image:url(/src/kap.gif)"><a href="#">HTML/XHTML</a></li>

behaupten. Wobei ich das style="" noch in eine
Klasse oder per Selektor definieren wuerde.

Gruesse,
 CK

[Tim Tepaße]

Hallo CK,

<li style="list-style-image:url(/src/kap.gif)"><a href="#">HTML/XHTML</a></li>

Irks. Gerade noch woanders etwas dazu geschrieben. Ich copy-und-paste mich
mal hierhin, wegen der Öffentlichkeit:

Das würde weitere, schwierige Fragen über die Linkkennzeichnung in SELFHTML
aufwerfen.

Es gibt ja verschiedene Methoden, über die Einbindung der Symbole
als Bild, als Hintergrundbilder oder als - allerdings unrealistische -
Möglichkeit mit dem :before-Pseudoelement. Nur bei der Einbindung als Bild
bleiben Metainformationen wie »Kapitel« auch in einer nicht-CSS-Darstellung
erhalten. Man muß sich also entscheiden, ob man diese Metainformationen
haben will, wenn ja wie, Browser-Bugs berücksichtigen und das ganze dann
möglichst konsequent durchsetzen. Weswegen ich wegen der Konsequenz die
Möglichkeit des list-style-images ignorieren würde.

Tim

[Ingo Turski]

Hi,

<li style="list-style-image:url(/src/kap.gif)"><a href="#">HTML/XHTML</a></li>

wäre zwar optimal, aber auch das verstehen ältere Browser leider nicht.

Übigens ein Nachtrag zur logischen Auszeichnung: Betrachtet mal die reine Textdarstellung im Opera.
M.E. stimmt da wirklich alles.

freundliche Grüße
Ingo

[Kristof Lipfert]

Hallo Christian, hallo Ingo,

ich wuerde eher

<li style="list-style-image:url(/src/kap.gif)"><a href="#">HTML/XHTML</a></li>

behaupten. Wobei ich das style="" noch in eine
Klasse oder per Selektor definieren wuerde.

meine Entscheidung wäre hier <li>, ohne Inlinestyle.

IE 4 und Netscape 4 sollten auch damit klar kommen, der von Ingo befürchtete Verlust der link-Eigenschaft beim NC4 muss nicht auftreten weil ja der a-Tag kein display:block usw. erfährt.

Ein Beispiel dazu für Netscape 4: http://www.lipfert-malik.de/webdesign/tutorial/bsp/listenjsss.html, das JSSS an sich ist kein Problem, das sollte auch per CSS realisierbar sein. (Beispiel aus http://www.lipfert-malik.de/webdesign/tutorial/css.html#Listen)

Allerdings dürfte da eine Browserweiche, z.B. per JSSS oder die CSS-Weiche per Kommentar, nötig sein.

Grüße,
Kristof

[Ingo Turski]

Hi Kristof,

Beim Beispiel von Ingo ist mir die häufige Verwendung von <p> augefallen, wäre hier nicht u.U. <li> besser oder ist <p> nötig um etwa Probleme bei mehreren Spalten zu vermeiden?

Das habe ich gerade bei der Antwort zu Jan ausgeführt. Das Hauptproblem sind nicht die mehreren Spalten, sondern die CSS-Formatierung von Listen - diese müßte ich zwangsläufig vor dem Netscape 4 verstecken, da sonst meiner Erfahrung nach die Links für ihn nicht mehr nutzbar sind.

Auch '<p id="header">' könnte ich mir als <h6> vorstellen, gar nicht dass es besser "funktionieren" würde, aber vielleicht hätte es Vorteile hier zuerst ein HTML-Grundgerüst festzulegen- hoffentlich ohne damit angesichts der Unzulänglichkeiten von Browsern+CSS zuviele alternative Lösungen auszuschliessen.

Ob Du es glaubst oder nicht: dieses Grundgerüst hatte ich sehr wohl im Kopf. Und etwas anderes als <h1> sollte man als erste Überschrift nicht verwenden; es gilt unter dem Aspekt der Barrierefreiheit die Reihenfolge von Überschriften einzuhalten. Und als Überschrift erster Ordnung sehe ich den Titel SELFHTML, den ich auch so ausgezeichnet habe.
Die Passagen davor sehe ich eher als 'Vorwort' oder Einstieg und somit logisch nicht anders als mit <p> auszuzeichnen.

freundliche Grüße
Ingo

[Tim Tepaße]

Hallo Kristof (Cyx?),

So kann die Frage wie NC4 zu bedienen ist auch noch spät geklärt werden,
besonders wenn bei den verschiedenen Methoden auch eine CSS-Weiche per
Kommentar usw. im Stylesheet nicht ausgeschlossen wird.

Ich würde sie aber ausschließen. Nicht um Netscape-Nutzer zu ärgern, sondern
weil das Stylesheet von SELFHTML über Umwege auch ein Mittel zum lernen ist.
Es kann oft das erste wirkliche Stylesheet sein, das man sieht (Mir ging es
zu meiner Zeit so) und aus dem man lernen kann. Kommentar-Hacks oder Hacks für
andere Browser, wie z.B. Conditional Comments wären da sehr  fehl am Platze
(Höchstens,  wenn dann ausführlich kommentiert wird, wozu der Hack) gut ist.
Sehr ausführlich.

Ich finde, die Frage wie (das »ob« muß außer Frage stehen) man Netscape 4.x
bedient recht am Anfang stehen muß, da seine Fähigkeiten auch dann etwas
die verschiedenen Designentscheidungen beeinflussen. Kompliziertere Möglichkeiten
von CSS, wie floats fallen dann leider raus. :(

Tim

[Cyx23]

Hallo Tim,

zu meiner Zeit so) und aus dem man lernen kann. Kommentar-Hacks oder Hacks für
andere Browser, wie z.B. Conditional Comments wären da sehr  fehl am Platze
(Höchstens,  wenn dann ausführlich kommentiert wird, wozu der Hack) gut ist.

die erklärenden Kommentare sollten ja hoffentlich kein Problem sein.

Die hier empfohlene Weiche http://www.lipfert-malik.de/webdesign/tutorial/bsp/kristof-lipfert-nc4-crossover.html
würde ich dazu auch anders bewerten als einige "Hacks".
Der Code für NC4 ist validierbar, steht in einem Kommentar und würde bei Zugang
durch einen anderen Browser überwiegend noch durch die Syntax ohne "-" abgefangen.

Und wenn sich hier wie auch beim < Selektor für die IE die Mängel von CSS
(oder CSS i.d. praktischen Anwendung) offenbaren kann das in deinem Sinne
("zu meiner Zeit ") nur richtig sein.

Grundsätzlich bin ich gegen Hacks, ganz besonders wenn sie bei zukünftigen Browsern
nicht zuverlässig sein dürften.
Damit fallen einige hier im Forum früher propagierte und von mir kritisierte Hacks
für Opera 7 durch die Weiterentwicklung des Mozilla folgerichtig weg, beim Netscape 4
ist sowas nicht zu befürchten. Ich sehe das eher als psychologisches Problem, ein
befürchteter Verlust von Werten, Reinheit oder Unschuld. Solch ein Bedürfnis nach
Unschuld sollte soweit rataionalisiert werden dass noch eine funktioniernde Website
dabei raus kommt, zumal es hier auch noch W3C-validierbar ist.

» Ich finde, die Frage wie (das »ob« muß außer Frage stehen) man Netscape 4.x

bedient recht am Anfang stehen muß, da seine Fähigkeiten auch dann etwas
die verschiedenen Designentscheidungen beeinflussen. Kompliziertere Möglichkeiten
von CSS, wie floats fallen dann leider raus. :(

Hier (nicht Forum, sondern Netscape 4) sehe ich eher das Problem ob sich jemand noch
umfassend mit Netscape 4 beschäftigen möchte. Kompliziertere Möglichkeiten von CSS wie
floats sind ja gerade für Netscape 4 die Lösung um anspruchsvolles tableless layout zu
realiseren, die Lösung für x-spaltige Layouts ohne Tabellen für Netscape 4, wie auch
Listen bei gruppierten Links letztendlich beherrschbarer sind als etwa /a><br .

Die von dir erwähnte Forderung "am Anfang stehen"  kann man bejahen wenn Netscape 4
optimal bedient werden soll. Zumal Netscape 4 geeigneter Code sehr reduziert und
richtig sein kann. Hier halte ich es aber doch für sinnvoll die Einschränkungen erstmal
etwas zu reduzieren, also Netscape 4 etwas weniger zu betrachten um erstmal die nötigen
"moderneren" Ansprüche zu definieren. Danach mag im Einzelfall geprüft werden ob für
Netscape 4 eine Änderung im HTML den Umgang mit float erleichtert, zur Not ist ja ggf.
ein <br style="clear:all"> für Netscape 4 hilfreich und stört sonst i.d.R. nicht.
Einige Dinge sind sogar bei Netscape 4 ähnlich realisierbar wie für Mozilla,
die IE-Problematik, zumal IE5,.5.5. und 6 untereinander, ist teilweise viel
heftiger als der Ärger mit Netscape 4.

Eine Netscape 4 spezifische Zensur was möglich sei und was nicht halte ich aber heute
nicht mehr für sinnvoll, zumal ja Netscape 4  (ggf. mit CSS-Weiche o.ä.) doch sehr viel
mehr kann als allgemein vermutet.

Nicht allgemeingültig werden m.E. die Entscheidungen erst bei dem Punkt, welches Risiko
denn bzgl. NC4 eingegangen werden sollte, ob NC 4.03, 4.51, 4.70 alle getestet werden
müssen usw. usw. Hier ist meine Entscheidung möglichst auch den NC4.03 zu testen,
ggf. ein margin-left:.1em für ihn einzuflicken, aber ansonsten z.B. hinsichtlich der
Stabilität den 4.80 als Masstab zu nehmen.

"die verschiedenen Designentscheidungen" müssen nach meinen Erfahrungen nicht wesentlich
wegen Netscape 4 eingeschränkt werden wenn es um reduzierten sauberen Code geht. Für
Netscape 4 entwickeln wäre nicht mehr zeitgemäss, mit ihm Testen schon, aber man sollte
Netscape 4 schon per CSS-Weiche o.ä. unterstützen.

Grüsse

Cyx23

[Tim Tepaße]

Hallo Cyx,

die erklärenden Kommentare sollten ja hoffentlich kein Problem sein.

Aber beim Neuling Verwirrung stiftend.

Und wenn sich hier wie auch beim < Selektor für die IE die Mängel von CSS
(oder CSS i.d. praktischen Anwendung) offenbaren kann das in deinem Sinne
("zu meiner Zeit ") nur richtig sein.

Es gibt keinen < Selektor (aus meiner Meinung nach unnötigen Performancegründen).
Hast Du Dich vertippt und meinst den > Selektor, den der IE nicht unterstützt?
Oder gibt es irgendwelche anderen Probleme, die mir nicht bekannt sind?

Solch ein Bedürfnis nach Unschuld sollte soweit rataionalisiert werden
dass noch eine funktioniernde Website dabei raus kommt, zumal es hier auch
noch W3C-validierbar ist.

Ich weiß nicht, inwieweit man in einem Lehrwerk rationalisieren kann, bzw.
nur nach pragmatischen Gesichtspunkten vorgegangen werden sollte. Auch wenn
Dein Beispiel validiert, von der Syntax, des Nochvollziehens und der
Erlernbarkeit dieser her betrachtet (und ja, auch an gewissen utopischen
Idealen gemessen), halte ich es für Wahnsinn, so praktisch es auch ist.

Tim

[Cyx23]

Hallo Tim,

die erklärenden Kommentare sollten ja hoffentlich kein Problem sein.

Aber beim Neuling Verwirrung stiftend.

m.E. ist die beim Webdesign nötige unscharfe oder flexible Handhabung von Code oder Problemen mit oder ohne Netscape 4 sowieso unumgänglich, so unterschiedlich wie das Ergebnis bei modernen Browsern ist.

Ein separater CSS-Block am Ende des Stylesheets für Netscape 4 mit Erklärung vorneweg halte ich nicht nur für zumutbar, es wäre sogar ein übersichtliches Stylesheet mit erkennbaren Bereich für bestimmte Browser.

Falls tatsächlich ein CSS für eine komplexere Seite ohne Weichen auskommt, ist es eher ein gesuchter Zufall, der zudem die genaue Browserkenntnis und immer noch einige Redundanzen und Vermeidungen nach Browser und doctype erfordert.

Oder gibt es irgendwelche anderen Probleme, die mir nicht bekannt sind?

Ein "Typo", allerdings unterstützt durch eine bei Shift usw. etwas eigenwillige Tastatur

Ich weiß nicht, inwieweit man in einem Lehrwerk rationalisieren kann, bzw.
nur nach pragmatischen Gesichtspunkten vorgegangen werden sollte. Auch wenn

Wer da in den Quellcode schaut soll kein Chaos sehen, aber das würde ja auch nicht entstehen. Die Lösung ist präsentabel und hat Vorteile gegenüber JSSS und ist auch besser als per JavaScript erzeugter Code a la document.write('<style..

Ansonsten geht es erstmal darum ein funktionierendes CSS ohne Einflüssse auf den HTNML-Code bereitzustellen, und bei Netscape 4 float und Listen umsetzen zu können. Erstmal soll die betr. Website sauber rüberkommen, der Code wäre immer noch aufgeräumt, ggf. barrierefrei mit konsistentem Layout bei Netscape 4 usw.

Dein Beispiel validiert, von der Syntax, des Nochvollziehens und der
Erlernbarkeit dieser her betrachtet (und ja, auch an gewissen utopischen
Idealen gemessen), halte ich es für Wahnsinn, so praktisch es auch ist.

Danke für die Blumen.

Da die Weiche als Besonderheit Opera 5 sowieso schon berücksichtigt kann zwischen den Kommentarzeilen auch normale CSS-Syntax eingesetzt werden, das von dir geschilderte Problem bezieht sich also vor allem auf Start- und Endzeile.

Und Nochvollziehen kann sowas jeder der seinen Netscape 4 oder Opera 5 ausprobiert oder benutzt.

Grüsse

Cyx23

[Jan H.]

Hallo Ingo,
Ja, das sieht doch wirklich klasse aus!
Die idee mit dem umbrechen der beiden floatenden boxen gefällt mir sehr.

In opera5 klebt die linke box am grauen rand, ein padding-left:..; in #spalte1{} schafft da abhilfe.

Für die anordnung/auszeichnung der links in den boxen hast du <p> elemente genommen, ich finde da ja listen passender, gibt es gründe warum es unbedingt <p> ist?

Für NN4 wird deine variante etwas komplizierter passend zu machen sein, will man ein ähnlich optisches aussehen haben.
Da du die inhaltsbereiche mehrfach ausgezeichnet werden, class:inhalt;, bekommt man ein problem mit dem linken randabstand und somit mit dem durchgehenden grauen linken balken.
Bei einem durchgehenden inhaltsbereich, wie ich es gemacht habe, hätte man das problem nicht, man müsste nur margin-left:..; auf null setzen und es wäre gut.
Die float anordnung der zwei boxen mit der übersicht müsste man sich wahrscheinlich in NN4 verkneifen, ich glaube da wird es probleme mit dem clear geben.

Was mir an deine konstruktion nicht gefällt sind die leeren hilfs <div> elemente, die nur dazu dienen andere elemente in "form" zu bringen.
Das widerstrebt mir und würde ich nur sehr ungern so einsetzen.

Aber alles in allem ist es doch recht klasse.

Gruss, Jan aus Dresden

[Ingo Turski]

hi Jan,

border:0 habe ich mal versucht, aber der Netscape will auch damit noch nicht die Hintergrundfarbe setzen - so tragisch finde ich das dann aber auch nicht.
Ich bin eigentlich zufrieden, daß die Darstellung selbst im Netscape 4 Ähnlichkeit - und damit Wiedererkennungswert - hat und natürlich vollständig nutzbar ist.

Opera 5? Wer benutzt den denn noch? Bevor ich mit padding die IE-Verdoppelung provoziere bzw. diese dann durch ein zusätzliches DIV korrigiere, würde ich eher diese kleine Fehldarstellung im Uralt-Opera inkauf nehmen.

Die <p> Elemente habe ich bewußt genommen. Zum einen handelt es sich nicht um ein Menü im klassischen Sinn, sondern eher um eine verlinkte Inhaltsübersicht mit entsprechenden Überschriften. Zum anderen bereitet die Listenformatierung bei älteren Browsern meist große Probleme. Da die einzelnen Links außerdem durch eine vorgestellte Grafik voneinander getrennt werden, dürfte diese Auszeichnung auch barrierefrei sein.

Mit den leeren DIV Elementen hast Du ja Recht. Diese sowie das 'mitte'-DIV gefallen mir auch nicht ganz, aber dieses kleine Übel denke ich kann man tolerieren angesichts der dadurch erreichten stabilen Darstellung in den erschiedenen Browsern.

Freundliche Grüße
Ingo

[molily]

Hallo,

Ich bin eigentlich zufrieden, daß die Darstellung selbst im Netscape 4 Ähnlichkeit - und damit Wiedererkennungswert - hat und natürlich vollständig nutzbar ist.

Ich sehe im Netscape 4 im Prinzip nur Kuddelmuddel und finde es in dieser Form alles andere als akzeptabel. Benutzbarkeit ist nicht vom Layout abgekoppelt und existiert nicht von selbst, sondern ist ein Produkt eines Interfaces. Und dieses Interface ist schlichtweg wirr und chaotisch. Wenn die kritischen floats und margins verborgen würde, würde es etwas werden, so ist es aber mitunter schlechter benutzbar als eine Version komplett ohne CSS.

Die <p> Elemente habe ich bewußt genommen. Zum einen handelt es sich nicht um ein Menü im klassischen Sinn, sondern eher um eine verlinkte Inhaltsübersicht mit entsprechenden Überschriften.

Eine lineare, gleichförmige Abfolge, meist nach einer bestimmten Ordnung, nennt man Liste, sobald diese Liste die Rubrikhierarchie einer Site wiedergibt, kann man mit Recht von einem Menü sprechen.

Da die einzelnen Links außerdem durch eine vorgestellte Grafik voneinander getrennt werden, dürfte diese Auszeichnung auch barrierefrei sein.

Das ist im Prinzip kontraproduktiv, weil die Grafiken bestenfalls Teil des Links sein sollten, also <a><img/> ...</a>.

Mathias

[Cyx23]

Hallo Mathias,

Das ist im Prinzip kontraproduktiv, weil die Grafiken bestenfalls Teil des Links sein sollten, also <a><img/> ...</a>.

das leuchtet ein, ich hab gerade mal
<ul>
<li><a href="javascript:void(0);"><img src="xy.gif" width="16" height="12">Ziel 1</a></li>
für Netscape 4 basierend auf http://www.lipfert-malik.de/webdesign/tutorial/bsp/listenjsss.html getestet,
sieht gut aus.

Rahmen lassen sich bei dem JSSS-Beispiel per 'contextual(tags.UL, tags.IMG).color="white";'
abstellen, die Umsetzung in CSS ist kein Problem (mögliche Unterschiede beim ersten Laden der Bsp-Seite
beruhen auf einer 'Mischtechnik' um Impressum etc. einzublenden und nicht auf d. betr. Code)
Allerdings benötigt Netscape 4 eine valide CSS-Weiche wie die für Opera 5 optimierte
http://www.lipfert-malik.de/webdesign/tutorial/bsp/kristof-lipfert-nc4-crossover.html, oder z.B. doch JSSS.

Grüsse

Cyx23

[Ingo Turski]

Hi Mathias,

Ich sehe im Netscape 4 im Prinzip nur Kuddelmuddel und finde es in dieser Form alles andere als akzeptabel. Benutzbarkeit ist nicht vom Layout abgekoppelt und existiert nicht von selbst, sondern ist ein Produkt eines Interfaces. Und dieses Interface ist schlichtweg wirr und chaotisch. Wenn die kritischen floats und margins verborgen würde, würde es etwas werden, so ist es aber mitunter schlechter benutzbar als eine Version komplett ohne CSS.

In welcher 4er-Version ist es denn so chaotisch?
Ich habe jetzt aber doch ein Zugeständnis an den Netscape 4 gemacht und u.a. das margin versteckt. In der meiner 4.78 Version sieht es jetzt wirklich brauchbar aus - nutzbar allemale.

Das ist im Prinzip kontraproduktiv, weil die Grafiken bestenfalls Teil des Links sein sollten, also <a><img/> ...</a>.

Wenn sie im Original in den Link mit einbezogen wären, hätte ich vermutlich eine andere Lösung gewählt.
Und kontroproduktiv finde ich das unter dem Aspekt der Barrierefreiheit in diesem Fall nicht. Einem Textbrowser wird der passende Alternativtext der Grafik angezeigt, z.b. 'Kapitel', gefolgt von dem Link. Was sollte daran unverständlich sein?

freundliche Grüße
Ingo

[molily]

Hallo Ingo,

In welcher 4er-Version ist es denn so chaotisch?

4.80.

Ich habe jetzt aber doch ein Zugeständnis an den Netscape 4 gemacht und u.a. das margin versteckt. In der meiner 4.78 Version sieht es jetzt wirklich brauchbar aus - nutzbar allemale.

Ja, wie man eben »brauchbar« und »nutzbar« definiert. Die m.E. schlechte Raumaufteilung hat sich nicht geändert.

Das ist im Prinzip kontraproduktiv, weil die Grafiken bestenfalls Teil des Links sein sollten, also <a><img/> ...</a>.

Wenn sie im Original in den Link mit einbezogen wären, hätte ich vermutlich eine andere Lösung gewählt.

»Man darf« sich auch über das Original hinaus Gedanken über sinnvolle Gestaltung auf den verschiedenen Ebenen machen. Sprich, die Eigenheiten des jetzigen Self-Layouts können m.E. durchaus konstruktiv in Frage gestellt werden.

Und kontroproduktiv finde ich das unter dem Aspekt der Barrierefreiheit in diesem Fall nicht. Einem Textbrowser wird der passende Alternativtext der Grafik angezeigt, z.b. 'Kapitel', gefolgt von dem Link. Was sollte daran unverständlich sein?

Daran ist problematisch, dass die Typisierung - in Selfhtml gibt es ja dutzende Linktypen - nicht explizit als zum Link zugehörig gekennzeichnet ist, sondern in dessen Kontext steht. Sie ist aber, insbesondere in solchen Linklisten, Teil eines Links, da sie das Linkziel direkt bestimmt. Das ist ein durchgängiges, vereinheitliches Schema in Selfhtml. Hinzu kommt, dass der jeweilige Typname nicht wirklich in den Kontext davor eingebettet ist, sondern in der Regel nur eine Verbindung zum nachfolgenden Link besteht, man denke an Fließttext und Links innerhalb eines Satzes (»Bitte schauen Sie bezüglich Blabla im Abschnitt nach unten 'Link Blablabla', wo auch Blablub erklärt wird.« mit <img alt="nach unten"> <a>Blablabla</a>). Da das Eingefügte vor dem Link eventuell deplatziert wirkt, muss die Verbindung zum nachfolgenden Link im Kopf des Lesers entstehen, zum Beispiel beim Vorlesen ist das entsprechend herausfordernd und eine Quelle der Unverständnis.
Eine Grundanforderung bzw. ein wichtiger Grundzusammenhang der Zugänglichkeit ist nun, dass die Linktitel so angelegt sind, dass möglichst ihr voller Sinn erhalten bleibt, wenn sie dem Kontext entnommen werden. Das ist vor allem dann relevant, wenn die Links einzeln durchgeschaltet, aufgelistet bzw. anderweitig ausgewertet werden. Die Zugänglichkeitsrichtlinie 13.1 beschäftigt sich im Speziellen mit diesem Sachverhalt.

Mathias

[Ingo Turski]

Hi Mathias,

»Man darf« sich auch über das Original hinaus Gedanken über sinnvolle Gestaltung auf den verschiedenen Ebenen machen. Sprich, die Eigenheiten des jetzigen Self-Layouts können m.E. durchaus konstruktiv in Frage gestellt werden.

aber sicher doch. Und ich denke, daß hierzu auch gute Argumente gekommen sind.
Nur um noch einmal auf meinen Entwurf zurück zu kommen, selbst auf die Gefahr, mich zu stellenweise wiederholen:
Es ging mir darum, ein auf den ersten Blick typisches Tabellenlayout mit einem linken Layoutteil und einem in zwei Spalten aufgeteiltem Inhaltsbereich mit den Mitteln von CSS so umzusetzen, daß das Originalbild erhalten bleibt und dies ohne Hacks auch möglichst in alten Browsern - um eben die Möglichkeiten von CSS zu testen und bei dem gleichen Layout zu demonstrieren, daß dies mit CSS eben _doch_ ohne große 'Verrenkungen' umzusetzen ist.
Darüber hinaus ist diese eine Seite bei genauerem Hinsehen eben doch keine Seite, die - logisch betrachtet - den Einsatz eine Tabelle rechtfertigt. Denn die Spalte mit den Kapiteln muß nicht links neben der Spalte mit den Seiten angeordnet werden und die einzelnen Zeilen stehen auch ohnehin nicht zueinander in Beziehung.
Bei zu wenig Anzeigeplatz macht es dann keinen Sinn, diese Struktur beizubehalten und horiziontal scrollen zu müssen. Und genau hier liegt ein großer Vorteil von CSS gegenüber Tabellen, den ich mit diesem Beispiel aufzeigen wollte.

Daß Konstruktionen wie

<img alt="nach unten"> <a>Blablabla</a>

nicht gut sind, wird glaube ich keiner bestreiten. Nur sollte wohl auch keiner annehmen, daß mit der Umsetzung dieser einen Seite gleichzeitig das Ziel verfolgt wurde, ein Konzept für die gesamten Inhalt von SelfHTML zu päsentieren.

Freundliche Grüße
Ingo Turski

[Cyx23]

Hallo Ingo,

... mit den Mitteln von CSS so umzusetzen, daß das Originalbild erhalten bleibt und dies ohne Hacks auch möglichst in alten Browsern - um eben die Möglichkeiten von CSS zu testen und bei dem gleichen Layout zu demonstrieren, daß dies mit CSS eben _doch_ ohne große 'Verrenkungen' umzusetzen ist.

du übersiehst, dass der Aufwand und die möglicherweise entstehende Sensibilität und Unflexibilität des CSS auch "große 'Verrenkungen'" bedeuten können.

Du würdest ja notfalls auch Einschränkungen hinsichtlich der Verwendung von Listen akzeptieren (auch wenn sich da Lösungen ergeben sollten Listen doch einzusetzen), damit wärst du schon zu einigen Klimmzügen bereit.

... Nur sollte wohl auch keiner annehmen, daß mit der Umsetzung dieser einen Seite gleichzeitig das Ziel verfolgt wurde, ein Konzept für die gesamten Inhalt von SelfHTML zu päsentieren.

Ich hatte es allerdings so verstanden daß da eine solches Ziel zumindest partiell hinterstehen würde.

Grüsse

Cyx23

[Jan H.]

Hallo Cyx23,

du übersiehst, dass der Aufwand und die möglicherweise entstehende Sensibilität und Unflexibilität des CSS auch "große 'Verrenkungen'" bedeuten können.

Daher fand ich die idee, dass viele, einige leute das self-layout mit css mitteln nachbauen, so interesant. Um zu sehen wie man sich selbst verenkt und andere mit simpelsten formaten das selbe auf die beine stellen.
Ich habe zb gemerkt, dass ich bei der herangehensweise immer die selben gedankenabläufe habe, ich denke in zusammenfassenden boxen, float, margin und padding. Man kann fast sagen, genauso festgefahren wie "tabellenlayouter", wie schachtel ich welche tabelle und wo, wie kommen die zerschnippelten bilder rein.

Du würdest ja notfalls auch Einschränkungen hinsichtlich der Verwendung von Listen akzeptieren (auch wenn sich da Lösungen ergeben sollten Listen doch einzusetzen), damit wärst du schon zu einigen Klimmzügen bereit.

Auch daher die idee, zu sehen wie es andere praktisch machen (leider zeigen das andere (noch) nicht)

... Nur sollte wohl auch keiner annehmen, daß mit der Umsetzung dieser einen Seite gleichzeitig das Ziel verfolgt wurde, ein Konzept für die gesamten Inhalt von SelfHTML zu päsentieren.

Ich hatte es allerdings so verstanden daß da eine solches Ziel zumindest partiell hinterstehen würde.

Eigentlich kann ich mir es gar nicht recht vorstellen, ein mammutwerk wie selfhtml völlig umzukrempeln, ein arbeitsaufwand ohne ende mag man meinen.

Naja, ich sah es in erster linie als einen kleinen feldversuch an ein und der selben seite.

Gruss, Jan aus Dresden

[Cyx23]

Hallo Jan,

Auch daher die idee, zu sehen wie es andere praktisch machen (leider zeigen das andere (noch) nicht)

nun, meine Ansätze und Prioritäten sind ja teilweise mit konkreten Beispielen deutlich geworden.

Netscape 4 als später lösbares Problem auffassen, mit der Option einer validen CSS-Weiche o.ä.
Dann HTML reduzieren, und Listen wo immer sinnvoll, was natürlich heikel ist da m.E. alle Browser bei Listen buggy und/oder unterschiedlich reagieren.

Eine Lösung für Listen beim NC4 mit liststyle:none und margin usw. ist ja auch am Beispiel belegt; heikel auch der doctype da ja die IE5, 5.5 6 häufig genutzt werden.

HTML 4 strict würde zumindest die Operas einheitlicher behandeln, ansonsten würde ich den doctype erstmal offenlassen wie auch die Frage ob NC4 ohne Resizebug bedient werden muss.

Naja, ich sah es in erster linie als einen kleinen feldversuch an ein und der selben seite.

Hat allerdings was, aber da würde ich eigentlich erstmal ein allgemeineres Beispiel auch risikofreudiger durchspielen, natürlich mit der Aussicht mich bei einer Weiterentwicklung mit komplexeren Wechselwirkungen auseinanderzusetzen, so die atypische Vererbung von Schriftgrössen bei Opera und Listen.

Grüsse

Cyx23

[Ingo Turski]

Hi,

heikel auch der doctype da ja die IE5, 5.5 6 häufig genutzt werden.

HTML 4 strict würde zumindest die Operas einheitlicher behandeln, ansonsten würde ich den doctype erstmal offenlassen wie auch die Frage ob NC4 ohne Resizebug bedient werden muss.

warum bei neu zu konzipierenden Seiten, die zudem den aktuellen Stand der Technik repräsentieren sollen, altes Markup verwenden? Ich denke, XHTML 1.0 Strict ist da z.Z. die sinnvollste Wahl. Denn in einem umfangreichen Projekt kannst Du das CSS leicht anpassen, aber wolltest Du Dir allen Ernstes später die Mühe machen, sämtliche Seiten von HTML nach XHTML zu konvertieren?
Und entsprechend flexible Seiten sollten auch Abweichungen z.B. durch das IE Box-Modell verkraften.

freundliche Grüße
Ingo

[Cyx23]

Hallo Ingo,

heikel auch der doctype da ja die IE5, 5.5 6 häufig genutzt werden.

HTML 4 strict würde zumindest die Operas einheitlicher behandeln, ansonsten würde ich den doctype erstmal offenlassen wie auch die Frage ob NC4 ohne Resizebug bedient werden muss.

warum bei neu zu konzipierenden Seiten, die zudem den aktuellen Stand der Technik repräsentieren sollen, altes Markup verwenden?

ich bezweifele erstmal dass XHTML aktueller Stand der Technik ist, zumal für HTML-Seiten, da würde ich eher bei HTML Strict als Ziel für eine Zeit nach IE5 und 5.5 landen.

Ansonsten hat der doctype eh kaum Einfluss auf den Inhalt solange modernes HTML verwandt wird, sondern er schaltet das Browserverhalten, und transitional-kompatibles Browserverhalten ist sogar beim Opera mit Version 7 eingeführt.

... sämtliche Seiten von HTML nach XHTML zu konvertieren?

Also dafür gibts ja Software. Abgesehen davon warum sollte jemand überhaupt HTML nach XHTML konvertieren müssen?

Und entsprechend flexible Seiten sollten auch Abweichungen z.B. durch das IE Box-Modell verkraften.

Ein Teil der geeigneten Lösungen beruht auf fragwürdigen CSS-Hacks, die etwa für IE50 nicht funktionieren usw., oder auf zusätzlichen Container-divs, oder für die IE5 und 5.5 auf immerhin verlässlicheren cond. comments, die aber zumindest im head des HTML-code auftauchen müssen.

Was ausser Opera 6 spricht denn nun für HTML strict, und was für XHTML ausser einer Jahreszahl auf dem Standard?

Im Gegenteil scheint es doch so zu sein dass ich bei transitional das richtigere HTML realisieren kann, z.B. ohne Hilfscontainer.

Grüsse

Cyx23

[Ingo Turski]

Hi,

ich bezweifele erstmal dass XHTML aktueller Stand der Technik ist, zumal für HTML-Seiten, da würde ich eher bei HTML Strict als Ziel für eine Zeit nach IE5 und 5.5 landen.

warum? Damit kommen IMO alle gängigen Browser klar; und ich finde die Auszeichnung einfach konsequenter (z.B. mit den erforderlichen EndTags.

Ansonsten hat der doctype eh kaum Einfluss auf den Inhalt solange modernes HTML verwandt wird, sondern er schaltet das Browserverhalten, und transitional-kompatibles Browserverhalten ist sogar beim Opera mit Version 7 eingeführt.

Aber sicher gibt es - wenn auch nicht große - Unterschiede wie z.B. EndTags bei leeren Elementen und natürlich die - zwangsweise - Beschränkung auf die in XHML zulässigen Angaben.

... sämtliche Seiten von HTML nach XHTML zu konvertieren?

Also dafür gibts ja Software. Abgesehen davon warum sollte jemand überhaupt HTML nach XHTML konvertieren müssen?

Ich gehe davon aus, daß in vielleicht noch nicht ganz absehbarer Zeit HTML den Stellenwert wie heute z.B. <font> bekommt. Und warum den Konvertierungsaufwand bereits bei Beginn einkalkulieren?

Und entsprechend flexible Seiten sollten auch Abweichungen z.B. durch das IE Box-Modell verkraften.

Ein Teil der geeigneten Lösungen beruht auf fragwürdigen CSS-Hacks, die etwa für IE50 nicht funktionieren usw., oder auf zusätzlichen Container-divs, oder für die IE5 und 5.5 auf immerhin verlässlicheren cond. comments, die aber zumindest im head des HTML-code auftauchen müssen.

Ich gehe ja auch von _flexiblen_ Seiten aus, die eben nicht pixelgenau dargestellt werden müssen und solche Hacks tatsächlich überflüssig machen.

Was ausser Opera 6 spricht denn nun für HTML strict, und was für XHTML ausser einer Jahreszahl auf dem Standard?

Im Gegenteil scheint es doch so zu sein dass ich bei transitional das richtigere HTML realisieren kann, z.B. ohne Hilfscontainer.

Der Standard alleine ist für mich schon Grund genug. Und wie schon gesagt kommt man bei geschickter Auszeichnung auch ohne Hilfscontainer aus.

freundliche Grüße
Ingo

[Cyx23]

Hallo,

Der Standard alleine ist für mich schon Grund genug. Und wie schon gesagt kommt man bei geschickter Auszeichnung auch ohne Hilfscontainer aus.

welcher Standard? HTML transitional ist Standard, HTML strict ist Standard.

End-Tags lassen ohne Aufwand automatisch umstellen wenn es soweit sein sollte, da aber ein Browser auch in einigen Jahren HTML verstehen wird....
Und welche so "_flexiblen_ Seiten" ohne Hilfscontainer, ohne Boxbug..

Jedenfalls bei HTML 401 strict werden die Unterschiede und Bugs gerade von Opera 7, IE 6 und Mozilla auch erstmal grösser, das ganze Abwägen welcher Browser bei html 100% haben muss, welcher darf usw. usw. und wann nun Opera bei float mehr Trickserei benötigt als der NC4 ist doch letztendlich schlimmer und riskanter als die von dir bemägelten "Hacks".

Aber -muss es nochnmal testen ob oder ob nicht- womöglich geht es eher um den Umstand dass bestimmte Browser bei XHMTL wieder auf transitional Quirks schalten, und XHTML als Etikette schaut halt einfach netter aus als ein reelles transitional?

Grüsse

Cyx23

[Cyx23]

Hallo nochmal,

Aber -muss es nochnmal testen ob oder ob nicht- womöglich geht es eher um den Umstand dass bestimmte Browser bei XHMTL wieder auf transitional Quirks schalten,

da wird offenbar doch xhtml und html 401 strict gleich behandelt (Konqueror habe ich jetzt allerdings nicht geschaut), offenbar war meine Befürchtung unbegründet, dann wäre eine Formatänderung von html strict unbedenklicher.

Aber html strict wäre damit potentiell auch ähnlich zukunftsicher, ganz abgesehen von der Möglichkeit "Quirks" bzw. transitional bei einem html-strict 401 geeignetem HTML-Code zu verwenden (nicht als pauschale Empfehlung, aber m.E. durchaus als zeitgemässe Methode).

Grüsse

Cyx23

[molily]

Hallo Cyx,

Aber -muss es nochnmal testen ob oder ob nicht- womöglich geht es eher um den Umstand dass bestimmte Browser bei XHMTL wieder auf transitional Quirks schalten,

da wird offenbar doch xhtml und html 401 strict gleich behandelt (Konqueror habe ich jetzt allerdings nicht geschaut), offenbar war meine Befürchtung unbegründet, dann wäre eine Formatänderung von html strict unbedenklicher.

Aber html strict wäre damit potentiell auch ähnlich zukunftsicher, ganz abgesehen von der Möglichkeit "Quirks" bzw. transitional bei einem html-strict 401 geeignetem HTML-Code zu verwenden (nicht als pauschale Empfehlung, aber m.E. durchaus als zeitgemässe Methode).

Ich verstehe den Satz nicht ganz, vielleicht wiederhole ich, was du bereits sagen wolltest, wie auch immer, eine kleine Anmerkung:
Ich verstehe nicht, warum sich die Debatte um den Rendermodus so sehr um das Markup selbst dreht. Ob nun HTML oder XHTML und Strict oder Transitional, ist doch letztlich nicht ausschlaggebend. Der Quirks-Mode kann auch selbst dann ausgelöst werden, wenn die Dokumenttyp-Deklaration selbst den Konformitätsmodus auslösen würde. So könnte man in XHTML, ob nun Strict oder Transitional, eine XML-Deklaration einfügen, welche sich sowieso anbietet. Bei HTML 4 Strict bzw. Transitional mit voller DTD-Angabe könnte man einen Kommentar vor die Dokumenttyp-Deklaration stellen. Beides löst jeweils unabhängig vom Dokumenttyp den Quirks-Mode aus. (box-sizing gäbe es zur Not auch noch.)

Insofern ändert sich zwischen HTML 4.x Transitional ohne System-Identifier, mit System-Identifier, 4.x Strict, XHTML 1.0 Strict und Transitional im Hinblick auf den Rendermodus nichts zwangsläufig, Geckos natürlich ausgenommen, aber der benutzt (von -moz-box-sizing mal abgesehen) in allen Modi sowieso dasselbe Rendermodell.

Mathias

[Cyx23]

Hallo Mathias,

Ich verstehe nicht, warum sich die Debatte um den Rendermodus so sehr um das Markup selbst dreht. Ob nun HTML oder XHTML und Strict oder Transitional, ist doch letztlich nicht ausschlaggebend. Der Quirks-Mode kann auch selbst dann ausgelöst werden, wenn die Dokumenttyp-Deklaration selbst den Konformitätsmodus auslösen würde. So könnte man in XHTML, ob nun Strict oder Transitional, eine XML-Deklaration einfügen, welche sich sowieso anbietet. Bei HTML 4 Strict bzw. Transitional mit voller DTD-Angabe könnte man einen Kommentar vor die Dokumenttyp-Deklaration stellen. Beides löst jeweils unabhängig vom Dokumenttyp den Quirks-Mode aus. (box-sizing gäbe es zur Not auch noch.)

die Methoden per dtd den Rendermodus umzuschalten hatte ich in dem Zusammenhang noch gar nicht vergegenwärtigt, da lässt sich XHTML allerdings vielseitiger einsetzen.

Auch wenn mich nun angesichts der von dir verdeutlichten flexibleren Voraussetzung weniger hindert XHTML zu verwenden, sehe ich eigentlich immer noch keine Vorteile oder bessere "Haltbarkeit" von XHTML gegenüber HTML, zumal ich annehme dass ein nach strengeren Kriterien geschriebenes HTML sich schnell konvertieren liesse (Und einige ärgerliche Merkwürdigkeiten bei float und Mozilla scheinen sowieso nicht nur vom doctype abzuhängen).

Grüsse

Cyx23

[Ingo Turski]

Hi,

zumal ich annehme dass ein nach strengeren Kriterien geschriebenes HTML sich schnell konvertieren liesse

unabhängig davon, daß ich weiter oben unter "Standard" einen "aktuellen Standard (der heute weitgehend unterstützt wird)" meinte, spricht nach wie vor einfach der Umstand, daß eine spätere Konvertierung - wie einfach sie auch sein mag - vermieden wird für XHTML.
Außerdem: wer sagt denn, daß eine HTML-Seite tatsächlich nach den strengen Kriterien von XHTML geschrieben ist? Der Validator würde Dich erst nach einer Doctype-Änderung und Konvertierung darauf aufmerksam machen, wenn etwas nicht XHTML-konform ist.

Und ehrlich gesagt verstehe ich die Doctype-Diskussion nicht. Selbst der Netscape 4 macht bei XHTML-Seiten keine (anderen) Probleme. Und für den IE setze ich normalerweise sehr gerne den XML-Prolog ein, um einfach unterschiedliche Auslegungen der 6er-Version ggü. den Vorgängern (die ich bei mir ohnehin nicht testen kann) gering zu halten.

freundliche Grüße
Ingo

[Cyx23]

Hallo Ingo,

Und für den IE setze ich normalerweise sehr gerne den XML-Prolog ein, um einfach unterschiedliche Auslegungen der 6er-Version ggü. den Vorgängern (die ich bei mir ohnehin nicht testen kann) gering zu halten.

gerade das hatte ich ja vorher gemeint, allerdings ohne genau die verschiedenen Varianten im Blick gehabt zu haben.

Für moderneres XHTML plädieren, und in dem Fall IE 6 auf Quirk und Opera 7 etc. auf Standard zu stellen sind ja zwei Aspekte, wobei momentan besonders die Einflüsse auf den layout mode interessant sein dürften.

Ansonsten ist derzeit HTML drinnen auch wenn es mit nem X daherkommt, und da ist HTML zunächst das richtigere und auch zumindest theoretisch browsersicherere Format. Wenn natürlich wirklich alle clients damit klar kommen, mag das letztendlich egal sein. Dann bliebe tatsächlich noch die höhere Zukunftssicherheit, die aber m.E. kaum in Anspruch genommen werden dürfte.

Grüsse

Cyx23

[Ingo Turski]

Hi,

Wenn natürlich wirklich alle clients damit klar kommen, mag das letztendlich egal sein. Dann bliebe tatsächlich noch die höhere Zukunftssicherheit, die aber m.E. kaum in Anspruch genommen werden dürfte.

Das stimmt zwar, aber da noch die Beispiel-Funktion von SelfHTML hinzu kommt (denke nur an die ganzen "javascript:..." in event-handlern), ist es ein Grund mehr, Xhtml einzusetzen.

freundliche Grüße
Ingo

[Ingo Turski]

Hi,

du übersiehst, dass der Aufwand und die möglicherweise entstehende Sensibilität und Unflexibilität des CSS auch "große 'Verrenkungen'" bedeuten können.

mache ich das wirklich? Bei dieser einen Seite jedenfalls ging es ohne Verrenkungen und sehr flexibel.

Du würdest ja notfalls auch Einschränkungen hinsichtlich der Verwendung von Listen akzeptieren (auch wenn sich da Lösungen ergeben sollten Listen doch einzusetzen), damit wärst du schon zu einigen Klimmzügen bereit.

Nunja ... zugegeben: die erste Idee, eine Liste zu verwenden, hatte ich wegen dem Netscape 4 verworfen; allerdings erst nach Abwägung, ob <p> auch angemessen sein könnte. Von daher hast Du mit dem 'Klimmzug' schon recht.

Ich hatte es allerdings so verstanden daß da eine solches Ziel zumindest partiell hinterstehen würde.

Bei mir wirklich nicht. Dieser Thread hat sich ja auch erst hinterher in diese Richtung entwickelt. Mir ging es hier tatsächlich nur um ein Beispiel zur Tabellen vs. CSS Diskussion - und um das Experiment, einmal ausschließlich Angaben in em zu machen.

freundliche Grüße
Ingo

[Thomas J.S.]

Hallo, »»

In welcher 4er-Version ist es denn so chaotisch?

http://www.meta-text.net/etc/selflayout_ns478.gif

Es geht mir nicht, darum, dass deine Arbeit schelcht sei! Sie ist in den anderen Browser sehr gut, aber eben in NS wirkt die Seite ziemlich schlecht.

Ich habe jetzt aber doch ein Zugeständnis an den Netscape 4 gemacht und u.a. das margin versteckt. In der meiner 4.78 Version sieht es jetzt wirklich brauchbar aus - nutzbar allemale.

Das ist Ansichtssache. ;-)

Grüße
Thomas

PS: kleiner Tipp am Rande: mache für den NS 4.x sowas:
div {border:0.1px; }

[Ingo Turski]

Hi,

Ich habe jetzt aber doch ein Zugeständnis an den Netscape 4 gemacht und u.a. das margin versteckt. In der meiner 4.78 Version sieht es jetzt wirklich brauchbar aus - nutzbar allemale.

Das ist Ansichtssache. ;-)

Genau. Dein Screenshot entspricht genau der Ansicht meines 4.78 und die finde ich zumutbar und auch besser, als eine reine Textversion. Was mich hier mehr als das fehlende Hintergrund-Grau stört sind die Zeilenumbrüche nach den Icons. Hast Du dazu eine Idee?

PS: kleiner Tipp am Rande: mache für den NS 4.x sowas:
div {border:0.1px; }

Gerade mal probiert - das würde funktionieren. Aber wie würde sich das auf andere Browser auswirken?

freundliche Grüße
Ingo

[Cyx23]

Hallo,

Gerade mal probiert - das würde funktionieren. Aber wie würde sich das auf andere Browser auswirken?

sorry aber was soll das alles mit dem Netscape 4? Vergesst Netscape 4 doch erstmal und erinnert euch etwas später wieder an ihn!

Erstmal richtiges und reduziertes HTML, die nervenden IE 5, 5.5 ordentlich bedienen, Konqu und Opera etc.

Dann würde ich noch überlegen ob die Verschachtelung, div usw. stimmen. Oder ob der erste p.header in den div rein soll usw.

Für Netscape 4 z.B. festlegen ob einige Sonderzeichen besser in Uni-code stehen sollten/könnten.

Wenn das alles steht, kann für Netscape 4 falls es überhaupt nötig ist immer noch minimal am HTML ergänzt werden.
Die Vorstellung Netscape 4 erstmal weniger zu berücksichtigen müsste optimaleren und zukunftstauglicheren HTML-Code bringen.

Um Netscape 4 dann zu bedienen gibt es wirklich genug valide und sichere Möglichkeiten, das Restrisiko dass man es für Nestcape 4 nicht optimal hinkriegt oder beim HTML nachbessern muss würde ich zugunsten der anderen Browser eingehen.

Mit der bereits vorgestellten Browserweiche oder auch mit separatem JSSS, zu diesen Strategien sind ja schon seit längerem detailliertere Information verfügbar (zur Not geht auch eine Lösung per JavaScript oder einfachere CSS-Weichen) kann Netscape 4 sauber seine eigenen oder seine ergänzenden Styleangaben erhalten, das darf aber doch gegen Ende geschehen wenn der HTML-Code halbwegs steht.

Grüsse

Cyx23

[Thomas J.S.]

Hallo

Genau. Dein Screenshot entspricht genau der Ansicht meines 4.78 und die finde ich zumutbar und auch besser, als eine reine Textversion.

Ich wäre da mit eine reine Textcersion d.h. ganz ohne CSS eher zufiden als mit dies Variante.

»»Was mich hier mehr als das fehlende Hintergrund-Grau stört sind die Zeilenumbrüche nach den Icons. Hast Du dazu eine Idee?

align="left" aber mit der strict.dtd geht das nicht.

PS: kleiner Tipp am Rande: mache für den NS 4.x sowas:
div {border:0.1px; }

Gerade mal probiert - das würde funktionieren. Aber wie würde sich das auf andere Browser auswirken?

Gar nicht. Ich habe zumindest bei IE6, Opera 7, Mozilla 1.4, Firebird 0.7 keine Auswirkungen gesehen.

Grüße
Thomas

[Thomas J.S.]

Nachtrag,

Ich wäre da mit eine reine Textcersion d.h. ganz ohne CSS eher zufiden als mit dies Variante.

»»Was mich hier mehr als das fehlende Hintergrund-Grau stört sind die Zeilenumbrüche nach den Icons. Hast Du dazu eine Idee?

http://www.meta-text.net/test/layoutmusterseite2.html

Grüße
Thomas

[Jan H.]

Hallo Thomas,

»»Was mich hier mehr als das fehlende Hintergrund-Grau stört sind die Zeilenumbrüche nach den Icons. Hast Du dazu eine Idee?

align="left" aber mit der strict.dtd geht das nicht.

Es liegt an den formaten:

#spalte1 img {
  width:15px;
  height:13px;
}
#spalte2 img {
  width:15px;
  height:10px;
}

diese sollten vor NN4 verborgen werden.

PS: kleiner Tipp am Rande: mache für den NS 4.x sowas:
div {border:0.1px; }

Gerade mal probiert - das würde funktionieren. Aber wie würde sich das auf andere Browser auswirken?

Gar nicht. Ich habe zumindest bei IE6, Opera 7, Mozilla 1.4, Firebird 0.7 keine Auswirkungen gesehen.

Ich neheme an, es geht um die hintergrundfarben?
Ich habe eigentlich mit: border:none; gute erfahrungen gemacht.
In meinem beispiel habe ich es so gemacht:
http://fractatulum.net/kram/templates/self-layout/

Allerdings über zwei css dateien da ich um eine anpassung der margins und paddings eh nicht herum kommen würde.

Gruss, Jan aus Dresden

[Thomas J.S.]

Hallo Jan,

Gar nicht. Ich habe zumindest bei IE6, Opera 7, Mozilla 1.4, Firebird 0.7 keine Auswirkungen gesehen.

Ich neheme an, es geht um die hintergrundfarben?
Ich habe eigentlich mit: border:none; gute erfahrungen gemacht.

Es hängen da mehrere Sachen zusammen.
In meinem verlinkten Bsp. half border:none; nichts, obwohl das normalweise bei NS4.x einiges löst. also musste ich border:0.1px; angeben.
Bzw. bei border:none; machte der NS einen noch größeren Abstand zwischen den Divs. Würde ich eine koplette Borderangabe eintragen, wäre der Abstand zwar weg, aber dafür gebe es sihtbare Rahmen.

Grüße
Thomas

[Cyx23]

Hallo Thomas,

Würde ich eine koplette Borderangabe eintragen, wäre der Abstand zwar weg, aber dafür gebe es sihtbare Rahmen.

eine komplette Borderangabe wäre so allerdings auch möglich:

border : 0.1px none inherit;
bzw.:
border: .1px solid transparent;

Grüsse

Cyx23

[Christian Seiler]

Hallo Ingo,

http://www.1ngo.de/web/selfhtml.html

Zitat aus Quellcode:

| font-size:0.83em;

Weißt Du, dass das bei mit gerade mal 11 Pixel groß ist? Das ist *definitiv* zu klein. Ich habe bei mir als Standardschriftgröße 13 Pixel eingestellt, weil ich diese Schriftgröße noch sehr gut lesen kann und ästhetisch finde. Dein 0.83em bewirkt dann, dass das ganze so klein wird bei mir. ~0.8em sind OK, wenn es sich um einen "herunvorgehobenen" Text handelt, also Bsp. ein Copyright-Vermerk. Aber für Fließtext ist das mir viel zu klein.

Wenn schon em, dann bitte Konsequent 1em für die Schriftgröße, denn 1em ist genau die Schriftgröße, die der *Besucher* im Normalfall haben will. Und bitte keine Argumentationen wie die meisten Leute wissen nicht, wo man das einstellen kann und das ganze ist dann für viele zu groß oder sowas; wenn man so argumentiert, sollte man lieber gleich px nehmen. Das schadet weniger als 0.8em.

Viele Grüße,
Christian

[molily]

Hallo,

Wenn schon em, dann bitte Konsequent 1em für die Schriftgröße, denn 1em ist genau die Schriftgröße, die der *Besucher* im Normalfall haben will.

Dieser »Normalfall« ist ausgedacht. Siehe Archiv.

Mathias

[Christian Seiler]

Hallo Mathias,

Wenn schon em, dann bitte Konsequent 1em für die Schriftgröße, denn 1em ist genau die Schriftgröße, die der *Besucher* im Normalfall haben will.

Dieser »Normalfall« ist ausgedacht.

Was genau meinst Du damit? (ausgedacht?)

Siehe Archiv.

Ich kenne die meisten Diskussionen zum Thema em, px, etc.

Viele Grüße,
Christian

[Tim Tepaße]

Hallo Christian,

Was genau meinst Du damit? (ausgedacht?)

Daß die Zahl der Nutzer, die tatsächlich eine bevorzugte Schriftgröße in
ihrem Browser eingestellt haben gleich Epsilon ist, würde ich sagen. ;)

Tim

[Christian Seiler]

Hallo Tim,

Daß die Zahl der Nutzer, die tatsächlich eine bevorzugte Schriftgröße in
ihrem Browser eingestellt haben gleich Epsilon ist, würde ich sagen. ;)

Du willst mir doch wohl nicht unterstellen, dass ich Teil einer Menge bin, deren Anzahl durch zwei dividiert, negativ ist? ;-)

Viele Grüße,
Christian

[molily]

Hallo,

Wenn schon em, dann bitte Konsequent 1em für die Schriftgröße, denn 1em ist genau die Schriftgröße, die der *Besucher* im Normalfall haben will.

Dieser »Normalfall« ist ausgedacht.

Was genau meinst Du damit? (ausgedacht?)

Du redest vom Idealfall, nennst es aber Normalfall. Es ist aber nicht normal im Sinne von gängig und bedenkenlos voraussetzbar, dass der Besucher die Schriftgröße in seinem Browser so eingestellt hat und alles dazugehörige kann und weiß, sodass 1em »genau die Schriftgröße ist, die der Besucher haben will«. Das hat nichts mit »dann kann man ja auch gleich für px plädieren« zu tun, im Gegenteil, man kann ohne diese Erkenntnis em gar nicht einsetzen, weil sie gegenüber denjenigen, die nicht die genannten nötigen Kompetenzen besitzen, nicht weniger rücksichtslos ist als px. Daher ist es nötig, andere Normalfälle anzunehmen, nämlich solche, in denen der Benutzer erst dazu ermutigt und angeleitet werden muss.

Siehe Archiv.

Ich kenne die meisten Diskussionen zum Thema em, px, etc.

Kann ich jetzt nicht heraussuchen, die Selfsuche ist deaktiviert oder defekt.

Mathias

[Christian Seiler]

Hallo Mathias,

Daher ist es nötig, andere Normalfälle anzunehmen, nämlich solche, in denen der Benutzer erst dazu ermutigt und angeleitet werden muss.

Woran denkst Du da zum Beispiel?

Viele Grüße,
Christian

[molily]

Hallo, Christian,

Daher ist es nötig, andere Normalfälle anzunehmen, nämlich solche, in denen der Benutzer erst dazu ermutigt und angeleitet werden muss.

Woran denkst Du da zum Beispiel?

Antworten auf die Fragen: Was bedeuten relative Schriftgröße, was bieten sie mir für Vorteile, wie kann ich diese nutzen, konkret, was sind die Möglichkeiten meines Browsers, die Schriftgröße nach meinen Vorstellungen im Allgemeinen und im Speziellen anzupassen, wie wird das praktisch bewerkstelligt, welche weitergehenden Möglichkeiten gibt es (Kurztasten, Benutzerstylesheets, Deaktivierung des Autorenstylesheets, Wahl alternativer Stylesheets, Zoom usw.).
Ich kenne keine Seite, die diese Themen benutzergerecht behandelt. (Jaja, <I>, irgendwann nehme ich es auch in Angriff.) Insbesondere findet man keine Hinweise auf Seiten, die 1em usw. einsetzen, als ob sich niemand obige Fragen stelle und als sei jeder Nutzer ein Profi, was das Personalisierung des Browsers und darüber von Webseitendarstellung sei.

Mathias

[Cyx23]

Hallo,

mein »Normalfall« ist die default-Einstellung.

Daraus ergibt sich für zeitgemässes Layout mit jüngerer Zielgruppe 0.6em.

Meine Wahl einer gutmütigen Schriftgrösse ist denn auch 0.8em bei möglichst 'liquid layout'.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

Meine Wahl einer gutmütigen Schriftgrösse ist denn auch 0.8em bei möglichst 'liquid layout'.

Was zur absurden Situation führt, dass ich mir im Endeffekt eine viel größere Standardschriftgröße einstellen muss, als ich will, da sehr viele Layouts 0.8em verwenden. Durch 0.8em wird die Einheit em IMHO kompromittiert.

Viele Grüße,
Christian

[Cyx23]

Hallo Christian,

Meine Wahl einer gutmütigen Schriftgrösse ist denn auch 0.8em bei möglichst 'liquid layout'.

Was zur absurden Situation führt, dass ich mir im Endeffekt eine viel größere Standardschriftgröße einstellen muss, als ich will, da sehr viele Layouts 0.8em verwenden. Durch 0.8em wird die Einheit em IMHO kompromittiert.

die default-Einstellung der Browser ist der eine Fixpunkt, der andere real für "Webautoren" existierende und zum erstgenannten in Beziehung zu setzende liegt in der empirisch überprüfbaren Spanne von 10 bis 13px.

"1" hingegen existiert nicht, und als Surfer bietet mir mein Browser wenn ich üpberhaupt auf die Idee komme Ctrl+[ und Ctrl+] oder +/ü...

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

Zitat aus Quellcode:

| font-size:0.83em;

Weißt Du, dass das bei mit gerade mal 11 Pixel groß ist? Das ist *definitiv* zu klein. Ich habe bei mir als Standardschriftgröße 13 Pixel eingestellt, weil ich diese Schriftgröße noch sehr gut lesen kann und ästhetisch finde. Dein 0.83em bewirkt dann, dass das ganze so klein wird bei mir. ~0.8em sind OK, wenn es sich um einen "herunvorgehobenen" Text handelt, also Bsp. ein Copyright-Vermerk. Aber für Fließtext ist das mir viel zu klein.

Ich stimme dir vollkommen zu.

em ist eine relative Größeneinheit. Und das Problem ist die Klärung der Frage: "Relativ zu was?"

Das W3C gibt hierüber ja zum Glück Auskunft: http://www.w3.org/TR/CSS2/syndata.html#length-units

em bezieht sich mit einer Ausnahme immer auf die errechnete font-size des Elements, für das es angewendet wird. Die eine Ausnahme ist font-size selbst - da gilt dann die font-size des Elternelements als Bezugsgröße.

Nun gibt es leider nicht beliebig viele Elternelemente - irgendwann ist man mal bei <html> angekommen. Aber welche Größe gilt hier?

Sofern man keine Definition abgibt, gilt die vom Benutzer eingestellte Schriftgröße. Das führt in der Folge dazu, dass "1em" exakt für die vom Benutzer definierte Schriftgröße steht.

Wer das nicht toll findet, dem steht es frei, eine andere Schriftgröße zu definieren. Aber bitte nicht mit "em", sondern mit Pixeln. Das ist auch eine relative Schriftgrößenangabe, die die Auflösung des Wiedergabemediums mit einbezieht. Ein Pixel entspricht einem Sichtwinkel von 0,0227 Grad - dieser Winkel führt bei einem nahen Computerdisplay beispielsweise zu einer realen Pixelabmessung von 0,3 Millimetern Länge, und bei einem Megascreen in 30 Metern Entfernung zu einer Pixelgröße von 12 Millimetern. Wie das Display hinkriegt, diese Pixelgröße anzuzeigen, ist ihm überlassen.

Da das Auge ohnehin nur eine Auflösungsfähigkeit von 0,01 Grad hat, also gerade einmal doppelt soviele Punkte wahrnehmen könnte, ist der Ansatz, für die Pixelgröße einen Winkel zu nehmen, der sich ungefähr in der Größenordnung der menschlichen Augenfähigkeit bewegt, sinnvoll.

Und nun kommt die Realität (in Form eines Browsers) und sagt: Pixel? Kenn ich nicht, will ich nicht, ignorier' ich alles relative dran, ich setze nur Bildpunkte in der Grafikkarte, und fertig. Und das Schema vom W3C wird trotzdem funktionieren, weil es von einer durchschnittlichen Auflösung von 90 dpi auf einem Computerbildschirm ausgeht. Windows hat standardmäßig 96 dpi eingestellt, und auf dem Mac kompensieren Browser die dort eingestellten 72 dpi mittlerweile.

Mit anderen Worten: Selbst wenn der dumme allgemeine Benutzer nichts einstellt, kriegt er mit Pixeln etwas, was vom Konzept her überall gleich groß aussehen sollte und in der Realität zumindest ungefähr diesen Anspruch schon erfüllt.

Als Seitenautor hat man also genau eine Entscheidung zu treffen: _Entweder_ glaubt man, dass alle Benutzer eines Browsers es hingekriegt haben, eine ihnen genehme Schriftgröße einzustellen. Dann ist jegliche Aussage des Designers "1 em ist für mich zu groß, ich brauche 0.8 em" bedeutungslos, denn durch den Verzicht auf die Angabe einer (mehr oder weniger) absoluten Größe hat er dokumentiert, dass er gerade _keinen_ Anspruch auf eine bestimmte Darstellungsgröße erhebt, sondern nur die Relationen der Schriftgrößen untereinander definiert.

_Oder_ man setzt die Schriftgröße fest, von der aus man relativ weitere Größen definiert.

Ich konnte in den Dokumentationen aber keinen Abschnitt finden, der definiert: "If no absolute or pixel dimension is given in the stylesheet, the user agent should render 1 em with the size of 1.2 times the initial value of font-size. This is because web designers like to define 0.8 em for otherwise undefined font sizes, which may be rendered too small for the average user if this special ruleset would not apply."

- Sven Rautenberg

[Cyx23]

Hallo Sven,

Sofern man keine Definition abgibt, gilt die vom Benutzer eingestellte Schriftgröße. Das führt in der Folge dazu, dass "1em" exakt für die vom Benutzer definierte Schriftgröße steht.

1em ist der default-Wert des Browsers, von kaum einem Benutzer "eingestellt", sondern vorgefunden und kaum korrigiert.

Deshalb gab es schon früher vor Pixelzeiten mit <font size...> die üblichen Anpassungen damit Browserdefault irgendwo bei 12-13 px landet.

Bei 0.6 oder 0.8em hauts hin und kann grösser oder kleiner gestellt werden, und damit ist dein "Relationen der Schriftgrößen untereinander definiert" eben auch erfüllt.

Grüsse

Cyx23

[molily]

Hallo,

1em ist der default-Wert des Browsers, von kaum einem Benutzer "eingestellt", sondern vorgefunden und kaum korrigiert.

Deshalb gab es schon früher vor Pixelzeiten mit <font size...> die üblichen Anpassungen damit Browserdefault irgendwo bei 12-13 px landet.

Die Kausalität lässt sich umdrehen und ist genauso wahr. Hatten wir alles schon.

Bei 0.6 oder 0.8em hauts hin und kann grösser oder kleiner gestellt werden, und damit ist dein "Relationen der Schriftgrößen untereinander definiert" eben auch erfüllt.

Bei 13px die Möglichkeit der Verkleinerung hervorzuheben, halte ich für einen ziemlichen Zynismus.
Verkaufst du maximales Skalieren bis 15px (»Sehr groß« bei 0.6em im IE) als barrierefrei?

Mathias

[Cyx23]

Hallo,

Bei 0.6 oder 0.8em hauts hin und kann grösser oder kleiner gestellt werden, und damit ist dein "Relationen der Schriftgrößen untereinander definiert" eben auch erfüllt.

Bei 13px die Möglichkeit der Verkleinerung hervorzuheben, halte ich für einen ziemlichen Zynismus.

13px könnten ja auch schonmal als gross beurteilt werden, 9px oder 10px eher nicht, hervorgehoben aber hast du es gerade.
Da Bilder nicht skalieren, auch nicht die Bedienoberfläche, Location und Statusleiste, ist die Änderung der Bildschirmauflösung neben Einstellungen im OS oder Registry usw. oder speziellen Browserversionen naheliegend wenn z.B. der IE nicht mehr hergibt (s.u.).

Verkaufst du maximales Skalieren bis 15px (»Sehr groß« bei 0.6em im IE) als barrierefrei?

Du meinst wohl IE 4, oder MacIE? Ich komme hier auf 17px in IE 5, IE 5.5, IE 6 bei 0.6em.

Auf satte 24px für die hier im Thread diskutierten 0.8em, und wenn da die Überschriften nicht per px festgenagelt werden zerlegt ein 24px Äquivalent in em sowieso alles, oder erfordert bei flexiblem Layout immer noch besondere Geschicklicheit beim Scrollen.

Grüsse

Cyx23

[Orlando]

Hi Cyx23,

13px könnten ja auch schonmal als gross beurteilt werden, 9px oder 10px eher nicht

warum so zaghaft? Steh' doch zu deiner Meinung.

Da Bilder nicht skalieren, auch nicht die Bedienoberfläche, Location und Statusleiste, ist die Änderung der Bildschirmauflösung neben Einstellungen im OS oder Registry usw. oder speziellen Browserversionen naheliegend wenn z.B. der IE nicht mehr hergibt (s.u.).

Du weißt, wie TFTs skalieren? Ja? Gut, ich will dir etwas vorrechnen.

Stell' dir bitte ein 17"-TFT-Display mit einer Auflösung von 1280x1024 Punkten vor. Dieses Display weist eine ca. 26,8 cm hohe Anzeige auf. Teilt man die Anzahl der verfügbaren Zeilen durch die Höhe eines Zeichens (13 px), ergeben sich gerundet 79 maximal mögliche Zeilen pro Seite. Teile ich jetzt die Höhe (26,6 cm) durch diese 79 Zeilen, ist jede Zeile maximal 3,4 mm hoch. Ist *das* lesbar? Du magst von dieser Rechnerei nichts hören? Auch gut, ich habe nachgemessen. Eine 9-px-Schrift ist auf meinem Monitor _weniger als 1,8 mm_ groß! Der gesunde Abstand zum Monitor beträgt ca. 60 bis 70 cm. Welch ein Verhältnis...

Fazit: 13 Pixel sind oft zu klein, 9 Pixel sind ein Witz.

Grüße,
 Roland

[Cyx23]

Hallo Roland,

warum so zaghaft? Steh' doch zu deiner Meinung.

grüss die anderen Elche.

Fazit: 13 Pixel sind oft zu klein, 9 Pixel sind ein Witz.

4.1 mm ist gerade meine Zeilenhöhe, und das empfinde ich eher als normal. Auf anderen Systemen sind 13px denn auch mal gross.

Deine 13px Zeichenhöhe dürften 64 Zeilen ergeben, das sind 4.2 mm Zeilenhöhe.

Auf meinem o.g. Monitor kann ich 9px, Zeichenhöhe ca 1.8mm, abhängig vom Schrifttyp übrigens noch relativ gut lesen, würde diese 9px aber wirklich nicht als gross beruteilen.

Grüsse

Cyx23

[Orlando]

Hi Cyx23,

warum so zaghaft? Steh' doch zu deiner Meinung.

grüss die anderen Elche.

verkehrte Welt.

Auf meinem o.g. Monitor kann ich 9px, Zeichenhöhe ca 1.8mm, abhängig vom Schrifttyp übrigens noch relativ gut lesen, würde diese 9px aber wirklich nicht als gross beruteilen.

Ich werde deine Meinung jetzt endgültig akzeptieren, obwohl alle mein Verwandten/Bekannten/Freunde anderer Meinung sind.

Grüße,
 Roland

[Cyx23]

Hallo Roland,

verkehrte Welt.

dass 17er TFTs schon ein (wenn auch nicht ganz seltener) kritischer Fall bzgl. der Pixelgrösse sind dürfte dir bereits vor dem Kauf bekannt gewesen sein, schließlich gibt es aus gutem Grund die 18.1 Zöller.

Auch die Tatsache dass ich trotz der bedingten Lesbarkeit keine 9px (auch keine 11 oder 12) empfehle oder verwende dürfte dir aufgefallen sein, aber jetzt willst du mir noch erzählen dass alle deine Verwandten/Bekannten/Freunde vor solchen 17 Zoll-TFTs hocken und trotz Opera Probleme haben 13 -14px zu entziffern?

Grüsse

Cyx23

[Orlando]

Hi Cyx23,

dass 17er TFTs schon ein (wenn auch nicht ganz seltener) kritischer Fall bzgl. der Pixelgrösse sind dürfte dir bereits vor dem Kauf bekannt gewesen sein, schließlich gibt es aus gutem Grund die 18.1 Zöller.

zu Hause habe ich einen 19er, tagsüber sitze ich vor dem beschriebenen 17er.

Auch die Tatsache dass ich trotz der bedingten Lesbarkeit keine 9px (auch keine 11 oder 12) empfehle oder verwende dürfte dir aufgefallen sein,

13 Pixel sind immer noch klein.

aber jetzt willst du mir noch erzählen dass alle deine Verwandten/Bekannten/Freunde vor solchen 17 Zoll-TFTs hocken und trotz Opera Probleme haben 13 -14px zu entziffern?

Wo habe ich das behauptet? Ausnahmslos alle, die ich gefragt habe, empfanden die Entfernung der Schriftgröße aus den Seiten als angenehm, das Ergebnis war für sie besser lesbar.

Grüße,
 Roland

[molily]

Hallo Cyx23,

Bei 0.6 oder 0.8em hauts hin und kann grösser oder kleiner gestellt werden, und damit ist dein "Relationen der Schriftgrößen untereinander definiert" eben auch erfüllt.

Bei 13px die Möglichkeit der Verkleinerung hervorzuheben, halte ich für einen ziemlichen Zynismus.

13px könnten ja auch schonmal als gross beurteilt werden,

Das kann ich nicht nachvollziehen.

9px oder 10px eher nicht, hervorgehoben aber hast du es gerade.

Da Bilder nicht skalieren, auch nicht die Bedienoberfläche, Location und Statusleiste, ist die Änderung der Bildschirmauflösung neben Einstellungen im OS oder Registry usw. oder speziellen Browserversionen naheliegend wenn z.B. der IE nicht mehr hergibt (s.u.).

Schon klar, dass etwa ein hochgradig Sehbehinderter andere Wege wählen würde, aber so wie ich den Sinn von <1em verstanden habe, geht es um die breite Masse der Besucher. (Wenn das nicht zutrifft, könnte man sich den Spaß sparen, wie einige Accessibility-Interessierte barrierefrei=behindertengerecht definieren und px nutzen, weil die spezielle Gruppe der besonders Betroffenen sowieso spezielle Möglichkeiten der Vergrößerung findet.) Somit ist das Ziel, soviel wie möglich zu bieten, ohne den Benutzer zu tiefgreifenden Änderungen im System oder gar zu einem Browserwechsel zu zwingen (da beißt sich die Katze sowieso in den Schwanz, <1em geht ja gerade davon aus, dass der Benutzer dazu nicht fähig ist). Für diese Masse ist Fliegendreck wie 0.6em = 9-10px zunächst einmal ein Schlag ins Gesicht. Wenn die maximale Fließtextgröße gleichzeitig bei für die 15px bzw. 17px - das ist m.E. gehüpft wie gesprungen, ich messe hier im MSIE 6 bei Arial 15px, wie auch immer - liegt, ist die Möglichkeit der Skalierung dermaßen eingeschränkt, dass gerade einmal die ursprüngliche Schriftgröße wiederhergestellt werden kann, dann aber bereits das Ende der Fahnenstange erreicht ist.

Verkaufst du maximales Skalieren bis 15px (»Sehr groß« bei 0.6em im IE) als barrierefrei?

Du meinst wohl IE 4, oder MacIE? Ich komme hier auf 17px in IE 5, IE 5.5, IE 6 bei 0.6em.

Siehe oben.

Auf satte 24px für die hier im Thread diskutierten 0.8em,

Ha, »satt« ist gut. Wenn ich mich zurücklehne und entspannt lesen will, komme ich schon ohne Absicht auf 20-22px bei 1024x768 und einem 19-Zoll-Monitor. Daher glaube ich nicht, dass beispielsweise Senioren in 24px die ultimative Erfüllung finden und damit zufrieden sein werden.

und wenn da die Überschriften nicht per px festgenagelt werden zerlegt ein 24px Äquivalent in em sowieso alles, oder erfordert bei flexiblem Layout immer noch besondere Geschicklicheit beim Scrollen.

Das sehe ich nicht so, bei den üblichen flexiblen Drei-Spalten-Layouts ist es durchaus ab einer entsprechenden Auflösung (800x600 vielleicht noch nicht, je nachdem) möglich, mit einer Vergrößerung zu arbeiten, welche die genannten Schriftgrößen zur Folge hat, ohne dass die Spaltenbreiten verschwindend gering werden und ohne dass horizontales Scrollen nötig ist.

Noch einmal, wenn ein Kunde eine Seite mit 0.6em wünscht, würdest du sie ihm auch als im Wortsinne barriere-frei verkaufen?

Mathias

[Cyx23]

Hallo Mathias,

Auf satte 24px für die hier im Thread diskutierten 0.8em,

Ha, »satt« ist gut. Wenn ich mich zurücklehne und entspannt lesen will, komme ich schon ohne Absicht auf 20-22px bei 1024x768 und einem 19-Zoll-Monitor. Daher glaube ich nicht, dass beispielsweise Senioren in 24px die ultimative Erfüllung finden und damit zufrieden sein werden.

da solltest du mal den Beamer wechseln.

Noch einmal, wenn ein Kunde eine Seite mit 0.6em wünscht, würdest du sie ihm auch als im Wortsinne barriere-frei verkaufen?

Es kann immer zu klein sein da der IE nicht beliebig vergrössert, von daher ist die Frage ab einem bestimmten Punkt unsinnig.
Wenn irgendwelche für Normalsichtige funktionierende Werte mehr als verdoppelt werden sollten, wird eben doch eine Umschaltung oder zweite Version nötig.
Das gleiche gilt m.E. für andere angebliche Massnahmen zur Barrierefreiheit wie vergrösserter Zeilenabstand, welche meist die Lesbarkeit verschlechtern, also gar nicht oder nur in eine extra Version zum Einsatz kommen dürften.

Aber wenn du aus den kundenseitigen .6em irgendeine Gretchenfrage machen möchtest:
Was meinst du mit "im Wortsinne barriere-frei" in Verbindung mit einem Vertrag?
Geht es dir um juristische Fragen, ethische Aspekte, gesunden Menschenverstand?

Grüsse

Cyx23

[molily]

Hallo,

Noch einmal, wenn ein Kunde eine Seite mit 0.6em wünscht, würdest du sie ihm auch als im Wortsinne barriere-frei verkaufen?

Es kann immer zu klein sein da der IE nicht beliebig vergrössert, von daher ist die Frage ab einem bestimmten Punkt unsinnig.

Ich bitte dich, das ist doch kein Argument. Natürlich kann selbst »Sehr groß« bei 1em zu wenig sein, aber das ist nunmal Wohl oder Übel die größtmögliche darüber erreichbare Schrift. Diese stellt hier den Maßstab dar, nicht das Wünschenswerte (die prinzipiell unbegrenzte Möglichkeit der Skalierung). So wollte ich die Frage auch nicht stellen, denn dann wäre sie tatsächlich unsinnig. Deshalb geht es hier nicht um absolute Bewertung hinsichtlich des Wünschenswerten, sondern der Vergleich mit dem faktisch Möglichen - und dieser Vergleich führt zu den besagten Schlüssen.

Wenn irgendwelche für Normalsichtige funktionierende Werte mehr als verdoppelt werden sollten, wird eben doch eine Umschaltung oder zweite Version nötig.

Wie gesagt, es ist eine Frage der Beschaffenheit des Layouts, wie weit nach oben skaliert werden kann. Es gibt kein Naturgesetz oder einen zwangsläufigen unumgehbaren Zusammenhang, der komplexe Layouts dazu verurteilt, ab einer bestimmten Vergrößerung auseinanderzufallen. Da braucht man nicht den Teufel in Form der zwei Versionen an die Wand malen.

Das gleiche gilt m.E. für andere angebliche Massnahmen zur Barrierefreiheit wie vergrösserter Zeilenabstand, welche meist die Lesbarkeit verschlechtern, also gar nicht oder nur in eine extra Version zum Einsatz kommen dürften.

Aber wenn du aus den kundenseitigen .6em irgendeine Gretchenfrage machen möchtest:
Was meinst du mit "im Wortsinne barriere-frei" in Verbindung mit einem Vertrag?

Meine Frage bezog sich darauf, wie du Barrierefreiheit als von zu erbringende Teilleistung der Seitenerstellung im Hinblick auf diese Problematik verstehst und wie du solche Kundenwünsche damit vereinbarst. Mir scheint es nämlich so, als seiest du der Meinung, dass 0.6em und entsprechenden Möglichkeiten der Skalierbarkeit genauso frei von Barrieren ist bzw. dieselbe Qualität der Zugänglichkeit ermöglichen wie 0.8em, 1em und die Endgröße 10 Pixel. Wenn die Anforderung lautet, eine im möglichst hohem Maße benutzbare und zugängliche Seite zu schaffen, hat das überhaupt Wirkung auf diese Entscheidungen oder ist die letztliche Nützlichkeit der Methoden zweitrangig, Hauptsache der gute Wille wird durch die MSIE-Vergrößerbarkeit gezeigt?
Abgesehen von einem Kundenwunsch: Falls du 0.6em und dergleichen auch zudem aktiv empfiehlst bzw. relativ frei als Methode wählst, wäre es auch interessant, in in wie weit das Maß (im Sinne von qualitativer Menge) der Flexibilität, Benutzbarkeit und Barrierefreiheit beurteilt wird.

Geht es dir um juristische Fragen, ethische Aspekte, gesunden Menschenverstand?

Es geht darum, was du deinem Kunden vermittelst, wenn du ein Layout solches Layout umsetzt, also im weitesten Sinne wie du ihn berätst. Eventuell auch, wie die Barrierefreiheit als Feature der Seite letztlich vertraglich abgerenzt bzw. definiert ist und an welche Merkmale es gekoppelt ist und welchen Stellenwert die oben genannten Kriterien einnehmen.

Mathias

[Cyx23]

Hallo Mathias,

Wie gesagt, es ist eine Frage der Beschaffenheit des Layouts, wie weit nach oben skaliert werden kann. Es gibt kein Naturgesetz oder einen zwangsläufigen unumgehbaren Zusammenhang, der komplexe Layouts dazu verurteilt, ab einer bestimmten Vergrößerung auseinanderzufallen. Da braucht man nicht den Teufel in Form der zwei Versionen an die Wand malen.

wenn ein stimmiges Layout beim default des IE für 80% der Benutzer hinsichtlich der Schriftgrösse und Lesbarkeit funktioniert, ist es erstmal 'richtig'. Die 12% Kiddies denen es zu gross geschrieben ist und die 7% Ältere denen es etwas klein erscheint können die Schriftgrösse verstellen wenn sie es denn wissen. Dann ist allerdings beim IE irgendwo Schluss weil der nicht unbegrenzt skaliert.

Es sind also meist zwei Probleme, die maximal mögliche Schrift und die Grösse bei default. Den default möchte ich i.d.R. wirklich nicht so anlegen dass er 92% der Besucher zu gross vorkäme, der soll und muss schon bei den meisten Projekten für über 90% der Besucher angenehm sein. Jetzt ist beim IE aber nach zweimal hochstellen Schluss, es sei denn es wird mit JavaScript unterstützt.

Abgesehen von einem Kundenwunsch: Falls du 0.6em und dergleichen auch zudem aktiv empfiehlst bzw. relativ frei als Methode wählst, [...]

Ich würde derzeit 0.8em bevorzugen, .85 wird meist vom Browser nicht umgesetzt und .9 scheint als default schon etwas viel. Es dürfte aber Projekte geben bei denen allerdings Skalierbarkeit bereits ein Fortschritt wäre im Vergleich zu 10px oder gar 9px.

Um nun auf die Barrierfreiheit zurückzukommen, so wird es allerdings mit den erwähnten zwei Versionen oder einer dynamichen Seitenerstellung möglich zumindest nach der Umschaltung den Ausgangswert und damit zugleich auch den IE-möglichen Endwert der Schriftgrösse zu erhöhen.

Ich versteh aber immer noch nicht ganz worauf du hinauswillst, denn das hängt ja stark vom Einzelfall ab.

Unterstellt auf einer Seite wären aus welchen Gründen auch immer tatsächlich .6em nötig, und weiter angenommen die IE-seitige Skalierbarkeit reichte als Barrierefreiheit nicht aus, dann müsste halt doch ein hinreichend auffindbarer Schalter oder Link zu Alternativen angebracht werden, was sich ja dann klären liesse.

Grüsse

Cyx23

[at]

Hallo.

Das gleiche gilt m.E. für andere angebliche Massnahmen zur Barrierefreiheit wie vergrösserter Zeilenabstand, welche meist die Lesbarkeit verschlechtern, also gar nicht oder nur in eine extra Version zum Einsatz kommen dürften.

Ein in Maßen vergrößerter Zeilenabstand trägt -- unabhängig vom subjektiven _Empfinden_ Einzelner -- zur besseren Lesbarkeit bei, gemessen in Wörtern pro Minute. Im Bereich der Pritmedien wird auf Grund der relativ hohen Kosten der Bedruckstoffe und der Handhabbarkeit des Gesamtproduktes häufig auf diese Erleichterung verzichtet, wozu bei Web-Präsentationen zumindest die genannten Anlässe keinen Anlass gäben.
Auch eine maßvolle Anhebung der Laufweite kann die Lesbarkeit durchaus erhöhen und gelegentlich sogar die eigentlich schlechte Lesbarkeit einer Schriftart vollständig kompensieren. Hierzu müsste man aber natürlich wissen, welche Schriftart der Betrachter verwendet.
MfG, at

[Cyx23]

Hallo,

Das gleiche gilt m.E. für andere angebliche Massnahmen zur Barrierefreiheit wie vergrösserter Zeilenabstand, welche meist die Lesbarkeit verschlechtern, also gar nicht oder nur in eine extra Version zum Einsatz kommen dürften.

Ein in Maßen vergrößerter Zeilenabstand trägt -- unabhängig vom subjektiven _Empfinden_ Einzelner -- zur besseren Lesbarkeit bei, gemessen in Wörtern pro Minute. Im Bereich der Pritmedien wird auf Grund der relativ hohen Kosten der Bedruckstoffe und der Handhabbarkeit des Gesamtproduktes häufig auf diese Erleichterung verzichtet, wozu bei Web-Präsentationen zumindest die genannten Anlässe keinen Anlass gäben.
Auch eine maßvolle Anhebung der Laufweite kann die Lesbarkeit durchaus erhöhen und gelegentlich sogar die eigentlich schlechte Lesbarkeit einer Schriftart vollständig kompensieren. Hierzu müsste man aber natürlich wissen, welche Schriftart der Betrachter verwendet.

klar, es hängt von Schriftart, Bildschirmschärfe usw., oder einer zu grossen Breite/Zeilenlänge des Textes ab. Dennoch, ab 130%, spätestens 140% wird es schlechter, die Lesegeschwindigkeit langsamer.
Ähnlich wird ja die Lesbarkeit mit Serifen u.U. besser, am Bildschirm wegen der fehlenden Schärfe dürfte sich das allerdings nicht so deutlichbemerkbar machen.
Auch die grössere Laufweite reduziert ja den erfassbaren Text und lässt schliesslich das Lesen zur Qual werden, auch hier natürlich das Problem Bildschirmschärfe.
Im Bereich der Pritmedien ist es doch häufig umgekehrt, dort müssen oft Seiten gefüllt, Texte gestreckt werden.

Grüsse

Cyx23

[at]

Hallo.

klar, es hängt von Schriftart, Bildschirmschärfe usw., oder einer zu grossen Breite/Zeilenlänge des Textes ab. Dennoch, ab 130%, spätestens 140% wird es schlechter, die Lesegeschwindigkeit langsamer.

Je länger die Zeile, desto größer darf der Zeilenabstand sein, damit man den Anfang der nächsten Zeile noch leicht finden kann. Und da 100% kompressem Satz entsprechen, in dem Unterlängen und Akzente einander berühren können, was der Lesbarkeit sicher nicht förderlich ist, sind in Abhängigkeit von der Schriftart auch jenseits von 150% noch gute Ergebnisse zu erzielen. Bei vielen auch guten (Headline-)Schriftarten ist unterhalb eines solchen Wertes gar keine vernünftige Lesbarkeit zu erzielen.

Ähnlich wird ja die Lesbarkeit mit Serifen u.U. besser, am Bildschirm wegen der fehlenden Schärfe dürfte sich das allerdings nicht so deutlichbemerkbar machen.

Die Schärfe muss hier nicht ausschlaggebend sein, was man daran sieht, dass die Lesegeschwindigkeit auf LCDs kaum mehr zunimmt, wenn die übrigen Parameter stimmen.

Auch die grössere Laufweite reduziert ja den erfassbaren Text und lässt schliesslich das Lesen zur Qual werden, auch hier natürlich das Problem Bildschirmschärfe.

Ich gehe mit den Erkenntnissen konform, dass nicht die Schärfe, sondern der Kontrast die größten negativen Auswirkungen auf die Schriftdarstellung am Bildschirm hat. Die Bildschärfe wird durch die Laufweite ja auch gar nicht beeinflusst, sondern vielmehr wird das Überstrahlen des meist helleren Hintergrundes gefördert, was dem durch die Erhöhung der Laufweite verbesserten Identifizieren von Einzelformen sicher ab einem gewissen Grad der Laufweite zuwider läuft.

Im Bereich der Pritmedien ist es doch häufig umgekehrt, dort müssen oft Seiten gefüllt, Texte gestreckt werden.

Und noch viel häufiger ist das Gegenteil der Fall, weswegen die Hersteller von Schriften für Bücher und Zeitungen ja schon sehr früh mit guter Lesbarkeit bei geringer Laufweite geworben haben.
MfG, at

[Tim Tepaße]

Hallo Cyx,

Bei 0.6 oder 0.8em hauts hin und kann grösser oder kleiner gestellt werden,
und damit ist dein "Relationen der Schriftgrößen untereinander definiert"
eben auch erfüllt.

Man muß aber auf stark auf die Verschachtelung der Baumstruktur in seinem
Quelltext oder aber auf die CSS-Zuweisungen achten, um der exponentialen
Kurve, die sich durch nicht-1em Werte ergibt.

Tim

[molily]

Hallo Sven,

Sofern man keine Definition abgibt, gilt die vom Benutzer eingestellte Schriftgröße. Das führt in der Folge dazu, dass "1em" exakt für die vom Benutzer definierte Schriftgröße steht.

Wer das nicht toll findet, dem steht es frei, eine andere Schriftgröße zu definieren. Aber bitte nicht mit "em", sondern mit Pixeln. [...]

Mit anderen Worten: Selbst wenn der dumme allgemeine Benutzer nichts einstellt, kriegt er mit Pixeln etwas, was vom Konzept her überall gleich groß aussehen sollte und in der Realität zumindest ungefähr diesen Anspruch schon erfüllt.

Genau das soll auch <1em leisten, indem es den allgemeinen Musterbenutzer mit allgemeinen Default-Schriftgrößen als Maßstab nimmt. Das ist letztlich hinsichtlich Anspruch und Zielsetzung dasselbe wie px.

Als Seitenautor hat man also genau eine Entscheidung zu treffen: _Entweder_ glaubt man, dass alle Benutzer eines Browsers es hingekriegt haben, eine ihnen genehme Schriftgröße einzustellen. [...]

_Oder_ man setzt die Schriftgröße fest, von der aus man relativ weitere Größen definiert.

Für diese Teilung interessiert sich doch niemand wirklich. Selbst Usability-Geläuterte haben mitunter kein Problem davon, Schriftgrößen in dieser Weise festzulegen.
Der Streit um 1em und <1em ist im Prinzip sinnlos, weil es letztlich nichts miteinander zu tun hat, denn die jeweiligen Standpunkte und Sichtweisen auf die Technik der relativen Schriftgrößen sind grundverschieden. Die Position <1em hat sich im Zuge der Verbreitung der Accessibility gebildet (obwohl es dabei um alle Benutzer geht und, wie manche sagen, Sehbehinderte weniger als die Allgemeinheit betroffen sind), als Antwort auf MSIEs Unvermögen, px-Schriften zu skalieren. Sie hat sich als »Mittelweg« bei den tonangebenden Platzhirschen der Szene weitesgehend durchgesetzt. (In wie weit diese Vorgehensweise überhaupt zielführende Methode des Barrierenabbaus ist, lasse ich einmal dahingestellt.) <1em soll ein direkter Ersatz für px sein, anhand der genannten Fixpunkte wird <1em als vermittelnder Faktor angenommen, der letztlich eine bestimmte Pixelgröße erreichen soll. Es geht nicht um eine anpassungsfähige und im Hinblick auf die vorgefundenen Gegebenheiten flexible Größe, es geht um im MSIE (zumindest ein wenig) vergrößerbare Schriften. Verschiedene benutzerseitige Schriftgrößeneinstellungen passen nicht in dieses Konzept, sie unterlaufen es sogar, daher auch die geschilderten Nebeneffekte bei von der angenommenen Mehrheit abweichenden Benutzern. Das sind demzufolge nur die Ausnahmen, die die Regel bestätigen, sie fallen notwendigerweise durch das Fangnetz. Sie können in der genannten Rechnung per se nicht berücksichtigt werden. Derjenige, der seinen Browser auf eine bestimmte individuelle Optimalgröße konfiguriert, verliert bei diesem Konzept zwangsläufig. Insofern ist es aussichtslos, eine vergleichende Verbindung zum 1em-Standpunkt herzustellen, der geht von völlig entgegengesetzten Prämissen aus. Sie schließen sich gegenseitig vollkommen aus. Das sich durchsetzende <1em kann nur Erfolg haben, wenn es keine Diversität gibt, 1em kann nur dann funktionieren.

Nein, ich werde keine Absätze in den obigen Text einfügen, Armin.

Mathias

[Ingo Turski]

Hi Christian,

| font-size:0.83em;

Weißt Du, dass das bei mit gerade mal 11 Pixel groß ist? Das ist *definitiv* zu klein.

Bei mir (in allen installierten Browsern mit Standardeinstellung) sind das 13px.

Ich habe bei mir als Standardschriftgröße 13 Pixel eingestellt, weil ich diese Schriftgröße noch sehr gut lesen kann und ästhetisch finde.

Hättest Du jetzt lieber, daß ich Deine gewünschte Schriftgröße in 13px angebe? Damit dann Andere (im IE) die Schrift nicht mehr sklalieren können? Und 1em sind dann vielen (die es anders als Du bei der Standardeinstellung im Browser belassen haben) dann wieder zu groß. Dir selbst ist 1em doch auch zu groß. Und schließlich kannst Du die Schrift ja beliebig vergrößern.

Dein 0.83em

Sorry, aber dies ist nicht 'mein' 0.83em sondern vielmehr die Umsetzung der Originalvorlage unter Verwendung einer relativen Schriftgröße. Bei der Umsetzung habe ich mir allerdings zumindest eine größere Zeilenhöhe erlaubt, da mir die Links direkt untereinander zu schlecht selektierbar waren. Nur bei der Schriftgröße wollte ich es beim Original belassen.

freundliche Grüße
Ingo

[Christian Seiler]

Hallo Ingo,

Dir selbst ist 1em doch auch zu groß.

Nein. molily hat ziemlich gut den unterschiedlichen Ansatz beschrieben, mit denen wir beide an die Schriftgröße em herangehen, und genau hier äußert sich unsere unterschiedliche Herangehensweise, die er beschrieben hat: Für mich ist 1em nicht zu groß, sondern genau richtig, weil ich 1em immer in Bezug auf den einzlenen Benutzer sehe; für Dich ist 1em zu groß, weil Du 1em in Bezug auf die Defaulteinstellung des Browsers und den unmündigen Benutzer siehst.

Viele Grüße,
Christian

[uepselon]

Hi,

Der Anfang:

http://fractatulum.net/kram/templates/self-layout/index.htm
SELFHTML Layouttest

ganz nett. aber das schwierige am SelfLayout ist wohl die untere Navigations-Leiste die bei deinem Beispiel gänzlich fehlt. Diese nämlich mit allen Browsern unter einen Hut zu bringen ist fast unmöglich. Hier mein alter Versuch:

http://mitglied.lycos.de/tselb/css/selfcss2.html

Leider mit Werbung :-(

Gruß,
ueps

[Jan H.]

Hallo,

... aber das schwierige am SelfLayout ist wohl die untere Navigations-Leiste die bei deinem Beispiel gänzlich fehlt. Diese nämlich mit allen Browsern unter einen Hut zu bringen ist fast unmöglich. Hier mein alter Versuch:

Ja, bis dahin habe ich noch nicht geschaut.
Aber Orlando hat das ja recht gut gelöst:

http://skop.net/self/selfhtml_css/

Ich habe an meiner version nochmal etwas geändert:
http://fractatulum.net/kram/templates/self-layout/index.htm

so dass die floatenden boxen wie bei Ingos variante auch umbrechen, funktioniert auch, nur im IE machts das nicht ganz wie gewollt. Und alle maße wurden "em-isiert".

Dann habe ich mal css für NN4 eingebaut, eigentlich wurden nur die margins und paddings angepasst sowie die floatenden boxen.
Nun gut, die herkunft der seite sollte zu erkennen sein aber etwas besser könnte es schon noch werden.

Gruss, Jan aus Dresden

[Orlando]

Hi Stefan,

[...] meinst du, du schaffst es mittlerweile, das SELF-Layout 1:1 in ein CSS-Layout umzubauen, welches zumindest in Mozilla 1.x, MS IE 6.x, Opera ab 6.x und vielleicht noch Konqueror ziemlich gleich aussieht (von NS 4.x rede ich gar nicht mehr)? Obwohl das SELF-Layout gar nicht so aufwaendig ist, wirst du vermutlich trotzdem ziemlich ins Schwitzen kommen, diverse Workarounds brauchen und tricksen muessen, was die reine Lehre doch arg aufweicht.

ich habe etwas gebastelt und bin vorerst bis zu

http://skop.net/self/selfhtml_css/

gekommen. Das ist zwar noch nicht so, wie ich es mir wünsche, aber es kommt dem Original doch schon sehr nahe. Die Tabelle mit den Links am Ende der Seite war leider nur mit einiger Mühe nachzubilden. Getestet habe ich mit Opera 5.02, 6.05 und 7.21, sowie Firebird 0.7, M$IE 6 und Netscape 4. Bis auf die Kröte sind sich alle einig :-) Über Feedback, wie andere Browser damit zurechtkommen, würde ich mich freuen.

Grüße,
 Roland

[Jan H.]

Hallo Orlando,

http://skop.net/self/selfhtml_css/

... Über Feedback, wie andere Browser damit zurechtkommen, würde ich mich freuen.

Ja, das sieht wirklich gut aus.
Ich kann noch NN6 anbieten und da schaut's auch wie gewollt aus und NN3 :) nicht ganz so aber ist ohne probleme zu bedienen.

Gruss, Jan aus Dresden

[Orlando]

Hi Jan,

http://skop.net/self/selfhtml_css/

Ich kann noch NN6 anbieten und da schaut's auch wie gewollt aus und NN3 :) nicht ganz so aber ist ohne probleme zu bedienen.

danke. Ich habe das Layout jetzt an das von SELFHTML angepasst, vor allem die Schriftgrößen. Außerdem *sollte* es jetzt auch mit dem M$IE4 halbwegs gleichwertig aussehen.

Was man einem Screenshot an Information entreißen kann... Danke, Thomas :-)

Grüße,
 Roland

[benni]

Hi!

Wenn Du gar nicht erst mit dem Tabellen-Blödsinn angefangen hättest, hättest Du niemals ein Problem gehabt.

Da hast du recht. Ich hab erst lange nach meinen ersten Versuchen mit CSS festgestellt, dass man auch mit Tabellen Layouten kann. Aber da wars dann schon zu spät ;-). Und jetzt bin ich eigentlich sehr froh darüber...

[Cyx23]

Hallo Frankie,

Also liebe Anfänger, benutzt Tabellen! Glaubt nicht was die "Gurus" euch erzählen. Die "Gurus" haben andere Browser.

könnte ich nachvollziehen wenn deine Tabellellenversion vorhanden wäre oder die unten verlinkte Seite funktionieren würde.

http://www.brasilieninformation.de/test/upload_2003_11_18/index2.php
(Zwischenstufe: Tabelle mit ein bisschen CSS)

Absichtlich o. versehentlich falscher Link (CSS-Layout mit Tabelle)?

Grüsse

Cyx23

[FrankieB]

Hi Cyx23,

könnte ich nachvollziehen wenn deine Tabellellenversion vorhanden wäre oder die unten verlinkte Seite funktionieren würde.

... nanana, das ist ja eine Tabellellenversion!

http://www.brasilieninformation.de/test/upload_2003_11_18/index2.php
Absichtlich o. versehentlich falscher Link (CSS-Layout mit Tabelle)?

Weder noch, der Link war korrekt.

Grüsse

Frankie

[Cyx23]

Hallo Frankie,

Hi Cyx23,

könnte ich nachvollziehen wenn deine Tabellellenversion vorhanden wäre oder die unten verlinkte Seite funktionieren würde.
... nanana, das ist ja eine Tabellellenversion!

weder noch, es ist ohne deine Testbrowser einfach nur Schrott :_)

http://www.brasilieninformation.de/test/upload_2003_11_18/index2.php
Absichtlich o. versehentlich falscher Link (CSS-Layout mit Tabelle)?
Weder noch, der Link war korrekt.

Um so schlimmer, deine Tabellenversion:

<body>
<div id="header">
Header-Text
</div>
<div id="nav_oben">
<ul id="nav">

Mach doch bitte erstmal funktionierendes Tabellenlayout bevor du "Tabellen sind besser" propagierst!

Grüsse

Cyx23

[FrankieB]

Hi Cyx23,

weder noch, es ist ohne deine Testbrowser einfach nur Schrott :_)

hmmm ... was wird jetzt schon wieder "falsch" dargestellt ..

Cyx23, ich will ja nicht streiten was besser ist, ich will und wollte nur eine konstruktive Duskusion anleiern ...

Grüsse
Frankie

[Cheatah]

Hi,

Cyx23, ich will ja nicht streiten was besser ist, ich will und wollte nur eine konstruktive Duskusion anleiern ...

eine Behauptung, die absolut kontrovers zur geläufigen Expertenmeinung ist und in der Runde eben dieser Experten aufgestellt wird, hat nur geringe Chancen, zu einem konstruktiven Diskurs zu führen; insbesondere wenn sie genau der Meinung entspricht, von der o.g. Experten sich mittlerweise konsequent abwenden.

Cheatah

[Ingo Turski]

Hi,

hmmm ... was wird jetzt schon wieder "falsch" dargestellt ..

so ziemlich alles ..;-)
insbesondere die hintergrundfarbe (sofern sie im browser nicht auf weis gestellt ist) und die breite der tabellenzeilen.
ich vermute, dein browser - den du als referenz verwendest - ist der internet explorer, oder?
und genau das ist dein fehler: du bastelst ein seite, die im IE korrekt aussehen mag, aber sich nicht am standard orientiert. daß der ie sie dennoch wie gewünscht anzeigt liegt entweder an seiner fehlertoleranz oder daran, daß du die seite für die falsche interpretation des IE geschrieben hast (stichwort box-modell-bug und diverse andere bugs im IE).

ich finde es im zusammenhang mit deinem posting hier sehr passend, daß gerade deine tabellenkonstruktion nicht funktioniert - und zwar in modernen browsern, die sich an den standard halten nicht funktioniert.
es kann also mit tabellen im grunde das gleiche wie bei css-layouts passieren: nämlich daß nachgebessert werden muß, weil einige browser probleme bereiten. nur daß halt - bei standardkonformen seiten - in aller regel für den IE nachgebessert werden muß.

sicher gibt es browser, die noch weniger CSS unterstützen als der IE, aber die kannst du eigentlich zunehmend vernachlässigen und ihnen eine abgespeckte aber nutzbare version der seite liefern.
denk mal drüber nach ...

freundliche Grüße
Ingo

[Cyx23]

Hallo Frankie,

weder noch, es ist ohne deine Testbrowser einfach nur Schrott :_)

hmmm ... was wird jetzt schon wieder "falsch" dargestellt ..

Cyx23, ich will ja nicht streiten was besser ist, ich will und wollte nur eine konstruktive Duskusion anleiern ...

du hast aber m.E. etwas das Thema verfehlt, ich streite nicht was besser ist sondern beanstande deinen Etikettenschwindel: Das Thema wäre "kann nicht genug CSS und richtig tabellen is auch nich".

Sorry wenn ich das so scheinbar unfair einem selbsternannten Anfänger gegenüber formuliere, aber wenn du schon soviel Vorstellung davon hast zu behaupten nur "Formatieren des Schriftgrads oder ähnliche Dinge mit CSS" zu machen oder zu empfehlen, warum machst du dann kein crossbrowsertaugliches gutes Tabellenlayout, das du ggf. per CSS bei Schrift und Farbe usw. ergänzt?

Dazu noch das merkwürdige Verhalten von deinem Server -eine Browserweiche per php, Umleitung?- jedenfalls läuft das wohl auch nicht sauber.

Grüsse

Cyx23

[Chräcker Heller]

Hallo,

wie so oft denke ich, liegt die Wahrheit dazwischen. Es gibt weder einen Grund, Tabellen zu verteufeln (was bei dieser Generalformulierung erst einmal ja keiner der Fraktionen macht ;-)) noch CSS zu scheuen.

Manche Dinge gehen mir mit Tabellen auch leichter von der Hand, manche Dinge erscheinen mir gar unmöglich, und da meine Denkweise reparaturfällig ist, nehme ich eben dann Tabellen, wenn ich mir etwas schweres zeitlich nicht erlauben kann oder eben etwas unbedingt meine zu brauchen, was eben mit CSS nicht geht. Oder wenn CSS eh ein ebensolcher Krampf wäre wie Tabellenkrampf. (Denn Tabellen-Layoutnutzung durch wildes div-gefloate zu ersetzen ist ja auch kaum Sinn der Sache....)

Asnonsten ziehe ich mittlerweile lieber tabellenloses Design vor, alleine weil es hinter den Kulissen "eleganter" aussieht. Tabellen als Layoutmittel hat übrigens den gleichen Effekt, wie alle anderen Werkzeuge auch (also auch "CSS") - es schlägt sich bei zu intensiver gläubiger Nutzung eine Ästetik durch, die eng mit dem jeweiligen verwendeten Werkzeug zusammen hängt. Eine "Div-gefloatete" CSS Seite sieht man selbiges genauso meistens an wie ein zu intensives Tabellendesign. Gerade die Starrheit des letzteren mit CSS nachzumalen ist da sowieso Quatsch. Wenn Tabellendesign, dann eben auch mit Tabellen. Man kann eine Fleisch-Frikadelle nicht Fleischlos herstellen ;-) Wer mit viel Kunst eine fleischlose Frikadelle auf den Geschmack und das Aussehen einer Fleischfrikadelle trimmt, der traut der fleischlosen Küche zuwenig eigene Rafinesse zu ;-) (Umgekehrt natürlich auch....)

Chräcker

[FrankieB]

Hallo Chräcker,

wie so oft denke ich, liegt die Wahrheit dazwischen. Es gibt weder einen Grund, Tabellen zu verteufeln (was bei dieser Generalformulierung erst einmal ja keiner der Fraktionen macht ;-)) noch CSS zu scheuen.

Manche Dinge gehen mir mit Tabellen auch leichter von der Hand, » []

Asnonsten ziehe ich mittlerweile lieber tabellenloses Design
[]

... da kann ich dir nur zustimmen ;-)

Die Wahrheit liegt wahrscheinlich wie immer irgendwo dazwischen ...

Daher frage ich mich auch immer, weshalb es so viele Verfechter des
reinen CSS gibt.

Ich mag Frikadellen mit Fleisch. Der Geschmack entscheidet.

Grüsse
Frankie

[Struppi]

Daher frage ich mich auch immer, weshalb es so viele Verfechter des
reinen CSS gibt.

Ja, wo denn?

Wenn du ein mehrspaltigen Entwurf hast wirst du momentan nur schwer und am besten gar nicht ohne Tabellen auskommen. Allerdings ist dein Entwurf jetzt eine DIV soup und enthält nach wie vor zahlreiche (überflüssige?) Tabellen.

Du solltest die Bereiche klarer strukturieren und nicht immer von einem DIV oder was auch immer ausgehen.

Was ich bei dir sehe ist:

Logo

Naviagtion

Menu -> Inhalt

und im Inhalt Fließtext mit verschiedenen Überschriften.
Ansonsten sind im Text Bildelemente, die entweder Links Fliessen oder Rechts.

Und wie gesagt Mehrspaltigkeit ist in HTML nicht vorgesehen ist auch nur bedingt praktisch bei längeren Texten wieder hoch scrollen zu müssen.

Alles in allem könnte man den Quelltext wesentlich klarer strukturieren und dann mit weniger DIV's (die auf gar keinen Fall ein Ersatz für Tabellen sind) und auch mit weniger Tabellen auskommen, wenn du mehr einfache HTML Elemente verwenden würdest.

Struppi.

[Cyx23]

Hallo,

Wenn du ein mehrspaltigen Entwurf hast wirst du momentan nur schwer und am besten gar nicht ohne Tabellen auskommen.

stimmt nicht, mehrpaltiges Layout ohne Tabellen per CSS  geht sogar für IE oder Netscape 4.

Und wie gesagt Mehrspaltigkeit ist in HTML nicht vorgesehen ist auch nur bedingt praktisch bei längeren Texten wieder hoch scrollen zu müssen.

Stimmt nicht, schließlich gibt es dafür Tabellen, und einige Browser können Text sogar selbst mehrspaltig umbrechen, und zum letzen Punkt, lesbar muß es auch noch sein zumal es Scrollräder (oder wie wärs mit Frames) gibt .

Grüsse

Cyx23

[Frank Opper]

Hallo,

Beim Versuch meine Seite auf CSS zu trimmen mußte ich aber leider feststellen, daß CSS von gängigen Browsern nicht ausreichend unterstützt wird.

Mit welchen Browsern hast Du getestet?

Insbesondere Anfängern (so wie mich) rate ich daher dringenst davon ab, das Seitenlayout komplett mit CSS zu gestalten. Formatieren des Schriftgrads oder ähnliche Dinge mit CSS zu bewerkstelligen ist natürlich absolut ok.

Also liebe Anfänger, benutzt Tabellen! Glaubt nicht was die "Gurus" euch erzählen. Die "Gurus" haben andere Browser.

Falsch! Ich habe vor einiger Zeit Seiten von Tabellen auf CSS umgestellt und sehe nur Vorteile:

• klare Struktur der Seiten
• weitaus mehr Möglichkeiten bei Änderungen des Layouts
• bessere Wartbarkeit

Ok, ich gebe zu, dass es auch bei mir etwas gedauert hat, um eine gewisse "CSS-Denke" zu erreichen und mich von Tabellen zu lösen. Tabellen sind für bestimmte Sachen sinnvoll, aber nicht für Layouts.

Und: Nein, ich bin kein Guru.

Viele Grüße
Frank

[FrankieB]

Hallo,

ich bin erfreut über die rege Teilnahme an diesem Thread ;-)

Um den Thread aber nicht noch weiter abdriften zu lassen, möchte ich mein ursprüngliches Anliegen nochmals formulieren.

Mir geht/ging es darum, ein relativ einfaches Tabellenlayout mit css umsetzen.

Ich hatte es versucht, selbst, mit Anregungen von Forumsteilnehmern, mit "Hacks" ...

Ich bin kein Profi, aber ich weiß durchaus was ich tue. Wenn mein Tun nicht das gewünschte Resultat erbringt, dann mag es an meinem Browser liegen. Aber das kann nicht das Hauptproblem sein, denn ich gehe sehr dezent mit brauserspezifischen Features um.

Fazit:
So wie ich es möchte geht es nicht mit CSS. Daher sind Tabellen nach wie vor das geeignetere Mittel für meine Bedürfnisse. Daher sind die Ausagen "Verwende CSS statt Tabellen" nicht haltbar.

Bitte:
Die Verwender von Tabellen nicht immer pauschal kritisieren, das ist nicht fair!

@Die CSS-Besserwisser:
Kann man meine ursprüngliche Idee mit CSS eigentlich brausertolerant (= ohne Hacks, etc.) umsetzen?

Gruß
Frankie

[Cyx23]

Hallo,

Um den Thread aber nicht noch weiter abdriften zu lassen, möchte ich mein ursprüngliches Anliegen nochmals formulieren.

??

Mir geht/ging es darum, ein relativ einfaches Tabellenlayout mit css umsetzen.

http://www.google.de/search?hl=de&ie=ISO-8859-1&q=spalten+layout+css+&meta=

Bitte:
Die Verwender von Tabellen nicht immer pauschal kritisieren, das ist nicht fair!

Verwende die Tabellen doch bitte so dass sich die mögliche breite Unterstützung verschiedenster Browser auch wirklich bemerkbar macht!

Grüsse

Cyx23

[at]

Hallo.

Fazit:
So wie ich es möchte geht es nicht mit CSS. Daher sind Tabellen nach wie vor das geeignetere Mittel für meine Bedürfnisse. Daher sind die Ausagen "Verwende CSS statt Tabellen" nicht haltbar.

Fazit:
Nur weil du es nicht kannst, ist es nicht unmöglich.

Bitte:
Die Verwender von Tabellen nicht immer pauschal kritisieren, das ist nicht fair!

Wär hätte dies je behauptet? ;-)

@Die CSS-Besserwisser:
Kann man meine ursprüngliche Idee mit CSS eigentlich brausertolerant (= ohne Hacks, etc.) umsetzen?

Ohne "etc."? Nein.
MfG, at