Le blog d'Aozeo

La réalité est cependant bien moins radieuse. Si les CSS représentent bien une innovation majeure (et déjà assez âgée, la première spécification datant d'il y a un peu moins de 10 ans), ils n'en sont pas moins exempts de défauts, différences d'interprétation dans les différents navigateurs mises à part.
L'erreur fondamentale des CSS est en fait leur objectif premier : réussir à équiper les pages HTML de styles à la manière des traitements de texte. Erreur fondamentale car cette optique ne convient absolument pas à la publication sur Internet - encore largement balbutiante en 1994 lorsque les germes de la technologie firent surface, c'est vrai. Si dans un traitement de texte vous choisissez au fur et à mesure de la rédaction le style à employer (ou même si vous tapez au kilomètre puis revenez en arrière), vous faîtes le travail de mise en page. Ors si ce fonctionnement peut s'avérer productif lors de la conception de sites fixes et simples, il est en fait complètement inadapté à la publication "à la chaîne". Si votre modèle de présentation impose le second paragraphe des articles en jaune et le troisième en rouge, ce n'est pas à vous de définir ces couleurs à chaque fois que vous publierez une prose, mais au site de s'adapter... ce qui n'était absolument pas prévu. Concrètement, vous ne pouvez pas changer le style d'un Xième paragraphe à l'aide des CSS ^[1]. Il vous faudra soit attribuer des classes au second et au troisième paragraphe, soit contourner le problème en utilisant une solution non comprise par Internet Explorer^[2]. Impossible de définir des modèles de présentation avancés qui s'appliqueront uniformément à tout un site. On peut dire que le texte sera du Arial de 12px et que l'interligne sera double, mais pas qu'une ligne sur deux sera en gris, que les retours à la ligne seront alignés à droite (pour de la retranscription de poésie par exemple), que dans un tableau les lignes devront être tantôt colorées tantôt sans fond, que le premier <li> de ce menu sera vert, le suivant bleu et le quatrième orange... Ces quatres exemples sont soit irréalisables soit nécessitent l'intervention de classes particulières : le modèle de présentation n'est pas indépendant du contenu. Bien sûr, l'argument pour justifier cette absence de fonctionnalité, c'est que les CSS ne sont pas et ne deviendront pas un langage de programmation. Ce n'est pas le propos, je ne souhaite pas que ce langage perde de sa simplicité ni qu'il devienne dynamique et nécessite un interpréteur ! D'ailleurs, le brouillon des spécifications CSS 3 commence enfin à aborder ces notions sans les transformer en un outil complexe à manier, mais juste un peu tard...

Les CSS n'ont pas été initialement conçus pour séparer présentation et contenu^[3], contrairement aux objectifs actuellement défendus par le W3C. Et on s'en aperçoit plutôt facilement, tout simplement car il est impossible de séparer présentation et contenu pour peu de souhaiter faire un site légèrement graphique, sans même entrer dans les utilisations avancées décrites au paragraphe ci-dessus. Même le site du W3C ne remplit pas cet objectif ; regardez la source, vous trouverez des <span class="invisible"> et autres <p class="small"> ! Ici, on sépare le détail du style, mais pas le style en lui-même, qui est toujours dans la page. C'est en soi parfaitement logique puisque les CSS ne nous permettent pas de le faire ! Un autre exemple est le CSS Zen Garden : chaque paragraphe a une classe différente... le travail des graphistes est facilité, mais en production il est impossible d'arriver à un tel résultat.

Les CSS comportent également des lacunes indépendantes de leur conception pure.
Tout d'abord, le modèle de boîte du W3C est une erreur magistrale. En résumé, la propriété width spécifie la largeur du contenu. On se demande comment des experts sont-ils arrivés à une telle abberation !
Un exemple simple : il est impossible, selon les spécifications CSS, de donner à une boite une largeur de 100% avec des marges internes (padding) de 15px. Pourquoi ? Car votre bloc fera, en largeur, 100% (le contenu)+15*2px (les marges gauche et droite). Il dépassera donc la zone de visualisation ! Selon le modèle de boîte spécifique à Microsoft, votre bloc fera 100% de largeur, et le contenu fera 100%-15*2px... ce qui semble être un comportement logique : la largeur spécifiée est la largeur que l'on souhaite obtenir au final... La traduction française des spécifications dit : On obtient la largeur de la boîte en additionnant les marges, bordures et espacements gauches et droites avec le largeur du contenu. Il est donc tout bêtement impossible de spécifier la largeur d'une boîte en pixels avec les CSS pour peu de désirer des marges internes en unités relatives. Et si vous voulez un bloc de 200px de largeur avec 10px d'espacement intérieur de chaque côté, vous allez insérer dans votre feuille de style width:180px;. Logique ! Si l'équipe de développement d'IE a eu tort de vouloir faire son originale en ne se pliant pas aux spécifications, elle avait raison sur le fond : son modèle de boîtes est bien plus pertinent.

Dans leur simplicité, les CSS ne permettent pas l'addition de différentes unités. Concrètement, ça signifie que si vous avez un menu de 30% de large à 40px du bord, vous ne pourrez pas attribuer une marge de 30%+40px à une autre boite et donc l'aligner à droite du menu ! Situation qui se traduit par un simple schéma :

Le bloc B ne peut pas être placé à la limite du bloc A. Et pourtant, l'énoncé est très simple !

À ces défauts majeurs s'ajoutent d'autres détails, l'impossibilité de spécifier deux arrière-plans pour un élément^[4], l'impossibilité de placer un bloc enfant dans son bloc parent avec des marges en % du bloc parent, l'absence de filtres d'images basiques pouvant remplacer ceux propriétaires d'Internet Explorer, ...

En conclusion, vous aurez compris que je critique pas les CSS au profit d'une autre solution - et c'est dans un sens malheureux, car toutes les choses décrites dans ce billet ne seront pas réalisables avant un bon bout de temps, mais bien pour ses défauts majeurs commençant seulement à être comblés, avec 10 ans de retard. Je ne reproche pas aux CSS de ne pas avoir été parfaits dès leur création, mais au W3C de s'être endormi (sur ses lauriers ?) en n'ayant toujours pas sorti ses spécifications CSS 3 7 ans après le début de leur élaboration alors que le besoin d'évolution était et est toujours, plus encore aujourd'hui, majeur, et d'avoir négligé ou oublié certaines fonctionnalités importantes pour les spécifications 1 et 2.
Pour revenir au titre, les CSS ne sont ni la solution ultime de mise en page ni les sauveurs intergalactiques du Web, contrairement à ce qu'affirment certains développeurs. Si les CSS sont un progrès - et c'est indéniable, j'en suis le premier convaincu -, ce sont également un progrès imparfait, non-fini et loin de répondre à tous les attentes des concepteurs de sites.