Les hacks CSS, c’est pas bien ; les commentaires conditionnels, c’est mieux. Pour autant, je ne vois pas d’inconvénient à utiliser quelques hacks à l’intérieur d’une feuille de style réservée à Internet Explorer à l’aide des commentaires conditionnels. En effet, pourquoi ajouter une requête inutile en ciblant chaque version de IE quand on peut régler le problème une fois pour toute ?
L’idée, c’est de ne prévoir qu’une seule feuille de style pour IE pour placer les déclarations spécifiques aux versions 6 et à 7 :
Dans ie.css
Pour s’adresser à IE6 :
* html div {
blablabla
}Et à IE7 :
html>body div {
blablabla
}IE6 et IE7 étant ciblés naturellement par le commentaire conditionnel suivant :
<!--[if lt IE 8]> <link rel="stylesheet" type="text/css" href="ie.css" media="screen" /> <![endif]-->
Espérons que IE8 sera bien conforme aux recommandations du W3C !
Idée inspiré par l’organisation des feuilles de style du framework CSS Blueprint que j’ai eu l’occasion de présenter dans cette traduction. Sans oublier le billet de Country qui a déclenché l’envie d’en faire un billet 😉
Note : Mise à jour de cette technique pour prendre en compte IE8 dans le fichier ie.css et liste des hacks CSS dans l’article Une Feuille de style et des « hacks CSS » pour cibler IE6, IE7 ou IE8
Ha, je suis carrément pas fan des hacks 😐
Que pense tu de cette solution (que je viens tout juste de découvrir) qui mixe un peu le meilleur des 2 mondes : http://www.lesintegristes.net/2008/04/08/cibler-internet-explorer-dans-une-css-oui-et-sans-hack/ ?
@Country > je suis déjà tombé sur ce billet, mais tout ça pour n’avoir qu’une feuille de style, j’avoue que ça devient carrément contre-productif, surtout si c’est pour éviter des hackounets dans une CSS que seul IE « verra »…
L’idée des intégristes peut-être très utile, mais pas dans ce cas, parce que du coup, on déporte la complexité dans le fichier html, ce qui est amha un remède pire que le mal 😉
Comme le dit un commentaire sur le billet que tu cites, un reset CSS efficace et de bonnes habitudes de balisages html, limitent fortement le recours aux hacks, et contrairement à ce qu’on peut lire, l’argument selon lequel, il est difficile de repérer les endroits où l’on doit corriger des déclarations pour IE n’est pas toujours vrai, parce que quand tu testes une page dans IE, tu sais forcément quelle version tu utilises, donc, tu sais aussi quel fichier css modifier 😉
Mais en tout cas merci de m’avoir remis en tête ce billet que je vais garder sous le coude au cas où !
Hello,
J’ai utilisé le principe que tu décris dans mes deux dernières intégrations (mes deux premières intégrations comme freelance!), et ça me semble être un très bon système.
La critique principale contre les hacks est le fait que l’on ne sait pas à quels navigateurs on s’adresse dans une feuille de styles «normale», et qu’on peut avoir des surprises avec 1) des navigateurs non pris en compte dans les tests et 2) des nouvelles versions des navigateurs testés. Beaucoup d’utilisateurs de hacks ont eu des surprises avec IE7, et c’est bien pour cela que les développeurs d’IE7 avaient déconseillé l’utilisation de hacks CSS bien avant la sortie définitive de ce navigateur.
Mais dans une feuille de styles appelée via un commentaire conditionnel visant certaines versions d’IE, on sait très exactement à quels navigateurs on s’adresse (à moins de viser les versions «greater than» plutôt que «less than», ou de ne pas filtrer les versions!). Il suffit de savoir quels hacks sont pertinents pour le panorama de versions d’IE visées.
Le système que tu décris est donc rationnel et bien pensé. Donc: aucune contrindication, bien au contraire. 🙂
Pour la petite histoire: je n’ai pas eu à utiliser html>body pour restreindre un correctif à IE 7. Les trois quarts de mes correctifs (assez nombreux…) étaient pour IE 6, tandis que le quart restant concernait des bugs présents des IE 6 et 7 à la fois, donc j’écrivais simplement le sélecteur (sans «* html» ou «html>body»).
Quant à IE 5.x, j’en ai abandonné le support vu ses parts de marché tombées des 5% vers les 0,3%. 😉
@Florent V. > Dans mon dernier projet, avec une pincée de reset CSS et en m’inspirant de Blueprint pour rationnaliser un peu le placement des blocs, je suis parvenu à limiter les déclarations spécifiques à IE au minimum :
– correctifs pour déclencher le haslayout après un overflow: hidden,
– un décalage de padding dans un menu déroulant (faudra que je pense à essayer display: inline au cas où il s’agisse d’un doublement de marge)
– et quelques correctifs présents dans blueprint comme la correction des marges pour la balise HR ou le décalage des chiffres de l’élément OL.
En plus, comme j’avais des difficultés à installer l’environnement de test pour ie6 sous Vista, j’avais décidé de tester uniquement dans FF et ie7 dans un premier temps et de faire un gros fichier css pour ie6 à la fin, mais non, même pas, tout était nickel à 95% o/
IE 5.x, je ne m’en occupe plus depuis bientôt deux ans ^_^