Les commentaires conditionnels : passé, présent et futur

Openweb.eu.org > Articles  > Les commentaires conditionnels : passé, présent et futur

Abstract

Les commentaires conditionnels ont eu une certaine évolution dans leur pratique, Nicolas Hoffmann vous propose une rapide mise en perspective de ce système autant haï qu’apprécié, et un regard sur l’avenir d’une telle possibilité.

Article

Le système des commentaires conditionnels

Les commentaires conditionnels ont été introduits avec la version 5 d’Internet Explorer, et fonctionnent jusqu’à la version 9 de ce navigateur, la 10 ayant abandonné ce système. L’idée de base est de pouvoir cibler une version spécifique d’Internet Explorer et de lui servir une CSS spécifique.

Voici un exemple de code :

<!--[if IE]>
  <link type="text/css" rel="stylesheet" href="styles-ie.css" />
<![endif]-->

Vous pouvez trouver un article complet sur les commentaires conditionnels sur le MSDN (en anglais) : About conditional comments.

Bien qu’en contradiction avec le principe « idéal » d’un unique code pour tous, ce système a eu comme principal avantage de permettre aux intégrateurs de se sortir des problèmes causés par les vieilles versions d’Internet Explorer. Il a également contribué à diminuer l’usage de « hacks » CSS, méthodes peu pérennes et moyennement fiables.

Bien sûr, ce système n’est pas exempt de défauts, entre autres :

  • il force à maintenir un ou plusieurs fichier(s) CSS, ce qui implique des requêtes supplémentaires,
  • il peut rendre difficile la maintenance d’un site, principalement à cause de nombreuses surcharges et de l’éparpillement des propriétés entre divers fichiers.

La pratique ayant fait son chemin, le système des commentaires conditionnels a évolué.

Évolution de la pratique vers les classes conditionnelles

La technique dite des classes conditionnelles (aussi appelée « sélecteurs conditionnels ») fonctionne ainsi : des classes vont être ajoutées sur l’élément html via les commentaires conditionnels, et permettront de cibler les éléments pour Internet Explorer.

Voici un exemple de code :

<!--[if lte IE 6]> <html lang="fr" class="ie6 oldies"> <![endif]-->
<!--[if lte IE 7]> <html lang="fr" class="ie7 oldies"> <![endif]-->
<!--[if IE 8]> <html lang="fr" class="ie8 oldies">  <![endif]-->
<!--[if IE 9]> <html lang="fr" class="ie9">  <![endif]-->
<!--[if gt IE 9]><!--> <html lang="fr"> <!--<![endif]-->

(c’est un simple exemple qui n’a pas force de vérité absolue, il peut être adaptable à vos besoins ou à vos pratiques)

Ces classes permettent de cibler une ou plusieurs versions d’Internet Explorer, par exemple :

  • .ie8 .header {} ciblera la classe .header sous Internet Explorer 8 ;
  • .ie7 .nav {} ciblera la classe .nav sous Internet Explorer 7 et inférieurs ;
  • .oldies .header permettra par contre de cibler la classe .header sous Internet Explorer 8 et inférieurs.

Si la dernière ligne peut vous sembler bizarre, elle a son sens : Internet Explorer 10 ignorera cette ligne vu que les commentaires conditionnels ne sont plus supportés pour les versions strictement supérieures à la 9 (gt = greater than, « supérieur à »), donc tous les autres navigateurs (qui ne supportent pas ces commentaires conditionnels) et Internet Explorer 10 se contenteront de lire html lang="fr".

Note : les classes sont mises sur l’élément html pour éviter un problème de performances sous IE.

Plusieurs facteurs ont favorisé l’adoption massive de cette technique.

Déjà la meilleure connaissance des rendus légèrement « baroques » des vieilles versions d’IE permet de minimiser les problèmes : les intégrateurs connaissent les propriétés dangereuses de celles qui passent partout, ainsi que les bugs de rendu. Cela permet de diminuer la quantité de styles spécifiques aux vieux IE, ces styles pourront être directement mis dans la CSS principale, ce qui permettra en prime d’éviter de charger un fichier CSS supplémentaire sur ces vieux navigateurs peu performants.

Ensuite, ne le cachons pas : le support de ces vieux navigateurs a tendance à disparaître petit à petit, ce dont nous ne nous plaindrons pas. Le concept de dégradation gracieuse a également fait son chemin : là où un client voulait un rendu parfaitement identique sur tous les navigateurs il y a quelques années, il est désormais plus facilement accepté que le rendu sur les navigateurs plus anciens ne soit pas parfait, tant que le site reste raisonnablement utilisable.

Toutefois, cela ne veut pas dire que l’inclusion de feuilles de styles entières via commentaires conditionnels soit totalement à abandonner. Selon le cas de figure et les objectifs du projet, s’il est décidé de favoriser clairement les navigateurs modernes, les styles additionnels pour les anciennes versions d’IE seront à séparer de la CSS principale.

L’exemple typique : pour économiser les requêtes HTTP sur les navigateurs récents, on peut utiliser les Data-URI. Or, si l’on doit assurer un affichage correct sous IE7 (qui ne supporte pas du tout cette possibilité), il faudra préciser le chemin complet vers l’image.

Évidemment, dans le cas où l’on cherche à favoriser les navigateurs modernes, remettre la ligne avec l’image fait perdre tout l’avantage gagné par la Data-URI. Dans ce cas, une feuille de style séparée sera une meilleure option.

Même si le système des classes conditionnelles peut être utilisable pour d’autres buts que le ciblage d’IE et peut être réalisé via d’autres moyens, tournons-nous vers un futur très proche : à l’avenir, il ne sera plus question de cibler un navigateur et encore moins une version particulière, mais plutôt de se baser sur la détection de feature (« possibilité » en anglais).

Vers l’avenir : la détection de features

Comme les moteurs de rendu des navigateurs s’améliorent tous sans exception, le ciblage de versions particulières de navigateurs tel qu’on le pratique principalement avec les commentaires conditionnels avec IE est amené à disparaître… ce dont, rappelons-le, nous ne nous plaindrons pas.

Toutefois, il sera nécessaire de connaitre les capacités de l’agent utilisateur, afin de lui proposer des fonctionnalités en rapport avec ce qu’il peut utiliser.

À cet effet, plusieurs techniques sont envisageables.

Utilisation d’une bibliothèque de détection en JavaScript

Modernizr est la bibliothèque la plus connue en matière de détection des possibilités d’un agent utilisateur. Pour ne donner qu’un exemple, une fois chargée, Modernizr va ajouter des classes sur l’élément html (en fait, il remplace la classe no-js si elle est présente).

Voici un exemple de code généré par son utilisation :

<html class="js no-flexbox no-touch rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients no-cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio svg inlinesvg" lang="en">

Dans notre exemple, on peut voir que la classe no-flexbox indique que l’agent utilisateur ne supporte pas le mode de positionnement flexbox.

Dans le cas où la classe .header est concernée, il est donc possible de prévoir une roue de secours dans la CSS via .no-flexbox .header {}.

Le principal avantage de cette méthode est d’être fonctionnelle dès à présent. En revanche, son principal inconvénient est d’être basée sur JavaScript, qui est potentiellement désactivable.

Note : l’article se concentre sur CSS pour d’évidentes raisons de longueur, toutefois Modernizr permet aussi de détecter d’autres possibilités de l’agent utilisateur : API JavaScript, support de certaines balises, SVG, etc.

@supports

@support fait partie du CSS3 Conditional Rules Module Level 3. À terme, cette règle permettra une détection native des possibilités CSS de l’agent utilisateur.

Voici un exemple de son utilisation :

@supports (display:flex) {
  section { display: flex }
  …
}

Cette propriété serait totalement merveilleuse… si son support actuel n’était pas très insuffisant. Au moment de l’écriture de cet article, seuls Firefox 22 (bêta), Chrome Canary (alpha) et Opera 12.1 (version en cours) annoncent la supporter.

Mise à jour du 23 Avril 2014 : Firefox, Chrome et Opera dans leurs dernières versions la supportent.

Toutefois, gageons que le support de @supports ne peut que vite s’améliorer !

Conclusion

Le ciblage d’une version spécifique d’un navigateur, à l’exception des vieilles versions d’Internet Explorer, est une pratique qui tend à disparaitre. Pour d’évidentes raisons de maintenabilité, l’orientation de la pratique est plutôt aux classes conditionnelles permettant de maintenir dans la mesure du possible une unique CSS pour tous les navigateurs.

L’avenir passera par la détection directe des possibilités de l’agent-utilisateur ; ainsi les projets pourront garantir une expérience utilisateur optimale avec aussi peu de code que possible.

Références, compléments

À propos de cet article

  • Openweb.eu.org
  • Profil : Débutant, Expert
  • Technologie : CSS
  • Auteur :
  • Publié le :
  • Mise à jour : 23 avril 2014
  • 2 commentaires

Vos commentaires

  • Intégrateur Le 29 mai 2013 à 00:48

    Bonjour Nicolas,

    Merci pour cette ressource claire et détaillée. J’ajouterai simplement, ayant eu à sélectionner IE10 pour résoudre un bug d’affichage, que l’astuce consiste à utiliser un script qui filtre bien, lui, IE10. Voici le code complet, testé et approuvé, à modifier selon ses besoins.

    <script type="text/javascript"> 
if (/*@cc_on!@*/false) { 
    var headHTML = document.getElementsByTagName('head')[0].innerHTML; 
headHTML    += '<link type="text/css" rel="stylesheet" href="ie10.css">'; 
document.getElementsByTagName('head')[0].innerHTML = headHTML; 
} 
</script>

    Alors, bien sûr, je ne vais pas troller, c’est une rustine et dans mon cas je me suis planifié de chercher dans le code ce qui pose problème, sûrement un box model surclassé quelque part. Mais en attendant cette astuce fait son boulot, et me retire une épine du pied :-)

  • Da Scritch Le 9 août 2013 à 08:08

    Excellent article, bravo Nico

    À noter que icrosoft a aussi créé un équivalent pour JScript, rendant le code là aussi difficilement bittable. Et étonnement, cette “feature” n’a pas été retirée dans MSIE10. Alors qu’à priori, en Javascript, c’est nettement plus rapide de faire de la detection feature, non ?
    http://dascritch.net/post/2013/04/08/Dirty-Hacky-I-%3A-Commentaires-conditionnels#jscript

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom