Webkrauts

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Produktiv? Wirtschaftlich?

Bringen wir es doch mal auf den Punkt: Ich behaupte, arbeiten mit dem Internet Explorer (IE) ist unproduktiv und unwirtschaftlich. Für wen? Für alle Kunden, die sich Webseiten entwickeln lassen und für alle Entwickler, die Webseiten (nach Auftrag) erstellen.

Arbeit mit dem IE ist unproduktiv

Der IE ist eine veraltete Software, die dem aktuellen Stand nicht mehr gerecht wird. Funktionalität, Sicherheit, Modularisierung, Personalisierung – alles Trends, die seit dem Jahre 2000 mit riesigen Schritten vorwärtsgetrieben wurden, jedoch unbemerkt am IE vorbeizogen. Den aktuellen Stand und die zukünftige Aussicht auf die Entwicklung des IE habe ich bereits in einem früheren Artikel ausführlich beschrieben.

Als Teil eines Workflows, sei es die Webseiten-Erstellung, Web-Programmierung oder die Informationsbeschaffung, ist der IE eigentlich untragbar. Zu viel Zeit wird mit Pflege, Updates, Security-Patches und ähnlichem vergeudet. Zudem besteht die oft dokumentierte Gefahr, bei einer regelmäßig notwendigen Aktualisierung das ganze Betriebssystem lahmzulegen, was einen Einsatz von Zeit und Manpower erzwingt, der von niemandem ersetzt wird. Als Gegenleistung erhält man nicht einmal wirklich verbesserte Software, sondern lediglich notdürftige Reparaturen einer unvollkommenen Software.

Ob sich diese Situation verbessert, wenn der IE in Zukunft nur noch als fester Bestandteil der jeweils neuesten Betriebsystemsversion ausgeliefert und somit zu einem nicht unerheblichen Kostenfaktor wird, sei dahingestellt.

Arbeit mit dem IE ist unwirtschaftlich

Das neue Jahr wird es zeigen – in Tabellen gequetschte und festgenagelte Layouts haben ausgedient. Jeder 'major relaunch' wird tabellenfrei sein, d.h. sich auf die strikte Trennung von Layout und Formatierung mittels CSS einlassen. Zu Recht, denn die Möglichkeiten von CSS-Design überbieten die Möglichkeiten von Tabellenlayouts um ein Vielfaches. Nicht nur design-technisch, auch was Wartung, Pflege und Änderungen oder Erweiterungen angeht, Hand in Hand mit besserer Zugänglichkeit und Nutzbarkeit.
Der Internet Explorer ist für diesen Wechsel ungeeignet, um nicht zu sagen: unbrauchbar. Sein (X)HTML-Support ist unzureichend, seine CSS-Unzulänglichkeiten sind ausreichend dokumentiert, XML kennt er überhaupt nicht – was soll man mit so einem Werkzeug anfangen, in einer Branche, die sich jedes Jahr dreimal um die eigene Achse dreht? Zumal es ja mittlerweile reichlich (und bessere) Alternativen gibt.

Was genau den IE so unproduktiv und unwirtschaftlich macht – ich beginne mal mit meiner Sicht als Entwickler. Mit einem standardkonformen Browser kann ich eine moderne, kompakte Website in sehr kurzer Zeit kodieren. Statt sie aber so zu veröffentlichen, beginnt nun der lange Ritt durch die wilden Browser-Instanzen. Nicht-CSS-fähige Browser sind kein Problem mehr, da sie mit sauber strukturierten und wohlgeformten Dokumenten bestens bedient sind, auch Nischenbrowser wie Opera oder Konqueror bereiten nicht allzuviel Aufwand – doch dann kommt der IE, der, so paradox es scheint, wegen seiner großflächigen Verbreitung ein echtes Hindernis darstellt. In grobem Maße hinderlich, da er immer noch in relativ vielen Versionen auftaucht (4, 5, 5.5 und 6), auch wenn die älteren Versionen langsam aber sicher von der Bildfläche verschwinden. Klammern wir den 4er mal aus (er wird eigentlich nicht mehr ernsthaft gefordert), dann bleiben immerhin drei Generationen des IE, die alle ihre ureigenen Fehler haben und irgendwie bedient werden müssen. D.h., daß ich ein sauber ausgearbeitetes CSS-Design nun drehen, zerren und biegen muß, um es einem Substandard-Browser verständlich zu machen – mit erheblichem Zeitaufwand und zu Lasten meines bereits sauber formulierten Quellcodes, der nun mit allerlei Hacks und Workarounds und Conditional Comments sowie zusätzlichen Stylesheets, Browserweichen und Javascript aufgeblasen wird, was wiederum die künftige Wartung und Pflege beeinträchtigen kann. Die Alternative, nämlich das Crossbrowser-Design auf ein Mindestmaß herunterzufahren, ist keine wirkliche Alternative, da ich dann auf ein Großteil der neuen Möglichkeiten verzichten müßte, verbunden mit der Gefahr, daß die Seiten eintönig oder langweilig wirken.

Sie, als potentieller Käufer von Internet-Dienstleistungen, stecken mitten drin in diesem Dilemma – einerseits verlangt der Markt, daß Sie mitziehen, indem Sie ein standardkonformes, zugängliches Angebot ins Netz stellen, andererseits entstehen Ihnen zusätzliche Kosten für die wenig zukunftsträchtigen Anpassungen, die ich eben beschrieben habe.

Wie befreien wir uns aus diesem gemeinsamen Dilemma?

Gern hätte ich eine präzise Antwort auf diese Frage parat – aber ich habe sie nicht. Wir kommen noch nicht darum herum, von Fall zu Fall sorgfältig abzuwägen, wie weit wir unsere eigenen Ansprüche gegen die unserer Kunden und Besucher durchsetzen können und wollen. Vielleicht hilft es bei der Entscheidungsfindung, sich nochmals ein paar grundsätzliche Dinge anzusehen.

Welchen direkten Nutzen ziehe ich aus tabellenfreiem Design?

• Basis eines jeden CSS-Layouts ist ein ordentlich strukturiertes, wohlgeformtes (Text-)Dokument. Dies gewährleistet praktisch 100%ige Erreichbarkeit für jede Art von UserAgent (Grafik-Browser, Text-Browser, Assistive Technologie wie Screenreader oder Braillezeilen, PDAs, Kiosk-Systeme etc.).
• Der Quellcode ist äußerst schlank und übersichtlich (schnelle Ladezeiten, gute Wartbarkeit), Formatierungen und Layout-Änderungen können schnell und komfortabel über zentrale Stylesheets ausgeführt werden.
• Durch Anlegen zusätzlicher Stylesheets können alternative Versionen der Präsenz angeboten werden, ohne in den eigentlichen Quellcode eingreifen zu müssen. So lassen sich Druckversionen, lesefreundliche Textversionen bis hin zu alternativen Layouts bereitstellen, die jeweils lediglich die Bearbeitung einer einzelnen Datei voraussetzen.

Welche Kompromisse muß ich eingehen?

Primär heißt es abwägen, wie weit Sie rückwärts schauen wollen/müssen. Möglicherweise können Sie aus Ihren Logfiles ersehen, welche Browser zu welchem Prozentsatz bei Ihren potentiellen Kunden vertreten sind – wenn z.B. der IE5.0 dort nur noch mit 0.1% auftaucht, lohnt es sich dann, spezielle Layoutvarianten für diesen Browser zu entwickeln?

Und behalten Sie immer im Hinterkopf – egal, wie Sie sich entscheiden -, es wird ja niemand von Ihrem Angebot ausgeschlossen. Schlimmstenfalls sieht dieser Anwender eine eher schmucklose Variante Ihres Angebotes, kann aber alles wahrnehmen und nutzen. Sie werden nie in die Verlegenheit jener Anbieter geraten, die Sie mit einer Tafel empfangen, auf der steht, daß diese Seite für Browser XY "optimiert" wurde und Sie sich diesen bitte erst mal herunterladen und installieren möchten. Eigentlich müßte auf der Tafel stehen: "Reduziert auf Browser XY. Du kommst hier net rein!" … Tja …

Welche Nachteile entstehen mir durch die Umstellung auf tabellenlose Layouts?

Keine. Selbst wenn die initiale Investition ein wenig höher ausfällt als beim 'klassischen' Tabellen-Layout (abhängig von Ihrer Kompromißbereitschaft), m.E. spielen Sie diese zusätzlichen Aufwendungen in kürzester Zeit wieder ein.