C’est au tour de Christophe Andrieu de prendre le clavier. Décidément, on n’est plus chez soi !
Même si sur le moment il ne m’avait pas frappé outre mesure, je repense assez fréquemment au coup de gueule de Gilles Vauvarin lors de sa conférence à Paris-web cette année : il était consterné que les intégrateurs ne respectent pas le rythme vertical de ses designs.
Ce fut l’occasion de me rappeler à quel point c’était super, le rythme vertical. Et à quel point j’en avais bavé à chaque fois que j’ai essayé de l’implémenter en CSS.
(C’est quoi le rythme vertical ? Allez lire cet excellent article de David sur le sujet)
Blueprint et les navigateurs sont dans un bateau
Remotivé par le sujet, j’attaque donc mon nouveau design avec Blueprint, framework CSS bien connu pour gérer intelligemment ce genre de problématiques délicates. On me l’a notamment conseillé pour éviter de me prendre la tête avec les calculs d’interlignages en em, qui donneraient des cauchemars à Pythagore en personne.
Hélas ! J’ai déchanté assez vite. Conserver un rythme vertical avec un vrai design (même minimaliste) est excessivement complexe, Blueprint ou pas Blueprint.
J’ai notamment buté sur les arrondis générés par les moteurs de rendu des navigateurs, qui ne sont apparemment pas calculés de la même manière.
Comme tout est défini en em, on se retrouve assez rapidement avec des styles générés assez exotiques : si mon line-height est de 1.5 et ma font-size de base de 11 px (12 px c’était trop facile), mon line-height généré va être de 1.5 × 11 = 16.5 px… et les demi-pixels, les navigateurs, en gros, n’aiment pas.
Ou du moins, ils ne l’interprètent pas tous de la même façon (ou alors j’ai vraiment raté un train). Ce qui oblige à une certaine gymnastique pour retomber sur des calculs de pixels générés entiers – qui eux sont interprétés de la même manière partout. Par exemple là, pour avoir un line-height généré de 17 px (mettons), je vais devoir mettre line-height:1.565… et encore, ça reste un arrondi.
Imaginez maintenant qu’on rajoute des bordures CSS, des images, bref toutes sortes de contenus et de styles qui décalent tout au fur et à mesure avec toujours plus d’arrondis.
Je ne vous fais pas de dessin, c’est un enfer !
Tout passer en pixels ?
Bref, j’ai été vite écœuré de cette mélasse d’em qu’on nous a pourtant appris à aimer dogmatiquement durant toutes ces années d’évangélisation aux bonnes pratiques.
D’où une question bien légitime : « mais pourquoi n’utilise-t-on pas tout simplement le pixel, unité native de notre medium ? ».
Évidemment, on sait qu’IE ne comprend pas grand-chose aux agrandissements de textes dès qu’on lui parle en pixels… et on entre alors dans des considérations plus philosophiques que techniques. Doit-on laisser IE sur le carreau ? N’est-il de toute manière pas intéressant de conserver des unités relatives pour les marges entre paragraphes (par exemple), afin de conserver nativement des proportions harmonieuses ?
Stéphane en parlait il y a deux ans de ça, les choses n’ont pas évolué depuis, et c’est bien dommage.
Bref, une piste à oublier, probablement.
Vers un mode de calcul normalisé pour tous les navigateurs ?
Revenons aux em : pourquoi les moteurs graphiques des navigateurs sont-ils infoutus de gérer les arrondis de décimales de pixels de la même manière ?
Y a-t-il des groupes de travail là-dessus ? Des ressources en ligne ? Est-ce que j’ai loupé quelque chose en route ?
Si vous avez des éléments de réponse je suis avide de les entendre…
Pour le moment, j’ai cette phrase de Stéphane qui me reste en travers de la gorge : « le rythme vertical pour moi, ne peut se tenir qu’avec des bricoles en JS : CSS n’est pas assez solide pour ça ».
Dites-moi que c’est faux !