pooker.blog

Die bleierne Zeit des Webdesigns

In Folge Nr. 61 der Technikwürze diskutierten am 26. Februar 2007 David Maciejewski, Marcel Schwarzenberger, Jens Grochtdreis und Tomas Caspers zum Thema Webstandards. Es ging dabei nicht so sehr um die bekannten Vorteile, eher um die Frage nach der richtigen Vermittlung, bzw. warum sich Webstandards noch nicht überall durchgesetzt haben. Kurzfristig sehen die Beteiligten keinen großen Fortschritt.

Hier folgt meine persönliche Auffassung zur Problematik. Ich wage darüber hinaus einen nicht ganz so negativen Blick in die nahe Zukunft der Webstandards.

Never change a running system…?

Als „Schuldige“ für die noch immer weit verbreiteten Tabellenlayouts werden vor allem die Browserhersteller gesehen. Um die Frage zu beantworten, warum sich Webstandards noch nicht umfassend durchgesetzt haben, kann man auch fragen, warum sich immer noch nicht überall Energiesparlampen anstatt stromfressender 80-Watt-Glühbirnen durchsetzt haben, oder warum man in Europa bei der Autoherstellung noch Jahrzehnte auf Einzelfertigung setzte, nachdem in den USA das Fließband längst etabliert war. Alle Antworten auf diese Fragen haben mehr mit menschlichen Entscheidungsprozessen zu tun als mit Logik oder Technologien.

Ein Weg, der sich einmal als erfolgreich erwiesen hat, bestimmt das zukünftige Verhalten. Das zu ändern, also ein Umschalten des imaginären Hebels, kann lange dauern. Wir alle kennen das von schlechten Angewohnheiten.

Um die Bedeutung der fatalen Gesetzmäßigkeit „hat immer funktioniert, kann heute nicht schlecht sein“ für das Webdesign zu erkennen, sollte man sich mit der Praxis des „Machens“ von Websites befassen. Es ist ja nun nicht so, dass alle „Tabellenfrickler“ nicht die Grenzen ihrer Technik erkennen. Viele interessieren sich sogar für Webstandards, bleiben aber letztlich bei ihren Tabellen.

Jens Grochtdreis bemerkt zu recht, dass er das Tabellenlayout „gar nicht mehr kann“. Das gilt schließlich für alle Webworker, die seit Jahren keine Tabellen mehr für Layouts verwenden. Wer aber seit 1996 bis heute Tabellenlayouts verwendet, macht das doch erfolgreich: die gezielte Verwendung von Spacer-GIFs, die komplizierte Verschachtelung mehrerer Tabellen mit horizontal und vertikal verbundenen Zellen, eingebunden in einem ebenso komplizierten Frameset, das alles funktioniert auf bewährtem Wege, und alle Browser zeigen das ja auch noch ganz fein und ordentlich an.

Ich hab`da mal was layoutet…

Der erste Schuldige ist dabei allerdings nicht immer der Webworker oder Kunde, sondern scheinbar noch zu oft ein (Print-)Grafiker, der in Photoshop, Freehand oder Illustrator eine Startseite und ausgesuchte Einzelseiten gestaltet und kaum Ahnung von HTML oder Navigationshierarchien hat („Mauszustände“ hält er für ein Burn-Out-Syndrom von Webdesignern). Der Webdesigner darf dann brav die Layouts exakt 1:1 umsetzen, weil, der Webworker ist ja eh nur eine Art Halbgrafiker (zusammengeschrieben wie Halbaffe) und der Vollprintgrafiker hat die Layouts als Ausdrucke auf Hochglanzpapier sowieso schon vom Kunden abnehmen lassen, natürlich ohne vorher den Pixelschubser gefragt zu haben, wozu auch.

Beispiele dieser Art lassen sich mit zahlreichen Beiträgen aus der Rubrik „wie kann ich dieses Layout/diese Navigation mit CSS umsetzen?“ in der CSS-Mailingliste belegen, die auch versierte Webworker in endlose Diskussionsrunden möglicher Lösungen nötigt. Gänzlich unmöglich wird eine Antwort auf solche Fragen, wenn zusätzlich der Wunsch nach Barrierefreiheit für solche Projekte ansteht. Die Webworker, die so einen Job auszuführen haben, darf man bedauern.

Man wird als standardkonformer Webworker natürlich nicht die ketzerische Aussage machen, dass manche dieser (im übrigen stets benutzerunfreundlichen) grafikbasierten Layouts besser mit steinzeitlichen Tabellen, Imagemaps und MausOver-Script umgesetzt werden sollten. Man sollte aber viel öfter herausschreien, dass so ein Scheiß als Vorgabe sowieso gleich abzulehnen ist und man als ernstzunehmender Profi stattdessen dem Verursacher dieser Vorgabe eine kostenlose Aufklärungsstunde in gutem Webdesign geben sollte. Passiert so eine Vorgehensweise in einer Agentur, ist das ja noch schlimmer: dann heißt es Klarstellung der Kompetenzen oder Job wechseln. Gottseidank ist diese Form des Grafikers als Chef für den Webentwickler auf dem Rückzug. Es muss also weitere Gründe für die immer noch vorherrschenden Tabellen geben.

Neuer Wein in alten Schläuchen

David Maciejewski bringt das Beispiel eines Kunden, der von seiner ersten (frame- und tabellenbasierten) Website vollkommen überzeugt war, da sie laut Angaben des ausführenden Webdesigners „nach neuestem technischem Stand“ umgesetzt war. Es gibt ja nur zwei Möglichkeiten der Erklärung, die beide kein gutes Licht auf den Webdesigner werfen, aber ein differenziertes Bild vom üblichen Basteln von Webseiten geben: weiß der Webdesigner um die veraltete und unprofessionelle Umsetzung, ist er bestenfalls ein Blender, schlimmstenfalls ein Betrüger. Doch wahrscheinlich ist die Website tatsächlich „nach neuestem technischem Stand“ umgesetzt.
Wie das? Die Antwort darauf liefern Programme, die das Web nahezu unbemerkt fast ebenso sehr beeinflusst haben wie die Fähigkeiten der Browser, und die heute das größte Hindernis für die Durchsetzung standardkonformen Webdesigns darstellen. Die Rede ist von den etablierten und als professionell eingestuften WYSIWYG-Webeditoren.

Fakt ist: Noch immer wird die absolute Mehrzahl aller kleinen und mittelgroßen Websites mit Hilfe von Editoren erstellt, nicht handcodiert und nicht mit standardkonformen Templates oder Frameworks.
Als Pixelschubser und GoLive-Nutzer der ersten Stunde, der erst 2003 einen intensiven Blick auf den Quellcode wagte, und 2007 zu Dreamweaver wechselte, weiß ich, wovon ich spreche. Editoren wie (Claris) Homepage, Pagemill, NetObjects Fusion, Freeway, Frontpage, GoLive, Dreamweaver – bzw. deren Vorgänger – erschienen zwischen 1997 und 1998, also – und das ist hier wichtig – mitten in den Wirren des Browserkrieges.
Die Editoren sollten nicht nur den Webworkern die Arbeit mit visuellen Vorschau- und Entwurfsdarstellungen erleichtern, denn das tun sie unzweifelhaft bis heute. Im Gegensatz zu den Browserherstellern versuchten die meisten Softwarefirmen (außer natürlich Microsoft und Netscape) ihre Editoren konsequent mit allen neuen Features der beiden Browser kompatibel zu halten. Diese Strategie war überaus erfolgreich, musste man sich als Webdesigner doch nicht ständig Gedanken darüber machen, ob und in welchen Browsern ein bestimmter Javascript- oder Ebeneneffekt korrekt gezeigt wurde. Die Editoren sorgten also zunächst für die angenehme Vermeidung verschiedener Websites. In GoLive führte das beispielsweise zu einer ins gigantische aufgeblähten Javascript-Bibliothek für diverse DHTML-Effekte: der Preis für eine nahezu vollständige Kompatibilität mit beiden Browsern. Gerade die „DHTML-Schande" brachte Javascript später zusätzlich in Misskredit, nachdem die Effekte in modernen Browsern nicht mehr richtig funktionierten.

Geht überall – unsichtbare Tabellen

Die wichtigste Voraussetzung für eine größtmögliche Kompatibilität war jedoch der kleinste gemeinsame Nenner in der Umsetzung komplizierter Layouts. Dieser Nenner war stets und bei allen Editoren das Tabellenlayout. Als sich der Markt nach der Jahrtausendwende auf Dreamweaver und GoLive reduziert hatte, verfügten sie zusammen mit dem weit verbreiteten Frontpage über ein komfortables Handling für komplizierteste Tabellenlayouts. Die CSS-Unterstützung außerhalb der rudimentären Formatierung der Schriften blieb jedoch ab etwa 2001 hinter den Darstellungsmöglichkeiten der Browser weit zurück. Es blieb ja vor allem den „handfesten Codierern“ vorbehalten, die Webstandards überhaupt nach vorn ins Bewusstsein der Webdesigner gebracht zu haben.

Aber heute ist ja alles viel, viel besser.
Die Hersteller haben Webstandards als Chance und Notwendigkeit für den weiteren Geschäftserfolg entdeckt. Die Editoren-Entwicklung ist eindeutig positiv zu sehen: Selbst der Frontpage-Nachfolger „Expression“ scheint doch mit CSS-basierten Layouts sehr gut umgehen zu können. Und: Die Tutorials und Templates der Editoren basieren mittlerweile auf der Vorgabe von CSS-Layouts.

Webstandards also endgültig auf dem Vormarsch und die WYSIWYG-Editoren sozusagen an vorderster Front mit wehenden Fahnen und aufgepflanzten Bajonett vorneweg?
Kompletter Blödsinn, so ist es eben nicht: Eine Lobhudelei wäre doch nur dann gerechtfertigt, hätte Adobe seine etablierten Profi-Editoren Dreamweaver und GoLive endlich und konsequent von sämtlichen Altlasten der Tabellenlaouts befreit, inklusive Font-Tag-Funktionen und aufgetakelte DHTML-Aktionsbibliotheken. Noch besser wäre es, wenn Microsoft dabei gleich mitziehen würde. Das wiederum taten und tun sie alle nicht.

Wir legen uns fest: Sowohl. Als auch.

Tatsache ist vielmehr: Auch wenn seit wenigen Jahren die großen Editoren eine sehr gute Unterstützung für CSS-basierte Layouts bieten, führen sie gerade heute ein für die Webstandards katastrophales „Zwitterdasein“: die veralteten Funktionen stehen dem Anwender noch genauso selbstverständlich zur Verfügung, nur dass zusätzliche Paletten für die CSS-Entwicklung dazugekommen sind.
Sogar Totgesagte leben noch: der Netscape Navigator 4 mag im Web längst verwest sein, doch in GoLive ist er mit ein Script für den Bug fliegender DIV-Layer bei Veränderung der Fenstergröße scheinbar noch putzmunter! Dieses Script aus dunkelster Vergangenheit ist auch noch – hoppla –in der GoLive-CS2-Version von 2005 vorhanden. Ich schätze mal, es wird auch noch in GoLive 9 (Juli 2007) als Perle der Web-Archäologie zu finden sein.

Eine kostenlose Alternative für kleine Websites bietet seit Jahren der Nvu-/KompoZer-Editor, eine zu unrecht kaum bekannte Open-Source-Applikation für Windows, Mac und Unix. Hier können verschiedenen Modi wie der WYSIWYG-Entwurf, HTML-Tags und Quelltext gewählt werden. Erstaunlich ist vor allem die Qualität der korrekten Darstellungen komplexer CSS-Layouts im Entwurfsmodus, die auf meinem Mac nicht nur die miese GoLive-Ansicht (CS2), sondern sogar Dreamweaver 8 um Längen schlägt (Beispiel: YAML-Layouts). Die technische Umsetzung basiert leider auch hier auf der doppelten Funktionalität: neben XHTML strict werden neben strong und em auch immer noch span class=“bold“ und span class=“italic“ in der Werkzeugpalette angeboten.

Wie soll man die WYSIWYG-Editoren also beurteilen?

Webdesigner lieben ja den Auto-Vergleich bei jeder sich bietenden Gelegenheit. Man stelle sich also mal einen Autoverkäufer vor, der einem klarmacht, dass im hochmodernen Kompressor-Boliden die Rückbank natürlich fehle, weil da ja die Kohle gelagert werde, nämlich für die zusätzliche Dampfmaschine im Kofferraum, man müsse schließlich an die Autofahrer denken, die noch das Fahren mit der Dampflok gelernt haben. Und das Heu auf dem Beifahrersitz für ein Pferdegespann, ja nun, das stamme noch aus der ersten Baureihe, das habe man nur vergessen zu entfernen, aber das störe doch nicht die Fahreigenschaften.

Der Tabellen-Freak kann also weiterhin seine Websites nach altem Muster und in bewährter Manier mit den bequemen Paletten seines WYSIWYG-Editoren umsetzen, er muss sich um die neuen CSS-Features ja nicht kümmern.

Somit konnte der von David Maciejewski querzitierte Webdesigner deshalb angstfrei behaupten, die von ihm erstellte Website sei auf dem neuesten Stand der Technik: Die Website umfasste eben das komplette Theater aller Tabellenlayout-FontTag-DHTML-Features einer aktuellen Version von Dreamweaver, GoLive oder Frontpage.

Es sind also nicht nur die trägen Browser-Hersteller, sondern vor allem die Hersteller der WYSIWYG-Editoren, die zur „bleiernen Zeit“ im Webdesign von heute führten.

Zu schnell vergisst man auch die ungesunden historischen Wechselwirkungen zwischen Editoren und Browser. Zahlreiche Browserkrieg-Features wären uns ja erspart geblieben, wenn die Editoren nicht alles sofort als PlugIns zum freien Verwursten integriert hätten in der Gewissheit, die Webdesigner würden sich wie neugierige Kinder sofort auf jedes neue Spielzeug stürzen: Alles was ging, wurde unkritisch und tausendfach umgesetzt. Die Kunden fanden das ihrerseits – je nach Charakter –„zeitgemäß“ , „super “ oder „megacool“. Der Browserkrieg war vor allem ein perfides Spiel mit der Gier nach Neuem.

Webstandards: Irgendwann kriegen wir sie alle…

Nach so ausführlicher Hoffnungslosigkeit nun die Antwort auf die berechtigte Frage, warum sich Webstandards trotzdem durchsetzen werden.

1. Blogs und Zen-Gärten

Während die WYSIWYG-Editoren hinter den Entwicklungen zurückblieben, waren und sind es gerade „Web 2.0“-Lösungen, die auch in Deutschland für eine Sensibilisierung von Webstandards gesorgt haben. Es waren weniger die Autoren Zeldmann oder Meyer, die den theoretischen Background lieferten. Vor allem die nach der Jahrtausendwende zunehmende Verbreitung von Weblogs haben viele Webdesigner und Hobbyanwender zunächst dazu gebracht, sich mit der Trennung von Inhalt und Design zu beschäftigen. Flexible Layouts oder fest positionierte Inhalte waren ja auch mit Tabellen realisierbar. Der Vorteil von Weblogs war aber die unendliche Variationsvielfalt von Themen und Templates bei gleich bleibender (X)HTML-Struktur auf der Grundlage von Webstandards. Nicht umsonst beklagte sich Joe Clark in einem Artikel, dass solch vorgefertigte Lösungen sozusagen „on the fly“ einen besseren Code generieren würden als die meisten selbstgebastelten HTML/CSS-Layouts.
Wer sich also mit CSS-Techniken beschäftigte, um sein Blog ein wenig zu hübschen, stieß irgendwann auch auf das Experiment CSS Zen Garden von Dave Shea. Wahrscheinlich hat Shea für die professionelle Beschäftigung mit Webstandards mehr getan als alle Foren, Bücher und die Propheten mit erhobenem Zeigefinger. Jeder noch so versierte Tabellenfrickler konnte anhand der Beispiele sehen, was er mit seinen Mitteln niemals schaffen würde: einen unveränderten Inhalt in unendliche Design-Variationen zu verpacken.

2. Standards beim Discounter

Der Discount-Provider 1&1 bietet einen so genannten „Homepage-Baukasten“, für ein paar gefühlte Pfennige an und dabei auf eine strikte Trennung von Inhalt und Design setzt. Im Gegensatz übrigens zu Strato, wo der „Live Pages“ genannte Baukasten noch auf grafikbasierten Tabellenlayouts setzt.

3. Neue Editoren: iWeb, Rapidweaver und Co.

Von der professionellen Gemeinde der Webworker fast unbemerkt haben sich kleine WYSIWYG-Editoren in Nischenmärkten hauptsächlich für Privatanwender etabliert. Als Mac-User kann ich nur für dieses Betriebssystem sprechen, für das es mittlerweile drei Altenativen zu Dreamweaver und GoLive gibt. Apple mit dem im iLife-Paket integriertem Programm iWeb, Sandvox (Karelia Software) und RapidWeaver (Realmac Software). Alle drei Editoren basieren auf der Erstellung von Websites nach dem XHTML 1.0-transitional-Standard. Das klappt mehr oder weniger gut, wie der Validator zeigt. Wichtig ist aber: Werkzeuge für Tabellenlayouts oder gar Font-Tag-Paletten wird man vergeblich suchen. Die Trennung von Inhalt und Layout hat im Fall von RapidWeaver innerhalb kürzester Zeit zur Entwicklung zahlreicher professioneller Themen, Features und Layout-Hilfen geführt. Die Anwender können als Add-ons zahlreiche Templates, Fotogalerien, AJAX-Anwendungen, Tools für Mehrspaltenlayouts, ein kleines CMS und ein Weblog über Drittanbieter erwerben und einsetzen. Mein Tipp an die Webentwickler mit Mac: mal ansehen und ausprobieren.

4. Baukästen und Vorlagen mit Webstandards: Templates

Auch wenn die aktuellen WYSIWYG-Editoren auch CSS-Templates vorgeben, sind es seit Jahren eher die kostenlosen „Baukastensysteme“ und Template-Sammlungen im Web (Beispiel: Linksammlung bei Dr. Web), die schnell zu realisierende Lösungen für den Anfang bieten. Oft beinhalten die generierten Layouts grundsätzliche IE-Hacks für die korrekte Darstellung. Diese Grund-Templates generieren nur das grobe Raster der DIV-Container und funktionieren nach dem Ausbauprinzip. Alle Elemente müssen zusätzlich in die DIVs eingepflegt werden, ebenso muss die CSS-Datei entsprechend erweitert werden.
Für wichtige Elemente gibt es wiederum eine große Auswahl im Web: für Navigationslisten gibt es mittlerweile Linksammlungen, und für alles andere ebenso. Daneben gibt es seit wenigen Jahren auch code-Schnipsel für Javascript/AJAX-Anwendungen. Ergänzend existieren lebendige Informationsforen wie die CSS-Mailingliste.
Das größte Problem dieser Ausbausysteme ist gleichzeitig ihre Stärke: Der Anfänger lernt über das Prinzip „Learning by doing“ mit jedem Layout und jedem Element die Fallstricke moderner CSS-Lösungen. Aus eigener Erfahrung weiß ich, dass vor allem Geduld und eine hohe Frustgrenze für diesen Weg notwendig sind.

5. CSS-Frameworks

Die wichtigste Entwicklung zugunsten von Webstandards sehe ich in Frameworks wie Yahoo Grids und vor allem das Framework YAML von Dirk Jesse. Aufgrund eigener Erfahrungen möchte ich mich diesem Framework etwas ausführlicher widmen. Im Gegensatz zu den rudimentären Layout-Templates setzen Framework- Lösungen auf vollständige Systeme.

Als Webentwickler erhält man z. B. mit YAML eine komplette Arbeitsumgebung für die unterschiedlichsten Anforderungen an Inhalten, Gestaltungsfreiheiten und Techniken. Es gibt YAML für bekannte Content-Management-Systeme wie Typo3 und Joomla, die Dokumentation umfasst neben einem Buch auch ein Entwicklungs- und Anwenderforum, und die Website selbst (www.yaml.de) zeigt, was diese Lösung möglich macht: Viele Webworker kennen ja das Portal von „Einfach für alle“ (EfA), sozusagen das unparteiisch-unabhängige Zentralorgan für barrierefreies Webdesign (wer es nicht kennt: sofort hin da!)
Das Framework ermöglicht ein unkompliziertes Update auf die Folgeversionen ohne großartigen Backups oder zeitaufwendige De-Installationen. Interessant ist vor allem die komplette Implementierung einer Vielzahl von IE-Hacks, die auch der routinierte Anwender zu schätzen weiß.
Und was ist mit der Flexibilität bezüglich CMS? Bitteschön, was hättens’ denn gern: Drupal, ExpressionEngine, Joomla, Papoo, Papaya, Postnuke, Serendipity, TYPO3, Wordpress, ZMS oder xt-Commerce? Alles da.

Ein paar Worte mehr zu YAML

Mit YAML kommen selbst Anfänger sehr schnell zu ansprechenden Lösungen, entsprechende Seitenvorstellungen im YAML-Forum zeugen von den Erfolgen und der Motivation auch jüngster Web-Novizen. Das ist die eigentlich „frohe Botschaft“. Die Fallstricke des Frameworks zeigen sich natürlich auch hier in Detailproblemen, die durch zusätzliche Modifikationen oder Ergänzungen im vorhandenen Projekt entstehen, aber es geht eben nur um die Lösungen von Problemen in sekundären Details. Dagegen muss der Anfänger mit den rudimentären Ausbau-Templates aus dem Web schon bei kleinsten Modifikationen des Grundlayouts auf gravierende Probleme mit verschiedenen Browserinterpretationen reagieren.

YAML nix für Profis?

Erstaunlicherweise hat sich das Framework noch nicht umfassend in der Gemeinde professioneller Webentwickler durchgesetzt. In persönlichen Gesprächen tauchen sehr oft die üblichen Vorbehalte und Vorurteile gegenüber einer „fertigen“ Lösung auf: zu viele DIVs, zu viele CSS-Dateien, zu kompliziert, nicht flexibel genug…
Wer sich jedoch einmal etwas Zeit nimmt, um das System hinter dem Framework zu erfassen, wird diese Vorurteile für immer ablegen. Es bleibt ja jedem Webworker vorbehalten, ob er die YAML- Lösungen für verschiedene Projektanforderungen unverändert einsetzt, oder doch lieber zusätzlich oder stattdessen auf eigene Elemente setzt.

Gelegentlich scheint es sich bei den Kritikern auch eher um eine Form der Bequemlichkeit zu handeln, ein gutes eigenes und bewährtes Template-System nicht über Bord zu werfen und etwas Neues zu wagen. Doch das Bessere ist auch hier des Guten Feind. Womit wir übrigens wieder beim Thema „HabIchImmerSoGemachtDatBleibtSo“ wären…

Meine eigenen Erfahrungen mit YAML zeigen, dass sich das Framework auch für jeden Profi eignet. Man muss das Rad nicht ständig neu erfinden. Und seien wir mal ehrlich: ein Blick auf die Referenzobjekte vieler Webentwickler zeigt auch, dass Grundlayouts immer mal wieder in neuer Verpackung auftauchen. Ja, Herrschaft, warum auch nicht? Gute Architekten verdienen ihr Geld mit der individuellen Modifizierung bestehender Pläne, komplett neu aufgesetzte Projekte sind dagegen was für Ruhm, Ehre und guten Platzierungen bei Wettbewerben.

Tipp: Ansgar Hein vom Barrierekompass hat übrigens ganz aktuell eine lesenswerte Rezension zum YAML-Buch geschrieben.

Fazit

Ich bin mir sicher, dass vor allem YAML und andere Frameworks das Potential zu einem enormen Vormarsch von Webstandards haben, ein Potential, das die großen Editoren der alten Zeit verschlafen haben. Andere, unscheinbare Lösungen werden zu diesem Erfolg rasch beitragen, wie die Beispiele der Mac-Editoren, und ja, sogar der 1&1 Homepage-Baukasten zeigen. Um mit Tomas Caspers zu enden: „Die Hoffnung stirbt zuletzt“ – aber so schnell stirbt es sich dann doch nicht.