CrossBrowser-Publishing [2/5]
Defensives Coding
Die Problematik der unzureichenden Unterstützung der Standards durch Browser und Tools bringt es mit sich, dass man sich nur auf Terrain bewegen sollte auf dem man sich auskennt. Web-Editoren wie Golive oder Dreamweaver bieten zwar viel Glitzer und Glamour in Form von DHTML/JavaScript-Behaviours oder -Actions an. Diese lassen sich ohne tiefere Programmierkenntnisse zu besitzen mit einer Mausbewegung auf die HTML-Dokumente ziehen.
Wer sich aber auf die Resultate von Dreamweaver und Konsorten verläßt, ist schnell verlassen. Das zeigte sich anhand des Erscheinen von Netscape 6 im November 2000. Obwohl Netscape 1999 angekündigt hat, das
Layer-Element nicht mehr zu unterstützen, obwohl Netscape 1997 auf einer Entwicklerkonferenz selber von der Verwendung des Layer-Elementes abgeraten hat, basieren einige der Actions/Behaviors der 2000er-Versionen der Web-Editoren auf diesem Nicht-HTML-Standard-Element. Folge: Mit Netscape 6 sind kommt es nun auf einigen Sites zu Darstellungs- oder Funktionsfehlern. Und diese sind aufgrund des teilweise extrem komplexen JavaScript-Codes der Editoren kaum von Hand zu beheben.Erschwerend kommt die mangelnde Unterstützung von Standards hinzu. Lange Zeit war es ist höchst ärgerlich, dass die nicht wirklich billigen HTML-Editoren nicht mal die Basics von HTML 4.0 unterstützen. Weder Dreamweaver 4 noch Golive 5 fügen beispielsweise automatisch ein
ALT-Attribut ein, wie es HTML 4.0 seit sage und schreibe 1997 vorsieht.Die Situation hat sich mit den neuen Versionen der WYSIWYG-Editoren (Macromedia Dreamweaver MX und Adobe Golive 6) gebessert, doch noch immer ist es häufig nötig selbst Hand an die Seiten anzulegen um den Quellcode zu modifizieren oder standard-konform zu machen. Man sollte sich daher mit den Standards auskennen, man sollte, siehe oben, das Terrain kennen auf dem man sich bewegt, um notfalls jederzeit auf "Handsteuerung" umschalten zu können.
Dazu gehört auch übersichtlichen Code zu schreiben, also mit Kommentaren zu versehen und adäquat einzurücken. Dann hat man es später auch mit der Pflege des Codes leichter.
K-I-S-S - Keep it simple, stupid!
Je komplexer die Seite und die Programmierung, desto mehr Aufwand muss man betreiben, damit die Seite auf allen relevanten Browserplattformen läuft. Browser-Switching verzweigt auf Browser-spezifische Seiten, die mit jeder neuen Browser-Version gepflegt und angepasst werden müssen.
Simples aber effizientes Design hat den Vorteil, dass es einfacher zu pflegen ist und sich wesentlich robuster in den Browsern verhält. Es ist simpler von dieser einfachen Basis aus später neue, raffiniertere Features einzubauen, als eine "verwarzte" Site abzumagern.
Die Herangehensweise sollte sein zu versuchen Inhalt vom Aussehen zu trennen. HTML 4 empfiehlt daher Tabellen nicht mehr für Designzwecke zu verwenden, um z.B. Grafiken "zusammenzuhalten". Ganz so rigide wird sich die Empfehlung nicht umsetzen lassen, aber man sollte auf komplexe, verschachtelte Tabellen verzichten. Nicht nur ist das Rendering der Seite schneller. Auch vermeidet man damit Darstellungsprobleme wie sie Netscape 4.x bei sehr komplexen Tabellen hat.
Effizientes Design
Hinter Screendesign steckt mehr als nur gute Beherrschung von Photoshop!
Meiner Meinung nach begeht das Webdesign von heute den Kardinalsfehler von Anfang an von einem festen Screendesign auszugehen, statt sich die Zeit zu nehmen und sich "iterativ" dem Endresultat anzunähern.
In der Screendesign-Abteilung wird, meistens ohne jegliches Verständnis für die dahinterliegende Programmierung, an einem Screendesign gewerkelt, das dann in einem Zug umgesetzt wird. Erkenntnisse die während der Umsetzung oder sogar später, beim Online-Schalten, gewonnen werden, fließn so nicht mehr ein. Man nimmt sich nur Zeit für einen Schuss, und der muss sitzen.
Es erschreckt mich in meinem Umgang mit Agenturen immer wieder wie wenig Screendesigner Ahnung vom Medium und Programmierung haben. So verwundert es nicht, dass viele Screendesigns schlichtweg nicht mediengerecht sind und sich nur mit viel Mühe und komplexen Tabellenverschachtelungen basteln lassen.
Diese Screendesigns sitzen im Browser fest wie in Beton gegossen, sind nicht in der Lage sich an verschiedene Screen-/Browsergrößen anzupassen. Konsequenz aus der Tatsache, dass ein Großteil der Designer aus dem Printbereich mit seinen festgelegten Dimensionen kommt. Statt sich über die mögliche Flexibilität eines "liquid" Designs zu freuen, wird bemängelt wie wenig Kontrolle man über das Aussehen einer Seite hat.
Dieses Problem der medien-inadäquaten Herangehensweise wird sich auch nicht so schnell beseitigen lassen, da die meisten Designer sich nicht weiterbilden, keine Antenne für aktuelle Webtrends haben, und in den einschlägigen Medien wie "PAGE" oder "Screen" lieber Wert auf "nutzwertige" Artikel gelegt wird, und eher theoretische Abhandlungen keinen Platz finden.
Test early, test often!
Nicht jedem wird es dabei vergönnt sein, einen Aufwand zu treiben wie DoubleClick es ernsthaft vorschlägt und die Seiten auf sage und schreibe 31 verschiedenen Konfigurationen zu testen (Wohlgemerkt: Nur Windows, Mac und WebTV. Linux, Palm und Konsorten nicht mitgerechnet!). Auch hier gilt es das Testprogramm seiner Zielgruppe anzupassen.
Die Webeditoren besitzen teilweise eingebaute "Checker", welche die HTML-Seiten überprüfen sollen. Diese legen allerdings die Standards sehr "weich" aus, und eignen sich nur begrenzt zur Code-Überprüfung.
Von anderem Kaliber sind da "Validatoren" und "Lints" die nicht nur die einzelnen HTML-Elemente, sondern gleich das ganze Dokument anhand eines Regelwerkes überprüfen. Sie achten sozusagen nicht nur auf die "Rechtschreibung", sondern auch auf die "Grammatik".
Der bekannteste "Lint" ist HTML Tidy, der frei via W3C erhältlich ist. Es gibt ihn als eigenständiges Programm, als Zusatzmodul und "eingebaut" in diversen Applikationen auf diversen Plattformen, z.B. als Plug-In für BBEdit.
Als quasi offizieller "Validator" für Webseiten kann der W3C HTML-Validator gelten, der in der Lage ist online abgestellte Dokumente zu durchforsten. Für Cascading Style Sheets ist der "W3C CSS Validator" zuständig. Darüber hinaus gibt es den W3C Link Checker, der sämtliche Links in einem Dokument überprüft.
Zwei weitere Hilfsmittel sind noch unbedingt empfehlenswert: Macromedia hat für Dreamweaver eine wirklich sinnvolle Extension entwickelt, die sich im Exchange-Center runterladen läßt, auch wenn der Titel "Check Page Accessibility" arg holprig ist.
Diese Dreamweaver-Extension hält sich eng an die Kriterien von "Bobby", einem Checker der die Seiten auf "Accessibility" für Behinderte überprüft, aber darüber hinaus sehr umfangreiche Tipps gibt. Bobby kann, wie der W3C-Validator, online die Seiten überprüfen.
Darüber hinaus sollte man natürlich auch "Real-World-Tests" mit echten Browsern durchführen. Auf evolt.org findet sich eine reiche Sammlung an neuen und alten Browsern im sogenannten "Browser-Friedhof". Dabei sollte man aber bedenken, dass man weder auf Windows noch beim Mac unterschiedliche Internet-Explorer-Versionen gleichzeitig testen kann, da die neueren Explorer-Systemdateien Auswirkungen auch auf die Anzeige der älteren Explorer-Versionen haben.
Es gibt auch verschiedene Emulatoren um bestimmte Browser nachzuahmen, z.B. von WebTV.
Im Sinne der Standard-Konformität ragen zwei Browser heraus. Der Mac Internet Explorer 5, der als erster eine große Bandbreite an Standards unterstützte. Und Netscape 6/Mozilla. Als viele Leute den Netscape 6-Browser zum ersten Mal auf eigene Websites ansetzen, und die Site plötzlich voller Macken war, war das Böse schnell geortet: Netscape muss voller Bugs stecken!!
Das was den Netscape-6/Mozilla-Browser von allen anderen Browsern unterscheidet, ist die Gnadenlosigkeit mit der bereits kleine Abweichungen von den heiligen Schriften des W3Cs bestraft werden. Das macht insbesondere den Mozilla-Browser, der, im Vergleich zu Netscape 6, immer über die aktuelleren Verbesserungen verfügt, zu einer harten Teststrecke für Webseiten.
