Cet article fait partie de la série KiwiParty : le plein de vitamines web.
Sur des petits formats de 30min, ces deux conférences creusaient des directions spécifiques au CSS.
BEM : Block Element Modifier
Thomas Zilliox (@iamtzi) nous présentait cette convention de nommage de classes.
Le but est d’avoir des classes autonomes (qui ne s’empiètent pas les unes les autres) et explicites (pour un humain qui les lirait et les modifierait).
Ce n’est pas un standard, mais plutôt une logique d’organisation, qui cherche la plus grande efficacité et maintenabilité du code.
BEM signifie « Block – Element – Modifier » (à prononcer à l’anglaise) : bloc, élément, « modifieur ».
On désigne par block un composant ou module qui fonctionne de manière autonome : un menu, un formulaire de recherche, une mini-fiche produit… Il peut se trouver dans des endroits différents d’une page, sans être défini ou influencé par ce qui l’entoure.
Un element est, lui, une sous-partie d’un block : le champ texte du formulaire, un lien du menu… Il existe et n’a de sens qu’au sein d’un block.
Enfin, modifier désigne en quelque sorte l’état de l’élément : important, ouvert, caché…
Ces trois informations vont former le nom de la classe, par exemple : block-name__element-name–modifier-name. Un seul tiret pour les noms composés, deux underscores avant le nom de l’élément et deux tirets avant le nom du modifier : c’est ce que propose la convention, mais cela peut également fonctionner avec du camelCase et ainsi réduire le nombre de tirets.
La présentation est plutôt claire sur les avantages (indépendance vis-à-vis des balises HTML, surcharge de styles plus facile, …), mais le temps était compté pour pouvoir échanger à la fin.
Les questions ont évoqué très rapidement la différence avec SMACSS, ou suggéré l’utilisation des attributs ARIA en guise de modifiers.
Pour ma part j’aurais bien voulu évoquer l’usage sans préprocesseur : sans extend et avec un principe de classe « non-réutilisable », le risque est de se retrouver avec beaucoup de répétitions, pour des styles identiques d’un block à un autre.
Consulter les slides
Et pour aller plus loin, la définition de BEM
En conclusion, c’est effectivement facile à mettre en place, mais il faut s’y tenir sur un projet entier pour que ca devienne une vraie convention de nommage et prenne toute sa valeur.
De notre côté notre convention de nommage a une logique similaire, mais qui est plutôt element-block puis des classes séparées pour les modifiers : cela nous permet de rester sur des noms de classes plus courts, et d’avoir une certaine souplesse pour des classes réutilisables.
Les dessous de line-height
Pour moi, cette conférence a été le clou de la journée : en 30 min, Vincent de Oliveira (@iamvdo) nous a décortiqué line-height à un rythme soutenu, démos interactives incluses.
Je pense que je n’ai pas été la seule à avoir du mal à suivre en prenant des notes, tellement les explications s’enchainaient, avec les détails typographiques et mathématiques qui vont bien.
Ce qu’on peut retenir, c’est que line-height (la hauteur de ligne) est une propriété beaucoup plus complexe qu’il n’y parait, qu’elle n’a pas de « valeur par défaut » universelle (ca dépend de la police utilisée), et qu’elle a une forte influence sur le vertical-align.
Ca a été l’occasion de découvrir le leading, cet espace ajouté en haut et en bas de chaque élément, qui s’ajoute à sa « hauteur réelle » pour former sa « hauteur virtuelle » (= la line-height).
Et ca permet de comprendre enfin pourquoi avec 2 éléments l’un à côté de l’autre, si l’un est théoriquement plus petit que l’autre, il peut néanmoins faire augmenter la hauteur du bloc les contenant.
Les slides sont plutôt bien détaillées, c’est ici