Was ist so verkehrt an tabellenbasiertem Design?

27. Januar 2006 Bisher 20 Kommentare

Icon Barrierefrei Könnt ihr diese Frage auch so leiden wie ich? Für alle Leidgeplagten habe ich die Case Study meines Essays Barrierefreie Webseiten überarbeitet. So könnt ihr nun das Aussehen und auch den Quelltext einer Webseite aus Photoshop und Dreamweaver mit der barrierefreien Version vergleichen. Jetzt gibt es keine Ausreden mehr!

Den Unwissenden kann man Webstandards und den Sinn dahinter wohl nur begreiflich machen, wenn man ihnen Ihre Fehler vorhält. Doch Worte alleine verhallen. Überall verlautbaren Webentwickler Ihren Hang zu Webstandards, doch bei genauerem Hinsehen fehlen die Beispiele.

Das Vorhaben

Ich habe mit Photoshop ein Design einer neuen Webseite erstellt und diese dann auf zwei Wegen realisiert.

  • Zum einen arbeitete ich ganz normal, in dem ich die Bilder optimierte und extrahierte, und sie dann in das Template integriert hatte. HTML und CSS habe ich in Zend Studio “programmiert”. Heraus kam schlichtes, valides Markup.
  • Nun wollte ich ein Paradebeispiel für schlechtes Webdesign herstellen und hatte dafür die Besten Voraussetzungen: Ich hatte keine Ahnung, wie ich das realisiere. Ich erstellte in Photoshop Slices (ich hasse sie) und mouseover-Effekte, exportierte das Design als HTML-Seite und bearbeitete diese dann schließlich mit Dreamweaver. Was hier herauskam, kann sich jeder denken: Eine Webseite, die 90% aller Webseiten weltweit repräsentatiert.

Der direkte Vergleich

Damit wir uns nicht falsch verstehen, ich habe bei der “grauenvollen Version” nicht extra schlechtes Markup geschrieben, sondern mich ganz einfach auf die Tools Photoshop und Dreamweaver verlassen. Einen Fehler, den ich schon seit vielen Jahre anprangere, schon lange bevor überhaupt jemand von Webstandards geredet hatte.

Zusammengefasst

Vergleicht man nun den Quelltext beider Seiten, wird schlagartig klar, wo die Fehler in der “grauenvollen” Version liegen. Der Quelltext erschlägt einen regelrecht, die Menübilder sind alles andere als Wartungsoptimiert.
Interessant wird die barrierefreie Version natürlich erst, wenn ihr die Stylesheets abschaltet oder die Seite einfach mal über die Druckfunktion eures Browsers ausdruckt.

Mehr Informationen zur Vergleichseite findet ihr hier

Update: Google analyisiert den Quelltext. So hat die Arbeitsgruppe Web Hypertext Application Technology (WHAT WG) festgestellt, dass semantisch strukturierte Inhalten kaum anzutreffen sind. Das ist soweit nichts neues. Was mich schockiert, ist die Meldung, dass WHAT WG an HTML 5 arbeitet und dort häufig genutzte proprietäre Erweiterungen oder Stylesheet-Klassennamen standardisieren möchte. Und das font-Tag ist doch noch nicht ausgestorben.

Dieser Artikel wurde am Freitag, 27. Januar 2006 um 11:50 Uhr von macx geschrieben und unter Intern abgelegt. Du kannst die Antworten zu diesem Beitrag via RSS 2.0-Feed beobachten.

Die Kommentarfunktion wurde für diesen Artikel deaktiviert. Möchtest du dennoch deinen Senf hinzufügen, schick mir bitte eine Nachricht

Kommentare

Einen eigenen Kommentar schreiben

  1. 1 SilentWarrior schrieb am 27. Januar 2006 (14:01 Uhr)

    DANKE! Endlich mal jemand, der etwas gegen die Verblödung der Web-Developer-Zunft tut (und nicht wie SELFHTML diese noch fördert).

  2. 2 Markus Stange schrieb am 27. Januar 2006 (18:01 Uhr)

    Sehr schön. Solche Case Studies sind unbedingt nötig, wenn man Die Bösen von Webstandards überzeugen will.

    Was genau hast du denn daran auszusetzen, dass in HTML 5 häufig genutzte proprietäre Erweiterungen oder Stylesheet-Klassennamen standardisiert werden? Meiner Meinung nach ist das ein sehr sinnvoller Schritt. Auch der Rest von HTML 5 sieht sehr gut aus – ein gescheit definiertes error handling ist unbedingt nötig.

    Das einzige, was ich daran auszusetzen hätte, wäre vielleicht das Element small. Dabei stört mich aber nicht die Funktion des Elements an sich (die Beispiele hören sich ja gut an – alles Dinge, die auf den ersten Blick nicht unbedingt ins Auge fallen sollen), sondern viel mehr der Name. “small” klingt ja schon eher präsentativ. Allerdings fällt mir kein besserer Name ein, der diese semantische Bedeutung beschreiben könnte.

  3. 3 macx schrieb am 28. Januar 2006 (09:01 Uhr)

    Die Heise-Meldung klang für mich so, als wenn die WHAT WG sich den von Google-gesammelten Code ansieht und sich davon das meist genutzte raussucht. Da die meisten Entwickler aber überhaupt noch nie was von struktureller Programmierung gehört haben, fürchte ich die ßbernahme von weniger logischen Auszeichnungen.

  4. 4 Markus Stange schrieb am 28. Januar 2006 (15:01 Uhr)

    Ah, die Heise-Meldung hatte ich noch gar nicht gelesen. Du hast recht, da klingt das wirklich so. Aber ich glaube, in diesem Fall braucht man keine Angst zu haben, da hinter dem ganzen offensichtlich Hixie steckt, und der hat ja nun wirklich genug Ahnung davon.

  5. 5 Stefan schrieb am 28. Januar 2006 (19:01 Uhr)

    “Und das font-Tag ist doch noch nicht ausgestorben.”

    Kein Wunder, wird ja auch in der Schule gelehrt.

    das wurde uns ausgeteilt: http://mitglied.lycos.de/emperor01/HTML-Frame.htm

    Ich muss eingestehen, dass Murks-HTML inuitiver und einfacher zu erlernen ist, auch wenn gute Webseiten damit zu schreiben eine Zumutung ist.

    Aber viel eher hat die Lehrerin keine Lust sich ernsthaft mit HTML und besonders CSS auseinanderzusetzen.

  6. 6 macx schrieb am 28. Januar 2006 (19:01 Uhr)

    Das Problem mögen in der Tat die Lehrer sein, doch dass Murks-HTML einfacher zu lernen ist, wage ich zu beweifeln. Denn: Wenn du weniger tippen musst, musst du auch weniger lernen. Daher wird sauber strukturierter Coder einfacher sein. Es sei denn, du nutzt diese Autorenprogramme wie Dreamweaver. Dort ist eh Hopfen und Malz verloren. Leider.

  7. 7 Knut Karnapp schrieb am 30. Januar 2006 (08:01 Uhr)

    Man könnte jetzt eine Grundsatzdiskussion lostreten wie fähig denn die Lehrer sind. Wenn ich mich an meine Infolehrerin denke kann ich nachträglich nur den Kopf schütteln, wie ich es auch schon damals getan habe. Anfang der 11 hab ich mich gefreut, dass HTML auf dem Lehrplan der 12 stand. Als es dann soweit war und ich gesehen habe, was das laut Lehrplan beinhaltet hab ich meine Mitarbeit eingestellt und meine Unterrichtsaktivität dem Surfen im Web gewidmet, meine Punkte hatte ich schon in der 11/1 und 11/2 gesammelt. Bei vielen, nicht bei allen, Lehrern fehlt einfach der grundsätzliche Wille sich durchgehend weiterzubilden, wie das z.B. bei Professoren der Fall ist.

  8. 8 tekton schrieb am 31. Januar 2006 (14:01 Uhr)

    also ich weiß zwar nicht warum macx hier so massiv auf den Dreamweaver (DW) negativ abstellt. Aber mit dem DW ist es genau wie mit vielen anderen Dingen auch … man muß natürlich damit umgehen können… und dann kann man mit DW sehr wohl valides Markup generieren …

  9. 9 macx schrieb am 31. Januar 2006 (14:01 Uhr)

    Bei der ganzen Diskussion geht es um die Kentnisse, nicht um die Programme. Im Negativbeispiel habe ich mich absichtlich auf die o.g. Programme verlassen, um dem Gros aller Webseiten weltweit zu entsprechen. Und genau hier setze ich an. Ich zeige auf, dass es andere Wege gibt, die zum gleichen Ziel führen.
    Ohne Know How geht es eben nicht. Und ohne den Faktor Mensch kann kein einziges Programm oder Content Management System barrierefreie Webseiten erstellen – auch Dreamweaver nicht.

  10. 10 harald schrieb am 16. August 2006 (16:08 Uhr)

    Hi!

    Also in dieser Case stud. is natürlich eindeutig klar was besser is, aber gibt es irgendwo vielleicht zusammengeschrieben warum man keine Tabellen verwenden soll? Ich verwende zwar Tabellen auch nur mehr im content-Bereich als für die Benutzer ersichtliche Tabellen und programmiere die Navigation und das Design über divs und zu 90% eigentlich über css, aber ich kann andere nocgh nicht wirklich davon überzeugen, denn laut W3C darf man Tabellen ja ganz normal nutzen…

    Das oben angesprochene font-tag is auch so ein fall, das findet man sogar in diversen Computerzeitschriften (wovon fast alle eh zum vergessen sind)! habt ihr hier vielleicht auch etwas zum herzeigen?

    Danke
    Harald

  11. 11 Roland schrieb am 16. August 2006 (16:08 Uhr)

    Was habt ir denn gegen selfhtml, hab bis jetzt noch nicht viel damit zu tun gehabt (ich hab bis jetzt höchstens selfphp genutzt)?

    lg
    Roland

  12. 12 macx schrieb am 16. August 2006 (17:08 Uhr)

    @Harald
    Wenn dein Kunde möchte, dass seine Webseite auf jedem Medium zu betrachten ist (unterschiedlichste Browser auf unterschiedlichsten Systemen, Handy, PDA, Fernsehen und zukünftige Medien, die wir noch nicht kennen), und wenn dein Kunde mehr Kunden haben möchte (ältere Menschen, die den Schriftgrad erhöhen, Menschen mit Leseschwäche), und wenn dein Kunde möchte, dass die Seite gut von Suchmaschinen indiziert werden kann (was nur bei einer klaren HTML-Struktur gut funktioniert), dann solltest du auf Webstandards setzen.
    Weitere Argumente erhälst du regelmässig jede Woche Montag im Technikwürze-Podcast

    Zum font-Tag: in XHTML gibt es das nicht mehr, kann also nicht eingesetzt werden. Und der W3C sagt auch, dass Tabellen nur für tabellarische Inhalte verwendet werden sollten, wenn man die Barrierefreiheit anstrebt.

    Kurz zusammengefasst: Es gibt kein einziges Argument gegen Webstandards, sondern tausende, warum es diese nicht unterstützen sollte. Wenn du Webseiten herstellst, mach sie alle sauber und gut ist. Ich sag: Es ist einfach sauberes Handwerk.

  13. 13 macx schrieb am 16. August 2006 (17:08 Uhr)

    Mehr Informationen zur Barrierefreiheit und dessen Pro-Argumente im meinem Essay

  14. 14 Harald schrieb am 20. August 2006 (07:08 Uhr)

    Es gibt diverse Scripte z.B. als CMSs oder Webshops, in denen Tabellenlayouts mit dem Programmcode vermixt ist. Wer einmal damit ein Layout erstellen musste und saubere CSS-Designs gewohnt ist, weiß Bescheid! Während ein paar neue Maße, Farben und Hintegrundbilder mit CSS in 2-3 Stunden umgesetzt sind, braucht man beim Tabellenverhau so lange, um überhaupt erst durchzusteigen.

    Trotzdem will ich aber Tabellen als Layoutelement nicht komplett verdammen, auch wenn das semantisch nicht korrekt ist. Jedoch sparsam und nur da, wo Alternativen fehlen! Leider ist die display:table-Eigenschaft in CSS noch nicht umfassend verfügbar.

Kommentare anderer Blogger zu diesem Artikel