Tous les articles

La vie des intégrateurs, chapitre III : puis vint Html5

Par Eric Le Bihan

Depuis plusieurs mois on ne lit plus que ça dans les nombreux blogs qui parlent d’intégration, de développement ou de webdesign. C’est venu timidement et puis la sortie des nouvelles versions des navigateurs a accéléré le processus, du coup les mêmes démonstrations se répètent inlassablement sans que concrètement on puisse dans un cadre professionnel utiliser pleinement toutes ces nouveautés. On peut maintenant faire des sites en HTML5 et CSS3 ! Ok mais seulement pour les dernières versions des navigateurs qui tous regroupés représentent à peu près 50% des utilisateurs. Difficile de vendre le truc à son patron ou à ses clients en expliquant que la moitié aura une version dégradée du site, même « gracieusement dégradée » (gracefully dégradation).
Après, attention tout ce qui bouge n’est pas CSS3, – j’ai vu (lu) de nombreuses personnes s’extasier devant des démonstrations CSS 2.1 particulièrement ingénieuses – et HTML5 n’est pas la solution à tout. Ajax, vous avez dit Ajax ? Voir le billet de Jeffrey Zeldman sur le terme HTML5 : html5 fuzzies

D’abord pourquoi passer à HTML5 alors que pendant des années on a seriné à tous ceux qui voulaient l’entendre que XHTML, c’est l’avenir, il y a rien de mieux et que franchement HTML c’est has-been (ok je caricature, mais à peine). Est-ce que tous ces évangélistes aussi prompts à faire du prosélytisme auraient retourné leur veste ? Effectivement nous de notre côté on a pu avoir des doutes au début et puis on s’est rendu compte que ça changeait pas grand chose finalement, on peut très bien continuer à faire du XHTML dans la syntaxe en utilisant les nouvelles balises HTML5, c’est vrai que Les Intégristes ont l’avantage de parler à des professionnels qui ne portent pas forcément Internet Explorer dans leur cœur. En revanche l’avantage et qui n’est pas des moindres c’est qu’HTML5 intègre ARIA et en terme d’accessibilité c’est un grand pas en avant. Si vous voulez un petit rafraichissement de mémoire allez voir par là, la traduction qu’avait faite Pierre de Introduction to WAI ARIA.

Si pour un blog ou l’administration d’un site on peut s’amuser avec HTML5 et CSS3 en ajoutant les JS qui vont corriger les déficiences d’Internet Explorer (http://code.google.com/p/html5shiv/ et http://www.keithclark.co.uk/labs/ie-css3/), il est moins possible de le faire pour un site grand public générant un chiffre d’affaires de plusieurs millions d’euros. Le moindre ko est traqué et il serait risqué de s’appuyer sur un script qui demain pourrait ne plus être mis à jour et créer pas mal de désagréments.

Plusieurs solutions :

  • Continuer à faire du bon vieux XHTML 1 et CSS 2.1
  • Faire accepter qu’avec IE ce sera moins bien
  • Faire du code forking, comme on faisait avant que des bibliothèques JS gèrent ça pour nous : une version pour IE une version pour les autres
  • Prendre le risque des solutions JS quand même

Aucune de ces solutions n’est parfaite mais les intégrateurs et développeurs sont tellement impatients d’utiliser des specs qui sont encore à l’état de brouillon, que je suis sur que les arguments ne manqueront pas pour vanter les mérites d’une technologie balbutiante, quitte à faire le travail deux fois.

Un petit tour d’horizon sur ce qu’il faut savoir de HTML5 et CSS3, comment l’utiliser, quelles solutions JS, etc. :

Et vous quel usage faites vous d’html5 et ses amis ? Applicable en milieu professionnel ou à réserver pour des projets isolés ?

Article rédigé par , publié le dans la catégorie Front-end. Vous pouvez suivre les commentaires de cet article en utilisant le flux RSS dédié. Les commentaires sont fermés sur cet article.

24 commentaires

Flux RSS des commentaires de cet article

Entre HTML 5 et CSS 3, il est plus raisonnable de privilégier CSS 3 avec dégradation élégante, surtout si l’on doit s’assurer que le site doit demeurer consultable sans JavaScript (étant donné que JavaScript est incontournable pour faire passer la pilule des nouveaux éléments HTML 5 à IE jusqu’à sa version 8). D’ailleurs, en termes d’accessibilité, il n’est pas exclu que certains lecteurs d’écran, Jaws en tête, aient du mal avec les nouveautés du HTML 5, même avec ARIA. Bref, pour pas mal de projets, les bons vieux XHTML 1.0 et CSS 2.1 auront encore de beaux jours devant eux.

Pour ma part, je continue à utiliser XHTML 1.0 et CSS 2.1 pour les projets professionnels sur lesquels je suis amené à intervenir. Quant à mes projets perso, il n’est pas exclu que j’y apporte à terme des touches de CSS 3, tout en restant en XHTML 1.0, tant que le support natif de HTML 5 ne sera pas décent sur IE.

Enfin, il ne faut pas oublier qu’une utilisation conforme aux spécifications du W3C du HTML, du XHTML et des CSS est un gage de pérennité, quelle que soit la version de HTML, de XHTML ou de CSS employée.

Le 11 Août. 2010 à 11h05 par Victor Brito

Cette mise au point était intéressante. Une phrase qui m’a un peu gênée :

« Le moindre ko est traqué et il serait risqué de s’appuyer sur un script qui demain pourrait ne plus être mis à jour et créer pas mal de désagréments. »

Là on a deux notions différentes :
– la maintenance du code, la sécurité, dès qu’on utilise des scripts écrits par d’autres, on devient un peu plus dépendant des développements extérieurs.
– Le poids du code, « le moindre ko est traqué ». C’est applicable aux 250-500 plus gros sites mondiaux.
Mais en France par exemple on peut tranquillement dire que sur les 100 plus gros sites édités, les développeurs ne font pas la chasse au moindre ko transféré. Loin de là.

Pour le script je parle de ce que j’utilise, html5shiv qui fait 1,5ko alors quand on a des publicité pré home de 300ko hein .. :)

Le 11 Août. 2010 à 11h22 par Vincent Voyer

Finalement on parle beaucoup de html5 sans que pas grand monde ne sache de quoi on parle réellement.

Je pense pour ma part que sur 90% des sites web qui sont intégrés actuellement en xhtml le passage à html5 n’aurait aucune valeur ajoutée.

En effet, html5 c’est avant tout quelques balises qu’il faut savoir exploiter et les compétences en ce domaine sont encore bien rare. Les quelques exemples que l’on peut voir de ci de là ne sont pas cross-browser. Quand aux dégradations élégantes pour les vieux navigateur cela demande aussi du temps de développement qui est aussi facturé la plupart du temps.

Bref c’est une équation compliquée que de passer à html5 pour avoir un retour sur investissement positif si je puis m’exprimer ainsi.

Le 11 Août. 2010 à 11h23 par Nicolas G

D’ailleurs, en termes d’accessibilité, il n’est pas exclu que certains lecteurs d’écran, Jaws en tête, aient du mal avec les nouveautés du HTML 5, même avec ARIA.

La spec d’ARIA dit que c’est ARIA qui a la préséance en termes de compréhension. J’ai déjà fait le test, quand on surcharge des éléments, les revues d’écran prennent en compte l’ARIA (quand elles savent le faire évidemment) en négligeant le HTML structuré sous-jacent. Donc ça ne m’inquiète pas.

Quant à moi je vais de plus en plus aller vers HTML5 (j’ai appelé de mes vœux pendant des années des balises de navigation et de structure comme section, article, etc.) tout en continuant pour des questions de qualité à faire du code formaté comme du XHTML. Le meilleur des deux mondes ? ;)

Le 11 Août. 2010 à 11h24 par Stéphane Deschamps

@Vincent Voyer

J’ai déjà eu le cas d’utilisation d’un plugin jquery non maintenu et non compatible avec la dernière version de la bibliothèque. Pour la traque au ko, c’est du vécu :-) Et apparemment c’est le cas de nombreux concurrents. Et je suis d’accord avec toi a quoi bon minifier, gzipper les JS, optimiser les css, compresser au max les images si on continue à nous passer des pub de 300ko…

Le 11 Août. 2010 à 11h30 par Eric Le Bihan

Je pense qu’on s’est mals compris, ce que j’avais compris de la phrase c’était qu’il fallait faire la chasse au moindre ko transféré.

Tu parlais de faire la chasse au moindre ko d’erreur possible lorsqu’on utilise énormément de code javascript et je suis bien d’accord avec ça :)

Le 11 Août. 2010 à 11h32 par Vincent Voyer

@Vincent Voyer :

Mais en France par exemple on peut tranquillement dire que sur les 100 plus gros sites édités, les développeurs ne font pas la chasse au moindre ko transféré. Loin de là.

Je travaille dans une boîte qui répond à ton critère, et en réalité les contraintes, bien que pas forcément vues par le client, font partie des cahiers des charges, et sont prises en compte (tant que faire se peut) dans les développements.

Le 11 Août. 2010 à 11h40 par Stéphane Deschamps

Personnellement je n’utilise plus qu’HTML5 et ce, pour tous mes projets (qui ne sont pas des projets à plusieurs millions d’euros ni des « projets isolés »). La dégradation gracieuse est un concept auquel je crois et que je pratique donc abondamment.

Le 11 Août. 2010 à 13h18 par Benjamin

Pour ma part, je suis récemment passé à HTML5 pour mon site personnel (et servi en application/xhtml+xml tant qu’à faire :) ), les demandes commencent à arriver côté professionnel (là, c’est plus délicat, mais je pense que d’ici peu de temps, les demandes vont arriver massivement).

Le 12 Août. 2010 à 17h54 par Nico

Perso, HTML5 j’y suis déjà, j’ai déjà publié un projet perso (mais pas vraiment) sur html5gallery (dame-bio.fr pour les curieux, une site de recette bio que ma copine utilise pour créer une activité, donc c’est pro sans l’être).
J’y utilise HTML5/ CSS3 avec dégradation gracieuse.
Pour l’HTML5 c’est vrai que le js est obligatoire pour IE mais bon en même temps quand on vois que Google Analytics ne propose que un code JS, et que pour le site où je bosse (40 000 pages vues/j) on traque pas les gens sans js, à quoi bon se prendre la tête. Les quelques balises c’est un peu pour le style. Après les Web Forms c’est pas mal (ce matin j’ai encore utilisé un plugin jquery pour autovalider un form à partir des nouveaux attributs (required, nouveaux types etc) http://flowplayer.org/tools/validator/ )
Aujourd’hui JS c’est un peu « obligatoire » (sur chrome par exemple pour le désactiver, faut ajouter une option au démarrage genre –disable-script un truc à la con comme ça). Je dis ça mais bien sur quasiment tout mes dévs (sauf vraiment quelques fonctionnalités) fonctionnent sans. Le js doit rester une surcouche client non fiable.
Pour le CSS3, idem, j’y suis à fond. Et franchement un utilisateur sous IE6 n’en à rien à faire d’un coin rond ou d’une ombre sur le texte. Et si c’est pas le cas, ben qu’il passe à autre chose. Google (dont Youtube) ont abandonné IE6, on devrait peut être tous y songer gentillement, ne serais-ce que pour le graphisme pixel perfect.

Pour ce qui est des Ko. Je peux vous jurer que du CSS3 (avec fallback IE en images ci besoins) ça pèsent moins lourd que un design full image. Puis le mieux dans tout ça, c’est que le rendu client est bcp plus rapide (jusqu’à 100fois plus rapide selon mes yeux :) )

Alors moi je le dis, faites le grand pas. Ca coûte pas grand chose de s’y mettre doucement. Puis comme disait une campagne microsoft australienne « Vous buvez pas du lait tourné, alors n’utilisez pas un browser vieux de plus de 10 ans »…

Le 18 Août. 2010 à 13h54 par Mr.MoOx

Il est vrai que je me suis emporté en disant IE6. Comme tu le dis toutes les versions sont concernés par ces manques. Mais quels est la part réelle d’utilisateurs sans JS sur ses browsers (je ne trouve pas de chiffres concerts) ?
Pour l’HTML5 et les nouvelles balises c’est un petit problème. Par contre pour le CSS3, faut avouer que c’est IE depuis sa version 5 qui a poussé de nouvelles techniques. Et oui avec ses filter (gradient, shadow, drop shadow, blur etc) IE est pour moi à l’origine de nouveautés dans CSS3, que webkit à retravaillé puis proposer au W3C.
Au final il reste pas beaucoup de choses très grave de mon point de vue.

ps: IE7et 8 pas si vieux? Franchement quand on vois la rapidité de l’évolution du web (les gens allumaient ils aussi souvent leur PC le soir en rentrant avant Facebook ?) ça fait vieux. Et encore un petit coup de vieux quand je regarde l’historique de versions de chrome :)
Après tout ce que je dis n’engage que moi. Je pense qu’il faut vraiment aller de l’avant et pousser les nouvelles technologies.
C’est pas en tentant d’améliorer d’améliorer la bougie qu’on a inventé l’électricité ^^

Le 18 Août. 2010 à 14h21 par Mr.MoOx

Pour ne pas virer au troll ou s’épuiser dans des débats stériles :

1. Oui, on a envie de faire avancer les choses et utiliser les nouvelles techno
2. Oui, on trouve qu’internet explorer est à la traine et que ce navigateur freine l’avancée d’html5 et css3
3. Oui, on pousse la dégradation gracieuse au maximum
4. Les choses étant ce qu’elles sont et nous travaillons souvent pour des clients qui veulent exactement la même chose dans tous les navigateurs ou qui ont pour navigateur IE6. On n’y peut rien c’est comme ça…

Le 18 Août. 2010 à 14h43 par Eric Le Bihan

Je vous vois tous parler de dégradation gracieuse, pourtant il me semblait que la nouvelle approche recommandée était l’inverse, l’amélioration progressive (progressive enhancement) qui avait en plus l’avantage d’une part d’inciter les dev à partir d’une base sans javascript et d’autre part qui permettant d’aplanir les tendances sur les performances des navigateurs (le site standard est conçu pour IE et les scripts / css d’amélioration sont exécutés par les navigateurs récents, supposés plus rapides).

Enfin bref, pour ma part je n’ai pas encore eut l’occasion de me pencher sur le HTML5 et les CSS3, travaillant essentiellement sur des appli intranet et non des sites web, donc généralement avec une cible navigateur bien fixée (souvent IE, malheureusement).

Le 20 Août. 2010 à 10h39 par Loic

Loic : pour être franc (et histoire de lancer un petit troll le vendredi :) ), le concept de dégradation gracieuse (ou élégante), c’est du pipeau en tant que prestataire professionnel.

C’est déjà difficile de faire accepter à un client que son site ne soit pas parfait… et je ne me vois pas dire à un client « écoutez, votre site sera superbe sur les derniers navigateurs… mais sous IE 6, le graphisme va être dégradé élégamment ». Cela ferait pas sérieux et le client va nous voler dans les plumes.
A la rigueur, on peut faire accepter qq détails… mais guère plus.

Donc, là, effectivement, le concept d’amélioration progressive prend du sens : on peut dire : « votre site de base sera comme vous l’avez demandé, mais il pourra bénéficier de telles améliorations sur ces navigateurs, blablabla… ».

Par contre, à titre privé ou sur des réalisations personnelles, oui, le concept de dégradation élégante est tout à fait envisageable, et même souhaitable : histoire de faire avancer le schmilblick, l’évolution du web, toussa… A titre personnel, j’ai jamais eu personne qui est venu se plaindre d’être sous IE avec Javascript désactivé et que mon site en HTML5 ne s’affichait pas. Et si jamais il y en a un qui ose, je lui conseillerai d’installer Firefox. :)

Le 20 Août. 2010 à 11h29 par Nico

@Loic, @Nico :

Il me parait difficile d’appliquer le modèle de l’amélioration progressive, dans le sens, je fais un site pour IE qui n’aura pas toutes les nouvelles améliorations de html5 et css3 par exemple et ensuite, j’ajoute toutes ces nouvelles fonctionnalités pour les autres navigateurs. Après si on parle de conception, je pense qu’on n’est plus en 2010 à promouvoir une stricte séparation entre html / css et javascript, ça fait longtemps que ce principe est appliqué.
Si votre javascript est non intrusif, ajax ou pas, il est bien conçu et propose une alternative aux personnes qui ne pourrait pas bénéficier de cette techno.
En revanche en ce qui concerne la dégradation élégante, il est plus facile de mettre en avant que le fait de ne pas avoir de coins arrondis, de dégradés ou d’ombres portés sur Internet explorer permettra à vos pages de se charger plus rapidement en limitant le nombre de requête http – après vous pouvez argumenter en faveur des images sprite, qui ne sont pas toujours facile à mettre en place sur tous les sites (en terme de maintenance, c’est pas ce qu’il y a de mieux).
Après il faut se poser la question, si on fait des sites pour les navigateurs du passé ou si on préfère se tourner vers l’avenir. Le nivellement par le bas me parait pas la meilleure des solutions.
Ceux qui ne veulent pas utiliser les outils d’aujourd’hui auront accès à des sites un peu moins bien.

Le 20 Août. 2010 à 11h41 par Eric Le Bihan

Effectivement, l’amélioration progressive a pour principal défaut de niveler par le bas (et d’avoir tout à refaire le jour où la société décide de ne plus supporter le navigateur qui provoque ce nivèlement).

En fait comme le dit Nico, c’est d’un point de vue commercial que la dégradation élégante a le plus de difficulté à s’imposer. Rien que par le terme, si le client en face ne sait pas ce que la sous-entend, malgré de vaines explications il gardera en tête « dégradation » qui a plus une image de quelque chose qui vieillit mal et qu’il faudra refaire demain.

La seule pilule qui arrive potentiellement à faire passer la dégradation élégante, c’est les performances. Sauf qu’en fonction du client, il peut s’en fiche comme d’une guigne…

Le 20 Août. 2010 à 11h54 par Loic

@Loic

Effectivement le terme « dégradation élégante », n’est pas à employer avec le client :-)
Après est-ce que le client doit être au courant de tous les détails techniques ? Si le résultat lui convient, ne donnons pas le bâton pour nous faire battre. La plupart du temps, l’internaute utilisera toujours le même navigateur et ne saura pas que le site qu’il voit de telle façon dans Internet Explorer est (légèrement) différent dans Chrome.

Le 20 Août. 2010 à 12h03 par Eric Le Bihan

Curieusement, un des leviers de l’amélioration progressive (et c’était vraiment pas celui que je pensais), c’est le duo « balise vidéo » + « dégoût actuel du flash ».
(ou remplacer « dégoût actuel du flash » par j’ai un produit qui commence par i de chez la Pomme qui aime pas flash)

Voici la discussion :
Client : on veut de la vidéo sur notre site.
Moi : donc il vaut mieux passer par flash.
Client : oui, mais on ne veut pas de flash (arguments précités).
Moi : ah, on ne peut pas vous en vouloir pour ça ! :)

(… discussion sur flash-ç-ai-pas-bien-toussa…)

Moi : Ceci dit, on a peut-être une solution… (faire celui qui réfléchit)
Client : ah bon ?
Moi : oui, si on passe par la balise video de HTML5, ça sera lu sur l’iTruc, les navigateurs modernes… et on garde flash uniquement pour IE.
Client : ah bon, ça marcherait ? Si c’est flash uniquement pour IE… on accepte.
Moi : Et en plus, ça sera bien, on utilise des trucs modernes, toussaaaaaaa…
Client : {content}
Moi : {content aussi}

Le 20 Août. 2010 à 13h42 par Nico

@Nico : On n’est pas obligé de recourir à l’élément HTML 5 video pour éviter de passer par Flash : le bon vieil élément object de HTML 4 et XHTML 1 permet l’imbrication de plusieurs éléments object appelant chacun un format différent (grâce à l’attribut type), en guise d’alternative à l’objet appelé par l’élément object parent. La spécification HTML 4.01 fournit un exemple d’éléments object imbriqués.

Cela dit, le HTML 5 prévoit l’élément source, qui peut être enfant de l’élément video et peut apparaître plusieurs fois pour offrir des formats alternatifs.

Le 20 Août. 2010 à 14h20 par Victor Brito

@Victor Brito : sans blague ? :)
Je te rassure, je suis au courant. ;)

Mais comme on parle ici d’intégrer les nouvelles technos et d’amélioration progressive, je vais pas proposer les « anciennes ». Et il faut reconnaître que la balise vidéo, c’est chuper-pratique.

Le 20 Août. 2010 à 14h59 par Nico

À propos du débat amélioration progressive / dégradation élégante, je pense qu’il s’agit surtout de la manière dont le graphiste va concevoir son design : s’il a conscience de la manière dont il va être assemblée (ou s’il l’intègre lui-même), et qu’il y a une bonne communication avec l’intégrateur, on pourra définir ce qui fait partie de la base du design, et ce qui fait partie des améliorations facultatives. Mais s’il ne sait rien ou se désintéresse de la manière dont la page sera assemblée, alors le design sera conçu comme un tout, et l’intégrateur, s’il veut concevoir ses pages de manière évolutive, va dégrader (élégamment ?) ce design : il n’y a rien à améliorer puisque la maquette est « finie ».

Le 20 Août. 2010 à 16h21 par Pierre Bertet

Les commentaires sont fermés sur cet article.