Organiser ses feuilles de style CSS

Rigueur. Et passion !

Ne dites pas à ma mère que je suis artisan en architecture de l'information appliquée aux sites web : elle croit que je suis webdesigner, intégrateur HTML & CSS, rédacteur web, formateur NTIC et consultant en webmarketing depuis 2001 ! Voulez-vous en savoir plus ?

Le blog de l'intégrateur web

Organiser ses feuilles de style CSS

Organiser ses feuilles de style CSS J’ai regardé l’organisation des CSS dans de nombreux CMS, de Dotclear à WordPress en passant par des plate-formes de e-commerce. Il n’y a pas deux feuilles de style qui partagent la même organisation, exceptée la remise à zéro du padding et du margin via le sélecteur universel ou seulement pour les éléments html et body, ou encore le choix de la police de caractère (famille, taille, interlignage et couleur du texte) pour le seul élément body. Certaines commencent par la structure pour finir avec les éléments html quand d’autres mettent les déclarations dans l’ordre alphabétique…

Comment ça ? Alors que tout le monde utilise une méthode similaire pour réaliser un menu horizontal en transformant les liens en bloc pour leur donner une taille et en faisant flotter les éléments de listes, il n’existe pas de consensus sur l’organisation des feuilles de style CSS ?

Un peu d’organisation ne fait pas de mal

Après quelques recherches, certaines approches semblent néanmoins faire des adeptes.

  1. L’une d’elles consiste à séparer les propriétés typographiques du positionnement, lui-même divisé en plusieurs parties comme header, middle et footer par exemple.
  2. Une variante consiste à ajouter une partie par grande famille d’éléments : liens, listes, images, formulaires, etc.
  3. Dans le même esprit, erracticwisdom divise la feuille de style en commençant par les élément globaux, continue avec la structure puis finit avec les titres, les styles de texte, la navigation, etc. Rien de bien nouveau me direz-vous, si ce n’est qu’il propose, pour chaque partie, d’indenter les règles CSS. A ce propos, NubiumGraphik propose une astuce pratique pour indenter les CSS à l’image du code HTML à coup de chercher-remplacer.
  4. Pour structurer des gros fichiers CSS, Emil Stenström s’applique à mettre les sélecteurs dans l’ordre où ils apparaissent dans le HTML, indente aussi son code, met chaque déclaration sur sa propre ligne dans l’ordre alphabétique, et utilise toujours le chemin complet pour atteindre un élément donné #content p strong { … }.
  5. Quelque soit la structure de votre CSS usez et abusez des astuces d’écriture des règles CSS pour vos déclarations. Ca change la vie, vraiment ;)
  6. Pour terminer ce florilège je vous conseille la lecture du billet paru dernièrement sur biologeek Des CSS de qualité qui fournit des idées et des liens concernant les feuilles de style tout en donnant un exemple concret reprenant : le principe de remise à zéro des éléments mise au point par Eric Meyer ainsi que l’indentation systématique chère aux programmeurs.

Et moi et moi et moi…

Quand je regarde ma propre pratique, je m’aperçois que j’ai pris quelques habitudes perfectibles : je commence souvent par la structure. Je mets en place le gabarit avec son cortège de container, de main, de sidebar, de footer.

J’ai longtemps utilisé la remise à zéro de tous les éléments via le sélecteur universel… * {margin: 0; padding: 0} mais le reset-reloaded semble bien plus complet et mieux maitrisable. Et si David Larlet l’utilise alors nous le pouvons tous ;)

Une fois la maquette en place, je mets l’ensemble dans un fichier indépendant appelé dans styles.css avec @import url(layout.css). En général, une fois calée, la structure globale ne change pas à condition de ne mettre que l’essentiel. Par exemple, dans un design à largeur fixe, certaines valeurs de margin et de padding seront des éléments structurels, tandis que dans un design fluide, ces valeurs pourront être modifiées sans casser le design et trouveront leur place ailleurs.

Le fichier layout.css terminé, je redéfinis les éléments HTML. Si la structure sémantique du document est bien respectée et si les différents niveaux de titres partagent les mêmes caractéristiques sur l’ensemble du site, je définis toutes les propriétés ici dans ce fichier html.css, autrement je me concentre sur les marges et je m’occupe des éléments typographiques dans la feuille principale styles.css.

Reste ensuite à styler tout le reste. Pour cela, je respecte l’ordre d’apparition des identifiants et des classes dans le code html pour construire ma feuille styles.css et je termine par une partie toolbox où je définis quelques classes récurrentes tels que .floatleft {float: left} ou .clearer {clear: both}.

Pour finir, je fais une relecture de ma feuille de style et je regarde ce qui peut être factorisé, mieux organisé, un peu comme pour un texte. Au début j’en mets des tonnes pour alléger après en ne gardant que l’essentiel.

C’est plutôt empirique et ça fonctionne bien… Du moins pour ce qui concerne les sites où les gabarits sont peu nombreux, car lorsque ce n’est pas le cas, le fichier styles.css peut vite devenir ingérable et mieux vaut se tourner vers des méthodes d’organisation complémentaires.

Organiser les CSS pour les gros sites

Pour faire face à cette situation, il existe plusieurs approches pour lesquels je me limiterais à vous fournir quelques liens. Il n’est déjà pas facile de se mettre d’accord sur l’organisation des CSS concernant un site relativement simple, alors vous pensez bien qu’il n’y a pas de recette pour les cas complexes. Et puis en même temps, si vous avez hérité d’un cas compliqué, c’est que vous le valez bien…

C’est certainement le cas pour GouBlog qui doit jongler avec des fichiers CSS multiples dans le cadre de sites complexes où de nombreuses personnes travaillent ensemble.

Quand vous créez des feuilles de style un peu complexe, pensez à Dave Shea, l’auteur de CSS Zen Garden, qui a évoqué la question sous l’angle de la redondance vs dépendance concenant les déclarations CSS. L’article de Garret Dimon sur l’architecture des CSS paru sur Digital Web est également intéressant à lire, d’autant plus qu’une version française existe !

Pour aller plus loin

Il n’y a pas de recette miracle pour structurer ses CSS ; juste une foule de détails à prendre en compte pour construire des feuilles de style solides résistant à l’épreuve de la maintenance. Si je ne devais citer qu’une source pour avoir sous la main les dernières techniques CSS dont on parle dans les salons, ce serait smashing magazine avec notamment des articles comme 53 CSS-Techniques You Couldn’t Live Without ou 70 Expert Ideas For Better CSS Coding.

Voilà, si vous êtes arrivés jusqu’ici, profitez-en pour lâcher votre site incontournable sur les CSS dans les commentaires ;)

Articles sur le même sujet

PS : Le respect de la vie privée sur internet est important : j'ai décidé d'échanger mon bouton Like de Facebook par un bouton Faire un don de Paypal car
Il n'y pas d'amour, il n'y a que des preuves d'amour (Jean Cocteau) ;) Merci d'avance.



21 commentaires pour “Organiser ses feuilles de style CSS”

  1. > Et si David Larlet l’utilise alors nous le pouvons tous ;)

    Huhuhu.

    Merci pour les liens… et tout ce qu’il y a autour :-)

  2. ZeuBeuBei dit :

    Scrogneugneu, DC ou WP ne sont pas des CMS mais des systèmes de blog ! Après il y a des gens qui croient pouvoir réaliser des sites "classiques" avec :'(

    Le problème des css est qu’il peut y avoir plusieurs intervenants sur les fichiers comme les webdesigners et développeurs par exemple. Certaines feignasses utilisent aussi des outils genre :

    cdburnerxp.se/cssparse/cs…

  3. clem dit :

    Si dotclear et wordpress ne sont pas des système de gestion de contenu ( cms … ) qu’on me coupe la main !

    Pour les gros sites, il y a des gros efforts à faire sur une charte de nommage des différentes feuille de style mais aussi sur les commentaires et l’ordre des données.

  4. ZeuBeuBeu dit :

    Mouais je ne suis pas d’accord avec toi, quand tu vois que certains veulent faire des vrais sites corporates avec ou bien du e-commerce tu commences à rigoler quand même. Je fais partie de la dev team de DC et je peux t’assurer que c’est fait pour gérer du blog et basta (modulo une poignée de pages statiques genre infos légales et tout le toutim).

  5. Tu fais pas des formations XHTML/CSS pour blogueurs lyonnais ? Nan parceque je suis preneur :)

  6. br1o dit :

    David > Tout le plaisir est pour moi :) Zeubeubeu > Je crois comprendre ce que tu veux dire quand tu ne veux pas que l’on qualifie les systèmes de blog de CMS : la confusion engendre l’incompréhension qui provoque des malentendus, et le support utilisateur en souffre parfois, j’ai bon ? ;) Mais c’est la nature humaine qui veut ça : lorsque un système est bien fait pour une chose on a tendance à vouloir l’utiliser pour une autre, et ainsi de suite. Beaucoup de personnes qui pourraient utiliser Joomla pour gérer un site corporate léger préfèrent la simplificité d’un système de blog. Et quand tu dois expliquer le fonctionnement d’une interface à quelqu’un qui ne connait que Word OpenOffice, tu comprends vite pourquoi les blogs sont parfois détournés de leur fonction première ;) Clem > C’est clair qu’il y a du travail pour mettre un peu d’ordre dans les CSS, notamment pour les gros projets. Mais j’ai tendance à penser que le plus important est peut-être de s’occuper du xhtml avant : ça ne sert à rien d’avoir des belles CSS sur un code bancal ;) Jean Bernard La Mouette > On en parle ce soir à l’apéro ? :)

  7. Rémi dit :

    Alors moi c’est plus compliqué (trop?), en résumé :

    • Un fichier structure.css qui contient toute la structure des pages;
    • La même chose mais dédiée à IE6 structure_Ie.css pour pouvoir s’adapter aux caprices d’IE;
    • Ensuite, ce qui est commun aux deux et à la charte graphique du site skinDefault.css, on y trouve les éléments de typo, de background, de couleurs et tout ça. Et enfin, last but not least, une feuille de style dédiée à chaque navigateur si besoin pour s’adapter aux petites différences de chacun speciale_opera.css, speciale_Ie7.css, speciale_safari.css, etc.

      Alors sois je code comme un sagouin, ou bien je suis le seul à ne pas supporter les hacks css ?

      Et sinon, pour structurer le fichier css, il est divisé en plusieurs parties :

    • un sommaire (je bosse sur de très gros projets :P)
    • squelette du site (taille des headers, containers, footer, menus)
    • une partie common qui rassemble les classes récurrentes (formulaires, bordures d’image, blocs, etc.)
    • le header
    • le footer
    • la partie secondaire (colonne droite souvent)
    • et enfin la partie Pages (la plus longue avec le css relatif à toutes les pages)

      Le tout bien sur joliment commenté et indenté pour pouvoir mieux s’y retrouver (et les deux css principales structure.css et structure_Ie.css) ordonnées de la même façon graçe à l’indispensable CompareIT

      :)

  8. Rémi dit :

    avec bien sur le p’tit javascript associé pour detecter le navigateur et sa version pour lui donner les bonnes css ^^

  9. br1o dit :

    Rémi > ton histoire de javascript pour détecter le navigateur me fais penser que j’ai complètement zappé la question des commentaires conditionnels (pour filtrer Internet Explorer) que j’utilise systématiquement dans mes CSS. Je vais certainement rajouter un paragraphe sur le sujet ;)

  10. k-ny dit :

    Allez hop, rss direct dans mon google reader :)

    Thanks ;)

  11. PêUR dit :

    L’article et le débat qui manquait!

    Merci pour le lien :)

    PS: J’aimerais tant changer mon gravatar (le site est en rade) pour être homogène partout… Tu veux pas mettre les avatars de MyBlogLog plutôt ;) Bizet’s blog en parle: http://www.bizetfamily.net/index...

  12. br1o dit :

    k-ny > idem, j’suis déjà fan : joli design, contenu intéressant ! A bientôt :)

    PêUR > j’ai jeté un oeil sur le blog de bizet, mais ce genre de changement risque de ne pas plaire à tout le monde ^^ A méditer pendant quelques mois, amha :p

  13. Aguillem dit :

    Encore un article réalisé avec Brio par Br1o ;) Je vois en fait que j’utilise la majorité de ces "bonnes pratiques", mis à part l’indentation que j’ai redécouvert il y a peu avec l’article de David. Si tu le permets, je ferais un petit billet pointant vers ton billet que je glisserais dans ma catégorie "Bonnes pratiques". C’est bien expliqué et complet alors je n’ai aucun interet à recommencer ;)

  14. teknofil dit :

    Merci pour cet article intéressant ! Je pense que chacun organise sa (ou ses) feuille(s) de style de manière personnalisée afin de s’y retrouver au mieux, surtout quand on bosse seul. Le problème n’est pas le même quand on travaille en équipe ;)

  15. PêUR dit :

    Tu as raison, c’était plus pour le lien intéressant qu’une réèlle supposition… d’autant que j’ai enfin mis à jour mon gravatar ;)

  16. Martin dit :

    Si durant la phase de développement, l’organisation d’une feuille de style et son découpage en plusieurs morceaux importe peu, au moment du déploiement sur le site final, il est bon de réaliser quelques optimisations purement techniques.

    Ainsi, réduire la quantité d’éléments externes nécessaires à l’affichage d’une page correctement permet d’en accélérer l’affichage. En effet, comme le montre cette petite démonstration théorique :

    http://www.die.net/musings/page_...

    les échanges par protocole HTTP nécessitent environ 500 octets, ce qui augmente de manière très sensible la taille des très petits éléments (comme un bout de CSS inclus par un autre CSS). De plus, Internet Explorer ne permet de charger que deux éléments à la fois depuis un même hôte. Avec quatre feuilles de styles incluses les unes dans les autres, les temps de chargement, ou du moins d’apparition de la page sous les yeux du visiteurs, peuvent augmenter de manière très significative.

    Une solution, sur un site à base de WordPress notamment, est d’utiliser un système tel que le "Inlined CSS / JavaScript WP Plugin" :

    elliottback.com/wp/archiv…

  17. br1o dit :

    Martin > Je pensais naïvement lire le lien die.net et revenir vers toi rapidement, mais la lecture du lien est assez ardue et mes connaissances théoriques en ce qui concerne les échanges http trouvent leurs limites. J’ai du pain sur la planche pour tout saisir, marci bien… ;) a++

  18. aymeric dit :

    je faisais aussi avant bcp de fichiers css, mais l’extension YSlow de Firefox m’a indiqué que cette multiplicité ralentissait le chargement de mes pages. du coup, je les ai regroupé. avec des commentaires bien placés, le résultat est plutôt bon.

  19. infirmier dit :

    Bonjour,

    pareil pour moi, je crée plusieurs pages pour la phase de développement que je regroupe pour la mise en ligne (avec un fichier de commentaire à part pour qui voudrait reprendre le code par la suite si ce n’est pas moi)

    Mais bon je gère des mini-projet sans envergure (tout est relatif)

  20. Nicolas G dit :

    Le billet commence à dater, mais je constate que son contenu est toujours d’actualité. Les dernières recommandations nous invitent à regrouper nos css pour éviter le nombre de requêtes http et améliorer les performances de votre site web.

    Pour faire simple moins on a de fichiers css mieux c’est.

    Il faut je crois penser à la fois l’organisation des css en terme de performance et aussi de maintenance, c’est la méthode que j’ai tendance à choisir pour des sites complexes.

  21. Cenwen dit :

    Bonjour:) et merci ! Je commence à y voir un peu plus clair :) Voilà qui devrait m’aider. Je suis loin de tout avoir compris, mais je vais enfin oser me lancer sur un projet qui me tient à coeur depuis des mois : adapter un thème wp sur mon blog canalblog.

    Je n’ai pas fini de venir et revenir ici :)

    A plus :)

Laissez un commentaire

Vous pouvez utiliser les balises HTML suivantes : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Les commentaires sont publiés sous votre pleine et entière responsabilité et ne doivent pas contrevenir aux lois et règlementations en vigueur. Les propos racistes ou antisémites, diffamatoire ou injurieux, divulguant des informations fausses, relatives à la vie privée d'une personne ou utilisant des oeuvres protégées par les droits d'auteurs ne sont pas les bienvenus et seront modérés sans modération.

Merci d'être constructif et n'oubliez pas : « sans la liberté de ramer il n'est point d'éloge flotteur ! »



Colophon

CSS & Webdesign est une publication irrégulomadaire à tendance hebdomadaire
éditée par Bruno Bichet qui carbure à WordPress et au café équitable.
Tous droits réservés © 2006 - 2011.

Contactez l'auteur du site