Project

General

Profile

Evolution #4391

Squelettes de la dist : améliorer le markup et passer à BEM

Added by tcharlss (*´_ゝ`) about 1 month ago. Updated 25 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
code généré
Target version:
Start date:
10/13/2019
Due date:
% Done:

0%

Resolution:

Description

Hello,

En voulant créer des nouveaux thèmes pour les squelettes de la dist, j'ai rencontré des limitations dûes au markup actuel.

Par exemple, certains éléments sans classe sont impossibles à cibler, il y a des retours lignes en dur, etc.
En certains endroits, cela limite pas mal les possibilités.
J'aimerais lancer un petit refactoring du markup afin qu'il soit plus facile de thémer les squelettes et de maintenir les styles.

Il s'agirait principalement d'améliorer la nomenclature des classes, en changeant le moins possible le markup afin que les thèmes actuels restent compatibles (ou au prix d'adaptations minimes).
On ajouterait donc des nouvelles classes, sans supprimer les classes actuelles (dans un 1er temps tout du moins ?).
Cela pourrait être l'occasion de passer à la méthodologie BEM pour la nomenclature des classes.

Exemple n°1

Exemple avec le copyright et les liens dans le footer.
Actuellement, il n'y a pas de classe autour du copyright, les liens ne sont pas encapsulés dans un conteneur, et les séparateurs « | » n'ont pas de classe n'ont plus.
Il est donc quasiment impossible de changer l'agencement général, de changer l'apparence des séparateurs, etc.

<p class="colophon">
    2009 - 2019 Thèmes SPIP
    <br>
    <a rel="contents" href="..." class="first">Plan du site</a>    | <a href="ecrire/">Espace privé</a> | <a href="..." rel="nofollow">Se déconnecter</a> | 
 <a rel="nofollow" href="...">Contact</a> | <a href="..." rel="alternate" title="Syndiquer tout le site" class="last">RSS&nbsp;2.0</a>
</p>
Voici ce que ça pourrait donner en refactorisant :
  • Le copyright est encapsulé dans un span
  • Les liens sont considérés comme faisant partie d'un menu, et sont donc encapsulés dans un composant « menu »
  • Les séparateurs sont fait en CSS, pas en dur dans le HTML
<p class="colophon">
    <span class="colophon__coyright">2009 - 2019 Thèmes SPIP</span>
    <div class="colophon__menu">
        <ul class="menu menu_footer">
            <li class="menu__item menu__item_plan">
                <a href="..." class="menu__link first" rel="contents">Plan du site</a>
            </li>
            <li class="menu__item menu__item_backoffice">
                <a href="...">Espace privé</a>
            </li>
            <li class="menu__item menu__item_logout">
                <a href="..." class="menu__link" rel="nofollow">Se déconnecter</a>
            </li>
            <li class="menu__item menu__item_contact">
                <a href="..." class="menu__link" rel="nofollow">Contact</a>
            </li>
            <li class="menu__item menu__item_rss">
                <a href="..." class="menu__link last" rel="alternate" title="Syndiquer tout le site">RSS&nbsp;2.0</a>
            </li>
        </ul>
    </div>
</p>

Avec ça, on peut faire beaucoup plus de choses : afficher le copyright et le menu côte-à-côte ou l'un sous l'autre, afficher le menu à l'horizontale ou à la verticale, choisir l'apparence des séparateurs, etc.

Exemple n°2

Autre exemple avec les résumés d'articles.

<li dir="ltr" class="hentry clearfix text-left">  
    <strong>
        <a href="...">
            <img src="..." class="spip_logo" alt="" width="150" height="185">
            Joie entourée d’angoisses (1)
        </a>
    </strong>
    <br><small>6 mai 2009, par  Victor Hugo</small>
    <div class="introduction entry-content">
        <p>
            Lorem ipsum&nbsp;(...)
        </p>
    </div>
</li>
En refactorisant :
  • Le composant de base est nommé « resume », et on voit qu'il s'agit d'une variante « article ».
  • Tous les éléments ont une classe.
  • Le titre est encapsulé dans un <h3> plutôt qu'un <strong>.
  • L'image est sortie du titre, et sa largeur n'est pas limitée à 150px (ça se ferait en CSS).
<li dir="ltr" class="resume resume_article hentry clearfix text-left">  
    <img src="..." class="resume__logo spip_logo" alt="" width="960" height="480">
    <h3 class="resume__title">
        <a href="...">
            Joie entourée d’angoisses (1)
        </a>
    </h3>
    <small class="resume__publication">
        <span class="resume__date">6 mai 2009</span><span class="sep">,</span> <span class="resume__author">par Victor Hugo</span>
    </small>
    <div class="resume__content introduction entry-content">
        <p>
            Lorem ipsum&nbsp;(...)
        </p>
    </div>
</li>

Voilà, ce ne sont que des exemples et non pas des propositions définitives.
C'est juste pour montrer la direction dans laquelle aller.

HTML5

Il est tentant de vouloir en profiter pour passer en HTML5, mais je préfère laisser cet aspect à part (il y a déjà des tickets dessus je pense).

Français/anglais ?

Actuellement pour la nomenclature des classes, il y a un mélange de français et d'anglais. Personnellement, ça ne me dérange pas :)
J'ai arrêté d'essayer de tout franciser à tout prix, je préfère partir sur une base en anglais, avec quelques éléments en français quand il n'y a a pas le choix (par exemple quand on fait référence aux objets spip : breve, rubrique, etc.).

Cahier des charges

  • Faire en sorte que les thèmes existants restent globalement compatibles (moyennant peu d'adaptations).
  • Passer la nomenclature des classes à BEM.
  • Ajouter des classes sur tous les éléments n'en ayant pas.
  • Retirer les retours ligne en dur : <br />.
  • Travailler dans une branche nommée « bem » du dépôt git : https://git.spip.net/SPIP/dist/
  • Pas de HTML5 pour l'instant.
  • Classes en english avec des exceptions en français

History

#1 Updated by erational 👺鬼 about 1 month ago

Salut

+1 !

Cela me semble vraiment une bonne démarche que d'adopter la méthodologie BEM.

Je ne suis pas sur qu'il faille conserver les noms des anciennes classes (hormis peut-être celles de modèles médias).
Sinon on va obtenir quelque chose de très verbeux.

Le but de la dist est d'être aussi un support pédagogique et montrer les bonnes pratiques.
Je serai donc pour obtenir les nouvelles classes et le support du HTML5 dès maintenant.

Rien n’empêche de distribuer une dist-vieux pour les personnes qui ne veulent rien casser.

Pour BEM, comme pour PSR, il faudrait écrire un document de référence de nos conventions.
A titre personnel, je serai pour adopter les noms de classe en français, une casse minuscule (éviter la camelCase).

Merci pour ce chantier.

#2 Updated by RastaPopoulos ♥ about 1 month ago

+1 évidemment :)

#3 Updated by tcharlss (*´_ゝ`) about 1 month ago

Pour BEM, comme pour PSR, il faudrait écrire un document de référence de nos conventions.
A titre personnel, je serai pour adopter les noms de classe en français, une casse minuscule (éviter la camelCase).

Oui c'est une bonne idée.
En principe les conventions de nommage de BEM couvrent déjà la majorité des cas de figure.
Par exemple, le camelCase est explicitement proscrit : tout doit être en minuscule, les mots composés étant séparés par le trait du milieu : « camel-case ».
Je serais pour simplement adopter le BEM, sans y faire d'ajout ou d'exception.

À la rigueur ajouter une recommandation sur une éventuelle préférence pour le français ou l'anglais.
Je n'ai pas d'avis tranché là dessus.

Je serai donc pour obtenir (...) le support du HTML5 dès maintenant.

J'aimerais bien aussi :)
Ça supposerait devoir régler quelques tickets corollaires si je ne m'abuse : #3664, #4202
RastaPopoulos faisait aussi remarquer que le HTML5 ne devrait pas être activable via l'espace privé, mais déclaré par les squelettes eux-mêmes, je suis d'accord.
Peut-être ouvrir un ticket à part pour la question ?

Je ne suis pas sur qu'il faille conserver les noms des anciennes classes (hormis peut-être celles de modèles médias).

Sinon on va obtenir quelque chose de très verbeux.

Oui, c'est toujours le dilemne.
Après, il n'y a tant de thèmes que ça pour la dist, peut-être qu'ils peuvent avoir une v2 adaptée à cette version de la dist tout simplement, ce qui éviterait de devoir se trimballer les vieilles classes.

#4 Updated by tcharlss (*´_ゝ`) about 1 month ago

En parlant de conventions d'écriture pour les squelettes, il y a un autre sujet qui pourrait être abordé.
Souvent le code est écrit de façon à éviter de produire des espaces blancs et sauts de ligne inutiles dans le HTML compilé.
L'intention est louable, mais ça se fait au détriment de la lisibilité du code : des fois il en devient quasiment illisible et du coup compliqué à maintenir.

Il me semble qu'avec la compression activée sur les serveurs, ça n'a du coup plus aucun intérêt, à part pour les gens qui regarde le code source des pages.

#5 Updated by tcharlss (*´_ゝ`) about 1 month ago

Par exemple, le camelCase est explicitement proscrit

J'ai parlé trop vite, ça c'est le schéma classique, mais il y a des schémas alternatifs possibles : https://en.bem.info/methodology/naming-convention/#alternative-naming-schemes

Mais quoiqu'il en soit ça me semble préférable de rester sur le classique.

#6 Updated by nicod _ about 1 month ago

Cela pourrait être l'occasion de passer à la méthodologie BEM pour la nomenclature des classes.

+1 bien sûr
J'y pensais justement aujourd'hui sur les formulaires spip.
Aujourd'hui on est obligés de faire de la cascade css pour les styler, et c'est rapidement compliqué de créer des déclinaisons sans surcharge des tonnes de trucs.

Donc j'irais plus loin que toi, et je serais pour BEMiser les formulaires et les saisies aussi (autre ticket à ouvrir sûrement).

Par contre :

Pas de HTML5 pour l'instant.

Pourquoi ?

Classes en english avec des exceptions en français

Why ?

Il me semble qu'avec la compression activée sur les serveurs, ça n'a du coup plus aucun intérêt, à part pour les gens qui regarde le code source des pages.

+1
La syntaxe de nos squelettes est déjà assez exotique, mais les crochets optimisés pour gagner une ligne vide, ça les rend souvent illisibles.
Si on veut vraiment optimiser, HTMLminifier et zou.

#7 Updated by nicod _ about 1 month ago

J'ai parlé trop vite, ça c'est le schéma classique, mais il y a des schémas alternatifs possibles : https://en.bem.info/methodology/naming-convention/#alternative-naming-schemes

Oui, on peut adapter BEM à ses propres habitudes, mais autant adopter le schéma "officiel", ce sera plus simple pour tout le monde.

#8 Updated by nicod _ about 1 month ago

Par contre, contrairement à ta proposition, où tu définis un nouvel élément "menu__item_plan" :

<li class="menu__item menu__item_plan">

j'utiliserais plutôt un modifier de "menu__item" :

<li class="menu__item menu__item--plan">

Remarque hautement philosophique, je le reconnais :)
Mais tant qu'on évite la cascade, on y gagnera.

#9 Updated by nicod _ about 1 month ago

erational 👺鬼 a écrit :

Je ne suis pas sur qu'il faille conserver les noms des anciennes classes (hormis peut-être celles de modèles médias).
Sinon on va obtenir quelque chose de très verbeux.

C'est le risque, d'être verbeux dans la dist, mais il y a beaucoup de spip-dist un peu customisés en ligne, et ce serait une rupture de compatibilité de casser ça.

#10 Updated by RastaPopoulos ♥ about 1 month ago

@nico le "plan" est bien un modifier chez tcharlss, dans BEM il n'y a plus "--" depuis pas mal de temps dans la doc officielle. La version en cours c'est DEUX "_" = un sous-élément, UN "_" = un modifier. :)
Les tirets ne sont plus utilisés que pour séparer les termes multi-mots (comme le disait tcharlss plus haut, à la place du camelCase).

#11 Updated by b b about 1 month ago

Ne pratiquant pas BEM je ne peux pas vraiment donner d'avis pertinent sur le sujet, mais j'ai deux remarques :

- je ne pense pas que la version cible est la 3.3, 3.4 ou plus à la limite
- pensez-vous que BEM est un truc utilisé par les personnes qui bidouillent leur site à partir de la dist ? Il ne faut pas oublier ce que disait tetue plusieurs fois, la dist est un squelette qui se veut pédagogique et simple d'accès. Si BEM est le truc standard qu'il faut absolument connaître pour faire du web aujourd'hui, très bien, la dist permettra aux gens de découvrir ça, mais si ça n'est pas le cas ça ajoute un "pré-requis" de plus pour les personnes qui débutent (la fameuse première marche).

#12 Updated by RastaPopoulos ♥ about 1 month ago

Une des bonnes pratiques les plus importantes en CSS de base c'est faire le moins de cascade et de multi-classes possible (le moins de sélecteurs compliqués quoi) car 1) c'est très coûteux en calcul et 2) c'est très compliqué à surcharger ensuite quand on arrive après.

BEM est la solution la plus utilisée il me semble pour répondre à ce besoin de faire le moins de cascade possible, et il force à réfléchir en terme modulaire en plus du coup. Donc oui ça me parait la méthode la plus simple pour apprendre les bonnes manières d'écrire du CSS brut (donc sans parler les trucs méga compliqués pré/post processeurs etc).

#13 Updated by tcharlss (*´_ゝ`) about 1 month ago

j'utiliserais plutôt un modifier de "menu__item" : <li class="menu__item menu__item--plan">

Cf. remarque de RastaPopoulos (qui a posté pendant que j'écrivais ma réponse :p)
Il y a encore beaucoup de guides officieux qui ne sont pas à jour sur ce point.
Le guide officiel : https://en.bem.info/methodology/naming-convention/

Pas de HTML5 pour l'instant.

Pourquoi ?

Je pensais qu'il y avait encore des points bloquants ou tout du moins genants, mais finalement ça ne semble pas être le cas.
Donc go go go pour le HTML5, mieux pour la sémantique et l'accessibilité.

Classes en english avec des exceptions en français

Why ?

Français ou anglais, ou mélange des 2, je n'ai pas d'avis vraiment tranché là dessus. Est-ce qu'il y a un consensus à ce sujet ? (dans ce cas, on continue comme ça et on en parle plus :p)
Mon avis en 2 mots, c'est que c'est en général moins verbeux, et ça rend le code accessible aux non francophones.

Je ne pense pas que la version cible est la 3.3, 3.4 ou plus à la limite

Ok pour 3.4. Mais on ne sait jamais, ça pourrait être prêt avant :)
Je te laisse modifier, j'ai pas le droit d'éditer le ticket.

pensez-vous que BEM est un truc utilisé par les personnes qui bidouillent leur site à partir de la dist ?

Bis, cf. remarque de RastaPopoulos qui poste plus vite que son ombre concernant les perfs.
C'est juste un standard parmis d'autres (OOCSS, SMACSS...), mais il me semble que c'est un des plus simples et un des plus utilisés.

Après, je ne pense pas que ça forcerait les gens qui bidouillent la dist à l'apprendre et à l'adopter.
Ce ne sont que des noms de classe, même sans connaître BEM et comprendre comment ces noms sont construits, ça n'empêche pas de bidouiller les styles.

Rangement

Il y a un autre point que je n'avais pas abordé, c'est le rangement des squelettes.

Je pense que les listes d'objets pourraient être mutualisées comme dans spipr, en ajoutant 2 dossiers et en y créant ces squelettes :

  • inclure/liste/
    • articles.html
    • rubriques.html
    • etc.
  • inclure/resume/
    • article.html
    • rubrique.html
    • etc.

Après, je me demande si on ne pourrait pas aller plus loin, et reprendre le rangement de z-core pour les blocs principaux.
Attention, je parle bien uniquement de rangement, pas de mettre z-core en dépendance.

C'est à dire concrètement :
  • header/
    • dist.html
  • footer/
    • dist.html
  • content/
    • sommaire.html
    • article.html
    • rubrique.html
    • etc.
  • aside/
    • sommaire.html
    • article.html
    • rubrique.html
    • etc.

Ce qui fait que le squelette des pages en serait simplifié, exemple pour sommaire.html :

<div class="page">

    <header class="header" id="header" role="banner">
        <INCLURE{fond=header/dist, home=oui} />
    </header>

    <div class="content" id="content">

        <main class="main" id="main" role="main">
            <INCLURE{fond=content/sommaire, env}>
        </main>

        <aside class="aside" id="aside">
            <INCLURE{fond=aside/sommaire, env}>
        </aside>

    </div>

    <footer class="footer" id="footer" role="contentinfo">
        <INCLURE{fond=footer/dist, self=#SELF} />
    </footer>

</div>

Bon, je sais pas, je réfléchis tout haut.
Peut-être que ça pourrait apporter aussi un peu de confusion.

Branche et dépôt GIT

Concernant le dépôt, je n'ai pas les droits pour créer une branche sur https://git.spip.net/SPIP/dist , du coup je bosse dans un fork : https://git.spip.net/tcharlss/dist/src/branch/bem

Pour celleux intéressées à contribuer, c'est quoi la meilleurs méthode ? Je vous ajoute comme collaborateurs sur ce dépôt ?
Ou alors il faut faire une vraie branche 3.4 dans le dépôt de l'orga SPIP ?

#14 Updated by tcharlss (*´_ゝ`) about 1 month ago

Un autre point à ajouter possiblement au cahier des charges : passer les CSS en mobile-first.
Donc partir sur des @media (min-width: Npx) au lieu de @media (max-width: Npx)

#15 Updated by erational 👺鬼 about 1 month ago

  • Target version changed from 3.3 to 3.4

Je passe à 3.4

#16 Updated by erational 👺鬼 about 1 month ago

Une réaction sur le rangement des fichiers
Je ne suis pas très fan de rangement par bloc de pages dans une optique z.

Je trouve qu'un rangement simplifié par fonctionnalité (comme actuellement) me semble suffisant et moins abstrait pour un débutant:
  • css/
    • style.css
  • formulaires
  • img/
  • inclure/
    • inc_article_complet.html
    • inc_article_resume.html
    • inc_header.html
    • inc_footer.html
  • js/

à discuter ...

#17 Updated by RastaPopoulos ♥ about 1 month ago

tcharlss a parlé de deux rangements, ya le rangement par bloc à la mode Z, donc ça ok c'est possiblement too much, mais ça ne concerne pas tout ce qu'il y a dans inclure/.

Ensuite il y a le découpage par fonctionnalité justement, et là c'est ce qu'il y a dans inclure/, avec d'un côté les listes/ (liste d'article, liste d'auteur, etc), les résumés (les morceaux individuels de chaque liste), et ça ça peut être mutualisé et rangé comme il faut dans inclure/ avec des sous-dossiers inclure/liste, etc. Là aussi en terme de bonne pratique, ça apprend aux débutants à réfléchir en terme modulaire, ce qui est bien mieux que de réfléchir en terme de "page" (design system, atomic design, etc) : on essaye de mutualiser ce qu'on détecte qui est commun à plusieurs pages, comme liste d'articles par ex.

Sinon, vraiment, jamais pigé le principe de mettre un préfixe "inc" devant des noms de squelette qui sont déjà bien rangés séparément dans un sous-dossier qui les distingue. :D

#18 Updated by tcharlss (*´_ゝ`) about 1 month ago

Oui après réflexion, le pseudo rangement zcore me semble too much aussi :) Ça sera plus confus qu'autre chose si ce n'est pas du vrai zcore.

Du coup je propose juste d'ajouter un inclure/liste/ et un inclure/resume/ pour les listes d'articles/rubriques etc.

#19 Updated by cy_altern - about 1 month ago

Un autre point à ajouter possiblement au cahier des charges : passer les CSS en mobile-first.
Donc partir sur des @media (min-width: Npx) au lieu de @media (max-width: Npx)

je plussois pour le mobile-first (et dans l'optique d'une dist "pédagogique" ça permet de privilégier une bonne pratique)

#20 Updated by tcharlss (*´_ゝ`) about 1 month ago

Le cahier des charges évoluant, je l'ai mis sur un pad : https://demo.codimd.org/2K_7KrSoT1G2fKnVaYoUvQ#
On peut aussi y noter les changements effectués (je n'ai encore rien commité pour l'instant).

#21 Updated by erational 👺鬼 about 1 month ago

Cela me semble très bien !

Pour le fallback de flexbox sur les vieux navigateurs, est-ce vraiment nécessaire ?
https://caniuse.com/#feat=flexbox

Il faudrait déterminer où s’arrête notre support des vieux navigateurs: IE 10 ?
Ce n'est pas bloquant d'ailleurs, l'affichage sera juste moche.

#22 Updated by RastaPopoulos ♥ about 1 month ago

Généralement on a l'habitude de dire : par défaut on supporte (avec un affichage correct) les navigateurs qui sont supérieurs à 1% (cf statcounter). IE 11 en est à un peu moins de 2% mais par contre IE10 n'est même plus mentionné, donc non pour celui là je pense qu'on peut abandonner. Ça n'empêche pas que le contenu serait parfaitement accessible quand même évidemment.

#23 Updated by nicod _ about 1 month ago

RastaPopoulos ♥ a écrit :

@nico le "plan" est bien un modifier chez tcharlss, dans BEM il n'y a plus "--" depuis pas mal de temps dans la doc officielle. La version en cours c'est DEUX "_" = un sous-élément, UN "_" = un modifier. :)
Les tirets ne sont plus utilisés que pour séparer les termes multi-mots (comme le disait tcharlss plus haut, à la place du camelCase).

N'importe quoi, ça devient complètement illisible...

Groumpfff... tant pis, je ferai du BEM de vieux con dans mon coin.

#24 Updated by b b about 1 month ago

N'importe quoi, ça devient complètement illisible...

Huhu les pseudos standards, alors on fait quoi avec la dist ? Du BEM de vieux, du BEM de djeunz ou pas de BEM du tout ? ^^

#25 Updated by RastaPopoulos ♥ about 1 month ago

Cela fait mal mal d'années que ça a changé, moi perso je préfère 1000 fois le truc à jour, c'est bien plus carré : ya UN caractère dédié à séparer les mots d'une même entité ("-" : mon-super-module) et UN caractère dédié à séparer les concepts BEM, block, element et modifier ("_" : mon-super-module__item_alt). Plus de mélange, c'est bien plus cohérent.
(Et ici on n'est pas dans un éditeur de code, normalement tout ça on le lit en monospace, donc ya pas de gros soucis à voir le nombre de caractères.)

#26 Updated by tcharlss (*´_ゝ`) about 1 month ago

N'importe quoi, ça devient complètement illisible...

Même réaction au début pour moi :)
Mais à l'utilisation j'ai rapidement trouvé ça plus cohérent et plus lisible.

#27 Updated by marcimat 🌈 about 1 month ago

Une remarque en passant : dans cette vidéo de Paris Web / Corinne Durrmeyer qui présente ITCSS, https://www.youtube.com/watch?v=Qmnw5HW7VFw&t=3790s ça parle (dans les questions) de BEMIT, qui propose de préfixer les classes CSS selon l’agencement ITCSS (o- pour objet, c- pour composant, ...).

- https://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/ (en)
- https://csswizardry.com/2015/08/bemit-taking-the-bem-naming-convention-a-step-further/ (en)
- https://www.bearstudio.fr/blog/bemit (fr)

#28 Updated by nicod _ 26 days ago

Justement, je suis en train de m'intéresser à BEMIT
Un article ici avec pas mal de ressources :
https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

Sinon, sur le fond de la refonte de la dist, ça risque de péter pas mal de sites qui utilisent la dist actuelle telle quelle, ou un peu adaptée.
Je me disais qu'on pourrait peut être faire un plugin de la dist actuelle, telle quelle, que les gens pourraient installer s'ils veulent la garder.

#29 Updated by erational 👺鬼 26 days ago

Comme il y a passage de version 3.4, on peut se permettre de péter des choses, il me semble.
Cela évitera d'alourdir le cahier des charges de la dist en maintenant un double code pour conserver la retro-compatibilité

Mais en effet pour respecter les vieux sites, un peu à comme pour grenier, il faudrait proposer un plugin dist-vieille.

#30 Updated by tcharlss (*´_ゝ`) 26 days ago

Oui l'ancienne dist en plugin, bonne idée.

Il va falloir que je regarde de plus près ITCSS et dans BEMIT. La vidéo sur ITCSS est intéressante, je vois l'idée générale, après pour la mise en application des concepts, va falloir regarder des exemples concrets. Par exemple je vois pas trop la différence entre objet et composant pour l'instant. Enfin bref.

Est-ce que quelqu'un avec les droits suffisants pourrait éditer le 1er message et y ajouter le lien vers le pad au début ? https://demo.codimd.org/2K_7KrSoT1G2fKnVaYoUvQ#
Merci !

#31 Updated by RastaPopoulos ♥ 26 days ago

En ce qui concerne l'architecture, la conception, proprement dite, de ITCSS, le inverted triangle correspond quasiment parfaitement au design atomique décrit par Brad Frost et son ordre de priorité (2013). Qui va même plus loin puisqu'après les "molécules" (composants réutilisables), il sait bien que dans la réalité, même s'il faut les limiter au maximum, il y a aussi des morceaux pas réutilisables et qui sont encore plus spécifiques, et il y a donc les "organismes" (sections d'une page), "templates" (styles communs à toutes les pages d'un même type), "pages" (style propre à une page précise, normalement ça doit à peu près jamais arriver). Bref du coup IT ça n'apporte pas grand chose de plus…

En ce qui me concerne, je n'aime pas le vocabulaire utilisé par Brad : la biologie, c'est très bien pour expliquer le concept global (plus général au plus particulier), mais du coup ça fait des termes cryptiques. J'avais donc essayé de trouver pour chacun des noms plus explicites avec en plus comme cahier des charges
1) que l'ordre corresponde à l'ordre alpha, ce qui fait que quand on range en dossiers, dans notre explorateur ou IDE, les dossiers restent toujours dans l'ordre du concept Atomic (ou IT) et donc plus on avance dans la liste des dossiers plus c'est spécifique, plus c'est rare, et moins réutilisable, et ça correspond donc aussi à 99% à l'ordre d'importation dans le CSS
2) que les mots soient si possible bilingues, utilisés couramment à la fois en français et anglais
(exemple dans Intégraal)

Là je parlais donc de l'architecture donc. Pour ce qui est du code, là pour le moment, je reste très (TRÈS) dubitatif de préfixer encore plus les noms des choses, avec des trucs o- -c etc. Je vois absolument pas l'intérêt, à partir du moment où le code est déjà bien rangé, et où BEM permet déjà de nommer correctement pour limiter à mort de cascader.

Donc pas BEM tout seul, mais bien Atomic (et son découpage/rangement) + BEM, il me semble que ça suffit. Je n'arrive pour le moment pas à saisir ce que IT apporterait de plus. Mais tant mieux si on arrive à m'expliquer mieux. :)

#32 Updated by nicod _ 25 days ago

Bon, toutes ces discussions sur l'architecture des css c'est super intéressant, mais il ne faudrait pas transformer la dist en un truc incompréhensible.
Il faut qu'elle reste simple et accessible, quand même.

Je suis pour un peu de nommage BEM, pour rationaliser les noms des classes et donner le bon exemple, sans aller trop loin non plus.

Also available in: Atom PDF