Internet-Explorer-Facepalm du jour

Veröffentlicht am 22. November 2010

Ich glaube ja manchmal, dass die meisten Leute da draußen gar keine Ahnung davon haben, wie verranzt der Internet Explorer tatsächlich ist. Und mit „Leute“ meine ich nicht nur Otto Normalnutzer, sondern auch manchen Webentwickler – mich eingeschlossen. Dass der IE ob seines biblischen Alters manches Feature nicht unterstützt und CSS manchmal kreativer als nötig interpretiert, ist hinreichend bekannt, aber man findet immer wieder etwas Neues.

Als ich vor ein paar Tagen über Tag-Auslassung in HTML schrieb bezog ich mich mitnichten auf eine Erfindung jüngerer Zeit, sondern auf ein Feature, das HTML seit Anbeginn der Zeiten hatte. In den Beispielen der ersten HTML-Version werden grundsätzlich Tags ausgelassen und in Version 2 der Spezifikationen heißt es explizit: Some elements only have a start-tag without an end-tag. Das ist also alles nichts Neues und HTML-Parser wissen seit jeher mit den fehlenden Tags umzugehen. Aber mit den Browsern ist es wie mit den gallischen Dörfern – irgendwer leistet immer Widerstand und das gern auch mehrere Epochen lang. Man nehme einmal folgenden hamlos aussehenden HTML-Schnipsel:

<!DOCTYPE html>
<head>
<title>Hallo</title>
<div><form>Welt</form></div>

Was hier passieren soll, ist logisch: nach dem </title>-Tag müsste der Browser merken, dass das nun folgende <div> nichts für das Head-Element ist und entsprechend ein Body-Element einfügen. Genau das machen auch alle Browser, inklusive der IE-Familie, doch letztere macht auch noch ein bisschen mehr als das:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<html>
    <head>
        <title></title>
        <form>
            <body>
                <div>
                    Welt
                </div>
            </body>
        </form>
    </head>
    <body>
        <div>
            Welt
        </div>
    </body>
</html>

Ich bin mir noch nicht ganz darüber im klaren, was hier genau passiert, aber richtig ist dieses Ergebnis sicher nicht. Dass der Title nicht in der DOM-Ansicht des IE erscheint ist (so wie ich das sehe) normal, ebenso das Austauschen des Doctypes. Der folgende Elementsalat ist es definitiv nicht. Und sobald man an der richtigen Stelle ein <body>-Tag einfügt, macht der IE alles richtig:

<!DOCTYPE html>
<head>
<title>Hallo</title>
<body>
<div><form>Welt</form></div>

Ergebnis:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<html>
    <head>
        <title></title>
    </head>
    <body>
        <div>
            <form>
                Welt
            </form>
        </div>
    </body>
</html>

So lange man also dem IE sagt, wo genau das Body-Element beginnen soll, passiert nichts schlimmes. Mir war diese Problematik bisher immer deshalb entgangen, weil ich immer ein Body-Starttag plus Conditional Comments verwende um CSS-Fehler im Internet Explorer auszubügeln. Ich danke Francesco für den sachdienlichen Hinweis auf diesen Internet-Explorer-Facepalm du jour.

Warum Websites ohne JavaScript zu funktionieren haben

Veröffentlicht am 9. November 2010

Ich habe noch einen halbfertigen Rant auf Halde, in dem ich am Beispiel eines gewissen, aus unerfindlichen Gründen populären E-Commerce-Systems (dessen Name mit M anfängt und mit agento aufhört) auf Websites schimpfe, die ohne JavaScript nicht funktionieren. Da ich mir aber ziemlich sicher bin, dass ich mich dort gleich mehrfach im Ton vergriffen habe, lösche ich diesen Text jetzt und lasse Jenn Lukas sprechen. Die gute Frau bringt die wichtigsten Gründe nämlich in wesentlich zivilisierterer Form vor, als ich mir das gelingen würde und liefert uns einen schönen kurzen Vortag, den man wunderbar als Munition gegen die meine-Website-muss-ohne-JS-nicht-funktionieren-Fraktion verwenden kann:

Jenn Lukas - JSConf 2010 auf Blip.tv

Alle guten Gründe hin und her – was mich an JS-untauglichen Webseiten mehr als alles irritiert, ist dass es sie überhaupt gibt. Wenn man nur kurz überlegt, bevor man draufloshackt, passieren ohne JS benutzbare Websites wie von selbst. Unobtrusive JavaScript ist kein Hexenwerk, sondern, sofern man seine Auszeichnungs- Gestaltungs- und Script-Schichten sauber trennt, fast unvermeidlich. Um Seiten zu bauen, die nur mit JavaScript funktionieren, muss man sich richtiggehend anstrengen. Und mir ist nicht wirklich klar, was in den Köpfen jener vor sich geht, die sich diese Mühe machen und derartiges HTML an die Öffentlichkeit lassen:

<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>

Klar, wenn man ein hyper-dynamisches neues Webapp rund um neueste JavaScript-Features herum konstruiert und das Projekt ohne JS prinzipbedingt nicht funktionieren könnte, wäre das etwas anderes. Aber eine herkömmliche Website oder einen Onlineshop mutwillig oder fahrlässig fest an JS zu binden, ist, als würde man über das Schiebedach in ein Auto einsteigen. Das kann man sicher so machen, aber wenn vorher nur kurz nachdenkt und entsprechend plant, kommt man ohne zusätzliche Mühen auch anders in die Karre – und sieht dabei dann auch nicht aus wie ein Vollhonk.

Keine Angst vor minimalem HTML(5)!

Veröffentlicht am 8. November 2010

Nach all den Jahren, in denen sich XHTML 1 größter Beliebtheit erfreute, sieht für viele Webworker so etwas aus wie ein einziger Syntaxfehler:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<p class="welt">Hallo Welt!
<ul>
    <li>Lorem
    <li>Ipsum
    <li>Dolor
</ul>

Da fehlen zwar einige Start- und End-Tags, aber tatsächlich ist das ein absolut gültiges HTML(5)-Dokument. Man kann das gleiche Dokument natürlich auch so schreiben …

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta charset="utf-8" />
        <title>Hallo Welt!</title>
    </head>
    <body>
        <p class="welt">
            Hallo Welt!
        </p>
        <ul>
            <li>Lorem</li>
            <li>Ipsum</li>
            <li>Dolor</li>
        </ul>
    </body>
</html>

… aber hat man etwas davon? Der Browser (jeder Browser) baut aus beiden HTML-Schnipseln das exakt gleiche DOM und damit die exakt gleiche Website zusammen. Tags wie <body> und </li> werden vom HTML-Parser auf eigene Faust an den richtigen Stellen eingebaut, so dass es im Endeffekt völlig egal ist, ob man HTML in der Spar-Variante schreibt, das XHTML-Lookalike nimmt oder sich seine eigene Mischform zusammenkombiniert. Welche Tags man unter welchen Umständen auslassen kann erklären unter anderem die HTML5-Spezifikationen.

Die Präsentation des ersten HTML-Schnipsels sorgt manchmal für erhebliches Gruseln, doch wenn man mal die ersten Abwehrreflexe sieht unaufgeräumt aus und kenne ich nicht überwunden hat, wird klar, dass minimales HTML durchaus seine Vorteile hat: man tippt schließlich weniger und transferiert weniger Bytes zum Browser des Users. Das Einzige, auf das man manchmal aufpassen muss, sind die Inhalte an den Grenzen ausgelassener Tags. Angenommen dies wäre unser HTML:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<script>alert("Hello World!")</script>
<p class="welt">Hallo Welt!
<!-- Saluton Mondo! -->

Wo werden hier </head> und </body> eingefügt? Landen der Kommentar und das <script>-Element außerhalb oder innerhalb des Bodys? Die Antwort: das Script landet im Head und der Kommentar als letztes Element im Body. Der Parser schließt den Head erst, wenn er das erste Element antrifft, dass keinesfalls im Head vorkommen kann, was in diesem Fall das <p> wäre. Gleiches gilt beim Kommentar, denn der könnte zwar auch erst nach dem Body kommen, aber der Parser hat keinerlei Anlass, den Body vor dem Kommentar zu schließen. Wenn es bei solchen zweideutigen Elementen wie Scripts und Kommentaren mal wirklich wichtig ist, was in solchen Grenzgebieten wo landet sind die optionalen Tags von unter anderem <html>, <body> und <li> das Mittel der Wahl, aber sonst? Kann man machen, muss man nicht.

Update: Lest das hier um zu verhindern, dass euch fehlende Body-Starttags im IE in den Hintern beißen.

Zur „HTML5-ist-noch-nicht-fertig-Debatte“

Veröffentlicht am 11. Oktober 2010

Im Moment werden aus mir unbekannten Gründen an allen Ecken und Enden des Webs Traktate darüber geschrieben, ob/wann/inwiefern HTML5 „fertig“ oder „einsetzbar“ ist. Dabei ist die Lage eigentlich ganz simpel: HTML5 (was immer man darunter auch versteht) ist in der Tat nicht „fertig“ im Sinne eines Webstandards wie etwa HTML 4.01. Es ist allerdings auch nicht vorgesehen, dass HTML5 je in diesem Sinne „fertig“ sein wird! Der momentane Plan ist, dass es nie ein HTML 6 geben wird, sondern dass alle Neuerungen, die sich die Browserhersteller so ausdenken, nahtlos in HTML5 einfließen – in dem Maße, in dem einige Teile von HTML5 stabiler werden, werden also immer wieder neue Baustellen aufgemacht. HTML5 ist prinzipbedingt nicht „fertig“ und wird es nie sein! Ob und wann man es in Teilen einsetzt, sei jedem selbst überlassen, aber klar ist: vom Abwarten wird es auf keinen Fall besser, stabiler oder fertiger.