Lunaweb, une réflexion sur la création web et le marketing Internet

Faut-il utiliser l’intégration en HTML5 en contexte de production ?

Par Kaelig le 16 décembre 2009
No Gravatar

Coder en HTML5Après avoir touché un peu au HTML5 dans mon précédent article, je pense que cette version 5 du langage le plus utilisé du Web va révolutionner la manière de structurer le code des pages et donc des interfaces que nous réalisons au quotidien.

Il y a des pour et des contre, et à travers cet article je vais surtout vous exposer ce qui me semble incohérent ou pas prêt pour la mise en production d’un site codé en HTML5.

Une accessibilité encore sujette à débat

Un des buts de l’HyperText Markup Language en sa version 5 est de rendre le contenu de ses pages plus accessible aux handicapés.

Je n’ai personnellement pas encore eu l’occasion d’utiliser <canvas> et <video> mais il semblerait que ces 2 nouveautés posent un gros souci d’accessibilité. En effet le principe de <canvas> est de manipuler des pixels à l’écran, alors comment décrire cette animation à un lecteur d’écran en direct via un contenu alternatif ?

Autre « souci », l’attribut alt n’est plus obligatoire :

The requirements for the altattribute depend on what the image is intended to represent, as described in the following sections.

Or, on a vu des lecteurs d’écran lire à un aveugle le contenu de l’attribut src quand l’attribut alt d’une image venait à manquer (d’où l’importance de mettre alt=”” sur des images dont la présence est à but exclusivement décoratif). L’intention est bonne car le code serait moins pollué ainsi, mais le parc des machines chez les handicapés visuels n’est pas prêt.

Articles sur l’accessibilité et le HTML5

Certaines technologies pas encore adoptées par tous les navigateurs

Le tag <video> n’est pas supporté par tous les navigateurs et nécessite donc de prévoir un flash en remplacement comme l’explique cet article (en).

Le tag <canvas> est supporté par la plupart des navigateurs modernes, mais dans le cas d’Internet Explorer, nous devrons attendre sa version 9.

Impact du HTML5 sur le référencement

Le HTML dans sa version 5 est fait pour le Search Engine Optimizer ! Le référenceur va y trouver son bonheur.

Les tags comme <header role=”banner”> remplaceront très justement les <div id=”header”>, et la navigation aura enfin son propre tag <nav>. La page ou l’<article> pourront être divisés en plusieurs <section>, et le contenu annexe sera imbriqué dans un <aside>. Bref tout un tas d’éléments pour signifier ce qui est du contenu propre à la page et ce qui n’en est pas.

En revanche, comment dire à un référenceur que l’on pourra inclure une infinité de <h1> dans notre page comme le préconise le groupe de travail sur le HTML5 ?

En effet, d’après le brouillon actuel des spécifications du HTML5, il est fortement recommandé de n’utiliser soit que des <h1>, soit des titres de niveau approprié (que comprendre par là ?).

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

Pour le moment nous ne savons pas l’effet qu’une telle utilisation des titres aura sur notre référencement, mais il y a fort à parier qu’un moteur de recherche rencontrant ce type de code aura bien du mal à hiérarchiser les contenus crawlés. Par exemple, Google recommande officieusement (en) l’utilisation de 2 à 3 titres h1 par page maximum.

HTML5 + Javascript + IE = *$@?

Si la mise en page des documents contenant de nouveaux tags fonctionne parfaitement sous Internet Explorer grâce à une astuce à insérer dans le <head> de votre code HTML :

<!--[if lte IE 8]>
 <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

Le moteur javascript d’Internet Explorer lui, ne parcourt pas correctement le DOM d’un document dont il ne connait pas les tags en natif. Par exemple, ce code ne s’exécutera pas sous IE :

Cufon.set('fontFamily', 'American Typewriter').replace('hgroup h1')

Il faut donc appliquer un ID au hgroup (par exemple #hgroup). On perd clairement l’intérêt sémantique puisqu’on revient au principe d’autrefois : des id sur des DIV.

Ce qui freine la planète dans son élan

Disons-le, le web est un bordel pas possible et 90% des pages sont mal construites ou pas construites du tout. Il est temps qu’un langage approprié au classement et à la hiérarchisation du contenu soit mis au point et fonctionne sur tous les terminaux de la planète.

Le HTML5 va venir nous sauver mais avant, les lecteurs d’écran, moteurs de recherche et navigateurs doivent être mis à jour dans une portion suffisante pour que notre travail ait un sens sur un maximum de terminaux. Sans cela, point de salut pour le HTML5.

D’après un récent communiqué, la compagnie de Redmond souhaite corriger le tir avec Internet Explorer 9. En espérant que l’effort soit réel cette fois.

Alors, on attend encore longtemps ?

Nous devons malheureusement nous plier au monopole de Microsoft car les parts de marché d’Internet Explorer restent supérieures à 60% (en). C’est principalement à cause d’un seul acteur du monde informatique que notre capacité d’innovation est radicalement bridée (tout comme pour le passage à certaines technologies – pour n’en citer qu’un : le CSS2 & 3).

Comme le disais dans mon précédent article, j’aime beaucoup la plupart des innovations contenues dans la version 5 du langage HTML, mais il me semble plus sage d’attendre que le marché soit prêt avant de l’employer sur des sites en production.

Dans quelques années  on pourra revenir sur cet article et le mettre à jour. En attendant, la release des recommandations HTML5 par le groupe de travail est prévue pour fin 2010 (mais le W3C lui-même ne préfère pas trop s’avancer). Rendez-vous en 2022, c’est là que le w3c prévoit de recommander officiellement l’utilisation du HTML5.

Lectures intéressantes

Cela m’intéresse de connaître vos retours d’expérience avec ce langage si vous l’avez récemment utilisé ou si vous pensez l’employer dans l’un de vos projets (perso ou pro), et pourquoi. J’attends vos commentaires à ce propos.

Pour en savoir plus sur l'auteur de cet article...  Kaelig est intégrateur xHTML/CSS et code toujours dans un souci de propreté, d'ergonomie et d'accessibilité. Lire plus d'articles de cet auteur...

Mots-clefs : , , , , ,
Publié dans Standards & Accessibilité |

  • TheSorrow
    Déjà on verra en 2012 si internet existe encore :o
  • C'est bien cela le soucis avec les technologies Web, surtout celles qui sont en bas de la pile : elles sont longues à mettre en application. Des fois, on a envie d'imposer cette mise à jour même si cela aurait des conséquences lamentables...

    Ne faudrait-il pas faire une espèce de certification pour désigner les sites qui contribuent à l'avancée technologique ? Une qualité supplémentaire qui pourrait se vendre mais à un degré supérieur de la validation W3C...
  • «Ren­dez-​vous en 2022, c’est là que le w3c pré­voit de re­com­man­der of­fi­ciel­le­ment l’uti­li­sa­tion du HTML5.»

    C'est parfaitement FAUX.

    Le lien donné pointe vers le wiki du WHAT-WG. En lisant un peu ce wiki, et notamment le passage vers lequel le lien pointe, on devrait comprendre les données suivantes:

    1. Le WHAT-WG n'est pas le W3C. La phrase est donc fausse.
    2. Ce n'est pas le WHAT-WG qui avance la date de 2022, c'est «the editor», à savoir Ian Hickson.
    3. 2022 est une estimation pour la publication par le W3C comme recommandation. Or, e fonctionnement actuel du W3C fait qu'une spécification reste au statut de «Candidate Recommendation» tant qu'il n'y a pas deux implémentations complètes (plus tout un tas de feedback d'implémentateurs, des suites de tests exhaustives, etc.). Donc, en pratique, énormément de specs complexes ne dépasseront peut-être jamais le statut de Candidate Recommendation. On peut par exemple noter que CSS 2.1 est une Candidate, et ce depuis 2008 uniquement. Pourtant, on utilise CSS 2.1 tout le temps…
    4. Si on prête foi à ces estimations (qui ne sont que cela), la date importance est 2010 pour le passage en Last Call, et 2012 pour le passage en Candidate Recommendation.

    Le prochain qui me parle de 2022 je le pends par les tripes.
  • «Faut-il utiliser l’intégration en HTML5 en contexte de production?»
    Ça dépend des ce qu'on entend par HTML5. Globalement, on peut utiliser le Doctype correspondant, la syntaxe, tous les éléments hérités de HTML4 (lorsqu'ils sont supportés), certains conteneurs sémantiques sur lesquels la spec est assez stable. Ensuite, c'est du cas par cas, fonctionnalité par fonctionnalité.

    «L’in­ten­tion [suppression du alt obligatiore] est bonne car le code se­rait moins pol­lué ainsi, mais le parc des ma­chines chez les han­di­ca­pés vi­suels n’est pas prêt.»
    C'est le parc des logiciels qui est concerné. Et ce n'est pas parce que la spécification permet un comportement logique qu'on est obligé d'ignorer d'autres facteurs. On fait tout le temps des arbitrages en fonction de bonnes pratiques et de conditions particulières. Les méthodes d'application des directives d'accessibilité existent pour faciliter ces arbitrages.

    «En re­vanche, com­ment dire à un ré­fé­ren­ceur que l’on pour­ra in­clure une in­fi­ni­té de

    dans notre page comme le pré­co­nise le groupe de tra­vail sur le HTML5 ?»
    On peut déjà le faire en HTML4, à vrai dire. Mais il est vrai que le principe des sections permet une utilisation de H1 comme titre de section universel (le niveau dans le plan de document dépendant alors de l'imbrication des sections). Ce dernier mécanisme est hérité d'une idée de XHTML2, qui proposait un élément H unique en remplacement de H1, H2, etc.

    «que com­prendre par là?»
    Que soit on continue à faire des titres comme en HTML4, soit on utilise uniquement des H1 (comme proposé par feu XHTML2).

    «Pour le mo­ment nous ne sa­vons pas l’effet qu’une telle uti­li­sa­tion des titres aura sur notre ré­fé­ren­ce­ment»
    La vraie question sera de savoir si les moteurs de recherche prendront en compte les sections, et si oui de quelle manière. Je n'ai pas un espoir énorme de ce côté, notamment parce que 90% des sites utilisant des sections en HTML5 auront une structure mal fichue (et dont l'exploitation serait contreproductive pour les moteurs). Les données riches du Web sémantique sont sans doute une meilleure piste pour l'avenir (mais je ne promets rien ;)).

    «Il est temps qu’un lan­gage ap­pro­prié au clas­se­ment et à la hié­rar­chi­sa­tion du conte­nu soit mis au point et fonc­tionne sur tous les ter­mi­naux de la pla­nète.»
    C'est bien d'avoir des envies d'ordre et de classement. Mais si 95% (plutôt que 90%) du Web s'en fiche, ce n'est pas faute d'un langage adapté. C'est surtout faute d'intérêt pour la chose, de connaissances, de rigueur, de temps…

    Pour finir: nous faisons du CSS 2 depuis des années, pourtant le support complet et universel de CSS 2 n'est pas encore d'actualité (du moins il l'est avec IE8, mais reste à attendre la fin d'IE6 et 7). Depuis le début de nos métiers, nous utilisons les technologies disponibles de manière progressive. HTML5 n'échappera pas à la règle. Cependant, je concèderai qu'il ne serait pas idiot d'attendre la publication du premier Last Call d'HTML5 du côté du W3C.

  • Tu résumes parfaitement la situation dans ce billet. Je ne pense pas qu'il soit réaliste d'utiliser HTML5 aujourd'hui dans des projets autres qu'expérimentaux ou dédiés à une cible de geeks bien équipés. Tant qu'Internet Explorer 6, 7 et 8 seront encore majoritaires, on va devoir se contenter de HTML4 ou XHTML1 avec CSS2 (et éventuellement CSS3 pour quelques améliorations graphiques).
blog comments powered by Disqus
↑ Haut de page