• CUBE #CSS - Piccalilli
    https://piccalil.li/blog/cube-css

    In this article, I’m going to tell you about how I like to write CSS, which I think could help a lot of folks—at least I hope so—because I’ve used this approach, or an earlier iteration of this approach, to power massive websites, tiny blogs, mobile apps and even intranet software! This #methodology has roots in both huge projects that service millions of people all the way down to small websites and starter kits, thanks to its flexibility. This Flexibility has also enabled CUBE CSS to work in both very old and very new codebases.

    The focus of the methodology is utilising the power of CSS and the web platform as a whole, with some added controls and structures that help to keep things a bit more maintainable and predictable. The end-goal is shipping as little CSS as possible—leaning heavily into progressive enhancement and modern techniques. I hope by the end of the article, it’ll help you to re-think how maybe you write CSS in the future.

    What is CUBE CSS?

    CUBE stands for Composition Utility Block Exception, and CSS stands for, y’know, CSS (Cascading Style Sheets). As mentioned before, the CUBE methodology is very much an extension of good ol’ CSS, rather than a reinvention. This mantra is very seriously maintained too, as the cascade and inheritance particularity play a big role.

    This isn’t a heavily documented, complex methodology. Well, not now, anyway. It’s more of a concept method of organising CSS just enough to not pull to far away from the “classic” way of writing it. Really, it’s more of a thinking structure.

    I’ve been all the way down the micro-optimisation rabbit hole and been down the “let’s build a library of skeletal components for all projects” (this almost never brings any benefit). On the opposite end of the scale, I’ve done all globals with direct HTML tag styling, too. Any method is extremely valid for your context and if this is how you write your CSS, keep doing what works for you and your team. All I would recommend is keeping other team’s contexts and caveats in mind before you recommend your way as absolute.

    #BEM_alternative

    • #intégration #web #html #css #méthodologie

      2-3 trucs que j’ai trouvé intéressant :
      – séparer la notion de composition (layout quoi), cela dit il ne donne aucun exemple de code et de comment l’appliquer, et au final pour moi c’est un peu comme un « module »/block particulier, dont on ne connait pas les éléments intérieurs (BEM permet sans aucun problème d’avoir des blocks dans des blocks, donc par exemple avoir un block « card » dans un block « colonnes_3 » …)
      – le fait de ranger les classes CSS dans le HTML lui-même, à la fois dans un ordre logique ET le plus important avec un séparateur, qui sera parfaitement ignoré par HTML (je trouve ça pas mal avec juste pipe | c’est léger et ça fait bien le job)
      – le fait de mettre les variantes dans des data- du HTML… ce qui les rend plus facile d’accès au JS aussi… bon j’ai trouvé ça intéressant mais ça reste à voir, si vraiment utile par rapport à des classes de variante en plus…

    • C’est intéressant même si je ne suis pas d’accord avec le démarrage de sa réflexion sur le faire qu’un wireframe c’est forcément un dessin statique (et donc dans son argumentation pas responsive etc).

      Du coup c’est déjà un peu ce qu’on fait, puisqu’on commence par mettre des blocs de contenu (faux ou plus précis suivant ce qu’on connait comme détails à ce moment) dans du HTML. Puis on style ce HTML en bloc que l’on place petit à petit. On pourrait aller plus loin et vraiment commencer par TOUT mettre en détail et faire valider cette liste de choses à placer dans un ordre de priorité, puis le styler une fois que c’est validé seulement.

      Mais du coup ses documents de priorités il continue de les faire en pixels, alors qu’on peut parfaitement les faire en HTML directement (et donc au départ c’est mobile first tant qu’on n’a rien stylé oui mais on PEUT les styler ensuite, ce qui n’est pas possible avec un truc statique).

      Bref, ça va dans le bon sens, mais je pense qu’il faut continuer à améliorer dans la voix de partir directement sur le HTML, jamais depuis un outil statique : aussi puissant qu’ils peuvent être (sketch etc), je trouve que c’est obsolète, des outils du passé, pour la majorité des cas.

      #conception #web #prototype #design #maquette #méthodologie #bonnes_pratiques

    • Alors je suis tout à fait d’accord, je viens encore d’en faire les frais ^^ Les outils comme sketch ou autre enferme dans une reflexion « pixel perfect » qui effectivement viens du print ou tout du moins tendrait a y ressembler.

      Le problème c’est aussi les gens qui utilisent le logiciel. Je retrouve les mêmes erreurs de conception de document, identiques a quand je faisais de la production et que j’executais les doc des directeurs artistique (ex 30 couleurs aucune dans le même format).

      On récolte donc des protos, conçues par des gens qui n’on jamais intégré ou conscience du markup, ni des implications de leurs choix graphiques.

      En exemple le plus courrant, des titres qui change de place suivant le mode mobile, mais change de bloc container : on se retrouve a dupliquer le code, a masquer en aria-hidden pour pas que les lecteurs vocaux double… bref moi j’aime pas et généralement on peut faire sans …

      Ce sont des méthodes ou type de réflexion, qui vont a l’encontre du progressive enhancement, et du mobile first.

      La en tout cas ce concept est intéressant car on pense la page en fonction du contenu réel : ce qui est totalement l’inverse des méthodes les plus couramment employées, encore largement tirés du print, sauf que l’ont à enlevé des étapes comme le calibrage ^^, et que maintenant on nous envoie le contenu quand le travail est fini, on marche à l’envers.

      Il y’a quelques années, j’avais été intéressé, par un projet Project Hub lancé par Brad Frost (Atomic Design methodology) : https://github.com/bradfrost/project-hub. En fait l’idée est de constatent garder le fil avec le client en le poussant a participer (genre Agile) . Je pense que l’implication, le suivi, le déroulement devrait faire partie d’un seul outil ou chaque intervenant à accès aux infos, a la timeline, des notifications rappels, guideline, …

      Dans un outil qui gérerait l’ensemble de la progression, l’exemple cité dans l’article peut effectivement permettre au SEO, marketeux de faire leur sauce en parallèle de l’intégrateur, sans interférer avec la partie purement dev.
      Je pense que réfléchir parallèlement ainsi pourrait éviter pas mal de problème pour ceux qui sont en fin de chaine, et surtout amener à se poser les bonnes questions sans penser QUE cosmétique mais contenu. Certainement un gain de temps aussi quand on travaille a plusieurs intervenants, …