Migrer un site de production vers un markup HTML5

ce site a migré : retrouvez cet article à jour sur braincracking.org

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'un certain subset 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="[email protected]" />

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)

Veille techno et articles similaires via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail

Comments

[Rédigé par : ^fabrice^^]

merci pour ce retour d'expérience (en particulier sur les formulaires).

question :
il fait quoi ce code ? if(!/*@cc_on!@*/0) {}

[Rédigé par : jpvincent]

d'après mes tests les IEs arrivent à passer après, mais pas FF
je n'ai pas testé avec + de browsers, mais ça serait donc un moyen de faire un commentaire conditionnel en JS plutôt qu'en HTML

pour les formulaires en HTML5, c'est vrai que je n'ai pas trouvé beaucoup d'infos sur le Net alors que ça me parait + important. Voir l'excellent http://diveintohtml5.org/detect.html#input-types

[Rédigé par : Nicolas]

Très intéressant tout cela... j'avoue que la tentation devient de plus en plus grande de refondre le mien aussi ! :)
Merci pour l'article.

[Rédigé par : Webetcaetera]

Très intéressant, merci.
Je n'étais pas sûre du bien fondé du passage en html5 ou même de la création des nouveaux projets en html 5 ... mais je crois que je vais sauter le pas, ça sera toujours ça de gagné pour le futur :)

[Rédigé par : jpvincent]

oui, ça évite de refaire son site :
c'est la première étape par laquelle il faudra de toute façon passer pour implémenter au fur et à mesure d'autres features HTML5 comme sur les formulaires, la sémantique, pourquoi pas la vidéo etc ...

donc autant se lancer maintenant, c bon pour l'autoformation, ça sera bon pour le référencement un jour prochain, et ça permet un passage en douceur :)

[Rédigé par : Daifen]

Pour répondre à Fabrice : @cc_on active la compilation conditionelle, pour les navigateurs qui le supportent. Ici, on utilise cette directive pour trier les navigateurs qui doivent executer le code et ceux qui ne le doivent pas.

Ceux qui supportent la compilation conditionelle vont donc traiter le code entre le @cc_on et le @ qui suit, les autres ne comprendront pas, et ignoreront donc tout le commentaire.

Ainsi, "if(!/*@cc_on!@*/0) return;" va donner :
- "if(!0) return;" pour un navigateur qui ne connait pas la compilation conditionnelle
- "if(!!0) return;" pour les autres

C'est juste un moyen d'écrire, en très peu de caractères, une détection des capacités du navigateur

[Rédigé par : jpvincent]

merci pour la précision Daifen
ça veut dire que ce moyen de détection n'est pas ultime puisqu'il ne teste pas précisément ce que l'on voulait (à savoir, styler un élément inconnu du browser).
Mais faute de mieux, c'est effectivement le + court moyen pour tester la présence de IE

précisons que ce test est un raffinement dont on peut se passer puisque créer ces éléments dans les autres browsers ne leur pas + mal que les créer sous IE

[Rédigé par : Sventovit]

Excellent ! Excellent article.
« pas de bénéfice immédiat connu en terme de référencement/accessibilité »

Je fais des tests pour le référencement et de temps à autre des compte-rendus comme là :
http://on-air.hiseo.fr/html5/html5-ameliorer-referencement/

Mais rien de probant encore sur les poids des nouvelles balises.
Mais je suis l'affaire de près. ;-)

Très cordialement,
Philippe

[Rédigé par : jpvincent]

oui Sventovit on suis tes tests SEO avec attention, sois en sur :)

[Rédigé par : Nicolas]

La question que je me pose est la suivante : si mon site actuel est servi en application xhtml/xml, comment pourrais-je passer en HTML 5 ? La syntaxe XML peut rester de rigueur ?

[Rédigé par : jpvincent]

je ne peux répondre qu'en théorie : probablement oui

HTML5 est beaucoup plus lâche sur la syntaxe, donc une syntaxe stricte comme tu as du la faire pour une page xml devrait d'autant plus facilement passer
par ailleurs, il existe même XHTML5, pour ceux qui veulent continuer à utiliser des syntaxes strictes

[Rédigé par : Nicolas]

Ok merci pour l'info !

Par contre, si je suis bien ton article... si quelqu'un sous IE bloque Javascript... adieu HTML 5 ?

[Rédigé par : jpvincent]

@Nicolas juste remarque :)
oui, sans ce trick JS, IE ne sait plus styler les balises qu'il ne connaît pas, donc le site risque d'être un peu moche à voir.

Après c'est une décision stratégique : si la proportion d'utilisateur IE sans JS du site dont tu es responsable est importante (l'importance variant selon le business model), que le site mal stylé devient inutilisable et que tu n'as pas besoin de parier sur la sémantique HTML5 pour améliorer référencement et accessibilité, alors il ne faut pas utiliser cette technique.

Par contre je serais curieux de savoir quels sites aujourd'hui ont une telle population, est ce que tu en gères toi même ?
intranet bancaire ?
forte proportion d'utilisateurs mobiles ?

[Rédigé par : Nicolas]

T'inquiète, c'est pas pour t'embêter : j'ai juste tendance à vite voir les limites d'une technique (l'habitude du pragmatisme :) ).

Je te rassure, je n'ai pas une audience aussi "particulière" pour mon site personnel par exemple :) , mais il peut m'arriver d'en gérer un ou deux où le problème pourrait se poser (intranets sur un parc de navigateurs vieillissants).
Je reconnais que le combo Norton (qui bloque JS) + IE n'est pas impossible (je l'ai vu de mes propres yeux horrifiés, 2 bouses combinées), mais tend à se faire rare àmha.

Selon moi, je ne peux pas proposer ça sur un site en tant que professionnel actuellement : pour l'instant, la priorité reste sur un site pleinement fonctionnel même sans Javascript. Je ne peux pas risquer d'envoyer paître IE toutes versions.

En fait, le HTML 5 m'occasionne presque une schizophrénie : le développeur curieux qui est en moi a bien envie de franchir le pas sur son site personnel (et là, il y a challenge !), et le développeur au boulot... se voit mal intégrer ça sur un site en production. :(

[Rédigé par : Dreamgratuit]

Merci de cet article qui confirme ce que nous sommes plusieurs à avoir expérimenté.
Pour ceux qui souhaite un test facile, je signale que je propose gratuitement un thème Wordpress tout en HTML5 : http://dreamgratuit.canalblog.com/archives/2010/01/12/16501225.html
ou directement téléchargeable ici : http://wordpress.org/extend/themes/freedream

[Rédigé par : Nicolas]

Bon bin finalement, j'ai suivi les conseils de ton article : retour d'expérience sur une migration XHTML5 : http://www.nicolas-hoffmann.net/source/1299-Pour-migrer-mon-site-vers-XHTML5.html

[Rédigé par : jpvincent]

@nicolas : merci d'avoir fait un post sur ta migration, tes contraintes de base (passer les validateurs XHTML) sont bien plus fortes que les miennes et c'est donc une lecture assez intéressante.
que je m'empresse de partager sur ma revue de presse d'ailleurs :)

[Rédigé par : Nicolas]

@jpvincent : merci et content que cela t'aie intéressé ! :)