Ist immer noch eine 800*600 Pixel Auflösung Pflicht?

[molily]

Momentan müsste man im Besonderen Kritik an CSS-Layouts üben, denn diese sind i.d.R. nicht einmal so anpassungsfähig wie gängige halbwegs flexible Tabellenlayouts

Nana, Mathias, hier vergleichst du schlechte CSS-Layouts mit guten Tabellenlayouts.

Genau. Denn die gängige Argumentation für CSS-Layout vergleicht reale, schlechte Tabellenlayouts mit idealen, guten CSS-Layouts. Das konnte man im Jahr 2001 noch machen, denn damals waren schlechte Tabellenlayouts verbreitet und CSS-Layouts versprachen eine rosige Zukunft mit anpassungsfähigen Layouts.
Im Jahr 2005 ist CSS etabliert und Kritik an Layouttabellen tendenziell anachronistisch, aber in puncto anpassungsfähige Layouts hat sich das Web durch den CSS-Aufschwung nicht grundsätzlich verbessert.

Für CSS-Layout wurde ordentlich Werbung gemacht, aber niemand hat jemals klipp und klar gesagt: Starre Layouts sind und bleiben starre Layouts, ob mit Layouttabellen oder CSS realisiert. Wenn ihr das Layoutmittel, aber nicht eure Layoutkonzepte ändert, wird beim Wechsel zu CSS nicht das Erhoffte dabei herumkommen. Hinsichtlich Flexibilität bleiben die Vorteile von CSS sonst nur theoretisch, CSS löst die Probleme von starrem Layout nicht automatisch. Den meisten Seitenbesuchern bleibt lediglich die Ultima Ratio, alle Autorenstylesheets gänzlich abzuschalten oder ein umstürzlerisches Benutzerstylesheet hinzuzuschalten. Abgesehen davon, dass das für das ganz normale Surfen im WWW keine praktikable Option ist – der Benutzer will, dass die Seite von selbst unter der gegenwärtigen Umgebung problemlos lesbar ist –, ist das dem Normalverbraucher sowieso unmöglich. So bringt die Trennung von Layout und Markup letztlich wenig für die Anpassungsfähigkeit.

Man kann auch bei Tabellenlayouts die Spaltenbreite in Pixeln festzementiert angeben, und man kann dies auch bei CSS-Layouts vermeiden.

Natürlich kann man das. Fakt ist, dass die meisten CSS-Layouts genausowenig wie die meisten Tabellenlayout auf festzementierte Größen verzichten.

Der Zengarden hat IMHO auch ein ganz anderes Ziel: zu zeigen, was so alles mit CSS zu machen ist. Da geht künstlerische Gestaltung vor Flexibilität und Usability. Mit versetzen einige Umsetzungen in Staunen, auch wenn da bei meinen Einstellungen mal was aus dem Rahmen fällt.

Über den CSS Zen Garden wollte ich eigentlich nicht diskutieren, dazu habe ich mich schon öfters in der Vergangenheit geäußert.

Der CSS Zen Garden will praxistaugliche, grafisch anspruchsvolle Beispiellayouts bieten. Sie dienen faktisch als Muster für eine ganze Generation von CSS-Layouts. Der Zen Garden zeigt eben nicht, »was man mit CSS so alles machen kann« – denn das ist der gängigen Argumentation zufolge auch: vielseitiges, anpassungsfähiges Design –, sondern zeigt ›nur‹, dass man mit CSS Grafikdesign auf hohem Niveau betreiben kann. Damit reproduziert der Zen Garden den ewigen Widerspruch zwischen »künstlerischer Gestaltung« und handfester Usability, anstatt ihn zu überwinden. Ja, Usability bleibt dabei auf der Strecke. Das ist bedauernswert.

Bedauernswert ist es vor allem deshalb, weil eines der gewichtigsten Argumente für CSS-Layouts die *mögliche* Anpassungsfähigkeit und im weiteren Sinne die Barrierefreiheit war und ist. Der CSS Zen Garden war Teil dieser Bewegung, die unter anderem CSS als Mittel zum Zweck der Accessibility kultivierte. Früher behauptete der Zen Garden von sich, WCAG-AAA-konform zu sein. Mittlerweile wurde die Aussage abgeschwächt und es wurde eingesehen, dass es mit den Zen-Garden-Designs und Accessibility nicht notwendigerweise gut steht.
Trotzdem ist der CSS Zen Garden nach wie vor die Referenz Nummer 1 für viele Webstandards- und Accessibility-Evangelisten, obwohl die wenigsten dortigen Beiträge vormachen, wie sich High-End-Design und Skalierbarkeit vereinbaren lassen. Schade, so etwas fehlt der Welt noch.

Mathias