共用方式為

HTML5 : respect des standards, tests et marketing

  • 發行項

 

Présentation du test disponible sur http://html5test.com/

html5test.com est un test sur le Web écrit Niels Leenheer qui contient (actuellement) une série de 160 tests regroupés en plusieurs catégories :

  • Doctype
  • Canvas
  • Video
  • Audio
  • Geolocation
  • Storage
  • Offline Web Applications
  • Workers
  • Section elements
  • Grouping content elements
  • Text-level semantic elements
  • Forms
  • User interaction

Ce test vérifie si un navigateur prend en charge ou pas HTML5 et les technologies couramment associées au langage de balisage.

Le test retourne 2 notes sur un total de 300 (à l’heure de cet article) :

  • une première note : la note principale
  • une seconde dite note des bonus

Remarque : ce test réutilise (avec son accord) les HTML5 parser tests écrits par Henri Sivonen (qui est un consultant indépendant développant le parser HTML5 de Firefox 4 pour Mozilla. Henri Sivonen participe également au Working Group HTML du W3C)

Informations complémentaires sur HTML5 et les technologies associées:

Le petit texte en bas que personne ne lit jamais :-)  

Source : http://html5test.com/

“The HTML5 test score is only an indication of how well your browser supports the upcoming HTML5 standard and related specifications. It does not try to test all of the new features offered by HTML5, nor does it try to test the functionality of each feature it does detect. Despite these shortcomings we hope that by quantifying the level of support users and web developers will get an idea of how hard the browser manufacturers work on improving their browsers and the web as a development platform.

The score is calculated by testing for the many new features of HTML5. Each feature is worth one or more points. Apart from the main HTML5 specification and other specifications created the W3C HTML Working Group, this test also awards points for supporting related drafts and specifications. Some of these specifications were initially part of HTML5, but are now further developed by other W3C working groups. WebGL is also part of this test despite not being developed by the W3C, because it extends the HTML5 canvas element with a 3d context.

The test also awards bonus points for supporting audio and video codecs and supporting SVG or MathML embedding in a plain HTML document. These test do not count towards the total score because HTML5 does not specify any required audio or video codec. Also SVG and MathML are not required by HTML5, the specification only specifies rules for how such content should be embedded inside a plain HTML file.

Please be aware that the specifications that are being tested are still in development and could change before receiving an official status. In the future new tests will be added for the pieces of the specification that are currently still missing. The maximum number of points that can be scored is 300 at this moment, but this is a moving goalpost.”

Les points positifs du test html5test.com

Comme pour le test ACID3 (maintenu par Ian Hickson de chez Google), html5test.com a le mérite d’être compréhensible et utilisable par tout le monde : il suffit de naviguer sur la page du test pour obtenir un résultat. Plus la valeur obtenue est élevée (aujourd’hui c’est 300 le score maximal) meilleur devrait être le support des nouvelles technologies HTML5 par le navigateur. C’est donc l’outil idéal pour les journalistes, les marketeux ou les personnes souhaitant faire rapidement un comparatif entre navigateurs Web. 

Autre point positif : ce test permet au plus grand nombre d’internautes de prendre conscience de la montée en puissance d’HTML5 et des technologies associées. Il met en lumière l’existence de nombreuses technologies en gestation et dont on entendra de plus en plus parler. C’est à mon avis le point le plus positif de ce test.

Les limites du test html5test.com

Le modèle d’évaluation du test :

Le test de prise en charge se limite à tester l’existence (feature detection) ou pas de la prise en charge de “technologies HTML5”.

Le test ne vérifie pas de la bonne prise en charge des spécifications (l’auteur ne s’en cache pas, cf le texte ci-dessus). En effet, le seul moyen de valider le respect d’un standard tel que HTML5 c’est de valider via les tests unitaires proposés par le W3C (qui reste le référent des standards du Web).

Un test unitaire est par définition très simple et doit permettre aux développeurs de navigateurs Web de valider le respect de l’interprétation de la norme par leur navigateur. L’objectif ultime étant d’obtenir le même comportement sur l’ensemble des navigateurs (et éviter le développement de sites web spécifiques à telle ou telle version d’un navigateur)

Exemple de test unitaire du W3C (celui-ci concerne une des propriétés de Canvas) : http://test.w3.org/html/tests/approved/canvas/2d.drawImage.image.incomplete.omitted.html 

Résultat du test sur IE 9 RC :

Résultat du test sur Google Chrome 9.0.597.98 :

Ceci n’est bien entendu qu’un exemple illustrant la différence de comportement et donc de support du standard HTML5 défini par le W3C entre 2 navigateurs. Pourtant, ces 2 navigateurs obtiennent la note maximale concernant Canvas dans le test html5test.com.

 Autre exemple de test de détection de fonctionnalités :

 

La couverture du test :

Comme cité précédemment, le test html5test.com couvre aujourd’hui 160 tests de détection sur le langage de balisage HTML5 et les technologies associées.

Il faut cependant être conscient :

  • Que la majorité des technologies concernées n’ont pas encore leurs spécifications à l’état de standard (au W3C). L’auteur du test est parfaitement clair là encore sur ce point.
  • Qu’une fois que ce sera le cas il faudra concevoir des énormes batteries de tests unitaires (Philippe Le Hégaret du W3C parle de 60 000 tests unitaires) pour mettre à l’épreuve ces spécifications pour garantir une implémentation harmonieuse entre les différents navigateurs. Ici on est bien au delà de la détection mais plutôt sur l’aspect bonne implémentation
  • Que certaines spécifications ou fonctionnalités testées ont depuis été dépréciées mais demeurent néanmoins présentes dans le test car certains éditeurs les ont implémenté (là encore, l’auteur l’écrit)
    • WebSocket

A l’heure actuelle, les éditeurs ayant déjà implémenté les spécifications non finalisées de Websocket ont partiellement (Mozilla et Opéra) fait le choix de le désactiver par défaut suite à la découverte de vulnérabilité dans la conception même du protocole.

Chris Heilmann de la Fondation Mozilla a déclaré (le 8 décembre 2010, cf ici) à ce sujet : “Right now, your Websocket solutions will not work in Firefox 4 final. Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release. The code will remain in the tree to help development, but will only be activated when a developer sets a hidden preference in Firefox (the same applies to Opera)…. Mozilla is still excited about what WebSocket offers and we’re working hard with the IETF on a new WebSocket protocol.”

Alors pourquoi attribuer des points sur une spécification obsolète qui va être complétement revue ? si ce n’est pour élever le score de certains éditeurs (sous réserve de réactiver les WebSocket dans le navigateur)

  •  
    • Storage

Effectivement comme indiqué, Web SQL Database a été déprécié, ne sera jamais un standard du W3C et n’est plus maintenu comme le confirme la dernière version du document de spécifications datant du 18 novembre 2010 (cf. capture ci-dessous). Du coup pourquoi le maintenir dans la batterie de tests ? (si ce n’est pour élever le score de 3 éditeurs)

Cliquer pour agrandir

Informations complémentaires :

Le bachotage des tests par les éditeurs de navigateurs :

Comme toute évaluation de connaissances, il existe 2 approches pour bien passer un examen : travailler les questions spécifiquement demandées ou travailler le sujet dans sa globalité afin de pouvoir répondre à n’importe quelle question du sujet. Donc aujourd’hui, les éditeurs de navigateurs, bien conscients de l’importance marketing de ce test, ont tout intérêt à bien paramétrer leur navigateur (laisser activer ou réactiver WebSocket…) et à implémenter spécifiquement les fonctionnalités testées afin d’obtenir le score le plus haut.

C’est de bonne guerre mais du coup cela peut clairement avoir un impact sur la perception du grand public vers qui sont relayés les scores du test.

Ce type de comportement des éditeurs se retrouve avec d’autres tests tel que ACID3 où Microsoft IE 9 et Firefox 4 ne sont pas à 100/100.

Informations complémentaires :

La pertinence des éléments testés :

De nombreux éléments testés et notés ne font pas parties des spécifications HTML5 en cours de standardisation par le W3C ou sont plus qu’expérimentales ou ne sont pas encore implémentées dans tous les navigateurs :

  • WebSocket (cf. plus haut dans cet article)
  • Web SQL Database (cf. plus haut dans cet article)
  • Local Devices (cf.  l’élément Device définit dans le document du WHATWG  : http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices) qui semble plus qu’expérimental d’après les commentaires des spécifications (qui ne sont d’ailleurs pas présentes dans le document officiel du W3C)

Pour les balises audio et vidéo, le test vérifie également la présence de codec même si les codecs ne sont jamais cités dans les spécifications du W3C. Il faut quand même reconnaitre que sur ce point, l’auteur du test le précise bien mais il donne quand même des points (bonus)

Exemple 1 : les codecs audio supportés

Exemple 2 : les codecs vidéos

La méthode de notation et la pondération des notes :

Actuellement la base de notation du test html5test.com est la suivante (catégories triées par ordre décroissant):

  • 38 point sur la catégorie Forms
  • 30 points sur la catégorie Elements
  • 27 points sur la catégorie Vidéo
  • 25 point sur la catégorie User interaction
  • 25 points sur la catégorie Communication
  • 20 points sur la catégorie Storage dont 10 points réservés à 3 éditeurs et concernant des spécifications dépréciées mais implémentées
  • 20 points sur la catégorie Canvas
  • 20 points sur la catégorie Audio
  • 20 points sur la catégorie Local Devices pourquoi autant de points sur une spécifications inexistante au W3C et encore non implémentée / testable dans les navigateurs ?
  • 14 points sur la catégorie Web Applications
  • 11 points sur la catégorie Parsing rules
  • 10 points sur la catégorie MicroData
  • 10 points sur la catégorie Geolocalisation
  • 10 points sur la catégorie WebGL
  • 10 points sur la catégorie Files

Pour les balises audio et vidéo, l’auteur du test attribue des points bonus en fonction du nombre de codecs supportés ce qui assez supprenant et pas forcément équitable (ne serait-ce pour la fondation Mozilla qui nous pouvons le comprendre ne souhaite implémenté que des codecs libres de royalties dans sa solution).

De même, ce test qui ne se limite pas, vous l’aurez compris, uniquement à la balise HTML5 n’inclue pas les technologies de feuille de style (CSS3) qui sont pourtant aussi importantes (voire plus) que certaines technologies mesurées par HTML5test.

A titre indicatif, une étude de Forester Consulting baptisée "The Evolution Of Web Development - An Inflection Point In Web Design And Evolving Standards Sets The Stage For HTML 5 Adoption“  et publiée en septembre 2010  (Base : 210 développeurs Web (USA & Royaume Uni)) indique qu’en terme de technologies autour de HTML5, la majorité des développeurs Web interrogés sont principalement intéressés par les feuilles de styles (CSS3), les balises Audio et Vidéo. Pour les autres technologies, la fragmentation des réponses est plus importante.

En comparant les technologies qui intéressent les développeurs Web (en septembre 2010) versus les pondérations de points d’html5test.com, il est difficile d’y voir une corrélation. La répartition des points d’html5test.com est donc plutôt obscure ou pas forcémement représentative de ce que les développeurs Web attendent d’HTML5 & cie.

Moderncar2011test : une métaphore par l’absurde

Et si on créée aussi un test permettant de tester “la modernité” des voitures sur un modèle similaire à html5test (même si la comparaison entre l’industrie informatique et l’industrie automobile n’est pas ce qui est le plus pertinent..), cela ressemblerait à ça :

Et maintenant, juste pour l’illustration, voici les deux voitures comparées dans ce test.

Comme quoi, il est facile de créer un test. Le rendre pertinent sur les résultats c’est une autre histoire.

 

Conclusion

html5test.com fait partie des inombrables tests disponibles en ligne permettant d’évaluer et de comparer les navigateurs entre eux. Il faut lui reconnaitre l’avantage de favoriser l’intérêt des internautes pour HTML5 en présentant de manière très simple une bonne couverture des technologies tournant autour du langage de balisage HTML5. Cependant, comme tout test externe à une organisation de standardisation, il n’a pas de valeur actuellement pour valider le bon respect des spécifications définies dans les standards du Web. Il demeure un indicateur concernant l’implémentation ou pas de fonctionnalités au sein d’un navigateur mais n’en vérifie pas la qualité de l’implémentation.

– Stanislas Quastana -

Tags: HTML5, html5test, html5test.com, CSS3, WebGL, WebSocket, Web+SQL+DB, balise+audio, balise+vidéo, Standards, W3C, tests+unitaires, test+unitaire

Comments

  • Anonymous
    March 15, 2011
    Quand on vois la mauvaise gestion (et non implémentation) du protocole HTTP, de son MIME Content-Type par exemple, c'est pas la peine de placer ce genre de comparaison sur les voitures, IE9 ressemblerais plus à celle de droite sur le coup pour un navigateur. Avant HTML5, essayez déjà de bien implémenter les standards de communication entre système hétérogènes. Et comme d'habitude, cela va être aux développeurs web de corriger vos lacunes, mais au niveau des serveurs  !

  • Anonymous
    March 15, 2011
    Pouvez-vous appuyer vos propos par des références documentés et donner des faits ?

  • Anonymous
    March 23, 2011
    Aahh, en fait IE9 fait tout bien et ce sont les tests qui sont soit bidonnes, soit stupides. D'accord! Alors, ou sont les web workers? drag and drop? File API? animations SVG ? animations et transforms css3? formulaires HTML5? application cache? WebGL? Text shadow? gradients css3? css3 border image? history API? etc etc... Allez, un nouvel article pour nous expliquer comment on peut s'en passer ou pourquoi c'est inutile? Le problème, c'est même pas que ce soit absent dans cette version de IE9, personne n'esperait meme vaguement que IE9 serait au niveau d'un firefox sorti il y a deux ans, le problème, c'est que tout ça sera dans IE10 qui sortira dans 3 ans et en attendant, pour la plus grande joie de tous les développeurs, IE9 va remplacer le boulet qu’était IE6...

  • Anonymous
    March 27, 2011
    @blop : Je n'ai jamais écrit qu'IE9 faisait tout bien. J'ai écrit et démontré que ce test html5test.com était "bidon" Certes il existe plein de technologies gravitant autour d'HTML5 et Microsoft a choisi d'implémenter dans IE9 les spécifications qui étaient les plus "sèches" au niveau des standards définies au W3C. Il demeure des manques, c'est un fait. Mais on parle ici de spécifications qui ne sont pas encore finalisées et qui ne sont pas encore aujourd'hui utilisées à grande échelle. Développer aujourd'hui avec des spécifications encore en cours d'élaboration et interprétées de manière différentes par les différents navigateurs correspond à développer au format propriétaire pour tel ou tel moteur de rendu. C'est donc risqué en terme d'audience sur le Web (on se limite à certains navigateurs et donc on limite son audience / revenu potentiel), c'est risqué en terme d'application si celle-ci s'appuie sur des fonctions qui changent car il faut alors reprendre son code. Pour exemple : le drag and drop a été implémenté pour la première fois (à ma connaissance) dans IE 5 !!! (cf. technet.microsoft.com/.../dd361922.aspx) mais comme ce n'était pas normalisé par le W3C (=propriétaire à un navigateur), la fonction n'a pas été utilisée par tous. Aujourd'hui cette fonctionnalité revient (sous une autre forme mais l'idée est la même) dans les spécifications du W3C et sera réellement exploitable quand elle sera finalisée et utilisable de la même façon quelque soit les navigateurs. Une bonne partie des technos ou spécifications que vous citez sera très probablement dans une prochaine version d'IE  (je croise les doigts sereinement).

  • Anonymous
    February 09, 2012
    Tres interessant ton post. Je ne connaissais pas toutes ces informations. Merci bien pour le partage et bonne continuation.