Plan de site — Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog

- Lire le billet précédent - Lire le billet suivant -

CSS, sensibilité à la casse, doctype switching et lecture des specs

Par Laurent Denis, le 17 novembre 2004.

Comme je n'ai pas pu m'empêcher de jeter un oeil dans mon Feed Deemon ce matin, un billet de Dive the Web m'a fait sursauter :

Le language CSS est sensible à la casse. Du moins, c'est ce que je croyais.

Et bien, me voici toute ébaubie, je découvre qu'il ne l'est pas. J'ai défini une class smallTxt et j'ai fait une faute de frappe en oubliant de capitaliser le t... et ça marche. Je m'étonne, je crois d'abord faire face à un bug du navigateur. Je teste dans FireFox 1.0 et IE6. J'ai ensuite essayé le coup avec SMALLTxt et SmALLtxt... Même résultat: le style est toujours appliqué.

Je vérifie donc sur quelques sites et j'ai la confirmation que je cherchais: le CSS n'est pas sensible à la casse.

CSS est insensible à la casse... pour ce qui le concerne

En fait, selon le principe d'orthogonalité, CSS2.0 est insensible à la casse pour ce qui dépend d'elle-même... mais laisse les autres normes concernées décider pour le reste :

Toutes les feuilles de style CSS sont insensibles à la casse, sauf leurs parties qui ne sont pas régies par CSS. Ainsi celles qui sont sensibles à la casse, comme les valeurs des attributs de HTML "id" et "class", les noms des polices et les URIs qui sont hors du cadre de cette spécification. Noter en particulier que les noms des éléments ne sont pas dépendants de la casse pour HTML, alors qu'en XML ils le sont.

La sensibilité à la casse des noms de classes est donc régit non par CSS2.0, mais par HTML4.01, qui est on ne peut plus explicite à ce sujet :

class = liste-de-valeurs-cdata [CS]

Mais si... c'est explicite : suivez le lien sur la mention [CS] :

Chaque définition d'attribut contient des informations concernant la sensibilité à la casse pour les valeurs qu'il admet. L'information de casse est présentée selon les clés suivantes :

CS
La valeur est sensible à la casse (i.e., l'agent utilisateur interprète « a » et « A » différemment).

De fait, le simple code suivant atteste du respect de la norme en la matière par les navigateurs :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html lang="fr">
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
      <meta http-equiv="Content-style-type" content="text/css">
      <title>Test</title>
      <style type="text/css">
      <!-- 
      .smallTxt {
      color: red;
      }
      .smalltxt {
      color: green;
      }
      .SMALLtxt {
      color: blue;
      }
       -->
      </style>
   </head>
   <body>
      <p class="smallTxt">Ceci devrait être rouge</p>
      <p class="smalltxt">Ceci devrait être vert</p>
      <p class="SMALLtxt">Ceci devrait être bleu</p>
   </body>
</html>

Et pourtant, le billet cité ci-dessus est bien exact, dans les conditions où son auteur a réalisé ses tests... Alors ?

Réflexe : lire les specs... mais penser à leur portée limitée

L'intéressant ici, je crois, c'est le comportement du développeur :

  • Il a acquis une habitude (se soucier de la casse dans ses CSS) sans trop se souvenir du pourquoi, mais tout à fait cohérente et rigoureuse : respecter des règles de casse strictes ;
  • Un jour, il commet une erreur, et obtient un comportement inattendu dans un navigateur.
  • Pour comprendre de quoi il retourne, il teste dans plusieurs navigateurs.

A aucun moment, on ne voit ce qui devrait être un réflexe immédiat, AMHA : consulter la spec qui est précisément là pour définir le comportement normalisé des navigateurs, ce que les auteurs peuvent en attendre, et ce dont ils doivent donc tenir compte avant tout. S'il y avait une éventuelle erreur d'implémentation, elle devait être cherchée à partir de là. En l'occurence, il n'y en a pas.

Mais ne jetons pas la pierre à notre développeur, car le problème reste entier : si la spec dit blanc, et que mes navigateurs disent unanimement noir avec ma page de test... je suis perdu !

Sauf que... la page de test de Dive the Web faisait intervenir un autre paramètre, qui faisait que le problème échappait totalement aux questions de comportement normalisé : supprimez en effet la DTD de l'exemple de code ci-dessus, et vous verrez qu'en effet, dans ce cas, tous nos navigateurs deviennent soudain indifférents à la casse des noms de classe.

Que s'est-il passé ? En supprimant cette DTD, nous avons fait basculer nos navigateurs dans un mode d'interprétation non standard, et donc a priori imprévisible. Dans ce mode Quirks, Opera, Firefox, Mozilla, IE6, etc. ne respectent plus la règle HTML de sensibilité à la casse des noms de classe. Chacun, à vrai dire, déclare de ce fait adopter le comportement de son choix, en toute imprévisibilité. De manière accidentelle, notre développeur avait sans doute basculé ses pages de test dans ce mode.

Conclusion

  • Ne testez pas en aveugle : Lisez la doc (La rédaction de cette spécification tient compte de deux types de lecteurs : les auteurs de feuilles de style et les personnes chargées de leur implémentation. Nous espérons que la spécification fournira aux auteurs les moyens d'écrire des documents efficaces, attractifs et accessibles, sans pour autant les noyer dans le détail de la mise en œuvre des CSS., À propos de la spécification CSS2 - Lire la spécification) ;
  • Le doctype switching est une mauvaise réponse obligée à une mauvaise question : "comment s'affranchir des normes de manière rigoureuse lorsque celles-ci ne sont pas respectées." Il y peu de chances en effet d'y trouver une bonne réponse.

Trackbacks

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Moz, le 17 novembre 2004

"Le doctype switching est une mauvaise réponse obligée à une mauvaise question" : je croyais pourtant t'avoir entendu dire un jour que le modèle de boîte quirks était plus logique que le modèle standards ?

Monique, le 17 novembre 2004

Bonjour,

Hum... De(e)mon = tentation = ... smiley clin d'oeil

Je viens encore d'apprendre quelque chose !
En fait mon aversion pour les majuscules en dehors de leur usage classique (début de phrase ou de nom propre, sigle), un vestige indélébile de l'apprentissage de la lecture par la méthode globale, m'a toujours préservée de ce type d'erreur.

Amicalement,
Monique

Laurent Denis, le 19 novembre 2004

Dans un ordre d'idée similaire, et pour mémoire, une superbe typo dans la spécification HTML4.01 : [...] une correspondance sensible à la casse est alors recherchée avec le jeu des types de média définis précédemment..

Il faut lire en fait une correspondance insensible à la casse, conformément à la définition de l'attribut media, au lien présent dans le texte litigieux, et à la cohérence nécessaire avec les types de médias définis par ailleurs dans CSS2. Bref, les descripteurs de medias (screen, print, etc.) sont insensibles à la casse.

Igor, le 08 janvier 2005

Bonsoir Laurent,
Je m'appretaîs à répondre à un message sur Alsacréations sur la sensibilité à la casse de font color="XXccXX" par rapport à font color="xxccxx", plutôt sur un ton badin, du genre "depuis que je j'ai découvert css, la casse des font color dans html m'importe peu" dans l'idée de citer ce billet sur la casse que j'ai lu trop brièvement lors de sa parution.
Et je m'aperçois en le relisant avant de poster qu'il y a un terme et même un principe que je ne comprend pas du tout: *orthogonalité*.
Pourrais-tu m'éclairer sur cette formulation, que mon Petit Robert ne défriche pas suffisament pour moi.

Laurent Denis, le 09 janvier 2005

La récente recommandation Architecture du World Wide Web définit le principe d'orthogonalité :

L'identification, l'interaction et la représentation sont des concepts orthogonaux, ce qui signifie que les technologies utilisées pour l'identification, l'interaction et la représentation peuvent évoluer indépendamment les unes des autres. Par exemple :

  • Les ressources sont identifiées par des URIs. les URI peuvent être publiées sans construire aucune représentation de la ressource, et sans déterminer qu'une représentation queconque en est disponible.
  • Une syntaxe générique d'URI autorise les agents utilisateurs à fonctionner dans de nombreux cas sans connaître les spécificités des schemes d'URI.
  • Dans de nombreux cas, on peut modifier la représentation d'une ressource sans briser les références à celle-ci (par exemple, en recourant à la négociation de contenu).

Quand deux spécifications sont orthogonales, on peut changer l'une sans changer l'autre, même si l'une dépend de l'autre. Par exemple, bien que la spécification HTTP dépende de la spécification URI, les deux peuvent évoluer indépendamment. Cette orthogonalité accroît la flexibilité et la solidité du Web. Par exemple, on peut se référer à une image par une URI sans rien connaître du format choisi pour représenter cette image. Ceci a facilité l'introduction de nouveaux formats d'images comme PNG et SVG sans rompre les références existantes à ces ressources d'images.

Dans notre cas, par exemple : les noms d'éléments sont insensibles à la casse en HTML, mais pas en XHTML. Si CSS avait régit ce point au lieu d'en laisser le soin aux normes concernées, le passage à XHTML aurait été problématique...

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.