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 !
22 commentaires ↓
Malheureusement, à moins de faire des designs vraiment simplistes, j’en suis arrivé à la même conclusion : c’est la galère, framework ou pas.
Après vouloir laisser cette partie à JS c’est pas terrible à mon avis non plus, il vaut mieux savoir que ça se passe très bien avec tels navigateurs et un peu moins bien avec d’autres. Ça nuit à la lisibilité et à l’esthétique mais ça reste lisible, tiens ça me rappelle d’autres choses ça
Sinon pour en revenir aux pixels, vu que Webkit et Gecko redimensionnent maintenant la totalité de la page maintenant et ne tiennent plus compte des ems si je ne me trompe pas, ça devient une alternative envisageable. Et peut-être plus facile…
@david : Il faudrait « seulement » que IE s’y mette aussi pour que cela apporte plus de souplesse dans les devs… Y’a plus qu’a attendre.
Mouh ! Merci David pour cette bien triste réponse… Je m’en vais éplucher les liens que tu postais sur ton article pour y voir plus clair tout de même, mais je déçuuuu, mais déçuuuuuuu…
Sinon il est toujours possible de configurer le zoom « texte only » (au moins sur Firefox, pas essayé sur Safari / Chrome) donc le problème reste entier (?)… et il reste IE ! Bouuuhouhouuuu…
David :
Martin :
Vous parlez de quoi là ? Du zoom « page » ? Si oui, ne perdez pas de vue que c’est très différent d’un zoom « texte », comme le signale Éric.
Des liens sur le sujet du rythme vertical, parce-que c’est important quand même :
Salut,
J’ai essayé de m’y mettre le mois dernier de manière artisanale, premier constat effectivement : avec les em c’est l’enfer, je suis donc passé en pixels pour faire mes tests. Tout d’abord sur un design simpliste, j’ai réussi à le mettre en place assez rapidement, mais dès que je suis passé sur un design un peu plus complexe c’est devenu tout simplement ingérable. Je n’ai toujours pas regardé blueprint, et je réfléchi encore sur des moyens d’utiliser le rythme vertical de manière industrielle : pour un site personnel on peut toujours se débrouiller à avoir un bon rendu, mais lorsque il y a « n » acteurs sur un projet, il faut avoir une feuille de style solide pour que ce procédé soit maintenable.
Bref si j’arrive à avancer sur le sujet je vous tiendrai au courant, sinon j’espère que des personnes s’y sont déjà frotté et pourront nous apporter des retours intéressants.
Super article sur un sujet super intéressant, merci.
[…] rythme vertical en #CSS http://www.htmlzengarden.com/2009/11/le_rythme_vertical_en_css/ a few seconds ago from […]
Éric,
Je vois au moins un problème majeur à l’utilisation des pixels : les marges ne sont pas proportionnelles à la taille du texte.
J’ai codé rapidement un petit exemple pour bien visualiser le problème si besoin.
C’est l’approche mis en pratique sur ce framework il me semble.
Oui, je sais, mais pour faire mes tests c’était plus simple que de calculer les em au millième avec une calculatrice… Je me posais la question également sur une utilisation mixte : la police en pixel, et l’interlignage et les paddings et margins en em, mais je n’ai pas eu le temps de tester encore. SI tu as des infos à ce sujet je suis preneur.
Je me permet de poster à nouveau, j’ai trouvé cet outil qui se combine à Firebug, je le trouve super pratique à l’utilisation : http://www.puidokas.com/portfolio/gridfox/.
Suite à la présentation de Gilles Vauvarin (si mon souvenir est bon), je glissais une question à un confrère sur le rythme vertical pour les sites web. Je ne sais plus si c’était Benjamin De Cock ou Aymeric Jacquet qui répondait en substance: «c’est beaucoup d’emmerdes pour pas grand chose.»
On discute ici du «beaucoup d’emmerdes». Très bien. Moi c’est surtout le «pas grand chose» qui m’intéresse. Malgré quelques lectures sur le sujet, je n’ai toujours pas compris l’intérêt de gérer finement le rythme vertical dans un design de site web. À titre personnel, une maquette avec un rythme vertical fin dans un journal ou un magazine, je le perçois (sans dire que je le remarque tout à fait consciemment); mais sur un site web, c’est beaucoup moins évident. Le défilement vertical rend le positionnement vertical des éléments assez flou pour le lecteur. Ce qui compte alors, c’est plus la succession verticale des éléments, l’association visuelle entre éléments (proximité). En tout cas c’est mon sentiment.
Est-ce qu’on a des données scientifiques sur l’importance du rythme vertical (maitrisé au pixel près ou à deux pixels près) dans un contexte web? Et dans un contexte print, tant qu’à faire?
@Eric : Comme Vincent pour les pixels, ça me chiffonne au fond. N’hésite pas à nous en faire profiter si tu explores d’autres pistes !
@FlorentV : c’est prendre le problème de l’autre côté, mais soit c’est un angle de débat intéressant.
Lorsque l’on se retrouve avec un layout à fort colonnage, je pense qu’on se rapproche des problématiques print question alignement vertical : le défilement n’y change rien, les colonnes défilent en même temps, comme si le regard parcourait une page de journal de haut en bas. Tu dis que tu le perçois sur papier, moi je pense que je le perçois sur l’écran !
Ce qui ne signifie évidemment pas que les autres lois d’ergonomie que tu rappelles (la Gestalt, Fitts et leurs copains) sont à négliger, c’est complémentaire.
Quoi qu’il en soit un éclairage statistique et scientifique sur le problème serait effectivement intéressant, et j’aimerais également avoir l’avis de designers sur la question que tu poses…
Maintenant ce qui me motive personnellement dans la recherche de la faisabilité technique de la chose, c’est tout simplement mon métier et ma conscience professionnelle : je suis dev front au quotidien. J’aimerais savoir si c’est applicable en prod de façon industrielle : en gros, si Gilles me refile un jour son PSD et me demande de respecter le rythme vertical, je veux savoir lui répondre « oui je peux le faire » ou « non c’est trop compliqué ».
J’arrive après la bataille, mais le rythme vertical, pour avoir essayé, même à base de pixels, c’est pas évident d’être calé au pixel près. J’ai même calculé à la main, on a parfois un décalage d’un « pixel fou » dont on ne trouve pas l’origine.
Par contre, il faut essayer car même si ce n’est pas parfait, je trouve que ça apporte de l’harmonie et de la visibilité aux pages web.
De mon côté, j’ai abandonné les em, partant du principe que l’agrandissement des textes est de moins en moins fréquent depuis l’arrivée du zoom.
Les principales difficultés rencontrées sont : - la taille des titres : par exemple, si j’ai un rythme vertical de 15px et que le titre h2 est de 16px, je doit mettre un line-height de 30px si je veux respecter le rythme pour un titre sur deux lignes. C’est particulièrement inesthétique. - la taille des images : si la hauteur de l’image n’est pas multiple du rythme vertical (n*15px) ça casse tout. Ca pose problème notamment pour les images envoyées par les clients. - les éléments de formulaires : c’est un peut la galère pour continuer de respecter ce rythme à l’intérieur d’un formulaire, surtout si ils sont généré à la volée par le CMS. - les bordures : penser à retirer 1px aux margin ou padding quand on y met une bordure.
Bref, pour chaque site que j’ai essayé d’intégrer en respectant le rythme (dans la limite de mon temps vu que c’est du plus), c’est un échec plus ou moins important.
Quelques exemples : http://www.renaissance-coiffure.com/ http://www.loreedumarche.fr/
@+
Encore une fois, j’ai du mal à faire cette simplification. Les marges autour des éléments textuels se doivent d’être proportionnelles à la taille du texte pour. Le zoom texte est toujours facilement accessible et je suis sûr que beaucoup préfèrent son utilisation qui ne provoque pas l’apparition de barre de défilement.
Une astuce toute simple : placer une marge négative pour compenser les pixels ajoutés par la bordure.
Complètement d’accord avec toi.
Bonjour à tous,
Il semblerait qu’en ce moment les réflexions autour de l’alignement vertical soient de rigueur.
Je suis allé voir la conférence de Gilles Vauvarin, et pour ce que j’en ai compris, son objectif était vraiment de proposer des solutions pour que les designers graphiques et les intégrateurs travaillent mieux ensembles, pas de semer la zizanie
J’ai cru comprendre qu’il avait éliminé des slides faute de temps, et il a au final passé plus de temps à développer les problèmes dans les échanges entre designers et intégrateurs qu’à développer ses solutions pourtant intéressantes.
Pour ce qui est de la gestion du rythme vertical mon point de vue est le suivant : c’est une considération visuelle qui contraint l’intégration. Il suffit juste de se demander si cette contrainte est justifiée ou acceptable dans le projet en cours.
En amont de la conception visuelle d’une interface, on est sensé avoir défini les objectifs et les plus-values d’un projet. Un projet dont la réelle plus-value est le design privilégiera les considérations design sur l’intégration. De façon corollaire, un projet dont la réelle plus-value sera l’accessibilité, le respect des normes, de la sémantique ou la propreté des codes HTML/CSS/JS privilégiera l’intégration sur le design.
Ces deux disciplines ne s’opposent pas, mais elles ont besoin de travailler ensembles pour pondre le projet le plus adapté possible au besoin client.
Un designer doit accepter les contraintes liées à l’intégration sur les projets ou la qualité du code est primordiale (sites très « orientés accessibilité » par exemple). Pour ces projets ou l’accessibilité et la sémantique sont primordiales, je préconise même parfois de concevoir les gabarits juste après la conception ergo et avant de concevoir le design. Ici, le webdesigner doit être capable de savoir où et comment ajouter des éléments graphiques au gabarit sans qu’il ne soit nécessaire de modifier le code ou d’ajouter de balises neutres.
Parallèlement à ça, un intégrateur doit accepté de respecter les choix graphiques d’un designer si (et seulement si) ceux-ci prévalent sur l’intégration. Dans ce cas, et en tant que designer, je connais la contrainte du rythme vertical, donc si je peux éviter d’augmenter la charge de travail des intégrateurs de 30% en évitant d’imposer cette contrante, je le fais. Par contre, dans les projets ou le design à carte blanche, et ou je trouve un parti-prit graphique qui impose le respect d’un rythme vertical, alors l’intégrateur devra faire avec.
On est bien d’accord, les contraintes, ça n’est pas confortable, parce que ça impose de faire du sur-mesure, voire de faire des choses qu’on a jamais fait avant. Mais n’est-ce pas là quo’n peut finalement trouver du plaisir à concevoir?
Pour finir, nous parlons en fait ici des contraintes projet. Il s’agit de ne pas faire des choix (graphiques ou d’intégration) qui imposent trop de contraintes à l’autre discipline. Pour ça, il est indispensable de définir le niveau de contrainte acceptable pour chaque discipline. C’est aussi en fonction de la répartition des budgets définie en amont. Normalement, la répartition des contraintes sur le projet est du ressort de la gestion de projet.
Merci Laurent pour cette réponse complète.
OK pour les contraintes projet et la gestion des priorités design / intégration : je te suis à 100% là-dessus, je me suis récemment pas mal battu sur un site de mairie pour qu’on puisse mettre tous les textes en HTML et pas en images, tout simplement parce que l’accessibilité était plus importante que le respect de la typo sur ce projet.
Là où je suis plus dubitatif sur le cas du rythme vertical, c’est que je doute tout simplement de la faisabilité de la chose en CSS, à cause des disparités de rendu entre les différents moteurs des navigateurs. Ou alors ça veut dire designer directement en HTML, avec une grille passe-partout (du 12px et de l’interlignage qui tombe « juste »).
J’aime bien l’idée de défi dans le fait de tenter de concevoir des choses qu’on n’a pas faites encore avant, mais sur le rythme vertical, avec une taille de font funky, je me suis juste cassé les dents !
Pour finir, la répartition des contraintes entre disciplines décidée en amont par la gestion de projet, j’ai un peu du mal à la voir appliquée à ce genre de considérations pointilleuses… J’ai l’impression (peut-être fausse ?) qu’on touche là à des spécialisations dans nos métiers respectifs que beaucoup d’intégrateurs et designers ignorent encore (et que je découvre pour ma part), je doute que mes chefs de projet en comprennent un traître mot ! Mais c’est peut-être un autre problème…
ok, sur la « faisabilité » de l’alignement vertical en CSS, n’étant pas un spécialiste de l’intégration, je ne m’avancerai pas trop.
Au delà de la faisabilité du truc, si l’alignement vertical ajoute 30% à la charge de travail jour/homme des intégrateurs et que ça sort du budget alloué à l’intégration, il ne faut pas se borner.
Sur 90% des projets, on fait travailler un designer et ensuite on appelle un intégrateur pour qu’il se démerdre à intégrer les gabarits tout en lui imposant un délai et un tarif (pour les indés). En clair, l’intégrateur n’a rien a dire sur l’approche graphique des compos, et on lui impose des contraintes parfois injouables dans les temps impartis. Souvent aussi, il est contraint de bidouiller un code pourri et de faire des abérations sémantiques pour coller aux contraintes imposées par le design. Je comprends la frustration. Pour moi, ce problème relève d’une grossière erreur de management du projet, et d’une méconnaissance totale des processus de production web. L’intégration et le design ne sont pas des phases séquentielles, elles s’imbriquent et sont interdépendantes l’une de l’autre.
Ce genre de problemes pourraient tout à fait etre éviter s’il y avait plus de communication entre les chefs de projet, les graphistes et les intégrateurs, pour que dans le budget imparti, on puisse faire rentrer le design et l’intégration. Je pense qu’au fond, c’était le propos de Gilles et j’y adhère.
En tant que graphiste, avant de commencer une mission je demande toujours à contacter l’intégrateur pour m’entendre avec lui sur le niveau d’accessibilité et de sémantique requis de son code. Je suis capable de pondre une compo graphique qui tient compte des contraintes d’intégration sur projet. A mon sens, tous les designers devraient le faire. Il est aussi de la responsabilité des intégrateurs de demander à voir le designer avant le début du design pour lui exploser ses contraintes projet.
Ici, si le budget intégration ou les délais impartis ne permettent pas à l’intégrateur de perdre du temps sur l’alignement vertical, il faut que le designer le sache et en tienne compte avant de commencer.
Il y a d’autres sujets à aborder entre designers et intégrateurs avant de commencer le design d’un gabarit: - La façon dont le psd sera organisé, et ses calques nommé. - définir la grille qui sera utilisée pour l’intégration. - etc… C’est ici que la répartition des contraintes doit se faire, avant le design. Ça éviterait pas mal de frustrations.
Je suis bien d’accord avec tout cela, d’ailleurs c’est amusant de voir le mot « frustration » revenir si souvent dans ton discours parce qu’il est également au centre de la conférence de Stéphane (toujours à Paris-web) qui parlait des intégrateurs…
Au quotidien (et du moins en agence), il est rare que l’intégrateur intervienne en amont sur le design, au mieux c’est le chef de pôle inté qui s’y colle (ce qui est déjà bien). La réunion de « lancement » avec l’intégrateur a généralement lieu une fois toute la créa abattue, et il n’est souvent plus temps de revenir en arrière.
La formation des designers est à mon avis aussi à mettre en cause, certains n’étant pas, comme toi, capables de pondre une compo qui tienne compte des contraintes intés (parce que méconnues et souvent jugées trop contraignantes et moins valorisantes par rapport à des créas print ou Flash par exemple). La solution passerait donc par de multiples aller-retours design / inté, une forme de validation continue au fur et à mesure de l’avancement de la créa ?
Dernier point : les créas en agence sont souvent héritées directement des compos qui ont été présentées au client pour remporter les appels d’offre. Et ces compos-là, aucun techos ne les voit jamais. Elles sont souvent irréalistes et infaisables (pour impressionner), mais difficile de revenir dire au client qu’on lui a vendu du rêve…
J’interviens sur un petit point de STPo.
Tout processus de création est itératif.
Je ne suis pas dans le métier. Et je ne souhaite pas y entrer avant 5 ou 10 ans. Mais ce que vous dites, c’est-à-dire aucune communication entre designers et intégrateurs, est une erreur de processus.
Il existe dans le domaine de l’ingénierie par exemple des traités sur les modes/processus de conceptions. Ce sont des traités qui existent depuis 2 siècles (peut-être plus) mais qui sont toujours utilisés.
je trouvais ca interessant au départ mais ingérable en pratique. Avec un site très visuelle non parlons pas. par exemple si j’ai du texte qui est accompagné d’une image qui float a droite plus haute que le texte, tout est foutu -_-
[…] tant qu’ayatollah affiché du rythme vertical, tout cela me chiffonne un brin. Non pas que j’utilise les lettrines très souvent (c’est même […]
Je vois qu’on est tous aussi bargeots, ça me rassure
J’ai aussi cette remarque de Gilles Vauvarin sur le rythme vertical qui me tarabuste et depuis sa conférence je m’y essaye, avec ou sans BluePrint, em ou pixels, mais avec acharnement et beaucoup de mesures, calculs et neurones froissés, pour arriver aux mêmes conclusions : mais quelle galère !
Ceci dit, c’est un bon entrainement et je veux bien garder un œil sur cette préoccupation, mais sans m’efforcer (en vain) de garantir un calage précis. La question de Florent est pertinente : pour évaluer si ça vaut le coup de tant se contorsionner, que sait-on vraiment des bienfaits du rythme vertical pour l’écran web est son utilisateur ?
Laisser un commentaire