#Sass-mq/sass-mq · GitHub
▻https://github.com/sass-mq/sass-mq
A Sass mixin that helps you compose #media_queries in an elegant way. Tags: Sass media_queries #RWD #clevermarks
#Sass-mq/sass-mq · GitHub
▻https://github.com/sass-mq/sass-mq
A Sass mixin that helps you compose #media_queries in an elegant way. Tags: Sass media_queries #RWD #clevermarks
Keep Calm And Write #Sass /via @HugoGiraudel
▻http://slides.com/hugogiraudel/keep-calm-and-write-sass
Tags: Sass #CSS qualité
Des #CSS Kick-Ass avec #Sass /via @HugoGiraudel
▻http://slides.com/hugogiraudel/css-kick-ass-avec-sass
Tags : Sass CSS
Scoped Media Query #Sass Mixin
▻https://github.com/filamentgroup/scoped-media-query
“An element query workaround. A Sass mixin for scoping #CSS styles to apply only within given selector/media query pairs.” Tags: Responsive Web Design (RWD) #Element_Queries Sass CSS #todo:formation:rwd
#IE-friendly mobile-first #CSS with #Sass 3.2
▻http://jakearchibald.github.io/sass-ie
Tags: IE #Mobile_first CSS Responsive Web Design (RWD) Sass
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
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. 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.
Gumby - A Flexible, Responsive CSS Framework - Powered by Sass
▻http://gumbyframework.com
Gumby 2 is an amazing responsive CSS Framework. Websites built today must be mobile friendly in order to survive. Why have two different sites for mobile and desktop when you can have your main site be one size fits all? Gumby Framework is also incredibly customizable; it’s as easy as download, tweak, deploy!
Utilisable avec ou sans Sass, en utilisant des classes de présentation ou des classes « sémantiques » (on se comprend), une bibliothèque d’éléments qui semble super intéressante, une documentation complète, claire et débutants-friendly. Je crois que je suis tombée amoureuse :-P
Quelqu’un l’a testé ?
J’ai passé un peu de temps à lire la doc ce matin, et l’impression que j’en ai pour l’instant, c’est que c’est (encore) un énôôrme truc qui fait tout à la fois et même plus. Je ne doute point que l’on puisse n’en prendre que telle ou telle partie, mais ce n’est ni formulé comme ça, ni conçu pour ça à la base.
J’avais eu meilleure impression quand j’avais lu les sites de Bourbon par exemple, qui a une grille totalement séparée, et pareil pour les styles typo/couleurs qui sont dans un module séparé.
Peut-être que je me fourvoie, mais actuellement mes recherches se tournent plutôt vers trouver chaque grandes fonctions séparément, du moment que c’est bien fichu (mais plusieurs peuvent être dans le même framework aussi hein, s’il est bien fait). Par exemple
– un reset intéressant (meyer ou normalize suivant les écoles)
– une base typo lisible et pratique (tinytypo de @tetue)
– une grille facile conçue avant tout en mixins (Neat de Bourbon par ex)
– etc :)
Oui, c’est aussi mon approche. Et ma pratique. Depuis des années maintenant. Avec la méthode Daisy, qui est faite précisément pour ça, pour modulariser son cadre de travail (framework) en intégration.
Plus ça va, plus je me dis qu’il faudrait que je publie un retour d’expérience…
Oui, mille fois. Prendre le meilleur de ci et le meilleur de ça pour créer son meilleur à soi.
Ceci dit, ce n’est pas trivial : ça demande une bonne compréhension de la logique CSS (héritage, cascade, framework), au moins pour poser ce socle, mais aussi ensuite, dans une moindre mesure, pour s’en servir avec plus de bénéfice que de contrainte :)
Oui @nicod_ : pour se construire un framework il faut utiliser des solutions déjà modulaires ou savoir les modulariser. Ce n’est effectivement pas le cas de KNACSS, qui se veut feuille unique, et qu’il faut donc étudier et morceller. C’est ce que j’avais fait pour un précédent projet, pour lequel j’avais surtout gardé la grille de KNACSS, avec Tiny Typo, évidemment :)
Oui c’est ce que j’allais dire, Knacss n’est pas fait pour être modulaire, donc forcément ça complique les choses pour n’en prendre qu’une partie. Mais pour les frameworks déjà conçus en plusieurs feuilles bien découpées, c’est quand même un peu plus facile.
@TiBounise : ah bin, c’est Tiny Typo ! en moins complet :
▻http://tinytypo.tetue.net/tinytypo.html
Breakup: #Sass component that allows multiple #CSS files from a single Sass partial
▻https://github.com/BPScott/breakup
“Breakup is a Sass component that allows you to create multiple CSS files from a single Sass partial by wrapping your code within breakpoint blocks” Tags: Sass #décomposition #modulaire CSS
Breakpoint
▻http://breakpoint-sass.com
« Breakpoint makes writing #Media_Queries in #Sass super simple. » Tags : Sass Media Queries
Yeah, excellent. Ce qui est bien c’est qu’on a tou⋅te⋅s chez soi, ou au moins lu déjà chez quelqu’un, ce genre de fonction qui aide à la lisibilité. Mais là c’est une lib officielle maintenue sur le long terme. Pratique pour ne pas maintenir la sienne dans son coin.
Et puis, il y a des GIF animés aussi.
Awesomeness: A modular and flexible responsive #framework
▻http://awesomeness.intuio.at
Tags: Responsive Web Design (RWD) framework #CSS #Mobile_first #BEM #Sass
Ça a l’air très intéressant (mais j’ai toujours l’impression qu’on cavale dans tous les sens, des ressources / méthodologies nouvelles chaque jour, des remises en question, des nouvelles pistes, des technos à apprendre…)
@kozlika normal, c’est en mouvement perpétuel (même HTML est un « living standard »)… même si ce n’est pas toujours dans le bon sens. L’intérêt de ce framework semble justement être de consolider pas mal de choses tout en restant modulaire…
Moi je ne comprends pas pourquoi il faudrait obligatoirement Ruby (par ex, mais c’est courant) pour utiliser un préprocesseur CSS. Il faut à mon avis absolument distinguer la syntaxe (SCSS en l’occurence) et les moyens de le compiler, qui par défaut viennent de Ruby, mais qui peuvent théoriquement être programmés autrement ensuite.
Là ce n’est pas juste le compilateur SCSS qui est en Ruby (et il en existe désormais, même imparfaits, dans d’autres langages, PHP, Python etc). Non, il y a du code Ruby dans les dépôts des frameworks eux-mêmes ! Compass, Susy, etc !
C’est parfaitement rébarbatifs quand on veut intégrer ça n’importe où, et je ne trouve pas ça très propre. Ça fait que c’est moins générique et universel. Ou en tout cas il faut faire plus d’efforts quand on veut les utiliser dans d’autres projets quelconques. Moi ça me rebute alors même que j’ai commencé à apprendre et utiliser le SCSS et que je voudrais l’insérer plus souvent partout (@touti a porté un compilateur SCSS dans SPIP par exemple, sur le même principe que celui de LESS).
Bref, c’est un peu une digression, mais dès qu’il y a un super nouveau framework qui sort, et qu’on me dit « install ruby », j’ai juste envie de me barrer.
@rastapopoulos : j’utilise Sass sur mon poste avec Ruby sur mon poste, et je ne déploie que la CSS générée. Il y a un souci avec Ruby que je ne connaîtrais pas ?
(question de profane)
@rastapopoulos Ruby est une dépendance comme une autre sur le poste de dev, je ne vois pas le problème.
Je l’ai expliqué précédemment : Ruby est le langage du premier compilateur (il s’agit de compilation d’un langage), mais ce langage lui-même, SCSS, sa syntaxe, ne devrait PAS être dépendant d’un autre langage : si d’autres personnes développent des compilateurs autrement (PHP, Python, JS, etc), tout devrait marcher pareil sans aucune dépendance à Ruby.
Quand tu fais du Java (par exemple), tu écris dans ce langage, et personne ne t’oblige à utiliser tel compilateur précis, il en existe plusieurs, certains écrits en C, d’autres en Java, etc.
C’est pareil pour les préprocesseurs : si tu es intégrateur, développeur front, tu apprends le SCSS et ensuite qu’il soit compilé en Ruby, en PHP ou autre ne devrait pas spécialement être ton affaire.
Et justement, la compilation ne se fait pas forcément sur le poste de dev : on peut avoir un compilateur côté serveur qui met les fichiers compilés en cache, et chez soi, un dev n’a qu’à toucher les feuilles SCSS ou LESS.
dès qu’il y a un super nouveau framework qui sort, et qu’on me dit « install ruby », j’ai juste envie de me barrer.
J’ai eu ce genre de réaction vis à vis de Sass. Au boulot, on a un environnement hétérogène (Windows, Linux, macOS)... une dépendance supplémentaire à gérer... bof (Et pourtant, j’essaierais bien Ruby :-)
@rastapopoulos ok, Ruby ne doit pas être une dépendance, mais alors que certains développent des compilateurs aussi complets et à jour dans d’autres langages. Je ne suis pas sûr que ce soit le cas, ni que ce soit pertinent vu la déperdition d’énergie que cela provoque.
Pour ce qui est de la compilation en prod, je suis contre, c’est trop risqué.
Faut-il limiter le nombre de #Media_Queries ? (Sass and Media Queries)
▻http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries
"Does combining the media queries have any actual performance improvements? Are people simply raising issue because they don’t like the way the output CSS looks? That’s a damn good question and one that Aaron also raised. As he put it, “Let’s ask science!”" Tags: Media Queries Responsive Web Design (RWD) #Sass #webperf
Mobile-first Responsive Web Design and #IE8 | theguardian.com
▻http://www.theguardian.com/info/developer-blog/2013/oct/14/mobile-first-responsive-ie8
"when supporting older, buggy and incapable browsers, we have to wave some of the “good ol’ web best practices” goodbye... so, how do we make sure we don’t cripple our codebase with hacks for #Internet_Explorer so the other 95.5% of our readers still benefit from the best experience possible?" Tags: Responsive Web Design (RWD) IE8 Internet Explorer #Sass #CSS #Media_Queries
#Plugin_SPIP #scssphp
téléchargeable sur ►http://plugins.spip.net/scssphp.html
compile en CSS et mets en cache les fichiers .scss
grace à ▻http://leafo.net/scssphp
Permet d’utiliser #SASS, un #préprocesseur_CSS et ses diverses possibilités dans #SPIP,
voir les discussions poursuivies sur seenthis à ce propos
►http://seenthis.net/messages/199765
▻http://seenthis.net/messages/204846
Les @import sont surchargeables dans les squelettes sans avoir à toucher aux originaux des éventuels #frameworks qui disposeraient de fichiers sass, par exemple #knacss
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/knacsss
Le code de ce plugin a été pompé de celui déjà existant pour less
►http://plugins.spip.net/lesscss.html
J’y connais rien mais je dis #spip_blog quand même... ;)
Yeah, merci @touti pour cette intégration de librairie à SPIP. Ça faisait longtemps que ça me trottait aussi dans la tête, mais tu as eu le courage et pris le temps de le faire : gloire à toi ! \o/
Et à nous les super mixins et le HTML qui redevient sémantique !
Merci @rastapopoulos et @nicod_, car nos diverses discussions m’ont permis de concrétiser un peu les choses avec scss.
Le but après avoir tenté de comprendre les imbrications actuelles entre html5/elasticité/grille/css/jsforIE, est de pouvoir simplifier la méthode de fabrication d’un site mais aussi, tenter d’échapper à Bootstrap, et faire que dans tout ce joyeux bordel l’#artisan-web (que je suis) ne se retrouve pas juste bouton pressoir ou assembleur de cascades à la chaine ;)
Pas sûr cependant que SASS permette de faire du simple, facile pour tous, dont la relecture soit aisée, sans attaches à un framework lourd, et entre autres rêves d’indépendance, autorise à se passer des class le plus possible.
J’ai aussi très envie d’une optimisation en légèreté avec une css de maximum… 25ko, ce qui devrait être suffisant pour : faire un beau site, alléger le poids des fichiers envoyés au serveur/client et faciliter la prise en main et la maintenance.
Avec des structures HTML adéquates, et ta piste d’échafaudage @rastapopoulos ▻http://seenthis.net/messages/204846#message205077 que tu nous expliqueras hein ! ça risque d’être bien sympa.
@seenthis : y’a un drôle de bug qui fait que je retrouve ce seen systématiquement épinglé en favoris chaque fois que je reviens sur Seenthis…
Tetris & The Power Of CSS
▻http://www.heydonworks.com/article/tetris-the-power-of-css
To be really good at #CSS, you have to learn CSS. I know this sounds like a tautology but I’ve become aware of a peculiar attitude that preprocessors such as #SASS are somehow successors to CSS. (…)
They forget that all preprocessors do is make writing CSS easier, not qualitatively different: It’s still CSS that comes out of the end. This is a shame, because vanilla CSS deserves some credit for being a powerful, rule-based language all its own and — when it comes to solving the kind of #design problem I shall be exploring in this post — it doesn’t matter how you “preprocess” the CSS; it’s the naked CSS logic that does the heavy lifting.
Put down your classes, ladies and gentlemen, because we’re talking about dynamic content and they cannot save you now.
L’emploi à tout bout de champs des preprocesseurs CSS me chagrine un peu : la plupart du temps (3/4 des cas, je dirais) c’est assez peu justifié. On vient ajouter une couche technologique supplémentaire sur un projet, qui va compliquer la prise en main, la maintenance, l’appropriation future et la perennité.
Pasque ça faisait mieux dans la phrase :o)
Blague à part, « pérennité » c’était comme conséquence des effets précédents.
Les préprocesseurs répondent en partie à des besoins qui seront bientôt couverts nativement par CSS. Dans certaines utilisations, on peut donc les voir comme des outils de transition, à durée de vie limitée, qui risquent de se « périmer ». Enfin, tous les intégrateurs et webdesigners n’ont pas forcément les compétences techniques / le temps / l’envie pour mettre en -œuvre et déboguer ce que génèrent les préprocesseurs.
Par contre, je ne suis pas « opposés » aux préprocesseurs, dans certains contextes (outils « thémables », sprites, etc...), ils peuvent être très utiles.
Simple, blog-aware, static sites
Second Crack (#PHP)
▻http://www.marco.org/secondcrack
Its input is simply a directory of Markdown text files, and a basic transformation script automatically renders the blog HTML from them as needed.
You can browse or download the source code on GitHub here.
Jekyll (#ruby)
►http://jekyllrb.com
Transform your plain text into static websites and blogs.
Simple
No more databases, comment moderation, or pesky updates to install—just your content.
Static
Markdown (or Textile), Liquid, HTML & CSS go in. Static sites come out ready for deployment.
Blog-aware
Permalinks, categories, pages, posts, and custom layouts are all first-class citizens here.
Hyde (#python)
▻http://hyde.github.io
Hyde is a static website generator written in python. While Hyde took life as awesome Jekyll’s evil twin, it has since been completely consumed by the dark side and has an identity of its own.
Pour mériter la mention de « blog » un site doit permettre l’interaction - si possible le trackback et au moins le commentaire. Un site statique est fort pratique, mais ce n’est pas un blog... A moins d’abandonner les commentaires à un service tiers et perdre ainsi son indépendance.
Mof, un blog c’est avant tout une suite d’articles réguliers, présentés du plus récent au plus vieux (= log, journal). Et c’est tout. Le fait qu’il y ait des commentaires ou pas n’a aucune incidence, un blog c’est pas forcément fait pour discuter, mais avant tout pour publier du contenu, dans un ordre daté.
Justement, je suis persuadé que l’essence même de la publication est la participation à une discussion - fut-elle sous-entendue... Même un blog purement statique, sans fonctionnalité de commentaires, participe à une discussion. Je déplore donc que le trackback ne soit pas plus pratiqué - le maillage des articles les enrichit mutuellement. De même, j’espère qu’un protocole tel que Salmon (►http://www.salmon-protocol.org) parviendra à redonner une unité aux discussions éclatées dans les réseaux décentralisés.
32 Static Website Generators For Your Site, Blog Or Wiki
▻https://iwantmyname.com/blog/2011/02/list-static-website-generators.html
Sometimes, all a geek needs is a quick way to generate a static site and put it up on a server or hosting service like Amazon S3 or GitHub Pages. We’ve compiled a list of static website generators that can be used for exactly this purpose:
#Blatter #Blogofile #Bonsai #Chisel #Dynamicmatic #Frank #Hobix #Hyde #ikiwiki #Jekyll #Jinja #Korma #Lanyon #Mako #Markdoc #Middleman #nanoc #Pagegen #Stacey #Tahchee #Templeet #Toto #ttree #Pelican #Poole #Pubtal #Sphinx #StaticMatic #Static #Vee #Webby #Webgen
Hu ça existe encore Templeet, excellent ! J’avais testé ça ya longtemps quand j’étais à l’IUT, ça avait l’air excellent, et j’avais l’intention de l’utiliser comme noyau pour me faire un CMS... Et puis ensuite je suis tombé dans SPIP et je n’ai plus vraiment eu le temps d’approfondir.
#Pelican 3 documentation
▻http://docs.getpelican.com
Pelican is a static site generator, written in Python.
Write your content directly (...) in reStructuredText, Markdown, or AsciiDoc formats
Includes a simple CLI tool to (re)generate your site
Easy to interface with distributed version control systems and web hooks
▻https://github.com/getpelican/pelican/blob/master/docs/report.rst
avec des plugins :
▻https://github.com/getpelican/pelican-plugins
et, comment rajouter un type de fichier :
▻http://docs.getpelican.com/en/latest/plugins.html#recipes
via @karlpro et @ametaireau
La doc Pelican en français ;-)
▻http://docs.getpelican.com/en/3.2/fr/index.html
“simple git-backed microsites” (en #ruby) :
▻https://www.petekeen.net/simple-git-backed-microsites
▻http://leeflets.com
Pour gérer des sites en une page (one pager). Très facile à installer et à utiliser...
▻http://dropplets.com
Pour faire un blog tout en drag’n’drop. C’est très limité en fonctionnalités, mais simple et agréable à utiliser...
et pour les forums, tester #nononsense, décrit ici
►http://seenthis.net/messages/218113
divers services (commerciaux) qu’on peut brancher sur un site
▻http://cloudcannon.com/tips/2014/12/12/the-ultimate-list-of-services-for-static-websites.html
(il y a une certaine contradiction dans tout ça)
Pourquoi je n’utilise pas les préprocesseurs CSS ?
Ils complexifient CSS
Ils n’ajoutent pas de fonctionnalités CSS aux CSS
Ils ne font pas (toujours) gagner de temps
Ils peuvent être dangereux pour le standard CSS (et provoquer une confusion)
▻http://blog.iamvdo.me/post/45259636008/pourquoi-je-nutilise-pas-les-preprocesseurs-css
Voir aussi : ▻http://blog.goetter.fr/post/46331150918/les-preprocesseurs-et-moi#_=_
Tout cela résume bien mon opinion sur le sujet.
#Sass_&_Bide - #Prêt-à-porter - Automne-hiver 2013-2014
▻http://www.flip-zone.com/fashion/ready-to-wear/independant-designers/sass-bide
▻http://img-new3.flip-zone.com/local/cache-vignettes/L600xH382/489076a2b5cab37c183f1a0e9c84b4bc-8c140.jpg Photos : PixelFormula #mode
hint.css - A tooltip library in CSS
▻http://kushagragour.in/lab/hint
Hint.css is a tooltip library written in SASS which uses only HTML/CSS to create simple tooltips.
It does not rely on any JavaScript and rather uses data-* attribute, pseudo elements, content property and CSS3 transitions to create the tooltips. Also it uses BEM naming convention particularly for the modifiers.
#SASS : Syntactically Awesome Stylesheets : un métalangage de feuilles de style en cascade (CSS). C’est un langage de script interprété en tant que CSS.
▻http://en.wikipedia.org/wiki/Sass_(stylesheet_language)
#maitre_capello ^^
Alors je continue :)
#BEM (pour Block, Element, Modifier) : Une convention de nommage des styles CSS avec une approche « Orienté Objet »...
▻http://bem.info/method/definitions
#LESS : un langage pour programmer des feuilles de styles dynamiques (traitées en javascript pour produire des feuilles de styles statiques).
►http://lesscss.org