Der Artikel Why CSS should not be used for layout
(veröffentlicht am 2. Februar) wird zur Zeit durch die Blogs gereicht, war schon bei Ajaxian und beim Webzeugkoffer. Der Autor des Artikels vertritt die These, dass man für Layouts statt CSS-Floats lieber Tabellen verwenden sollte, da CSS zu viele Macken habe – zum Beispiel bei mehrspaltigen Websites. Der Artikel nennt zahlreiche hierfür Beispiele und analysiert die Mängel von CSS auf zutreffende Weise.
Der Denkfehler hierbei ist nur, dass bloß weil das Eine vielleicht nicht das Nonplusultra ist, die Alternative nicht automatisch die Lösung ist. CSS ist im jetzigen Zustand für komplexe Layouts vielleicht nicht besonders ideal und in wie weit die Trennung von Design und Inhalt damit umgesetzt werden kann, ist bestenfalls von Fall zu Fall unterschiedlich. Fakt ist aber, dass sie mit Tabellen von in jedem Fall komplett ausgeschlossen ist. Viel Spaß dabei, ein vierspaltiges Tabellenlayout auf dem Winzbildschirm eines Mobilgeräts abzubilden. Hinzu kommt der ganz beachtliche HTML-Overhead.
Kurz gesagt ist CSS immer noch das beste was wir haben – habe es auch die eine oder andere Kinderkrankheit. Nicht von solchen Artikeln bekehren lassen.
Kommentare (66)
Frank ¶
4. Februar 2009, 23:22 Uhr
Zustimmung +1
Wollen wir hoffen, dass sich nicht diverse Leute an diese Meinung hängen und wir wieder bei Null anfangen müssen um die Massen der Tabellenlayouts zu verdammen.
Peter ¶
4. Februar 2009, 23:25 Uhr
Genau das ist meine Befürchtung. Der Artikel ist überzeugend und in vielen Punkten nicht falsch. Das ist gefährlich.
YellowLed ¶
4. Februar 2009, 23:36 Uhr
Ich bin noch nicht dazu gekommen, den bzw. die auslösenden Artikel zu lesen (von den dranhängenden Kommentar-Rattenschwänzen ganz zu schweigen), aber so langsam verspüre ich auch keine große Lust mehr darauf.
Wenn wir jetzt schon zu Tabellenlayouts zurück sollen (was ich persönlich streng genommen gar nicht *kann*, derweil ich solchen Unfug so gut wie nie gemacht habe; die Gnade des Spätberufenen), könnten wir aber doch auch gleich FONT und ALIGN reanimieren. Ist ja ein Abwasch. Oder wir bauen gleich ganze Seiten als bildschirmfüllende ImageMap oder am besten in Flash.
Und überhaupt: Barrierearmut, Usability, ist doch alles Tinnef. Hauptsache, es sieht gut aus und geht schnell, gelle? Time is money, gerade in diesen Zeiten allgemeiner Teuerung ;-)
Luchador GFX ¶
5. Februar 2009, 00:50 Uhr
schnell gecodet sind tabellen auf jedenfall,
aber jedem halbwegs professionell arbeitendem Webdesigner sollte klar sein das sich Webseiten immer mehr dazu entwickeln auf allen Anzeigen gut auszusehen.
Und selbst Hobby-Designer welche mal mit ihrem Handy ein bisschen mobil in der InternetLandschaft gesurft sind werden verstehen wieso CSS einfach die schlauere Lösung ist.
Schwierig wirds nur das Laien ebenfalls klar zu machen.
Mit gutem Beispiel vorran gehen wird aber auch in Zukunft definitiv am meißten nutzen bringen.
erlehmann ¶
5. Februar 2009, 04:18 Uhr
Kennt der Autor etwa
display:table-foonicht?Björn ¶
5. Februar 2009, 06:59 Uhr
Ich denke, er ist kürzlich an irgendwas gescheitert, das mit CSS zu tun hat und lässt seinen Frust ab. Oder er wollte schnell, viele Besucher und "Ruhm". Oder es steckt eine Bewegung dahinter. Oder Alkohol am Arbeitsplatz? ;-)
Wie Du auch schon angemerkt hast, ist diese Abhandlung zwischendurch immer wieder ziemlich einleuchtend. Wobei die Argumente im Gesamtkontext nicht aufrecht erhalten werden können bzw. zu wenig Gewicht haben, um deshalb gleich Layout mit CSS in Frage zu stellen.
Die nachfolgende Diskussion macht's dann aber wieder interessant. Wobei man viel Zeit mitbringen muss, um die insgesamt über 300 Kommentare durchzulesen :-)
soophie ¶
5. Februar 2009, 08:20 Uhr
amen bruder!
Peter ¶
5. Februar 2009, 08:22 Uhr
Zitat erlehmann:
Man weiß es nicht, aber wenn er es kennt, ist das aus einer Sicht eher ein weiteres Argument für HTML-Tabellen – denn die würden, anders als CSS-Tabellen, auch im IE<8 funktionieren.
Bernd ¶
5. Februar 2009, 09:11 Uhr
Ich denke, dass ist der Punkt. Mehr muss ich dazu nicht sagen.
Der Autor sagt unter anderem:
Hmmm, weil Cplusplus "schwerer zu schreiben" ist, kommt aber auch keiner auf die Idee es mit BASIC zu versuchen...
Karsten ¶
5. Februar 2009, 10:41 Uhr
Was dem Einen sein Mac-Bashing, ist dem Anderen sein Tabellen-Layout. Einfacher lässt sich eine hitzige Diskussion unter Webworkern nicht anzetteln.
Stefan ¶
5. Februar 2009, 12:02 Uhr
Zitat erlehmann:
Unglaublich! Erst dachte ich, das sei ein alter Artikel, aber weit gefehlt. Ich persönlich brauche
display:tablenoch nicht mal, bislang konnte ich noch _jedes_ Layout in CSS umsetzen. Komplexe Tabellen kann man nur in WYSIWYG-Editoren pflegen, und das wollen wir doch schön bleiben lassen …datenkind ¶
5. Februar 2009, 13:14 Uhr
Das greift ja viel weiter.
Die sonst so berühmt berüchtigten Jungs von 37signals haben das aufgegriffen und gutgeheißen und lauthals gemeint, CSS-Layouts sind was für Trolle.
Das Blog dieses einen Honks da kennt ja kein Schwein. Nur: Signal vs. Noise hat drauf verlinkt.
Ihr Fett haben die ganzen Deppen jedenfalls wegbekommen. Ist auch richtig so. Ganz ehrlich.
JCG ¶
5. Februar 2009, 13:21 Uhr
Brr, gruselig! ;-o
Markus Thömmes ¶
5. Februar 2009, 14:11 Uhr
Zitat Stefan:
Genau so sieht es aus! Mit ein wenig Geduld (und zum Teil auch ein bisschen googel) bekommt man jedes Layout auch mit CSS umgesetzt! So einen Schwachsinn wie diesen Artikel (hab ihn nicht gelesen aber deine kurzen Erläuterungen sagen alles) sollte nicht in die Welt gesetzt werden.
FuNKeR ¶
5. Februar 2009, 20:37 Uhr
Full Ack!
Ich bin auch schon seit langem begeisterter CSSer. Tabellen hab ich ziemlich schnell wieder über Bord geworfen und werd sie zu Design-Zwecken wohl nie wieder benutzen.
*procss*
Alexander ¶
6. Februar 2009, 07:35 Uhr
Ich hatte es kürzlich in der Firma noch mal mit einer "alten" Tabellen-Seite zu tun, die ich gerne kurz in CSS umgebaut hätte (es war nur eine kleine Seite mit wenig Inhalt), aber da das angeblich zu lange dauern würde habe ich versucht, den Müll nur um ein paar Links zu erweitern.
Fazit: Ich habe mich dann doch den ganzen Tag mit den Tabellenzellen herumgequält, weil sich die Änderung einer Zelle ja auch gleich auf die column auswirkt und es schnell alles verschiebt. Also: schnelle Breitenänderungen oder Anpassungen? Forget it! Ich muss hier dauernd Kleinigkeiten an Seiten ändern (hier mal breiter, da mal schmaler) und mit CSS ist das KEIN PROBLEM (wenn man die IE6-Bugs kennt.
Rückkehr zu HTML-Tabellen: NEVER EVER!!!! Wer -sorry- zu dämlich ist CSS zu kapieren, sollte sich 2009 einen anderen Job suchen. Punkt!
GE ¶
6. Februar 2009, 09:58 Uhr
Mit dem Tabellenlayout ist es wie mit allem anderen, man kann es sinnvoll machen und auch schlecht. Wenn die eingerückten td den rechten Bildschirmrand meines widescreens erreichen, dann grauts mich auch.
Aber ein militanter Tabellenverweigerer bin ich nicht. Der grosse Vorteil von CSS, dass ich ein CSS-Layout besser an zentraler Stelle ändern kann, ist z. B. bei einem Template-basierten CMS dahin. Ich kann das Template auch mit Tabellen neu gestalten, Layout und Design völlig runderneuern.
Das hat nix mit Wiedereinführung von font, align & Co. zu tun, auch eine Tabelle kann wunderbar CSS-gestylt daherkommen.
Ich bevorzuge auch CSS-Layouts, schrecke aber vor dem Einsatz einer Tabelle, auch zu Layout-Zwecken, nicht zurück, wenn es sinnvoll ist. Wenn etwas die Layout-Eigenschaften einer Tabelle haben soll, dann nehme ich auch eine Tabelle. Oft besser als Verrenkungen mit CSS3 und display:table zur Unzeit. In ein paar Jahren vielleicht.
Also locker bleiben, vertretet Euren Standpunkt, aber lasst andere auch mal selber, und vor allem auch mal anders denken. Überheblichkeit war noch nie ein sonderlich hoch bewerteter Charakterzug.
Markus Thömmes ¶
6. Februar 2009, 11:55 Uhr
Das Problem ist einfach, dass Tabellen nicht zum layouten gedacht sind! Sie sollen etwas tabellarisch darstellen. Und dabei sollte man es eben auch belassen.
Johann ¶
6. Februar 2009, 12:16 Uhr
Ist schon Krass, dass CSS ausgerechnet an der webspezifischen Flexibilität von Layouts versagt. Das sollte doch die Kernkompetenz von CSS sein. Da kann man schon mal Zweifeln.
GE ¶
6. Februar 2009, 12:33 Uhr
Zitat Markus Thömmes:
Für mich ist das kein Problem. Mit 2 Löffeln oder einem Waschbrett kann man wunderbar Musik machen, obwohl die eigentlich nicht dazu gedacht sind ;-)
Natürlich mache ich Musik normalerweise mit anderen Instrumenten, aber wo es passt ...
Und ich mache die Musik auch nicht NUR mit Löffeln und Waschbrett, bei den meisten Liedern kommen diese Instrumente gar nicht zum Einsatz.
Peter ¶
6. Februar 2009, 13:26 Uhr
Es ist doch interessant zu lesen mit welcher Regelmäßigkeit bestimmte Themen immer wieder auf den Tisch des Hauses kommen. Es werden immer dieselben Stereotypen in Stellung gebracht, wenn es darum geht, Layouts mit Tabellen zu gestalten. Die mangelnde Fähigkeit mit CSS umzugehen, kann ja nicht bedeuteten alten Wein in neue Schläuche zu füllen.
Tabellen sind für Darstellung von Daten sinnvoll, Punkt! Es kommt ja auch keiner auf die Idee einen Brief mit Excel zu schreiben.
GE ¶
6. Februar 2009, 14:10 Uhr
Zitat Peter:
Du glaubst gar nicht, wie verbreitet das ist. Standardvorlagen für Briefe in Excel. Aber auch nur für bestimmte Standardbriefe.
Was mich eigentlich an diesen Diskussionen stört, ist dass immer wieder mangelnde Fähigkeiten im Umgang mit CSS unterstellt werden. Wer eine Tabelle zum layouten nutzt ist von vorgestern, hat keine Ahnung, ist zu faul zum lernen und sollte sich einen neuen Beruf suchen.
Es wird einfach nicht akzeptiert, wenn sich gerade jemand, der sich sehr intensiv mit allem Pro und Contra beschäftigt hat, nach reichlicher Überlegung an einer bestimmten Stelle für die Tabelle entscheidet.
Die Überschrift "Why CSS should not be used for layout" ist ganz sicher überspitzt. Ich habe den Artikel auch nur überflogen, so wie ich das verstanden habe geht es nur um das Grundgerüst
header
Spalte 1-3
footer
Innerhalb der Tabellenzellen kann und soll man sich dann mit CSS austoben.
Ich finde es schade, wenn solche Überlegungen nicht diskutiert, sondern einfach vom Tisch gewischt werden, mit einem kategorischen "Punkt!" hinten dran.
Peter ¶
6. Februar 2009, 14:16 Uhr
Zitat GE:
Nun, die Gründe für das vom-Tisch-wischen sind ja nun zahlreich und nicht von der Hand zu weisen. Insofern ist das als Fazit schon richtig. Anderseits ist es zweifellos so, dass es unnötig kompliziert ist, komplexe tabellenartige Layouts mit CSS umzusetzen. Ich sitze und fluche selbst gerade an so einem. Nur – wenn man am Ende alle Vorteile und Nachteile gegeneinander aufrechnet verlieren die Tabellen immer noch.
CW ¶
6. Februar 2009, 15:23 Uhr
Und ich hatte gedacht, das Tabellen-Thema sei so gut wie vorbei! Bei der Arbeit an alten Seiten (mit Tabellen) merkt man schnell, warum CSS das bessere "Übel" ist :)
Benjamin ¶
6. Februar 2009, 19:02 Uhr
Was würde der Erfinder von CSS, Håkon Wium Lie, dazu sagen?
Er hat damals mit Tim Berners-Lee zu viert an HTML gearbeitet und schon damals war klar, dass HTML nicht für Layoutzwecke ernsthaft in Frage kommt.
Was ist daran eigentlich so schwer zu verstehen? Bis eine Technik den Markt für sich einnimmt soll es doch immer so ungefähr 10 Jahre dauern. Da sind wir nun schon weit drüber...
Zumal das Argument, es wäre sehr schwer CSS zu schreiben, nur über die eigene Unfähigkeit Auskunft gibt. Sowas.
datenkind ¶
6. Februar 2009, 22:36 Uhr
Ja verdammich, aber bei 99% der „Anwender“ ist das nunmal so!
Ich kann doch als Automechaniker auch nicht sagen, dass ich nur den 8er Schlüssel nehm, weil mir der 15er zu schwer ist! Das ist doch Blödsinn. Entweder ich habe die Ehre im Leib und gehe mit gewissem Berufspathos ans Werk und hiefe meinen Allerwertesten dazu auf, dem Kunden die gerechte Qualität zu liefern, oder ich lass es bleiben.
Webentwicklung ist kein Ferienurlaub im Takka-Tukka-Land. Es ist nicht einfach, es ist oft verdammt harte (Hirn-)Arbeit. Entweder ich nehm das auf mich, oder ich lass es.
Herr Gabriel ¶
7. Februar 2009, 16:28 Uhr
Ich wittere "target=_blank 2"...
André ¶
15. Februar 2009, 17:46 Uhr
Nachdem ich zunächst ca. 8 Jahre lang Tabellenlayouts und seitdem ca. 4 Jahre lang CSS-Layouts gebaut habe, komme ich zu dem Fazit, dass die Verteufelung von Tabellenlayouts überzogen und die diesbezüglichen Argumente nicht immer stichhaltig sind.
1. falsches Argument: Tabellenlayouts sind nicht barrierefrei. - Das ist unlogisch. Denn wenn eine Datentabelle mit zahlreichen Spalten und Zeilen barrierefrei sein kann, kann es eine simple dreispaltige Layouttabelle auch.
2. falsches Argument: Tabellen sind nicht fürs Layouten gedacht. - In welcher HTML-Spezifikation bitte steht das? Und selbst wenn: ist eine dreispaltige Tabelle, über deren Spalten man durchaus sinnvoll die <th>-Überschriften "Navigation", "Inhalt" und "Infoboxen" setzen könnte, wirklich Layout oder nicht vielleicht doch einfach nur eine sinnvolle Datenanordnung?
3. falsches Argument: Tabellen passen nicht in Minibildschirme. - Das gilt für dreispaltige CSS-Layouts ganz genauso. Dass ein CSS-Layout in diesem Falle umbrechen und die Spalten untereinander setzen kann, gilt ebenfalls auch für eine Tabelle: @media handheld { table, tr, td { display: block; }}. Andererseits bietet ein "Spaltenumbruch" nicht immer den besseren Anblick - manchmal ist ein waagerechter Scrollbalken das geringere Übel.
4. falsches Argument: Tabellenlayouts lassen sich schlecht warten. - Erstens: im Zeitalter von CMS, wo auch der HTML-Code zentral verwaltet wird, verliert dieses Argument heftigst an Bedeutung. Zweitens: dieses Argument hatte für mich auch vorher keinerlei Bedeutung, da ich es noch nicht ein einziges Mal erlebt habe, dass ich bei einem Redesign den alten HTML-Code unverändert wiederverwendet und das neue Layout nur mittels CSS in diesen Code reingewürgt habe. Es war ausnahmslos immer notwendig, Seitenelemente anders anzuordnen, hinzuzufügen oder herauszunehmen. Genaugenommen gibt es kein Redesign, sondern nur einen Neuanfang - und zwar nicht nur beim Design, sondern auch bei Site-Struktur, Inhalt und Funktionalität. Der Traum, Redesigns nur durch Anfassen der zentralen .css-Datei zu realisieren, ist reine Theorie bzw. Augenwischerei (csszengarden) - in der Praxis ist es mir noch nicht untergekommen, und in der Praxis führt leicht (d.h. gar nicht) zu wartender, für die Ewigkeit geschriebener HTML-Code nur zu schwer zu wartenden CSS-Dateien.
5. falsches Argument: Tabellenlayouts erzeugen mehr/unnötiges Markup. - Dafür erzeugen CSS-Layouts mehr (Browserhacks) und unnötigen (clear) CSS-Code. Es passt für mich einfach nicht zusammen, einerseits für sauberen, validen und schlanken HTML-Code zu plädieren, und andererseits den dabei vermiedenen "Dreck" in der CSS-Datei abzukippen. Da einige "Tricks" auf Hintergrundgrafiken beruhen (gleichlange farbig hinterlegte Spalten), wird außerdem die fürs Markup "eingesparte" Ladezeit für die Grafiken wieder verpulvert. Außerdem zoomen Hintergrundgrafiken für Spalten nicht mit, wenn die Spaltenbreite in "em" angegeben ist. Dass sieht dann immer total professionell aus, wenn sich unter dem letzen Navigationslink eine Stufe bildet oder die Links aus dem Grafikstreifen herausragen. Am professionellsten sieht sowas aus, wenn die Textfarbe der Navilinks mit der Hintergrundfarbe der Nachbarspalte identisch ist.
6. falsches Argument: Tabellen lassen sich immer durch CSS wenigstens gleichwertig ersetzen. - Siehe Punkt 5.
Ich kenne nur einen objektiven Grund, Tabellen nicht als Layoutmittel zu verwenden: wenn sich das Layout *nicht* wie eine Tabelle verhalten soll.
Alles andere ist reine Ideologie.
André
Markus Thömmes ¶
15. Februar 2009, 18:31 Uhr
Richtig in der Spezifikation! Da steht aber auch nicht wofür sie nicht sind sondern wofür sie gedacht sind. Und das ist nunmal NICHT layouten!
Tabellen sind, bei deinem Anwendungszeck, eben nicht semantisch korrekt eingesetzt. Ich denke darauf die zielt die "nicht-barrierefreiheit" ab.
Tabellencode ist und bleibt beschissen zu warten. Du weisst vielleicht wo dein ganzes Zeugs ist, aber wenn ein anderer an deinem Code schrauben soll (soll im Zeitalter von CMS wo ja durchaus vorkommen) wirds schwierig. Stichwort: Wiederverwertbarkeit.
Zu den Hacks und Markup: Es ist nunmal so, dass sich bspw. ein Textbrowser nicht um die CSS Datei schert! Für ihn zählt einzig und allein ein sauber geschriebener semantisch korrekter HTML Code. Soweit ich weiss geht's dem Screenreader genauso, womit wir bei der Barrierefreiheit wären.
André ¶
15. Februar 2009, 20:20 Uhr
Was in den Spezifikationen nicht drinsteht, ist deswegen nicht automatisch verboten. Außerdem ist es eine Ermessensfrage, ob Dreispaltigkeit ein Layout- oder ein Ordnungsmerkmal ist. Ich sehe es durchaus auch als Ordnungsmerkmal.
Wenn es nach deinem Argument ginge, dürftest du UL-Elemente nicht für Navigationsmenüs einsetzen, denn dafür war eigentlich das MENU-Element gedacht. Weil dieses aber in HTML 4 abgeschafft wurde, hat sich als Ersatz das weniger semantische UL-Element eingebürgert. Nun kommt MENU mit HTML 5 aber gottseidank wieder, und somit müsste den UL-Navigationsmenüs nun dasselbe blühen wie Layouttabellen: sie müssten als semantisch nicht korrekt und barrieremäßig suboptimal gebrandmarkt werden. Und dagegen hilft dann auch kein CSS, da muss dann schon der unantastbare HTML-Code angetastet werden.
Und ansonsten: wenn eine simple dreispaltige Layouttabelle eine Barriere sein soll, ist es eine komplexe echte Datentabelle erst recht. Und es gibt nunmal Daten, die müssen tabellarisch ausgegeben werden, sonst ergeben sie keinen Sinn. Wenn ein Browser nicht mit Tabellen klarkommt, dann tut es mir herzlich leid, aber ein standardkonformer Browser muss das einfach können.
Ich verstehe auch nicht, wieso Tabellencode "beschissen zu warten" ist. Er ist genauso einfach oder schwer zu warten, wie x-beliebige andere mehrfach verschachtelte HTML-Elemente auch. Und falls jemand in meinem "Code schrauben" sollte, setze ich bei demjenigen entsprechende Fähigkeiten voraus - alles andere wäre unhöflich.
Aber manchmal bin ich eben unhöflich: Ich hab zunehmend das Gefühl, dass im Zeitalter der Frameworks und Templates die Fähigkeit verloren geht, komplexere HTML-Strukturen wirklich zu *beherrschen* und nicht bloß per Drag&Drop in sein Projekt zu ziehen.
André
GE ¶
16. Februar 2009, 10:32 Uhr
Hallo Andre, freut mich, dass mit Deinen Beiträgen hier doch noch eine "Diskussion" entsteht. Das Thema "Layouttabellen" verkommt ja in der Regel immer wieder zu einer einseitigen "Draufhauerei" auf Leute, die bereit sind, nachzudenken und und die nicht sofort bedingungslos dem Mainstream folgen.
Was Zugänglichkeit und Anwenderfreundlichkeit betrifft kann der Einsatz von blinden Tabellen zu Layoutzwecken unter bestimmten Bedingungen, z. B. auf einem PC-Bildschirm, durchaus auch Vorteile haben.
Wenn nämlich das Grundlayout einer Seite per html hergestellt wird (Tabelle), werden die Inhalte auch bei abgeschaltetem CSS noch ordentlich angeordnet gezeigt. Wenn man dieses Grundlayout per div und CSS herstellt, werden die Inhalte bei abgeschaltetem CSS linear angezeigt.
Ein eigenes stylesheet für Hintergrundfarbe, Schriftfarbe, Schrifttyp und Schriftgrösse kann sich ein Besucher mit Farbproblemen selbst schreiben, schreiben lassen oder (z. B. im Opera) selbst aussuchen. Ein stylesheet für die Anordnung der Seitenelemente (div), das bei jeder Internetseite funktioniert, wohl eher nicht.
Eine Internetseite mit Tabellenlayout bekommt dieser Besucher also in einem ordentlichen Layout angezeigt, eine per div und CSS layoutete Seite bekommt er linear angeordnet (oder besser "ungeordnet"?) präsentiert.
Und wenn es Euch auch noch so sehr auf die Nerven geht:
Das wird wohl auch die Überlegung sein, die Jakob Nielsen dazu bewogen hat, für das Grundlayout seiner Seiten eine Tabelle zu verwenden.
Benjamin ¶
16. Februar 2009, 13:27 Uhr
@André
Und?
Ein Menü ist immer auch eine Liste. Wo ist das Problem? Wenn es im alten Standard läuft, gibt es nichts zu mäkeln. Man muss den Doctype ja nicht ändern :).
@GE
Wozu schalten Besucher CSS ab? In der Regel doch um Inhalte zu linearisieren. Ich kenne übrigens keine Dokumente die tabellarisch aufbereitet werden. Weder in Buchform, noch handschriftlich. Es sei denn es sind Rechnung oder ähnliches, aber die werden bei abgeschalteten CSS auch nicht linearisiert. Daraus folgt, dass semantisches HTML das Richtige tut, ob mit oder ohne CSS, wenn, ja wenn man es korrekt einsetzt.
Markus Thömmes ¶
16. Februar 2009, 13:43 Uhr
Fakt ist: Ordentlich semantisch geschriebene HTML Seiten sind auch ohne CSS gut bedienbar! Hierarchiche Überschriften usw. sei dank.
GE ¶
16. Februar 2009, 14:55 Uhr
Das sehe ich nicht so.
Ich schalte CSS ab, wenn mich das Design der Seite nervt, die Inhalte aber interessant sind.
Ich schalte CSS ab, wenn bei einem Blog die Schrift der Kommentare 2 Nummern kleiner ist als die Schrift des Beitrages. Sieht man übrigens sehr oft, meine Tastatur dokumentiert das, die Tasten strg, plus und minus sind schon nicht mehr lesbar.
Ich schalte CSS ab, wenn die Schrift Times New Roman übermässig und zu klein verwendet wird. Oder wenn so viele verschiedene Schriftarten, Schriftgrössen oder Schriftvarianten verwendet werden, dass es nervt.
Manche Menschen schalten CSS ab, weil sie dunkelgraue Schrift auf hellgrauem Hintergrund nicht lesen können.
Manche Menschen schalten CSS ab, weil ihnen bestimmte Farben oder Farbkombinationen Übelkeit und Kopfschmerzen bereiten.
Ich kenne niemanden, der CSS abschaltet, um die Inhalte zu linearisieren.
Nun muss ich aber bei einer Seite, deren Layout komplett auf CSS basiert, auch noch den Browser in den Fenstermodus versetzen und schmalziehen, um eine erträgliche Zeilenlänge zu erreichen. Ich muss zwischen header, Kopfnavigation, verschiedenen Sidebars und footer nach den Inhalten suchen, weil das Layout nicht mehr da ist.
Ich weiss, dass Layout per html gegen die reine Lehre verstösst. Ich weiss die Vorteile der Trennung von Inhalt und Layout zu schätzen. Ich persönlich wende eine Tabelle zu Layoutzwecken nur im Ausnahmefall an.
Aber man wird ja mal nachdenken dürfen. Und vielleicht akzeptieren dürfen, das der eine oder andere ein wenig Grundlayout im html gar nicht so schlecht findet.
André ¶
16. Februar 2009, 19:27 Uhr
Ich habe den Eindruck, als würde man einer Tabelle vorwerfen, dass sie auch wie eine Tabelle aussieht. Dass sie es wagt, auch dann wie eine Tabelle auszusehen, wenn man es ihr vorher nicht explizit via CSS befohlen hat. - Nun, ein UL-LI-Block sieht auch wie eine Liste aus, ohne dass man ihr vorher gesagt hat, dass vor jedem LI ein Bullit erscheinen soll, dass sie einrücken und oben und unten einen Margin haben soll. Ja, selbst ein DIV-Element kommt bereits mit einem eigenen Layout - nämlich "display: block" - und erzeugt "ungefragt" über und unter sich einen Zeilenvorschub und dehnt sich auf 100% aus.
Leutz, so gut wie alle HTML-Elemente haben ein eigenes rudimentäres Layout, das ihnen die Browser mitgeben. Im Firefox kann man diesen CSS-Code sogar angucken, wenn man resource:///res/html.css in die Adresszeile eingibt. Und da steht nicht nur "div { display: block }", sondern auch ul { list-style-type: disc; }" und - tja - "table { display: table; }". Ja, was denn sonst?
Wie soll denn eine Webseite ohne Stylesheets noch lesbar sein, wenn ihnen die Browser nicht zwangsweise ein bisschen Layout mitgeben? Es wird in den Spezifikationen nämlich ausdrücklich gefordert, dass eine HTML-Datei auch dann lesbar sein muss, wenn die darin verlinkten externen CSS- oder JS-Dateien nicht verfügbar sind bzw. Stylesheets abgeschaltet sind. Aus diesem Grunde sind sogar in den HTML-Strict-Varianten Attribute wie "width", "align" und "border" für Tabellen bzw. Zellen noch erlaubt. Irgendeinen Grund muss es haben, dass es sogar extra Elemente gibt (colgroup, col), deren einzige Aufgabe es ist, eine Tabelle zu *layouten*. Auch Elemente wie thead und tfoot greifen in das Layout ein - zumindest einige Browser drucken sie bei mehrseitigen Tabellen auf jeder Seite. - Und das alles ohne eine einzige Zeile CSS-Code.
Und was ist angesichts dessen nun so schrecklich daran, dass td-Elemente von sich aus nebeneinander stehen und gleich hoch sind?
André
Stefan ¶
27. Februar 2009, 05:05 Uhr
Ich stimme damit überein, dass wenn es um Layout-Tabellen geht, die große Propaganda-Keule rausgefahren wird.
Es wird mit unsinnigen Argumenten argumentiert, auf die Gegenargumente wird erst gar nicht eingegangen, sondern es wird schlicht und ergreifend gesagt: "Tabellen sind nicht zum Layouten gedacht. Das ist so. Punkt." - Totschlag-Argument am Ende des eigenen Verständnisses.
Auch ich beschäftige micht seit mehreren Jahren mit dem Thema und bin in der Lage sowohl CSS-Pure-Layouts, als auch Tabellen-CSS-formatierte-Layouts zu schreiben.
Ich entscheide mich aber grundsätzlich immer für das Letztere. Ja, man kann auch mit Tabellenlayouts liquide und flexible Seiten gestalten, zumeist besser als mit CSS-pure-Layouts.
Ich finde es immer wieder eine Schande wenn ich bei einem CSS-pure-Layout die Schrift vergrößern will und die Seite fällt in sich zusammen. Blöcke verschieben sich unschön, weil sie ja unbedingt floaten müssen, Texte überlagern andere Blöcke oder Texte oder sogar sich selbst, sodass sie nicht mehr zu lesen sind.
Tatsache ist nunmal, dass Tabellenzellen den z.Zt. noch unschlagbaren Vorteil besitzen, dass sie sich automatisch ihrem Inhalt anpassen, falls dieser größer sein sollte, als vorgesehen. Z.B. bei Vergrößerung der Schrift. div-Container mit CSS formatiert können dies nicht. Nicht so fkexibel.
Und alle weiteren genannten angeblichen Vorteile von CSS-pure-Layouts sind Blödsinn, es sein denn man verwendet ausschließlich die schlechtesten Tabellenkonstrukte um seine Thesen zu untermauern.
Pure-CSS-Code ist nicht immer schlanker als Tabellencode.
Fast jedes mobile Anzeigegerät kann Tabellen ohne Probleme darstellen.
Tabellen sind behinderten-gerecht, weil sie Schwer-Sehenden nicht die Möglichkeit nehmen, die Schrift größer zu skalieren.
Auch Tabellencode kann einfach zu überschauen und strukturiert erstellt werden.
Für komplexe Layouts sind Pure-CSS-Layouts in der Regel ungeeignet.
Tabellen lassen sich genauso serialisieren wie div-Container, wenn man es will.
Und jetzt kommt mir bitte niemand mit den Argument Lynx und Textbrowser um die Ecke. Ich zumindest kenne niemanden der diese Software verwendet. Und von den Leuten die ich kenne, es sind schon einige, kennt auch niemand jemanden mit einem Textbrowser.
Und selbst wenn, läßt sich die Seite, wenn man bei der Erstellung dies bedacht hat, absolut korrekt serialisiert darstellen.
Auch bei mir ist es bislang nie vorgekommen, dass das HTML-Markup einer alten Seite ganz oder auch nur teilweise übernommen wurde. Es wurde grundsätzlich neu erstellt. Meistens immer in Verbindung mit einem CMS-System.
Und das Argument: Tabellen waren nie zum Layouten gedacht ist das mit Abstand dümmste Argument welches überhaupt zu dem Thema existiert. Erstens stimmt es nicht, außer man biegt es sich selber so zurecht und zum anderen:
Computer waren nie zum Surfen im Internet konzipiert,
Mais war nie für die Herstellung von Bio-Diesel gedacht,
Viagra war niemals zur Potenzsteigerung vorgesehen,
Zahnbürsten waren auch nie dafür gedacht Milchaufschäumer zu reinigen, Bierdeckel sollten keine Tischbeine stabilisieren und mit Kaugummis sollte man nie Sprengladungen an Türen befestigen.
In diesem Sinne,
Grüße,
Stefan
Herr Gabriel ¶
27. Februar 2009, 10:44 Uhr
Zitat Stefan:
Korrekt. Und Tabellen waren nie für Layouts gedacht.
GE ¶
27. Februar 2009, 11:08 Uhr
Das stimmt ja nun nachweislich nicht. Tabellen wurden in der html3-Spezifikation nur zu einem einzigen Zweck eingeführt: Inhalte übersichtlich in Zeilen und Spalten angeordnet auf den Bildschirm zu bringen.
Und weil das auch beim Layouten oft so gewünscht wird, wurden die Tabellen in der html3-Spezifikation auch ausdrücklich zum Layouten empfohlen. Das kann man auch heute noch nachlesen.
Erst in der html4-Spezifikation wird davon abgeraten, wegen eventuellen Problemen auf diversen Ausgabegeräten.
Das ist nun aber auch schon wieder ein paar Jahre her, auch die "diversen Ausgabegeräte" haben sich weiterentwickelt. Und die Programmierer dieser Ausgabegeräte orientieren sich an der Realität und nicht an den Ansichten von Webdesignern, die die Standards in ihrem eigenen Sinne auslegen.
Herr Gabriel ¶
27. Februar 2009, 11:39 Uhr
Zitat GE:
Du meinst, Leute wie du werden von den Programmierern nicht ernst genommen? Schade eigentlich.
Das Ding mit den Empfehlungen in alten Spezifikationen ist nämlich leider folgendes: damals wusste man es nicht besser. Denken wir doch mal an Dinge wie Frames, die damals ohne Ende benutzt wurden. Eben weil man es nicht besser wusste.
GE ¶
27. Februar 2009, 11:57 Uhr
@ Herr Gabriel
Du hast geschrieben:
"Und Tabellen waren nie für Layouts gedacht."
Und das ist eindeutig falsch, egal, wie lange das her ist. Hier steht es geschrieben:
http://www.w3.org/MarkUp/html3/tables.html:
"Borderless tables are useful for layout purposes ..."
Herr Gabriel ¶
27. Februar 2009, 12:22 Uhr
@GE:
Siehe:
Zitat Herr Gabriel:
GE ¶
27. Februar 2009, 12:40 Uhr
Naja, ich will ja niemanden überzeugen, ich layoute ja selbst nicht mehr mit Tabellen. Ich bin nur für eine offenere Sichtweise.
Ich bin übrigens schon gespannt auf die Zukunft mit 4 Boxmodellen in CSS3 (content-box, padding-box, border-box und margin-box).
Wenn ich an die vielen Anzeigeprobleme der verschiedensten Browser (und bei weitem nicht nur im IE) bei nur EINEM Boxmodell denke, wird mir beim Gedanken an eine Zukunft mit 4 Boxmodellen schon ganz übel.
Browser A hat ein Problem mit padding-box, Browser B versagt bei border-box, Browser XYZ ...
Deshalb habe ich mir einen eigenen Umgang mit den Boxmodellen angewöhnt, nämlich die Trennung von float, width und clear (äussere Box) und padding, margin, border und allem anderen (innere Box). Diese Art der Verschachtelung dürfte bekannt sein. Nur so ist das Layout weitgehend browser- und zukunftssicher.
Ein schlankeres und semantischeres Markup gegenüber der Tabelle erreiche ich so aber auch nicht.
Stefan ¶
28. Februar 2009, 04:09 Uhr
Zitat Herr Gabriel damals wusste man es nicht besser:
Aber du weißt es besser?
Ich sag ja, auf Argumente wird nicht eingegangen, es werden nur Totschlagfloskeln aufgesagt.
Schade eigentlich.
Grüße,
Stefan
Markus ¶
28. Februar 2009, 11:11 Uhr
Wie soll man Leuten gegenüber argumentieren, die HTML3 (!!!) als Killer-Argument heranziehen? Sowas kann man (ich) nicht ernst nehmen, sorry...
GE ¶
28. Februar 2009, 11:48 Uhr
Zitat Markus:
Das ist ja lächerlich!
Ich habe das niemals als Killer-Argument herangezogen. Ich habe lediglich die Aussage widerlegt, dass Tabellen "nie für Layouts gedacht" waren. Das stimmt eben ganz einfach nicht.
Oder wie würdest Du "NIE" interpretieren? Fängt Deine Zeitrechnung erst mit html 4.01 an?
Stefan ¶
28. Februar 2009, 16:18 Uhr
Zitat Markus:
Und wieder wird nicht auf die Argumente eingegangen.
Was ist denn los?
Ich finde es teilweise schon anmaßend, entscheiden zu wollen, was wofür gedacht war und was nicht. Obwohl dies nun wirklich keine Rolle spielt.
Es vollkommen egal wofür Tabellen ursprünglich gedacht waren, obwohl mein Vorredner natürlich recht hat.
Die Vorteile der Zellen-Anpassung sowohl in der Breite als auch in der Höhe sind einfach vorhanden.
Was ich z.B. nicht ernst nehmen kann ist blinder Gehorsam / Glaube an eine Ideologie, weil irgendwer meint es müsse so sein.
Jeder sollte das benutzen was ihm dienlich ist ohne von kleinkarierten Fanatikern verteufelt zu werden.
Wenn ich floats brauche dann verwende ich diese.
Wenn ich Tabellenzellen brauche dann verwende ich diese.
Denn mir ist es einfach wichtig, dass man meine Seite mit beliebiger Schriftgröße und variabler Anzeigebreite betrachten kann.
Und wenn ich unbedingt eine Nur-Textversion benötige, dann filtere ich per php alle tags aus und voila, der Text ist serialisiert für jeden (vor) zu lesen.
Mann muss diese Serialisierung nur von Anfang an bedenken.
Grüße,
Stefan
Herr Gabriel ¶
28. Februar 2009, 19:18 Uhr
Hier geht es nicht um irgendwelche absurden Ideologien. Hier geht es darum, gewisse Standards einhalten zu wollen. Und dazu gehört nunmal, Tabellen nicht mehr für Layoutzwecke zu missbrauchen.
Sehen wir uns http://is.gd/lePe an und lesen folgendes:
Auf http://is.gd/lePm erfahren wir:
Oder hier http://is.gd/lePw lässt sich sich ebenfalls interessantes lesen:
Das kann man ewig so weiterführen.
Persönlich habe ich absolut nichts gegen Tabellen, solange sie dazu benutzt werden, um Informationen an den Benutzer weiterzugeben und sie von jeglicher Designfunktion getrennt sind.
Ich meine, alleine die Tatsache, dass man bei einer Layout-Tabelle freien Raum auf einer Webseite immernoch definieren muss, zeigt doch, wie dämlich die ganze Sache ist, oder?
André ¶
28. Februar 2009, 21:08 Uhr
Ich hab gerade mal getestet, wie weit die Unterstützung von display: table/table-row/table-cell inzwischen gediehen ist. – Gegeben sei ein HTML-Gerüst aus html, head und body sowie einem ul-Element mit li-Tags als Hauptnavigation links und einem div-Element für den Content-Bereich rechts. Der prinzipielle CSS-Code sähe so aus:
html { display: table; }
body { display: table-row; }
ul, div { display: table-cell; }
li { display: block; }
Ein feines 2-spaltiges Layout bauen daraus: Safari 3, Netscape 7.2, Firefox 3, Opera 9.5, Camino 1.6. MSIE 7 (und sicherlich auch IE 6) ignoriert die Stylesheets komplett. Mit Conditional Comments wird dem MSIE das übliche float- oder position-Gedöns übergeholfen.
Nun sage noch einer, Tabellen-Layouts seien komplex.
André
Stefan ¶
28. Februar 2009, 23:19 Uhr
@Herr Gabriel
Das ist doch schlicht und ergreifend bla bla was du da schreibst.
Aha, sollten sie also? Weil wer es nochmal sagt?
Und nein, man kann Tabellenzellen-Eigenschaften NICHT durch CSS nachbilden. Zumindest nicht im IE, der wieviel % Marktanteil nochmal hat? 70? Aber Hauptsache ideologisch korrekt, ob 70% eine andere Darstellung erhalten juckt niemanden, was?
Nochmal zum Mitpinseln: CSS kann Tabellenkonstrukte NICHT ersetzen. Warum habe ich mehrfach geschrieben. Aber auch auf die Gefahr hin mich zu wiederholen: Eine Tabellenzelle passt sich dem Inhalt an, ein CSS-formatierter-div-Container tut das nicht.
Das kann doch jetzt nicht so schwer zu verstehen sein, oder?
Meine nicht. Ich rede hier auch nicht von dem schlechtesten anzunehmendem Konstrukt, wie es offenbar in dem Zitat getan wird. Tabellen != Tabellen.
Alles was du hier bringst sind Statements von irgenwelchen Leuten, die meinen sie brauchen keine Tabellen für ihre Konstrukte. Das ist schön und gut so. Nur sind es keine Argumente warum man bei bestimmten Anforderungen auf Tabellen verzichten soll, sondern einfach nur persönliche Arbeitsweisen.
Grüße,
Stefan
Stefan ¶
1. März 2009, 00:10 Uhr
@Herr Gabriel
Nachtrag:
Das stimmt nicht. Denn Layout-Tabellen gehören nunmal auch zum Standard. Man sollte mit diesen Begriff auch nicht leichtfertig um sich werfen, nur weil es gerade anscheinend passt um seine schwachen Argumente zu untermauern.
Falsch! Oder die Mär begonnen mit "Es war einmal". Firefox 3 (als Beispiel) rendert durchaus Tabellen wenn sie noch nicht vollständig geladen sind.
Zumindest meine.
Grüße,
Stefan
Markus Thömmes ¶
1. März 2009, 01:45 Uhr
Super Stefan! Auf der einen Seite sagst du, dass 70% den IE nutzen und auf der anderen Seite das Firefox 3, der deutlich weniger Marktanteile hat, anscheinend anders rendert.
Und _natürlich_ sind deine Tabellen anders als irgendwelche Tabellen! Wenn ich den Autor als "Stefan" im Head definiere schmeissen alle Browser natürlch sämtliche Rendering-Eigenschaften über Bord und machen was ganz anderes.
Zu den Standards: So ist das also so das *Layout*-Tabellen zum Standard gehören? Dann geb mir doch bitte den Abschnitt aus der W3C Spezifikation in der es heisst, man solle doch bitte veraltete Techniken benutzen und sich gegenüber der Pro-Argumente von CSS absolut blind stellen.
Es ist hier wohl noch nicht angekommen, dass sich die sogenannten "Webdesigner" mehr an den Entwicklern zu orientieren haben um sauberen und barrierefreien Quellcode zu gewährleisten. Wenn dir das mit CSS zuviel gefrickel ist machst du irgendwas falsch. Ich für meinen Teil hab noch jedes Layout einwandfrei umgesetzt bekommen.
Stefan ¶
1. März 2009, 03:37 Uhr
Du hast mich leider nicht verstanden.
Ich sagte dass FF3 Tabellen auch schon vorher aufbaut. Nicht mehr nicht weniger.
Zum Thema Standard: Das hast du leider auch nicht verstanden. Schade.
Auf keines meiner Argumente gehst du ein und wiederholst einfach nur aufgesagte Phrasen.
Du bekommst ein Layout wie meines nicht ohne Tabellen hin. Nicht wenn du im FF unter Ansicht/Zoom/Nur Text zoomen einstellst. Und genau darum geht es hier.
Aber es ist müssig ständig auf Phrasendrescher zu antworten, die die Vorteile, nämlich die Anpassung von Tabellenzellen an ihren Inhalt, bewusst ignorieren.
Und auch mit dem letzten hast du unrecht. Ein Webentwickler / Webdesigner / Webworker hat sich an den Kunden zu orientieren, nicht an irgendwelchen fadenscheinigen Ideologien.
Grüße,
Stefan
Stefan ¶
1. März 2009, 04:15 Uhr
Nachtrag:
Ich habe nie behauptet dass irgendetwas zuviel "Gefrickel" ist. Ich verwende das was ich brauche. Pure-CSS genügt aber meinen Ansprüchen nicht und ist leider zu unflexibel.
Herr Gabriel ¶
1. März 2009, 09:08 Uhr
Wenn ich mir den Quellcode deiner verlinkten Seite so anschaue, wird mir schon ein bisschen schlecht, ob der ganzen conditional-comments darin.
Sollte diese Seite wirklich von dir gemacht worden sein: Hut ab. Schlechter gehts wirklich nicht mehr.
Aber bevor du jetzt kommst mit "hier wird wieder nicht auf Argumente eingegangen":
Geh mal zu http://csscreator.com/ und vergrößer den Text mal nach Lust und Laune. Du wirst erstaunliches feststellen. Nämlich dass sich jeder div-container seinem Inhalt anpasst und nirgends das Design zerhackstückelt wird.
Markus Thömmes ¶
1. März 2009, 12:22 Uhr
Ohdoch ein Layout wie deines bekomme ich sehr wohl mit purem CSS hin.
Ausserdem: Deine Seite wächst auch bei "Nur Text zoomen" in die Breite! Das ist nicht zweck der Übung Meister. Peter's Blog macht das zum Beispiel nicht.
Ein Webdesigner sollte niemals blind das umsetzen, was der Kunde ihm sagt, wenn er genau weiss, dass das am Ende schlechte Ergebnisse bzgl. des Codes liefern MUSS. Und genau das ist dein Tabellencode.
Stefan ¶
1. März 2009, 14:27 Uhr
Zitat Herr Gabriel
Sorry, aber wieder nur bla bla.
Wird langsam zur Gewohnheit, oder?
Erstens behauptest du: Sclimmer gehts nimmer.
Ach ja? Kannst du das auch praktisch belegen? Nein? Dann solltest du sowas auch nicht behaupten.
Zweitens bin ich zu der von dir verlinkten Seite gegangen, habe den Text vergrößert und voila, er überlagert sich dahingehend selbst, dass die Seite nicht mehr zu gebrauchen ist. Und das soll jetzt ein gutes Beispiel sein? Vielleicht lässt sie sich von einem Screenreader gut vorlesen, aber wenn man den Schriftgrad auf ein Maß erhöht, welcher notwändig wäre um die Seite schwer Sehenden zugänglich zu machen versagt sie.
Klasse!
Aber irgendwie scheint es mit sinnlos mit dir zu diskutieren. Du willst es nicht verstehen. Schade.
Div-Container passen sich ihrem Inhalt nicht an. Wenn du jetzt was Gegenteiliges behaupten willst, dann hast du, sorry, einfach keine Ahnung von der Materie.
Grüße,
Stefan
Markus Thömmes ¶
1. März 2009, 14:47 Uhr
Achso! Deshalb zieht mein Layout sich auch nicht nach unten, wenn ich mehr Text einfüge? Ja ne is klar.
Stefan ¶
1. März 2009, 14:56 Uhr
Zitat Markus Thömmes
Ich behaupte: Nein.
Sie wächst in die Breite? Ja, genau das war beabsichtigt. Kein Text überlagert den anderen. Sie wächst soweit wie es dafür nötig ist. Das war der Zweck, Meister. Und das bekommt man so mit reinem CSS nicht hin. Würde ich Peters Blog größer zoomen, wäre die Seite ab einer gewissen Größe auch hier nicht mehr zu gebrauchen.
Auch du behauptest, dass der Code schlecht ist, ohne es begründen zu können. Beispiele bitte, wo die Seite nicht richtig angezeigt wird.
Nebenbei bemerkt habe ich nur eine zentrale XHTML-Datei, da ich ein eigens geschriebenes CMS verwende.
Es wäre für mich auch überhaupt kein Problem, alle Informationen zu liniarisieren, Grafiken auszufiltern, etc ... bei Verwendung entsprechender Anzeigesoftware. Nur ist das nicht notwendig.
Ich habe dir ja gerade auch das Ziel des Projektes dargelegt. Es war übrigens keine Vorgabe von einem Kunden, sondern mein eigenes Projekt.
Grüße,
Stefan
Stefan ¶
1. März 2009, 15:11 Uhr
Zitat Markus Thömmes:
Dann habe ich das etwas falsch dargestellt.
Natürlich wachsen div-Container in ihrer Höhe, wenn entsprechen mehr Text oder Zeilenumbrüche vorhanden sind.
Float-(und nur float!)Container wachsen auch in ihrer Breite.
Aber sie haben keinen Einfluss auf ihre links und rechts benachbarten Container in Höhe, sowie auf die oben und unten benachbarten Container in ihrer Breite.
Sprich: Es fehlen die Zusammenhänge die notwendig sind, um ein mehr oder minder grafisches Layout zu erhalten.
André ¶
1. März 2009, 22:24 Uhr
Wenn wir von Layouttabellen mal kurz absehen könnten und nur mal die Fähigkeiten von Tabellenzellen mit denen von div-Elementen vergleichen, fällt auf, dass wir für einiges, was uns "weggenommen" wurde, keinen gleichwertigen Ersatz bekommen haben.
Eines hat Stefan schon genannt: es fehlt (von display:table-* mal abgesehen) eine Möglichkeit, div-Elemente via CSS dazu zu zwingen, aufeinander Bezug zu nehmen, wie es Tabellenzellen von sich aus tun. Und zwar so, dass man das im CSS-Quellcode auch sehen kann; dass also zwei nebeneinander liegende Divs nicht einfach nur beide 100 Pixel hoch sind, sondern dass sie explizit gleich hoch sein sollen. Auch das verstehe ich unter semantischem Code.
Desweiteren fehlt ein funktionierendes vertical-align: middle, bottom, baseline usw. für Block-Elemente. Pseudozentrierungen oder "-bottomisierungen" mit padding oder line-height offenbaren sich spätestens dann als Blendwerk, wenn der Text in nebeneinanderliegenden Boxen gezoomt wird und der Text in einer der Boxen umbricht, also mehr Zeilen hat als der Text in den anderen Boxen. Und auch hier: von Semantik keine Spur.
Man kann es nun drehen und wenden wie man will, aber Tabellen beherrschen das seit Netscape 2. Aber wenn man Tabellen für bestimmte Anwendungsgebiete als unerwünscht brandmarkt, dann ist es nur recht und billig, gleichwertigen Ersatz zu liefern. - Wenn nun also jemand sagt, die Macher von HTML 3 wussten es nicht besser, dann kann ich nur sagen: daran hat sich aber bis heute nichts geändert.
Es gibt noch ein paar andere Sachen, die ich an der CSS-Spezifikation für unlogisch oder zumindest unplausibel halte. Ich sage nur: clear.
André
Herr Gabriel ¶
2. März 2009, 11:08 Uhr
Was ist an
clear:denn unlogisch oder unplausibel? Und was verstehst du unter semantischem Code?GE ¶
2. März 2009, 13:13 Uhr
Hallo, Ihr Streithähne,
habe mich mal ein wenig kundig gemacht und folgendes auf selfhtml zum Thema display:table & Co. gefunden:
"Speziell für die Erzeugung von Tabellen mit Nicht-Tabellen-Elementen stehen weitere Angaben zu display zur Verfügung. Die entsprechenden Angaben lassen sich allerdings auch auf entsprechende HTML-Tabellenelemente anwenden. Gedacht sind sie aber eher für die tabellarische Darstellung von XML-Daten. Denn XML kennt kein Handling, um Daten als tabellarisch auszuzeichnen. Das muss die Style-Sprache übernehmen, mit deren Hilfe die XML-Daten angezeigt werden. In CSS hat man die display-Eigenschaft zu diesem Zweck auserkoren"
Wer also display:table & Co. verwendet, missbraucht genauso wie bei einer richtigen html-Tabelle eine Tabelle zu Layout-Zwecken, nur eben eine XML-kompatible Tabelle.
Auch display:table, display:table-row & Co. sind keinesfalls zu Layout-Zwecken erschaffen worden, sondern zur XML-kompatiblen Darstellung von tabellarischen Daten.
Die Syntax wird genauso aufgebaut wie bei einer html-Tabelle, nur eben mit DIVs und entsprechenden Klassen, somit ist die Anzeige nicht im (X)html definiert, sondern im Stylesheet.
Das entspricht zwar der Forderung nach Trennung von Inhalt und Layout, aber im Grunde werden auch hier (X)html-Elemente in Verbindung mit css-Eigenschaften für einen Zweck missbraucht, für den sie ursprünglich nicht gedacht waren, nämlich für Layout-Zwecke.
Also, wenn ich schon eine Tabelle für bestimmte Layout-Anforderungen "missbrauche", dann doch lieber eine Tabelle, die auch von Browsern dargestellt wird, die diese css-Eigenschaften nicht interpretieren.
Und mit solchen Browsern werden wir wohl noch die nächsten 3-5 Jahre leben müssen, denn auch folgendes habe ich auf der oben verlinkten Seite (selfhtml), ein paar Zeilen weiter, gefunden:
"Die Angaben zu den Tabelleneigenschaften werden von Netscape 6.0 interpretiert, vom Internet Explorer jedoch auch in der Version 7 noch nicht."
Herr Gabriel ¶
2. März 2009, 13:32 Uhr
Persönlich habe ich noch keine Seite gesehen, bei der jemand
display: table-rowoder ähnliches benutzt hat.GE ¶
2. März 2009, 14:09 Uhr
Zitat Herr Gabriel:
Hallo Herr Gabriel,
ich auch nicht. Die Zeit ist ja auch noch gar nicht reif dafür. Aber schon, wenn du die ersten 10 Kommentare hier liest, wirst Du feststellen, dass das die Alternative der Zukunft sein soll für Layouts mit Tabelleneigenschaften (Layout in Zeilen und Spalten).
Das Thema
display:table& Co. zieht sich ausserdem schon seit geraumer Zeit durch die WebdesignBlogs. Das Thema "Layouttabellen" war ja für lange Zeit aus dem Focus und ist eigentlich erst mit der Diskussion dieser css-Eigenschaften wieder ins Rampenlicht geraten.Vielen Standardistas scheint aber eben nicht klar zu sein, dass mit
display:table& Co eben auch eine Tabelle missbraucht wird, wenn diese Eigenschaften zu Layout-Zwecken eingesetzt werden.Genaugenommen habe ich das auch nur "geahnt", bis ich das Thema mal gegoogelt habe und vorhin auf selfhtml mal eine richtig gute Erklärung gefunden habe.
Vorher war mir völlig unklar, warum man etwas funktionierendes (html-Tabelle) durch ein div-css-Konstrukt ersetzen will. Die XML-Kompatibilität ist eine einleuchtende Erklärung.
Gleichzeitig habe ich aber auch verstanden, dass es sich bei diesem div-css-Konstrukt genauso um eine Tabelle handelt wie bei einer richtigen html-Tabelle, also ursprünglich nicht zum Layouten gedacht.
So gesehen habe ich im Verlauf dieser Diskussion mal wieder was gelernt, deshalb mag ich solche Diskussionen, wenn sie sachlich geführt werden.
André ¶
2. März 2009, 22:23 Uhr
Zitat Herr Gabriel:
Oftmals wird clear nur verwendet, damit ein Block die darin befindlichen floatenden Elemente umschließt. Da gibt es nun die abenteuerlichsten Konstruktionen, um diese möglichst ohne zusätzliches Markup hinzubekommen, u.a. mit overflow, position oder float. Was wäre nun dabei gewesen, eine Style-Anweisung zu schaffen, die das ohne unerwünschte Nebenwirkungen hinbekommt und der man auf den ersten Blick ansieht, was sie tut?
Wobei wir da auch gleich bei semantischem Code wären. Die Anweisungen overflow, position, float und auch clear sagen nicht aus, dass der Programmierer damit gewollt hat, dass die Box die darin enthaltenen Elemente umschließt. Sie sagen zunächst lediglich aus, dass der Übersatz, die Position und der Umfluss der Box damit geregelt wird (bei clear sogar nur das, was sich in der Box befindet - über die Box selber wird damit überhaupt nichts ausgesagt). Dass damit eigentlich nur das Umschließen gewollt wurde, kann man aus diesen Anweisungen nicht folgern, zumal alle genannten Anweisungen noch Wirkungen haben, die über das Umschließen ja nun erheblich hinausgehen (im Grunde ist das Umschließen nur eine Nebenwirkung).
Klarer und wie gesagt nebenwirkungsfrei wäre eine Anweisung, deren Name schon sagt, was sie tut. Mir war ohnehin noch nie klar, welchen Nutzen es haben soll, dass eine Box in sich zusammenfällt, sobald etwas in ihr floatet. Ich kenne niemanden, der das je gebraucht hätte, ich sehe nur all die unästhetischen und uneleganten Konstrukte, die diesen Effekt wieder rückgängig machen sollen. Es hat immer einen unguten Grund, wenn sich für ein Problem ausschließlich hässliche Lösungen finden.
André
Markus ¶
3. März 2009, 08:05 Uhr
@ André
Ganz abgesehen von der Diskussion: Ich bin mir nicht sicher, aber wenn ich dich richtig verstanden habe, verwechselst du glaube ich "semantisch" und "generisch". Semantik würde ich nur auf HTML-Code anwenden (ganz simpel: Ein Absatz ist durch das <p> gekennzeichnet, Überschriften durch <hX> etc. pp.).
Generischer CSS-Code hingegen bedeutet, dass Klassen mit eindeutigen Namen für ihr jeweiliges Verhalten bezeichnet werden (z.B. .align-left). Wäre das nicht zumindest ein Ansatz, einfach diese Klassen einzusetzen, um die von dir gewünschten Ergebnisse zu erreichen? Das löst zwar nicht das Problem, das du beschreibst. Aber da scheint es mir eh unwahrscheinlich, dass die Sache auf die Schnelle zu lösen wäre ;)