Und noch mehr Fragen zu HTML5 beantwortet

Achtung: dieser Beitrag ist alt! Es kann gut sein, dass seine Inhalte nicht mehr aktuell sind.

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.

Kommentare (5)

  1. Matthias Mees

    19. März 2012, 15:50 Uhr

    Zur Update-Aufforderung sei angemerkt, dass man dieses reduzierte IE-Stylesheet nicht einmal selbst schreiben muss. Dafür gibt es ja das Universal IE6 Stylesheet.

    Ganz zu schweigen davon, dass die Updateaufforderung bei Leuten, die technisch nicht in der Lage sind, ein Update einzuspielen oder einen anderen Browser zu verwenden, nutzlos verpufft.

  2. Alex

    19. März 2012, 15:51 Uhr

    Hallo Peter,
    wer hätte gedacht, dass ich mit meiner Frage gleich in die Liste aufgenommen werde. Vielen Dank nochmals für die Hilfe letzte Woche!

  3. Emanuel

    19. März 2012, 17:07 Uhr

    zum thema parseInt möchte ich anmerken, dass man im zweifelsfall als zweites argument das gewünschte zahlensystem mit übergeben kann: parseInt('08', 10).

    alternativ kann man auch mit bitwise-operatoren arbeiten: '08' | 0.

    letzteres scheint performance-technisch die beste lösung zu sein – http://jsperf.com/parseint-01

  4. Janek

    19. März 2012, 18:02 Uhr

    Webfonts in Canvas: ich habe die Erfahrung gemacht, dass das Zeichnen das Canvas bei bei onload statt schon bei DOMContentLoaded hier ziemlich zuverlässig ist. Für simple Dinge wie eine Canvas-Tagcloud reicht das.

    Was die Browserkompatibilitätsmeldung angeht, so denke ich, dass das zielgruppenabhängig ist. Bei einem normalen Endkundenshopsystem sollte man das besser unterlassen (wobei ein dezenter Hinweis vielleicht nicht verkehrt ist), aber bei Seiten, die sich mehr an technisch versierte Leute richten, finde ich das in Ordnung.
    Ich habe bei mir z.B. ein fettes Banner eingebaut, dass IE-lte-8-Nutzern angezeigt wird zusammen mit einem Basis-Stylesheet, das funktioniert, aber nicht schön aussieht (und noch unschöner, wenn kein JS zur Verfügung steht, das die HTML5-Elemente reparieren könnte).
    Sofern die Zielgruppe damit umgehen kann, ist das IMHO in Ordnung. Außerdem ist es immer ganz unterhaltsam zu sehen, welche Crawler so alle alte IE-Engines nutzen um ihre Screenshots zu rendern. :-)

  5. Thomas

    20. März 2012, 07:26 Uhr

    Das mit den Oktalzahlen ist schon Teil vom Standard (ES3); allerdings steht da, dass der Browser die Wahl hat: Entweder oktal oder dezimal – autsch!

    Zum Thema Validator: Es gibt keinen "HTML5-Standard". Allenfalls eine Working Draft, die weit davon entfernt ist, zur Recommendation zu werden.
    Man muss sich also immer vor Augen halten, dass man hier mit noch nicht fertiggebackenen Features experimentiert. Selbst wenn der Validator den aktuellen Stand der Working Draft wiederspiegeln würde, wäre das noch längst keine Garantie dafür, dass ein einmal validiertes Dokument nächste Woche immer noch validiert.
    Also: Testen ist besser als Validieren.

Die Kommentarfunktion ist seit Juli 2014 deaktiviert, weil sie zu sehr von Suchmaschinenoptimierern für manuellen Spam mißbraucht wurde. Wenn du Anmerkungen oder Fragen zum Artikel hast, schreib mir eine E-Mail oder melde dich via Twitter.

Folgt mir!

Kauft mein Zeug!

Cover der HTML5-DVD
Infos auf html5-dvd.de, kaufen bei Amazon

Cover des HTML5-Buchs
Infos auf html5-buch.de, kaufen bei Amazon

Cover des CSS3-Buchs
Infos auf css3-buch.de, kaufen bei Amazon