Au fil des projets, on aime à pouvoir réutiliser du travail déjà réalisé auparavant. On gagne du temps, on ne réinvente pas la roue et surtout, on sait que ça fonctionne.
Assez curieusement, cette pratique reste quelque peu à l’écart du monde de la présentation Web. Combien de fois n’a-t’on pas recréé son screen.css depuis la page blanche ?
Une approche objet des CSS pourrait pourtant nous faire gagner un temps précieux !
Les CSS … c’est de l’objet ?
À première vue ce n’est pas le cas. Pourtant à y regarder de plus près, la cascade et l’héritage sont des bases de modularisation du code de présentation.
À vrai dire, la première fois où j’ai entendu parler de CSS, d’objet et d’extension dans une même phrase, c’était lors de [Paris-Web 2008->http://www.paris-web.fr/]. Nicole Sullivan demandait alors à Daniel Glazman s’il était possible d’introduire une approche objet indépendante de la cascade.
Depuis, Nicole a planché sur l’affaire et publié OOCSS pour Object Oriented CSS. Son travail se matérialise par un ensemble de bonnes pratiques ainsi qu’une librairie CSS basée sur YUI.
Penser bien, penser module
Un des fondamentaux avancé est le changement de la représentation de notre code CSS. Plutôt que d’écrire des sélecteurs CSS pour habiller spécifiquement du contenu, il vaut mieux s’orienter sur un travail en plusieurs temps :
-# créer un socle commun (reset, typographie, helpers etc.)
-# identifier les motifs et modules dans nos pages (exemple : paragraphe de tête illustré par un media, une liste de contenus courte, une liste de contenus longue etc.)
-# habiller le tout pour les besoins du site (skin)
Si notre module n’existe pas, on le crée sinon le réutilise. Dans tous les cas on l’habille spécifiquement pour le site et ça n’est au final que la seule charge de travail peu réutilisable d’un projet à un autre.
En faisant ainsi, nous séparons le fond et la forme mais surtout, nous faisons en sorte que les 2 soient maintenables.
En pratique, au lieu d’avoir une feuille CSS par environnement (home.css, forum.css, news.css etc.), on aurait 1 feuille par type de composant (media.css, grid.css, box.css etc.). Ces éléments sont réutilisables d’un projet à un autre.
_ La mise en forme serait quant à elle l’objet d’une autre feuille (skin-rauze.css par exemple), spécifique au projet.
Use the Grid, Luke
Si Luke Skywalker était designeur et/ou intégrateur HTML, c’est ce qu’il aurait entendu d’Obi-Wan au moment d’enregistrer sa feuille CSS. Qu’est-ce qu’il aurait gagné comme temps contre l’Empire des CSS spaghettis !
Les grilles permettent d’harmoniser les largeurs de colonne. On peut y goûter depuis un bon moment avec les nombreux frameworks CSS du marché tels que Blueprint CSS, YUI Grids CSS, ou encore 960 Grid System.
Le système de grille d’OOCSS apporte une syntaxe facile à mémoriser avec des tailles proportionnelles. De quoi imbriquer des colonnes à volonté et des présentations complexes en peu de temps.
Idéalement ce travail de grilles doit être mis en place le plus en amont possible : au niveau de la création artistique ; d’elle-même ou sur demande de l’intégrateur.
_ Les colonnes deviennent ainsi elles-même des composants réutilisables tout au long de vos projets.
Conclusion et anticipation
Ces quelques pistes de réflexion et d’action permettent au final de gagner :
– du temps
– des kilo-octets en moins
– des bugs en moins
– des lignes directrices dans le travail
– une harmonie dans le code
En d’autres termes, on gagne en performance que ce soit au niveau de l’intégration, de la maintenance mais aussi de la production : votre site en live sera plus rapide à l’affichage.
OOCSS est une sorte de framework composite à la carte avec :
– le cœur du framework
– l’extension du framework que vous créez pour vos besoins et que vous maintenez
– sa philosophie de modularisation et de performances, motivante pour toujours faire mieux sans régresser
Modulariser notre conception de l’affichage est également une bonne anticipation des futurs modules CSS 3 Layout et [Multi-column->http://www.w3.org/TR/css3-multicol/].
