Logo Adobe Certified Expert (ACE) und Adobe Certified Instructor (ACI) für Adobe Acrobat

07. Februar 2006

CSS-Layout kontra Tabellenlayout

Bild eines FragezeichensFür mich ist dieses Thema noch lange nicht abgeschlossen. Zwar sind meine Seiten hier ohne Tabellen gestaltet, aber die meisten fremden Seiten, die ich betreue oder weiter entwickle, sind nach wie vor Tabellenmonster. Und wenn ich für Kunden neue Seiten aufbauen kann, dann ist ein reines CSS-Layout meist ebenfalls nicht drin, sei es, weil es das Budget nicht hergibt, oder weil ältere Browser einbezogen werden müssen, oder weil vorhandene Teile integriert werden müssen und so weiter.

Ich werde wohl auch künftig Kompromisse eingehen: Das Grundlayout als zwei- oder dreispaltige Tabelle und alles weitere über CSS. Damit kann ich bis auf ein paar die meisten CSS-Hacks vermeiden, sorge für Stabilität auch in alten Browsern und schone das Budget meiner Kunden. Und spare mir stressende Anrufe nach dem Motto: Im Browser xy sieht die Seite aber ganz schön beschissen aus. Also, wenn Sie Ihr Handwerk nicht verstehen, müsssen wir uns jemand anders suchen ... etc. usw. usf.

Ziel ist für mich, mit minimalem Aufwand eine stabile und sehr leicht pflegbare Seite erstellen zu können, die im Idealfall auch noch zumindest grundlegend barrierefrei ist. Wobei die Barrierefreiheit im Moment ein Hobby von mir ist; zahlen tut mir das bis jetzt kein Kunde. Dieses Ziel erreiche ich im Moment noch leichter durch den (sehr sparsamen!) Einsatz von Tabellen.

Das wird sich hoffentlich bald ändern, vor allem wenn sich der IE 7 weiter verbreitet. Was ich bisher darüber gehört habe, lässt mich hoffen: er scheint zumindest die wichtigsten Fehler der alten IE-versionen nicht mehr zu haben. Aber bis er sich verbreitet hat und der IE 5 endgültig verschwindet, wird es wohl noch dauern.

Da mich das Thema sehr interessiert, habe ich in meiner Ressourcen-Rubrik die Kategorie Tabelle vs. CSS-Layout eigens dafür eingerichtet und sammle jetzt dort die interessantesten Beiträge und Links.

Von Peter am 07.02 um 12:37 Uhr. Kategorie: HTML-CSS | Lisardo-intern

Trackbacks

  1. Trackback-URL: http://www.lisardo.biz/trackback/240/GOUSIyHB/

Kommentare

  1. Kommentar von Jens Grochtdreis am 08. 02 um 09:48 Uhr:

    Warum sind Tabellenlayouts ein Kostenargument? Weil man sie jahrelang geübt hat und kann. Sie sind aber kein Ausdruck von Qualität. Wenn man also lieber schnell und mit mangelhafter Qualität arbeiten will, dann bieten sich natürlich Tabellenlayouts an. Wenn man sich hingegen fortbildet und übt, dann sind tabellenfreie Layouts auch kein Hexenwerk. Diese Seite hier beweist es. Wo ist also das Problem? Wer meint, ein Layout ohne Layouttabellen sei langsamer umzusetzen und deshalb nicht wirtschaftlich, der irrt und zeigt nur, daß er nicht auf der Höhe der Entwicklung ist. Ich persönlich biete gar keine Tabellenlayouts an. Warum auch? Es gibt keine Gründe hierfür. Es sei denn, es handelt sich um eine Intranetanwendung für Netscape 4-User.

  2. Kommentar von Peter am 08. 02 um 12:20 Uhr:

    Zunächst mal grundlegend: ich spreche nicht von einem Layout mit ineinander verschachtelten Tabellen, sondern von einem sparsamen Einsatz, das kommt in der Diskussion meist nicht richtig rüber. Also eine Layouttabelle mit z. B. drei Spalten und einer Zeile, wobei die Betonung auf eine liegt.

    Aber ein Kostenargument ist es, nicht nur wegen der mangelnden Übung (was schon zutrifft - zwangsläufig mache ich Tabellendesign schon ein paar Jahre länger). Ein wesentliches Argument sind die fehlenden Tools: CSS-Design ist Coding. Tabellendesign kann aber in Dreamweaver innerhalb von Minuten aufgebaut werden. In Golive ist es möglich, aus einem Photoshop-Entwurf ein Tabellen-Design regelrecht aus der Bildvorlage herauszuschneiden. Ich komme bei CSS-Designs allein mit dem Tippen nicht hinterher.

    Es gibt in der Praxis eine Reihe von weiteren Gründe, die von Fall zu Fall dazu führen, dass ich (mit schlechtem Gefühl) letztlich doch wieder Tabellen baue.

    1. Wenn ich eine vorhandene Webseite ausbauen oder ändern muss. Ein Redesign kommt in der Regel nicht in Frage (obwohl wir das natürlich anstreben). Ausserdem ist es problematisch, innerhalb eines Webauftritts mehrere Design-Paradigmen zu kombinieren. Man bekommt Wildwuchs, der kaum mehr zu pflegen ist. 

    2. Wenn ausser mir noch andere Personen die Seite pflegen sollen. CSS-Layouts sind in den Händen von HTML-Laien sehr fragile Objekte, ausserdem setzen diese Personen in der Regel Tools wie Dreamweaver ein. Es hat keinen Zweck, den Leuten eine Seite hinzustellen, die sie in Dreamweaver & co. nicht bearbeiten können.

    3. Einbinden von Shops und andere vorgefertigte Tools wie Pollsysteme etc. Sie basieren praktisch alle noch auf Tabellendesign. Wenn ich in diesem Zusammenhang einzelne Seiten dazubauen muss, entscheide ich mich in der Regel für die Hauptarbeitsweise, um das Designparadigma nicht zu wechseln (siehe oben).

    4. Zielgruppen. Die Zielgruppen meiner Kunden haben noch öfter alte Browser, zum Beispiel werden im Bereich Grafikdesign immer noch Macs mit OS 9 eingesetzt, mit IE 5.2 als modernstem Browser. YAML und viele andere CSS-Designs, die ich mir bereits angesehen habe, laufen nicht (meins hier schon - aber ich musste einige Kompromisse eingehen und habe lange getestet).

    5. Erfahrung. Bei einem Tabellendesign weis ich blind, was in welchem Browser funktioniert und was nicht. Soweit bin ich in CSS nicht. Da mache ich meine Erfahrungen noch auf die harte Tour.

    6. Komplexität. Eine dreispaltige Tabelle ist in jedem Browser stabil, den ich jemals in den Fingern hatte. Ein dreispaltiges CSS-Layout ist das nicht. Der Testaufwand ist um ein Vielfaches höher.

    7. CMS-Systeme. Blogsoftware ist neu und deshalb meist gut an CSS angepasst. Aber Blogsoftware ist als CMS für Unternehmen völlig ungeeignet. Die klassischen CMS-Systeme sind älter und die Anpassung des Outputs an CSS ist entweder nicht vorhanden oder nur in Teilen. Beispiel Typo3: erst seit wenigen Wochen können alle Inhaltelemente als CSS aufgebaut werden, bisher mussten barrierefreie Typo3-Auftritte auf einige Inhaltselemente verzichten.

    8. Geschwindigkeit. Ich brauche jetzt, innerhalb von wenigen Minuten eine Seite, die garantiert in allen Browsern läuft und ich habe keine Möglichkeit zu testen. In dieser Situation bin ich ziemlich oft.

    Warum versuche ich trotzdem ein CSS-Design zu erreichen? Weil darin die Zukunft liegt. Weil es flexibler ist und weil auf lange Sicht die Kosten niedriger werden. Mein Ziel ist letztlich das reine CSS-Layout, allerdings bin ich pragmatisch genug, auf dem Weg dahin einige Kompromisse einzugehen, solange sie die Benutzbarkeit der Seite nicht einschränken.

    Dass CSS-Design nicht unproblematisch ist, beweist die momentane Angst vor dem IE 7. Für viele CSS-Designer kommt jetzt eine unangenehme Phase: sie müssen nämlich die HTML-Seiten ihrer Kunden an IE 7 anpassen. Welcher Kunde wird dafür zahlen wollen? Und warum sollte er das überhaupt tun? Ich denke, viele Designer werden kostenlos anpassen müssen. Auch das ist ein Kostenfaktor.

  3. Kommentar von Boda am 05. 03 um 00:38 Uhr:

    Ein Tabellendesign ist für die meisten viel verständlicher als ein Layout mit CSS, obwohl CSS auf lange Sicht natürlich der richtige Weg ist. Der andere Punkt sind die alten Browser. Man ist da nie sicher wie die Web-Seite schlussendlich im Browerwindow ausschaut.

  4. Kommentarseite 1 von 1.
Dieser Eintrag kann nicht mehr kommentiert werden.

Aktuelle Seminartermine:

PSO-Workflow-Kompentenzen: Normgerechte PDF-Daten erstellen nach PSO
17. September 2008, Skill GmbH in Ismaning, München Mehr Infos …
Seminar: Adobe Acrobat im PDF Workflow
30. September 2008, Skill GmbH in Ismaning, bei München Mehr Infos …
Seminar: Adobe Acrobat – PDF-Prüfung und Korrektur mit PitStop
08. Oktober 2008, Skill GmbH in Ismaning, bei München Mehr Infos …

Seminarkalender abonnieren

Icon einer Kalenderdatei
Seminarkalender als .ics-Datei: Für Kalenderanwendungen herunterladen (alle Systeme)
Icon einer Kalenderdatei
Seminarkalender für iCal: Kalender abonnieren (nur Mac OS X)