WIP: conteneur_inline #98

Open
maieul wants to merge 9 commits from conteneur_inline into master
maieul commented 1 year ago
Collaborator

Comme discuté l'autre jour avec @nicod_ et @rastapopoulos une nouvelle saisie permettant de regrouper des saisies pour un affichage sur une seule ligne.

Les points qui restent à régler, où je vous laisse la main :

  • je me rappelais plus la convention sur laquelle on s'était entendu en terme de nomenclature > à corriger le cas échéant
  • j'ai mis quelques css par défaut (css/saisies.css), qui seront du coup chargé aussi côté public mais
    • est-ce pertinent de les proposer au public ?
    • je ne suis pas sur de ne pas m'être trompé dans mon flex, en tout cas si on met un radio dans cette saisies, ca fait vraiment bizarre (mais peut etre qu'on a pas à le faire :-)
  • surtout dès qu'on édite au niveau du constructeur, les css sont tout pété (cf capture d'écran)

je vous laisse sur ces aspects css...

Comme discuté l'autre jour avec @nicod_ et @rastapopoulos une nouvelle saisie permettant de regrouper des saisies pour un affichage sur une seule ligne. Les points qui restent à régler, où je vous laisse la main : - je me rappelais plus la convention sur laquelle on s'était entendu en terme de nomenclature > à corriger le cas échéant - j'ai mis quelques css par défaut (css/saisies.css), qui seront du coup chargé aussi côté public mais - est-ce pertinent de les proposer au public ? - je ne suis pas sur de ne pas m'être trompé dans mon flex, en tout cas si on met un radio dans cette saisies, ca fait vraiment bizarre (mais peut etre qu'on a pas à le faire :-) - surtout dès qu'on édite au niveau du constructeur, les css sont tout pété (cf capture d'écran) je vous laisse sur ces aspects css...
maieul added 4 commits 1 year ago
maieul added 1 commit 1 year ago
Owner

Mes 2 sous :

  • Il faudrait autoriser le retour à la ligne quand il n'y a plus de place, flex-flow: row wrap ou bien flex-wrap: wrap;
  • Dans la css partagée entre le public et le privé, les styles devraient être limités au conteneur .editer-groupe--inline. Tout le reste ça ne concerne que les styles du privé.
Mes 2 sous : * Il faudrait autoriser le retour à la ligne quand il n'y a plus de place, `flex-flow: row wrap` ou bien `flex-wrap: wrap`; * Dans la css partagée entre le public et le privé, les styles devraient être limités au conteneur `.editer-groupe--inline`. Tout le reste ça ne concerne que les styles du privé.
maieul added 2 commits 1 year ago
Poster
Collaborator

Dans la css partagée entre le public et le privé, les styles devraient être limités au conteneur .editer-groupe--inline. Tout le reste ça ne concerne que les styles du privé.

oui, en soit. Mais si les gens utilisent les styles de la dist ou autre, ils vont avoir une surprise si on leur fournit pas mes compléments. Après c'est dit dans l'explication, mais comme on la voit qu'au survol. Je me suis dit qu'on pouvait forunir cette base minimale, comme on fournit aussi une base minimale pour les onglets, les pliables / depliables etc.

> Dans la css partagée entre le public et le privé, les styles devraient être limités au conteneur .editer-groupe--inline. Tout le reste ça ne concerne que les styles du privé. oui, en soit. Mais si les gens utilisent les styles de la dist ou autre, ils vont avoir une surprise si on leur fournit pas mes compléments. Après c'est dit dans l'explication, mais comme on la voit qu'au survol. Je me suis dit qu'on pouvait forunir cette base minimale, comme on fournit aussi une base minimale pour les onglets, les pliables / depliables etc.
Owner

Mais si les gens utilisent les styles de la dist ou autre, ils vont avoir une surprise si on leur fournit pas mes compléments.

J'ai l'impression que ces compléments ont une utilité surtout pour le privé, et pas vraiment d'effet sur la dist.
Par exemple si je désactive tous les styles que tu as ajoutés sur les labels, dans la dist ça ne fait aucune différence : ils sont déjà en display block, il n'y a pas de marge, pas de largeur fixe, etc.
Le padding sur le .editer permet d'espacer les saisies, mais là encore, c'est raccord avec les styles du privé mais dans le public ça décale la 1ère saisie.

Amha pour les styles publics, ces compléments devraient être vraiment minimalistes et agnostiques, et ne pas entrer potentiellement en conflit avec les différents thèmes.
On peut se dire que dans 99%, quand des saisies sont affichées côte-à-côte, il vaut mieux mettre le label par dessus, donc display: block, ok. Mais mis à part ça, tout le reste ça peut occasionner des conflits amha.

> Mais si les gens utilisent les styles de la dist ou autre, ils vont avoir une surprise si on leur fournit pas mes compléments. J'ai l'impression que ces compléments ont une utilité surtout pour le privé, et pas vraiment d'effet sur la dist. Par exemple si je désactive tous les styles que tu as ajoutés sur les labels, dans la dist ça ne fait aucune différence : ils sont déjà en display block, il n'y a pas de marge, pas de largeur fixe, etc. Le padding sur le .editer permet d'espacer les saisies, mais là encore, c'est raccord avec les styles du privé mais dans le public ça décale la 1ère saisie. Amha pour les styles publics, ces compléments devraient être vraiment minimalistes et agnostiques, et ne pas entrer potentiellement en conflit avec les différents thèmes. On peut se dire que dans 99%, quand des saisies sont affichées côte-à-côte, il vaut mieux mettre le label par dessus, donc `display: block`, ok. Mais mis à part ça, tout le reste ça peut occasionner des conflits amha.
Poster
Collaborator

On peut se dire que dans 99%, quand des saisies sont affichées côte-à-côte, il vaut meut mettre le label par dessus.

OUi, c'était surtout ca. Du coup peut être juste garder le float:none ?

>On peut se dire que dans 99%, quand des saisies sont affichées côte-à-côte, il vaut meut mettre le label par dessus. OUi, c'était surtout ca. Du coup peut être juste garder le float:none ?
Owner

OUi, c'était surtout ca. Du coup peut être juste garder le float:none ?

Ouais ça ne mange pas de pain.

Pour avoir un espacement horizontal entre les saisies, maintenant que le support navigateur est correct, j'hésiterais presque à faire un display: grid afin de pouvoir utiliser grid-gap, à la place de display: flex + padding / margin.
Mais bon, c'est peut-être too much aussi.

> OUi, c'était surtout ca. Du coup peut être juste garder le float:none ? Ouais ça ne mange pas de pain. Pour avoir un espacement horizontal entre les saisies, maintenant que le support navigateur est correct, j'hésiterais presque à faire un `display: grid` afin de pouvoir utiliser `grid-gap`, à la place de `display: flex` + `padding / margin`. Mais bon, c'est peut-être too much aussi.
Poster
Collaborator

@tcharlss je te propose de faire les commits sur le branches, c'est pas ma spécialité ce genre de chose :)

@tcharlss je te propose de faire les commits sur le branches, c'est pas ma spécialité ce genre de chose :)
tcharlss added 1 commit 1 year ago
ae3aae4833 CSS groupe inline :
Owner

Envoyé, cf. commit pour les commentaires.
Il y avait surtout une correction à faire pour le constructeur de formulaire, lui il à tendance à exploser au moindre changement :p

Envoyé, cf. commit pour les commentaires. Il y avait surtout une correction à faire pour le constructeur de formulaire, lui il à tendance à exploser au moindre changement :p
maieul added 1 commit 1 year ago
Poster
Collaborator

merci @tcharlss ! Il reste encore un problème sur le constructeur de la saisie-inline elle même, cf ma capture d'écran Screenshot_2021-04-05 [Mon site SPIP] inline.png

merci @tcharlss ! Il reste encore un problème sur le constructeur de la saisie-inline elle même, cf ma capture d'écran Screenshot_2021-04-05 [Mon site SPIP] inline.png
tcharlss added 1 commit 1 year ago
Owner

@maieul J'ai tenté un fix tu, me diras si ça résoud de ton côté.
Aaaah, intervenir sur la css de ce constructeur, c'est toujours un moment convivial.

@maieul J'ai tenté un fix tu, me diras si ça résoud de ton côté. Aaaah, intervenir sur la css de ce constructeur, c'est toujours un moment convivial.
Poster
Collaborator

@tcharlss tu m'étonne ! Ca marche bien chez moi

par contre comme à chaque fois qu'on a des modifs css du constructeur, j'ai du passer par un vidage de cache manuel.

Du coup pour moi ce serait publiable. Attendons voir si on encore un avis d'une autre personne.

@tcharlss tu m'étonne ! Ca marche bien chez moi par contre comme à chaque fois qu'on a des modifs css du constructeur, j'ai du passer par un vidage de cache manuel. Du coup pour moi ce serait publiable. Attendons voir si on encore un avis d'une autre personne.
Poster
Collaborator

ah si faudrait un petit picto pour cette saisie (si possible directement avec les 2 versions svg et png)

ah si faudrait un petit picto pour cette saisie (si possible directement avec les 2 versions svg et png)
maieul force-pushed conteneur_inline from a7b5ff017e to f12e0ea7ba 1 year ago
maieul force-pushed conteneur_inline from f12e0ea7ba to 887c0c7d66 1 year ago
maieul force-pushed conteneur_inline from 887c0c7d66 to e4c9948ef3 1 year ago
Collaborator

Comme discuté sur IRC :

Cette PR introduit des .editer-groupe--inline et des .conteneur_inline .editer-groupe--inline (quelle est la différence entre les deux ? comment ça s'utiliserait en terme de structure ?)

Mais dans la charte (plugin dev), je ne sais pas si c'est définitif mais je vois qu'il y a un div.editer-groupe.deux_colonnes, qui contient des div.editer.editer_2cols1.

Il y a aussi un fieldset.editer.editer_text_inline, qui contient par contre un legend et des span.choix qui contiennent eux des input (pas très cohérent ça, pour moi .choix s'applique à des radios ou des checkboxes).

Autant que les classes pour ce type de structures soient identiques partout, privé / public, ce sont les même besoins à priori.

@tcharlss un avis là dessus ?

Comme discuté sur IRC : Cette PR introduit des `.editer-groupe--inline` et des `.conteneur_inline .editer-groupe--inline` (quelle est la différence entre les deux ? comment ça s'utiliserait en terme de structure ?) Mais dans la charte (plugin dev), je ne sais pas si c'est définitif mais je vois qu'il y a un `div.editer-groupe.deux_colonnes`, qui contient des `div.editer.editer_2cols1`. Il y a aussi un `fieldset.editer.editer_text_inline`, qui contient par contre un `legend` et des `span.choix` qui contiennent eux des `input` (pas très cohérent ça, pour moi .choix s'applique à des radios ou des checkboxes). Autant que les classes pour ce type de structures soient identiques partout, privé / public, ce sont les même besoins à priori. @tcharlss un avis là dessus ?
Owner

@nicod_ Dans la charte de dev j'ai recensé tous les cas que j'ai rencontrés dans la dist. Mais j'ai été un peu trop zélé, certains trucs sont des astuces propres à des formulaires précis, mais ne doivent pas forcément faire partie de la charte.

div.editer-groupe.deux_colonnes c'est dans le formulaires de préférences, pour choisir les entrées de menus favorites.

Le fieldset.editer avec des .choix + input inlines, c'est dans le formulaire d'édition de document, où la hauteur et la largeur sont sur la même ligne.

Ce dernier cas c'est pour répondre à la même problématique que ce ticket donc, il faudrait vraiment avoir une solution normalisée pour ça dans la charte, c'est un besoin assez courant.
Et saisies pourra adopter cette structure ensuite.

Comme conteneur ça me semblerait logique de partir sur un fieldset.editer comme c'est le cas pour les .choix, ensuite à l'intérieur il faut un autre conteneur pour les inputs et cie, pas forcément .choix quoi.

Dans l'autre ticket, la discussion sur les fieldsets à glissé vers la structure complète des formulaires, pour consolider et remettre les choses à plat.
Il faudrait y inclure ce sujet amha : https://core.spip.net/issues/4623

@nicod_ Dans la charte de dev j'ai recensé tous les cas que j'ai rencontrés dans la dist. Mais j'ai été un peu trop zélé, certains trucs sont des astuces propres à des formulaires précis, mais ne doivent pas forcément faire partie de la charte. `div.editer-groupe.deux_colonnes` c'est dans le formulaires de préférences, pour choisir les entrées de menus favorites. Le `fieldset.editer` avec des `.choix` + input inlines, c'est dans le formulaire d'édition de document, où la hauteur et la largeur sont sur la même ligne. Ce dernier cas c'est pour répondre à la même problématique que ce ticket donc, il faudrait vraiment avoir une solution normalisée pour ça dans la charte, c'est un besoin assez courant. Et saisies pourra adopter cette structure ensuite. Comme conteneur ça me semblerait logique de partir sur un `fieldset.editer` comme c'est le cas pour les `.choix`, ensuite à l'intérieur il faut un autre conteneur pour les inputs et cie, pas forcément `.choix` quoi. Dans l'autre ticket, la discussion sur les fieldsets à glissé vers la structure complète des formulaires, pour consolider et remettre les choses à plat. Il faudrait y inclure ce sujet amha : https://core.spip.net/issues/4623
Owner

Effectivement ça me parait pas mal le bazar les classes utilisées là, et je suis d'accord qu'il faudrait uniformiser au mieux avec les ajouts qu'il y a dans le noyau de la 3.3. Uniformiser en terme de type d'imbrication et de nommage des classes. Cf notamment le ticket sur les fieldsets avec les ".editer-fieldset" (ou autre nom car pas fini de réfléchir) pour bien distinguer les "vrais" fieldsets de ceuix qui groupent les ".choix".

Effectivement ça me parait pas mal le bazar les classes utilisées là, et je suis d'accord qu'il faudrait uniformiser au mieux avec les ajouts qu'il y a dans le noyau de la 3.3. Uniformiser en terme de type d'imbrication et de nommage des classes. Cf notamment le ticket sur les fieldsets avec les ".editer-fieldset" (ou autre nom car pas fini de réfléchir) pour bien distinguer les "vrais" fieldsets de ceuix qui groupent les ".choix".
Owner

Le conteneur de l'inline ne doit surtout pas être un "fieldset.editer", ça n'a à priori rien à voir.

  1. L'inline n'est pas du tout du sémantique : à aucun moment on ne doit le regrouper avec la balise HTML "fieldset" + un "legend", qui va donner un sens en terme d'accessibilité à ce qu'on regroupe. Alors que là c'est juste de la présentation (quand la largeur d'écran le permet)
  2. En plus les "fieldset.editer" c'est vraiment pour les "listes de choix" càd explicitement pour les radios et checkboxs uniquement.
Le conteneur de l'inline ne doit *surtout pas* être un "fieldset.editer", ça n'a à priori rien à voir. 1) L'inline n'est pas du tout du sémantique : à aucun moment on ne doit le regrouper avec la balise HTML "fieldset" + un "legend", qui va donner un sens en terme d'accessibilité à ce qu'on regroupe. Alors que là c'est juste de la présentation (quand la largeur d'écran le permet) 2) En plus les "fieldset.editer" c'est vraiment pour les "listes de choix" càd explicitement pour les radios et checkboxs uniquement.
Owner

L'inline n'est pas du tout du sémantique : à aucun moment on ne doit le regrouper avec la balise HTML "fieldset" + un "legend", qui va donner un sens en terme d'accessibilité à ce qu'on regroupe. Alors que là c'est juste de la présentation (quand la largeur d'écran le permet)

Qu'est-ce qui n'est pas sémantique dans les exemples ci-dessous ?

  • Légende = Nom complet, saisies = civilité + prénom + nom
  • Légende = Date, saisies = jour + mois + an
  • Légende = Dimensions, Saisies = largeur + hauteur

En plus les "fieldset.editer" c'est vraiment pour les "listes de choix"

Bah c'est ce qu'on décide d'y mettre. Je vois pas pourquoi l'un empêcherait l'autre.

> L'inline n'est pas du tout du sémantique : à aucun moment on ne doit le regrouper avec la balise HTML "fieldset" + un "legend", qui va donner un sens en terme d'accessibilité à ce qu'on regroupe. Alors que là c'est juste de la présentation (quand la largeur d'écran le permet) Qu'est-ce qui n'est pas sémantique dans les exemples ci-dessous ? * Légende = Nom complet, saisies = civilité + prénom + nom * Légende = Date, saisies = jour + mois + an * Légende = Dimensions, Saisies = largeur + hauteur > En plus les "fieldset.editer" c'est vraiment pour les "listes de choix" Bah c'est ce qu'on décide d'y mettre. Je vois pas pourquoi l'un empêcherait l'autre.
Poster
Collaborator

Effectivement ça me parait pas mal le bazar les classes utilisées là, et je suis d'accord qu'il faudrait uniformiser au mieux avec les ajouts qu'il y a dans le noyau de la 3.3. Uniformiser en terme de type d'imbrication et de nommage des classes.

Ah bah ca j'avais prévenu que les class c'était pas mon fort, et que je laissais à d'autres que moi le soin de trouver, d'autres qui notamment bossent à haute dose sur les formulaire :p. Et oui faudrait voir cela avec le ticket general

C'est pas pour rien que c'est une PR WIP !

Qu'est-ce qui n'est pas sémantique dans les exemples ci-dessous ?

Je donnerais un autre exemple où fieldset aurait peu de sens.

Ligne 1 :
- saisie 1 : numero dans la rue
- saisie 2 : type de rue
- saisie 3 : rue
Ligne 2
- saisie 1 : CP
- saisie 2 : Vill

Alors autant regrouper Ligne et Ligne 2 dans un fieldset gloable "adresse" ca a du sens, autant je trouve que ligne 1 = fieldset dont le legend est "???" et ligne 2 = fieldset dont e legend est ???? ca a peu de sens.

> Effectivement ça me parait pas mal le bazar les classes utilisées là, et je suis d'accord qu'il faudrait uniformiser au mieux avec les ajouts qu'il y a dans le noyau de la 3.3. Uniformiser en terme de type d'imbrication et de nommage des classes. Ah bah ca j'avais prévenu que les class c'était pas mon fort, et que je laissais à d'autres que moi le soin de trouver, d'autres qui notamment bossent à haute dose sur les formulaire :p. Et oui faudrait voir cela avec le ticket general C'est pas pour rien que c'est une PR WIP ! > Qu'est-ce qui n'est pas sémantique dans les exemples ci-dessous ? Je donnerais un autre exemple où fieldset aurait peu de sens. Ligne 1 : - saisie 1 : numero dans la rue - saisie 2 : type de rue - saisie 3 : rue Ligne 2 - saisie 1 : CP - saisie 2 : Vill Alors autant regrouper Ligne et Ligne 2 dans un fieldset gloable "adresse" ca a du sens, autant je trouve que ligne 1 = fieldset dont le legend est "???" et ligne 2 = fieldset dont e legend est ???? ca a peu de sens.
Owner

un fieldset c'est un groupe qui doit avoir une légende, donc qui est vraiment 100% du temps un truc accessible regroupant sémantiquement des champs avec un titre qui chapeaute le tout

c'est le cas pour "votre adresse" avec les différents champs à l'intérieur par ex

Mais là pour l'inline c'est totalement découplé. Tu peux parfaitement avoir Prénom + Nom sur la même ligne et dessous Email + téléphone etc, et on ne veut pas du tout spécialement mettre un titre chapeautant chacune de ces lignes.

Ce sont deux fonctionnalités totalement séparées : d'un côté on veut parfois regrouper des champs sémantiquements, donc avec un titre, et parfois dedans (… ou pas) on veut mettre des champs "en ligne" ce qui est juste de la présentation.

On peut faire que l'un OU que l'autre OU les deux, mais ce sont bien des champs séparés.

Si on doit faire les deux, pour moi on fait un fieldset sémantique, donc avec un titre, et dedans on fait un groupe "inline" si visuellement on veut une ligne. Mais c'est bien deux choses n'ayant rien à voir.

un fieldset c'est un groupe qui *doit* avoir une légende, donc qui est vraiment 100% du temps un truc accessible regroupant sémantiquement des champs avec un titre qui chapeaute le tout c'est le cas pour "votre adresse" avec les différents champs à l'intérieur par ex Mais là pour l'inline c'est totalement découplé. Tu peux parfaitement avoir Prénom + Nom sur la même ligne et dessous Email + téléphone etc, et on ne veut pas du tout spécialement mettre un titre chapeautant chacune de ces lignes. Ce sont deux fonctionnalités totalement séparées : d'un côté on veut parfois regrouper des champs sémantiquements, donc avec un titre, et parfois *dedans* (… *ou pas*) on veut mettre des champs "en ligne" ce qui est juste de la présentation. On peut faire que l'un OU que l'autre OU les deux, mais ce sont bien des champs séparés. Si on doit faire les deux, pour moi on fait un fieldset sémantique, donc avec un titre, et *dedans* on fait un groupe "inline" si visuellement on veut une ligne. Mais c'est bien deux choses n'ayant rien à voir.
Collaborator

Oui, on pourrait avoir des fieldset inline ou pas tout autant que des groupes de champs inline ou pas, c'est décorrélé pour moi.

Sur la structure actuelle, actuellement on a :

div.fieldset.saisie_fieldset
  fieldset
    legend
    div.editer_goupe
      div.editer
      div.editer
      div.editer
            
div.editer_goupe
  div.editer
  div.editer
  div.editer
            

Avec juste l'ajout d'une classe .fieldset--inline et .editer_goupe--inline, ça pourrait donner :

div.fieldset.saisie_fieldset
  fieldset.fieldset--inline
    legend
    div.editer_goupe.editer_goupe--inline
      div.editer
      div.editer
      div.editer
            
div.editer_goupe.editer_goupe--inline
  div.editer
  div.editer
  div.editer
            

L'ajout de .editer_goupe--inline sous .fieldset--inline serait automatique, ou bien alors on ciblerait en cascade fieldset.fieldset--inline > div.editer_goupe

Qu'en pensez vous ?

Oui, on pourrait avoir des `fieldset` inline ou pas tout autant que des groupes de champs inline ou pas, c'est décorrélé pour moi. Sur la structure actuelle, actuellement on a : ``` div.fieldset.saisie_fieldset fieldset legend div.editer_goupe div.editer div.editer div.editer div.editer_goupe div.editer div.editer div.editer ``` Avec juste l'ajout d'une classe .fieldset--inline et .editer_goupe--inline, ça pourrait donner : ``` div.fieldset.saisie_fieldset fieldset.fieldset--inline legend div.editer_goupe.editer_goupe--inline div.editer div.editer div.editer div.editer_goupe.editer_goupe--inline div.editer div.editer div.editer ``` L'ajout de `.editer_goupe--inline` sous `.fieldset--inline` serait automatique, ou bien alors on ciblerait en cascade `fieldset.fieldset--inline > div.editer_goupe` Qu'en pensez vous ?
Owner

Je pense vraiment que ça doit totalement être découplé jusqu'au bout : il ne devrait pas y avoir plusieurs moyens de le faire, et les gens ne devraient pas avoir à réfléchir à "c'est où déjà".

Donc

  • s'illes veulent une groupe sémantique, ya déjà la saisie fieldset pour ça, ya rien à faire du tout dessus
  • si à l'intérieur de ce fieldset (ou pas !) illes veulent que des champs soient en ligne quand il y a la place : il y aura une saisie pour ça uniquement pour la présentation en ligne sans aucune sémantique

Et donc on utilise que l'un ou que l'autre ou les deux à la fois l'un dans l'autre.

Ça peut parfaitement être dans l'autre sens d'ailleurs : on pourrait parfaitement vouloir deux fieldsets côte à côte (deux adresses différentes à remplir par ex), et dans ce cas ça serait une saisie inline et dedans deux saisie fieldsets (chacune ayant sa légende sémantique).

Je pense vraiment que ça doit totalement être découplé jusqu'au bout : il ne devrait pas y avoir plusieurs moyens de le faire, et les gens ne devraient pas avoir à réfléchir à "c'est où déjà". Donc - s'illes veulent une groupe sémantique, ya déjà la saisie fieldset pour ça, ya rien à faire du tout dessus - si *à l'intérieur* de ce fieldset (ou pas !) illes veulent que des champs soient en ligne quand il y a la place : il y aura une saisie pour ça *uniquement pour la présentation en ligne sans aucune sémantique* Et donc on utilise que l'un ou que l'autre ou les deux à la fois l'un dans l'autre. Ça peut parfaitement être dans l'autre sens d'ailleurs : on pourrait parfaitement vouloir deux fieldsets côte à côte (deux adresses différentes à remplir par ex), et dans ce cas ça serait une saisie inline et *dedans* deux saisie fieldsets (chacune ayant sa légende sémantique).
Owner

Et donc le corollaire : il n'y a qu'une seule classe à trouver, celle pour la saisie "inline", puisqu'il n'y a pas de notion de "fieldset inline".

Un groupe sémantique, avec dedans on veut que les champs soient en ligne :

array(
    array(
        'saisie' => 'fieldset',
        'options' => array(
            'nom' => 'identite',
            'label' => 'Identité',
        ),
        'saisies' => array(
            array(
            	'saisie' => 'inline',
                'options' => rien de spécial
                'saisies' => array(
                	array(
                        array(
                            'saisie' => 'input',
                            'options' => array(
                                'nom' => 'prenom',
                                'label' => 'Prénom',
                            )
                        ),
                        array(
                            'saisie' => 'input',
                            'options' => array(
                                'nom' => 'nom',
                                'label' => 'Nom',
                            )
                        ),
                    ),
                ),
            ),
        )
    )
)

Un groupe inline, dans lequel on met deux adresses côte à côte :

array(
    array(
        'saisie' => 'inline',
        'options' => rien de spécial
        'saisies' => array(
            array(
            	'saisie' => 'fieldset',
                'options' => array(
                    'nom' => 'adresse_facturation',
                    'Label' => 'Adresse de facturation',
                ),
                'saisies' => array(pays, rue, ville, etc)
            ),
            array(
            	'saisie' => 'fieldset',
                'options' => array(
                    'nom' => 'adresse_livraison',
                    'Label' => 'Adresse de livraison',
                ),
                'saisies' => array(pays, rue, ville, etc)
            ),
        )
    )
)
Et donc le corollaire : il n'y a qu'une seule classe à trouver, celle pour la saisie "inline", puisqu'il n'y a pas de notion de "fieldset inline". Un groupe sémantique, avec dedans on veut que les champs soient en ligne : ```php array( array( 'saisie' => 'fieldset', 'options' => array( 'nom' => 'identite', 'label' => 'Identité', ), 'saisies' => array( array( 'saisie' => 'inline', 'options' => rien de spécial 'saisies' => array( array( array( 'saisie' => 'input', 'options' => array( 'nom' => 'prenom', 'label' => 'Prénom', ) ), array( 'saisie' => 'input', 'options' => array( 'nom' => 'nom', 'label' => 'Nom', ) ), ), ), ), ) ) ) ``` Un groupe inline, dans lequel on met deux adresses côte à côte : ``` php array( array( 'saisie' => 'inline', 'options' => rien de spécial 'saisies' => array( array( 'saisie' => 'fieldset', 'options' => array( 'nom' => 'adresse_facturation', 'Label' => 'Adresse de facturation', ), 'saisies' => array(pays, rue, ville, etc) ), array( 'saisie' => 'fieldset', 'options' => array( 'nom' => 'adresse_livraison', 'Label' => 'Adresse de livraison', ), 'saisies' => array(pays, rue, ville, etc) ), ) ) ) ```
Collaborator

Ça va générer beaucoup de div entre le fieldset et les .editer :

  div.editer-groupe 
    div.avec-sous-saisies.fieldset.saisie_fieldset 
      fieldset 
        legend
        div.editer-groupe 
          div.avec-sous-saisies.conteneur_inline.saisie_conteneur_inline
            div.editer-groupe.editer-groupe--inline
              div.editer
              div.editer
              div.editer    
Ça va générer beaucoup de div entre le fieldset et les .editer : ``` div.editer-groupe div.avec-sous-saisies.fieldset.saisie_fieldset fieldset legend div.editer-groupe div.avec-sous-saisies.conteneur_inline.saisie_conteneur_inline div.editer-groupe.editer-groupe--inline div.editer div.editer div.editer ```
Poster
Collaborator

Je pense vraiment que ça doit totalement être découplé jusqu'au bout : il ne devrait pas y avoir plusieurs moyens de le faire, et les gens ne devraient pas avoir à réfléchir à "c'est où déjà".

je suis 100 % d'accord :)

> Je pense vraiment que ça doit totalement être découplé jusqu'au bout : il ne devrait pas y avoir plusieurs moyens de le faire, et les gens ne devraient pas avoir à réfléchir à "c'est où déjà". je suis 100 % d'accord :)
Collaborator

Bon ben go alors, on a donc juste besoin d'une classe .editer-groupe--inline

Je prévoierais bien aussi (par expérience sur des styles que je gère sur un projet) des classes complémentaires pour caler les .editer sur 2, 3 ou 4 colonnes.

Bon ben go alors, on a donc juste besoin d'une classe `.editer-groupe--inline` Je prévoierais bien aussi (par expérience sur des styles que je gère sur un projet) des classes complémentaires pour caler les `.editer` sur 2, 3 ou 4 colonnes.
Poster
Collaborator

Je prévoierais bien aussi (par expérience sur des styles que je gère sur un projet) des classes complémentaires pour caler les .editer sur 2, 3 ou 4 colonnes.

J'y pensais aussi. Mais du coup je me demande comment tout cela s'articulerait avec le constructeur des saisies. Est-ce qu'on proposerait ces classes ?

> Je prévoierais bien aussi (par expérience sur des styles que je gère sur un projet) des classes complémentaires pour caler les .editer sur 2, 3 ou 4 colonnes. J'y pensais aussi. Mais du coup je me demande comment tout cela s'articulerait avec le constructeur des saisies. Est-ce qu'on proposerait ces classes ?
Owner

pour moi peu importe le nombre de div, du moment que ça correspond à un sens précis :)

mais pour les groupes inline : pourquoi est-ce qu'il y aurait besoin de deux div imbriqués ? c'est juste un groupe de champs qui indique "ce qui est dedans est sur la même ligne si ya la place"

div.editer-groupe : racine du form par ex
    div.saisie_fieldset  : possiblement viré cf le ticket core fieldsets
      fieldset.classe_a_trouver (cf le ticket core fieldsets)
        legend
          div.editer-groupe (généré par la saisie fieldset là)
            div.conteneur_inline (généré par la saisie inline : un seul niveau)
              div.editer
              div.editer
              div.editer    
pour moi peu importe le nombre de div, du moment que ça correspond à un sens précis :) mais pour les groupes inline : pourquoi est-ce qu'il y aurait besoin de deux div imbriqués ? c'est juste *un* groupe de champs qui indique "ce qui est dedans est sur la même ligne si ya la place" ``` div.editer-groupe : racine du form par ex div.saisie_fieldset : possiblement viré cf le ticket core fieldsets fieldset.classe_a_trouver (cf le ticket core fieldsets) legend div.editer-groupe (généré par la saisie fieldset là) div.conteneur_inline (généré par la saisie inline : un seul niveau) div.editer div.editer div.editer ```
Collaborator

J'y pensais aussi. Mais du coup je me demande comment tout cela s'articulerait avec le constructeur des saisies. Est-ce qu'on proposerait ces classes ?

Ça pourrait être un paramètre "Mise en forme", avec boutons radio :

  • 2 colonnes
  • 3 colonnes
  • 4 colonnes
  • Libre

et des classes sématiques, à reprendre dans la charte (plugin dev), genre .editer-groupe--2_colonnes

> J'y pensais aussi. Mais du coup je me demande comment tout cela s'articulerait avec le constructeur des saisies. Est-ce qu'on proposerait ces classes ? Ça pourrait être un paramètre "Mise en forme", avec boutons radio : * 2 colonnes * 3 colonnes * 4 colonnes * Libre et des classes sématiques, à reprendre dans la charte (plugin dev), genre `.editer-groupe--2_colonnes`
Poster
Collaborator

pas sur qu'on parle de la même chose. Là tu parle au niveau du conteneur, mais je vois pas l'intéret de numeroter le nombre de colonne au niveau du conteneur : c'est le nombre de contenu qui le determine.

Moi ce que je voyais c'est plus un système pour dire "cette saisie prend l'équivalent de x colonne".

Genre

div.conteneur_inline
   div.1col
   div.2col

Pour avoir un rapport 1/3 - 2 /3

pas sur qu'on parle de la même chose. Là tu parle au niveau du conteneur, mais je vois pas l'intéret de numeroter le nombre de colonne au niveau du conteneur : c'est le nombre de contenu qui le determine. Moi ce que je voyais c'est plus un système pour dire "cette saisie prend l'équivalent de x colonne". Genre ```` div.conteneur_inline div.1col div.2col ```` Pour avoir un rapport 1/3 - 2 /3
Collaborator

je vois pas l'intéret de numeroter le nombre de colonne au niveau du conteneur : c'est le nombre de contenu qui le determine

Pas pour moi car j'imagine ce conteneur en flex-wrap, donc le nombre de contenu ne pourrait pas déterminer le nombre de colonnes.
Tu pourrais par exemple mettre 6 saisies dedans, et demander à les afficher sur 2 ou 3 colonnes (et donc 3 ou 2 lignes), ou même sur 4 colonnes ce qui ferait une ligne de 4 et une ligne de 2.
Et si pas de nombre de colonnes, alors pas de flex-wrap et tout sur une seule ligne.

C'est ce que j'utilise sur un projet, comme je le disais, par exemple pour des listes de filtres dans des moteurs de recherche, que je peux organiser en n colonnes.

Le rapport entre les colonnes elles même c'est encore autre chose, des classes au niveau des .editer donc, ce à quoi je n'avais pas pensé.

> je vois pas l'intéret de numeroter le nombre de colonne au niveau du conteneur : c'est le nombre de contenu qui le determine Pas pour moi car j'imagine ce conteneur en flex-wrap, donc le nombre de contenu ne pourrait pas déterminer le nombre de colonnes. Tu pourrais par exemple mettre 6 saisies dedans, et demander à les afficher sur 2 ou 3 colonnes (et donc 3 ou 2 lignes), ou même sur 4 colonnes ce qui ferait une ligne de 4 et une ligne de 2. Et si pas de nombre de colonnes, alors pas de flex-wrap et tout sur une seule ligne. C'est ce que j'utilise sur un projet, comme je le disais, par exemple pour des listes de filtres dans des moteurs de recherche, que je peux organiser en n colonnes. Le rapport entre les colonnes elles même c'est encore autre chose, des classes au niveau des `.editer` donc, ce à quoi je n'avais pas pensé.
Poster
Collaborator

hum, oui je comprend mieux. Mais du coup par défaut ca ferait tout de même "On essaie de caser un max" ?

hum, oui je comprend mieux. Mais du coup par défaut ca ferait tout de même "On essaie de caser un max" ?
Collaborator

hum, oui je comprend mieux. Mais du coup par défaut ca ferait tout de même "On essaie de caser un max" ?

Oui, si pas de nombre de colonnes, alors pas de flex-wrap et tout sur une seule ligne.

Dans l'idée je propose une config à base de radios entre 2 et 4 colonnes, parce que c'est une liste fermée et qu'on peut donc définir ces trois classes en css, plutôt qu'un input à saisie libre, ce qui serait plus compliqué côté css.
Et 4 colonnes me semblent le max, au delà ça fait "tout tassé" je pense.

Après, pour les .editer, on pourrait aussi avoir .editer--1_3, .editer--2_3, .editer--1_4, .editer--2_4, .editer--3_4 par exemple.
Mais alors à saisir "à la main" ? parce que en option, ça peut être compliqué de déterminer si une saisie est fille directe d'un conteneur inline, non ?

> hum, oui je comprend mieux. Mais du coup par défaut ca ferait tout de même "On essaie de caser un max" ? Oui, si pas de nombre de colonnes, alors pas de flex-wrap et tout sur une seule ligne. Dans l'idée je propose une config à base de radios entre 2 et 4 colonnes, parce que c'est une liste fermée et qu'on peut donc définir ces trois classes en css, plutôt qu'un input à saisie libre, ce qui serait plus compliqué côté css. Et 4 colonnes me semblent le max, au delà ça fait "tout tassé" je pense. Après, pour les `.editer`, on pourrait aussi avoir `.editer--1_3`, `.editer--2_3`, `.editer--1_4`, `.editer--2_4`, `.editer--3_4` par exemple. Mais alors à saisir "à la main" ? parce que en option, ça peut être compliqué de déterminer si une saisie est fille directe d'un conteneur inline, non ?
Poster
Collaborator

Mais alors à saisir "à la main" ? parce que en option, ça peut être compliqué de déterminer si une saisie est fille directe d'un conteneur inline, non ?

je suis pas fan du 'à la main' qui fait trop peser sur la personne, et est donc très technique.

je vois 2 solutions :

  • soit effectivement on arrive à determiner cela au niveau du constructeur, mais sauf erreur de me part cela n'existe pas actuellement "determiner le parent de la saisie actuelle", et j'ai peur que cela complexifie le code pour pas grand chose (à moins que l'on triche et que l'on fasse le masquage en css)
  • soit on propose systèmeatiquement les choix mais on met un gros avertissement auparavant
> Mais alors à saisir "à la main" ? parce que en option, ça peut être compliqué de déterminer si une saisie est fille directe d'un conteneur inline, non ? je suis pas fan du 'à la main' qui fait trop peser sur la personne, et est donc très technique. je vois 2 solutions : - soit effectivement on arrive à determiner cela au niveau du constructeur, mais sauf erreur de me part cela n'existe pas actuellement "determiner le parent de la saisie actuelle", et j'ai peur que cela complexifie le code pour pas grand chose (à moins que l'on triche et que l'on fasse le masquage en css) - soit on propose systèmeatiquement les choix mais on met un gros avertissement auparavant
Owner

Je pense que ça part dans trop du détail alors qu'à la base yavait même pas d'inline du tout.

C'est déjà très très bien si 1) on peut faire de l'inline, et 2) on peut dans une option de la saisie inline déterminer le nombre de colonnes à l'avance.

Si pas de colonnes particulière : ça met juste en inline avec la taille "au mieux" de chaque élément (flex sait faire ça normalement), et si ya un nombre de colonnes, alors c'est réparti équitablement (50% ou 33% ou 25%). Dans les deux cas avec wrap.

Je pense que ça part dans trop du détail alors qu'à la base yavait même pas d'inline du tout. C'est déjà très très bien si 1) on peut faire de l'inline, et 2) on peut *dans une option de la saisie inline* déterminer le nombre de colonnes à l'avance. Si pas de colonnes particulière : ça met juste en inline avec la taille "au mieux" de chaque élément (flex sait faire ça normalement), et si ya un nombre de colonnes, alors c'est réparti équitablement (50% ou 33% ou 25%). Dans les deux cas avec wrap.
Poster
Collaborator

Je propose effectivement de commencer par cela, et si le besoin se fait sentir, de voir ce qu'il en est.

Je propose effectivement de commencer par cela, et si le besoin se fait sentir, de voir ce qu'il en est.
Collaborator

+1, très bien, et on verra à l'usage.

+1, très bien, et on verra à l'usage.
Poster
Collaborator

du coup @nicod_ tu peux faire les ajustements suite à nos discussions ? et quid de la nomenclatura finalement ?

du coup @nicod_ tu peux faire les ajustements suite à nos discussions ? et quid de la nomenclatura finalement ?
nicod_ added 2 commits 1 year ago
d7591cbc55 Injecter la classe 'nombre de colonnes' et gérer l'affichage.
Collaborator

Ayé, et ça marche plutôt bien :)

Ayé, et ça marche plutôt bien :)
Poster
Collaborator

et du coup on partirait pour incorporer ces classes sur le core ? @tcharlss ?

et du coup on partirait pour incorporer ces classes sur le core ? @tcharlss ?
Collaborator

Ah pourquoi pas oui, ça peut être utile pour les gens qui n'utilisent pas saisies :)

Ah pourquoi pas oui, ça peut être utile pour les gens qui n'utilisent pas saisies :)
Owner

@maieul Oui les classes pourraient sans doute être utiles dans le core, après tout il y avait déjà l'ébauche d'un mode 2 colonnes sur le form des préférences (mais pas tout propre en grid comme ici).

À garder dans un coin de la tête, dans un 1er temps il faudrait finir de trancher sur la structure de base quand même (les fieldsets où et comment, tout ça). Je crois que la dernière proposition avait l'air de convenir, mais faut l'acter.

@maieul Oui les classes pourraient sans doute être utiles dans le core, après tout il y avait déjà l'ébauche d'un mode 2 colonnes sur le form des préférences (mais pas tout propre en grid comme ici). À garder dans un coin de la tête, dans un 1er temps il faudrait finir de trancher sur la structure de base quand même (les fieldsets où et comment, tout ça). Je crois que la dernière proposition avait l'air de convenir, mais faut l'acter.
Poster
Collaborator

@tcharlss ma question portait plus sur "est-ce qu'on part maintenant avec cette nomenclature car si on intègre dans le core ce sera celle là, et donc on peut fusionner" qu'azutre chose.

@tcharlss ma question portait plus sur "est-ce qu'on part maintenant avec cette nomenclature car si on intègre dans le core ce sera celle là, et donc on peut fusionner" qu'azutre chose.
nicod_ added 1 commit 1 year ago
Collaborator

Mise à jour :

Un premier div englobant avec .conteneur_inline

Ajout de .editer-groupe_inline sur le div .editer-groupe, affichage sur une seule ligne quel que soit le nombre d'éléments (nowrap)

Ajout de .editer-groupe_2_colonnes pour affichage en 2 colonnes avec retours à la ligne si plus d'éléments (wrap), variantes possible en 3 et 4 colonnes.

Exemple de markup généré par la saisie :

<div class="avec-sous-saisies conteneur_inline saisie_conteneur_inline">
	<div class="editer-groupe editer-groupe_inline editer-groupe_3_colonnes">
		<div class="editer">
            ...
        </div>
		<div class="editer">
            ...
        </div>
		<div class="editer">
            ...
        </div>
    </div>
</div>
Mise à jour : Un premier div englobant avec `.conteneur_inline` Ajout de `.editer-groupe_inline` sur le div `.editer-groupe`, affichage sur une seule ligne quel que soit le nombre d'éléments (**nowrap**) Ajout de `.editer-groupe_2_colonnes` pour affichage en 2 colonnes avec retours à la ligne si plus d'éléments (**wrap**), variantes possible en 3 et 4 colonnes. Exemple de markup généré par la saisie : ``` html <div class="avec-sous-saisies conteneur_inline saisie_conteneur_inline"> <div class="editer-groupe editer-groupe_inline editer-groupe_3_colonnes"> <div class="editer"> ... </div> <div class="editer"> ... </div> <div class="editer"> ... </div> </div> </div> ```
Owner

Ok merci pour l'exemple. Mais c'est toujours pas hyper clair pour mon petit cerveau les ami⋅e⋅s.

Le .conteneur_inline il est lui même dans un .editer-groupe, au même niveau que les autres .editer c'est ça ?
On peut partir d'un exemple simple, et voir ce que ça donnerait avant / après ?
Si on reprend l'exemple donné par @maieul plus haut, un formulaire avec entre autres des champs d'adresse :

form
  .editer-groupe
    .editer (nom)
    .editer (voie)
    .editer (rue)
    .editer (cp)
    .editer (ville)
    .editer (tel)

Si on veut regrouper voie + rue, et cp + ville, ça donnerait quoi ?

Une remarque sur le nommage, si on veut des règles CSS communes à tous les groupes en colonnes, avec editer-groupe_3_colonnes ça oblige à répéter le sélecteur pour toutes les variantes possibles :

.editer-groupe_2_colonnes,
.editer-groupe_3_colonnes,
.editer-groupe_4_colonnes { display: grid }

En nommant dans le sens inverse ça simplifie, .editer-groupe_cols-2 par exemple :

[class*=editer-groupe_cols] { display: grid }

Prévoir aussi une variante pour un nombre de colonnes automatiques, ce que css-grid fait très bien.

Ok merci pour l'exemple. Mais c'est toujours pas hyper clair pour mon petit cerveau les ami⋅e⋅s. Le `.conteneur_inline` il est lui même dans un `.editer-groupe`, au même niveau que les autres `.editer` c'est ça ? On peut partir d'un exemple simple, et voir ce que ça donnerait avant / après ? Si on reprend l'exemple donné par @maieul plus haut, un formulaire avec entre autres des champs d'adresse : ``` form .editer-groupe .editer (nom) .editer (voie) .editer (rue) .editer (cp) .editer (ville) .editer (tel) ``` Si on veut regrouper **voie + rue**, et **cp + ville**, ça donnerait quoi ? Une remarque sur le nommage, si on veut des règles CSS communes à tous les groupes en colonnes, avec `editer-groupe_3_colonnes` ça oblige à répéter le sélecteur pour toutes les variantes possibles : ```css .editer-groupe_2_colonnes, .editer-groupe_3_colonnes, .editer-groupe_4_colonnes { display: grid } ``` En nommant dans le sens inverse ça simplifie, `.editer-groupe_cols-2` par exemple : ```css [class*=editer-groupe_cols] { display: grid } ``` Prévoir aussi une variante pour un nombre de colonnes automatiques, ce que css-grid fait très bien.
Owner

j'ai posé la question un peu plus haut, justement car on disait que ça faisait beaucoup d'imbrication pas forcément nécessaire : quelle est la raison (utilitaire ?) d'avoir deux niveaux à la fois généré par la saisie inline ?

Déjà pour la 4.0 on va possiblement virer le div désormais inutile qui entoure les fieldsets, et du coup la saisie de la branche pour cette version de SPIP générera directement le fieldset à la racine de ce que génère la saisie.

Là ça serait pareil : directement le sous-groupe "inline", et dedans les champs enfants. Normalement ça suffit puisque c'est ce wrapper qu'on met en flex wrap ou grid, et ensuite ya les enfants dedans qui s'alignent.

Ça permettrait aussi de le proposer possiblement en tant que norme pour le core, sans rapport avec saisie : dans tout editer-groupe (qui est l'entourage de "une liste de champs") on peut faire des sous-groupes "lignes" : juste un niveau suffit pour ça.

À terme à la fin du fin :

form
  div.editer-groupe
    fieldset.fieldset /* vrai groupe */
      legend
      div.editer-groupe
        (div|fieldset).editer × N
    fieldset.fieldset /* 2e vrai groupe */
      legend
      div.editer-groupe
        div.editer-groupe_inline /* une ligne */
          (div|fieldset).editer × N
        div.editer-groupe_inline /* une 2e ligne */
          (div|fieldset).editer × N
        (div|fieldset).editer × N /* autres champs pas en ligne */

carrément moins d'imbrication qu'avant :)

au passage @tcharlss ça te fait là un récap de tout ce qui existerait in fine

j'ai posé la question un peu plus haut, justement car on disait que ça faisait beaucoup d'imbrication pas forcément nécessaire : quelle est la raison (utilitaire ?) d'avoir deux niveaux à la fois généré par la saisie inline ? Déjà pour la 4.0 on va possiblement virer le div désormais inutile qui entoure les fieldsets, et du coup la saisie de la branche pour cette version de SPIP générera directement le fieldset à la racine de ce que génère la saisie. Là ça serait pareil : directement le sous-groupe "inline", et dedans les champs enfants. Normalement ça suffit puisque c'est ce wrapper qu'on met en flex wrap ou grid, et ensuite ya les enfants dedans qui s'alignent. Ça permettrait aussi de le proposer possiblement en tant que norme pour le core, sans rapport avec saisie : dans tout editer-groupe (qui est l'entourage de "une liste de champs") on peut faire des sous-groupes "lignes" : juste un niveau suffit pour ça. À terme à la fin du fin : ``` css form div.editer-groupe fieldset.fieldset /* vrai groupe */ legend div.editer-groupe (div|fieldset).editer × N fieldset.fieldset /* 2e vrai groupe */ legend div.editer-groupe div.editer-groupe_inline /* une ligne */ (div|fieldset).editer × N div.editer-groupe_inline /* une 2e ligne */ (div|fieldset).editer × N (div|fieldset).editer × N /* autres champs pas en ligne */ ``` carrément moins d'imbrication qu'avant :) au passage @tcharlss ça te fait là un récap de tout ce qui existerait in fine
Poster
Collaborator

j'ai posé la question un peu plus haut, justement car on disait que ça faisait beaucoup d'imbrication pas forcément nécessaire : quelle est la raison (utilitaire ?) d'avoir deux niveaux à la fois généré par la saisie inline ?

c'était juste pour imiter fieldset. Mais si depuis ca a changé, on peut simplifier :)

> j'ai posé la question un peu plus haut, justement car on disait que ça faisait beaucoup d'imbrication pas forcément nécessaire : quelle est la raison (utilitaire ?) d'avoir deux niveaux à la fois généré par la saisie inline ? c'était juste pour imiter fieldset. Mais si depuis ca a changé, on peut simplifier :)
Owner

Avec un exemple réel pour @tcharlss 👍:

form
  div.editer-groupe
    div.editer-groupe_inline
      div.editer /* prénom */
      div.editer /* nom */
    div.editer-groupe_inline
      div.editer /* email */
      div.editer /* téléphone */
    fieldset.fieldset
      legend /* adresse */
      div.editer-groupe
        div.editer /* voie */
        div.editer-groupe_inline
          div.editer /* code postal */
          div.editer /* ville */
    div.editer /* Votre message */
    div.etc

Autre exemple réel plus complet encore :

form
  div.editer-groupe
    div.editer-groupe_inline /* deux champs côte à côte */
      div.editer /* prénom */
      div.editer /* nom */
    div.editer-groupe_inline /* deux vrais groupes côte à côte */
      fieldset.fieldset /* qui peuvent eux-mêmes avoir des champs en ligne */
        legend /* adresse de livraison */
        div.editer-groupe
          div.editer /* voie */
          div.editer-groupe_inline
            div.editer /* code postal */
            div.editer /* ville */
      fieldset.fieldset
        legend /* adresse de facturation */
        div.editer-groupe
          div.editer /* voie */
          div.editer-groupe_inline
            div.editer /* code postal */
            div.editer /* ville */
    div.editer /* Votre message */
    div.etc
Avec un exemple réel pour @tcharlss 👍: ``` css form div.editer-groupe div.editer-groupe_inline div.editer /* prénom */ div.editer /* nom */ div.editer-groupe_inline div.editer /* email */ div.editer /* téléphone */ fieldset.fieldset legend /* adresse */ div.editer-groupe div.editer /* voie */ div.editer-groupe_inline div.editer /* code postal */ div.editer /* ville */ div.editer /* Votre message */ div.etc ``` Autre exemple réel plus complet encore : ``` css form div.editer-groupe div.editer-groupe_inline /* deux champs côte à côte */ div.editer /* prénom */ div.editer /* nom */ div.editer-groupe_inline /* deux vrais groupes côte à côte */ fieldset.fieldset /* qui peuvent eux-mêmes avoir des champs en ligne */ legend /* adresse de livraison */ div.editer-groupe div.editer /* voie */ div.editer-groupe_inline div.editer /* code postal */ div.editer /* ville */ fieldset.fieldset legend /* adresse de facturation */ div.editer-groupe div.editer /* voie */ div.editer-groupe_inline div.editer /* code postal */ div.editer /* ville */ div.editer /* Votre message */ div.etc ```
Owner

Ok merci pour les exemples @rastapopoulos , ça clarifie. Donc avec cette proposition il y aurait tout : le regroupement juste visuel et le vrai regroupement fieldset sémantique (qui peut lui aussi en avoir des visuels à l'intérieur si besoin).

Autre question : les variantes de colonnage s'ajoutent aussi aux .editer-groupe ok, mais forcément en complément de .editer-groupe_inline, ou complètement indépendamment ?
Autrement dit : je « veux afficher ces .editer ensembles ET en N colonnes », ou « je veux afficher ces .editer en N colonnes » tout court ? Si vous voyez la subtilité.

Et bon quand même, avant de pousser à adopter super vite un truc dans le core pour répondre à l'agenda de saisies, on peut se laisser un peu de temps pour réfléchir, merci :p

Ok merci pour les exemples @rastapopoulos , ça clarifie. Donc avec cette proposition il y aurait tout : le regroupement juste visuel et le vrai regroupement fieldset sémantique (qui peut lui aussi en avoir des visuels à l'intérieur si besoin). Autre question : les variantes de colonnage s'ajoutent aussi aux `.editer-groupe` ok, mais forcément en complément de `.editer-groupe_inline`, ou complètement indépendamment ? Autrement dit : je « veux afficher ces `.editer` ensembles **ET** en N colonnes », ou « je veux afficher ces `.editer` en N colonnes » tout court ? Si vous voyez la subtilité. Et bon quand même, avant de pousser à adopter super vite un truc dans le core pour répondre à l'agenda de saisies, on peut se laisser un peu de temps pour réfléchir, merci :p
Owner

@tcharlss je pense que ça doit toujours être en tant que variante de l'inline, car option de ce même parent :

div.editer-groupe_inline.editer-groupe_colonnes_2

par ailleurs semi troll : est-ce que ça doit s'appeler inline, ou grid ? bon en vrai ça va toujours être pour mettre en ligne, même si ça passe sur plusieurs lignes suivant la largeur de colonne configurée :p

@tcharlss je pense que ça doit toujours être en tant que variante de l'inline, car option de ce même parent : ``` css div.editer-groupe_inline.editer-groupe_colonnes_2 ``` par ailleurs semi troll : est-ce que ça doit s'appeler inline, ou grid ? bon en vrai ça va toujours être pour mettre en ligne, même si ça passe sur plusieurs lignes suivant la largeur de colonne configurée :p
Poster
Collaborator

Et bon quand même, avant de pousser à adopter super vite un truc dans le core pour répondre à l'agenda de saisies, on peut se laisser un peu de temps pour réfléchir, merci :p

moi mon poitn c'est juste : on ne merge pas tant que c'est pas clarifié et qu'on est pas d'accord :) après il y a pas d'urgence à ce que ce soit dans le core, mais il faudrait que si ca vienne un jour dans le core, ca bouge pas

> Et bon quand même, avant de pousser à adopter super vite un truc dans le core pour répondre à l'agenda de saisies, on peut se laisser un peu de temps pour réfléchir, merci :p moi mon poitn c'est juste : on ne merge pas tant que c'est pas clarifié et qu'on est pas d'accord :) après il y a pas d'urgence à ce que ce soit dans le core, mais il faudrait que si ca vienne un jour dans le core, ca bouge pas
Owner

on ne merge pas tant que pas clarifié : ça oui

en revanche une fois ok, on n'est pas obligé que ce soit intégré dans le core, pour déjà l'utiliser et le releaser dans Saisies :)

ça nécessite bien sûr dans ce cas d'ajouter du CSS dans l'admin et dans le public, tant que le noyau n'a pas cette fonctionnalité prévue

(mais si ça peut à un moment, tôt ou tard, être directement prévu dans la norme du core, c'est cool)

on ne merge pas tant que pas clarifié : ça oui en revanche une fois ok, on n'est pas obligé que ce soit intégré dans le core, pour déjà l'utiliser et le releaser dans Saisies :) ça nécessite bien sûr dans ce cas d'ajouter du CSS dans l'admin et dans le public, tant que le noyau n'a pas cette fonctionnalité prévue (mais si ça peut à un moment, tôt ou tard, être directement prévu dans la norme du core, c'est cool)
Poster
Collaborator

@rastapopoulos on est d'accord

@rastapopoulos on est d'accord
Owner

@rastapopoulos : En fait je posais la question parceque les termes de « inline » et de « colonnes » me semblent pas forcément complémentaires, ça pourrait aussi être soit l'un, soit l'autre.

Inline, c'est juste des items « les uns après les autres », colonnes, c'est des items « alignés sur quelque chose » (une grille implicite).
Et donc ils auraient pas forcément besoin d'être inline pour être en colonnes.

Ça me questionne sur les termes aux-mêmes, indépendamment de la méthode d'affichage qu'il y aura derrière : inline-block, flex, grid, ou quoi ou qu'est-ce.

(imaginer des champs label+input à la place des blocs)

inline :

colonne / grille :

@maieul : oui donc si ça te bloque pas pour merger, très bien. Tu me disais tantôt sur IRC que pas possible car ces classes se retrouveront dans le public, et donc si changement ultérieur ça cassera chez les gens.

il faudrait que si ca vienne un jour dans le core, ca bouge pas

Moi je suis surtout d'accord avec ça.

@rastapopoulos : En fait je posais la question parceque les termes de « inline » et de « colonnes » me semblent pas forcément complémentaires, ça pourrait aussi être soit l'un, soit l'autre. Inline, c'est juste des items « les uns après les autres », colonnes, c'est des items « alignés sur quelque chose » (une grille implicite). Et donc ils auraient pas forcément besoin d'être inline pour être en colonnes. Ça me questionne sur les termes aux-mêmes, indépendamment de la méthode d'affichage qu'il y aura derrière : inline-block, flex, grid, ou quoi ou qu'est-ce. (imaginer des champs label+input à la place des blocs) inline : ![](https://git.spip.net/attachments/4fe8fb8b-32e9-4c34-95b6-10ea4a461466) colonne / grille : ![](https://git.spip.net/attachments/b7125d0c-720d-4473-ba6c-af603a39f87c) @maieul : oui donc si ça te bloque pas pour merger, très bien. Tu me disais tantôt sur IRC que pas possible car ces classes se retrouveront dans le public, et donc si changement ultérieur ça cassera chez les gens. > il faudrait que si ca vienne un jour dans le core, ca bouge pas Moi je suis surtout d'accord avec ça.
Owner

Ps : j'entends bien que dans Saisies, le workflow via l'interface c'est d'abord d'ajouter la saisie « conteneur inline », donc par défaut avec la classe .editer-groupe_inline. Et ensuite, on active par-dessus l'option de colonnage, donc dans ce sens les 2 paraissent complémentaires.

Mais en dehors de ça, uniquement du point de vue de la charte et du markup, ça fait moins sens.
C'est juste des questions hein.
Sur ce je rends l'antenne.

Ps : j'entends bien que dans Saisies, le workflow via l'interface c'est d'abord d'ajouter la saisie « conteneur inline », donc par défaut avec la classe `.editer-groupe_inline`. Et ensuite, on active *par-dessus* l'option de colonnage, donc dans ce sens les 2 paraissent complémentaires. Mais en dehors de ça, uniquement du point de vue de la charte et du markup, ça fait moins sens. C'est juste des questions hein. Sur ce je rends l'antenne.
Collaborator

Il y a effectivement une clarification à apporter, le nom acutel de la saisie ("Champs sur une ligne") est ambigü si on fonctionne à la fois en ligne et colonnes.

Il y a effectivement une clarification à apporter, le nom acutel de la saisie (*"Champs sur une ligne"*) est ambigü si on fonctionne à la fois en ligne et colonnes.
Collaborator

Y'a un bug : on ne peut pas changer l'ordre des saisies par drag'n drop.
Enfin si, on peut, mais c'est pas enregistré.

Y'a un bug : on ne peut pas changer l'ordre des saisies par drag'n drop. Enfin si, on peut, mais c'est pas enregistré.
Owner

@tcharlss je n'ai pas l'impression que ce soit si éloigné que ça dans le contexte des formulaires

en effet, les colonnes ne sont qu'une définition de la largeur forcée de chaque élément des lignes (peu importe flex ou grid)

  • dans les deux cas ça passe à la ligne si trop d'éléments
  • par défaut ça se pose l'un à la suite de l'autre, avec la taille "au mieux" de chaque élément (suivant leur contenu)
  • et si on défini, ça force une largeur à 25, 33 ou 50%

il n'y a pas d'histoire du genre une colonne 25, une 50, une 25 comme le montre l'image plus haut, c'est juste soit taille du contenu, soit tous les éléments ont la taille XX

ça me parait tordu de faire plus que ça, dans le cadre spécifique de norme générique de formulaire (que ce soit pour saisies ou pour le core)

vouloir plus compliqué, c'est pour 1 cas sur 100 à la marge, donc à faire à la main, mais pas dans une norme générique, à mon avis

@tcharlss je n'ai pas l'impression que ce soit si éloigné que ça *dans le contexte des formulaires* en effet, les colonnes ne sont qu'une définition de la largeur *forcée* de chaque élément des lignes (peu importe flex ou grid) - dans les deux cas ça passe à la ligne si trop d'éléments - par défaut ça se pose l'un à la suite de l'autre, avec la taille "au mieux" de chaque élément (suivant leur contenu) - et si on défini, ça force une largeur à 25, 33 ou 50% il n'y a pas d'histoire du genre une colonne 25, une 50, une 25 comme le montre l'image plus haut, c'est juste soit taille du contenu, soit tous les éléments ont la taille XX ça me parait tordu de faire plus que ça, dans le cadre spécifique de norme générique de formulaire (que ce soit pour saisies ou pour le core) vouloir plus compliqué, c'est pour 1 cas sur 100 à la marge, donc à faire à la main, mais pas dans une norme générique, à mon avis
Poster
Collaborator

@nicod_

Y'a un bug : on ne peut pas changer l'ordre des saisies par drag'n drop.

j'ai eu reproduit ce bug, puis plus. Je me demande si c'est pas des souci de cache lié à x mystère de la nomenclatura Fait un var_mode=recalcul

@tcharlss en gros mon souci: on ne merge pas tant que ces problèmes terminologique et co sont pas résolu :)

@nicod_
ton commit qui est passé en grid a peté un truc sur les marges (en spip 3.2)

Avant
image

Après

image

@nicod_ > Y'a un bug : on ne peut pas changer l'ordre des saisies par drag'n drop. j'ai eu reproduit ce bug, puis plus. Je me demande si c'est pas des souci de cache lié à x mystère de la nomenclatura Fait un var_mode=recalcul @tcharlss en gros mon souci: on ne merge pas tant que ces problèmes terminologique et co sont pas résolu :) @nicod_ ton commit qui est passé en grid a peté un truc sur les marges (en spip 3.2) Avant ![image](/attachments/ec131b32-d138-46e8-9211-31950f840d86) Après ![image](/attachments/c1cd9f98-7007-446a-8f88-99373abd5d63)
maieul added 1 commit 1 year ago
maieul force-pushed conteneur_inline from ba8bd2ea2f to e4c9948ef3 1 year ago
maieul added 4 commits 1 year ago
maieul force-pushed conteneur_inline from ba8bd2ea2f to e4c9948ef3 1 year ago
maieul added 4 commits 1 year ago
maieul force-pushed conteneur_inline from ba8bd2ea2f to b329ae716d 1 year ago
Poster
Collaborator

Pour info, je vais de faire un push force en ayant repris tout ce qu'il y a dans v3.

On verra lorsqu'on se sera décidé si on met cela dans v3 et master, ou uniquement dans master (il commence à y avoir des divergences !)

Pour info, je vais de faire un push force en ayant repris tout ce qu'il y a dans v3. On verra lorsqu'on se sera décidé si on met cela dans v3 et master, ou uniquement dans master (il commence à y avoir des divergences !)
Poster
Collaborator

bon, on fait quoi?

bon, on fait quoi?
Collaborator

Bonjour à toutes,
2022, l'année des e avec des bisouses.

Désolée, ce fil me parait très ardue, si quelqu'in pouvait résumer ce serait chouette :)Voici ma question posé sur contrib
https://contrib.spip.net/Reference-des-saisies#comment509932

et qui concerne juste la possibilité de décider de la class suivant la profondeur et non pas quel class ou quelles caracteristiques de class.

++

Bonjour à toutes, 2022, l'année des e avec des bisouses. Désolée, ce fil me parait très ardue, si quelqu'in pouvait résumer ce serait chouette :)Voici ma question posé sur contrib https://contrib.spip.net/Reference-des-saisies#comment509932 et qui concerne juste la possibilité de décider de la class suivant la profondeur et non pas quel class ou quelles caracteristiques de class. ++
maieul force-pushed conteneur_inline from b329ae716d to 72f8b3486c 7 months ago
Poster
Collaborator

@nicod_ @tcharlss @rastapopoulos je viens de tenter de rattraper cette branche sur le master, en gérant les conflits de merge.

Il y encore des choses à adapter au niveau css. Je vais tenter cet après midi.

Par ailleurs suite discussion irc, on a une reunion demain 10h avec tcharlss, rasta et nicod si tu est dispo, pour essayer d'avancer sur cette question de nomenclatura / structure.

@nicod_ @tcharlss @rastapopoulos je viens de tenter de rattraper cette branche sur le master, en gérant les conflits de merge. Il y encore des choses à adapter au niveau css. Je vais tenter cet après midi. Par ailleurs suite discussion irc, on a une reunion demain 10h avec tcharlss, rasta et nicod si tu est dispo, pour essayer d'avancer sur cette question de nomenclatura / structure.
maieul force-pushed conteneur_inline from 72f8b3486c to b95c1d30c7 7 months ago
Poster
Collaborator

En prévision de cette réunion de demain, et au cas où finalement on arriverait pas à trancher j'ai :

  • nettoyer un peu l'historique de la branche pour merger beaucoup de commit (en gardant l'attribution aux bons auteurs)
  • mis dans master 2 commits qui étendent le constructeur de formulaire pour permettre de gérer tout type de saisies contenant des sous saisies (aka : fieldset et conteneur_inline) pour l'instant : en soit c'est une feature qui devrait être accessible quelque soit le devenir de notre saisie conteneur_inline.

Next rounds de réécriture de l'historique : avoir une icone format svg

En prévision de cette réunion de demain, et au cas où finalement on arriverait pas à trancher j'ai : - nettoyer un peu l'historique de la branche pour merger beaucoup de commit (en gardant l'attribution aux bons auteurs) - mis dans master 2 commits qui étendent le constructeur de formulaire pour permettre de gérer tout type de saisies contenant des sous saisies (aka : fieldset et conteneur_inline) pour l'instant : en soit c'est une feature qui devrait être accessible quelque soit le devenir de notre saisie conteneur_inline. Next rounds de réécriture de l'historique : avoir une icone format svg
maieul force-pushed conteneur_inline from b95c1d30c7 to 2b3dc99014 7 months ago
maieul force-pushed conteneur_inline from 2b3dc99014 to 53a4ef311a 7 months ago
Owner

CR de la réunion

Normalement on a tout ce qu'il faut pour finir cette PR.

À faire

  • Nomenclature : nom de la saisie et des options d'affichage (@maieul ?)
  • Configuration / affichage : ajouter une explication ou un message important invitant à vérifier la taille de chaque sous-saisie (attribut size des input texte notamment) (@maieul ?)
  • CSS privé/public : màj les règles concernant la saisie (@tcharlss)
  • CSS du constructeur : régler les problèmes de gouttières, etc. (@tcharlss)
  • Supprimer une imbrication en trop dans conteneur_inline (@tcharlss) et adapter les css
  • Nouvelle branche où on supprime une imbrication en trop dans le fieldset (@maieul + @tcharlss pour les onglets)

Markup

On va en profiter pour enlever une imbrication non nécessaire sur les saisies fieldset et inline : un div conteneur inutile.
Ça sera fait dans une branche de dev séparée, elle sera mergée dans celle-là plus tard.

On mettra ça dans la v5, même si ça peut potentiellement amener les gens à devoir faire quelques ajustements sur leurs styles persos.

Cela suppose aussi d'adapter le code js des onglets.

On obtiendrait cela au final :

Saisie inline :

div.editer-groupe_inline[.editer-groupe_N_colonnes]
  div.editer
  div.editer
  div.editer
  …

Saisie fieldset :

fieldset.fieldset
  div.editer-groupe
     div.editer
     div.editer
     div.editer
     …

Nomenclature

Pour distinguer de la saisie « Groupe de champs » qui sert à grouper de façon purement sémantique, on nommerait la nouvelle « Affichage en ligne » puisque c'est que de la cosmétique.

On revoit un peu le wording des options d'affichage (je sais plus ce qu'on avait dit exactement, mais dans l'idée c'était ça) :

  • Saisies en ligne
  • 2 saisies par ligne
  • 3 saisies par ligne
  • 4 saisies par ligne

Affichage

L'affichage de base doit vraiment être purement inline, et par conséquent conserver la largeur "naturelle" de chaque sous-saisie. Il ne faut donc pas forcer leur largeur de façon arbitraire avec flex-basis, ni permettre flex-grow.
On vire donc la règle flex: 1 1 4em.

Pour les saisies input text, ça sera la valeur de l'attribut size qui fera effet (si c'est un élément flex, le width: 100% n'a pas d'effet).

C'est bien ce qu'on recherche, ça permet de garder la main si on veut des textes plus courts que d'autres, comme pour civilité - prénom - nom par exemple.

En contrepartie il faut inviter les gens à vérifier cette valeur, on ajoutera donc un texte d'explication au niveau des options d'affichage de la saisie inline.


Ping @maieul @rastapopoulos je pense qu'on pourrait avoir une option d'affichage supplémentaire : affichage en N colonnes, mais sans nombre prédéfini.

Au lieu de faire grid-template-columns: repeat(2, 1fr) qui donne 2 colonnes par ex., on peut faire quelque chose comme grid-template-columns: repeat(auto-fit, minmax(5em,1fr))

L’avantage c'est que c'est naturellement responsive.
Après je sais pas comment nommer cette option, dans l'ordre ça pourrait être en 2ème.

  • Saisies en ligne
  • N saisies par ligne
  • 2 saisies par ligne
  • 3 saisies par ligne
  • 4 saisies par ligne
## CR de la réunion Normalement on a tout ce qu'il faut pour finir cette PR. ## À faire - [x] Nomenclature : nom de la saisie et des options d'affichage (@maieul ?) - [x] Configuration / affichage : ajouter une explication ou un message important invitant à vérifier la taille de chaque sous-saisie (attribut `size` des input texte notamment) (@maieul ?) - [ ] CSS privé/public : màj les règles concernant la saisie (@tcharlss) - [ ] CSS du constructeur : régler les problèmes de gouttières, etc. (@tcharlss) - [ ] Supprimer une imbrication en trop dans conteneur_inline (@tcharlss) et adapter les css - [ ] Nouvelle branche où on supprime une imbrication en trop dans le fieldset (@maieul + @tcharlss pour les onglets) ### Markup On va en profiter pour enlever une imbrication non nécessaire sur les saisies fieldset et inline : un div conteneur inutile. Ça sera fait dans une branche de dev séparée, elle sera mergée dans celle-là plus tard. On mettra ça dans la v5, même si ça peut potentiellement amener les gens à devoir faire quelques ajustements sur leurs styles persos. Cela suppose aussi d'adapter le code js des onglets. On obtiendrait cela au final : Saisie inline : ``` div.editer-groupe_inline[.editer-groupe_N_colonnes] div.editer div.editer div.editer … ``` Saisie fieldset : ``` fieldset.fieldset div.editer-groupe div.editer div.editer div.editer … ``` ### Nomenclature Pour distinguer de la saisie « Groupe de champs » qui sert à grouper de façon purement sémantique, on nommerait la nouvelle « Affichage en ligne » puisque c'est que de la cosmétique. On revoit un peu le wording des options d'affichage (je sais plus ce qu'on avait dit exactement, mais dans l'idée c'était ça) : * Saisies en ligne * 2 saisies par ligne * 3 saisies par ligne * 4 saisies par ligne ### Affichage L'affichage de base doit vraiment être purement inline, et par conséquent conserver la largeur "naturelle" de chaque sous-saisie. Il ne faut donc pas forcer leur largeur de façon arbitraire avec `flex-basis`, ni permettre `flex-grow`. On vire donc la règle `flex: 1 1 4em`. Pour les saisies input text, ça sera la valeur de l'attribut `size` qui fera effet (si c'est un élément flex, le `width: 100%` n'a pas d'effet). C'est bien ce qu'on recherche, ça permet de garder la main si on veut des textes plus courts que d'autres, comme pour `civilité - prénom - nom` par exemple. En contrepartie il faut inviter les gens à vérifier cette valeur, on ajoutera donc un texte d'explication au niveau des options d'affichage de la saisie inline. ---- Ping @maieul @rastapopoulos je pense qu'on pourrait avoir une option d'affichage supplémentaire : affichage en N colonnes, mais sans nombre prédéfini. Au lieu de faire `grid-template-columns: repeat(2, 1fr)` qui donne 2 colonnes par ex., on peut faire quelque chose comme `grid-template-columns: repeat(auto-fit, minmax(5em,1fr))` L’avantage c'est que c'est naturellement responsive. Après je sais pas comment nommer cette option, dans l'ordre ça pourrait être en 2ème. * Saisies en ligne * **N saisies par ligne** * 2 saisies par ligne * 3 saisies par ligne * 4 saisies par ligne
maieul added 3 commits 7 months ago
maieul force-pushed conteneur_inline from b8fcecd87a to 55f57f158c 7 months ago
Poster
Collaborator

@tcharlss merci pour le CR.

  • J'ai corrigé également dans la todolist en ajoutant qu'il fallait aussi supprimer le niveau de trop dans le conteneur inline.
  • J'ai tenté de le faire mais mes css étaient tout tout cassés. Après 2-3 tentatives de decassage, j'ai laissé tomber : je pense que plus experts que moi y arriverons très rapidement.
  • pour ton je comprend l'idée, mais là tu introduit un min de 5em. Quelle justification à ce choix ?
  • idée de nom "Saisies par ligne, de largeur égales d'une ligne à l'autre " ?
@tcharlss merci pour le CR. - J'ai corrigé également dans la todolist en ajoutant qu'il fallait aussi supprimer le niveau de trop dans le conteneur inline. - J'ai tenté de le faire mais mes css étaient tout tout cassés. Après 2-3 tentatives de decassage, j'ai laissé tomber : je pense que plus experts que moi y arriverons très rapidement. - pour ton je comprend l'idée, mais là tu introduit un min de 5em. Quelle justification à ce choix ? - idée de nom "Saisies par ligne, de largeur égales d'une ligne à l'autre " ?
maieul force-pushed conteneur_inline from 55f57f158c to 5fbcd0a1d3 7 months ago
maieul force-pushed conteneur_inline from 5fbcd0a1d3 to 861d40fd64 7 months ago
maieul force-pushed conteneur_inline from 861d40fd64 to 832c0d1940 7 months ago
maieul force-pushed conteneur_inline from 832c0d1940 to cc60ef21ad 7 months ago
Poster
Collaborator

@tcharlss une petite relance pour finaliser cette PR ?

@tcharlss une petite relance pour finaliser cette PR ?
maieul force-pushed conteneur_inline from cc60ef21ad to 15f7f8c16b 4 months ago
maieul force-pushed conteneur_inline from 15f7f8c16b to 3f7cb563be 4 months ago
maieul force-pushed conteneur_inline from 3f7cb563be to 15f7f8c16b 4 months ago
maieul force-pushed conteneur_inline from 15f7f8c16b to f9a59a4261 4 months ago
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.