Produits Entr'ouvert » w.c.s.

Dans l'état, il faudrait déconseiller de mettre l'option `(grow)` sur le bouton `previous` qui n'est pas systématiquement présent (mise à jour de la doc).

Sinon, comme propositions :

• faire en sorte que previous soit toujours présent dans le code, mais avec un attribut `disabled` dessus (et son container du coup) et masquer ou non ce bouton à l'aide d'un `display:none`. Et si option (grow) est placé dessus, mettre à la place un visibility: hidden,
• soit trouver une solution pur CSS que je n'entrevois pas encore.

Il me semblait que de l'autre côté il y avait un contournement qui marchait ?

Il me semblait que de l'autre côté il y avait un contournement qui marchait ?

Dans un cas spécifique, oui. Et c'était une mauvaise idée, conseiller la modification de $buttons-alignment aurait été préférable :

Je récapitule pour flex-start et flex-end,
si l'option (grow) est placé sur le bouton previous, quand il n'est pas présent, la position des boutons qui l'entourent peuvent être modifiés

1/ l'alignement des boutons est en `flex-start`

Quand le bouton previous est en 1ère ou 2e position

previous (grow), cancel, submit
ou
cancel, previous (grow), submit

Alors le⋅s bouton⋅s placés APRÈS `previous` perdent leur positionnement à droite quand previous n'est pas présent et repassent à gauche

1/ l'alignement des boutons est en `flex-end`

Alors c'est l'inverse
Quand le bouton previous est en 2e ou 3e position
Alors le⋅s bouton⋅s placés AVANT `previous` perdent leur positionnement à gauche quand previous n'est pas présent et passent à droite.

Exemple 1. Previous position 1.
Dans le cas de la Dordogne où l'affichage doit être

previous --> cancel Submit

Il faut donc utiliser

$buttons-order: previous, cancel (grow), submit;
$buttons-alignment: flex-end

ET pas

$buttons-order: previous (grow), cancel, submit;
$buttons-alignment: flex-start // default

Exemple 2, previous position 2.
Dans le cas où on souhaite

cancel previous --> Submmit

Idem, La solution est d'aligner à droite et de faire un grow sur Submit

$buttons-order: cancel, previous, submit (grow);
$buttons-alignment: flex-end

Après avoir détaillé tout ça, pour moi, déconseiller l'utilisation de l'option grow sur previous devrait suffire.
Par contre, que le bouton soit présent dans le code avec l'option 'visibity;:hidden' permettrait quand même de pouvoir 'conserver' l'emplacement du bouton dans d'autres configurations d'alignement (center, space-between) et rendrait les options de placement moins confus.

Je ne comprends toujours pas, mais c'est sans doute parce que ce ticket a été créé trop générique.

Du cas Dordogne, qui posait : $buttons-order: previous (grow), cancel, submit;

À ça on dit "dans ce cas précis il faut également poser telle ou telle option".

Et j'imaginais ce ticket comme étant mettre dans le code le "dans ce cas précis également poser telle ou telle option".

(...) déconseiller l'utilisation de l'option grow sur previous devrait suffire

En l'état elle ne produit pas, seule, un comportement convenable.

Est-ce qu'il y a des moments où elle produit un comportement qui serait souhaité ?

Si oui, mais en combinaison avec d'autres options, a-t-on de quoi les poser ?

Si non, a-t-on de quoi interdire le previous (grow) ?

Pour moi c'est bon, mais je trouve ça compliqué à tester (je sais pas comment déboguer du code scss).
Et surtout très spécifique.
Je pense comme toi qu'une solution du coté du code HTML serait plus adaptée.

je sais pas comment déboguer du code scss

Dans le code SCSS tu peux poser des `@debug()`: https://sass-lang.com/documentation/at-rules/debug

Je pense comme toi qu'une solution du coté du code HTML serait plus adaptée.

N'hésite pas à proposer un patch côté WCS :)

Automatic expiration