N’oubliez pas le C de CSS

22 septembre 2011 |

Auteur: bruce

J’ai eu, au cours des derniers mois, l’occasion de faire du code review sur beaucoup de pages web (et quand je dis beaucoup, je veux dire beaucoup…), et je me suis rendu compte de quelque chose d’assez étonnant : la plupart des développeurs et autres intégrateurs web sont bien conscients de ce qu’il faut séparer le contenu du contenant via des pages CSS et utilisent aujourd’hui largement les balise <div> en lieu et place des balises <table> (y compris pour les tables, ce qui pour le coup est une connerie); mais pour autant, ils semblent être passés, pour la plupart — et je pèse mes mots — à côté d’une des composantes principales des CSS : la lettre C.

CSS : Cascading Style Sheets

Le C de CSS est pour Cascading, ou « en cascade » en bon français. Ce que cela signifie — et je vous prie d’avance de m’excuser pour enfoncer des portes largement ouvertes — c’est qu’un style appliqué à un élément d’une page web est automatiquement, par cascade, appliqué à tous ses éléments, sauf contre-indication. Je n’ai pas l’intention dans cet article de faire un cours sur comment fabriquer de belles feuilles de styles, certains sites font cela très bien, bien mieux que moi et depuis bien plus longtemps (pour n’en citer que deux : Alsacreations.com et aListApart.com ); mon intention est ici de relever quelques unes des erreurs les plus couramment rencontrées ces dernières semaines, et de tenter de les comprendre et résoudre.

Et, pour être parfaitement complet, je précise qu’il ne s’agit, dans la plupart des cas, pas d’erreurs à proprement parler, mais plutôt de mauvaises habitudes de code…il conviendra alors que je justifie la mauvaise qualité de ces pratiques.

Mauvaises habitudes CSS, en général

Un fichier CSS par page web

Sans doute un des problèmes les plus courants : créer un fichier css pour chaque page web; cette pratique en dit long sur les méthodes de travail des intégrateurs web qui ne travaillent que rarement en équipe, leur métier étant souvent considéré (à tort) comme une simple tâche d’exécutant (de plus en plus souvent sous-traité à l’étranger, qui plus est); on a trois pages à intégrer : accueil, contact et qui sommes-nous, on confie la tâche à un intégrateur qui fait travailler deux ou trois personnes (permettant ainsi des délais plus courts, et donc plus chers), chacune travaillant dans son coin sans même simplement imaginer que d’autres personnes travaillent.

Pourquoi est-ce une mauvaise pratique ?

Le but des feuilles de style est triple :

séparer la mise en forme d’une page du contenu de cette page;
définir un style uniforme pour un contenu présenté de façon homogène;
définir un style pour une destination donnée (écran, imprimante, mobile, etc.).

La plupart du temps, seul le premier objectif est pris en compte; c’est déjà bien, mais « peut mieux faire » comme disent les professeurs. En réalité, si on ne remplit pas les deux autres objectifs, le premier devient très accessoire. En effet, un des intérêts majeurs à séparer le fond de la forme est de se laisser la capacité de modifier la forme en une seule fois tout en garantissant que les modifications sont prises en compte partout et que l’aspect global reste homogène. Or, une feuille de style par page signifie un style par page. Donc, une modification de style sur n pages signifient n fichiers CSS modifiés.

Résolution

La résolution consiste en la construction naturelle de feuilles de styles :

Combien de styles différents souhaité-je déployer sur mon site internet ? Par exemple, un style pour la partie commerce, un style pour la partie institutionnelle et un style pour le back office; il doit y avoir autant de fichiers CSS que de styles à présenter;
Par ailleurs, quelles destinations souhaité-je adresser de façon définie ? Si je souhaite définir un style particulier pour les imprimantes, pour les tablettes numériques, les smartphones, etc. c’est autant de multiplications des feuilles de style (du moins en partie, comme nous le verrons plus loin).

Un fichier CSS pour Internet Explorer

Là encore, du fait que l’HTML n’a jamais été vraiment standardisé (et même si HTML 5 résout une partie des problèmes), chaque navigateur internet propose des interprétations, parfois différentes, des tags HTML. Du coup, il est fréquent de voir traîner, près d’un fichier main.css, un fichier main_IE.css .

Pourquoi est-ce une mauvaise pratique ?

En soi, ce n’est pas nécessairement une mauvaise pratique; en effet, IE peut être considéré comme une destination à part entière, de la même manière qu’une imprimante. Ceci étant, il est nécessaire de considérer, dans ce cas, le fichier IE.css comme une surcharge d’une feuille de style générale, en prenant en compte la mise en cascade des styles, et ne pas copier/coller le fichier principal en modifiant ensuite ce qui doit l’être.

Résolution

Je viens de le dire : la résolution tient dans le fait de n’adresser dans ce fichier que les surcharges nécessaires. Plus de détails dans la résolution du problème suivant.

Chaque élément de la page est complètement défini

Une page relativement simple, avec un entête, un pied-de-page, une navigation, et deux colonnes remplies d’articles (tous sur le même modèle : titre, chapeau, texte, lien, image), et pourtant une feuille de style avec des dizaines de styles.

Pourquoi est-ce une mauvaise pratique ?

De la même manière que définir une page CSS pour chaque page web rend la maintenance très difficile, le fait de définir un style pour chaque élément de contenu d’une page rend la maintenance très difficile et compromet rapidement l’homogénéité du site.

Résolution

Il est nécessaire de profiter de toutes les facettes du CSS à notre disposition : les tags HTML, les id, les classes (on peut aller plus loin avec les sélecteurs, les opérateurs, etc.).

Les règles pour cela sont extrêmement simples (et leur mise en oeuvre pas particulièrement compliquée) :

les tags HTML doivent avoir un style (défini explicitement ou hérité);
les éléments de page qui sont uniques (comme par exemple la navigation principale) doivent avoir un style défini par un id;
les éléments de page génériques, qui sont repris potentiellement plusieurs fois par page (par exemple, un article) doivent avoir un style défini par une classe.

Concernant le premier point, pensez à bien utiliser le sélecteur universel *, les tags html et body, les leaders h1, h2…, les liens a, a:hover…Ceci étant, attention de ne définir que le strict nécessaire; il est inutile de définir le style h6 s’il n’est jamais employé. Par ailleurs, utilisez autant que possible l’héritage en cascade : si vous définissez une police donnée dans le tag body, et si la même police, mais dans une autre taille et en gras, est utilisée pour les leaders h1, n’implémentez dans ce tag que la taille et le poids de la police.

Concernant le second point, ayez toujours à l’esprit la règle simple suivante : les positions sont définies par des id. Sauf cas très rare, cette règle est toujours applicable. Vous pouvez utiliser les tags pour définir les marges intérieures et extérieures, éventuellement les dimensions, idem pour les classes, mais réservez les positions (absolues ou relatives) aux id. Une exception notable à cette règle est l’utilisation du float qui peut être prise en charge par des classes ou par des tags (c’est régulièrement le cas du tag img).

En bref, sur notre page d’exemple définie en présentation du problème, on devrait retrouver les sections suivantes au sein du fichier css (quelle que soit sa destination) :

*, body, html (pour les tags);
#page (pour l’ensemble de la page), #header, #footer, #content, #column_1, #column_2 (les ids);
.article (pour les articles).

On devrait également trouver les sous-sections suivantes (par exemple) :

#header ul, #header li (pour les éléments de navigation);
.article h1, .article p, .article a, .article a:hover (pour les tags dans les articles).

Évidemment, selon les cas, la résolution peut être plus ou moins simple. Gardez toujours à l’esprit les deux idées suivantes :

comment puis-je simplifier mon découpage sans perdre le sens de ce découpage;
si je dois revenir dans 3 ans pour modifier l’aspect du site, ai-je optimisé mes feuilles de style pour simplifier cette tâche ?

Bilan

Cet article ne prétend pas faire le tour des problèmes rencontrés; en revanche, je souhaite que vous puissiez y déposer les problèmes que vous avez rencontrés ainsi que leur résolution si vous en avez. Les bonnes pratiques peuvent être définies par des livres, des spécifications, des forums, des vidéos, des formations, etc. Mais la source principale de ce qui se définit comme une bonne ou une mauvaise pratique reste avant toute chose la pratique.

Publié dans Développement, Généralités, Méthodologie, TIML

LeMondeDuDev