Gou blog

Structurer des CSS peut sembler anodin pour certain, mais il est important de bien classer celles-ci si on désire avoir une bonne gestion de l'héritage. Depuis quelques mois que je planche sur une approche de l'héritage. J'ai testé diverses approches, et voici que j'ai une proposition à faire. Mais avant tout, ça prend une mise en contexte.

Lorsque je fais du Web design, c'est généralement pour des systèmes qui peuvent être assez complexes. Ces systèmes se subdivisent en modules. Le système a une signature graphique (qui devrait normalement découler de l'organisation hôte) et chaque module a des particularités. Mon approche est donc la suivante: j'ai un ensemble de CSS principal qui contient les informations d'affichage général (par exemple, la police, les marges, le positionnement du PIV pour un site gouvernemental).

On retrouve par la suite un sous-groupe de CSS représentant un ensemble de modules. Dans l'exemple suivant c'est le sous-groupe du pilotage qui est représenté. Il y a une certaine relation visuelle dans ce sous-groupe, ce qui peut nécessiter des styles précis. Par exemple, dans le système qui m'intéresse, la navigation en pilotage se fera par un fil d'ariane, fonction qui ne sera pas présente dans l'ensemble su système.

Finalement, on a les ensembles de CSS par modules. Un module particulier pourrait avoir des particularités qu'un autre n'aurait pas. Par exemple, un module peut permettre d'afficher des statistiques des données alors qu'un autre permet la gestion des utilisateurs du système. L'affichage peut nécessiter des effets particuliers.

Cette approche peut paraître complexe pour le néophyte (et aussi pour les programmeurs), mais ça permet de se retrouver dans l'héritage et d'alléger les CSS.

Une autre particularité, c'est l'utilisation de CSS de redirection. Celles-ci ne contiennent que des attributs @import permettant de faire des liens vers des feuilles par médium ou des feuilles parentes. Voici un exemple de code d'une CSS d'importation:

/* imortation par médium */
@import url(/share/css/pilotage/module1/module1_all.css)
@import url(/share/css/pilotage/module1/module1_print.css)

/* importation supérieure */
@import url(/share/css/pilotage/pilotage.css)

Contrairement à certains, je n'indique pas de médium dans mes feuilles d'importation, il se trouve que ça empêche certains fureteurs de bien fonctionner (ie, pour ne pas le nommer). Je préfère encadrer ma CSS de cette façon:

/* css pour l'impression */
@media print {

body   {color:black;}
/* continuer les déclaration de styles... */

/* fermeture media */
}

Cette approche, bien qu'étant moins élégante, fonctionne sur l'ensemble des fureteurs que j'ai pu tester (c'est ce que j'utilise pour Gou Blog, alors si ça ne fonctionne pas, personne ne me l'a dit encore!).

Pour ce qui est d'appeler la première CSS, je le fais toujours par le biais de la balise link et chaque module n'appelle qu'une seule page. J'évite ainsi les multiples liens vers des CSS, le programmeur n'a pas à se casser la tête et c'est moi qui gère l'ensemble de la structure des CSS.

Cette technique fonctionne très bien lorsque je suis en mode «statique», mais dès qu'on déploie le tout avec J2EE, ça ne fonctionne plus. Les importations de CSS et d'images ne se font pas car la racine du serveur n'est pas la même pour les CSS et pour le Java. Pour l'instant, on a deux solutions:

1. Mettre les CSS et les images dans un répertoire parallèle, dans leur propre environnement. À terme, c'est ce qu'on désire, avoir un entrepôt central des CSS, mais il n'est techniquement pas encore prêt. On va peut-être devoir utiliser une approche temporaire.
2. Tout convertir en tableaux avec des tags font (aaaaaargh!!!)

Sans blagues, on va probablement devoir se créer un entrepôt de CSS et d'images. Perso, ça ne me dérange pas trop. Reste à voir comment tout ça va se terminer. Je vous tiens au courant!

Note: Un raffinement de la présente méthode a été fait avec le temps. Je vous invite à consulter un billet qui résume le tout.

Libellés : css, html, méthodes