« N’y revenez pas ! »

Openweb.eu.org > Articles  > « N’y revenez pas ! »

Abstract

« N’y revenez pas », voici encore un titre étrange pour un article sur CSS. Pourtant il illustre parfaitement une problématique de production : éviter de perdre du temps en revenant sur une intégration.

Autrement dit, gagner du temps sur la maintenance et la vie du site.

Article

Préambule

Ne nous le cachons pas : le métier de développeur front-end (anciennement intégrateur) ainsi que la création d’un site se sont complexifiés. « Curieusement », les budgets ne reflètent pas cette complexification. L’explosion de la bulle internet dans les années 2000 y est certainement pour beaucoup : des budgets énormes pour produire des sites parfois d’une qualité douteuse dont on se demandait comment ils allaient se rentabiliser… le retour de bâton allait tomber à un moment ou un autre.

Je ne prétendrai pas que produire des sites à cette époque était simplissime non plus, souvenez-vous, nostalgie :

  • IE6 et son moteur de rendu… nous dirons « baroque » sourire ;
  • la documentation bien moins abondante qu’à présent ;
  • CSS offrait beaucoup moins de possibilités exploitables, il fallait tout faire en images pour avoir un rendu satisfaisant ;
  • etc.

Mais globalement, si nous avons la chance d’avoir en général enterré des horreurs comme IE6, d’avoir une documentation abondante et le bonheur de pouvoir utiliser des propriétés magnifiques comme border-radius, les média-queries ou des transitions CSS, produire un site ne s’est pas simplifié pour autant. La complexité dont nous nous sommes affranchis avec les progrès des navigateurs… s’est reportée sur d’autres points, liste non exhaustive :

  • gérer correctement le responsive ;
  • gérer l’amélioration progressive ou la dégradation gracieuse le cas échéant ;
  • gérer tous les aspects de cette série d’article : maintenabilité, performances, etc.

Et comme je le disais plus haut, le budget n’a pas forcément suivi. Globalement, on en fait beaucoup plus actuellement en… beaucoup moins de temps. Le développeur front-end n’y échappe pas.

Le temps pour créer une CSS est difficilement compressible : même si le développeur front-end travaille vite et bien, il faut ne serait-ce que produire une intégration robuste et… la tester sur de nombreux navigateurs.

Les incessants changements d’un client légèrement casse-pied, la maintenance proprement dite, etc. bref, revenir sur une intégration peut aussi avoir un coût en temps non négligeable. Toutefois, ces temps peuvent être grandement limités, pour peu que le développeur de la CSS… y ait pensé lors de la conception.

Préparer le terrain

Si vous avez déjà fait une intégration très complexe, par exemple une intégration en mobile-first nécessitant de nombreuses média-queries ainsi que des tests sur bon nombre de navigateurs, vous voudrez sûrement capitaliser sur ce travail, autrement dit : essayer de ne pas casser l’immense travail qui a été abattu, ou à minima éviter de vous relancer dans une batterie de tests exhaustive.

Pour ce faire, vous aurez deux possibilités :

  • soit tout bonnement ne pas toucher à la CSS !
  • soit y revenir en limitant les risques.

Parfois une refonte en profondeur est nécessaire, et là il ne sera pas possible de continuer sans repartir de zéro. Toutefois, c’est bien le côté maintenance qui nous intéresse ici :

  • soit une refonte complète n’est pas nécessaire ou même possible ;
  • soit c’est la simple vie du site qui nécessite des ajouts/modifications.

Qu’on se le dise : ces gains de temps – et de prises de tête – potentiels se construisent très tôt dans le projet, et les précédents articles de la série vous en donnent déjà plusieurs aperçus.

Si cela ne vous a pas sauté aux yeux, en voici quelques exemples.

Coder sa CSS du plus général au plus spécifique vous permettra de progresser par étapes : d’abord le layout général (avec les tests qui vont bien) ensuite des parties générales (la navigation par exemple, toujours avec des tests), et enfin des parties spécifiques.

Je prends toujours cet exemple (ici dans un article sur la qualité Web) : la CSS print est souvent vue comme quelque chose de pénible à produire… et bien souvent faite en catastrophe à la fin du projet.

Une fois n’est pas coutume, je cite cet article :

Un autre exemple : toujours dans ma checklist qualité, j’ai un point qui me dit que je dois prévoir une adaptation des contenus pour l’impression, une CSS print en somme. Si les maquettes sont suffisamment précises… je peux faire cette étape au moment de l’intégration. Dans le cas contraire, je peux quand même préparer cette adaptation ! Ainsi, cela me permettra de limiter les risques de surprise : si une version print d’une page a un problème, je peux raisonnablement penser que le problème viendra du contenu de cette page et non du gabarit en lui-même.

Cette méthode vous rendra des services, et pas que dans ce cas-là : pouvoir être quasiment certain que le problème ne vient pas du général mais de quelque chose de plus spécifique vous fera gagner beaucoup de temps !

Note : si vous avez étudié la conception de systèmes complexes, on appelle cela l’analyse descendante. Grosso modo : il y a un problème complexe qu’on va découper en sous-problèmes plus simples, etc. jusqu’à ce que les problèmes deviennent solubles. L’analogie est tout à fait valable pour CSS.

L’orthogonalité, la prise de conventions, penser en dehors de la boîte et avoir une approche DRY vous aideront également à préparer ces gains de temps, vous aurez posé des fondations solides en somme. Bien travailler pour moins travailler est un excellent motto ! sourire

N’y revenons pas (trop)

Ne pas revenir sur l’intégration

Si avec ce qu’il y a dans votre CSS, vous arrivez à reconstruire ce dont vous avez besoin sans toucher à la CSS et sans que l’intégration ne devienne non-sensique, pourquoi s’en priver ?

Le meilleur moyen de ne pas faire de casse sur une CSS est parfois de s’abstenir d’y toucher.

Cela peut sembler extrême, mais certains cas s’y prêtent très bien. Par exemple, si vous avez des classes atomiques à disposition dans votre CSS qui vous permettent de créer la mise en forme souhaitée, vous pouvez mettre en forme de nouveaux contenus aisément. Pour ma part, si j’utilise des styles atomiques, ce n’est pas juste pour faire joli, parce qu’un blogueur influent l’a dit ou par fainéantise : c’est bien pour éviter de revenir complètement sur une intégration si je peux le faire.

Autre cas de figure – j’anticipe un peu le prochain article –, concevoir votre site en modules bien distincts peut également vous permettre d’effectuer des changements importants sur la structure sans pour autant revenir sur la CSS : pour peu que vous utilisez le flux correctement et que vous appliquiez les principes évoqués dans « penser en dehors de la boîte », vous vous surprendrez parfois à ne rien toucher à la CSS en enlevant complètement un pan de la structure !

Revenir sans faire de casse

Cela peut sembler assez facile, il suffit de ne pas toucher à ce qui existe et de rajouter les classes nécessaires. Seulement, vous connaissez sûrement le résultat si cette méthode est utilisée à tort et à travers : la CSS va enfler. Pour peu que les divers intervenants ne soient pas très attentionnés, le règne du désordre va vite reprendre le dessus.

En général, trois cas de figure sont possibles en maintenance :

  • il manque une classe atomique ;
  • un objet ou un module nécessite un cas particulier ;
  • un objet ou un module nécessite un ajustement global.

J’élude volontairement le cas où il faut coder quelque chose de complètement nouveau, ce dernier ne posant normalement pas de problème particulier.

Classe atomique manquante

Soit c’est une classe atomique qui manque pour pouvoir construire quelque chose : il suffira de la rajouter dans la section concernée. Les classes atomiques ont l’immense avantage de ne pas casser l’existant, de par leur définition.

Un exemple : j’utilise souvent le modèle tabulaire avec des classes comme :

.row {
 display: table;
 table-layout: fixed;
}
.col {
 display: table-cell;
 vertical-align: top;
}
.aligncenter { text-align: center; }

Lequel me permet aisément de mettre des contenus côte à côte, et de les centrer. Sur un site, on m’a demandé de mettre deux contenus côte à côte, mais dont l’un devait être aligné en bas de la cellule. Avec les classes que j’avais à disposition, je ne pouvais pas le faire. Comme cette demande était assez simple, il m’a suffit de créer les deux classes atomiques suivantes :

.col-noalign {
 display: table-cell;
}
.alignbottom { vertical-align: bottom; }

Ces dernières ont eu un poids supplémentaire négligeable sur la feuille de style, et m’ont permis de répondre à la demande. Qui plus est, elles sont réutilisables (et ont été réutilisées d’ailleurs :)) ).

Ajustement particulier d’un objet/module

Si un objet qui subit une variation ponctuelle (pour un cas particulier), dans ce cas, on préfèrera se baser sur l’objet existant et le dupliquer en modifiant juste le nécessaire. Dans ce cas, une bonne factorisation et un ordre adéquat vous permettront de le faire proprement. Si vous êtes adepte de la convention BEM avec un pré-processeur, vous étendrez (@extend) votre objet avec un modifier.

.mon-objet,
.mon-objet--modifieur {
/* ici les propriétés standards de l'objet/module */
}
.mon-objet--modifieur {
/* ici les propriétés particulières */
}

Ajustement global d’un objet/module

Si c’est un objet/module qui subit une modification globale : on ne changera que le strict nécessaire pour le mettre à jour, en ayant toujours à l’esprit d’isoler le plus possible les changements, pour éviter des modifications trop globales (risque de dégâts collatéraux) ou trop spécifiques (risque de portée insuffisante des modifications).

Si vous appliquez les principes de OOCSS, normalement vous séparez le positionnement d’un module de son design : cela vous rendra service pour limiter la portée des modifications que je viens d’évoquer.

Idéalement, si l’on peut se baser sur les motifs déjà existants et déjà éprouvés par les tests, cela limitera le temps pour mettre à jour (tests, etc.).

Bien entendu, ce n’est pas toujours possible, il est parfois nécessaire de revenir complètement sur une partie de l’intégration, et cet article n’est pas là pour dire qu’il ne faut pas le faire : un refactoring est parfois souhaitable et même nécessaire. Toutefois, si cela peut être évité sans que la CSS n’en pâtisse, autant se faciliter la tâche sourire.

Conclusion

Si vous appréciez le sujet de la thermodynamique, on peut faire une analogie : globalement, l’idée est d’éviter d’augmenter trop rapidement l’entropie de la feuille de styles, l’entropie pouvant être considérée comme une mesure du degré de désordre. sourire

J’avais déjà indiqué que cette série d’articles était à voir comme un tout cohérent, cette problématique de revenir sur une feuille de style en faisant le moins possible d’efforts et de casse en est le parfait exemple. Ce travail se prépare avant même de commencer une CSS, et les bénéfices ne viendront que plus tard. Mais soyez assurés que quand vous serez confrontés à ce genre de problèmes, le travail en amont portera ses fruits et vous en serez très content !

Références, compléments

Note

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

À propos de cet article

  • Openweb.eu.org
  • Profil : Débutant, Expert
  • Technologie : CSS
  • Thème : Méthodes
  • Auteur :
  • Publié le :
  • Mise à jour : 31 juillet 2014
  • 2 commentaires

Vos commentaires

  • JulienW Le 28 mars 2015 à 22:35

    Ptite question pour la partie "Ajustement particulier d’un objet/module".

    Je ne comprends pas pourquoi tu as le sélecteur ".mon-objet—modifieur" dans la partie "propriétés standards". Comme je le comprends, cette classe sera ajoutée _en plus_ de la classe ".mon-objet" et dès lors il n’y a pas besoin d’avoir le sélecteur du modifieur pour la partie standards à mon avis.

  • Nicolas Hoffmann Le 30 mars 2015 à 13:38

    @Julien : question de point de vue, certains préfèrent mettre deux classes sur l’élément (standard + modifier), d’autres préfèrent étendre .mon-objet (un extend avec un pré-processeur).

    Y a pas de bonne ou mauvaise façon de faire, les goûts et les couleurs sourire

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom