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

Auch wenn das Weblog den Großteil der letzen Monate stillgelegt war, habe ich natürlich wieder per E-Mail, Twitter, Formspring und andere Kanäle so manche Frage zu HTML5 beantwortet. Diesmal war sogar eine Frage zu JavaScript dabei, um die ich mich natürlich auch gerne kümmere – auch in Sachen CSS, DOM und amderem Webkrempel kann man mich jederzeit löchern! Und weil einige der zuletzt eingegangenen Fragen wieder erheblich zu schade für fortwährende Geheimhaltung waren, werden sie hiermit als ein weiterer Teil der beliebten Serie „Fragen zu HTML5“ befreit.

HTML-Validierung

Nach der Umstellung des doctypes schlägt die Validierung unserer Seiten mit dem W3C-Validator an vielen Stellen fehl - einige davon konnte ich fixen, aber bei den Meta-Tags bin ich nicht ganz sicher, was ich tun soll. Beispiele:

Bad value DC.Subject for attribute name on XHTML element meta: Keyword dc.subject is not registered.
<meta name="DC.Subject" content="" />

Bad value DC.Date for attribute name on XHTML element meta: Keyword dc.date is not registered.
<meta name="DC.Date" content="2011-12-19T14:15:48" />

Die entsprechenden Meta-tags rauszuwerfen ist keine Option, da die SEO-Abteilung sie behalten möchte. Was tun? Sie bei der WHATWG selber definieren bzw. ändern wie in wiki.whatwg.org/wiki/MetaExtensions beschrieben?

Ich würde zu aller erst mal die Option „einfach ignorieren“ in den Raum stellen. Das, was der Validator hier bemängelt, sind allein ungültige bzw. unbekannte Attribut-Angaben, aber so lange nicht die Struktur des HTML kaputt ist, wird das keinerlei negative Folgen für Browser und 99,99% der anderen Endgeräte haben. Was der Browser nicht kennt, ignoriert er einfach. Und wenn die SEO-Abteilung der Meinung ist, diese Meta-Tags wären wichtig, spricht nichts dagegen, sie einfach drin zu lassen. Das macht am wenigsten Arbeit und hat trotzdem keine großen Nachteile.

Unabhängig davon ist der Validator in Sachen HTML5-Syntax auch nicht die letzte Instanz und er hinkt oft etwas hinter dem Standard her. Gerade was kleinere Features angeht (wie z.B. welche Attribute erlaubt sind oder wann man &-Zeichen escapen muss und wann nicht), gibt er oft falsche Auskunft. Das einzige was also wirklich zählt, ist was im Browser funktioniert und was im Standard steht.

Infos zu Browserunterstützung

Auf den WHATWG-Seiten kann ich herausfinden, welcher Tag in den aktuellen Versionen von Safari, Chrome, Firefox und IE unterstützt wird. In Ihrem Buch, z.B. auf Seite 92, 182-13, geben Sie aber die Browser-Versionen exakt an, z.B. Firefox 3.6. Wie kommen Sie zu diesen detaillierten Angaben im Vergleich zur Spezifikation? Haben Sie dies selbst ausprobiert oder steht dies auf einer Website?

Ich habe das seinerzeit selbst durchgetestet und aus diversen Quellen zusammengetragen. Mittlerweile gibt es mit caniuse.com aber eine hervorragende Webseite, die detaillierte Kompatibilitätstabellen zu allem Möglichen sammelt – HTML5, CSS3 und vielem mehr.

Zahlen parsen mit JavaScript

Kannst du mit sagen wieso parseInt('08') 0 ist und parseInt('02') 2?

Das ist einer der vielen „Bad Parts“ in JavaScript. Die Funktion parseInt() macht zwar die Strings zu Zahlen, aber Zahlen mit führender Null werden von Browsern als Oktalzahl behandelt. Das ist im Standard so gar nicht vorgesehen und damit ein Browserbug, der zum Glück vom Strict Mode in ES5 abgestellt wird.

Update-Aufforderungen

Was hältst du von Browser-Update-Aufforderungen in IE auf Seiten, die IE < 8 nicht unterstützen?

Eine Webseite (nicht Webapp) kann man immer in eine für alte Browser komumierbare Form bringen, zur Not, indem man alten IEs einfach alle Styles entzieht. Eine Update-Aufforderung bei gleichzeitig nicht mehr funktionierender Seite fände ich an dieser Stelle einfach nur faul. Wer sich die Mühe macht, eine Update-Aufforderung zu bauen, der kann auch schnell einen auf die Basics reduzierten IE6-Stylesheet anlegen.

Bei Webapplikationen ist das etwas anderes. Wenn bestimmte HTML5-Features zwingend gebraucht werden, ist es OK, entsprechende Systemanforderungen zu formulieren. Wenn das alle anderen Programme auf dieser Welt dürfen, warum nicht auch die Webapps?

Formularvalidierung steuern

Gibt es bei der HTML5 Formularvalidierung eigentlich auch die Möglichkeit, dass man bei dem Kick auf einen bestimmten Submit-Button nicht validiert? Also quasi ein novalidate-Attribute für einen Button bzw. Input-Submit.

Bei Formularen mit mehreren Seiten (z.B. Bestellvorgang) möchte ich einen Zurück-Button verwenden, bei welchem allerdings nicht zwangsläufig das ganze Formular ausgefüllt sein muss. Dennoch sollen bereits ausgefüllte Felder übermittelt werden, was einen normalen Link bzw. die history ausschließt. Hast du eine Idee?

Eine solche Möglichkeit existiert, funktioniert aber nur in wenigen Browsern. Es gibt das novalidate-Attribut für Formulare, mit dem man die Validierung für das gesamte Formular deaktivieren kann und es gibt das formnovalidate-Attribut für Submitbuttons. Wenn man dieses für die speziellen Submits verwendet (also für die, die keine Validierung auslösen sollen) findet die Prüfung nur beim normalen, finalen Submit sattt und nicht mehr bei den Zwischenschritten. Alle weiteren Details verraten die Spezifikationen.

Webfonts und Canvas

Gibt es eine Einschränkung für das Verwenden von Schriftarten in Canvas-Elementen? Ich würde gerne Googles Webfonts verwenden …

Eine Einschränkung gibt es an sich nicht. Das Problem mit Webfonts und Canvas ist nur, dass die Webfonts vollständig geladen sein müssen, bevor man sie auf der Canvas verwenden kann. Und soweit ich weiß, gibt es keine native Möglichkeit in allen Browsern zuverlässig den Zeitpunkt abzupassen, ab dem die (normal via @font-face in CSS eingebetteten) Webfonts da sind. Die Verwendung von Font.js oder Googles WebFont Loader könnte Abhilfe schaffen.

Weitere Fragen?

Eure Fragen zu HTML5, CSS und anderen Webthemen beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.