Traduction : Architecture des CSS

Je la promets depuis longtemps, j’aurai certes mis du temps à la pondre, mais voici donc enfin ma nouvelle traduction : Architecting CSS, de Garrett Dimon, publié à l’origine sur DigitalWeb Magazine, un article d’une grande utilité et très intéressant, qui traite de l’organisation des CSS : fichiers, règles, sélecteurs, etc.
J’espère que cela pourra vous éclairer et vous rendre service !
Edit du 06/08/06 : j’ai ajouté quelques commentaires à la fin de l’article…


Début de la traduction (article d’origine ici)

Grâce au support presque universel des standards par les navigateurs modernes, nous nous tournons de plus en plus vers les CSS pour une gestion de haute volée de la présentation. Plus nous nous appuyons sur les CSS, plus les fichiers CSS grossissent et se complexifient. Ces fichiers soulèvent aussi des défis de maintenance et d’organisation.

Loin sont les jours où l’on créait un fichier CSS unique pour y coller des règles au fil des besoins. Au fur et à mesure que nous construisons de nouveaux sites, il devient nécessaire de passer un peu de temps à planifier l’organisation et la structure des CSS.

Organisation de fichiers

Le premier pas dans l’organisation de nos CSS est de trouver un plan pour l’organisation de nos fichiers. Un bon schéma organisationnel des CSS est aussi important pour un site que la planification de la structure des dossiers. Aucune solution n’étant parfaite pour toutes les situations, nous allons examiner les choix de base pour l’organisation et leurs avantages et désavantages respectifs.

Le fichier CSS principal

Vous débuterez généralement par un fichier CSS par défaut qui contient les règles utilisées sur chaque page. Ce fichier établit les paramètres par défaut comme les polices, les couleurs et comportements des liens et ancres, les titres, et toutes autres propriétés que toutes les pages partageront. Avec un fichier par défaut en place, examinons quelques stratégies pour l’organisation de haut niveau.

Méthode 1 : Archétypale

La stratégie la plus basique est de segmenter les fichiers en fonction de pages archétypales. Par exemple, un site avec des designs différents pour la page d’accueil, les sous-pages et les pages de portfolio pourrait tirer partie d’un système archétypal. Chaque page importe sa propre CSS.

Cette méthode est directe et fonctionne bien pour un petit nombre d’archétypes distincts. Cependant, elle commence à pêcher si les éléments de présentation ne tombent pas facilement dans des catégories prédéterminées pour chaque archétype. Si il y a des éléments partagés par des sous-pages et des pages de portfolio mais pas par la page d’accueil, nous avons les choix suivants :

  1. Mettre les éléments partagés dans le fichier CSS principal. Bien que ce ne soit pas la solution la plus pure, elle est appropriée dans certaines situations. Cependant, si vous travaillez sur un gros site, le CSS principal peut rapidement gonfler, rendant caduque le but de la séparation des fichiers, qui est d’éviter d’importer des fichiers inutilement gros.
  2. Créer des versions dupliquées des règles CSS à la fois dans le CSS de la page portfolio et dans le CSS des sous-pages. Il est clair que nous ne voulons pas suivre cette route car cela reviendrait à maintenir du code redondant.
  3. Créer un nouveau fichier qui pourra être partagé entre les deux pages. Ceci a l’air d’être une bonne solution à moins d’avoir 10 lignes de code partagé. Auquel cas nous avons crée un fichier entier juste pour 10 lignes de code. C’est pur, mais deviens peu maniable si vous avez un gros site et beaucoup de paires de pages qui partagent un petit set d’éléments unique.
  4. Créer un fichier CSS distinct pour prendre en compte tous ces petits cas. C’est peut-être aisé, mais dépendamment de la taille de votre site et du nombre de ces occurrences, vous pourriez vous finir par inclure un gros fichier CSS dans une situation où une page n’utilise qu’un petit pourcentage des règles de ce fichier. Là encore, cela rends caduque le but de l’organisation vos CSS pour éviter l’importation de fichier inutilement gros.

Ceci est ce que j’ai commencé à appeler le “Dilemme du Chevauchement”. Des sous-ensembles de pages différents se chevauchent de manière unique, et il n’existe pas de solution toute prête pour organiser proprement ces petites règles CSS.

Méthode 2 : Par élément de page/section

Cette méthode fonctionne très bien si vous utilisez des inclusions côté serveur sur votre site. Par exemple, si vous utilisez un include pour votre en-tête, il aurait son propre fichier CSS correspondant. Vous pourriez faire de même avec le pied de page ou toute autre inclusion. Il vous resterai alors seulement à appeler le fichier CSS correspondant lorsque vous effectuez une inclusion dans une page. Ceci est propre et simple mais peut résulter en la création de nombreux petits fichiers CSS.

Par exemple, votre pied de page peut nécessiter 20 lignes de CSS pour le styler. Créer un fichier unique pour cela serait peut-être exagéré. De plus, cette méthode pourrait vous amener à inclure un grand nombre de fichiers sur chaque page. Si une page a 5 inclusions, elle nécessitera 5 fichiers CSS additionnels.

Méthode 3 : Par balise

Cette solution est directe et pratique, similaire à la précédente. Si nous avons un site avec 30 pages, 10 d’entre elles utilisant des formulaires, nous pourrions créer un fichier qui gère tous les styles de nos formulaires et l’importer uniquement dans les pages qui contiennent des formulaires. De la même manière, si 10 autres pages contiennent des tableaux pour l’affichage de données, nous pourrions créer un fichier pour gérer les styles des tables.

Conseils d’organisation additionnels

En parallèle des façons subjectives d’organiser les fichiers, nous devrons aussi considérer les fichiers pour les différents types de médias comme l’impression, les PDA, les écrans… Ceci est plus clairement défini mais reste un facteur que nous devons considérer lorsque nous créons notre structure de fichiers. Lorsque le support de plusieurs types de médias est obligatoire, vous voudrez probablement revoir certaines des règles inclues dans votre fichier CSS principal.

Le Co-Branding est un autre facteur important qui peut s’appliquer à votre projet. Si c’est le cas, vous devrez déterminer quels éléments peuvent être changés pour gérer une marque différente, et séparer ces éléments dans un fichier à part.

Une autre possibilité souvent ignorée est celle d’utiliser les déclarations @import imbriquées. Vous pouvez créer un fichier CSS qui ne contient qu’une série de déclarations @import ou utiliser @import pour inclure des fichiers dans une de vos feuilles de style parallèlement à une série d’autres règles. Ceci vous permet de créer un fichier CSS principal pour certaines sections du site. Si vous vous rendez compte que vous importez 4 ou 5 fichiers CSS différents sur chaque page, vous devriez définitivement envisager de prendre parti de ce conseil.

Organisation des sélecteurs et des règles

Maintenant que nous avons ordonné l’organisation de nos fichiers, voyons comme organiser tout ce qu’ils contiennent. Naturellement, nous voulons naviguer dans ces fichiers sans problèmes et retrouver rapidement les sélecteurs ou règles que nous voulons éditer.

Redondance vs Dépendance

Comme Dave Shea en parlait dans son article “Redundancy vs Dependency”, vous devez constamment prendre en compte la cascade. Vous devrez décider si vous préférez grouper les sélecteurs, ce qui crée des dépendances, ou séparer les sélecteurs, ce qui amène de la redondance. Grouper les sélecteurs nous permets de conserver un code court et simple, mais cela crée aussi une dépendance qui peut amener des cauchemars de maintenance au long terme. Cependant, si nous ne groupons pas ces sélecteurs et leurs attributs communs, la taille du fichier augmente, et il devient plus difficile de conserver une constance entre sélecteurs identiques. Vous devez prendre en compte cette différence afin de prendre la bonne décision dans chaque cas de figure.

Grouper par Relation et Contexte

Tandis que l’organisation de fichiers peut être subjective, il est clair que le meilleur moyen de grouper des règles et des sélecteurs est de se baser sur leurs relations entre eux et au reste de la page. Par exemple, si vous avez un conteneur, un en-tête et un pied de page qui font votre mise en page, groupez-les.

Cela a l’air simple, mais quand vous ajoutez votre navigation, qui est contenue dans l’en-tête, est-ce que vous la groupez avec ses éléments parents, ou dans son propre nouveau groupe ? Dans cette situation, prenez en considération le contexte de la règle dans la page. Généralement, votre en-tête est connexe à la disposition de votre page, et elle devrait être groupée avec d’autres éléments de disposition. Votre navigation, d’un autre côté, est une partie de l’en-tête et devrait probablement être groupée avec les autres éléments de l’en-tête mais pas nécessairement près du conteneur d’en-tête en lui-même.

Utilisez les commentaires

Comme avec beaucoup de langages de code, la clé d’une bonne organisation est le commentaire. Étiquetez clairement chaque section de vos CSS en fonction de ce qu’elle contrôle. Il vaut mieux s’assurer que ces commentaires ressortent visuellement afin de pouvoir rapidement les identifier quand vous faites défiler le fichier.

Doug Bowman a poussé l’art des commentaires plus loin dans son article sur les commentaires CSS, “CSS Organisation Tip #1 : Flags”. Il y explique comment il précède les noms de section d’un signe “=” afin de pouvoir utiliser la fonction de recherche de son éditeur de texte pour sauter rapidement vers une section.

Ne pas oublier

Assurez-vous d’être au fait des subtilités de la spécificité, la cascade et l’héritage, et utilisez-les à votre avantage. Chacune d’entre elles peut être votre pire ennemi ou, tout aussi aisément, votre meilleur ami. Quand vous construisez un gros site, la compréhension des subtilités de ces pièces du puzzle peut faire la différence entre une organisation réussie et la création d’un château de carte qui pourrait s’effondrer à n’importe quel moment.

Organisation d’attributs

Nous avons maintenant des options pour l’organisation de nos fichiers, et savons comment organiser les règles dans ces fichiers, mais il reste un niveau d’organisation. Les attributs sont beaucoup plus simples que les autres concepts présentés dans cet article mais il existe quand même des bonnes pratiques définies pour conserver la propreté de vos règles.

Alphabétisation

Quand il s’agit d’attributs, si vous ne devez suivre qu’un seule de ces directives, ce devrait être celle-là : alphabétiser. Alphabétiser. Alphabétiser. Cela n’aidera pas la navigation dans vos attributs, mais aidera à éviter que vous ne dupliquiez un attribut et écrasiez accidentellement un réglage précédent.

Par exemple, je ne compte plus le nombre de fois où j’ai spécifié la marge comme premier attribut d’un sélecteur particulier puis ai inconsciemment ajouté un deuxième attribut de marge après ou avant mes valeurs d’origine. Naturellement, la deuxième valeur de la liste est utilisée. Si vous ne réalisez pas que le second attribut est présent, vous pourriez tenter d’ajuster la première valeur et ne pas voir de changement en rafraîchissant la page dans votre navigateur. Si, en revanche, vos attributs sont tous alphabétisés, vous remarquerez que vous avez donné des valeurs à vos margins deux fois car les deux attributs sont l’un sous l’autre, et vous éviterez complètement le problème.

!Important

Lors de la construction de sites complexes avec beaucoup de fichiers CSS, vous pouvez créer un grand nombre de dépendances. Quand vous rencontrez un problème avec l’application d’un attribut spécifique à un élément, l’option d’utiliser la règle !important peut être tentante. Bien que cela puisse régler le problème à court terme, il vaut mieux pour le long terme déterminer quel autre attribut est la source du problème. Remontez la cascade et déterminez si utiliser !important est réellement la bonne réponse.

Si vous êtes familiarisé avec la spécificité, la cascade et l’héritage comme mentionné plus haut, vous n’aurez pas besoin de vous baser sur !important. Il y aura des moments où vous en aurez besoin, mais vous devriez bien connaître ces instances avant de créer la règle. N’utiliser jamais !important comme rustine rapide ou comme arrière-pensée parce que vous ne trouvez pas la source réelle du problème.

Résumé

Au fur et à mesure que nous nous appuyons de plus en plus sur les CSS, et que la complexité de nos feuilles de style s’intensifie parallèlement, nous avons besoin d’une planification appropriée afin d’éviter les erreurs et s’assurer d’écrire du code facile à maintenir. Bien qu’il n’y ait pas toujours de solution parfaite pour chaque scénario, la compréhension du fonctionnement des CSS et des différentes options d’organisation de fichiers, de sélecteurs et d’attributs qui sont à notre portée peut nous aider à écrire du code à l’épreuve du temps.

—-

Garrett Dimon travaille chez Bright Corner, Inc. à Plano, Texas, où il participe à l’Architecture de l’Information et le Développement de Site. La nuit, il publie et maintient YourTotalSite, et trouve occasionnellement du temps pour jouer un peu de basketball.


J’ajouterai quelques remarques à tous ces conseils très intéressants…

Personnellement, quand je monte un site, je me sers très souvent de PHP, et d’includes. J’ai un système un peu perso : je récupère le nom du fichier (moins l’extension) et je m’en sers pour appeler la feuille de style.

Par exemple, j’ai une page “panier”, le fichier php qui s’en occupe s’appelle cart.php et la feuille de style associée cart.css (qui appelle base.css, où je décris les éléments communs à toutes les pages)… mais là où ça devient intéressant, c’est lorsqu’on a un niveau supplémentaire : une famille de pages, ou plusieurs langues par exemple.

Ainsi, dans mon exemple j’appelle en fait cart_fr.css ou cart_en.css ou cart_jp.css par exemple (toujours grâce aux variables de mon php), qui elles-mêmes appellent cart.css, qui appelle base.css… on peut ajouter un autre niveau si on veut ! Je crois que ça commence à ne plus marcher (avec IE, bien sûr) à partir de 5 niveaux… mais sinon, on peut vite se rendre compte de la souplesse du système ! Enfin, en tout cas il marche bien pour moi ! :)

Je pense que le plus important est en fait d’être imaginatif, intuitif, souple, de se laisser prendre au jeu (car moi je m’amuse avec les CSS, pas vous ?)… Il ne faut pas hésiter à sortir des sentiers battus et d’inventer son propre système si notre cas bien à nous ne rentre dans aucune case existante…

Voilà, c’était quelques remarques, j’en ajouterai peut-être d’autres plus tard si il m’en vient… Je me demande si je ne pourrai pas faire une checklist des choses que je pense être à faire en CSS pour bien démarrer et monter un site en CSS, histoire de comparer un peu et peut-être de rendre service ?

Et vous, vous avez des méthodes spéciales ??

Edit : Firefly me fait remarquer que la génération de CSS par PHP est plus judicieuse… je suis d’accord avec lui, mais je comptais en parler plus longuement dans la prochaine traduction dans ma besace… donc patience… et chuuut ! ;)

Commentaires