Posez quelques classes conditionnelles sur la balise <html> et codez proprement, y compris pour IE, en évitant les hacks et les feuilles de styles alternatives !
Internet Explorer est un navigateur qui pose problème à tous les développeurs web, par ses bugs et son non respect des standards. Plusieurs méthodes sont utilisées pour palier à ses déficiences : hacks CSS, commentaires conditionnels, feuille de style alternative par navigateur…
Les commentaires conditionnels, oui mais...
Les hacks CSS — comme « * html{} » et « *+html{} » pour cibler respectivement IE 6 et 7 — sont des bidouilles à éviter car ils sont peu pérennes et peu fiables. Pour coder plus proprement, mieux vaut utiliser les « commentaires conditionnels » mis à disposition par Microsoft pour Internet Explorer Windows.
Grâce à eux, beaucoup déportent leurs déclarations dans une feuille de style externe, ou plutôt plusieurs, dédiées à Internet Explorer, version par version, appelées entre les balises <head> de la page HTML, à l’aide de commentaires conditionnels, comme ceci :
<link rel="stylesheet" type="text/css" href="css/style.css" />
<!--[if IE 7]><link rel="stylesheet" type="text/css" href="css/ie7.css" /><![endif]-->
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="css/ie6.css" /><![endif]-->Mais c’est une méthode humainement détestable, car le style est pénible à maintenir du fait de l’éparpillement du code en différents fichiers. Non seulement cela interfère sur le calcul des priorités CSS au point de devoir répéter parfois certaines déclarations, mais le risque est gros d’en oublier dans les recoins : quand on revient ajuster tel bloc, comment deviner quelles surcharges se cachent dans ces fichiers alternatifs, sauf à ouvrir et relire scrupuleusement chaque feuille de style à chaque intervention ?
C’est ainsi qu’alors que s’annonce la sortie de la version 10 de ce navigateur, on croise encore des feuilles dédiées à IE 5 et même IE 5.5… et certains se retrouveront bientôt avec un minimum de 7 feuilles de style alternatives à maintenir pour Internet Explorer, une par version ! C’est inhumain.
Modularité : regroupez vos déclarations
Pour bien faire, mieux vaut regrouper les déclarations dans une feuille de style, idéalement unique — quitte à utiliser des hacks, ouille. Mais il y a plus malin que nos bons vieux hacks : la méthode exposée à cet article (en troisième partie) : « Cibler Internet Explorer dans une CSS ? Oui, et sans hack. ».
Il s’agit d’utiliser les commentaires conditionnels pour poser des sélecteurs dédiés sur la page HTML, de façon à disposer de classes à utiliser comme ceci dans votre feuille de style :
.toto { ... }
.ie6 .toto { ... }
.ie7 .toto { ... }Vous pouvez ainsi regrouper vos déclarations CSS de façon plus cohérente : par bloc, par module, par plugin… et non plus par navigateur ni même par média. Plus besoin de feuilles de style alternatives : en route vers plus de modularité, jetez-les !
Perfo : placez vos classes sur <html>
Les intégrateurs futés que vous êtes ont pris la bonne habitude de placer ces sélecteurs CSS parents sur la balise <body>. C’est très bien, mais… cela peut ralentir le temps de chargement des pages dans Internet Explorer ! Pour éviter tout souci, mieux vaut s’appuyer sur la balise <html>, si si, comme dans HTML5 Boilerplate, comme l’explique Paul Irish : Conditional stylesheets vs CSS hacks ? Answer : Neither !. Voici ce qui est recommandé :
<!--[if lt IE 7 ]> <html class="ie6"> <![endif]-->
<!--[if IE 7 ]> <html class="ie7"> <![endif]-->
<!--[if IE 8 ]> <html class="ie8"> <![endif]-->
<!--[if IE 9 ]> <html class="ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html class=""> <!--<![endif]-->J’y ajoute les classes plus globales « ie » et « noie » pour mon confort personnel, sans oublier les attributs de langue « dir="ltr" lang="fr" », etc.
Au final les pages HTML commencent par une grosse tartine de code, mais ce n’est rien à côté du gain en confort d’écriture des feuilles de styles, en maintenance, en modularité et en perfo. N’hésitez plus !
Vos commentaires
1. Le 2 août 2011 à 12:26, par Nicolas Hoizey
En réponse à : Sélecteurs conditionnels pour IE
J’ai tendance à m’arrêter à IE8, tant qu’à faire, cela devrait suffire amplement.
Et le dernier test est inutile :
<!--[if (gt IE 9)|!(IE)]><!--> <html class=""> <!--<![endif]-->IE10 n’aura plus de CC donc
(gt IE 9)ne sera jamais vrai, et!(IE)non plus vu qu’il n’y a que IE qui interprête les CC...2. Le 2 août 2011 à 13:56, par Martin - Webaaz
En réponse à : Sélecteurs conditionnels pour IE
j’ai eu dernièrement à utiliser un hack contre mon gré !
Cas particulier du développement d’un module pour un CMS.
Cas noirmal avec ce CMS, pour que la CSS soit concaténée et minifiée je dois l’inclure via une méthode du framework qui ne prends pas de paramètres.
Donc, soit je perdait la concaténation et la minification et donc les performances, soit je sortait mon code dans une feuille de style dédiée à IE et déjà existante mais mon module perdait sa consistance, soit j’utilisais un hack...
Qu’en penses-tu ?
3. Le 2 août 2011 à 14:49, par Romy Têtue
En réponse à : Sélecteurs conditionnels pour IE
Cette approche avec des sélecteurs conditionnels permet de regrouper le code par modules fonctionnels et non plus par média destinataire, ce qui est certes plus cohérent mais devrait aussi faciliter la concaténation. Reste que ce n’est pas forcément bien implémenté partout... Utilise SPIP ;)
Dans le cas que tu évoques, un hack te dire d’affaire à moindres frais. Nécessité fait loi :)
4. Le 2 août 2011 à 21:02, par bgermain
En réponse à : Sélecteurs conditionnels pour IE
Dommage que cette pratique ne soit pas valide en HTML, je préfère l’utilisation de la classe sur body.
5. Le 11 novembre 2011 à 17:28, par Romy Têtue
En réponse à : Sélecteurs conditionnels pour IE
précise Alsacréations : les classes conditionnelles en CSS.
6. Le 13 novembre 2011 à 12:07, par Corinne
En réponse à : Sélecteurs conditionnels pour IE
En fait, je nuancerais juste ta réponse : elle est valide en HTML5. Si on tente de l’utiliser avec un doctype HTML 4, on se refera retoquer par le navigateur. Ca peut toujours être bon à savoir...
7. Le 14 novembre 2011 à 11:21, par Romy Têtue
En réponse à : Sélecteurs conditionnels pour IE
@bgermain @Corinne : seriez-vous prêts à renoncer aux avantages de cette méthode, notamment au gain en maintenabilité, juste pour satisfaire les bots validateurs ? Pourquoi ?
8. Le 12 décembre 2011 à 20:05, par Joseph Tux
En réponse à : Sélecteurs conditionnels pour IE
Merci pour cette contribution
Si je lis bien, grâce à Mr Porte et ses collaborateurs, inventeurs des brevets sur les fenêtres, il faudrait écrire 5 CSS supplémentaires = 6 fois le travail ( pour le créateur ) mais aussi un important ralentissement du chargement ; une surcharge du serveur ( multiplié par le nombre des sites qui se soumettent à ces exigences perverses ), et un encombrement de la bande passante, pour limiter les moyens d’expressions, d’esthétique et d’ergonomie !
J’apprécie ces conseils pour leur qualités et leur utilité immédiate, mais je ne perdrai plus mon temps à courir après les frasques, les distorsions, les retards, les « inventions » de micromou, juste pour éviter un langage commun et clair, seulement nuisible aux dépôts de brevets et autres affaires juteuses d’un quasi monopole. ( Il paraîtrait que la Chine resisterait encore bien.. on aurait préféré les démocraties. )
Plutôt que de mixer la viande peu digeste pour les utilisateurs, je pense qu’il vaut mieux contrer la propag^^ publicité toxique en éduquant les utilisateurs et en les aidant à faire des choix d’une bonne viande ( surtout quand elle est aussi moins chère ), ce que je n’ai jamais vu regretter.
Le refus de payer des licences onéreuses et inutiles ( sauf à flatter la dominations par les dominants pour son propre intérêt, rapide mais mal compris ) me semble être la première voie vers un peu plus de respect, de partage et de liberté.
La richesse et la simplicité des alternatives libres sont tels aujourd’hui qu’on ne voit plus très bien à quoi et à qui servent ces systèmes privatifs, toujours plus clinquants que réellement efficaces, sinon à enrichir facilement un quasi-monopole
Et en bonus, pour être dans le ton millénariste de la faillite mondiale, ne crachons pas sur le bonus de quelques milliards de moins dans notre dette collective, faciles à ne plus gaspiller, et sans sacrifier à son bonheur d’ internaute ou de secrétaire, bien au contraire ( moyennant un très modeste effort de réadaptation au choix, à la liberté et à la créativité )
9. Le 29 février 2012 à 23:31, par nstr
En réponse à : Sélecteurs conditionnels pour IE
Bonjour,
Désolé de revenir sur un sujet un peu daté, mais une question me turlupine après avoir lu cet article (fort intéressant) et celui d’Alsacréations sur le même sujet : pourquoi ne pas utiliser
$_SERVER['HTTP_USER_AGENT'], qui devrait en principe passer partout ? On sait que le js est mal, car pas forcément supporté par tous les navigateurs (sous-entendu toutes les configurations), et qu’il alourdit le chargement côté client, mais vous n’évoquez pas la méthode php. J’imagine qu’il y a une raison, mais laquelle ?D’avance merci pour cet éclaircissement !
10. Le 1er décembre 2012 à 23:35, par Romy Têtue
En réponse à : Sélecteurs conditionnels pour IE
@nstr : c’est d’une fiabilité très décevante parce que, trop souvent, les navigateurs mentent sur leur identité. Lire cet indispensable article de Rudy Rigot : Les User Agents, c’est le mal.
11. Le 12 décembre 2013 à 11:23, par Sabrina Lange
En réponse à : Sélecteurs conditionnels pour IE
Merci beaucoup pour toutes ces explications, cela fait des jours que je galère pour arriver au bon résultat !
12. Le 6 novembre 2015 à 00:42, par Mike
En réponse à : Sélecteurs conditionnels pour IE
Quand je lis ça, j’ai hâte que IE ne soit qu’un lointain souvenir. Enfin... Quand on voit que certain client demandent encore la compatibilité IE6, je sens que le souvenir va mettre longtemps à en devenir un. Merci pour ces explications en tout cas.
Répondre à cet article
Suivre les commentaires :
| 