Kompatibilität und Standardkonformität

gedacht
gefunden
Published

08.05.2011 18:10

Es fing alles an mit dem Internet Explorer von Microsoft. Dieser interpretierte HTML auf teilweise abenteuerliche Weise, schaffte es durch seine Vorherrschaft in den Pioniertagen des Internets jedoch, dass viele Webseiten ihrerseits nicht dem Standard folgten, sondern sich dem Platzhirsch anpassten. Seitdem haben alle Browserhersteller das Problem, sich zwischen Standardkonformität und einer Kompatibilität zu möglichst vielen Seiten zu entscheiden. Und so interpretiert jeder Browser eine Webseite auf individuelle Art und Weise, die Webdesign zu einer Bastel- und Frickelarbeit verkommen lässt, will man mehr als einen Browser unterstützen.

Da helfen auch keine erprobten und gehärteten Frameworks wie YUI oder jQuery, wie ich auf dem harten Weg erfahren musste. Denn seit kurzen verwende ich für mein Blog ein Gallery-Plugin in Zusammenspiel mit dem jQuery-Lightbox-Klon. Da Wordpress bereits jQuery mitbringt, spare ich mir so Probleme durch den Einsatz mehrerer JavaScript-Frameworks (das Lightbox-Original verwendet Prototype & Scriptaculous) - dachte ich zumindest. Beim Austesten musste ich jedoch feststellen, dass Opera und der IE gut damit zurechtkommen, der Firefox jedoch beim Klick auf ein Bild nicht den Lightbox-Effekt startet, sondern das Bild in einem Tab öffnet.

Nach einer längeren Google-Session fand ich dann den entscheidenen Hinweis: Lightbox verwendet das Attribut rel am Anker-Tag um zu erkennen, welche Bilder es mit dem Effekt ausstatten soll. Bei Gallerien folgt hinter dem Wert lightbox noch in eckigen Klammern der Galleriename, also zum Beispiel rel="lightbox[set1]" - und diese eckigen Klammern sind ab XHTML 1.1 dort nicht mehr erlaubt, bzw es dürfen überhaupt nur noch vordefinierte Werte angegeben werden (schön zu sehen im Validator des W3C). Lightbox ist an dieser Stelle also nicht zukunftskompatibel, sondern nutzt einen Freiraum der Spezifikation von XHTML 1.0.

Bei mir sollte es jedoch funtionieren, da ich eben XHTML 1.0 einsetze und dies im DOCTYPE angebe. Der Firefox scheint jedoch nicht nur in den DOCTYPE zu schauen, sondern seine Interpretation auch von dem im Header mitgesendeten Contenttype abhängig zu machen. Als ich von application/xhtml+xml, dem für XHTML vorgesehenen Standard, auf text/html umschwenkte, den ich sonst nur dem IE sende, funktionierte der Effekt plötzlich. Dies ist keine schöne Lösung (andere ersetzen die Klammern durch Striche direkt in der JS-Bibliothek), doch sie funktioniert erst einmal. Und sie steht trotz der Annäherungen der Browser der aktuellen Generation an die verschiedenen Standards in bester Tradition der Browserweichen und trägt damit zu dem komplexen Interaktionswettbewerb zwischen Seitenbetreibern und Browserherstellern bei…