Blog - Britoweb - 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.