Hop, la 3ème édition du WaSP café aura lieue le 17 avril (inscrivez-vous !) avec, comme la dernière fois, 3 ateliers : Accessibilité, CSS et Sémantique (1). La dernière fois j’avais choisi l’atelier Javascript et je n’avais franchement pas été déçu. Cette fois-ci j’ai choisi l’atelier CSS dont le thème est “Organiser et gérer vos CSS”, l’occasion pour moi d’évoquer ici comment j’ai choisi d’organiser les miens pour le dernier projet sur lequel je travaille.
Il s’agit d’un projet assez important avec beaucoup de pages différentes et donc beaucoup de fichiers CSS (2).
Organisation de nos fichiers
Voila comment seront organisés les fichiers CSS :
- un fichier CSS commun à tout le site (main.css)
- un fichier CSS supplémentaire par page (nom-de-la-page.css)
Le header de notre page (j’utiliserai une page nommée “Article” dans mes exemples) ressemblera alors à ça :
<link rel="stylesheet" type="text/css" href="/style/main.css" media="screen" /> <link rel="stylesheet" type="text/css" href="/style/article.css" media="screen" />
Le fichier main.css contiendra :
- le Reset CSS (3)
- le layout : header, footer, navigation, classes adéquates pour pouvoir faire 1,2 ou 3 colonnes, etc. Bref tous les éléments communs à toutes les pages du site.
- les éléments communs : des éléments que l’on retrouve un peu partout sur le site (boutons, messages d’erreur, éléments de formulaire, etc.)).
- la page d’accueil : la page par laquelle la majorité des visiteurs arrivent (économie d’une requête HTTP) (4).
Le fichier article.css contiendra quant à lui… le CSS de la page article (5).
Eléments de page communs
Il arrive que des éléments soient présents sur plusieurs pages sans pour autant qu’il soit nécessaire de les charger dans le fichier main.css. Dans ce cas j’utilise @import dans mon fichier de page afin d’importer ces éléments.
Les jumeaux maléfiques
Suivant le besoin, chaque fichier .css peut avoir un (ou plusieurs) fichier(s) jumeau(x) : ceux-ci contiendrons toutes les corrections pour IE6 et IE7 (6).
Ils sont suffixés par -ie ou -ie6 :
- article-ie6.css contiendra tous les “hacks” pour IE6 (PNGs, HasLayout, etc.) pour la page Article
- article-ie.css contiendra tous les “hacks” communs à IE6 et IE7 pour la page Article
On utilisera nos amis les commentaires conditionnels pour inclure ces fichiers en fonction de la version d’IE. Cette technique a le désavantage de multiplier les fichiers (ainsi que les requêtes HTTP) mais c’est encore la technique la plus fiable pour gérer les différences de rendu d’IE sans recourir à des hacks incompréhensibles et inmaintenables. A vous de voir en fonction des contraintes de vos projets.
Au bout du compte notre header commence à prendre un peu de volume, voila ce que ça donne (7) :
<link rel="stylesheet" type="text/css" href="/style/main.css" media="screen" /> <!--[if lte IE 6]><link rel="stylesheet" type="text/css" href="/style/main-ie6.css" media="screen" /><![endif]--> <!--[if lte IE 7]><link rel="stylesheet" type="text/css" href="/style/main-ie.css" media="screen" /><![endif]--> <link rel="stylesheet" type="text/css" href="/style/article.css" media="screen" /> <!--[if lte IE 6]><link rel="stylesheet" type="text/css" href="/style/article-ie6.css" media="screen" /><![endif]--> <!--[if lte IE 7]><link rel="stylesheet" type="text/css" href="/style/article-ie.css" media="screen" /><![endif]-->
Ça commence à en faire des fichiers CSS, et là on ne couvre que 2 pages de notre site (8) !
Structurer nos fichiers
Maintenant va falloir structurer nos fichiers CSS, rien de compliqué, quelques commentaires ça éclairci tout de suite les idées.
Le Header
Je démarre toujours mon fichier avec un Header claire et concis, avec ces quelques informations :
- Titre du CSS
- Courte description du fichier
- Nom du projet
- Auteur
- Copyright (ou pas)
- Sommaire
Voila, rien d’extraordinaire, sauf peut être le dernier : Sommaire. Nous verrons celui-ci plus tard.
Le Sections
Nous allons diviser notre fichier CSS en plusieurs sections et sous-sections. Chacune aura un niveau de titre différent :
Titre de niveau 1 :
/* ================================ * Section * ================================*/
Titre de niveau 2 :
/* * Sous-section */
Titre de niveau 3 :
/* Sous-sous-section */
On peut imaginer que notre section soit la sidebar, chaque sous-section un bloc de cette sidebar et chaque sous-sous-section une partie spécifique de ce bloc. On remplira alors notre sommaire avec nos niveaux de titre.
Au final on aurai un fichier CSS qui ressemblera à ça :
/*----------------------------------------------------------- Article CSS Styles for the article page Project: MyProject Author: me Summary : Sidebar Article - Article body - Article comments - Article comments form ----------------------------------------------------------*/ /* ================================ * Sidebar * ================================*/ @import "sidebar.css"; /* ================================ * Article * ================================*/ /* * Article body */ /* * Article comments */ /* Article comments form */
Et Les jumeaux maléfiques ?
Même traitement pour eux, à ceci prêt que les fichiers seront beaucoup plus léger que le fichier original (9). Pour ma part je ne leur met pas de Header aussi complet, je me limite juste à une courte description (10). Voici ce que ça donnerai pour article-ie6.css :
/*-----------------------------------------------------------
Corrections for IE 6 (PNG Hacks, HasLayout triggers etc.)
----------------------------------------------------------*/
/* ================================
* Sidebar
* ================================*/
@import "sidebar-ie6.css";
/* ================================
* Article
* ================================*/
/*
* Article comments
*/
/* Article comments form */
Vous remarquerez que le fichier jumeau d’article importe le fichier jumeau de la sidebar, pour rester cohérent par rapport au fichier original. Ça serait le même traitement pour article-ie.css.
Conventions
Voila pour ce qui est de l’organisation globale. En plus de ça je me suis imposé quelques conventions à respecter dans mes fichiers, je vais vous les lister en vrac et libre à vous de les utiliser ou pas :
- Tout en anglais
- Séparation des différents mots d’un id/class avec des tirets : .nav-page, #article-comment-preview, etc.
- Utilisation du single line CSS (11)
- Propriétés dans l’ordre alphabétique
- Indentation du code, de la même manière que le code HTML
- Pour les styles liés aux Javascript, via Javascript j’ajoute un id #js sur l’élément HTML (12) et j’attaque mes éléments par #js selecteur { … }
Conclusion
Et voila, je pense que j’ai rien oublié. Faites le moi savoir si je fais de grosses erreurs de conceptions, si vous avez vous aussi des astuces à partager ou autre. Sinon, on se vera au WaSP café pour parler de tout ça 
- Microformats/RDFa
- Le dernier projet en date en comportait plus d’une 100ène
- J’utilise celui d’Eric Meyer
- En plus ça peut nous simplifier la vie pour certains éléments des pages annexes.
- Parfois je fais des trucs logique aussi
- Les utilisateurs d’IE5 peuvent aller brûler en enfer, personne ne les regrettera.
- Vous remarquerez qu’elles n’appliquerons aussi aux versions d’IE<6
- Et là vous vous dites “pas étonnant qu’il y ait plus de 100 fichiers CSS au final”, ce à quoi je répondrai “c’est pas faux”.
- Ou alors c’est que vous avez merdé quelque part….
- Vous pouvez aussi y mettre des insultes pour les utilisateurs d’IE, ça soulage.
- Là j’entends des dents grincer, mais croyez moi, après un petit temps d’adaptation on trouve ça beaucoup plus pratique.
- class n’est pas autorisé sur l’élément HTML, seul id l’est.
15 commentaires
Intéressant de lire les habitudes des autres, ça serait pas mal que ça devienne une chaîne
!
Sinon mes questions/remarques (même si la plupart tu les connais) :
“un fichier CSS supplémentaire par page (nom-de-la-page.css)” –> Si tu as beaucoup de page ça devient vite le bordel, c’est pour ça que j’ai adopté les dossiers en plus de ça
Et puis comment tu range les fichiers spécifiques pour l’impression ou les appareils mobiles ? Si tu as des pages qui doivent s’imprimer différement de la home tu dois faire un autre fichier qui sera en vrac avec le reste :/
“la page d’accueil : la page par laquelle la majorité des visiteurs arrivent (économie d’une requête HTTP)” –> Oui, mais dans le cas où le visiteur n’arrive pas sur la page d’accueil il charge une CSS plus grosse qu’il n’en faut, et à mon avis c’est presque pareil qu’une requête HTTP, si c’est pas plus ;P !
“article-ie.css contiendra tous les “hacks” communs à IE6 et IE7 pour la page Article” –> ok mais tu ne couvre pas l’éventualité d’un bug qui n’existe que sous IE7. Je fais comme toi, mais je commence par le spécifique (parce qu’après tout le débuguage IE c’est déjà du spécifique, je fais donc un fichier -ie6.css et un -ie7.css), et si au final je trouve des similitudes entre les deux je les fusionne dans un fichier -ie.css
“Je démarre toujours mon fichier avec un Header claire et concis, avec ces quelques informations :” –> J’espère que tu fournis une version “packée” pour la production parce que sinon ton argument de la requête HTTP..
!
“Tout en anglais” –> ok, mais si tu as à tout prix besoin d’une ancre en français
?
“Utilisation du single line CSS” –> Je grince des dents à moitier. En production ok, mais en dev ça doit être super relou, surtout que t’indente (bon, ça dépend de la taille de tes tabulations c’est vrai), et à moins d’avoir un écran large et que l’éditeur prenne tout l’écran.
“Propriétés dans l’ordre alphabétique” –> Donc t’es emmerdé si t’as besoin de faire des fichiers spécifiques (font, background, i18n, etc.)
Sinon globalement je suis d’accord, mais c’est pas simple de trouver une organisation, faire des compromis entre maintenabilité, faisabilité, requetes HTTP, etc.
C’est en me posant des questions comme ça que j’me dis que le CSS est encore trop artisanal…
le Mardi 1 avril 2008 à 00:12
@Neovov :
)
1. Complètement d’accord pour les dossiers, c’est vrai que j’en ai pas parlé.
2. Pareil pour les périphériques mobiles et l’impression
3. Une fois passé par Gzip la taille des CSS est très négligeable, je pense que c’est beaucoup plus avantageux qu’une requête HTTP.
4. Alors sur mon projet j’ai déjà fait une 15ène de page (bien différentes) et je ne suis pas encore tombé sur un bug qui soit présent sous IE7 et pas IE6. Mais oui, dans l’éventualité où ça arriverai on peut prévoir un fichier -ie7.css
5. Pareil que 3. : Gzip
6. Ha, je n’ai pas encore rencontré ce cas, mais je pense qu’il faudrai essayer de laisser ces ancres en dehors du code css (ou alors ça serai l’exception qui confirme la règle).
7. L’indentation éclairci vachement justement et c’est vrai qu’il faut mieux que l’éditeur prenne toute la largeur de l’écran. Mais ton code est beaucoup plus clair je trouve. Après ça c’est le goûts et les couleurs…
8. Pas compris (mais ça t’es déjà au courant
Sinon ouai, encore et toujours des choix à faire, des compromis,… si il y avait une solution parfaite on se poserai pas de questions
le Mardi 1 avril 2008 à 00:56
Article intéressant !
L’écriture sur une seule ligne est effectivement assez déroutante mais il est vrai que ca rend plus rapide la recherche d’un sélecteur en particulier dans la feuille de style.
Je ne connaissais pas le reset css. Je me contentais habituellement d’un simple * pour mettre les margin et padding a 0.
J’ai juste une question au niveau de l’utilisation du tiret dans tes id/class. Pourquoi un tiret plutôt qu’un underscore ? les deux sont valables en Css2. J’ai personnellement l’habitude d’utiliser des underscores pour une raison simple. Dans la plupart des éditeurs le tiret est considéré comme une séparation de mot alors que le underscore non. On peut donc sélectionner l’id ou la class en double cliquant dessus, ce qui ne fonctionne pas toujours lorsqu’il y a un tiret
le Jeudi 3 avril 2008 à 17:16
Salut Vince1415
En fait le problème du * c’est qu’il agit sur les éléments de formulaire qu’il est conseillé de ne pas styler (dans la vraie vie on a généralement pas le choix, mais je préfère les traiter à part quand même).
Sinon pour les tirets, c’est juste que je trouve ça plus lisible qu’avec des underscores
(Je n’avais jamais remarqué pour le double clic…)
le Vendredi 4 avril 2008 à 10:58
C’est par contre un peu dommage de multiplier les fichiers CSS.
Vu qu’à chaque fois que tu utilises article.css tu utilises forcément main.css, le mieux serait peut être d’inclure main.css dans article.css. Si tu veux faciliter la maintenance tu peux garder deux fichiers et laisser ton application fusionner les deux au dernier moment avant envoi.
Sous MSIE c’est pas moins de 4 requêtes HTTP qui vont s’exécuter. Là aussi il est possible de profiter encore plus des commentaires conditionnels pour servir un seul gros CSS pour IE6 (qui contient les deux sections CSS IE6 et les deux sections CSS génériques) qui se charge à la place de la grosse CSS article+main et pas en plus.
le Lundi 7 avril 2008 à 18:29
Salut Eric,
Oui mais si je fusionne article.css et main.css (et donc que je fais de même avec toutes les CSS spécifiques de toutes mes pages) ça veut dire que je vais télécharger plusieurs fois le contenu de main.css : 1 fois toute seule sur la homepage, 1 autre fois avec mon gros fichier qui contient main.css+article.css, etc.
Veux-tu dire qu’il est préférable d’envoyer plusieurs fois la même CSS (et donc de beaucoup moins miser sur le cache du client) que de multiplier les requêtes HTTP ? Ça me semble bizarre.
le Mardi 8 avril 2008 à 00:18
Si ton contenu est zippé et si tu n’as pas 150 versions de page différentes (un article, une page d’index, un accueil, etc.), oui, c’est probablement mieux.
La différence de taille peut s’effacer devant le nombre de requêtes. Certains navigateurs ne téléchargeant qu’une CSS à la fois.
Ca se calcule :
- X = main+article zippé
- Y = article zippé
Si X - Y prend plus de 40ms à télécharger sur une liaison standard (comptes 1 à 2 mb/s en France pour un public internaute), alors c’est probablement une bonne chose de fusionner.
Disons que pour main+article ça se calcule. Quand tu commences à faire 4 fichiers CSS (pour IE) là ça devient beaucoup et comme le main.css ne sera *jamais* pris indépendamment du main-ie.css pour un client ie6, il n’y a plus aucune raison de ne pas les agréger.
le Mardi 8 avril 2008 à 00:57
Merci pour tes réponses.
Le contenu est zippé et je dois avoir une 20ène de pages différentes en tout, donc en effet c’est peut être avantageux de fusionner dans ce cas. Enfin pour ce projet ça ne sera pas possible car pour faire ça bien ça demanderai des modifs côté serveur et on vas pas pouvoir, mais c’est à considérer pour les futures projets.
Par contre la fusion des CSS et des CSS spécifiques à IE ça fait abandonner les commentaires conditionnels et repasser aux hacks
PS : très bien ton blog
le Mardi 8 avril 2008 à 15:48
Complément d’information, une astuce qui peut permettre de réduire le nombre de fichier CSS sans pour autant utiliser des hacks pour IE : http://www.lesintegristes.net/2008/04/08/cibler-internet-explorer-dans-une-css-oui-et-sans-hack/
le Mercredi 9 avril 2008 à 14:30
Le fait d’avoir des pages vraiment différentes au point de devoir faire une CSS dédiée est effectivement un casse-tête qui peut vite devenir “casse-gueule”.
Au début ça parait toujours une bonne idée qui permet d’avancer rapidement même si on a pas toutes les données sur l’ensemble des pages.
Les problèmes surviennent généralement lorsqu’une page doit être modifiée et quand on se rend compte qu’il faudra également en modifier d’autres : on s’aperçoit alors qu’il y avait des éléments redondants que l’on aurait pu réunir.
Tiens-nous au courant
le Jeudi 10 avril 2008 à 09:47
Salut Bruno,
Pas de problème, de toute façon le projet sort incessamment sous peu et je me manquerai pas de vous demander votre avis dessus
le Jeudi 10 avril 2008 à 17:12
Non non, tu peux fusionner les CSS IE et garder les commentaires conditionnels.
Il te suffit de faire une version “normale” et une version “normal+IE”. Tu choisis laquelle tu intègres avec les commentaires conditionnels (tu peux faire du contenu qui ne s’affiche que sur IE comme tu l’as fait, mais tu peux aussi faire le contraire, l’association des deux te donnes ce que tu veux).
le Mercredi 16 avril 2008 à 21:16
Ha ok, j’ai pigé le système. Donc si on a un script pour fusionner les css côté serveur alors c’est une bonne méthode. Sinon il reste celle que j’ai linké plus haut qui semble pas mal aussi.
le Jeudi 17 avril 2008 à 17:40
“Les utilisateurs d’IE5 peuvent aller brûler en enfer, personne ne les regrettera.”
“Vous pouvez aussi y mettre des insultes pour les utilisateurs d’IE, ça soulage.”
Pas très pro tout ça, mais je comprends ta haine envers ces misérables ^^
Merci pour cet article, je n’avais plus trop le net je le découvre à peine. Très instructif pour un noob comme moi
le Mercredi 23 avril 2008 à 16:21
[…] que j’ai eu l’occasion de présenter dans cette traduction. Sans oublier le billet de Country qui a déclenché l’envie d’en faire un […]
le Mercredi 23 avril 2008 à 19:14