Das HTML5shim ist erforderliche Grundlage, um coole HTML5 Elemente wie canvas, video, audio oder datalist, aber auch die “langweiligen” Sectioning Elemente wie nav, article, section etc. sowie andere langweilige Elemente wie mark, figure, figcaption etc. in älteren IE-Versionen einsetzen zu können.
Da das HTML5shim erfordert, dass der Nutzer JS eingeschaltet hat, wird dies gerade im Zusammenhang mit den Sectioning Elementen als problematisch gesehen, da diese im wesentlichen zur Strukturierung und letztlich zum Styling genutzt werden und damit im Widerspruch zum Schichtenmodell der Frontendentwicklung stehen.
Skepsis ist erlaubt
Ich stehe dem heutigen Einsatz dieser Elemente bei 90% aller Webseiten, grundsätzlich negativ gegenüber. Der Grund ist einfach, diese Elemente haben einerseits keine funktionalen Features und ihre Semantik ist schlechter unterstützt als WAI ARIA (Landmarks), andererseits machen sie erheblich mehr Probleme.
Der diskutierte Einsatz von Sectioning Elementen
Eine diskutierte Variante ist zwar HTML5 Elemente einzusetzen, hier jedoch zusätzliche div-Wrapper vorzusehen und ausschließlich diese in CSS und JS anzusprechen. In diesem Fall ist es dann in älteren IEs egal, ob sie nutzbar sind oder nicht.
Letztendlich kann ich dem nicht viel abgewinnen, da in diesem Fall nur zusätzlicher Ballast erzeugt und letztlich in keinem Browser wirklich HTML5 angesprochen wird. Zudem unterscheidet sich die HTML Struktur in den unterschiedlichen Browsern, so dass hierdurch andere Bugs entstehen können und beispielsweise oft keine Kind- sowie Nachfolgeselektoren eingesetzt werden können.
Die konträre Extrem-Position setzt auf das HTML5shim und erklärt das Trennungsprinzip mit HTML5 und seinen reichhaltigen DOM-/JS-APIs sowieso für grundsätzlich erledigt. Webseiten müssen hiernach nicht mehr ohne JS funktionieren und der Aufbau einer Webseite soll nach anderen Prinzipien erfolgen (wobei die neuen Prinzipien, dann nicht mehr erklärt werden bzw. offen gesagt wird, dass man noch auf der Suche nach solchen ist).
Ich halte letztere Position zwar für richtig, aber die Argumentation für extrem gefährlich. Extrem gefährlich deshalb, weil “HTML5 Entwickler” sowieso schon zu dumm sind, um zu erkennen, dass ein button-Element, die richtige Struktur für einen Abspielbutton des eigenen HTML5 Videoplayers wäre. Soviel Dummheit kann man nicht mit den Worten, “Die Spielregeln haben sich verändert, irgendwann erklär ich sie dir”, auf die Welt los lassen.
HTML5 ist nichts anderes als die Weiterentwicklung von HTML und HTML4 bot bereits eine sehr reichhaltige DOM-API. Dass man nun mit noch mehr APIs, mehr und featurereichere Webapplikationen umsetzen kann, welche selbstverständlich JS voraussetzen müssen, ist kein Argument schnöde Webseiten mit ein paar Tabs, Accordions und Galerien so umzusetzen, dass sie ohne JS nicht funktionieren. Es ist letztendlich auch nicht so, dass Webentwickler vor der grossen Herausforderung stehen, sich zu fragen wie man JS abhängige Webapplikationen sauber strukturiert. Die steigende Anzahl und das ebenso steigende Interesse an Templating-Scripten sowie JS-Frameworks, die das MVC-Pattern sowie ähnliche Konzepte mit aufnehmen, dürfte dies deutlich machen.
technik- und nutzerzentrierte Vereinbarung des Schichtenmodells mit HTML5shim
Als erstes gilt es festzustellen, dass das Trennungsprinzip ein Entwicklungsmodell ist, welches beim Entwickeln ungemein hilft. Man schaue sich hier das in die Jahre gekommene DOM-Tab Script an, quasi das Paradebeispiel des Trennungsprinzips und unobtrusiven JS. Ist es nicht schön zu sehen, wie die semantische Information des HTML (Verbindung eines Links mit einem Element durch href-Verweis auf die id dieses Elements) als Konfigurationsgrundlage für das JS aufgegriffen wird. Es gibt viele Beispiele für eine gute HTML-Struktur die nicht nur ohne JS alleine funktioniert, sondern beim stückweisen Aufbau der Webseite mit JS hilft. Soll ich auf so etwas geniales verzichten, obwohl mir gerade HTML5 mit den data-* Attributen und vielem mehr, weitere “Semantik” als [custom-]Konfigurationsmöglichkeiten zwischen Backend und Frontend in die Hände drückt, nur weil irgendwelche alten Browsergenerationen einer einzelnen Firma, bestimmtes HTML bei ausgeschaltetem JS nicht richtig parsen? Nein mit Sicherheit nicht! Warum sollten Frontendentwickler gerade heute anfangen, ihre Konzepte am IE8 und nicht am IE9 auszurichten. Wer unobtrusives JS in Kombination mit HTML5 Sectioning Elementen schreibt, bekommt in jedem Fall ein sauberes Entwicklungsprinzip für eine Webseite und im Fall moderner Browser wird diese wie gewohnt auch weiterhin ohne JS funktionieren. Soviel zur Technik.
Letztendlich kommt es nicht allein auf die Technik, sondern auf den Nutzer an. Hat eine Webseite viele Besucher mit IE8 (und ausgeschaltetem JS), sollte man ohne Zweifel auf HTML5 Sectioning Elemente schlichtweg verzichten. Aber auch in Fällen in denen kaum Nutzer des IE8 mit ausgeschaltetem JS zu erwarten sind, muss man den Nutzer nicht im Regen stehen lassen. Durch geschickte Vermischung von Konditionellen Kommentaren und dem so verhassten noscript Element, lässt sich auf einfache Weise erreichen, dass auch der IE8 bei ausgeschaltetem JS ein (IE6-)universelles Stylesheet bekommt und ansonsten das HTML5 Stylesheet. Und man kann sich dabei auch ganz toll HTML5 fühlen. Denn erst ab HTML5 ist es erlaubt das noscript Element innerhalb des head-Elements zu platzieren.
Die wahren Probleme von neuen Elementen im IE8
Das erste Problem dürfte mit Erscheinen von jQuery 1.7 bekannter werden und gleichzeitig zumindest für die jQuery-Welt auch gelöst sein. Das HTML5shim hilft nämlich bei dynamisch erstellten Elementen nicht viel. Will man beispielsweise seinen schönen HTML5 content mit AJAX in eine Lightbox laden, hat man das selbe Problem wie mit ausgeschaltetem JS. Das dynamisch erstellte HTML[5] weist dann i.d.R. die selben Fehler auf, wie ohne HTML5shim.
Das andere Problem ist die fehlende Möglichkeit HTML5 Elemente zu drucken. Dies erscheint auf den ersten Blick nicht so schlimm, aber man kann letztlich bei fast keinem Projekt im voraus ausschließen, dass es zumindest irgendwann eine Druckvariante geben wird. Die einzige Möglichkeit besteht derzeit in der Verwendung von IEPP (wird vom aktuellen HTML5shim inzwischen genutzt), welches jedoch im Vergleich zu dem reinen klassischen HTML5shim kein einfacher Workaround, sondern ein gigantischer Hack ist. In der Natur von IEPP liegt es, dass der IE kurz vor dem Druck entweder sehr kurz oder recht lang bis hin zum Absturz einfriert. Ebenso in der Natur des Hacks liegt es, dass das Resultat mal dem definierten CSS mal eher weniger diesem entspricht, da IEPP an HTML sowie CSS für die Zeit des Drucks grosse Veränderungen durchführt. Ob es zu solchen Performanceproblemen oder solchen Fehlern kommt, hängt entscheidend vom Umfang des CSS und dem Schreibstil des jeweiligen Entwicklers ab. IEPP ist noch ein recht junges Projekt, welches sich noch deutlich weiterentwickeln kann und muss. Leider sind Verbesserungen häufig nur zu Lasten anderer Kenngrößen des Scripts(Performance vs. Genauigkeit vs. Dateigröße) zu erreichen.
Es ist merkwürdig, dass über dieses Problem kaum gesprochen wird bzw. kaum Entwickler, welche HTML5 gerade anfangen einzusetzen, diese wirklich kennen. Das kennen dieser Probleme sollte jedoch für jeden Entwickler, der über den Einsatz von HTML5 “Sectioning Elementen” nachdenkt, Pflicht sein. Zusätzlich kann zur Verbesserung des Problems einiges getan werden: Entwickler könnten darüber diskutieren, wie sie ihr CSS einbinden/schreiben, damit IEPP dieses schneller parsen kann. JavaScript-Entwickler könnten sich an die Verbesserung des Scripts machen etc..