Ou pourquoi j’ai décidé de maintenir et d’utiliser ma propre base de code pour développer mes interfaces web plutôt que d’adopter un framework CSS populaire.

Documentation | Download latest | Sources

Les origines du projet

J’ai commencé, vers 2006, à coder mes interfaces web. Ça correspond au moment où les slices tables avaient fait leur temps, Dreamweaver en WYSIWYG était décrié et les sites web devaient se baser sur un code respectueux des standards. Mais ce n’est que début 2009 que j’ai structuré un starter kit, avec un simple squelette HTML et 3 feuilles de styles : reset / base typo / forms, inspirés du framework blueprint. Puis le projet s’est bonifié avec le temps, en l’agrémentant avec mes découvertes, expérimentations et les bonnes idées puisées de ma veille technique.

Ce squelette avait comme objectif de fixer l’indispensable, et de faire vivre une codebase en parallèle pour des éléments plus spécifiques. C’est pourquoi j’ai attendu très longtemps avant d’y implémenter un système de grille par exemple.

Aujourd’hui, Amorce (vous noterez que je n’ai pas cherché bien loin pour le nom…) est bien plus complexe. Il embarque le système de templating nunjucks pour découper le code HTML en modules, utilise cssnext pour profiter des CSS du future en cours de standardisation, GRUNT pour compiler les fichiers. Il s’est fortement modularisé et va certainement continuer à évoluer (tant que je continue à coder des interfaces web) et gardera le même esprit : rester un constructeur d’interface souple, “style-agnostique” et qui ne me cadre surtout pas trop.

Parce qu’il n’y en aura jamais assez

En 2012, je me suis demandé pourquoi maintenir une base de code alors qu’il existe maintenant des frameworks CSS plutôt matures et très répandus.

J’en ai alors testé plusieurs, pensant que le code d’autrui, écrit par des huiles du web, devaient forcement me convenir. Je n’étais heureux avec aucun. J’avais l’impression qu’ils ne prenaient pas en compte ma problématique de designer. Le plus souvent, ils proposaient soit une conception trop ready out of the box, du pré-mâché, avec une liste de composants qu’il suffit d’appliquer avec plus ou moins d’options, soit je les trouvaient trop lourd pour mes besoins. Bref, tous ont leurs logiques et objectifs et aucun ne me satisfaisait.

Mes méthodes de travail et mes exigences évoluent sans cesse. CSS et le design interactif évoluent. j’ai trouvé qu’il était plus simple d’adapter ma base de code à mes besoins et envies, que de partir à la quête d’un nouveau Graal.

Le meilleur outil est celui que vous maîtrisez, qui ne vous bride pas, mais vous enrichi et dont vous prenez plaisir à utiliser.

Il y a plein de cadres CSS disponibles, et c’est finalement une bonne chose. Je suis partisan du pluralisme. Chaque intégrateur, chaque projet, chaque équipe a ses exigences et ses particularités, et devraient construire leur propre cadre, leurs composants, dans l’objectif d’un Material design idoine.

Personnellement, je veux pouvoir prototyper & designer en code, ce qui nécessite une boite à outils qui ne cadre pas les possibilités graphiques et n’impose pas de solutions d’interfaces. Elle doit avant tout m’aider à les construire.

Concepts & particularités

Les particularités de mon starter kit découlent de mes besoins et de ma façon de travailler. Il n’a nullement l’ambition de plaire au plus grand nombre, ni de répondre aux besoins les plus courants. Je ne fais pas dans le marketing. Je vous liste ici quelques pensées sur ce qu’il est ou qu’il devra être (oui, il est forcement perfectible).

Style-agnostique

Amorce n’embarque quasiment aucune personnalisation graphique et les choix par défaut (famille et taille des fonts, taille des gouttières) sont modifiables très simplement à travers des variables. C’est pour moi une condition indispensable pour construire une identité graphique et une interface utilisateur propre à un projet.

Une grille sur-mesure

En tant que designer, je souhaite pouvoir composer une grille qui s’adapte au contenu, et ne pas limiter mes compositions aux possibilités restreintes d’un système à 12 colonnes. Ne pas pouvoir utiliser une grille basée sur 7 ou 5 colonnes (ou même le nombre d’or) est inadmissible :). Amorce propose pour le moment un système de grille de 2 à 7 colonnes, j’ai rarement eu besoin de plus de 7 colonnes, et au besoin, il suffit d’ajouter quelques lignes de code.
Je pense d’ailleurs qu’il devient moins nécessaire de s’appuyer sur des modules de grilles pour concevoir un layout, car quelques lignes de flexbox peuvent aujourd’hui suffire.

Juste du CSS, exit Sass.

J’ai passé l’âge de perdre du temps à apprendre un langage ou une bibliothèque qui peut disparaitre d’ici une décennie au détriment du temps que je pourrais prendre pour m’améliorer en CSS ou JS. Pourtant, les variables, c’est quand même pratique. CSS s’est beaucoup (et va encore) s’améliorer : calc(), custom properties, custom selectors, color functions. cssnext m’apporte pour le moment tout ce dont j’ai besoin pour organiser mon code et de plus, il me permet d’utiliser et de découvrir les specs CSS en cours de standardisation.

Un constructeur de composants

J’ai remarqué que si l’on travaille avec un cadre qui propose une bibliothèque de composants, on tombe dans la facilité d’utiliser ces composants dans nos productions plutôt que de passer par une véritable phase créative de conception.
J’ai besoin que ma codebase soit avant tout un toolkit permettant de créer des composants sur-mesure, et s’il peut proposer une galerie de composants, ceux-ci doivent être modifiable/adaptable facilement et surtout désactivable rapidement (en commentant 1 simple ligne de code, et pas un build à relancer) pour ne pas polluer le projet avec des lignes de code inutiles.

Une convention de nommage unique.

Quand on utilise un framework, un module ou un composants “externe” (un système de grille CSS, un plugin JS), on importe une convention de nommage de class CSS (quand elle existe !) qui va venir en superposition de celle que l’on applique à son projet. Au final, on obtient souvent une soupe de class difficilement identifiables.
Utiliser une base de code qui pose et documente une convention de nommage permet de la conserver pour tout le projet.

Personnellement j’ai commencé en 2011 à utiliser le pattern element-block avec le plus souvent une lettre unique pour identifier l’élément enfant d’un block, inspiré de la sémantique des tags HMTL : h pour le titre du bloc, l pour les listes, i pour les items, a pour le lien principale d’un item, etc. Par exemple, les class CSS que j’appliquais à la navigation principale d’un site :

.main-nav { } /* pour l'élément <nav> */
.l-main-nav { } /* pour l'élement <ul> */
.i-main-nav { } /* pour les <li> */
.a-main-nav { } /* pour les <a> */

J’ai fait évoluer cette convention en utilisant des doubles underscores pour séparer l’identifiant de l’élément du nom du bloc et en ajoutant l’option modificateur séparé par un double tiret. Ce qui nous donne E__B—M, qui n’est finalement qu’une nouvelle variante de BEM.

J’ai conservé l’élément en prefix, par habitude.

J’utilise les doubles tirets/underscores pour :

• permettre de composer le nom des blocs à l’aide de trait d’union, je ne suis pas fan du camelCase pour les class CSS ;
• pour ouvrir la possibilité de sélectionner de manière sûre, à l’aide des sélecteurs d’attribut, les éléments et les modificateurs. De cette façon, il est possible de leur appliquer un style de manière globale, indépendamment du bloc parent.

Par exemple, le sélecteur utilisé si je souhaite appliquer un style particulier à touts les éléments metas informations (date, tags, auteur) :

[class^="metas--"], [class*=" metas--"] { }

Et si je souhaite créer un modificateur utilisable par tous les blocs, comme un modificateur --small :

[class$="--small"], [class*="--small "] {
    font-size: .8em;
}

Bref, finalement ce n’est qu’une question de préférence. L’important étant d’avoir une convention de nommage claire, unique et documentée.

Du prototype au produit

En 2012, j’ai pris la décision de proposer à mes clients une phase de prototypage après l’étape de wireframing, plutôt qu’une phase de maquettage (un wireframe fonctionnel en somme). Excellente décision, mais pour réaliser le prototype, j’ai décidé d’utiliser Bootstrap. Le moment venu de refactoriser le code pour passer à l’étape suivante, j’ai regretté amèrement mon choix et promis qu’on ne mis reprendrait plus.
Pouvoir démarrer un projet avec une base de code que l’on peut faire évoluer par itérations successives, du prototype au produit, est un gain de temps qui m’évite bien des céphalées.

Pour moi, l’étape de prototypage est le moment où je vais tester différents layouts de pages ou de composants sur différents viewport, dans leur contexte réel: le navigateur. En somme, j’ai besoin d’un outil qui permet de confronter rapidement une idée à la réalité; mais également de pouvoir conserver le code produit comme base de travail pour la suite.
Certains modules CSS d’Amorce , comme placeholder images ou flex utils, sont écris dans l’optique de faciliter l’étape de prototypage et peuvent ensuite être désactivées au besoin.

Mutant et non retrocompatible

Je ne conçois cette base de code comme un logiciel versionné que l’on peut mettre à jour à l’aide d’une ligne de shell.
Je démarre chaque nouveau projet avec la dernière version ou juste une partie du kit. La base de code doit servir à construire un cadre documenté, qui va évoluer ensuite en suivant le rythme de vie du projet. La specificité de chaque projet fait qu’il a son propre code, son propre cadre, sa propre identité.

Comme le web, Amorce doit être un outil en constante mutation. Tout peut changer d’une version à l’autre: les dépendances, la convention de nommage, les outils. Il doit pouvoir évoluer librement au grès de ma R&D, de mes besoins & découvertes.

Patch & work

La majeure partie du code d’Amorce n’est pas issue de mon cerveau. Il est essentiellement un patchwork de plein d’idées, méthodes, astuces glanées à droite à gauche sur des articles de blogs, frameworks, ou en explorant le code source de sites à l’aide des outils de développeurs.

Le code est sous Github, pour à mon tour rendre en partie ce que j’ai réussi à glaner et transformer, dans l’espoir que cela puisse servir à d’autres.

Vive le pluralisme