• @mist_
    Mist. GraphX
    1
    @spip
    1

    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

    Mist. GraphX
    • @rastapopoulos
      RastaPopoulos CC BY-NC

      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

      RastaPopoulos CC BY-NC
    • @mist_
      Mist. GraphX

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

      Mist. GraphX
    • @mist_
      Mist. GraphX

      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.

      Mist. GraphX
    Écrire un commentaire