Responsive Web Design Patterns | This Is Responsive

/patterns.html

  • Qu’elle classe ce code css ;-)

    Responsive Elements - Semantic
    https://semantic-ui.com/examples/responsive.html

    Bon semantic ui est bien connu, plus qu’il n’est utilisé certainement. Mais en retombant dans mes notes, sur cette page, je suis toujours séduis par l’approche de ce code css.

    Loin des BEM, et autres méthodes verbeuse et finalement lourdes à rédiger, la on est dans la simplicité, tout semble logique, lisible.

    Si on regarde bien comment c’est foutu, on se rends compte que la spécificité des classes est super ciblé, verrouillée, sans pour autant utiliser des classes verbeuse de Block__elm—pod.is-elem-state

    tout est dans ::not ou ~= , ^=

    un peut comme dans une boucle spip quand on enlève ce qu’on veut pas, pour récupérer ce que l’on veut ^^

    L’autre avantage de cette méthode est aussi d’économiser sur les css générées, j’ai fais quelques test et il y’a un gain significatif sur des composant tout bêtes comme des labels, ou icones.

    #css#méthodologies#web-design

    • Sauf que bem n’est pas fait par hasard comme ça, d’une ya la cohérence total avec vraiment 100% toujours la même manière d’écrire mais surtout c’est fait pour être le plus rapide possible à exécuter par les navigateurs.

      .ui.segments:not(.horizontal) > .segment:first-child est très long à compiler et trouver, c’est méga complexe comme sélecteur.

      .segments_vertical .segments__segment:first-child est beaucoup plus rapide

    • +1 effectivement, la ça mérite des tests réels de temps de rendu navigateur, plutôt qu’une estimation de gain en kbytes transférés.

      Quand je vois le pross de mon vieux mac sur une page ou j’ai pas mal d’animations css3, ça peut vite aller dans le rouge suivant comment c’est rédigé. Donc le parcours du dom comme tu le souligne est forcément plus couteux avec des pseudo selector.

      Du coup, ça me donne envi de de réfléchir a un suite de test la dessus. En fait j’ai un petite lib qui est inspiré de bem_selectors, en fait ça gère le nomage des selecteurs, mais en fonction de plusieurs conventions … pour le moment SMACSS, OOCSS, BEM, et Rscss …

      Pour faire ce genre de test, ça peut être interressant, de prendre une page type, et de générer un rapport de perf entre les différentes méthodologies, vu qu’on peut switcher en changeant une map.

    • En fait je n’utilise pas semantic ui, ;-) mais je lis le code de tout le monde, j’aime bien regarder surtout les approches différentes, ça sert toujours un jour, dans une certaine situation ^^.

      Au départ je lisais ceci http://bradfrost.github.io/this-is-responsive/patterns.html#layout

      et cela https://github.com/oddbird/accoutrement-layout

      dans le but de créer un composant/lib scss qui gère tout le layout de manière « générique »… comme on a un support qui commence a être correct de grid et flex, ça simplifie quand même bien le boulot.

    • 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/kss

      J’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 ?

      #grunt #bibliothèque_de_motifs

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

      Les plugins :
      http://gruntjs.com/plugins

      [edit : comment on fait pour mettre du code dans seenthis ? là mon exemple de path avec globbing casse tout...]

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