Des approches en vogue confrontées aux principes

Openweb.eu.org > Articles  > Des approches en vogue confrontées aux principes

Abstract

Après avoir posé – huit articles durant – les principes modernes de construction des feuilles de styles, Nicolas Hoffmann vous propose d’y confronter diverses méthodes en vogue pour la conception de CSS.

Accrochez-vous, l’avant-dernier article de cette série ne manque pas de densité !

Article

Maintenant que nous avons posé les principes modernes de construction des CSS durant cette série d’articles, nous allons y confronter des approches en vogue. Rappelons-nous ces principes :

  • Du plus général au plus spécifique
  • Séparation structure/présentation autant que possible
  • Orthogonalité
  • Possibilité de prendre des conventions
  • Possibilité de produire des guides de styles
  • Poids réduit
  • Sélecteurs efficaces
  • Sélecteurs qualifiants
  • Possibilité de penser en-dehors de la boîte
  • Approche DRY
  • Évite d’y revenir

Rajoutons quelques bonus :

  • Tire parti des outils comme les pré-processeurs
  • Capacité à aider à travailler depuis plusieurs postes (intégration, graphisme, développement, etc.)

Des approches en vogue

Cinq méthodes/approches vont être passées au crible : l’intégration classique, SMACSS, OOCSS, la méthode Daisy et BEM.

L’intégration classique

Nous aurions bien pu l’appeler « l’intégration à Papa », toutefois, le terme « intégration classique » sera moins irrévérencieux sourire.

Ses principes sont connus de tous, et nous n’avons pas mâché nos efforts ici-même pour les disséminer. Ce sont tout simplement la stricte utilisation des concepts de base de l’intégration :

  • séparation structure/présentation ;
  • un élément unique est signalé par un id, via une class s’il n’est pas unique ;
  • ils sont stylés d’après leurs id/class ;
  • on tire parti de la cascade autant que possible.

Confrontons l’intégration classique face aux principes d’intégration moderne !

Principes et commentaires sur l’intégration classique
Principes Commentaires
Du plus général au plus spécifique Très bon : c’est un des principes de la méthode.
Séparation structure/présentation autant que possible Moyen : c’est un des principes de la méthode, mais curieusement, elle ne favorise pas le découplage structure/présentation.
Orthogonalité Non applicable : ni favorisé, ni empêché.
Possibilité de prendre des conventions Plutôt bon : c’est la méthode la plus basique qui soit, donc elle est de facto compréhensible et n’empêche pas de prendre des conventions.
Possibilité de produire des guides de styles Non applicable : ni favorisé, ni empêché.
Poids réduit Dépend du contexte : on parle de relation 1:1, la CSS grossit proportionnellement au site. Plutôt bon sur les petits sites, très mauvais sur des sites plus volumineux.
Sélecteurs efficaces Moyen : tirer trop parti de la cascade produit des sélecteurs peu efficaces.
Sélecteurs qualifiants Moyen/bon : pour peu qu’on se limite sur la cascade, les sélecteurs peuvent être plutôt bien qualifiants.
Possibilité de penser en-dehors de la boîte Moyen : le manque de séparation présentation/positionnement peut vite être handicapant.
Approche DRY Mauvais : confrontée à beaucoup de maintenance, l’approche DRY n’est pas facilitée, toujours à cause de la relation 1:1.
Évite d’y revenir Mauvais : la relation 1:1 implique de très souvent revenir pour ajouter des classes, etc.
Tire parti des pré-processeurs Moyen : la production peut en bénéficier, mais elle ne va pas tirer leur plein potentiel.
Travail entre intervenants Non applicable : jusqu’à preuve du contraire, elle ne l’a pas empêché sinon nous ne serions pas là pour en parler. sourire

Le tableau est sans appel : cette méthode pose des problèmes. Si vous n’en êtes pas convaincu, vous pouvez lire ou relire « CSS, l’âge de raison ».

Remarque : utiliser cette méthode n’est pas une erreur en soi et n’empêchera fondamentalement pas un site de fonctionner. Les limites viendront plutôt avec une forte maintenance, du fait de son manque de souplesse.

SMACSS

SMACSS pour Scalable and Modular Approach for CSS a été imaginée par Jonathan Snook. Comme son nom l’indique, cette méthode a été pensée spécialement pour produire des CSS qui « scalent » le mieux possible.

Selon cette méthode, Il existe cinq catégories de règles :

  • la base : les resets, normalisations, etc. ;
  • le layout global : la présentation globale du site (les grands ensembles) ;
  • les modules : les parties autonomes qui peuvent être réutilisées ;
  • les états : les différents états d’un module (ex : un menu ouvert/fermé, liens actif/survolé, etc.) ;
  • les thèmes : si votre projet contient plusieurs designs (forum, webmail, etc.).

Les principes sont les suivants :

  • Catégoriser les règles comme ci-dessus ;
  • Limiter la profondeur d’application des styles (éviter des styles qui s’appliquent trop profondément et qui génèrent des effets de bords hasardeux) et découpler la structure de la présentation ;
  • Travailler la performance des sélecteurs.

Confrontons SMACSS à nos principes !

Principes et commentaires sur SMACSS
Principes Commentaires
Du plus général au plus spécifique Très bon : les règles invitent à fonctionner ainsi.
Séparation structure/présentation autant que possible Très bon : SMACSS s’y prête bien également.
Orthogonalité Très bon : les classes d’état permettent de favoriser/faciliter l’orthogonalité.
Possibilité de prendre des conventions Plutôt bon : les principes de SMACSS se marient très bien avec la prise de conventions.
Possibilité de produire des guides de styles Très bon : les catégorisations, les modules, les états invitent à bien décrire les éléments réutilisables.
Poids réduit Très bon : comme son nom l’indique, SMACSS gère cela très bien.
Sélecteurs efficaces Plutôt bon : SMACSS invite à y prêter attention, en indiquant de ne pas y perdre non plus trop de temps.
Sélecteurs qualifiants Plutôt bon : SSMACSS conseille explicitement d’avoir des sélecteurs qualifiants à droite de vos sélecteurs CSS.
Possibilité de penser en-dehors de la boîte Plutôt bon : certains aspects comme les règles d’états et les modules le favorisent.
Approche DRY Plutôt bon : encore une fois, penser en modules invite à réutiliser, et donc à ne pas se répéter.
Évite d’y revenir Plutôt bon : l’approche modulaire est censée permettre une relation 1:n : un élément de la CSS pour n éléments du contenu.
Tire parti des pré-processeurs Plutôt bon : l’approche se marie bien avec les pré-processeurs.
Travail entre intervenants Plutôt bon : la modularisation permet de simplifier la discussion entre divers intervenants.

Le constat est sans appel : SMACSS répond également bien à des problématiques d’intégration modernes. Cette approche est particulièrement adaptée sur des applications ou des sites à visée applicative.

OOCSS

Les CSS orientées objet ont été imaginées par Nicole Sullivan. Ses constats étaient les suivants :

  • les CSS prenaient trop de poids ;
  • la réutilisation du code était quasi-inexistante : on parle de relation 1:1 => la CSS grossit proportionnellement au site ;
  • le code est trop peu robuste, car trop couplé à la structure.

Les deux principes de base d’OOCSS sont les suivants :

  • séparer la structure de l’apparence ;
  • séparer le contenu du contenant.

L’idée est de créer une bibliothèque de composants, tous réutilisables à souhait. Ces composants deviennent donc des objets. Cela peut aller de simples boutons jusqu’à des objets comme une nouvelle sur un blog (titre, date, corps, etc.).

De bonnes et mauvaises pratiques découlent de cette approche, vous pouvez les consulter sur cet article : « Plongée au cœur de l’OOCSS ».

Confrontons OOCSS à nos principes d’intégration modernes !

Principes et commentaires sur OOCSS
Principes Commentaires
Du plus général au plus spécifique Plutôt bon : même si ce n’est pas expressément expliqué dans la méthode, l’approche objet invite à penser global puis spécifique.
Séparation structure/présentation autant que possible Très bon : c’est un des principes de la méthode.
Orthogonalité Non applicable : ni favorisé, ni empêché.
Possibilité de prendre des conventions Plutôt bon : les principes d’OOCSS sont tout à fait compatibles avec des prises de conventions.
Possibilité de produire des guides de styles Très bon : OOCSS force à créer des objets/bibliothèques, les guides de style en tireront parti.
Poids réduit Dépend du contexte : sur de petits sites, le bénéfice sera léger voir inexistant. Il sera par contre conséquent sur les sites plus volumineux.
Sélecteurs efficaces Très bon : OOCSS invite à cibler précisément et à minimiser les sélecteurs.
Sélecteurs qualifiants Très bon : pour les mêmes raisons que pour les sélecteurs efficaces.
Possibilité de penser en-dehors de la boîte Très bon : les principes de la méthode le favorisent fortement.
Approche DRY Très bon : les principes de la méthode le favorisent également.
Évite d’y revenir Très bon à long terme : à terme, la relation 1:n doit permettre de ne plus revenir dans la CSS.
Tire parti des pré-processeurs Très bon : penser en objet permet de bien tirer parti des extend pour les étendre, les reprendre, etc.
Travail entre intervenants Plutôt bon : penser en objets force à synthétiser.

Le tableau récapitulatif est parlant : OOCSS est robuste et répond à de nombreuses problématiques des sites modernes. Ses seuls « défauts » sont d’être souvent vue à tort comme un bazooka lourd à manier sur de petits sites, et d’avoir une petite tendance à générer beaucoup de classes sur la structure.

Reste encore à définir les « petits » sites : avec la démocratisation du responsive, n’importe quelle intégration peut être vite pointue. Quand au nombre de classes, est-ce vraiment un drame ? Il est raisonnable d’en douter fortement.

D’autres approches intéressantes

La méthode Daisy

La méthode Daisy a été pensée par Romy Duhem-Verdiere. Elle est partie du postulat que CSS est souvent un joyeux bazar et que les productions de CSS étaient trop artisanales. Elle en a déduit de grands ensembles savamment ordonnés (resets, typographie, layout, grid, etc.) afin de :

  • penser plus modulaire, plus adaptable et plus réutilisable ;
  • capitaliser sur l’existant ;
  • permettre du travail collaboratif et l’inclusion de styles imposés par des composantes du projet (CMS, plugins, etc.).

Comme cette méthode est plus une méthode d’organisation que d’approche pure de conception des CSS, la confronter directement à tous les principes n’est pas pertinent : plusieurs sont non-applicables. Par exemple la méthode peut très bien se marier avec des pré-processeurs et très bien fonctionner sans.

Les points forts de cette approche sont les suivants :

  • le travail en équipe est particulièrement facilité ;
  • la prise en compte de styles propres aux CMS a également été bien pensée ;
  • la décomposition de chaque ensemble (typographie, etc.) est très fine, ce qui permet un rangement très pointu et très efficace des règles.

Cette méthode se marie très bien avec d’autres préceptes des autres méthodes, ce qui en fait un terreau fertile, si j’ose dire (« daisy » veut dire Marguerite en anglais).

À noter, les problématiques de cohabitation avec des CMS grincheux (comprenez qui imposent des styles) a été bien pensée. En résulte une approche pouvant même se diviser sur plusieurs postes différents, et permettre à l’intégration de se marier mieux avec des contraintes purement CMS-iennes.

Assurément, la méthode Daisy répond à de grosses problématiques d’intégration.

BEM

BEM signifie Block Element Modifier. Cette méthode a été élaborée par Yandex et publiée en 2010. Elle se décompose en deux points :

  • Produire une structure globale en identifiant les blocs principaux d’une page ou d’une application (ce qu’on appelle l’arbre BEM) ;
  • et offrir une convention de nommage, qui a d’ailleurs rencontré une certaine popularité.

Un bloc est une entité indépendante des autres, un élément est un constituant d’un bloc et un modifieur permet d’indiquer une variation d’un bloc ou d’un élément (un cas particulier, etc.). Exemple :

.blog-billet {
/* un bloc : un billet d'un blog */
}
.blog-billet__titre {
/* un élément d'un billet : le titre */
}
.blog-billet__titre--breaking {
/* un modifieur : un titre d'un billet important */
}

Les points forts de cette méthode :

  • le découplage structure/styles est plutôt aisé ;
  • l’information véhiculée par cette convention est pratique et aide bien à la compréhension ;
  • les sélecteurs sont efficaces et qualifiants ;
  • la ré-utilisabilité est plutôt favorisée ;
  • la méthode se marie très bien avec les pré-processeurs.

BEM est devenue rapidement populaire, le seul reproche qui lui est couramment fait est d’être parfois… trop verbeuse.

Conclusion

Comme attendu, chaque méthode a ses forces et ses faiblesses. Il est aisé de comprendre qu’au-delà des effets de mode, certaines tirent leur épingle du jeu : en les confrontant aux grands principes d’intégration moderne, les résultats sont éloquents.

Typiquement, ces méthodes sont des efforts d’industrialisation qu’il serait bien regrettable d’ignorer. Et libre à vous de prendre ce dont vous avez besoin dans chacune, mais cela, nous l’aborderons dans le prochain et dernier article !

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 : Expert, Gourou
  • Technologie : CSS
  • Thème : Méthodes
  • Auteur :
  • Publié le :
  • Mise à jour : 12 novembre 2014
  • 7 commentaires

Vos commentaires

  • Gaël Poupard Le 12 novembre 2014 à 11:41

    Très bon article, merci Nicolas sourire

    L’angle est très pertinent mais il manque - à mon avis - une dimension importante pour comparer ces approches : leurs liens mutuels.

    Par exemple, OOCSS est né du constat d’échec de « l’intégration classique », et est une réponse excessive à cet échec. C’est notamment de cette réaction allergique à la méthode classique que vient la règle absurde du « Zéro ID dans vos CSS », qui s’entendait lorsque Nicole Sullivan a travaillé sur un ensemble de portails web incluant des centaines de milliers de lignes de CSS, mais n’a jamais été valable à une autre échelle.

    Ce lien entre les méthodologies me semble extrêmement pertinent puisqu’on peut mettre en perspective les différents choix qui ont été faits par leurs concepteurs respectifs. Chaque contexte de travail a des priorités : séparation du fond et de la forme, poids des fichiers finaux, lisibilité et organisation des fichiers, etc. Il ne s’agit pas d’une préférence d’environnement de travail mais bel et bien d’adaptation à un contexte projet.

    Permuter d’une méthodologie à l’autre en fonction du projet en cours peut parfois être indispensable, et c’est une qualité qu’un bon intégrateur devrait avoir. Mais on va encore me traiter d’extrémiste langue tirée

  • Nicolas Hoffmann Le 12 novembre 2014 à 14:17

    @Gaël : certes !

    Tu auras noté la longueur dudit article : je ne voulais pas en remettre encore une couche supplémentaire en (ré-)écrivant l’histoire (et les commentaires, c’est bien pour ce genre de précisions).

    En fait, quand j’ai déblayé le terrain pour cet article, je me suis re-plongé dans toutes ces ressources, et ce qui m’a frappé, c’est que les théories de base ont de grosses différences avec l’interprétation « au bazooka » qui en a été faite ensuite. Typiquement, si tu relis SMACSS, il n’interdit nulle part les id, il les déconseille juste.

    Sur OOCSS, tout le monde s’est arrêté sur le côté profusion de classes, alors qu’en utilisant correctement le contexte, on peut faire de l’OOCSS sans même le savoir, comme M. Jourdain qui faisait de la prose. J’ai coutume de dire que je fais de l’OOCSS vite-fait-bien-fait quand j’utilise un helper pour amener le positionnement qu’il me manque à un module.

    Je vais même te dire, même si ça anticipe sur le dernier article : la finalité n’est pas dans le switch entre telle ou telle méthode, mais dans l’appropriation de leurs avantages respectifs. Pour ma part, il y a un peu de tout dans ma façon d’intégrer :

    - du Daisy côté rangement ;
    - de l’OOCSS comme indiqué ci-dessus ;
    - les règles d’état de SMACSS sont très pratiques (et là, je commence à beaucoup utiliser ARIA pour faire le pont entre JS et CSS) ;
    - et BEM a un côté pratique pour les modules.

    En gros, du SMOOACSSEMSY.

  • Gaël Poupard Le 12 novembre 2014 à 14:25

    Ah ben tout pareil sourire

    Ça me fait également rapprocher le récent article de Raphaël Goetter sur la bonne utilisation des frameworks CSS !

    La radicalité n’est jamais une solution viable.

  • Mélado Le 16 novembre 2014 à 23:02

    Ce qui serait intéressant, c’est aussi de voir quelle logique adopent les frameworks css populaires comme bootstrap, knacss et les autres.

    Ca permettrait d’orienter le choix du framework en fonction de la manière dont on préfère coder, quand on voudra étendre et personnaliser le framework...

  • Nicolas Hoffmann Le 17 novembre 2014 à 14:35

    Effectivement, ce serait intéressant. Pour ma part, Röcssti est clairement basé sur ces principes (et suffisamment customisable pour le faire si ça n’est pas le cas). Sans trop m’avancer, je suppose que KNACSS le permet aussi.

    Pour les autres frameworks comme Bootstrap, là je ne le connais pas assez.

  • Fred le manchot Le 14 décembre 2014 à 21:55

    Encore une série d’article vraiment très intéressante... j’attends le dernier article avec impatience.
    Contrairement à beaucoup d’entre vous et de personnes qui laissent des commentaires, j’ai encore beaucoup de mal à voir de l’intérêt avec toutes ces "nouveautés" de OOCSS, KNACSS, SMACSS & co....
    Je me documente pourtant dessus... autant je vois vraiment de l’intérêt sur des règles simples comme Röcssti (au depart car apparemment il a bcp évolué et je ne suis pas allé récemment voir les modifications), Boiterplate et autres... mais avec les sascss & consort.
    Je ne suis qu’un petit développeur de sites persos qui fait cela par loisir et c’est peut être pour cela que j’ai du mal avec tout ceci.
    D’un coté je comprends très bien l’intérêt dans les différents articles mais je n’arrive pas à le mettre en application malgré les évolutions que j’essaie d’appliquer en rendant mes sites en responsive design.
    Je n’ai peut être pas la bonne méthode et l’impression donc que ça me complexifie plus mes développement qu’autre chose....

    C’était un avis personnel, qui dérive peut être un petit peu du sujet, si vous avez des conseils ou autres je suis preneur, dans tous les ces articles malgré tout son très intéressant pour une personne comme moi

    a+

    Fred le manchot

  • Nicolas Hoffmann Le 15 décembre 2014 à 10:49

    Ces « nouveautés » sont là pour résoudre des problèmes de maintenance/qualité/complexité à plus ou moins long terme sur la vie d’un projet. Effectivement, ce sont des méthodes professionnelles, peut-être un peu difficiles à appréhender pour vous si vous pratiquez cela en loisir.

    Comme je l’ai indiqué plus haut, utiliser des méthodes « classiques » n’est pas une erreur en soi. Cela ne vous empêchera jamais de faire des sites.

    Par contre, en tant que professionnel, je peux vous certifier que cela me permet de gérer des projets qui seraient proprement ingérables sans avoir toutes ces méthodes et ces conseils. sourire

    Imaginez-vous un site en 10 langues (tant qu’à faire avec une qui se lit de droite à gauche comme l’Arabe histoire que ça soit rigolo), qui doit fonctionner en responsive (et même en mobile-first tant qu’à faire), être et rester performant, si possible avec plein d’intervenants, etc. si vous n’avez pas des conventions, une méthodo en béton armé, ça finira par partir en sucette, croyez-moi sur parole ! grand 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