Peter Kröner, Webtechnologie-Erklärbär

Formulare erstellt man in MODx Revolution (bekanntermaßen das beste CMS der Welt) mit einem neuen Snippet namens FormIt. FormIt ist der Revo-Nachfolger von eForms und ein gutes Stück weniger krampfig als eForms, hat es doch den Vorteil, Formulare und ihr Zubehör in wesentlich weniger großem Umfang über unzählige Chunks zu verteilen. Der größte Haken an FormIt ist meiner Meinung nach die noch etwas löchrige Dokumentation, die sich zum Beispiel darüber ausschweigt, wie man mehr als eine FormIt-Instanz auf einer Seite unterbringt, ohne dass sich diese in die Quere kommen.

Früher bei eForms behob man dieses Problem, indem man dem Snippet via Parameter jene Formular-ID mitteilte, um die das Snippet sich zu kümmern hatte. Ganz ähnlich geht es auch bei FormIt, nur auf etwas „formularigere“ Art und Weise: man teilt dem Snippet im Parameter submitVar den Namen eines Formularfelds mit, das als Identifikator fungiert – wohl in aller Regel ein Input vom Typ hidden, das speziell für diesen Zweck eingebaut wurde. Das könnte in Aktion dann so aussehen:

<form action="weblog/" method="post">
<input type="hidden" name="meinformular" value="1">

...

</form>

Da in diesem Fall $_POST["meinformular"] nur 1 ist, wenn auch wirklich das fragliche Formular abgesendet wurde, weiß die fragliche FormIt-Instanz wann sie in Aktion zu treten hat und wann sie Post-Daten ignorieren kann – denn die Formulare anderer FormIt-Instanzen übertragen eben keine meinformular-Variable.

Die Existanz von submitVar habe ich das über den Bugtracker des Projekts bei Github in Erfahrung bringen können – denn dokumentiert ist das Ganze wie gesagt nicht, Google liefert nichts Verwertbares und den Code von auch nur ein klein wenig komplexeren Revolution-Komponenten kann man ebenfalls nicht immer locker durchblicken. Schon doof dass es solche Doku-Löcher gibt, denn was nützt einem beste CMS der Welt, wenn man nicht auch mühelos nachlesen kann, wie es zum funktionieren zu bewegen ist?

Mein HTML5-Buch ist seit heute endlich auch als E-Book zu haben! Steter Tropfen höhlt den Stein – nachdem die Anfragen nach einer papierfreien Version einfach nicht nachgelassen haben, kann man das gute Stück nun also auch digital erstehen. Der Inhalt ist mit dem der Totholz-Fassung identisch: alle wichtigen Bereiche von HTML5 werden anhand von anschaulichen Beispielen besprochen, von den neuen semantischen Elementen über <audio>, <video> und <canvas> bis hin zu Geolocation- und Drag&Drop-APIs. Hinzu kommen die Hintergründe der Entstehung von HTML5, zahlreiche Hacks und Tricks sowie ein umfangreicher Anhang mit vielen Tabellen und Referenzen zum Nachschlagen. Lesermeinungen gibt es bei Amazon und Gerrit.

Ich küre morgens via Twitter gerne mal eine Seite des Tages. Meist handelt es sich dabei um lustige oder fossile Relikte aus grauer Web-Vorzeit und als ich heute morgen die zweite von den beiden genannten zwitscherte, dachte ich, es wäre doch mal interessant zu beleuchten, warum so Dinge wie <frameset> und <marquee> in den HTML5-Spezifikationen stehen und dort haarklein definiert wird, wie sie zu funktionieren haben.

HTML5 ist zwar die nächste Version von HTML, aber man ist sich darüber im Klaren, dass sich fast 10 Jahre HTML-Geschichte nicht einfach so in Rauch auflösen werden, also veraltete Elemente, Attribute und Technologien nicht einfach aus den Websites dieser Welt verschwinden, bloß weil sie sie jetzt überholt sind. Normalerweise wäre das völlig egal – man würde einfach eine neue Spezifikation unter Ausklammerung der veralteten Elemente schreiben, maximal in einem Nebensatz erwähnen, dass es sie mal gab. So heißt es beispielsweise in den XHTML 1-Spezifikationen zu <isindex> lediglich:

The isindex element is deprecated in favor of the input element.

Im Gegensatz dazu spezifiziert HTML5 sogar das Marquee-Element mit allen Details, inklusive aller HTML-Attribute und einer JavaScript-API. Auch Frames und historische HTML-Attribute wie align und cellpadding erhalten diese Behandlung. Warum ist das so?

Bisherige HTML-Spezifikationen waren für HTML-Autoren geschrieben. Es stand jeweils drin, zu was die einzelnen Elemente und Attribute gut waren und wie man sie benutzt. Die HTML5-Spezifikationen hingegen richten sich auch an jene, die HTML-Implementierungen programmieren, also die Bowserhersteller. Und da ist es natürlich im Sinne eines einheitlichen (eben standardisierten) Verhaltens sinnvoll, auch festzulegen, wie sich jene Dinge verhalten sollen, die nicht Teil des Standards sind. Und genau das macht HTML5 mit den detaillierten Spezifikationen zu <frameset>, <marquee> und anderen Relikten.

Der Abschnitt mit all den Details und APIs zu den ganzen Fossilien ist außer zur Erheiterung (eine erst gemeinte JavaScript-API für das Marquee-Element?) für HTML5-Autoren nicht weiter wichtig und richtet sich nur an Browser-Programmierer. Alles was der Webworker zum Thema „abgeschaffte Elemente und Attribute“ wissen muss, steht im Abschnitt über Non-conforming features – eine einfache Liste mit allem, was man in HTML5 nicht mehr verwenden sollte.

Das <wbr>-Element ist, soweit ich feststellen konnte, eine Erfindung aus Netscape 4. Was es in HTML5 zu suchen hat weiß ich nicht (es ist nicht nur archaisch, sondern auch recht nutzfrei), aber der Chronistenpflicht wegen habe ich es letzte Woche mal erforscht. Das <wbr>-Element repräsentiert eine Möglichkeit zum Zeilenumbruch, d.h. da wo es steht, kann der Browser einen Zeilenumbruch einfügen, wenn er das brauchen sollte.

Beispiel:

<h1>Mit <code>&lt;wbr&gt;</code></h1>
<p style="width:100px; border:1px solid red;">
    Donau<wbr>dampf<wbr>schiff<wbr>fahrts<wbr>gesellschaft
</p>

<h1>Ohne <code>&lt;wbr&gt;</code></h1>
<p style="width:100px; border:1px solid red;">
    Donaudampfschifffahrtsgesellschaft
</p>

Ergebnis:

Der Browsersupport ist recht medium, in Opera und Internet Explorer 8 funktioniert <wbr> nicht, wohl aber in allen anderen Browsern inklusive IE7 und IE6. In Opera lässt sich das Problem relativ einfach fixen, indem man per CSS hinter jedem <wbr> ein Zero-Width-Space einfügt:

wbr:after {
    content: "\00200B"
}

Dieses Leerzeichen ist unsichtbar, trennt aber das Wort auf und ermöglicht so einen Zeilenumbruch wie ein normales Leerzeichen. Im IE8 kann man das gleiche mit JavaScript erreichen:

var wbrs = document.getElementsByTagName('wbr');
var num_wbrs = wbrs.length;
if(num_wbrs > 0 && HTMLTextElement && wbrs[0] instanceof HTMLTextElement){
    for(var i = 0; i < num_wbrs; i++){
        wbrs[i].insertAdjacentHTML('afterEnd', '&#x200b;');
    }
}

Hier ist vielleicht noch bemerkenswert, dass die im JS-Code verwendete insertAdjacentHTML()-Methode seit HTML5 auch erstmals Standard ist, was natürlich nicht heißt, dass sie in einer nennenswerten Anzahl Browser funktioniert.

Das <wbr>-Element ist recht nutzlos, da es zwar Wörter trennt, aber keine Trennstriche einfügt. Das Entity ­ macht genau das und ist daher vermutlich in vielen Fällen die bessere Wahl:

<h1>Wbr</h1>
<p style="width:100px">
    Donau<wbr>dampf<wbr>schiff<wbr>fahrts<wbr>gesellschaft
</p>

<h1>Shy</h1>
<p style="width:100px">
    Donau&shy;dampf&shy;schiff&shy;fahrts&shy;gesellschaft
</p>

Ergebnis:

Allerdings weiß ich aus dem Stand gerade nicht, wie aktuell die Browserunterstützung für ­ aussieht – was ich aber mal vor Jahren ausprobiert habe, war die Suchmaschinenfrundlichkeit. Hier gibt es keine großen Probleme zu berichten, bis auf die Produkte aus dem Hause Microsoft ignorieren alle Suchmaschinen ­ und finden auch Keywords, die im HTML entsprechend getrennt sind.

Fazit: auf jeden Fall für mögliche Zeilenumbrüche ­ verwenden und sich angesichts von <wbr> einfach nur fragen, was die HTML5-Jungs und -Mädels in ihren Pausen eigentlich so rauchen.