hugogiraudel.com

/384093

  • Organisation des SCSS.

    Je cherche à mieux structurer mes dossiers de styles, maintenant que je suis définitivement en pré-processeur (et en SCSS), que j’essaye de découper au maximum en petits morceaux réutilisables, et que donc je suis censé avoir à la fois plein de fichiers modulaires, et d’autres propres au site en cours.

    J’ai donc lu diverses ressources qui abordent le même problème.

    D’abord, hors pré-processeur, en relisant le rangement de @tetue avec Daisy
    http://romy.tetue.net/methode-daisy

    En relisant aussi les trois proches méthodes de structuration des styles que sont OOCSS, Smacss et Atomic design. Une intro mêlant les trois en français ici :
    http://www.24joursdeweb.fr/2013/le-design-atomique
    Puis :
    http://smacss.com/book
    Et :
    http://pattern-lab.info/about.html

    Mais cela ne parle pas des dossiers et fichiers, donc enfin en cherchant des propositions de rangement réels :

    Sur un des sites de la communauté Sass
    http://thesassway.com/beginner/how-to-structure-a-sass-project

    Par un mec qui a écrit un livre sur Sass
    http://gist.io/4436524

    Par le designer en chef de OneHub, sur Medium
    https://medium.com/p/7fe19ab647fa

    Avec tout cela, je n’ai pas encore choisi définitivement comment MOI je préfère ranger mes fichiers.

    D’abord parce que je parle français et que tous mes collègues sont francophones, et que 99% de nos clients aussi. Donc pourquoi faire le mec à la mode en mettant de l’anglais partout ?

    Inversement, le fait d’utiliser des mots que l’on trouve ailleurs, fait que les futurs lecteurs du code s’y retrouveront plus facilement. Et moi-même aussi, car lorsque je décide d’utiliser tel ou tel framework, je retrouve des termes similaires pour les dossiers, donc même tout seul ça aide.
    De plus, une partie des termes vient aussi des langages utilisés, comme HTML5 par exemple. Donc peut-être mieux de ne pas mélanger.

    (Par contre une idée : utiliser le français pour tous les trucs qui sont uniquement propre au site en cours (lorsque c’est un site fr bien sûr). Par exemple le nom des variables de couleurs, ou encore le noms des objets propres à ce site-là. Ainsi je distinguerai encore plus vite ce qui est commun, en anglais, de ce qui est propre au site, en français.)

    Je suis intéressé par le découpage de Brad Frost, mais je trouve que les termes analogiques ne sont utiles que lorsqu’on explique le principe. Pour les vrais noms des dossiers ou fichiers de travail, je n’ai pas envie de mettre « atoms » ou « organisms », je trouve cela confus.

    Les mots propres à un outil ou à une communauté précise me dérange un peu aussi. Par exemple le mot « partials » peut bien évidemment être utilisé autre part, mais il est surtout présent dans la communauté Sass car c’est le terme qui désigne les fichiers avec un « _ » devant (ceux qui ne sont pas compilés en CSS mais qui doivent uniquement être inclus).
    Je n’ai donc pas trop envie d’utiliser ce mot non plus.

    Pour l’instant, les premiers mots que j’ai retenu sont :
    frameworks/ pour les librairies externes, comme TinyTypo ou Bourbon
    sections/ ou zones/ (pas choisi encore mais « section » est déjà utilisé donc mieux) pour les styles propres à des zones précises (mais communes) des pages, comme header, firstnav, footer, etc
    templates/ pour les styles qui seraient propres à des grands types de pages comme sommaire, rubrique-galerie
    pages/ pour les styles propres à une page précise

    Chaque morceau est censé être de plus en plus rarement utilisé, bien sûr !

    Vous devriez avoir noté qu’il manque encore des choses. Car là-dedans je ne range pas encore les objets réutilisables, qui doivent forcément être avant « sections ». Ce sont les « organismes » dans le vocabulaires de Frost, qui ont une cohérence ensemble quelque soit la page et quelque soit la section dans laquelle on les insérera. Il faut un mot pour ça.
    Peut-être patterns/.

    Il me manque aussi les choix graphiques généraux, pas dans une section particulière : c’est à dire en gros la surcharge de TinyTypo mais avec les couleurs, typos, tailles, etc, qui sont propres à ce site-là. Je ne sais pas encore vraiment pour ce point-là.

    Dans mon vrai « theme.scss », j’aurais donc à peu près l’ordre d’importation :
    – frameworks
    – styles de base (personnalisation de tinytypo + ajouts)
    – objets réutilisables
    – styles de sections
    – styles de templates

    Il me reste aussi à définir si les gabarits ("layouts" en anglais) par défaut du site (pas ceux propres à un template), c’est-à-dire le placement sur les grilles des zones principales, doivent être définis dans chaque section (le section/header défini son placement, le section/content défini son placement, etc) ou bien plutôt dans un unique fichier ensemble. (Par contre les surcharges du layout par défaut seraient à priori bien dans templates/.)

    Si vous avez tout lu, vous êtes courageu⋅x⋅ses, mais il me fallait aplanir tout ça par écrit pour y voir plus clair. Ça peut vous aider, ou m’aider moi après commentaires.

    Bisous. :)

    #conception #design #HTML #CSS #SCSS #Sass #framework #structure #bonnes-pratiques #styleguide

    • Pour « vendor(s) », je ne sais pas. Je n’aime vraiment pas ce terme. « Fournisseur(s) » en français. Ça fait très import-export. Je n’arrive pas à m’y faire… :D
      Par ailleurs « framework » est un mot qu’on utilise désormais couramment dans plusieurs langues (en français nous n’avons pas de terme immédiat d’un seul mot pour ça), et donc je le trouve plus passe-partout, en disant bien ce qu’il veut dire.

      Pour Atomic je l’ai expliqué plus haut : je trouve qu’utiliser des termes « par analogie » est super pour expliquer le concept. Mais pour le concret, les vrais dossiers et fichiers quotidiens, je ne trouve pas ça très intuitif. patterns n’est qu’une idée, ça pourrait être modules aussi… (mot multilingue en plus).

      Je préfère en tout cas utiliser des termes qui ne sont pas en rapport avec un outil précis : ceux utilisés par Brad Frost sont uniquement utilisés par sa méthodologie. Ils ne sont pas compréhensibles « en eux-mêmes », sans explications en amont. Tu comprends ?

    • Ce n’est pas le premier post que je lis sur le rangement des fichiers SCSS : qu’a donc ce langage pour tant inciter à ranger ?

      Ça me semble induire de l’arborescence, ce qui me semble quelque peu surdimensionné (mais pourquoi pas) pour ranger du CSS. Est-ce que ça ne complexifie pas inutilement ?

      La seule raison qui me fait arborer des styles est motivée par l’humain, non par le besoin de ranger : ça permet, par exemple, d’isoler le code de base dans un « dossier sacré » intouchable, et de pouvoir facilement le désigner comme tel aux différents intervennant·e·s. Du coup, y’a 3 dossiers maximum , qui servent à ne pas se marcher dessus et à préserver la robustesse du projet. Dans ce cas, c’est au préprocesseur de ranger ensuite par logique d’héritage, par rôle/fonction dans le site.

      D’un point de vue macro, j’utilise toujours le même découpage #Daisy, en 3 parties (qui peuvent être 3 dossiers, 3 feuilles ou 3 séries de feuilles, peu importe) :

      1. Base CSS : base pour l’intégration. Cette première partie regroupe les trucs qui servent partout, dans chaque projet web.
      2. Modules : interviennent ensuite les styles optionnels, généralement importés/imposés, associés à une fonctionnalité, un script ou un plugin.
      3. Spécifique : si nécessaires, les styles spécifiques au projet, en dernier.

      Merci en tout cas, pour le partage de ta réflexion et tes recherches.

    • D’abord une courte réponse à @tetue, puis là où j’en suis. :)

      qu’a donc ce langage pour tant inciter à ranger ?

      Pas spécialement ce langage, mais n’importe quel pré-processeur a sa fonction d’importation (mais qui importe dans une feuille unique au final). Et donc ça aide à découper en fichiers cohérents ne contenant qu’une seule fonctionnalité.

      C’est comme pour le code fonctionnel : c’est plus facilement maintenable et lisible quand on a pas un fichier de centaines de lignes. Par exemple un fichier ne contenant que les styles des boutons et leurs variantes (gros boutons, petits boutons, différentes couleurs). Puis un fichier contenant uniquement les styles des commentaires et leur agencement. Etc.

      Cela dépend bien entendu des équipes, mais je connais pas mal de gens qui préfèrent des petits fichiers cohérents (on sait qu’on trouvera tous les styles des boutons dans le fichier des boutons).

      –----

      En ce qui me concerne, voilà où j’en suis.

      Pour les fichiers et dossiers

      css/
         \_ frameworks/
         \_ modules/
         \_ sections/
         \_ templates/
         \_ theme.scss + les trucs généraux (variables, layouts, …)

      On notera que les noms de dossier que j’ai choisi sont utilisés aussi bien en anglais que dans les conversations francophones. De plus, le tri alphabétique correspond déjà à l’ordre d’importation de ce qu’ils contiennent : du plus général au plus particulier. Pratique !

      Pour l’ordre d’importation dans la feuille principale

      /**
      * Variables et fonctions de base
      *
      * Ces imports ne génèrent aucun style CSS, ce sont des utilitaires
      */
      @import "variables";
      @import "bourbon";
      @import "grid-settings"; // config de Neat, après Bourbon car utilise em()
      @import "neat";
      @import "omega-reset"; // complément à Neat pour le responsive
      @import layoutgala // mixins LayoutGala, si on en a besoin
      @import "hashgrid"; // mixin de visualisation de la grille pour aider

      /**
      * Base CSS
      *
      * Styles de premier niveau pour les éléments de base, la plupart sans classes
      */
      @import "tinytypo"; // Typographie de base, pour n'importe quel site
      @import "typo"; // Choix graphiques de base propres à ce site (couleurs de base, tailles, polices, etc)

      /**
      * Gestion des gabarits
      *
      * Placement des blocs principaux, colonnes, etc
      */
      @import "layouts";

      /**
      * Modules
      *
      * Ce sont des modèles cohérents, réutilisables quelque soit l'endroit où on les place
      */
      @import "modules/buttons"; // Tous les boutons et leurs variantes
      @import "modules/forms"; // Les formulaires
      @import "modules/lists"; // Les différentes listes du site
      @import "modules/illustrations"; // Les images et légendes
      @import "modules/comments" // Les commentaires
      // ...

      /**
      * Sections
      *
      * Styles spécifiques à des morceaux de pages, mais dans tout le site
      */
      @import "sections/access"; // Accès rapide
      @import "sections/header"; // Entête du site
      @import "sections/firstnav"; // Navigation principale
      @import "sections/footer"; // Pied de page
      // ...

      /**
      * Templates
      *
      * Styles spécifiques à des pages ou groupes de pages
      */
      @import "templates/sommaire"; // Styles propres à la page d'accueil
      @import "templates/rubrique-agenda"; // Pour l'agenda
      // ...
    • On est d’accord sur l’approche globale, du général au particulier à la Daisy : 1. base puis 2. modules puis 3. spécifique.

      Par contre, le découpage de ta dernière partie par section et templates, j’en suis revenue : d’expérience, ça tient mal sur la durée, parce qu’on ré-organise les pages, les renomme, les recompose, etc. C’est vraiment une mauvaise idée.

      Je découpe cette dernière partie par profil d’intervenants (qu’ils soient potentiels ou réels, peu importe), ou plutôt par type d’intervention, parce que ça correspond mieux à la réalité de la vie d’un projet. Parce qu’un projet ça vit, ça passe entre plusieurs mains, de talents divers, qu’on le veuille ou non, et c’est seulement en prévoyant cela qu’on s’assure de la robustesse et de la pérennité d’une intégration. Concrètement, ça donne qqch comme ça, dans cet ordre :

      theme (habillage graphique général)
      skin (si besoin de « skin » par exemple saisonnières)
      color (si besoin de variantes de couleurs, par exemple par rubrique)
      debug (feuille de débug, désactivable)
      custom (personnalisations, yes, toutes ; livré par le développeur front, interne ou externe)
      team (surcharges de l’équipe exploitant le site, en cours de vie)
      temp (surcharges à l’arrache, par les autres mains passant sur le projet, en CSS à la truelle, à vocation temporaire)

      Cela permet de passer des consignes claires :
      – si t’as besoin de modifier le look (t’as un miminum de sensibilité graphique et de connaissance en variables), va dans « theme », sinon si t’as juste besoin de rustiner un truc, vas dans « team » (et touche pas au reste, auquel t’as pas accès d’ailleurs, comme ça on casse pas le site)
      – pas besoin d’avoir la connaissance de l’ensemble du projet, de comprendre quels sont les gabarits, pour intervenir
      – d’expérience, la démultiplication de « petits fichiers cohérents » ne doit pas déborder l’étape de fabrication et être imperceptible des suivants, sinon ça rend fou le webmestre en bout de chaîne qui, peu rompu aux pré-processeur &co, préfère qu’on lui indique un seul fichier où poser ses rustines CSS.

    • En suivant un lien de @nhoizey :
      http://seenthis.net/messages/384093

      je remarque que Hugo Giraudel a décrit sa méthode, qui a quasiment le même principe découpage :
      http://sass-guidelin.es/#the-7-1-pattern

      Les termes ne sont pas les mêmes (components VS modules, etc) et lui fait encore plus de dossiers : notamment pour y mettre ce que moi j’ai toujours en bazar à la racine à côté de mon fichier principal, ce qui est un point que je dois encore améliorer. Mais sinon les principes sont vraiment les mêmes.

      Comme je dis dans l’autre seen, je préfère quand même mon nommage, car
      1) chaque terme (frameworks, modules, sections, templates) est utilisé aussi bien en anglais qu’en français, ce qui en fait un découpage passe-partout ;
      2) l’ordre alphabétique des dossiers suit scrupuleusement l’ordre d’importation, donc quelque soit où l’on travaille (dans l’explorateur de fichiers, dans l’IDE, etc) on sait encore plus facilement où l’on se trouve, tout est toujours affiché dans le même ordre.