• #Daisy_Haynes pète une soupape
    https://tradfem.wordpress.com/2019/12/22/daisy-haynes-pete-une-soupape

    Savez-vous ce qui me gave le plus ? Qu’il ait fallu attendre les années 90 pour que le viol conjugal soit reconnu et interdit légalement ! Aujourd’hui encore, les femmes doivent continuer à se battre pour leur droit au contrôle de leur procréation. Nous aimons penser que nous sommes en sécurité au Royaume-Uni, mais nous sommes à un simple coup de crayon d’une perte victorienne de tous nos droits.

    Nous avons écrit des études et des articles par milliers. Nous avons parlé dans les écoles et à la télévision. Nous avons fait face à des critiques de toutes parts, et d’éminentes féministes ont été harcelées de menaces de mort et de viol pour avoir parlé de violence conjugale ou de prostitution. Du côté des Étasuniennes, on vient de faire reculer les droits des femmes de cinquante ans en restreignant la définition de la violence conjugale.

    Ce n’est que depuis quelques années que le contrôle coercitif a été reconnu dans la législation britannique. Les femmes ont été jetées dans des asiles et ont subi des dommages irréparables au cerveau pour les soumettre quand elles osaient se plaindre de leur traitement, ou simplement parce que leur mari voulait se remarier. Aujourd’hui encore, lorsqu’une femme quitte un agresseur ou un coureur de jupons, elle est étiquetée de folle, psychotique, hystérique. La loi a évolué, mais sur le plan social ? Rien n’a changé.

    Traduction : #Tradfem
    Version originale : https://www.facebook.com/daisy.daisy.311056?hc_location=ufi

  • RAF Bombs Diverted to Saudis for Yemen Strikes
    http://www.defensenews.com/story/breaking-news/2015/07/16/britain-diverts-bombs-destined--raf--help-saudi-fight--yemen/30236031

    Britain is transferring Paveway IV precision guided bombs originally earmarked for the Royal Air Force to Saudi Arabia to enable the Gulf state to build stocks of the weapon being used against targets in Yemen and Syria, sources here said.

    The Ministry of Defence has swapped delivery positions on the production line at Raytheon UK to ensure the Saudi Royal Air Force has weapon stocks to continue strike missions with the highly accurate 500-pound bomb.

  • Comment fabriquer des thèmes CSS ? - romy.tetue.net
    http://romy.tetue.net/comment-fabriquer-des-themes-CSS

    Un thème est l’habillage graphique d’un site. Il en définit les éléments identifiants : couleurs, style graphique, etc. Concrètement, il est constitué de déclarations CSS rassemblées dans une feuille de style additionnelle, simplement nommée « theme.css » […], laquelle peut appeler d’autres fichiers : images, polices, etc. Un thème est donc nécessairement rangé dans un répertoire, simplement nommé « /theme ».

    #CSS #Daisy #frontend #thèmes

  • Méthode Daisy, pour du CSS modulaire
    http://daisy.tetue.net

    Plus personne aujourd’hui n’est seul·e à produire son CSS : outil de publication, plugins, intervenants différents… Les styles en vigueur sur un projet ont plusieurs origines. Pragmatique, la méthode Daisy leur donne successivement la main :

    1. posons d’abord la base CSS,
    2. puis laissons passer les plugins additionnels,
    3. et reprennons la main, en dernier, pour définir nos styles spécifiques.

    #CSS #Daisy #frontend

    • Quand on travaille en pré-processeur, il semblerait que 1 et 2 soit entièrement inversé. En effet, en pré-proc on génère un thème en utilisant des frameworks et des modules. Ce qui est dans 3, utilise ce qui est dans 1 en l’incluant directement afin de pouvoir l’utiliser (par exemple avec @extend). « theme.scss » inclut les trucs de 1.

      Or ce qui est dans 2 est ajouté automatiquement par le CMS ou autre outil, de manière externe à la construction du thème. Le 2 est hors pré-proc et a sa propre vie, développé par d’autres et inséré automatiquement.

      Ce qui fait qu’on a alors plutôt 2 / 1 / 3, avec 3 incluant 1 en son début.

      <head>
      - feuilles insérés par le CMS
      - theme.css généré par agrégation, incluant 1 en son début
      </head>
    • Je précise que je parle de ça car la documentation évoque le cas du « pré-processing » :

      Daisy s’utilise de façon progressive, sur mesure : en feuille unique, en trois feuilles, ou en framework CSS multi-feuilles (avec ou sans concaténation, preprocessing , etc.)

      Et donc je commente uniquement ce cas-là. Et même plus précisément en fait : je commente uniquement le cas où on utilise pré-processeur ET un CMS qui ajoute des choses.

    • Le thème (en 3) n’a pas à inclure la base (= 1), jamais, celle-ci devant passer avant (en 2) les outils (dont CMS) et divers plugins.

      La méthode Daisy décrit ce qui se joue dans le navigateur (du CSS donc), quelque soit la façon de le produire (avec ou sans preprocessing).

      En cas d’utilisation avec preprocessing, la personnalisation ne se fait plus seulement en 3 (par surcharge CSS), effectivement, mais aussi sur la base, par paramétrage, des variables. En revanche, il n’y a aucune bonne raison d’intervertir l’ordre d’appel dans le navigateur.

    • J’ai pourtant tenté de l’expliquer : en pré-processing, le thème (les choix personnels pour tel ou tel élément) peuvent appeler un ou plusieurs styles définis dans les feuilles du 1. C’est même une bonne pratique pour ne pas redéfinir des styles similaires en plusieurs endroits.

      Par exemple si on choisit graphiquement d’afficher tel lien précis « comme un bouton », alors on va dire .bloc_truc a{ @extend .button; }. Ce choix personnel peut changer plus tard si on pense que graphiquement ou ergonomiquement ça ne va pas, c’est donc bien dans « theme.css » (3), en revanche la définition générique d’un bouton, c’est bien dans 1. Or pour pouvoir utiliser ce code, tout ce qui est dans 1 doit être importé (@import) au début de 3. Sinon c’est inutilisable et le pré-processing ne sert à rien.

  • 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.

    • Ouais, c’est super cool. C’est super bien découpé selon le même principe #daisy expliqué par @tetue (et à peu près avec les mêmes noms de feuilles en plus, donc encore mieux) mais sauf que si on utilise pas #LESS et bien il est impossible depuis leur site de récupérer facilement les #CSS une par une. On est obligé de traficoter en allant dans le truc configurable et ne cocher qu’une seul case sur toute la page puis télécharger, et ainsi de suite jusqu’à avoir juste les feuilles qu’on veut pour son projet.

      Sinon, c’est très bien d’utilisation, la grille est super, et les facilités pour le #responsive sont bien faites, donc ça va assez vite de construire un site.

      Généralement je prends les trucs de bases : reset, layout, grid, et parfois typo bien que celle de @tetue me convient, et ensuite je mets tout ce qui est uniquement propre au site dans theme.css.

    • Pour mon boulot, j’ai construit un « framework » du même genre, adapté aux besoins du projet. Quand twitter bootstrap est sorti, je leur ai allègrement repompé les parties qui m’intéressaient.

      Je rejoins @rastapopoulos. Twitter bootstrap est bien fichu, le projet est très actif et populaire sur Github (et la documentation est très sympa).

      En effet, j’ai aussi trouvé le module de layout très bien (bien mieux que d’autres frameworks CSS). Je n’utiliserais rarement twitter bootstrap « tel quel », mais il y a beaucoup de choses à y moissonner. Il y a également des choses sympas dans les composants #javascript.

      On trouve aussi sur github d’autres projets basés sur ou compatible avec bootstrap : un thème jquery-ui, pour ceux qui aiment, une version SaSS, des composants UI compatibles, etc. : https://github.com/search?langOverride=&q=bootstrap&repo=&start_value=1&type=Repositories

    • Merci pour ton point de vue. Je me suis lancé aujourd’hui pour tester tout ça dans la perspective de la refonte d’un site perso dans une surcharge de Zpip-dist basé sur le framework. On arrive de fait très vite à des résultats satisfaisants.