Weil im Moment Diagramme wie dieses, Listen wie diese und Websites wie diese die Runde machen, sehe ich mich gezwungen tatsächlich trotz geplanter Blogpause diesen Post vorzuziehen. Es ist nämlich so, dass die Ergebnisse von HTML5-Feature-Detektoren nicht für mehr zu gebrauchen sind, als für Witze (Quelle). Der Grund: Die Detektoren prüfen via Javascript, ob Feature X implementiert ist, und nicht, wie es implementiert ist, also ob es schon zu gebrauchen ist. Und es ist zur Zeit sehr oft der Fall, dass eine HTML5-Funktion in einem Browser zwar vorhanden ist, aber entweder buggy oder gar nur ein reiner Platzhalter ist!
Ein gutes Beispiel ist das ImageData-Interface und dessen CanvasPixelArray, über das man bei einem Canvas-Element einzelne Pixel auslesen kann.
// Pixel für einen Ausschnitt auslesen
var imgData = context.getImageData(200, 80, 80, 80);
for(var i = 0; i < imgData.data.length; i++){
// Mache irgendwas mit den Farbwerten der Pixel
}
Ist es in Webkit vorhanden? Ja! Ist es ein Array wie vom Standard vorgeschrieben? Ja! Sind denn auch Pixel drin? Nein (Update: Scheint nur bei mir der Fall zu sein, siehe Kommentare). Für einen Feature-Detektor wäre dies trotzdem ein vorhandenes Feature, das die volle Punktzahl abräumt. Noch ein Beispiel: Das dataTransfer-Objekt in Webkit-Browser, das normalerweise den Datentransfer in Drag&Drop-Operationen übernimmt.
// Drag-Start-Event, setzt das dataTransfer-Objekt
dragme.ondragstart = function(event){
event.dataTransfer.setData('hallo', 'welt');
event.dataTransfer.effectAllowed = 'move';
};
// Drop-Event
dropme.ondrop = function(event){
alert(event.dataTransfer.getData('hallo'));
};
Ist es in Webkit vorhanden? Ja! Ist es ein Objekt wie vom Standard vorgeschrieben? Sind die Getter und Setter vorhanden? Ja! Kann man denn damit auch wirklich Daten transferieren? Nein. Implementiert Webkit das draggable
-Attribut? Nein, stattdessen gibt es einen proprietären CSS-Hack.
Nur um das ganz klar zu machen: Dererlei ist für einen Detektor kaum zu ermitteln, insofern ist das hier keine Kritik an html5test.com und Konsorten. Und es ist durchaus sinnvoll, dass ein Browser halb fertige Features an Bord hat – wie soll man diese denn sonst testen? Klar ist aber auch, dass Feature-Detektoren eine für Webentwickler nicht brauchbare Aussage machen. Für hypende Marketing-Fritzen mag das gut genug sein, für Webworker eher nicht.
Ein letztes Beispiel: das <input type="date">
funktioniert in Webkit insofern, als dass es nicht wie gänzlich unbekannte Input-Elemente in ein <input type="text">
umgewandelt wird. Allerdings wird von dem Browser (anders als bei Opera) kein Datumspicker o.Ä. bereitgestellt. Dies ist zwar auch nicht explizit von den Spezifikationen vorgeschrieben, aber ob man hier von einer vollständigen Implementierung sprechen kann, ist zumindest diskutabel. Für einen HTML5-Feature-Detektor ist die Sache hingegen klar: Safari unterstützt diesen Teil von HTML5. Ich würde dieser Diagnose nicht unbedingt zustimmen.
Fazit: Die Schwarz-Weiß-Welt, die ein HTML5-Feature-Detektor oder HTML5-Support-Chart malt, existiert so nicht. Nicht mal im Ansatz. Für PR und Hype sind diese Dinger toll, für mehr nicht. Seid ihr hypende PR-Leute?
Kommentare (10)
Dominic ¶
8. Juni 2010, 16:49 Uhr
Du hast zwar recht, dass die Feature-Detektoren nicht immer das gelbe vom Ei sind (oder sein können), aber der Ansatz vorhandene Features zu testen, statt Browser, ist ein durchaus nobler.
Dein erstes Beispiel kann ich auch nicht so ganz nachvollziehen. Ich habe eine einfache Funktion zum Nearest-Neighbour-Scalen eines Canvas-Elements, die tadellos in FF, Chrome, Safari und Opera funktioniert - sowohl unter Windows als auch OSX. Dazu benutze ich das angesprochene ctx.getImageData() und den obj.data Array den ich davon bekomme.
Evtl. fliegt die Funktion bei großen Bildern auf die Nase!? Hast du einen konkreten Use-Case der in FF funktioniert und in Safari/Chrome nicht?
Peter ¶
8. Juni 2010, 17:02 Uhr
Zitat Dominic:
Und wofür ist dieser Gesinnungstest dann gut?
In der Tat: man das kann das auslesen, habe ich gerade in Chrome versucht. Du hast also Recht. Aber man (ich) kann es nicht setzen. Eine Idee woran das liegt?
Dominic ¶
8. Juni 2010, 17:31 Uhr
Zitat Peter:
Aufwärtskompatibilität.
Wenn ich mit JS frage "bist du Opera 10.5x?" und daraus schließe, dass der Browser Feature Y nicht beherrscht, mag ich vllt. bei Version 10.52 richtig liegen und bei 10.53 nicht mehr. Und eine so haarkleine Abfrage nach Browser-Versionen ist natürlich alles andere als praktikabel.
Was ich sagen will: "Feature-Sniffing" ist im Gegensatz zu "Browser-Sniffing" der deutlich bessere Weg. Perfekt aber ist auch der nicht.
Auch das funktioniert bei mir ohne Probleme. Ansonsten könnte ich ja meine gescaltes Bild nicht sehen. Ich benutze dazu allerdings 2 Canvas Elemente: einen für das Source-Bild und einen (in der gescalten Größe) für das Target.
Aber auch das direkte Setzen von Pixeln in nur einem Canvas sollte eigentlich funktionieren. Beachte, dass das zurückgegebene Array Width * Height * 4 Elemente enthält (RGBA). Alle in der Range von 0-255. Evtl. versuchst du einen "ganzen" Pixel auf einmal zu setzen - a la 0xff00ffff?
Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-imagedata-data
Peter ¶
8. Juni 2010, 17:36 Uhr
Würde ich nicht so sagen. Man muss, wenn überhaupt, beides kombinieren – Feature ermitteln und dann bekannte Abweichler im Sinne des Artikels wieder abweisen. Alles andere ist jeweils nur die halbe Miete.
Ne. Ein derartiges danebengreifen würde doch sicher auch irgendwelche Exceptions nach sich ziehen ;)
Ich update mal den Artikel mit Verweis auf deinen Kommentar.
Dominic ¶
8. Juni 2010, 17:49 Uhr
Sorry, Nachtrag: der Pixel Array den du bekommst, ist auch nur eine Kopie der "echten" Pixel des Canvas Elements. Wenn du mit dem Manipulieren der Pixel fertig bist, musst du das Pixel Array mit ctx.putImageData() wieder zurück in den Canavs kopieren.
Zum Feature vs. Browser Sniffing hast du natürlich recht: wenn dir solche Edge-Cases bekannt sind, musst du korrekterweise leider beides testen. Ändert aber imho nichts daran, dass Feature-Testing der "noblere" Ansatz ist - sofern er denn korrekt funktioniert :)
Felix Nagel ¶
8. Juni 2010, 18:03 Uhr
Interessanter Artikel. Danke Peter.
Zitat Dominic:
Dem würde wohl auch das jQuery Team zustimmen, die haben ja vor einiger Zeit von browser auf feature detect umgestellt:
http://api.jquery.com/jQuery.support/
erlehmann ¶
9. Juni 2010, 08:14 Uhr
Der Update-Link zu den Kommentaren wird im Feed nicht richtig umgebaut, da er relativ zu dieser Seite ist. Ich schlage vor, so etwas in Zukunft absolut zu setzen.
Mario Fink ¶
9. Juni 2010, 10:18 Uhr
Die immer mal wieder auftauchenden HTML5 Infografiken mögen vielleicht nicht als praxistaugliche Referenz dienen – sie geben aber m.E. einen schnellen Überblick über die Richtung, die die Browserentwickler eingeschlagen haben. Besonders beim IE9 immer wieder überraschend. Man darf gespannt sein.
ChrisB ¶
10. Juni 2010, 15:44 Uhr
Kann nur bestätigen, dass ImageData bzgl. Canvas in Safari 4/Win problemlos funktioniert. Dass man nur eine „Kopie“ der Pixeldaten bearbeitet, und diese Änderungen nicht on-the-fly umgesetzt werden, sondern erst, wenn man die Daten explizit mittels putImageData zurückschreibt, ist im übrigen vollkommen korrekt, das handeln auch die anderen unterstützenden Browser ganz genauso.
Patrick H. Lauke ¶
17. Juni 2010, 12:06 Uhr
Ein schoenes Beispiel, auf das ich gerade gestossen bin: Chrome zeigt bei http://html5test.com/ an, dass es alle neuen input-types versteht...was aber im Endeffekt nicht so stimmt, da keine UI oder Validierung eingebaut ist...
Somit stimme ich dir natuerlich 100% zu.