Ich sehe vor allem folgende Vorteile von CSS:

* Mit CSS kann ich als Autor sagen, fuer welches Medium das Layout meiner Meinung nach geeignet ist. Z.B. kann ich fuer das Medium "Screen" ein zweispaltiges Layout (links Menue/rechts Inhalt) vorschlagen, aber eine serielle (vertikale) Abfolge (zuerst Inhalt, dann Menue) fuer kleine Bildschirme (Medium "Handheld"). Zumindest theoretisch.

Ja, eben, daher ist es ziemlich schwer, momentan so zu argumentieren. Es geht ja nicht um potenzielle, theoretische Vorteile von CSS, die niemand nutzen kann.

[CSS abschalten, Tabellen auszuschalten erfordert oft mehr Know-How]

Da gebe ich dir Recht, keine Frage. Doch erst durch einfach benutzbare und flexibel anwendbare Abschaltmöglichkeiten wie die Operas wird dieses essentielles Feature von CSS ein wirklicher, real nutzbarer Vorteil.

Natuerlich _kann_ man schlechte HTML-Seiten machen, welche ohne CSS schlecht (oder gar nicht) benutzbar sind, aber ich denke, dass die Gefahr dafuer weniger gross ist, als die Gefahr, dass man schlechte Tabellen baut.

Das eben denke ich nicht. Was hindert jemanden daran, CSS unvernünftig einzusetzen? Etwa, dass die Lernkurven von CSS steiler sind und ein gleichsam komplexes bzw. überladenes und vertracktes Layout mit CSS schwerer lösbar ist als mit Tabellen? Das würde dem Anfänger Hürden in den Weg legen und ihn zur Einfachheit zwingen statt zur Einsicht, und das hält nur solange vor, bis die Möglichkeiten von CSS erschlossen werden, insbesondere die potenziell problematischen Techniken.

Der moderate Einsatz von sauberem, einfachem Tabellenlayout für grundlegende Mehrspaltigkeit ohne Tricks mit dutzenden verschachtelten Tabellen war nie das große Problem. Wer von diesem Niveau, auf dem schon Stylesheets für fast alle Formatierungen genutzt werden, zur konsequenten Trennung von Struktur und Präsentation wechselt, wird auch brauchbare CSS-Layouts produzieren. Denjenigen, die seit jeher »klassische«, vermurkste Tabellenlayouts geschrieben haben, geht nicht plötzlich ein Licht auf, wenn sie auf CSS als Layoutmittel umstellen, und sie schreiben nicht plötzlich nur noch hochsemantisches und wohlstrukturiertes Markup, welches gekonnt mit CSS in eine anspruchsvolle Präsentation gebracht wird. Stattdessen würde aus dem murksigen Tabellenlayout ein ebenso murksiges »div-Layout« und ein Wust aus mit position:absolute-»Layern«. CSS verhindert das nicht und das »Layer«-Modell wird die Möglichkeiten des typischen Tabellenlayouters eher erweitern als ihn zu mäßigen.
Es lässt sich lediglich konstatieren, dass es momentan mehr Tabellenlayouts als solche schlechten CSS-Layouts gibt, aber das hängt eher damit zusammen, dass CSS ingesamt nicht so verbreitet ist. Kommt Verbreitung, kommt problematischer Gebrauch.

Keine offizielle Quelle gibt die Auffassung wieder, dass Tabellen in HTML nicht für Layout »gedacht« sind, [...]

OK, ich sehe, Interpretationen und eigene Formulierungen sind bei Dir nicht erlaubt.

Das ist gar nicht die Frage. Meine Meinung ist, dass sie zu nichts führen und nicht weiterbringen.

Ich werde in Zukunft ganz objektiv schreiben:

Das W3C raet in zwei Publikationen aus dem Jahr 1999 davon ab, Tabellen fuer Layout-Zwecke zu gebrauchen.

Die Kernaussage meines verlinkten Postings war eine andere, du zitierst wieder ohne Beachtung des Kontexts: *Dass* das W3C irgendwo von Tabellen abrät oder abriet, ist vollkommen irrelevant (und nicht zielführend) hinsichtlich einer Argumentation gegen Tabellenlayout; wichtig ist hingegen, *warum* von Tabellen abgeraten wird und ob diese Begründung überzeugend ist.

Das Argument beider Aussagen ist einzig und allein das besagte: Es gibt Linearisierungsprobleme. (Ich weiß nicht, was hinter dem »may present problems when rendering to non-visual media« sonst noch stecken soll, was vor allem nicht auch gleichermaßen für CSS gelten kann.) Aus heutiger Sicht ist dieses Argument wie gesagt nicht mehr haltbar bzw. äußerst schwach, weil es von überholten Verhältnissen ausgeht. Die WCAG sind sich dessen bewusst: Sie nehmen vorweg, dass die Linearisierungsprobleme eines Tages gelöst sein werden (die besagte Richtlinie 10.3).

Wenn nun jemand davon überzeugt werden soll, dass Tabellenlayout problematisch ist, bringen diese Zitate rein gar nichts. »Das W3C rät in zwei Publikationen aus dem Jahr 1999 davon ab, Tabellen fuer Layout-Zwecke zu gebrauchen.« ist an sich ein nullwertiger Beitrag zur Frage, *warum* Tabellenlayout nicht für Layoutzwecke gebraucht werden sollte. Diese Zitate vermitteln demjenigen, der sich fragt, *was* tatsächlich, wirklich und praktisch an Tabellen problematisch ist, kein bisschen Einsicht und Erkenntnis, sie erhellen die Diskussion nicht. Was die Zitate aussagen, ist nicht das, was zählt und worauf es ankommt.

Es geht mir übrigens nicht darum, deine Aussagen zu widerlegen, sondern darum, im Allgemeinen eine wasserdichte Rechtfertigung zu finden. Mir geht es um einleuchtende Gründe und Belege, nicht um Bauchmeinungen und Hörensagen-Halbwissen einerseits und das argumentationslose Zitieren von Vorschriften andererseits. Nur eine handfeste Argumentation kann überzeugen und damit ihren Zweck erfüllen, das habe ich schon in </archiv/2003/12/67615/#m387759> anklingen lassen:

»Ich finde es insgesamt viel aussichtsreicher, das heißt überzeugender, wenn auf diese Weise für CSS argumentiert wird, nicht darüber, dass das W3C angeblich font verbietet und HTML und Tabellen 'für etwas anderes gedacht' sind und nur im Sinne des Erfinders verwendet werden dürfen. Es interessiert nämlich manche (in einigen Fällen zurecht) nicht, für was eine Technik ursprünglich 'gedacht' ist, sie werden sich von Ge- und Verboten nicht beeindrucken lassen [sondern nur von der Begründung dieser], daher ist diese Argumentationsweise schlichtweg nicht effektiv.«

Aussagen wie »das W3C hat festgelegt...«, »das W3C schreibt vor...«, »das W3C hat $Technik für $Zweck gedacht« usw. sind also keine Argumente, sie lassen Hintergründe und Ursachen vollkommen außer Acht, sie *erklären nichts* und sind deshalb nicht fähig, jemanden zu überzeugen. Wir brauchen Analyse!(tm)

"Tables should be used to mark up truly tabular information ('data tables'). Content developers should avoid using them to lay out pages ('layout tables')."

Das ist eine bekannte Auffassung, die an dieser Stelle nicht begründet wird. Das einzige gegebene *explizite* Argument gegen Tabellenlayout (bzw. Tabellen im Allgemeinen und dem Rat, alle vermeidbaren Tabellen zu vermeiden, d.h. Layouttabellen) im Kontext steckt wie gesagt im Folgesatz »Tables for any use also present special problems to users of screen readers (refer to checkpoint 10.3).« bzw. unter Richtlinie 3 »it is appropriate to use the TABLE element in HTML to mark up tabular information even though some older screen readers may not handle side-by-side text correctly (refer to checkpoint 10.3)«.

Darüber hinaus handeln die kompletten WCAG von der Trennung von Struktur und Präsentation und deren Vorteilen bzw. sehen dies als Grundzusammenhang an, der eine zugängliche Seite ausmacht. Somit sprechen eher die gesamten WCAG implizit gegen Tabellenlayout, weil es die Vorteile dieser Trennung konterkariert.

Aber auf einem kleinen Bildschirm/Browserfenster (z.B. 320px breit) ist man bei Layouttabellen oefter gezwungen, horizontal zu scrollen, als wenn die Elemente mit einer schlauen CSS-Loesung (eher float als position) fluessig angeordnet sind und auch untereinander rutschen duerfen.

Ohne Frage, das stimmt.
Der springende Punkt ist aber, dass CSS es *ermöglicht*, ein in diesem Sinne flüssiges Layout zu schreiben. Es *fordert* aber nicht ein solches und zieht es auch in der Regel nicht nach sich. Die Erfahrung zeigt, dass diese Möglichkeit nicht genutzt wird. Die gewöhnlichen CSS-Spaltenlayouts, wie sie als Templates von einschlägigen Sites angeboten werden (einschließlich dem W3C, siehe den letzten Absatz von </archiv/2004/1/68396/#m393249> und </archiv/2003/11/63992/#m365148>) und bereits tausendfache Anwendung gefunden haben, sind eben nicht in dieser Weise flüssig, weil sie sich ebenso an starren Konzepten orientieren wie Tabellenlayouts. Sie erzwingen die Mehrspaltigkeit ebenso und sind ebenfalls nicht (bei aktiviertem Screen-Stylesheet) bei 320 Pixel Viewportbreite und ähnlichen Einschränkungen lesbar.
Was derzeit als höchste Kunst in Sachen CSS-Design gepriesen wird (CSS Zen Garden usw.), ist hinsichtlich des Kriteriums der Anpassungsfähigkeit meist stockkonservativ (feste Breite von 760 Pixel usw.) und nicht vorteilhafter als konventionelles Tabellenlayout. Das ist insgesamt neuer Wein aus alten Schläuchen, das ist kein Fortschritt.

Daher poche ich die ganze Zeit darauf, dass der angebliche besondere Nachteil von Tabellenlayout »z.B. Leute mit kleinen Bildschirmen können Probleme damit haben« gleichermaßen auf die meisten CSS-Layouts im Umlauf zutrifft (wenn nicht sogar stärker). Es müsste nicht nur für CSS im Allgemeinen plädiert werden, sondern gleichsam für flexible/»fluide« Layouts, wozu CSS natürlich das Mittel der Wahl ist.

Wenn man dieses Layout mit einer Tabelle macht:

...oder mit einem gewöhnlichen CSS-Layout...

dann muss ein Benutzer mit einem 320px schmalen Bildschirm zuerst mal horizontal scrollen [...]

Bei einer schlauen CSS-Loesung auf einem schmalen Bildschirm wuerde dies z.B. zu: [...]
D.h. man muss "nur" vertikal scrollen, um zum Inhalt zu kommen, und dann ist saemtlicher Text ohne horizontales Scrollen lesbar.

Das ist vollkommen richtig, findet aber nahezu keine Verbreitung.

P.S. Eine amuesante "Dia-Show" zum Thema
"Why tables for layout is stupid"
http://www.hotdesign.com/seybold/index.html

Das einzige dort genannte »Argument« zu der These, warum CSS-Layout im besagten Sinne zugänglicher ist: »Visitors using screen readers (as well as those with slow connections) do not have to wade through countless table cells and spacers to get at the actual content of our pages.« (http://www.hotdesign.com/seybold/12access.html) Ich habe keinen blassen Schimmer, was damit gemeint ist - ein Screenreaderbenutzer bekommt von zahllosen Tabellen und Spacer-Gifs überhaupt nichts mit und es ist auch keine Mühe, zum nächsten Inhaltsabsatz zu springen. http://www.wdr5.de/ bspw. ist ein klassisches aufgeblasenes Tabellenlayout mit ordentlichen Verschachtelung und Blindgifs en masse, von allem merkt man im JAWS kein bisschen bzw. es wirkt sich nicht in der besagten Art aus.