A force de couvrir l’actualité du développement web où l’on parle d’HTML5 à peu près tous les jours, on finit par être frustré des démos faites sur des pages qui n’ont pas grand chose à voir avec les contraintes que l’on a en production : compatibilité IE6, contenus lourds, sites complètement dynamiques et édités par plusieurs dizaines de mains dont certaines non techniques.

En tombant ici et là sur des exemples de migration de layout (sur des pages de portfolio) vers HTML5, je me suis rendu compte qu’une certaine partie de HTML5 était déjà utilisable en production de manière assez peu coûteuse. Voici donc ce que j’ai du faire pour passer un site de production en HTML5.

L’objectif est donc de rajouter toute la sémantique HTML5 utile possible, rôles ARIA inclus, sans rien casser du design ou de la compatibilité existante.

CSS et JS

librairie CSS

Premier problème : j’utilise un système de CSS qui m’a permis au tout début du site de proposer facilement des variations de layout, et qui sera bien pratique lorsque le site se proposera en marque blanche : il s’agit de YUI grids. Couplé à leur CSS reset et au font.css, il permet d’obtenir un rendu uniforme des éléments de base sur tous les browsers. Hors de question donc de s’en passer, mais elle faisait référence exclusivement à des éléments de type DIV, alors que je m’apprête à en supprimer quelques unes. J’ai donc du la fixer, même si je n’aime pas modifier des librairies, car cela pose des problèmes de maintenance par la suite. Je leur ai ouvert un ticket en espérant faire évoluer la librairie.

CSS Reset

Une fois ma librairie fixée, je me suis rendu compte que tous les browsers affichent par défaut inline les élément inconnus. Ce qui veut dire par exemple qu’une <DIV> qui doit devenir un <HEADER> ne sera plus en display:block;.

j'ai trop de modifications CSS à faire pour rattraper cette règle cas par cas
il n'est pas précisé dans les specs un valeur display par défaut (j'imagine que cela viendra plus tard ?).
les anciens browsers ne se mettront jamais à jour et il n'est pas sur que les nouveaux s'entendent sur des valeurs par défaut
je ne veux pas me contenter de noyer les DIVs existantes dans les nouvelles balises, mais bien remplacer ce qui peut l'être
j'ai déjà un fichier reset.css qui me garantit le même affichage de tout le HTML sur tous les browsers

J’ai donc décidé d’étendre l’idée du reset.css aux nouvelles balises HTML5, en lisant ce pour quoi chacune était faite et en leur imposant une valeur de display par défaut en conséquence :

/* some of the HTML5 tags that should display as blocks by default */
article,
aside,
audio,
canvas,
datagrid,
datalist,
details,
dialog,
figure,
footer,
header,
menu,
nav,
section,
video {
display: block;
}
/* some of the HTML5 tags that should display as inline text by default */
abbr,
eventsource,
mark,
meter,
time,
progress,
output,
bb {
display:inline;
}

Que pensez vous des choix faits entre block et inline ?

NB : D’après certains, du point de vue des performances, c’est une mauvaise pratique que de targeter en css des éléments HTML, il vaudrait mieux privilégier les classes et IDs. Personnellement je n’ai jamais pu constater de différence, et tous les fichiers de “CSS reset” du monde sont bien obligés d’en passer par là. Connaissez vous des cas où cette notation peut ralentir ? Y-a-t il une autre solution ?

Fixer IE

IE (de 6 à 8) ne sait pas styler des éléments qu’il ne connaît pas. Je vais donc utiliser la même technique que d’autres pour hacker IE : créer tous les types de tag HTML5 au moins une fois. Voici le JS final, fortement inspiré de celui-ci, optimisations paranoïaques en plus.

// inspired from http://remysharp.com/downloads/html5.js
// creates all know HTML5 tags once, for IE to be able to style them
// For discussion and comments, see: http://remysharp.com/2009/01/07/html5-enabling-script/
(function(){
if(!/*@cc_on!@*/0)
return;
var e = 'abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource,figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video'
.split(','),
create = document.createElement;
for(var i=0, iTotal = e.length; i<iTotal;i++) {
create(e[i]);
}
})();

Je vois beaucoup de démos utilisant les commentaires conditionnels IE pour inclure ces lignes de JS qui ne servent qu’à IE. Du point de vue des performances, il faut limiter au maximum le nombre d’objets externes à une page, en particulier celui des fichiers JS qui bloquent le rendu de la page tant qu’ils ne sont pas téléchargés et interprétés. IE étant justement le browser qui a le plus besoin de ce genre d’optimisation, j’inclus ce fichier dans le JS principal du site, où il va d’ailleurs rejoindre d’autres hacks IE.

Question maintenance c’est un peu embêtant car on se retrouve avec 2 fichiers (css + js) comportant la même liste d’objets à mettre à jour en cas d’addition/suppression de tags HTML5. Rien d’ingérable cependant.

HTML

HEAD

N’étant pas un utilisateur des validateurs W3C et encore moins de XHTML, les pages ont toujours été définies en HTML 4 transitionel : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> On passe donc à la nouvelle balise

<!DOCTYPE html>

et c’est tout … j’ai lancé mes 3 machines virtuelles avec des installations propres de IE6, IE7 et IE8 en cherchant partout un bug CSS ou même JS qui signalerait qu’on est passé en quirksmode, et RIEN, le site s’affiche normalement.

Développeurs, avez vous constaté des différences d’affichage en passant à HTML5 en partant d’un autre doctype que HTML4 transitional ?

Formulaires

HTML5 introduit une dizaine de nouveaux types de champs (email, url, datetime …). Il faut utiliser Opéra, qui va jusqu’à afficher un widget calendrier sur un champs datetime, pour comprendre ce que les browsers pourront en faire dans les années à venir. Safari iPhone lui adapte le clavier virtuel au type de champs. Le bonus, c’est que de IE6 au dernier Chrome, les input de type inconnus sont reconnus comme des <input type=”text”> ! C’est dont à la fois sans risque et avec un certain intérêt que l’on peut les introduire dès maintenant

<input type="email" name="loginemail" id="loginemail" placeholder="votremail@votrefai.com" />

HTML5 introduit également l’attribut “placeholder” qui contient le texte par défaut à afficher lorsqu’il n’y a pas de focus sur le champs. Si cela vous fait penser à un code JS que vous avez probablement déjà implémenté une bonne dizaine de fois, c’est normal, et vous pourrez le réutiliser en fallback. Voici un exemple de code

Rôles ARIA et nouvelle sémantique

Dans les templates qui définissent mes quelques layouts, j’ai remplacé certaines <DIV> par un markup qui a plus de sens : <HEADER>, <FOOTER>, <NAV> et <SECTION>. Les 2 premières parlent d’elles même, les specs ne disent pas si elles doivent être unique ou pas, la logique suggérant que oui. <NAV> correspond aux différents éléments de navigation et <SECTION> quant à elle n’a pas plus de signification que <DIV>, l’utilisation que j’en fais est donc tout à fait arbitraire : je garde <DIV> pour le positionnement, et <SECTION> pour les endroits qui entourent directement le contenu, et auxquelles je vais rajouter un role ARIA.

Il existe d’autres balises qui seront surtout utiles aux sites de contenu comme <ARTICLE> et <ASIDE> (contenu relatif), mais dont je n’ai pas l’utilité sur un réseau social qui permet de stocker son contenu numérique. D’autres balises sont beaucoup plus spécifiques : <HGROUP> permet de faire une table de matières ou <ADRESS> qui contient un moyen de contact relatif à l’article ou à la page entière. J’utilise cette dernière pour baliser le lien vers “nous contacter” en bas de page, car la spec laisse supposer que le navigateur devrait mettre en avant cette information… Là encore, c’est de la sémantique, donc il y a une grande part d’interprétation : au final ce sont les browsers et surtout les moteurs de recherche qui dicteront les balises utilisées et leurs usages

Bénéfices

Sémantiquement le markup devient très lisible, cela va donc bénéficier aux lecteurs d’écran pour la partie ARIA. Concernant les balises HTML5, à ma connaissance personne ne les prend en compte actuellement. Mais gageons que dans un futur proche les moteurs de recherche, les lecteurs d’écran ou tout autre robot/browser vont implémenter de quoi exploiter le markup HTML5 car après tout on leur mâche le travail, et Yahoo/Google ont déjà fait l’effort pour les microformats alors même que ceux ci ne sont pas des standards W3C.

Vu l’orientation sémantique des balises HTML5, on peut imaginer que les premiers sites de news à se lancer auront un avantage concurrentiel sur leurs concurrents, c’est moins évident pour les sites qui dépendent peu du référencement.

Cela permet accessoirement de commencer à se lancer de manière soft dans cette évolution du web qui sera incontournable dans un futur proche. A partir de ces manipulations de base, tout nouveau développement pourra être pensé avec les nouvelles balises et l’ajout de ARIA. L’équipe et le site seront ainsi prêts pour le futur.

Coût

Cela m’a pris une journée pleine (sur 3 jours), mais pour vous aider à quantifier l’effort chez vous voici quelques variables à prendre en compte :

J'ai fait ces modifs sur un site de taille moyenne (150 modules) mais avec très peu de modèles de pages différents (1 seul header, 1 seul footer, 4 layouts)
Le HTML a moins de 2 ans et la base de code était saine (oui je me jette des fleurs). Il n'y a eu que 6 dévelopeurs différents qui ont édité HTML et CSS.
J'avais une connaissance très théoriques des rôles ARIA et de la nouvelle sémantique HTML5, j'ai donc passé beaucoup de temps en recherches dans les specs W3C et sur Google pour comprendre. Et pour tout ce qui touche à la sémantique, on peut passer des heures à tergiverser sur l'idée qu'en avaient les concepteurs.
Je n'ai touché qu'au plus facile : le markup des layouts. Cela prendrait 1 semaine pour passer en revue les 150 modules et mettre à jour le markup de tous les widgets du site intelligemment (barre d'upload, listings, références aux dates ...)
Rajoutez encore une journée pour jouer TOUS les scénarios de tests de tout le site sur la petite dizaine de browsers supportés : IE6 (hé oui), IE7, IE8, FF3.5, FF3.6, Chrome Mac et Chrome PC. Safari Mac et Opéra en bonus

Conclusion

Passer au markup HTML5 :

le risque de ne plus être compatible tout browser est maîtrisé
la transition est facile si l'équipe maîtrise bien le markup des layouts du site
pas de bénéfice immédiat connu en terme de référencement/accessibilité
tout futur projet incluant une nouvelle balise HTML5 bénéficiera de ce travail déjà accompli (et il y en aura)