Des erreurs assez fréquentes

C’est pourtant très humain : quand nous intégrons une CSS, nous le faisons dans une certaine configuration, dans un contexte donné, nous utilisons des propriétés pour contrôler le rendu dans le navigateur et… nous utilisons nos petits yeux pour observer le résultat de notre travail.

Néanmoins, ce cadre – bien rassurant – qui nous permet de travailler nous amène à commettre des erreurs, si évidentes quand on sort la tête du guidon, et parfois si dures à éviter dans le feu de l’action.

Un exemple

Partons d’un exemple volontairement simple : imaginons un design classique en trois colonnes (200px/600px/200px), et imaginons que vous ayez un petit module qui affiche un message sur fond gris dans la colonne de droite.

Souvent, on va voir ceci dans la CSS :

.box {
  width: 220px;
  background: #ddd;
}

En soi, il n’y a pas de problème à priori : le module est défini de manière courte et efficace, en accord avec ce que l’on « voit ». Néanmoins, n’y a-t-il pas quelque chose qui vous surprend ? Si l’on reprend les conseils dédiés aux performances, un d’entre eux disait « ne pas utiliser de styles inutiles ». Si la colonne de droite fait 220 pixels, pourquoi redéfinir cette largeur pour notre module ? Dans ce cas, ce style est inutile.

Fort heureusement, concevoir des sites en responsive nous force en général à penser « plus souple » : imaginons que nos largeurs soient en pourcentages, cela implique nécessairement que notre module ne puisse être spécifié en pixels, vu qu’il va devoir s’étirer en suivant la largeur de notre colonne de droite. C’est déjà mieux !

Si cela n’était pas le cas et que vous n’êtes toujours convaincu, un autre exemple : revenons à notre exemple de départ. Imaginons maintenant que la colonne de droite soit linéarisée dans les résolutions inférieures (les trois colonnes sont empilées). Du coup, si nous avions spécifié la largeur, nous serions de nouveau embêtés avec notre module qui ne s’étire pas. Bien sûr, nous pouvions réadapter cette valeur via une média-query, mais c’était évitable déjà en amont !

Toujours pas convaincu ? Revenons encore une fois à notre exemple de départ. Imaginons qu’il faille adapter votre gabarit de base, votre collègue décide d’adapter les colonnes en 200px/550px/250px au lieu du 200px/600px/200px. La largeur spécifiée de notre module vient encore nous gêner. Pire, si la colonne de droite ne devait non pas être agrandie mais réduite, qui sait quels problèmes pourraient encore s’ajouter ?

Bref, une simple économie de styles nous permet non seulement d’alléger la CSS mais en plus nous simplifie beaucoup la vie et/ou d’éventuels changements… et la maintenance.

Utilisez le contexte

Si vos yeux vous font faire trop de zèle dans la création de styles, voici un conseil peu orthodoxe mais très efficace : soyez fainéant. Ne refaites pas ce qui est déjà amené par l’extérieur du module : son contexte. Laissez votre module respirer, rendez-le indépendant, laissez-le vivre sa vie en-dehors du reste.

Typiquement, si l’on prend l’approche OOCSS, un de ses postulats de base est de séparer le positionnement d’un module de son design intrinsèque. En l’occurrence dans notre exemple, si l’on sépare le positionnement de notre module de son design, on constate… qu’il n’y a pas de styles de positionnement, ces derniers sont apportés par le contexte où se situe le module.

Donc, quand vous définissez un module, ne voyez pas le fait d’ignorer son contexte comme un inconvénient et profitez-en au contraire pour le définir de manière aussi indépendante que possible. Déjà vous aurez plus de chance que ce dernier s’adapte bien quel que soit son contexte (ce qui va vous éviter beaucoup de problèmes en responsive), et surtout vous ferez des styles plus légers, plus passe-partout, et surtout plus réutilisables.

Éviter les « chiffres magiques »

Un chiffre magique en CSS est une valeur dont la seule justification est « ça marche » mais qui ne fonctionne que dans certaines circonstances données, souvent dictées par le cadre dont nous parlions au début. En général, c’est une erreur fréquente chez les débutants qui ne sont pas à l’aise avec le modèle de boîte, la gestion de la typographie ou quand le temps presse tellement que la CSS en est maltraitée.

Ces chiffres magiques ont énormément de défauts :

• ils ne fonctionnent que dans un cas donné : par exemple sur tel navigateur avec la taille de police de caractère par défaut ;
• ce ne sont pas des gages de pérennité : si un développeur reprend la CSS, il ne va pas forcément comprendre d’où cette valeur sort pour peu qu’il soit dans une configuration différente ;
• toujours pour le développeur qui doit mettre à jour, comment être sûr que ce bricolage ne va pas s’écrouler ?

Bref, ce n’est pas du tout fiable ! Dans l’absolu, évitez à tout prix ce genre de peaux de bananes.

La question

Posez-vous la bonne question : de quoi dépend réellement la valeur que je veux mettre, de quel contexte ?

Soit c’est un simple positionnement par rapport à un bloc, par exemple tel bloc doit être collé à droite dans son parent, ce qui donne :

position: absolute;
right: 0; 

ou le cas échéant un simple flottant.

Soit c’est fonction de la typographie – et beaucoup de choses en dépendent si vous utilisez le flux correctement – et dans ce cas, on préfèrera des valeurs avec des unités qui sont basées dessus, typiquement les em.

Bien que cette unité ait parfois mauvaise presse de par son fonctionnement – proportionnelle à la taille de son parent – en fait, il faut la comprendre ainsi : vous ferez dépendre la propriété de la taille de la police. Autrement dit, au lieu de choisir un chiffre magique qui ne marchera que dans un cas précis, vous utiliserez une unité qui se base sur un contexte, qui évoluera avec et qui vous offrira même une couche d’abstraction : peu importe la valeur réelle d’un em (selon le contexte cela peut varier), vous contrôlerez non pas le rendu mais son évolution.

N’oublions pas que tout ce qui est défini en fonction de la typographie permet de facto la possibilité de zoomer pour l’utilisateur sans créer de casse pour votre CSS, que ce soit en zoom global ou en zoom texte.

En poussant à l’extrême : le lâcher prise

« Penser en dehors de la boîte » ne peut au final que vous amener à une conclusion : le lâcher-prise. C’est le propre du Web, vous n’en avez pas et vous n’en aurez jamais la maîtrise. L’article de référence sur le sujet est « le tao du design Web (traduction francophone de Pompage) », écrit à l’origine par John Allsop.

Cet article pourtant écrit il y a 14 ans est encore plus vrai actuellement : rien qu’avec les centaines de périphériques (mobile, tablettes, etc.) et les centaines de paramétrages différents possibles (par défaut ou modifiés par les utilisateurs) le tout combiné au responsive, vous avez peu ou prou tellement de cas différents que vous ne pouvez pas maîtriser cela en respectant vos utilisateurs, leur diversité et leurs préférences.

Par contre, savoir lâcher-prise n’implique pas de perdre le contrôle.

C’est particulièrement bien expliqué dans l’article de Nicolas Hoizey « lâcher prise sans perdre le contrôle ». L’article parle de l’unité em, toutefois c’est applicable à n’importe quelle unité relative : vous n’imposez pas vos choix à vos visiteurs (ce qui est de toute manière une impossibilité), toutefois vous avez la possibilité de gérer ces choix sans pour autant démultiplier votre travail.

Un changement de mentalité

On pourrait croire que ce lâcher prise est contraignant et/ou tueur de liberté pour le concepteur du site, c’est tout à fait le contraire : non seulement vous vous permettez de satisfaire autant l’utilisateur sur smartphone, tablette que celui sur un ordinateur classique qui a un écran gigantesque avec un zoom important par défaut, mais en plus vous le faites avec un code unique !

Il m’arrive parfois d’être stupéfait de voir un cas d’utilisation – un périphérique exotique par exemple auquel je n’ai pas pensé – qui fonctionne parfaitement, et ce juste en ayant fait une CSS souple. :)

C’est pareil pour la quantité de travail : on pourrait croire que cette façon de penser implique beaucoup plus de travail. Ce n’est pas exact : avec un peu d’habitude, quelques outils (non indispensables), cela ne prend pas plus de temps, et parfois vous en gagnerez même beaucoup en définissant moins de styles ! (sans compter leur meilleure robustesse ainsi)

Comme le premier article l’indiquait, ces principes sont à voir comme un tout cohérent : penser « en dehors de la boîte » vous permettra de faire des CSS plus légères, plus performantes, plus souples et plus maintenables.

Pour le faire, quelques repères :

• séparez le positionnement du design de vos modules ;
• concevez aussi souple et fluide que possible ;
• évitez les valeurs sorties de nulle part ;
• utilisez le contexte pour éviter de sur-gérer le positionnement ;
• et demandez-vous de quoi vos valeurs CSS doivent être fonction, si elles doivent être fonction de quelque chose.

Bien entendu, il faut tester, tester et tester. Mais cela, vous connaissez déjà, n’est-ce-pas ? :)

Références, compléments

• A Dao of Web Design
• Le tao du design Web (traduction de Pompage)
• Lâcher prise sans perdre le contrôle
• Object Oriented CSS
• Code smells in CSS
• Magic Numbers in CSS

Note

Cet article fait partie de la série « Grands principes de construction moderne de CSS ».