Édition Nº1 du 15 mai 2012 Retour au sommaire

Pour ou Contre : HTML 5 en production ?

Développeur 1 Je m’ennuie. Ça te dirait qu’on parle un peu « contenus de segmentation » ?

Développeur 2 À tes souhaits ! :)

Développeur 1 Mais si, les nouvelles balises à la mode en HTML5 !

La spécification W3C distingue maintenant plusieurs ensembles pour mieux s’y retrouver. Je te résume ça en deux mots :

  • Tu as toute la sémantique de niveau texte que tu connais :
    <strong>, <em>, etc.
  • Puis à un niveau au-dessus les contenus intégrés du type images et vidéos.
  • Il y a aussi toute une section dédiée aux formulaires.
  • Puis viennent les contenus dits de regroupement que nous connaissons bien aussi : <p>, <ul>, etc.
  • Et enfin, les fameux contenus de segmentation, qui comprennent de nouvelles balises telles que <article>, <aside>, <nav>.

Développeur 2 Ah oui ! Toute une partie de la nouvelle sémantique donc. Je connaissais, mais je ne savais pas que ça portait un nom.

C’est super ces nouvelles balises, on peut pousser la sémantique du document beaucoup plus loin et elles permettent d’affiner le plan de la page de façon significative grâce à un nouvel algorithme. Ainsi, chaque section intègre son propre plan de document qui saura s’adapter en fonction de son contexte. C’est très intéressant dans le cadre de contenus inclus (via AJAX ou tout autre système de templating habituel).

Développeur 1 Par contre question support ce n’est pas ça encore, hélas. Les CSS scoped par exemple – qui sont l’équivalent côté CSS des contenus de segmentation –, et qui permettent de mettre en forme des fractions de code isolées ne sont implémentées nulle part.

Bref, tout ça reste de la science-fiction et c’est en grande partie inutilisable aujourd’hui. En tout cas moi, je fais très attention quand il s’agit d’utiliser cela à des fins professionnelles…

Développeur 2 C’est vrai que c’est un peu expérimental mais ça commence à arriver dans les navigateurs. CSS scoped ça va être très pratique, je veux pouvoir utiliser ça très vite pour mettre en forme des portions de code, directement en fonction du contexte. Ça m’évitera de devoir jouer avec les descendances CSS à outrance.

Développeur 1 Tu vas pouvoir attendre encore quelques siècles à mon avis… Ne serait-ce que parce qu’il va falloir assurer la rétro-compatibilité avec les vieux IE pendant de longues années et que cette fonctionnalité est difficilement dégradable gracieusement.

Développeur 2 CSS scoped c’est vrai que c’est un peu avant-gardiste à l’heure actuelle, mais d’autres nouvelles fonctionnalités sont plus facilement dégradables. Et puis bon, la rétro-compatibilité IE en 2012 : sérieusement, on en est encore là ?

Développeur 1 Eh oui, encore.

Mes clients ne voient souvent que les chiffres. Et pour eux, IE8 reste le navigateur le plus utilisé au monde. Pour certains projets même, le support IE7 (voire parfois IE6 !) est encore exigé, et ce n’est pas par lubie intégriste mais bien par pragmatisme : si IE6 ressort en premier dans les statistiques du site que je refonds, je ne peux mathématiquement pas le négliger. C’est dommage (en plus d’être castrateur) mais on est souvent contraint de suivre le rythme du dernier de la classe.

Et c’est d’autant plus vrai que l’on parle là de la couche HTML qui touche à la structure même du document : quand ça casse, on est mal. Alors qu’avec CSS, c’est la présentation qui va se dégrader, à moindre mal donc.

Développeur 2 Je te plains. J’ai la chance de travailler régulièrement sur des projets dont la cible me permet de m’affranchir du support des vieux navigateurs, c’est-à-dire principalement des vieux IE donc (puisque les autres constructeurs ont opté pour une logique de mise à jour silencieuse ou simplifiée).

Et c’est bien agréable, surtout quand on voit les efforts considérables fournis par Microsoft pour rattraper le terrain qu’il a perdu au cours des années 2000 : IE9 est un bon navigateur et soutient presque la comparaison avec ses contemporains, IE10 y arrivera peut-être enfin…

Développeur 1 Formidable, mais pour beaucoup de développeurs hélas le support des vieux IE reste tout simplement incontournable. Et vu les implémentations actuelles de HTML5, on va devoir avoir recours systématiquement à tout un tas d’astuces et de correctifs plus ou moins propres et plus ou moins pérennes pour être sûr que ça passe partout.

C’est pénible et ce n’est jamais gratuit : poids, complications de mises à jour, multiplication des inconnues… Hélas sans cette tambouille indigeste, toutes les nouveautés de HTML5 resteront le privilège des utilisateurs équipés de navigateurs récents.

Développeur 2 Il existe tout de même des outils bien faits et fiables pour pallier à ce genre de problèmes. En s’appuyant sur de la détection de fonctionnalités via JavaScript, on arrive à servir les correctifs à ceux qui en ont besoin uniquement, et les autres profitent pleinement des nouveautés.

Modernizer est sans doute la bibliothèque la plus connue pour faire cela. Elle inclut entre autres HTML5 shiv, qui va faire reconnaître à IE toutes ces nouvelles balises. Il est alors possible de les mettre en forme de la même manière que n’importe quelle autre balise.

Développeur 1 Oui mais en liant la structure même de ta page au support JavaScript, tu prends un gros risque : le JavaScript peut casser, d’autant plus dans les situations de mobilité qui sont aujourd’hui fréquentes avec l’essor des tablettes et des smartphones. Si sans JavaScript ton document est illisible, tu vas commencer à additionner les problèmes… J’ai du mal à me résoudre à passer ce point sous silence ; c’est pire que de lier CSS à JavaScript puisque c’est lier HTML à JavaScript !

Et j’ajouterais plus philosophiquement que JavaScript n’est pas destiné à cela. On m’a appris à bien séparer le contenu de la présentation et des interactions, et jusque là ça a toujours porté ses fruits. Choisir les bons outils, ça relève aussi de nos compétences, pas de la mode du moment.

Développeur 2 On est quand même en droit de questionner ce dogme, même si ça ébranle un peu les convictions…

Regarde tout ce qui se passe en CSS3 : animations, transitions, pseudos-éléments… Les limites ne sont plus franches entre contenu, présentation et interaction.

D’ailleurs même CSS2 introduisait en son temps des notions d’interaction, ne serait-ce qu’avec la pseudo-classe :hover, utilisée partout depuis des années maintenant… Pas toujours à bon escient, je te l’accorde.

Développeur 1 En effet, ça bouge beaucoup. C’est Christian Heilmann, un développeur évangéliste de chez Mozilla qui en parlait récemment : HTML5 est un standard vivant. Il prenait le temps quelques mois avant de faire le point sur ces séparations entre HTML, CSS et JavaScript justement.

Pour moi la conclusion de tout ça, c’est surtout d’y aller avec précaution et d’éviter de compliquer davantage les choses par des usages anarchiques. Même le W3C lui-même semble penser qu’il est bon de freiner un peu cet engouement.

D’autant que l’accessibilité est aussi un peu en berne sur le sujet.

Développeur 2 Tu es sûr ? Sur ce point il me semble que ARIA apporte des solutions concrètes à tout ce qui peut être produit en HTML5. On peut maintenant identifier des comportements et des contenus de manière bien plus fine et efficace.

Le développement des standards montre une fois de plus qu’il est possible d’innover sans oublier une partie du public sur le bord de la route, et même mieux : d’améliorer et favoriser la montée de ce public dans un même wagon progressiste.

Développeur 1 C’est vrai que c’est formidable, tu fais bien de le rappeler.

Dans la théorie du moins, car dans la pratique c’est moins idyllique : les fabriquants de navigateurs ont des cycles de développements qui sont rarement en adéquation avec l’évolution des standards, qu’ils soient en avance (XML HTTP Request était une innovation propriétaire de Microsoft par exemple) ou, comme ici avec ARIA, en retard.

La vérité c’est que actuellement, très peu de navigateurs permettent d’exploiter tout ça.

Développeur 2 Si on attend toujours que tout le monde soit à jour, rien ne bougera jamais. Un standard vivant, c’est justement à nous de le construire au quotidien par nos usages ! Pour l’exemple, donne-moi un cas d’école concret : qu’est-ce qui serait bloquant aujourd’hui pour toi question accessibilité ?

Développeur 1 Sans même avoir besoin de parler d’ARIA, un bon exemple ce sont les liens de type « bloc ».

Tu le sais je pense, il se trouve que jusqu’alors ces éléments étaient de type inline : impossible dans ses conditions d’y inclure d’autres éléments de type block. Ce qui était bien handicapant, notamment pour effectuer des regroupements.

Développeur 2 Je vois très bien. C’est d’ailleurs une bénédiction, j’utilise régulièrement ces nouveaux types de liens. Désormais il est techniquement possible (et autorisé) de mettre ce que l’on veut dans l’intitulé d’un lien hypertexte : des images, des paragraphes, des titres, etc.

C’est une bouffée d’air sans précédent d’un point de vue ergonomique et on va pouvoir mettre à la poubelle pas mal de bidouilles peu recommandables qu’on utilisait auparavant pour faire des zones cliquables complexes tout en ne fâchant pas le validateur. Ça devrait te faire plaisir !

Développeur 1 Oui, oui, hourra. Hélas comme je le disais, l’accessibilité est encore malmenée sur ce point pourtant bien pratique. Les lecteurs d’écran peinent notamment à traduire ces liens correctement à l’utilisateur : répétition de contenus, liens ignorés ou fractionnés, etc.

Développeur 2 Bah, on est tout de même en droit de considérer que ces logiciels arriveront techniquement à maturité sur le sujet dans un avenir plus ou moins proche, non ?

Développeur 1 Peut-être bien oui. Mais que fais-tu des mes réserves d’un ordre plus sémantique alors ? Un lien qui engloberait un titre, un extrait textuel et une image (par exemple) prend le risque de devenir salement brouillon pour un lecteur d’écran, qui va devoir parser tout son contenu là où un intitulé concis gagnerait sûrement en pertinence et en efficacité…

Développeur 2 Peut-être qu’un attribut title sur la balise <a> contribuerait à clarifier les choses ? Cela dit, on perd en précision pour les uns ce que l’on gagne en ergonomie pour les autres, c’est certain.

Développeur 1 Sans parler du SEO : on ne sait pas encore comment vont s’adapter les moteurs de recherche à toutes ces nouveautés.

Développeur 2 À eux de faire au mieux sur ce point, merci de ne pas inverser la logique. À quoi bon tâcher de faire les choses bien s’il faut ensuite pervertir son travail pour satisfaire le dernier algorithme à la mode ?

Développeur 1 Certes. Mais c’est une raison de plus pour ne pas aller jouer à l’apprenti sorcier si tes objectifs de visites sont importants.

Développeur 2 Oublions les sujets qui fâchent… Et parlons plutôt d’une brochette de nouveautés emblématiques de HTML5 : les éléments de formulaires. Pas mal de possibilités intéressantes à ce sujet, à commencer par les nouveaux types de champs de saisie. Enfin un peu plus de sémantique ! Ça faisait un bail qu’on attendait ça : email, search, date, color, tout ça de façon native dans le navigateur avec les contrôles ad hoc directement implémentés. C’est quand même quelque chose !

Développeur 1 En effet, c’est un progrès significatif. Mais là tu me revois venir évidemment : maturité, rétro-compatibilité, qu’en est-il ?

Développeur 2 En tout cas, ça marche super bien sur mon iPhone. Et outre les aspects sémantiques, ça a un impact bassement pragmatique, visible dès aujourd’hui, et qui va certainement te ravir : le basculement automatique d’un clavier à l’autre en fonction du contexte. Si tu dois entrer un numéro de téléphone, seuls les chiffres te seront proposés par exemple. Voilà un truc super malin, pratique et concret. La révolution est en marche !

Développeur 1 Content pour toi et tes semblables fortunés. La mauvaise nouvelle, c’est que vous représentez une part du parc informatique très minoritaire et que, comme d’habitude, il faut décliner tout cela pour les vieux navigateurs afin de prétendre à un minimum d’exhaustivité. Par exemple, le champ de type date n’est aujourd’hui implémenté que dans Opera !

Développeur 2 Sur ce point justement, et contrairement aux nouveaux éléments de structure qui peuvent parfois être mal interprétés, la dégradation gracieuse fonctionne très bien : s’il ne reconnaît pas le type de champ, le navigateur bascule mécaniquement sur une alternative de type text. C’est une alternative tout-à-fait acceptable à mon sens !

Développeur 1 Peut-être, mais il suffit que je m’amuse à utiliser un champ de type email sur un navigateur moderne, pour qu’il vienne m’ajouter un moche filet rouge à la moindre erreur de saisie. C’est bien gentil mais je n’ai rien demandé moi.

Développeur 2 Ah oui, la validation des formulaires en natif ! Encore une belle avancée qui va permettre de s’affranchir des kilos de JavaScript nécessaires jusque là pour cette tâche.

Pour résoudre ton problème graphique, il te suffit d’ajouter un attribut à ton formulaire.

Développeur 1 Ah, voilà qui est bien utile en effet. Mais tu m’accorderas sans peine que si nous pouvions plus facilement mettre en forme les messages d’erreurs et autres retours graphiques, ce serait encore plus pratique. Les designers vont maudire à coup sûr le manque de souplesse graphique de ces nouveaux comportements !

Développeur 2 Oh, les designers pointilleux, ils avaient déjà l’habitude avec les formulaires à l’ancienne. Mettre en forme un select, un radio ou une checkbox, ce n’était déjà pas possible et on faisait très bien sans.

Développeur 1 Tu plaisantes ? Dans le meilleur des cas, le designer se résignait à effectivement ne pas y toucher et on se retrouvait avec des formulaires dépareillés et hors charte graphique. Et dans le pire, il s’entêtait à exiger du pixel-perfect et il fallait mettre en branle des usines JavaScript pour émuler ces éléments de formulaire de façon imparfaite (et rarement accessible)… Un cauchemar quelle que soit la solution adoptée. Et tu viens me dire que maintenant ça va toucher encore plus d’éléments ?

Développeur 2 Là encore, répondre à ce difficile problème est un chantier en cours. Cela devrait permettre à chacun de choisir la solution qui lui semble la mieux adaptée ; même s’il est vrai que les réponses pratiques se font clairement attendre.

Développeur 1 Exactement. Si les constructeurs voulaient déjà bien s’accorder sur une même façon de mettre en forme les éléments de formulaire historiques de façon enfin homogène, des légions d’intégrateurs et de designers excédés leur rendraient un hommage mérité. Au lieu de cela, ils s’entêtent à se concurrencer sur des nouveautés branchouilles totalement dispensables… Mais je m’égare. Revenons au sujet : tu vois d’autres avantages directs à utiliser HTML5 ? On a déjà fait le tour tu crois ?

Développeur 2 Oh non ! Nous n’avons pas parlé d’un truc tout bête encore : la simplification du langage. Plus besoin d’ajouter tout un tas d’attribut abscons lorsque ce n’est pas nécessaire : le code s’en retrouve ainsi plus léger, plus lisible et plus facilement mis à jour.

Développeur 1 C’est vrai que de ce point de vue, c’est simple et efficace. Le meilleur exemple étant le fameux doctype.

Cependant, je me demande dans quelle mesure cela ne va pas être pénalisant à terme. Le laxisme, ça a ses limites ; et la rigueur, quelques avantages quand il s’agit de code.

Développeur 2 Sur ce point je pense qu’il faut simplement distinguer les travaux amateurs des travaux professionnels. N’importe quelle équipe Web sera heureuse de travailler avec un minimum de règles afin de garantir un minimum d’erreurs et un maximum de cohérence.

Développeur 1 Je suis bien d’accord cette fois.

Autre point intéressant avec cette nouvelle syntaxe : il n’est plus besoin de recourir à des artifices au niveau des classes pour stocker des données, les data-attributes viennent corriger le tir ! Ça fonctionne, ça simplifie le travail, et tout est plus clair ainsi.

Développeur 2 Il en va de même pour video et audio. Enfin une alternative sérieuse à Flash quand il s’agit d’exploiter des contenus riches.

Développeur 1 Oui, c’est une belle avancée, je ne peux pas dire l’inverse. Mais c’est un peu terni par les difficultés qu’on a à normaliser un format d’encodage. Même si les mécanismes existent pour s’y retrouver, cela peut s’avérer bien contraignant de produire n versions de la même vidéo. On retrouve d’ailleurs le même type de problèmes côté CSS, avec @font-face qui exige une infinité de formats différents pour être compatible tout navigateur.

Et tu noteras également qu’il n’est pas toujours possible d’utiliser pleinement les contrôles de la vidéo au clavier ou sans la présence de JavaScript. Ce n’est donc pas encore pleinement fonctionnel.

Développeur 2 Le fameux dogme JavaScript est de retour. Comment vas-tu faire quand il va s’agir d’utiliser canvas ? Tu n’es pas sans savoir que cette technologie ne fonctionne pas sans.

Développeur 1 C’est vrai que canvas sans JavaScript ressemble fortement à une coquille vide. Mais tu noteras qu’une alternative est prévue pour justement garantir un contenu accessible quelles que soient les conditions d’accès…

Développeur 2 Je vais devoir filer, quelle conclusion tirer de tout ce que nous nous sommes dit ?

Développeur 1 Que je me suis bien occupé au lieu de m’ennuyer !

Mais surtout qu’une réponse universelle à la question d’utiliser HTML5 en production aujourd’hui n’existe pas : en fonction du contexte projet, de ses contraintes et de la cible visée, certaines choses seront faisables et même préférables, d’autres non. Céder aux sirènes de la nouveauté pourquoi pas donc, mais en étant extrêmement attentif aux répercussions sur nos utilisateurs dans le cadre projet qui est le nôtre.

Développeur 2 Je serais curieux d’avoir l’avis d’autres personnes, moi. La question est vaste et complexe ! Je suis sûr que nous avons oublié plein de choses. Nous développons surtout des sites vitrines et des portails, des développeurs de web apps auront sans doute un regard très différent sur HTML5 et des problématiques peut-être toutes autres.

Développeur 1 Je reste persuadé que faire des apps, ça n’autorise pas de se moquer des standards. Le Web est un formidable terrain de jeu, essayons de faire en sorte que cela dure.

Je m’inquiète d’ailleurs de voir les développeurs répéter aujourd’hui les erreurs qu’on a faites jadis aux grandes heures du monopole d’IE6 : partir dans une logique de développement Webkit-only comme le font certains par exemple, en négligeant Gecko et les autres, ça me fait hurler ! Va-t-on bientôt revoir fleurir des « sites optimisés pour tel navigateur » en foulant au pied standards et interopérabilité ?

Pour ou Contre : HTML 5 en production ?

Note de cet article : 3 / 5

Pour pouvoir noter les articles, vous devez voyager avec un billet (c'est gratuit !).
Toutes les infos sur la page d'abonnement !
Déjà inscrit ? Connectez-vous.

Photo : Jean-François Renauld

Vincent est développeur Web client depuis l’époque des tableaux de mise en page. Après quelques expériences (brèves mais intenses) dans de grandes agences, il travaille maintenant chez Clever Age ; une agence plus petite mais tout aussi respectable. Impliqué dans de nombreux projets qui tentent de promouvoir le Web de qualité, il aime échanger sur ses passions pour le Web en général et la typographie en particulier.

Photo : Émilie Pistorius

Christophe Andrieu est web designer et front-end developer indépendant. Après 5 ans de CDI en agence, il profite de ses pauses entre deux missions pour collaborer à W3Qualité, Trois Questions, Twitfat et d’autres projets bénévoles sympas.

Pas (encore) de réactions (RSS)

Réagir à cet article

XHTML : Vous pouvez utiliser ces balises : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>