Une «classe conditionnelle» pour IE 6 et 7

Astuce par Florent V. (Chef de projet, intégrateur web, Lyon, France)
Mis à jour le 14 Avril 2010. 9863 lectures.
Tags : css, internet explorer, hacks, IE6, ie7, commentaire conditionnel

Les cancres du Web, Internet Explorer 6 et 7, nous mènent parfois la vie dure. Même quand on s’abaisse à leur niveau, il leur arrive de ne pas comprendre, ou d’y mettre de la mauvaise volonté.

C’est qu’en plus d’être limités, ces deux navigateurs ont parfois des réactions bizarres. Heureusement, IE8 corrige largement ces problèmes. Mais comment gérer le cas Internet Explorer 7 quand modifier légèrement les styles appliqués à tous les navigateurs ne suffit pas? Ou pire encore, gérer les multiples bugs d’IE6 (si vous en assurez encore le support)?

La solution classique (comprendre: à l’ancienne) est d’utiliser des hacks CSS. Ces derniers sont déconseillés car peu fiables; en effet, on ne sait jamais à l’avance quels seront les navigateurs sur le marché dans deux ou cinq ans, et comment ils comprendront ou pas nos hacks CSS. Une deuxième solution, conseillée par Microsoft et Alsacréations (que du beau monde :)), est d’utiliser les commentaires conditionnels.

Nous allons voir dans cette article que l’utilisation habituelle des commentaires conditionnels a quelques désavantages, et proposer une technique qui combine le meilleur des deux mondes: commentaires conditionnels pour cibler Internet Explorer, et quelques hacks CSS pour cibler des versions particulières.

1. Utilisation classique des commentaires conditionnels

On veut appliquer à chaque version d’Internet Explorer qui pose problème (mettons la 6 et la 7) une feuille de styles qui comportera quelques lignes de correctifs CSS. Quelques lignes seulement, car si on se retrouve à dupliquer la feuille de styles principale on s’est planté (non seulement c’est inutile, mais en plus ça posera des problèmes lors des modifications ultérieures des styles CSS).

On écrira donc dans l'élément head de chaque page du site:


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

Les inconvénients de cette méthode:

IE6 doit charger deux fichiers au lieu d’un (styles.css et styles-ie6.css), de même pour IE7 (styles.css et styles-ie7.css). Ce n’est pas énorme mais ça fait une requête HTTP supplémentaire, ce qui a un petit impact sur la vitesse d’affichage des pages.
Certains correctifs CSS s’appliquent à la fois à Internet Explorer 7 et à IE6. Il faudra les écrire une fois dans chaque fichier de correctifs.
Le plus important: à chaque changement de styles.css, il faudra vérifier dans les deux feuilles de correctifs CSS s’il n’y a pas des changements à répercuter. La maintenance et l’évolution des styles CSS deviennent difficiles.

2. Une classe CSS conditionnelle

La méthode que je vous propose permet de se passer de feuilles de styles supplémentaires. La première étape se passe également dans la structure HTML de vos pages. Cette fois, on ne s’intéresse pas à l'élément head mais à l’élément body:


<body>
<!--[if lte IE 7]><div class="ISIE67"><![endif]-->
...
<!--[if lte IE 7]></div><![endif]-->
</body>

On encadre tout le contenu de body par deux commentaires conditionnels, qui visent tous les deux IE7 et IE6 (et aussi les versions inférieures, mais ces dernières ont pour ainsi dire disparu de la circulation).

En clair, le code HTML compris par Internet Explorer 6 ou 7 ressemble à ceci:


<body>
<div class="ISIE67">
...
</div>
</body>

Tandis que IE8, IE9, Firefox, Chrome, Safari, Opera et tous les autres comprennent ceci:


<body>
...
</body>

Cela veut dire que la classe "ISIE67" (nom choisi arbitrairement, changez-le si vous le souhaitez) peut être utilisée pour différencier Internet Explorer 6 et 7 des autres navigateurs. Voici comment ça se passe côté CSS:


#test { 
  /* Styles pour tous navigateurs */ 
} 
.ISIE67 #test { 
  /* Styles pour IE 6 et 7 */ 
} 
body > .ISIE67 #test { 
  /* Styles pour IE 7 */ 
} 
* html .ISIE67 #test { 
  /* Styles pour IE 6 */ 
}

Voici une analyse de ce code, sélecteur par sélecteur:

Le sélecteur de base utilisé dans cet exemple est #test {}. Il correspond à un élément du contenu de la page, quel qu’il soit (un conteneur, un paragraphe, un lien…). La plupart du temps, on va définir les styles pour #test sans se soucier d’Internet Explorer 6 et 7.
Si jamais on rencontre un bug dans l’une ou l’autre version d’Internet Explorer, et que modifier légèrement les styles CSS appliqués à tous les navigateurs ne suffit pas, on peut avoir besoin d’appliquer un correctif CSS d’une ou deux lignes (rarement plus), spécifique à IE6-7, pour cet élément. On va pouvoir utiliser le sélecteur .ISIE67 #test {}.
Si le problème est spécifique à Internet Explorer 7 (c’est assez rare), on a un moyen simple de cibler uniquement cette version. On continue à utiliser la classe "ISIE67" pour restreindre le champ d’action à ces deux navigateurs, et on la combine avec le sélecteur d’enfant (symbole >) qu’IE6 ne comprend pas. On écrit donc body > .ISIE67 #test {} (car l’élément qui porte la classe "ISIE67" est un enfant de body), et le sélecteur sera compris par IE7 et ignoré par IE6.
Enfin, pour cibler IE6 uniquement, on va utiliser un hack CSS. Il s’agit du Star HTML Hack, qui consiste à placer un sélecteur d’élément universel (symbole *) avant un sélecteur d’élément qui vise l’élément html. Le sélecteur obtenu ne devrait trouver aucun élément dans la page, car l’élément html est la racine du document, il n’y a pas d’autre élément en amont! Ce sélecteur est malgré tout compris par Internet Explorer 6, tandis qu’IE7 corrige ce bug. On l’utilise donc ici pour distinguer IE6 et IE7, tout en conservant notre classe "ISIE67" pour filtrer les autres navigateurs, pour plus de sécurité. On obtient donc: * html .ISIE67 #test {}.

Pour finir, sachez que cette technique est inspirée d’une technique présentée par Pierre Bertet. La technique de Pierre est plus complète, et sensiblement plus complexe côté HTML; par contre la syntaxe des sélecteurs CSS est un peu plus simple quand il s’agit de viser spécifiquement IE6 ou IE7 (surtout si vous n’êtes pas un habitué du sélecteur d’enfant et du Star HTML Hack). À vous de voir quelle variante vous préférez.

3. Limites de la technique de classe conditionnelle, et solutions

La technique que je présente a quelques limites:

Elle s’intéresse uniquement à Internet Explorer 6 et 7, et ne permet pas de viser la version 8. (À ma connaissance ce n’est pas un grand problème car le support de CSS 2.1 dans IE8 est très bon.)
L’élément div qui porte la classe "ISIE67" est un enfant de body. Cela signifie que cette classe ne peut pas être utilisée pour modifier les styles des éléments html et body.
Enfin, certains scripts JavaScript créent à la volée des éléments HTML qui sont rajoutés à la fin de l’élément body. Les styles de ces éléments générés en JavaScript ne pourront pas être modifiés via la classe "ISIE67" non plus.

D’expérience, les deux premiers problèmes sont rarement handicapants. Par contre le troisième problème peut l’être. Je vous propose donc une solution JavaScript, qui n’est pas parfaite, mais qui peut être utile. Il s’agit de rajouter dans l’élément head de la page le code suivant:


<!--[if lte IE 7]>
<script type="text/javascript">document.documentElement.className+=' ISIE67';</script>
<![endif]-->

Vous pouvez utiliser cette solution en remplacement du code HTML à rajouter dans le body, mais dans ce cas la classe "ISIE67" ne sera utilisable que si JavaScript est activé! Vous pouvez aussi garder les deux codes (celui-ci dans le head, et celui proposé dans la partie précédente dans le body).

Enfin, je précise à l’attention des développeurs JavaScript que la solution ci-dessus peut être gérée différemment, avec un ajout de classe sur l’élément body plutôt que html, peut être reproduite en jQuery ou autre, etc. À vous d’adapter. :)

Commentaires

Patidou a dit le 2010-04-14 23:46:14

Heu non, Florent, il ne faut pas utiliser une librairie javascript pour ajouter la classe sur l'élément html : il y a un problème de perfomance car il faut d'abord charger la librairie, pendant ce temps l'affichage peut bouger. Et il n'est pas conseillé non plus d'utiliser <body>.

Plus d'info : http://www.lesintegristes.net/2010/01/27/pour... ;-)

Opi a dit le 2010-04-14 23:50:08

On peut sinon faire quelque chose comme ca :

body class="uneclasse <!--[if lte IE 7]<ISIE67<![endif]--< uneautreclasse">

si je ne me trompe pas ?

opi

Florent V. a dit le 2010-04-15 00:29:23

@Patidou: je n’ai pas recommandé d’utiliser jQuery pour rajouter une classe sur l’élément html. Je mentionne que c’est une possibilité, avec tout un tas d’autres. Alors oui, mieux vaut ne pas charger une libraire JS + attendre un évènement domready pour ajouter une classe dont dépendent une partie des styles pour IE6-7. Mais si pour une raison ou une autre on doit (ou on veut…) placer mon bout de JS ou un équivalent dans un fichier externe, quitte à ce que l’ajout de classe se fasse un peu tard, eh bien c’est une possiblité technique et pour beaucoup de petits ou moyens sites ça ne sera pas dommageable.

@Opi: non, on ne peut pas mettre de commentaire HTML au milieu d’une balise HTML. C’est invalide en XHTML1 et en HTML5, vaguement valide en HTML4 à cause d’une fonctionnalité de SGML mais dans ce dernier cas le commentaire ne sera pas vu comme un commentaire et ça va mettre le bazar.

vvoyer a dit le 2010-04-15 00:44:05

Hello, concernant :

"Certains correctifs CSS s’appliquent à la fois à Internet Explorer 7 et à IE6. Il faudra les écrire une fois dans chaque fichier de correctifs."
Et si on fait trois css : un pour ie6, un pour ie7 et un pour ie7&6;?

avec lte IE7 on arrive dans le cas ie7&6;Pour la remarque "on fait faire une requête de plus à ie6/7" tout dépend de la quantité de code nécessaire pour faire fonctionner les css dans ie6/7.

Car si on utilise la technique citée, cela signifie qu'on surcharge tous les navigateurs autres que ie6 & 7 avec des classes/règles dont ils n'ont que faire.

Alors est-ce qu'on souhaite "pénaliser" les vieux navigateurs ou surcharger les gens qui utilisent des navigateurs récents?
Moi je pencherai plus pour "pénaliser" ie6 & 7 en leur faisant faire une requête supplémentaire, surtout qu'ils sont capables de télécharger deux css en même temps (au moins pour ie7).

Charger les styles ie6 dans firefox 3.6, chrome 4 et safari me semble être un mauvais choix, surtout depuis qu'on parle de plus en plus de "progressive enhancement", autant aller jusqu'au bout.

Est-ce qu'il est plus judicieux de faire télécharger X octets en plus pour tout le monde ou bien faire une requête de plus pour les ie6 & ie7, la réponse est claire pour moi ... !

Ladytron a dit le 2010-04-15 00:46:44

En même temps, si on veut traiter IE sans faire appel aux commentaires conditionnels ou aux hacks, on a pas trop le choix : il faut insérer une classe CSS via un bout de JS, et le choix des tags est pas très large pour ça : à part body, je vois pas trop ; c'est ce qui me semble le plus propre: pourquoi n'aurait-on pas le droit d'appliquer une classe à body via JS pour cibler IE ?

Ceci étant, ma préférence reste d'inclure des correctifs IE sur des feuilles de styles en commentaires conditionnels et utiliser Javascript pour les autres cas insolubles en CSS :)

Florent V. a dit le 2010-04-15 01:41:48

@vvoyer, je me cite:
«Les inconvénients de cette méthode: (…) Le plus important: (…) la maintenance et l’évolution des styles CSS deviennent difficiles.»

La question des performances client, que ce soit par le poids rajouter à une feuille de styles commune ou l'ajout d'une requête HTTP pour certaines versions d'IE, me semble pas si importante. Je dirais que dans le cas où on attache les correctifs CSS (par nature réduits, sinon il faut apprendre à faire du CSS qui tient la route ;)) aux styles principaux, c'est négligeable. L'ajout d'une requête HTTP, surtout pour IE6 et 7 qui font peu de requêtes parallèles, est à mon avis plus dommageable, c’est pourquoi je le mentionne. Mais à la rigueur ça n’est pas bien important.

La principale motivation de cette méthode, pour moi, c’est d’éviter de séparer les styles «normaux» des correctifs CSS. D’expérience, sur des projets à partir de quelques milliers de lignes de code CSS et demandant des interventions régulières (maintenance, évolutions, refactoring), avoir les correctifs IE 6-7 séparément est la meilleure manière d’oublier de corriger ou faire évoluer ces correctifs. J’y ai déjà perdu des heures sur de gros projets.

Folken-Laeneck a dit le 2010-04-15 02:25:06

Il est tard, je vais peut-être dire une bétise et je préviens à l'avance que je n'ai pas testé la validité de ce code, mais est-ce qu'on ne pourrait pas lier les deux solutions ensemble en faisant quelque chose comme ceci :

<!--[if IE 7]><body class="ie-7"><![endif]-->
<!--[if IE 6]><body class="ie-6"><![endif]-->
<!--[if !IE]> <--><body><!--> <![endif]-->

Plus besoin de diviser les feuilles de styles et d'alourdir la maintenance, mais plus besoin non plus de se reposer sur du javascript pour appliquer des styles.

br1o a dit le 2010-04-15 03:35:44

Quitte à utiliser cette technique pourquoi ne pas appliquer le commentaire conditionnel sur la balise html au lieu de créer une div pour IE ? Pour ma part, même si j'aime bien explorer de nouvelles techniques, la plus propre pour moi, c'est de cibler les différentes versions d'IE à l'intérieur d'une seule feuille de style dédiée à toutes les version d'internet explorer comme ici : http://css4design.com/une-feuille-de-style-et...

Raphael a dit le 2010-04-15 07:30:45

@Folken-Laeneck, @br1o : j'aime beaucoup l'idée d'appliquer tout simplement une classe sur body ou html :)

jpvincent a dit le 2010-04-15 09:05:42

@Florent V. : franchement je te soutiens sur le fait qu'inclure des feuilles de style alternatives pour IE6-7, d'un point de vue perfs, c'est vraiment mal, aussi merci beaucoup pour ces techniques alternatives.

Pourquoi c'est mal ? parce que ces 2 browsers sont justement ceux qui ont le + besoin d'optimisation des perfs, et que inclure un CSS, c'est impactant car pendant le download (et je crois qu'ils ne font qu'un seul download à la fois sur les css), le browser bloque tout rendu.

et oui si on veut une feuille de style valide, appliquer la classe au body est encore le plus propre.

maintenant perso, je n'ai jamais cherché à avoir une feuille de style valide, donc j'utilise toujours le hack avec _ ou * devant la property ... en espérant qu'ils soient suffisamment répandu pour que les futurs browsers ne les interprètent jamais :)

Florent V. a dit le 2010-04-15 09:56:38

@Folken-Laeneck : Ta solution ne marche pas car elle est incomplète. Par contre, Yves Van Goethem en propose une version plus complète dans les commentaires du sujet cité par br1o.

Si je reprends la solution d'Yves, et que je l'adapte comme je l'ai fait pour la solution de Pierre, en HTML5 ça revient à faire:

<!DOCTYPE html>
<!--[if !IE]><!--><html lang="fr"><!-- <![endif]-->
<!--[if lte IE 7]><html lang="fr" class="ISIE67"><![endif]-->

Du coup, pas de DIV supplémentaire qui peut parfois gêner certaines mises en page (essentiellement les pages en min-height:100%), et pas de problème avec les éléments rajoutés en JS à la fin de l'élément body. On peut aussi faire la même chose sur l'élément body plutôt que html (ce qui a l'avantage d'être valide en HTML4).

Felipe a dit le 2010-04-15 10:38:14

Les commentaires conditionnels sur du code HTML avec les éléments body ou html, est-ce que ça ne risque pas d'être mal interprété par des outils simplistes à la façon 'tiens il y a plusieurs éléments body/html dans cette page, je vais tout foirer' ?
Pour les parsers des navigateurs aucun souci, c'est bien pour ça que les CC çaÿbieng mais doit y avoir des outils moins robustes qui traînent ...

vvoyer a dit le 2010-04-15 10:54:14

Une autre solution si vous souhaitez vraiment utiliser la technique de l'article : une seule feuille de style :
- Mettre des marqueurs simples chaque fois que vous écrivez un hack css IE (en commentaire css par exemple).
- Puis au moment du déploiement de votre appli, pour chaque css qui contient des hacks css vous créez des fichiers _ie6.css _ie7.css qui contiennent l'essentiel pour le navigateur (css communs + hacks spécifiques version).
Supprimez ensuite tous les hacks css du fichier de base.
Puis avec une réécriture d'url vous dirigez toutes les demandes de css en fonction du user agent vers les mêmes fichiers css avec _ie6.css ou _ie7.css rajouté.

Long est fastidieux mais au moins Firefox, safari, chrome etc ne se tapent pas des styles css foireux.

Si la performance est importante pour votre application et que votre site utilise énormément de bande passante j'imagine que cette solution sera la plus adaptée.

Une autre solution qui cette fois sort complètement du but de l'article mais qui m'a bien aidée dans pas mal de cas, c'est d'utiliser les scripts IE7/8/9.js de dean edwards qui corrigent une bonne partie des mauvais comportements css de ie6-7-8.

De plus IE7.js a été mis à jour récemment. Je l'ai utilisé sur un site vitrine dernièrement et le résultat est parfait, 0 css supplémentaires, 0 hacks à utiliser.

http://code.google.com/p/ie7-js/

Je ne l'ai pas utilisé sur un "énorme" projet donc pas de retour la dessus mais pas de raison que le comportement soit différent d'un site vitrine classique.

Une bonne solution si on veut arrêter de se prendre la tête sur des bugs navigateurs qui ne nous font pas progresser dans notre métier.
Alors certes ça fait télécharger un javascript de plus pour les ie6-7 mais si vous vous débrouillez un peu vous pourrez le faire télécharger en // des autres scripts et en dernier dans votre page.

Juste pour info concernant l'hypothèse du chargement en // des css, tous les IE le font depuis la version 6, voir sur http://www.browserscope.org/?category=network... 6,IE 7,IE 8,IE 9

Hermann a dit le 2010-04-15 16:33:09

@vvoyer : "Une bonne solution si on veut arrêter de se prendre la tête sur des bugs navigateurs qui ne nous font pas progresser dans notre métier."
Ca ne corrige ni les bugs de haslayout ni les autres différences d'affichage mais c'est très commode effectivement, notamment pour implémenterles pseudo-class/éléments CSS3. Un seul regret: même IE9.JS ne permet pas d'implément les display:table-machin.
D'autre part d'expérience il vaut parfois mieux utiliser un filter Microsoft que se reposer sur cette lib. pour des raisons de perfs d'affichage.

cahnory a dit le 2010-04-16 13:11:05

Petite application ici :
http://ns368219.ovh.net/~dev/conditional-comm...

J'ai préféré utiliser un id plutôt qu'une classe pour javascript afin d'éviter les soucis de classes multiples rencontrés par ie.

Une page intéressante sur les commentaires conditionnels :
http://msdn.microsoft.com/en-us/library/ms537...

Riku Asakura a dit le 2010-04-17 15:12:17

Je n'arrive pas à comprendre en quoi c'est plus simple de maintenir un document d'un millier de lignes plutôt que deux documents de 750 et 250 lignes par exemple.
Surtout que la division en plusieurs feuilles de styles peut permettre un repérage plus rapide.
Je suis sur "styles-ie6.css" je sais que je vais jouer avec les styles IE6.

De plus, comme l'a précisé vvoyer, je préfère faire charger des fichiers complémentaires aux mauvais élèves plutôt que de tout faire charger à tous les navigateurs.
Je pense donc rester sur du commentaire conditionnel dans HEAD pour le moment.

L'astuce reste tout de même très intéressante, notamment la discussion qui en découle, la solution de la classe sur HTML me semble plus pertinente que la division. Mais en pratique... ?

Merci Florent.

Ladytron a dit le 2010-04-18 13:54:54

@Riku Asakura :
J'suis assez d'accord, ayant l'habitude de pas plomber les bons élèves avec des trucs qui ne leur sont pas destinés.
En terme de repérage, c'est plus simple, c'est vrai. Si on a besoin de corriger un truc pour IE7, on sait où ajouter ça, c'est rapide.

En pratique, avec la classe conditionnelle, tous les styles devront être dans le même fichier, même les correctifs pour les "mauvais élèves" (les bons élèves se taperont à charger des règles qu'ils n'appliqueront pas). Pas génial, quoi.
La solution la plus "pratique" reste encore la division avec les commentaires conditionnels dans le head (à mon avis) ;)

Florent V. a dit le 2010-04-18 22:03:36

Bon, tout ça c’est des questions de méthodologie personnelle ou d’équipe (avant tout d’équipe, peut-être). Quelques remarques:

1. Je préfère ne pas séparer les styles génériques et les correctifs (quel que soit le navigateur visé par ces derniers). Il m’est arrivé plusieurs fois de perdre du temps à cause d’un code ancien dans un fichier ie-fixes.css, code dont j’avais oublié l’existence et qui entrait en conflit avec les nouveaux codes CSS génériques suit à une évolution, une maintenance, une factorisation de certains styles, etc. Peut-être que je suis juste étourdi et que certains arrivent à garder à l’esprit le contenu de fichiers ie6.css, ie7.css et autres pendant qu’ils interviennent sur les styles génériques. Moi ça m’a trop souvent joué des tours pour que je revienne à ce type de segmentation des codes.

2. «Ne pas obliger les bons élèves à charger les correctifs destinés aux cancres», ce n’est pas un objectif pertinent. Il n’a, en soi, aucun intérêt pratique. L’impact sur les performances est négligeable. (@Riku, 250 lignes de correctifs IE pour 750 lignes de CSS génériques, c’est n’importe quoi. Pour 1000 lignes de CSS génériques, j’ai 10 lignes de correctifs IE, parfois 20, et pas plus. Si on dépasse un rapport de 5% de correctifs, on a un gros problème…)

3. Je ne vois pas d’intérêt à organiser les CSS en répartissant les styles pour un élément (un «module») donné dans plusieurs fichiers. À une époque certains conseillaient de placer les styles pour la typographie dans un fichier, ceux pour la gestion du positionnement et des espaces dans un autre, ceux pour la décoration (fonds, couleurs, images…) dans un troisième. Je crois que certains thèmes pour Dotclear étaient conçus ainsi. Une horreur à maintenir ou modifier, à mon avis. Mais certains trouvent peut-être ce genre de structure plus pratique, et souhaitent l’appliquer aussi pour les correctifs CSS… why not. Pour ma part je préfère garder ensemble tous les styles qui concernent un contenu donné. Pour un site important, je vais séparer ces styles dans plusieurs fichiers CSS, en essayant de rester en-dessous de quelques centaines de lignes pour chaque fichier, et en allant du plus générique au plus particulier.

Ladytron a dit le 2010-04-18 22:57:38

@Florent V. : C'est effectivement une question de méthodo' personnelle issue (pour ma part) d'une méthodologie d'équipe discutée et approuvée ;)

Diviser les styles en différents modules (typo, couleurs, etc…) relève bien du suicide. C'est simplement pas logique, ça "casse" la vision d'ensemble de la chose.
Sauf peut-être pour un portail où chaque section aurait ses propres couleurs et variantes, auquel cas avoir plusieurs feuilles CSS de "couleur" simplifierait la maintenance (si c'est un gros site, et ça peut arriver). J'ai rencontré ce cas quelques fois déjà.
Et encore, en organisant une feuille unique (les commentaires, ça sert), on doit pouvoir s'en sortir assez bien.

Ninik a dit le 2010-04-23 18:18:10

J'ai découvert un site l'autre jour : http://rafael.adm.br/css_browser_selector/
Est-ce que c'est bien d'utiliser un script pour arranger les certains bugs dans les navigateurs? Je l'ai essayé et je trouve que ça fonctionne pas mal.

Ninik a dit le 2010-04-23 18:24:44

cahnory a dit le 2010-04-24 10:58:07

@Ninik : Pour arranger certains bugs je ne trouve pas que ça soit une bonne solution. Là le problème serait un souci d'affichage sous ie (par exemple), tu le corrige via un js.
Très bien maintenant comment tu fais pour l'utilisateur ie sans js ?
Soit tu le laisse tomber mais dans ce cas pourquoi s'embêter avec l'utilisateur ie,
soit tu fais un correctif pour ceux qui auraient ie sans js mais du coup, l'utilisation du script devient inutile.
Pour moi tout doit être fonctionnel sans javascript à l'aide d'html et css seulement. Si quelque chose est impossible pour un navigateur alors je trouve une solution alternative plus simple, offrant peut être moins de chose visuellement mais qui n'a pas l'air buggé. Ensuite seulement, au besoin et surtout selon la demande, je me servirait de js pour tenter de gommer la différence.

Quoi que js puisse apporter à ta page il faut que celle-ci s'en sorte sans lui honorablement.

Au passage j'ai encore un peu modifié l'utilisation faite ici, une démo sur cette page :
http://www.cahnory.fr/css/browser-check.html
Un ptit retour ne serait pas de refus ;)

Ninik a dit le 2010-04-24 15:10:18

@cahnory : Merci pour votre réponse. Je vais y remédier prochainement dans mes prochains sites Internet.