Blog - Britoweb - CSS

N'oublions pas les sélecteurs CSS 2.1

Victor Brito — Fri, 05 Feb 2010 09:08:00 +0100

Tel est le message que souhaite faire passer le site 456 Berea Street dans un billet publié hier et intitulé Forgotten CSS selectors.

Ce billet présente brièvement quelques sélecteurs avancés de la spécification CSS 2.1 qui ont été oubliés jusqu'à présent, à cause qu'Internet Explorer 6 ne les prend pas du tout en charge ou très partiellement, mais auxquels on peut songer, vu qu'IE 6 a atteint des parts de marché suffisamment basses pour que la prise en compte de cette version de navigateur ne soit plus synonyme de « rendu visuel au pixel près ».

Les sélecteurs évoqués dans le billet de 456 Berea Street sont les suivants :

le sélecteur d'élément enfant (E > F),
le sélecteur d'élément frère adjacent (E + F),
le sélecteur d'attribut (E[attribut] et E[attribut=valeur], notamment),
la pseudo-classe :first-child,
la pseudo-classe :hover applicable à n'importe quel élément et non seulement à l'élément a,
la pseudo-classe :focus,
le sélecteur de classes multiples (E.classe1.classe2).

L'enjeu de l'utilisation des sélecteurs avancés de CSS est résumé ainsi :

What these selectors offer us is cleaner HTML, since we can drop a lot of class names, and in some cases JavaScript, that were only necessary to achieve visual equivalence in IE 6. I am not saying that you should “drop support” for IE 6, just that it’s ok for some things to not look perfect in a Web browser that is eight and a half years old. Besides, Do websites need to look exactly the same in every browser?

En français :

Ce que ces sélecteurs nous offrent est du HTML plus propre, puisque nous pouvons retirer beaucoup de noms de classe, et de JavaScript dans certains cas, qui n'étaient nécessaires que pour parvenir à un visuel équivalent sous IE 6. Je ne dis pas que vous devriez « laisser tomber la prise en charge » d'IE 6, mais seulement de ce qui est bon pour que certaines choses n'aient pas l'air parfaites sous un navigateur Web qui a huit ans et demi. D'ailleurs, Les sites Web ont-ils besoin d'être exactement pareils sous chaque navigateur ?

La réponse est non. Du moins, à partir du moment où l'on se soucie de dégradation élégante pour les navigateurs obsolètes (ou d'amélioration progressive pour les navigateurs les plus avancés en matière de prise en compte des standards et de leur respect).

Du pixel aux unités relatives ou de l'art de dompter les grilles fluides

Victor Brito — Tue, 03 Mar 2009 19:57:00 +0100

Puisque le pixel n'est pas une unité recommandée pour créer des feuilles de styles soucieuses de permettre l'agrandissement du texte, on doit se contenter des unités relatives restantes, comme l'em ou le pourcentage. Mais, il reste le problème de reproduire fidèlement une maquette réalisée sous Photoshop (ou tout autre logiciel de graphisme), où tout est figé en pixels.

Heureusement, il existe des astuces permettant d'obtenir un design fluide et j'ai déjà eu l'occasion d'en rapporter dans un précédent billet. A List Apart vient de publier un article qui présente une astuce qui va plus loin que le traitement de la taille du texte.

Partons du bout de code HTML suivant :

<div id="page">
  <h1>Some header</h1>
  <p>Some text</p>
</div>

D'abord, fixons la taille de police globale à 100 % de la taille par défaut de la police utilisée.

body {
  font-size: 100%;
}

Nous avons une maquette qui nous présente le texte de l'élément h1 comme ayant une taille de 24 pixels.

Pour traduire la taille en pixels vers la taille équivalente en ems, nous emploierons l'équation suivante : taille ciblée ÷ taille du contexte = taille résultante. La taille ciblée est celle dont on souhaite obtenir l'équivalent en ems, la taille du contexte est la taille de texte utilisée par l'élément parent de celui contenant le texte ciblé (ou, à défaut de taille déclarée, par l'élément ancêtre le plus proche) et la taille résultante est le résultat obtenu par la division de la première par la deuxième.

Lorsque la taille du contexte est égale à 100 %, elle correspond à la taille par défaut de la police, telle que fixée par le navigateur, soit la plupart du temps 16 pixels. À partir de cette donnée précieuse, nous pouvons calculer la taille en ems de l'élément h1 comme suit : 24 ÷ 16 = 1,5 ; l'élément h1 aura donc une taille de texte de 1,5 ems.

h1 {
  font-size: 1.5em;
}

Notre maquette indique que le texte du paragraphe p a une taille de 14 pixels. Pour en obtenir l'équivalent en pixels : 14 ÷ 16 = 0,875, soit 0,875 em.

p {
  font-size: 0.875em;
}

Ce qui est possible pour la taille de texte l'est également pour la dimension des blocs. En effet, une maquette rigide ne contenant que des blocs définis en pixels peut produire un design fluide.

Reprenons notre maquette, qui nous dit que l'ensemble du contenu (représenté par l'élément div dont l'identifiant est "page") tient dans une largeur de 988 pixels et que l'élément h1 occupe une largeur de 700 pixels, avec une marge de 144 pixels à sa gauche.

Pour calculer l'équivalent en ems de la largeur du div, nous nous basons sur la taille par défaut de la police, soit les fameux 16 pixels, ce qui donne 988 ÷ 16 = 61,75, soit 61,75 ems.

#page {
  width: 61.75em;
}

Pour calculer la largeur du bloc h1, nous devons partir de celle du plus proche ancêtre déclaré, à savoir l'élément div en question. Ainsi, le calcul est le suivant : 700 ÷ 988 = 0,7085 (résultat arrondi). Le résultat peut être exploité sous forme de pourcentage, puisque l'élément h1 occupe non seulement 700 pixels de la page hors tout, mais surtout 700 des 988 pixels du div, soit 70,85 %. Pour la marge de 144 pixels, même motif, même punition : 144 ÷ 988 = 0,14575 (résultat arrondi). Ce qui, dans la feuille de style, s'écrit :

h1 {
  width: 70.85%;
  margin-left: 14.575%;
}

Ainsi, la page Web intégrée sera fluide non seulement pour la taille de texte (et la nécessité, parfois, de l'agrandir), mais aussi pour les taille et résolution d'écran disponibles. Bref, ce n'est pas sorcier de faire entrer un carré dans un cercle.

Agrandissement de texte : le pixel n'est toujours pas conseillé

Victor Brito — Thu, 26 Feb 2009 22:01:00 +0100

Pour des raisons liées à l'accessibilité, la taille de police utilisée pour le texte contenu dans une page Web doit être exprimée dans une unité relative, surtout quand l'affichage du texte en question est destiné à un écran (que ce soit un écran d'ordinateur ou un écran de n'importe quel support mobile pouvant tenir dans une seule main) : en effet, une unité relative permet l'agrandissement du texte pour un meilleur confort de lecture.

La spécification CSS 2.1 du W3C inclut, parmi les unités relatives, le pixel. Toutefois, il n'est toujours pas conseillé d'utiliser le pixel pour définir une taille de texte.

En effet, comme le rapporte le site 456 Berea Street, Internet Explorer 8 refuse encore d'agrandir un texte dont la taille est fixée en pixels, pas même dans son mode de rendu « super » standard.

Par conséquent, les pourcentages, cadratins et autres hauteurs d'x continueront toujours d'avoir l'exclusive préférence.

CSS 2 - Pratique du design Web de Raphaël Goetter, troisième édition : note de lecture

Victor Brito — Sun, 11 Jan 2009 02:10:00 +0100

Les éditions Eyrolles viennent de publier la troisième édition de CSS 2 - Pratique du design Web, de Raphaël Goetter.

S'il y a un seul ouvrage qui m'ait marqué dans mon parcours dans le Web, c'est bien celui de Raphaël Goetter : en effet, la lecture de la première édition, en 2006, m'a incité à plus de rigueur dans mon code, plus particulièrement dans le respect du balisage sémantique, tout en me faisant prendre conscience des problèmes de compatibilité entre navigateurs.

Cette troisième édition, tout en tenant compte des nouveautés de Firefox 3 et, surtout, d'Internet Explorer 8, reste fidèle à l'esprit des deux précédentes éditions. En effet, le livre commence par un exposé sur les standards du Web, tout en soulignant l'importance de l'accessibilité du Web, de la séparation entre la structure d'un document Web et sa présentation et de la sémantique de chaque balise HTML. Ensuite, après plusieurs chapitres théoriques sur l'essentiel des CSS, le livre aborde des cas concrets et très courants d'application de CSS, comme le centrage d'un élément ou l'habillage d'un menu de navigation. Enfin, le livre présente un exemple d'application de la matière abordée à un projet de site Web de qualité professionnelle, tout en offrant une méthodologie simple permettant aux concepteurs de sites Web plus ou moins maladroits de coder avec rigueur et de résoudre les problèmes d'affichage (et ce sans même recourir à des outils comme l'extension Firebug de Firefox).

En somme, c'est un livre indispensable pour connaître l'essentiel des CSS, tout en ayant conscience de certaines bonnes pratiques de conception de sites Web.

Feuilles de styles, médias CSS et navigateurs mobiles : une astuce pour garantir compatibilité et confort d'utilisation

Victor Brito — Tue, 06 Jan 2009 20:17:00 +0100

Que l'on déplore ou non, le Web sur les mobiles est de moins en moins négligeable, d'autant moins qu'il peut compter sur le succès, entre autres, de l'iPhone. Or, consulter un site Web depuis un mobile peut devenir un casse-tête quand le site consulté utilise des feuilles de style inadaptées aux mobiles ou que le navigateur mobile utilisé implémente mal les différents médias CSS ou n'en reconnaît pas certains.

En effet, une feuille de style destinée à un écran d'ordinateur (utilisant donc le média screen) peut être remplie de règles CSS dont l'objectif est d'afficher tout ou partie du contenu en colonnes (avec les propriétés display et float, notamment), en tenant compte d'une taille d'écran au moins égale à 800 ou à 1024 pixels de large. Or, sur un mobile, une telle feuille de style induira soit la présence d'une barre de défilement horizontale soit le recours à une fonctionnalité permettant de zoomer le contenu auquel on veut accéder, la page Web entière s'adaptant dans un premier temps à la largeur d'écran disponible, réduisant la taille des polices à un niveau tel qu'un problème d'accessibilité se pose.

Heureusement, en HTML 4 et en XHTML, il est possible de préciser le(s) média(s) concerné(s) par la feuille de style lorsqu'on l'appelle au moyen de l'élément link, grâce à l'attribut media. Il en est de même en CSS 2, grâce à la règle @media, d'une part, et à la possibilité de préciser le(s) média(s) concerné(s) par la feuille de style appelée au moyen de la règle @import. Ainsi, on peut créer plusieurs feuilles de styles, dont une ciblant les mobiles en utilisant le média handheld :

<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/screen.css" media="screen,handheld" />
<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/handheld.css" media="handheld" />

@import "screen.css" screen;
@import "handheld.css" handheld;

@media screen {
  /* Règles CSS pour les écrans d'ordinateur */
}
@media handheld {
  /* Règles CSS pour les mobiles */
}

Seulement voilà : si certains navigateurs mobiles implémentent le média handheld, d'autres, en revanche, l'ignorent et, qui plus est, iront même jusqu'à ne lire que les feuilles de style ciblant le media screen ! Et je ne me hasarde pas à parler des media queries, un module de CSS 3 qui permettra de cibler plus finement les médias (par exemple, ne cibler que les écrans dont la taille ne dépasse pas 480 pixels de largeur, ce qui donne le code suivant pour l'attribut media et les règles @media et @import : only screen and (max-device-width:480px)) ; mais, ce genre de requête n'est, pour l'instant, implémenté que par Opera et Safari.

Malgré tous ces points délicats, il est possible de fournir à l'ensemble des navigateurs mobiles une feuille de style adaptée au support mobile. A List Apart vient de publier un article indiquant une astuce garantissant à la fois un confort d'utilisation du mobile pour consulter un site et la compatibilité entre navigateurs mobiles.

L'astuce part du principe de deux feuilles de style distinctes, l'une (ecran.css) pour les écrans d'ordinateurs, l'autre (correctifs-mobile.css) pour les mobiles (dont le rôle est d'annuler les règles énoncées par ecran.css qui sont inadaptées aux écrans de mobile). Ces deux feuilles sont appelées par une troisième (noyau.css), qui contient le code suivant :

@import "ecran.css";
@import "correctifs-mobile.css" handheld;
@import "correctifs-mobile.css" only screen and (max-device-width:480px);

Une quatrième feuille de style (mobile.css) apporte des styles supplémentaires pour les mobiles.

Les différentes feuilles de style sont appelées comme suit :

<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/noyau.css" media="screen" />
<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/mobile.css" media="handheld, only screen and (max-device-width:480px)" />

Ainsi, les navigateurs mobiles ne tenant compte que du média handheld ne chargeront que la feuille de style mobile.css ; ceux qui tiennent compte à la fois des médias screen et handheld chargeront toutes les feuilles de style, de même pour ceux qui ne tiennent compte que du média screen tout en implémentant le module media queries de CSS 3. Quant à ceux qui ignorent ce module de CSS 3 et qui ne connaissent que le média screen, ils ne chargeront que la feuille de style ecran.css.

Connaissez-vous les JSSS ?

Victor Brito — Mon, 23 Jun 2008 22:12:00 +0200

En lisant un entretien accordé par Daniel Glazman à Openweb sur les CSS, je suis tombé sur le sigle suivant : JSSS.

J'ai ainsi appris qu'il y a une décennie (ce qui, à l'échelle du Web, veut dire dans l'Antiquité), Netscape mit au point les feuilles de style JavaScript (en anglais JavaScript StyleSheets), qui concurrençaient les CSS.

Si elles pouvaient être puissantes pour des calculs dynamiques hautement complexes ; en revanche, elles se rélévaient bien pauvres à côté des CSS, en ne supportant que le sélecteur d'élément simple. De plus, la syntaxe, issue de JavaScript, était plus verbeuse et sensible à la casse : là où en CSS on écrit h1 { font-size: 20pt; }, en JSSS on écrivait document.tags.H1.fontSize = "20pt";.

Bien que Netscape eût soumis les JSSS au W3C, elles ne furent jamais acceptées comme standard. Qui pis est, elles furent d'autant plus boudées par le marché que le principal concurrent de Netscape, Internet Explorer, n'hésita pas à adopter les CSS comme langage de feuille de style. Seul Netscape 4, sorti en 1997, supportait les JSSS ; mais, très vite, la société Netscape laissa tomber la promotion de ce langage propriétaire pour s'intéresser aux CSS et cessa tout support des JSSS à la sortie de Netscape 6, en 2000.

Pour plus de détails, un article de Wikipédia lui est consacré, qui m'a servi de source pour les propos tenus dans ce billet.

Taille des polices : une raison de ne pas se caler au pixel près ?

Victor Brito — Wed, 16 Apr 2008 15:53:00 +0200

Pour d'évidentes raisons d'accessibilité, l'utilisation de tailles fixes pour les polices est à éviter. Qui plus est, même s'il est rangé parmi les tailles relatives, le pixel n'est pas recommandable, parce qu'Internet Explorer refuse d'agrandir les polices dont la taille est exprimée en pixels (sauf à cocher « Ignorer les tailles de polices spécifiées sur les pages Web » dans les options d'accessibilité, ce qui oblige à recourir au zoom, qui, en attendant la version 8, ne vaut pas celui d'Opera). Et ce n'est pas tout au chapitre du casse-tête de la compatibilité des tailles de polices entre les navigateurs ; bref, de quoi vous donner envie d'étrangler le directeur général ou de massacrer votre designer .

Cela dit, il existe des moyens permettant d'utiliser les tailles relatives (notamment le pourcentage et l'em) de manière à produire une taille de police équivalente à celle exprimée en pixels.

Ces moyens sont décrits dans un article d'Aurélien Levy sur Openweb, qui privilégie le pourcentage. Pour l'em, on consultera le billet de Laurent Denis sur la définition de la taille de texte en ems.

Toutefois, les méthodes proposées ne sont pas exemptes d'approximations, outre qu'il faut tenir compte que l'utilisateur peut configurer le navigateur de manière à utiliser une taille de polices par défaut autre que 16 pixels, voire ajouter une feuille de style utilisateur susceptible d'écraser les règles CSS de la feuille de style auteur (par exemple, avec un body { font-size: 150% !important; }), sans compter l'héritage de la taille quand on utilise les pourcentages et les ems.

Les CSS et les commentaires conditionnels, ou l'art d'user de ces derniers avec une certaine modération

Victor Brito — Fri, 11 Apr 2008 21:49:00 +0200

Le site Les intégristes a récemment publié un billet intitulé Cibler Internet Explorer dans une CSS ? Oui, et sans hack.

Un tel intitulé montre de bonnes intentions en matière de bonne pratique de codage CSS dans le cadre de la prise en compte des lacunes d'Internet Explorer.

Toutefois, il est regrettable que la méthode privilégiée ne soit pas celle de l'ajout de feuilles de style ciblant Internet Explorer ou l'une de ses versions. En effet, le billet préconise d'écrire dans le code HTML des balises div entourées de commentaires conditionnels et comportant un attribut id dont la valeur permet de cibler telle ou telle version d'IE, IE toutes versions confondues ou les autres navigateurs. Autrement dit, on aurait un code HTML ressemblant, par exemple, à cela (code inspiré de celui proposé par le billet) :

<body>
<!--[if IE 6]><div id="IE6"><![endif]-->
<!--[if IE 7]><div id="IE7"><![endif]-->
<!--[if gte IE 8]><div id="IE8"><![endif]-->
<!--[if !IE]><--><div id="NOTIE"><!--><![endif]-->
<!-- Contenu de la page -->
</div>
</body>

Ce qui aurait comme avantage apparent de n'utiliser qu'une seule feuille de style contenant des règles comme celles-ci (code inspiré de celui proposé par le billet) :

.mon_element {
  margin-left: 2px;
}
#IE8 .mon_element {
  margin-left: 3px;
}
#IE6 .mon_element {
  margin-left: 4px;
}
#IE7 .mon_element {
  margin-left: 5px;
}
#NOTIE .mon_element {
  margin-left: 6px;
}

Or, on retombe dans l'inconvénient de la méthode des hacks CSS (soit dit en passant, j'estime que le sélecteur d'élément enfant, quoi qu'en dise le billet des Intégristes, n'en est pas un), qui consiste à « polluer » une feuille de style qui, avant tout, ne devrait contenir que les règles CSS idéales pour le style que l'on cherche à appliquer et appliquées sans broncher par les navigateurs respectueux des standards. Comme le dit si bien Vincent Voyer dans son commentaire : ça alourdit inutilement les CSS des autres navigateurs pour rien. Et eux ils ont rien demandé ! . En outre, ça alourdit le code HTML.

Bref, il vaut mieux utiliser les commentaires conditionnels pour appeler des feuilles de style supplémentaires ou pour afficher (ou masquer) du contenu ciblant ou excluant IE (ou telle ou telle version d'IE).

Les CSS mises à nu

Victor Brito — Wed, 09 Apr 2008 00:00:00 +0200

Où est donc passé l'habillage du site ? Le site se serait-il mis à poil ?

En quelque sorte, oui. Aujourd'hui, c'est la troisième édition du CSS Naked Day.

Il s'agit d'une initiative, lancée par Dustin Diaz, qui consiste à dépouiller, pour une journée, un site Web de ses feuilles de style, afin de promouvoir les standards du Web, et plus particulièrement le bon usage du (X)HTML, le balisage sémantique et la bonne hiérarchisation de la structure d'une page Web. Bref, il s'agit de montrer qu'une bonne structure (X)HTML se moque de la mise en forme et de la présentation et reste parfaitement consultable, voire accessible, puisqu'elle va à l'essentiel : le contenu et la nature de ce contenu.

Sur ce, si votre site Web est une charmante jeune femme en lingerie, qu'elle ose ôter son <body> et se mette à poil !

CSS, PNG : ne pas rester prisonnier d'Internet Explorer 6

Victor Brito — Mon, 24 Mar 2008 23:19:00 +0100

La spécification CSS 2.1 offre des possibilités d'appliquer un style à un document Web si riches (et je ne parle pas de ce que nous réserve CSS 3…) qu'elle paraît trop en avance pour les navigateurs « mauvais élèves », comme Internet Explorer 6. Même si ce dernier est encore, hélas ! répandu, ce n'est pas une raison de ne pas utiliser toute la puissance des CSS.

Prenons l'exemple de ce bout de code HTML :

<div id="exemple">
  <h1>Titre</h1>
  <ul>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section1.html">Section 1</a></li>
    <li>
      <a href="http://blog.britoweb.net/post/2008/03/24/section2.html">Section 2</a>
      <ul>
        <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-1.html">Section 2.1</a></li>
        <li>
          <a href="http://blog.britoweb.net/post/2008/03/24/section2-2.html">Section 2.2</a>
          <ul>
            <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-2-1.html">Section 2.2.1</a></li>
            <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-2-2.html">Section 2.2.2</a></li>
          </ul>
        </li>
        <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-3.html">Section 2.3</a></li>
      </ul>
    </li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section3.html">Section 3</a></li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section4.html">Section 4</a></li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section5.html">Section 5</a></li>
  </ul>
</div>

Nous voulons que chaque élément de liste ait une bordure en haut, sauf le premier de chaque liste, et que les listes imbriquées aient une couleur d'arrière-plan différente de celle de la liste qui la contient. Pour corser les choses, le deuxième élément de chaque liste doit avoir son texte en gras.

Il est possible de réaliser cette volonté sans qu'on touche au code HTML, en codant, par exemple, le code CSS suivant :

/* Texte en gras pour le deuxième élément li de chaque liste */
#exemple li:first-child + li {
  font-weight: bold;
}
/* Si ce deuxième élément contient une liste,
   seul le deuxième élément de cette dernière est en gras
   (le reste est en graisse normale) */
#exemple li > ul {
  font-weight: normal;
}
/* Bordure */
#exemple li {
  border-top: 1px solid black;
}
/* Pas de bordure pour chaque premier élément li */
#exemple li:first-child {
  border-top: none;
}
/* Couleurs d'arrière-plan différentes pour les listes selon leur niveau */
#exemple > ul {
  background-color: yellow;
}
#exemple > ul > li > ul {
  background-color: orange;
}
#exemple > ul > li > ul > li > ul {
  background-color: red;
}

Pour résumer, nous recourons aux sélecteurs d'élément enfant (>) et adjacent (+), ainsi qu'à une pseudo-classe (:first-child), pour traiter les différents niveaux de liste. Et ça marche sous Firefox 2, Opera 9 et Safari 3, ainsi que sous Internet Explorer 7.

Ça ne marche pas sous IE 6, me direz-vous. C'est un fait, certes ; mais, cela ne doit pas être une excuse pour mépriser les sélecteurs évoqués ci-dessus, sous prétexte que cela compliquerait la maintenance pour les intégrateurs ou que tout ce qui en CSS n'est pas compris par IE 6 est à ignorer parce que les utilisateurs d'IE 6 sont la cible principale.

Pour ma part, j'estime que la maintenance est plus compliquée lorsqu'on doit ajouter des attributs class (ou quelques id lorsque le contexte du code HTML le permet), au risque de friser la classite aiguë (comme dirait Raphaël Goetter), alors qu'en utilisant toute la puissance des CSS, notamment grâce à ses sélecteurs, on garde la faculté d'alléger le code HTML (et donc de réaliser des économies de bande passante, même s'il ne s'agit que de quelques kilo-octets ).

Cela ne veut pas dire, pour autant, qu'il faille interdire l'utilisation des classes en CSS. Si l'on souhaite ou doit tenir compte d'IE 6, on peut s'en servir dans notre exemple (pour distinguer les éléments li devant être mis en gras). Mais, la classe ajoutée ne servira qu'au correctif pour IE 6 si l'on veut y reproduire le style recherché. Auquel cas il faudra créer une feuille de style à part, qui ne servira que pour IE 6 (et les versions antérieures à la 6, si l'on veut) et qu'on appellera par un commentaire conditionnel. C'est une méthode à la fois plus pérenne et plus propre, en ce sens qu'une fois qu'IE 6 aura disparu du marché des navigateurs (et plus vite il disparaîtra, mieux ce sera ), on pourra non seulement ôter les classes du code HTML, mais surtout supprimer la feuille de style pour IE 6, sans qu'on ait besoin de maintenir la feuille de style principale, contrairement à la méthode des hacks CSS (ou de l'utilisation d'une seule feuille de style, qui mélange règles CSS standards et corrections pour IE), qui pollue une feuille de style qui, après tout, ne doit contenir que des règles CSS conçues pour être appliquées sans broncher par les navigateurs, à commencer par ceux qui respectent les standards.

On peut en dire tout autant concernant les images en PNG contenant une couche de transparence. Sous prétexte qu'IE 6 ne gère pas nativement la transparence du format PNG, beaucoup en viennent à brider la créativité en matière de design Web, en se contentant du format GIF pour utiliser de la transparence, mais sans pouvoir utiliser de couche Alpha ni aller au-delà de 256 couleurs (ce qui condamne l'utilisation de dégradés de couleurs). Si l'on souhaite ou doit tenir compte d'IE 6, même motif, même punition que pour les CSS : un commentaire conditionnel, où l'on remplacera le PNG qui ne passe pas par un GIF ou, mieux, par un JPEG équivalent, l'idéal étant que l'image en question soit une image générée en CSS (même si l'on peut utiliser les commentaires conditionnels pour afficher ou masquer un contenu HTML à Internet Explorer).

Et je ne vais pas me hasarder à parler du DOM et de la manière standard de parcourir l'arborescence d'un document HTML, où l'on peut jongler à merveille entre les liens de parenté qu'entretiennent les élements entre eux, voire boucler entre éléments frères.

Bref, tout cela pour dire que, malheureusement, même dans le milieu des agences Web, on continue encore à coder « à la cochonne », en n'osant pas exploiter à fond toutes les possibilités des CSS parce qu'on reste prisonnier d'un navigateur et d'une version qui ne respectent pas les standards du Web : on crée des classes pour sélectionner le premier élément enfant, on pollue la feuille de style principale de hacks et de propriétés CSS propriétaires (comme filter ou zoom) qui l'invalident dès qu'elle passe au validateur CSS du W3C… Même s'il faut tenir compte des problèmes de compatibilité entre les navigateurs et entre les versions d'un même navigateur, il ne faut pas rester prisonnier de ce cancre qu'est Internet Explorer 6, d'autant moins que la version 7 fait son bonhomme de chemin, que la version 8 pointe déjà son nez et qu'un code pérenne doit se tourner vers cet avenir, de plus en plus présent, qu'est la généralisation des standards du Web.

Il est important d'avancer en CSS ; sinon, nous en serions à coder en mode Quirks, ce qui n'arrangerait pas du tout le W3C, dont le travail essentiel est de faire en sorte que, sur le Web, tout le monde parle les mêmes langages côté client, afin de faciliter la tâche des concepteurs de sites.