_Article publié initialement le 11 mars 2020, corrigé et complété_ Tel le marronnier de l’intégration web, j’ai vu réapparaitre régulièrement au fil des années, l’idée de replacer dans le HTML des attributs de mise en forme. **Au départ, on avait les “vrais” attributs de mise en forme HTML**. Rappelez-vous : valign, align, margin, etc. C’était pratique, mais ça, c’était en 1998. Et puis avec CSS Zen Garden, on a découvert que séparer fond (HTML) et forme (CSS), c’était quand même bien pratique : le fait de découpler la mise en forme du HTML avait beaucoup d'avantages. Donc on a mis cette histoire de déclaration de la mise en forme dans le HTML de côté. **Bootstrap a relancé l’idée**, avec ses Utilities : `border-top-0`, `position-absolute`, etc. Et encore une fois, ces Utilities, bien qu’utiles, posaient des problèmes : - **problème de séparation du fond et de la forme** : CSS est plus ou moins une librairies de styles, et la mise en forme est faite dans le HTML :/ - **problème de spécificité** : si je prends le border-top de Bootstrap 4, par exemple, on tombe sur une règle de ce type : border-top: 1px solid #dee2e6 !important;. Bon, ça c’est le problème de Bootstrap. Mais quand même, en empilant des classes qui n’ont aucun rapport les unes avec les autres, on a vite fait des créer des conflits de règles. Exemple : ```

``` - **problème de lisibilité** : en définissant les éléments d’interface (les unités d’informations) comme en empilement, sans logique, de classes de mise en forme, on ne savait plus trop bien à quoi correspondait, dans l’interface, l’élément sur lequel on bossait. - **problème de maintenance** : une évolution ? un bug à corriger ? Imaginez revoir tous les boutons sur votre intégration, pour leur apporter un border-radius, ou bien ajuster le padding, ou un truc du genre. Bon courage. Alors bon, ça nous faisait marrer de revoir des trucs comme ça. Pour du prototypage, ça fait le boulot, mais pour de l’intégration durable, passons. **Mais ça c’était avant, et maintenant, on a du neuf : Utility-First CSS**. En gros, en pied de nez aux méthodos orientées composants (OOCSS, BEM, etc.), qui place le composant d’abord, exemple : ``` Mon bouton

``` Le logique Utility-First CSS propose quelque chose comme : ``` Mon bouton ``` Vous noterez le concept particulièrement novateur : - plus de problème de nommage : y’en a plus - donc si on ne nomme plus, on va plus vite à taper du code Mais : - aucun d’aspect sémantique (c'est l'idée) Je m’imagine reprendre une inté qui a été initialement faite comme ça, et les questions qui me viendraient (NB: toutes mes remarques sont issues de mises en situation imaginaires avec des équipes en production) : - **plus de liens avec l’architecture de l’information définie dans la maquette** (comment savoir, dans le code, quelle unité d’information est représentée ?) : alors oui, un bon découpage de templates peut faire le boulot, mais d’une façon ou d’une autre, a minima, le debug ne sera pas une partie de plaisir. - c’est subjectif, mais je me dis : **et la lisibilité là-dedans ?** Je reprends une tartine de HTML écrite comme ça => 🚪. Plus sérieusement, le temps passé juste à comprendre quel élément est où / fait quoi ne me semble pas du tout négligeable. - si on va plus vite à tomber l’intégration d’un élément, je pense que sur le long terme, on y passe beaucoup plus de temps (cf. plus haut, mon exemple du bouton avec Bootstrap). - comment maintenir une cohérence dans l’interface : il arrive qu’on m’appelle pour me demander de resserrer les vis sur des intégrations qui ont été faites et où il y a pas mal d’incohérences, sur les mêmes composants (dans les maquettes, tout du moins) d’une page à l’autre du site. Utility-First est voué à produire des incohérences de ce genre : un bouton à un endroit n’a pas de lien avec un bouton à un autre endroit (sauf si on a un système de vues bien découpé - React, Vue, etc). Plus généralement, le concept de composants s’est fait une place de choix dans tous les métiers de l’interface : UX designer, UI designer, dev front, parlent déjà tous de composants d’interface / d’unités d’informations. Depuis plusieurs années, le dialogue s’est simplifié : de manière transverse, **chaque métier peut discuter avec les autres en parlant des mêmes choses : des composants d’interface**. Pourtant, c’est comme si en 2017, un intégrateur c’était dit : fuck, allez-vous faire foutre, moi j’aimais bien Bootstrap, je vais faire les trucs à ma sauce. > Designer : “il faut qu’on retouche le composant d’avatar utilisateur” > Intégrateur : “tu parles de `

` ?” Cette méthodo supprime tout l’aspect nommage / sémantique de classes CSS. Pourtant, on a besoin de cet aspect : pour discuter, pour s’y retrouver, pour définir des éléments réutilisables. **Alors qui fait le boulot si ce n’est plus les classes ?** La seule solution qui me vient à l’esprit, c’est que c’est le templating qui reprend ce boulot. Effectivement, si vous avez un composant React de

enguerranws

Utility-first CSS : on va dans le mur ?

Join Our Newsletter. No Spam, Only the good stuff.