Herman Style Guides | OddBird
▻http://oddbird.net/2018/01/03/introducing-herman
If it’s not documented, it doesn’t exist. Documentation should become the default – an integrated part of the development process.
—Miriam Suzanne (me)
-
-
Style Guides - Policy Viz
▻https://policyviz.com/2016/11/30/style-guidesMy hope is that this post will serve as a repository for guides from around the world that others can use to develop their own guides and best practices.
(il manque ▻https://visionscarto.net/guide-de-styles )
-
Une liste de Styleguides UI/UX
▻http://usabilitygeek.com/usability-user-experience-user-interface-guidelines-companies-2016Une liste de Styleguides UI/UX Design de grandes marques. Voilà ce qu’on peut faire avec du budget et du temps. ▻https://t.co/YRWxV5VEIb
-
An In-Depth Overview Of Living Style Guide Tools – Smashing Magazine
▻https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-style-guide-toolsLiving Style Guide Tools. ▻https://t.co/uJfsj4AZ0R
-
50 Style Guide Tools, Articles, Books and Resource
▻http://webdesign.tutsplus.com/articles/50-style-guide-tools-articles-books-and-resources--cms-2120950 Style Guide Tools, Articles, Books and Resources. ▻https://t.co/sOAbLNLeDs
-
#Responsive #Logos, Part 1: Tips for Adapting Logos for Small Screens
▻http://viget.com/inspire/responsive-logos-part-1-tips-for-adapting-logos-for-small-screens -
maban/styleguide · GitHub
▻https://github.com/maban/styleguideA boilerplate style guide built entirely in #Jekyll so that it can be hosted on GitHub Pages. Outputs static HTML. Tags: Jekyll #clevermarks #styleguide
-
Medium’s CSS is actually pretty f***ing good. — #Medium
▻https://medium.com/@fat/mediums-css-is-actually-pretty-fucking-good-b8e2a6c78b06I’ve been meaning to write something about the #CSS at Medium for a while because I’m not completely ashamed of it…
So how did that happen? What did we do differently? OMG, how can you do the same thing? Or learn from us, or something?
What follows are some notes on our CSS, the steps we’ve taken to get it to where it is, and the world we live in today.
-
The Style Guide Guide
▻http://vinspee.me/style-guide-guideTags : #styleguide
-
Ah merci, ça me fait des bases intéressantes pour imaginer ma résolution du même besoin mais appliqué à SPIP spécifiquement (générer un guide à partir d’un dossier de snippets + des styles appliqués).
Je dis « spécifiquement » car des librairies à part, je trouve ça utile quand on est par exemple dans une « grosse » boite, et qu’il y a des compétences séparées, genre une personne qui fait spécialement le HTML/CSS mais sans l’intégration CMS. Quand on est moins de monde, moins de moyens, ou encore quand il y a des délais plus serrés, on fait fort souvent de l’intégration continue directement à partir de l’outil final (souvent SPIP en l’occurrence pour moi :D). Bon voilà, donc c’est peut-être un truc qui pourra être utile.
#intégration #web #html #css
-
-
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-daisyEn 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.htmlMais 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-projectPar un mec qui a écrit un livre sur Sass
▻http://gist.io/4436524Par le designer en chef de OneHub, sur Medium
▻https://medium.com/p/7fe19ab647faAvec 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/ouzones/(pas choisi encore mais « section » est déjà utilisé donc mieux) pour les styles propres à des zones précises (mais communes) des pages, commeheader,firstnav,footer, etc
–templates/pour les styles qui seraient propres à des grands types de pages commesommaire,rubrique-galerie
–pages/pour les styles propres à une page préciseChaque 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-êtrepatterns/.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 templatesIl 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/headerdéfini son placement, lesection/contentdé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 danstemplates/.)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
-
-
Waow, bravo pour ce défrichage dans la jungle !
dès que j’ai du courage, promis, je re-teste ! -
Pour les libs/framework externes, j’utilise « vendors » comme beaucoup dans les développements côté serveur.
Pourquoi n’appliques-tu tout simplement pas le vocabulaire d’Atomic Design ? Par exemple, pourquoi nommer « patterns » les « organisms » ?
-
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.
patternsn’est qu’une idée, ça pourrait êtremodulesaussi… (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/384093je 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-patternLes 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.
-
-
-
Front end styleguides and pattern libraries
▻https://gimmebar.com/collection/4ecd439c2f0aaad734000022/front-end-styleguidesTags : #styleguide
-
Designing Products That Scale (Salesforce’s #styleguide)
▻https://medium.com/p/c8f3001f709bTags: styleguide #Salesforce
-
#BBC Programmes - #styleguide
▻http://www.bbc.co.uk/programmes/styleguideTags: BBC #télévision styleguide
-
#Styleguide | #Yelp
▻http://www.yelp.com/styleguideTags: Yelp Styleguide
-
Getting Started With #Pattern_Libraries ∙ An A List Apart Blog Post
▻http://alistapart.com/blog/post/getting-started-with-pattern-libraries
▻http://patterns.alistapart.com-
Même chose identifiée sous le nom de « style guide », recensé par @nhoizey il y a 2 mois :
►http://seenthis.net/messages/204620 -
Il y a beaucoup d’intérêts ; d’avantages et de bénéfices à construire ce genre d’outils. Par contre, il faut également les maintenir...
Je dois actuellement démarrer la génération d’un guide de style, je ne referais pas les mêmes erreurs qu’auparavant : il sera le plus possible généré automatiquement (grunt, fichiers en markdown). Faire un guide de style en HTML pur est bien trop coûteux à maintenir et rapidement source d’erreurs. Enfin, l’inclusion d’outils d’automatisation permet également de jouer des tests directement sur le guide de style (tests de unitaires, test d’intégration de composants ).
-
Il semble y avoir 2 manières populaires de commenter ses CSS / LESS / etc.. de manière à générer automatiquement une bibliothèque de motifs / un guide de style :
– Styledocco : ▻http://jacobrask.github.io/styledocco
– KSS : ▻https://github.com/kneath/kssJ’ai essayé grunt-styleguide ( ▻https://github.com/indieisaconcept/grunt-styleguide ), que j’ai utilisé avec Styledocco. Honnêtement c’est vraiment vraiment sympa, voir même un peu magique (puisque styledocco fournit déjà des styles et templates pour le site généré de documentation).
Et je trouve le formalisme styledocco vraiment lisible et agréable : on écrit ses sommentaires CSS en markdown et boum, voilà une super doc qui tient déjà la route.
cc @tetue ?
-
Bon alors j’en profite, puisque tu commences à connaître Grunt et assimilés, et que tu connais SPIP, et que tu parles français.
Donc : est-ce qu’on peut utiliser ce type d’outils dans un projet quelconque, pas du tout JS/Node/etc ? Par exemple, est-ce que je peux utiliser Grunt lorsque j’intègre un site SPIP, dans mes plugins-squelettes et mes plugins-thèmes (découpage Z) ? Et si oui comment ?
-
Par exemple, est-ce que je peux utiliser Grunt lorsque j’intègre un site SPIP, dans mes plugins-squelettes et mes plugins-thèmes (découpage Z) ?
Carrément, Grunt c’est juste un automatiseur de tâches, comme il est JS, et utilise node, il a des affinités avec cet écosystème, mais on peut s’en servir pour n’importe quoi.
Ce qui est intéressant, c’est qu’une fois qu’on a compris comment ça marche, il y a très peu de choses à coder, à écrire. La plupart du temps ça se résume à un path d’entrée (avec du ’globbing’, comme dans zsh - « /repertoire//.js » = tous les fichiers js situés dans répertoire et les sous-répertoires), des options, et un path de sortie (si il y a écriture de fichiers).
Par exemple, pour le guide de style dont je parle plus haut, j’ai juste ajouté ça dans mon « gruntfile » :
styleguide : {
options : {
framework : {
name : ’styledocco’
},
name : ’Guide de style de mon appli’
/,template : {include : [’plugin.css’, ’app.js’]}/
},
doc_projet : {
files : {
’projet/dossier/documentation/’ :’projet/dossier/css’
}
}
et pour lancer la tâche : « grunt styleguide:doc_projet »
Pour faire des squelettes, oui, je pense qu’il doit y avoir des choses intéressantes : optimisation des images, génération automatique de sprite, génération de webfonts, vérification et validation du code JS, concaténation, copie, compression de fichiers etc...
Et si oui comment ?
Je ne sais pas ;) , il y a tellement de plugins, de possibilités, que ça doit partir du besoin. Si vous me donnez des cas concrets, je pourrais en dire plus :)
C’est quoi les trucs qui font braire lorsque tu fais des squelettes ou des thèmes ?Les grandes étapes :
*Niveau Système :
– installer node.js
– installer l’interface cli de grunt ("npm install -g grunt-cli")Niveau Projet :
– créér un fichier ’package.json’ à la raçine du projet (le dossier de ton squelette, je dirais) : soit à la main, en copiant collant un truc trouvé en ligne, soit en tapant « npm init ». Ce fichier contiendra les dépendances et la description de ton projet grunt.
– installer grunt (et les plugins qui t’intéressent) : "npm install grunt —save-dev’. Le flag à la fin va dire à npm (node package manager) d’écrire la dépendance dans le fichier package.json.
L’installation va créer un répertoire node_modules à coté du fichier package.json. La plupart du temps, il faut dire au gestionnaire de source d’ignorer ce répertoire.
– créer un fichier Gruntfile.js (le plus simple est de recopier un exemple sur le site de grunt).
– modifier le Gruntfile.js en fonction de ses besoins et du projet.Bref, l’automatisation d’un projet via grunt peut se résumer à 2 fichiers : le package.json et le Gruntfile.js. Sur la machine de quelqu’un qui a déjà node.js, il suffira juste de taper « npm install » dans le répertoire pour que toutes les dépendances, plugins et autres soient installés.
Pour démarrer :
▻http://gruntjs.com/getting-startedLes plugins :
▻http://gruntjs.com/plugins[edit : comment on fait pour mettre du code dans seenthis ? là mon exemple de path avec globbing casse tout...]
-
Un article à ce sujet par ici : ▻http://mike.teczno.com/notes/being-a-client.html
On y trouve un lien vers cette page : ▻http://codeforamerica.clearleft.com
-
À noter que le dernier lien utilise la même présentation que celui d’A List Apart.
Ya ça aussi, un site où sont collectés tous les modèles et toutes les ressources de Brad Frost autour du #responsive :
▻http://bradfrost.github.io/this-is-responsive/patterns.html
▻http://bradfrost.github.io/this-is-responsive/resources.html -
Sinon pour @0gust1, sur SPIP/Grunt, je ne sais plus… :D
En fait, le Less et le Scss, il y a des plugins qui les compilent magiquement en interne, côté serveur. Puis ensuite il y a déjà un plugin qui compresse tous les CSS et JS, côté serveur aussi. Du coup, il ne reste plus grand chose à faire en local…
Du coup non, pour l’instant, je ne vois pas à quoi ça pourrait me servir. Mais à chaque fois que je vois un article ou une personne qui en parle, je me demande toujours si ça peut m’aider… :D
-
@rastapopoulos : c’est vrai que grunt est souvent utilisé pour du build. Ce qui est aussi intéressant, ce sont les fonctions d’automatisation du workflow de dev :
– grunt-contrib-watch, qui permet de « surveiller » un ensemble de fichiers et lancer automatiquement des traitements si changement (modification, ajout, suppression).
– la génération de sprites et de webfonts d’icônes.
– les outils de qualité de code (jshint).
– les plugins d’upload automatique.Grâce à ça, c’est possible de gagner beaucoup de temps, et surtout de garder son fil de pensées, sa concentration quand on fait de la conception front : j’ai cote à cote mon éditeur et mon navigateur, et au moindre changement, je vois tout de suite le résultat.
-
Je vous rejoins concernant le gain de temps avec Grunt concernant l’automatisation de taches, il faut prendre le temps de bien configurer ses taches et derrière ça roule !
C’est super pratique d’avoir une version dev (avec livereload) sur laquelle travailler confortablement et pouvoir en une ligne de commande générer une version production avec toutes les optimisations nécessaires (compression images, minification, concaténation ...)Concernant les guides de styles j’utilise grunt-styleguide avec KSS comme framework et j’ai publié un article sur le sujet ▻https://medium.com/@JeremyRaffin/4abccdcbab29
Ca permet de pouvoir rapidement générer un styleguide maintenable facilement.
-
-
BBC - GEL (Global Experience Language) - Home
►http://www.bbc.co.uk/guidelines/gel#design #styleguide #webdesign #reference #ux
