J’avais malheureusement passé mon tour pour les deux cafés précédents, donc je suis très content d’avoir pu assister à celui-là. Le jeudi 17 avril 2008, donc j’étais au troisième WaSP Café parisien, plein de beau monde et de discussions intéressantes.
Un grand merci aux français du WaSP pour leur invitation, et une petite note sur les locaux : très bien ! Pas forcément hyper adaptés pour une table ronde, mais impeccables pour les ateliers (la configuration « salle de classe » est particulièrement propice à la prise de notes).
Atelier CSS : organisation interne et externe
Nous nous posons tous les mêmes questions sur les CSS : comment les ranger, dans quel ordre les écrire, etc.
Cet atelier a bien montré la difficulté de répondre à ces questions. Il a surtout eu le mérite de faire un tour assez complet de toutes les méthodes possibles pour organiser d’une part ses fichiers (organisation « externe ») et d’autre part pour écrire, dans une CSS donnée, ses règles (organisation « interne »).
CSS : organisation externe
On distingue quatre grands types d’organisation de fichiers : par type de contenu (page d’accueil, rubrique 1, rubrique 2, etc.), par type d’éléments (mise en page, blocs, typographie - modèle peu fréquent), par familles de blocs (agenda, news, panier, etc.), ou par « version » (rouge, bleu, vert, classique, Noël, etc.).
La bonne solution n’existe pas, et se trouve au milieu, en prenant un peu des quatre.
Marie [1] pour sa part préfère organiser ses fichiers comme ça :
-
base.css -
home.css - et quelques fichiers pour les pages intérieures, pour accélérer l’affichage en tirant parti du cache du navigateur
Éric quant à lui évoque les problèmes de performance liés à un trop grand nombre de requêtes http; il préfère donc compiler côté serveur toutes ses instructions CSS et n’envoyer au client qu’un seul fichier.
On mentionne aussi la séparation de fichiers pour des raisons de médias (print, screen, handheld, etc.), ce qui déclenche une réflexion sur le reste de l’organisation des fichiers (je suis moins catégorique à ce sujet : on peut faire une seule CSS pour chaque média cité, et plusieurs pour le screen, qui reste le média le plus complexe à styler).
Est évoquée aussi la gestion des langues, et la solution suivante semble assez consensuelle : regrouper les spécificités dans une CSS par langue appeler ce fichier en dernier, notamment pour régler les problèmes d’encombrement des mots dans des largeurs souvent très contraintes.
Certains participants parlent de montages au pixel près qui rendent obligatoire ce réglage très fin par langue, d’autres expliquent qu’au contraire leurs designs prennent en compte la souplesse liée à ces différences d’encombrement et que ça les affranchit de cette multiplicité de CSS.
CSS : organisation interne
Plusieurs points sont précisés, et je vous renvoie à la présentation de Marie et Thierry qui sera en ligne bientôt à n’en point douter.
En vrac, je note :
- préciser en début de CSS un index des couleurs les plus fréquentes, ce qui permet de s’affranchir des nommages de classe maladroits (« Titre12pxRouge » à bannir)
- mettre des flags CSS pour retrouver facilement les sections (
/* =HEADER */, en référence à un article de Douglas Bowman sur l’organisation des CSS) - grouper les propriétés par type : boîte puis disposition puis police puis couleur ; l’important étant de garder la même disposition tout au long de la vie du projet, pour des questions de convention et de productivité
- privilégier un nommage sémantique : « blocTitre » plutôt que « Titre12pxRouge » (j’ai cru bon d’expliquer que certains projets font des CSS qui seront jetées au bout de six mois, entretemps maintenues pendant quelque temps par des développeurs côté serveur, et que des nommages « sales » sont parfois préférables, là encore pour des questions de productivité)
- maintenir un Guide de style expliquant à quoi sert telle classe. J’ai trouvé ce point un poil utopique, mais Marie nous assure que ça marche. À creuser, donc.
La conclusion de l’atelier, c’est qu’il n’existe absolument pas de solution idéale, et qu’il faut faire son marché entre tout ce qu’on a pu trouver jusque-là, en fonction du projet, de sa durée de vie, de sa conception, etc.
Un grand bravo à Marie et Thierry qui ont fourni un gros travail préparatoire et présenté un très bon panorama de tout ce qui se fait.
Table ronde
La table ronde était intéressante surtout parce que les intervenants venaient d’horizons très différents : Jérémie Patonnier de Cetelem [2], qui travaille au sein d’un service 100% web, Olivier Grange-Labat pour lemonde.fr, Laurent Poinsignion pour le Service d’Informations du Gouvernement, et moi pour l’Accessibilité du SI du groupe Orange-France Télécom.
Je suis incapable de vous dire ce qui s’y est dit : chaque fois que je dois parler publiquement, je rentre dans un genre de transe, une ivresse, qui me rend très concentré sur l’instant et me fait presque tout oublier sitôt le moment passé...!
Je vais laisser les autres personnes présentes résumer la table ronde, normalement on devrait voir des comptes-rendus sur le site de l’organisation. En tout cas je suis bien tenté de revenir, ça fait beaucoup de bien d’échanger sur nos pratiques, et d’avoir des retours d’expériences de gens confrontés aux mêmes questions.