Project

General

Profile

Anomalie #4623

Styles des fieldset dans l'espace privé

Added by Maïeul Rouquette 4 months ago. Updated 19 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
01/08/2021
Due date:
% Done:

0%

Resolution:
Navigateur:

Description

Le style des fieldset dans l'espace privé
1. Ne marquent pas clairement la fin de fieldset
2. Marque mal l'imbrication

Il faudra améliorer cela.

Cf. https://git.spip.net/spip-contrib-extensions/saisies/pulls/55#issuecomment-2997

Screenshot_2021-04-16 [Mon site SPIP] 1 Un article pour tester la charte.png View (42.3 KB) nicod _, 04/16/2021 06:02 PM

Capture d’écran 2021-04-17 à 11.52.58.png View - Formidable fieldset bordure gauche (90.9 KB) marcimat 🌻, 04/17/2021 10:07 AM

Capture d’écran 2021-04-17 à 11.53.12.png View - Form spip bordure gauche (178 KB) marcimat 🌻, 04/17/2021 10:07 AM

Capture d’écran 2021-04-17 à 11.55.59.png View - Form spip n2 bordure gauche (122 KB) marcimat 🌻, 04/17/2021 10:09 AM

Capture d’écran 2021-04-17 à 11.55.26.png View - Formidable fiieldset n2 bordure gauche (213 KB) marcimat 🌻, 04/17/2021 10:09 AM

Capture-d’écran-2021-04-17-à-12.37.png View (18.6 KB) nicod _, 04/17/2021 10:39 AM

Screenshot_2021-04-17 arrondis.png View (40.8 KB) nicod _, 04/17/2021 11:36 AM

History

#1 Updated by cedric - 3 months ago

  • Target version set to 4.1

oui enfin il faudrait pas faire peser sur tout le monde les besoins de saisie ^^
Les fieldset de l'espace privé sont stylés pour l'usage qu'on en fait, pas pour des trucs emboités dans tous les sens à tiroir etc.

#2 Updated by RastaPopoulos ♥ 3 months ago

Saisies n'est qu'un exemple, je ne vois pas en quoi c'est spécifique. En HTML on peut bien évitement imbriquer des fieldsets à volonté, et c'est même recommandé pour grouper des blocs complets pour une adresse ou pour les checkboxs multiples d'un même name, ces blocs là eux-mêmes pouvant être dans des grands groupes du formulaire. Les styles de l'admin ne sont pas censés être que pour les 3 objets fournis par le core, ça doit faire partie de tout "framework" ou "design system" d'afficher correctement les forms HTML en général, avec tout ce qu'on peut faire dedans (et un groupe dans un groupe, c'est vite très courant, dès qu'on a des profils, des coordonnées…).

Par ailleurs : même les fieldsets racines sont assez laids. :)

#3 Updated by b b 3 months ago

Par ailleurs : même les fieldsets racines sont assez laids. :)

Mais il seront bien beaux quand quelqu'un se sera occupé d'eux :)

#4 Updated by RastaPopoulos ♥ 22 days ago

Je mets ici un essai fait un peu à l'arrache hier dans le navigateur que j'ai peaufiné un peu ce matin.

Les arguments qui vont avec :
  • Je pense que c'est plus léger visuellement à la fois que le master et que dans la branche de cette PR, y compris pour les groupes racines, car il n'y a pas de coupure horizontale. Quand l'œil parcourt de haut en bas, il n'est pas bloqué par des bordures horizontales qui font que l'esprit s'arrête un instant.
  • Les groupes doivent tous être matérialisés par un début et une fin, y compris les groupes racines : il peut y avoir des champs hors groupe après n'importe quel fieldset, et donc on doit savoir où finit un fieldset.
  • Là je matérialise avec une fine ligne de la couleur du thème, que je fais terminer en dégradé vers le transparent afin de ce soit plus doux (ce n'est pas une border mais une background-image gradient de 1px)
  • De cette manière on voit à la fois le début et la fin, sans coupure de lecture, et avec une indication de 1px seulement. Notamment les groupes racines ne sont pas décalés du tout par rapport au reste : l'indication de 1px se superpose à la bordure existante des formulaires. Ainsi comme on le voit, les champs intérieur au premier groupe racine sont pile au même niveau que les champs en dehors du groupe.

Commentaire supplémentaire : cette légère matérialisation ne se base pas sur la couleur mais sur la luminosité, ainsi ça marche même si on est daltonien. Pour appuyer on peut utiliser spip-color-theme-dark, ou si on veut faire plus neutre, on pourrait aussi virer totalement la couleur et utiliser spip-color-gray-dark aussi bien pour la ligne dégradé que pour le legend. Le principe restant le même.

Version monochrome avec spip-color-gray-dark (plus foncé que précédemment), on voit quand même pas mal la diff à tous les niveaux.

#5 Updated by nicod _ 22 days ago

Le principe est pas mal, mais je n'aime pas trop ces dégradés sur la fin des bordures, ça fait "pas net" et ça ne correspond à aucun autre élément d'UI.
Tu as essayé avec juste une bordure à gauche, mais très légère (en luminosité/opacité) et épaisse (0.33em) ?

Pétouille : au niveau des marges, la légende d'un fieldset imbriqué devrait être plus proche de ses champs, que des champs du fieldset parent.
Et je trouve bizarre que l'input du fieldset imbriqué soit décalé lui aussi vers la droite, même si ça parait logique, c'est bizarre visuellement.

#7 Updated by b b 22 days ago

J'aime assez ta proposition @nicod, comme elle garde la ligne qui file du libellé du fieldset vers la droite, je me demande si ça ne serait pas encore plus "percutant" en collant la bordure non pas sur la gauche, mais sur la droite, ainsi on aurait un "bel" effet de fermeture/englobante visuelle (quand on lit de gauche à droite).

#8 Updated by RastaPopoulos ♥ 21 days ago

Alors c'est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.

Je détaille l'argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n'est pas grave si ce n'est que de la déco. Alors qu'un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s'agit d'une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.

Pour les barres horizontales, là aussi c'était voulu de les enlever, afin d'alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d'œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n'en rajoute pas dans ce domaine.

Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c'est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c'est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu'on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.

#9 Updated by marcimat 🌻 21 days ago

À vous entendre j'ai un peu l'impression que c'est insoluble.

À titre personnel :

- j'aimais bien la démarcation bordure top du fieldset (au contraire même je trouve quelle améliore la lecture, enfin pour celui du premier niveau)
- je n'aime pas pour sûr non plus le dégradé de bordure sur la proposition de Rasta
- et je ne suis pas choqué du tout par le "cadre" de la proposition de Nicod ;

Ce qui me gène par contre un peu plus c'est de démarquer le premier niveau de fieldset ; ou alors il faudrait pouvoir le désactiver avec une classe.

Je comprends l'argument que tu disais pour "si tu demandes une date en 3 parties jour | mois | annee" (ou je sais plus exactement) tu as besoin que ça se démarque.
Mais pour pas mal de formulaires utilisés dans SPIP démarquer plus le fieldset de premier niveau est pas utile (d'où peut être de pouvoir désactiver au besoin son décalage). Si tu regardes ?exec=configurer_contenu : il n' a pas besoin de plus que ça actuellement.

Maintenant si ça doit être fait quand même, ce que propose Nicod me parait vaguement plus agréable, même si c'est peut être pas assez distinctif. J'enlèverais la marge blanche entre le bord et le premier fieldset également.

Quelques remarques d'alignement :

- Par ailleurs je crois que (comme le montre Nicod) il faut réaligner le legend avec les labels dessous.
- Je dirais même qu'il faut aligner ce legend avec les labels au dessus (c'est à dire en soustrayant de la marge l'éventuelle bordure ajoutée)
- Il ne faudrait pas qu'une éventuelle bordure gauche sur le fieldset dépasse vers le bas (comme encore une fois ce que montre Nicod) ; Ce que je n'ai pas spécialement réussi à faire sur les captures que je montre après (peut être faut décorer la bordure avec un :before {} alors plutôt que de tenter d'altérer les marges des :last-child contenus dans le fieldset)

Je montre différents tests ensuite, pour montrer que mettre un fieldset de premier niveau "visible" c'est pas gégé sur les formulaires de base, et mieux sans (ou faut un truc pour le désactiver - ou inversement l'activer au besoin). En fait il y a peut être besoin de 2 types de fieldsets (de premier niveau)

avec bordure gauche, sans marge gauche, alignements verticaux respectés


Ici le fieldset de premier niveau est bien lourd…

sans bordure gauche de premier niveau, alignements verticaux respectés


Le problème est montré sur le dernier champ du formulaire formidable : on ne sait pas s'il est du fieldset ou possiblement en dehors du fieldset

Bref, tout ça est hyper pas simple. Je n'ai pas l'impression qu'on puisse concilier l'un (la simplicité du premier niveau) sans alourdir visuellement inutilement, et sans proposer 2 «types» de fieldset de premier niveau.
Je parle même pas de la syntaxe avec ou sans div.fieldset en plus…

#10 Updated by nicod _ 21 days ago

marcimat 🌻 a écrit :

Ce qui me gène par contre un peu plus c'est de démarquer le premier niveau de fieldset ; ou alors il faudrait pouvoir le désactiver avec une classe.

Je suis d'accord avec ça, comme rasta l'a dit aussi.
Ça me gêne un peu aussi, mais comme tu le dis :

Je comprends l'argument que tu disais pour "si tu demandes une date en 3 parties jour | mois | annee" (ou je sais plus exactement) tu as besoin que ça se démarque.
Mais pour pas mal de formulaires utilisés dans SPIP démarquer plus le fieldset de premier niveau est pas utile (d'où peut être de pouvoir désactiver au besoin son décalage). Si tu regardes ?exec=configurer_contenu : il n' a pas besoin de plus que ça actuellement.

Peut être une détection automatique, qui vérifierait s'il y a des imbrications, pour formidable au moins ?

Bref, tout ça est hyper pas simple. Je n'ai pas l'impression qu'on puisse concilier l'un (la simplicité du premier niveau) sans alourdir visuellement inutilement, et sans proposer 2 «types» de fieldset de premier niveau.

Non, ce n'est pas simple, mais c'est pour ça qu'on en discute :)
Et je n'ai pas trouvé d'exemple de design un peu moderne et élégant dans des frameworks ou autres.

Je parle même pas de la syntaxe avec ou sans div.fieldset en plus…

Oui, ça c'est probablement une vraie difficulté pour styler de façon générique, sans compter que les radio et checkbox doivent aussi être regroupés dans des fieldsets, c'est dans notre charte maintenant.

#11 Updated by RastaPopoulos ♥ 21 days ago

Le problème est montré sur le dernier champ du formulaire formidable : on ne sait pas s'il est du fieldset ou possiblement en dehors du fieldset

C'est bien pour ça que d'après moi, le cahier des charges doit inclure ce point : "on doit toujours connaitre le début ET la fin d'un groupe, y compris pour les fieldsets racines".
Car à tout moment il peut y avoir des champs avant et après un groupe. Donc on doit savoir quand ça se finit.

Et c'est bien si la solution choisie montre ce début-fin sur 100% des forms sans avoir besoin de faire des exceptions. Et pour ça l'idée c'était justement que ça reste léger visuellement, donc en superposition de la bordure du formulaire pour ce qui est du premier niveau.

#12 Updated by nicod _ 21 days ago

J'aime bien le côté arrondi du coin supérieur gauche de la bordure, avec le changement d'épaisseur.
Je prolongerais un petit peu horizontalement de quelques pixels, pour bien accrocher la légende, et le top serait de terminer le bloc en bas par le même arrondi.
Quelque chose comme ça (bricolé dans Photoshop, j'ai triché)

#13 Updated by marcimat 🌻 21 days ago

C'est bien pour ça que d'après moi, le cahier des charges doit inclure ce point : "on doit toujours connaitre le début ET la fin d'un groupe, y compris pour les fieldsets racines".

Non je ne crois pas Rasta (pour le : y compris pour les fieldsets racines) : ça sous-entends que tu ne sais pas comment va être le formulaire et que la personne qui design du formulaire n'en tient pas compte. C'est peut être vrai pour Formidable potentiellement, mais ce n'est pas vrai pour les formulaires qu'on introduit à la main, comme ceux de ?exec=configurer_contenu où on a une maîtrise totale de ce qu'on fait, et où on peut donc éviter ces problèmes et / ou ajouter une classe au fieldset pour le distinguer.

#14 Updated by marcimat 🌻 21 days ago

Oué c'est mignon Nicod ! Peut être pas facile à faire par contre :p
Avec un border image linear gradient peut être (avec stops 0 gray, marge gray, marge + 1px transparent, 100% transparent)… hum.

#15 Updated by Maïeul Rouquette 21 days ago

Je ne suis pas tout ce qui se passe, j'avoue. Mais cela me parait pas déconnant d'avoir une classe spécifique désignant la profondeur du fieldset (plutot que je juste le premier niveau), et ce ne serait pas très compliqué à adapter saisies pour qu'il s'en charge.

J'ai dit !

#16 Updated by nicod _ 21 days ago

En vraie CSS sans trucage :

.fieldset .fieldset fieldset {
    margin-left: var(--spip-form-gutter-x);
    border-left: 3px solid var(--spip-form-border-color);
    border-radius: 12px;
    margin-bottom: var(--spip-form-gutter-y);
}
.fieldset .fieldset fieldset .editer-groupe:last-child {
    padding-bottom: 0;
}

#17 Updated by tcharlss 🐽 21 days ago

  • Assignee deleted (tcharlss 🐽)

Je suis bien d'accord avec le cahier des charges, mais je trouverais vraiment dommage de changer de représentation des fieldsets à la racine.

Pour ces dernier je trouve que la représentation actuelle est de loin la plus simple, la plus claire et la plus élégante : un simple trait discret en séparation. Ça ne « coupe » pas la lecture, ou disons juste ce qu'il faut pour indiquer qu'on passe à une autre partie.
Et c'est 100% des fieldsets utilisés dans la dist, si ça "pète" ceux-là pour s'accommoder d'éventuels fieldsets imbriqués qu'on ne rencontre quasiment que dans formidable, bof quand même.

En revanche pour ceux imbriqués, oui je trouve qu'un trait de côté est une bonne solution, ça fonctionne bien sans trop alourdir, et ça montre bien le début et la fin. Peu importe les détails : bords arrondis ou pas, trait en haut ou pas, espèce d'angle droit ou pas comme sur les tests de rastapopoulos.
Dans l'ensemble c'est le dernier test de nicod_ qui me semble la meilleure piste.

MAIS (bruit de tonnerre)

Pour montrer la fin des fieldsets à la racine, c'est la galère.
À priori il suffit d'une bordure en bas, ok.
Ça marche si le fieldset est suivi d'autre chose qu'un fieldset.

Mais pas quand 2 fieldsets se suivent : ça fait 2 bordures successives avec un espace entre, c'est bancal.
Il faudrait qu'ils soient "collés" avec une seule bordure partagée, mais j'ai aucune idée de comment faire. Il faudrait un sélecteur CSS "élément suivi de" qui n'existe pas.

#18 Updated by tcharlss 🐽 21 days ago

Ah voilà, un jour... : https://drafts.csswg.org/selectors-4/#relational

Si jai bien compris :

fieldset { border-bottom: 1px solid red; }
fieldset:has(+ fieldset) { border-bottom: 0; }

#19 Updated by tcharlss 🐽 21 days ago

Hu, mais il doit y avoir moyen de ruser tout compte fait : pas de bordure en bas des fieldsets eux-mêmes, mais en haut des trucs qui les suivent. Ça va faire suer pour gérer les marges mais ça doit être jouable.

#20 Updated by cedric - 21 days ago

avec un :last-child-of-type ? ou sinon par defaut pas de border bottom sauf si le fieldset a une class last ?

#21 Updated by tcharlss 🐽 21 days ago

sinon par defaut pas de border bottom sauf si le fieldset a une class last ?

Ah oui avec un classe ça serait bien plus simple, plutôt que de se faire des noeuds CSS à la tête, Saisies pourrait l'ajouter automatiquement.
Cela dit je crois que la règle ne porte pas nécessairement sur les derniers fieldsets, mais sur tous ceux qui ne sont pas suivis d'un autre fieldset. Si je me trompe pas il peut y avoir un .editer ou un .editer-groupe entre 2 fieldsets.

#22 Updated by Maïeul Rouquette 21 days ago

comme exprimé, lorsque vous aurez besoin d'adapter saisies en terme de class, etc, vous me donnez le cahier des charges et je m'en chargerai (sauf si vous voulez le faire vous même !)

#23 Updated by RastaPopoulos ♥ 21 days ago

Bé oui ça n'a pas de rapport avec la fin, c'est que dans n'importe quel form, même sans aucun groupe imbriqué, juste ceux racines, il peut y avoir alternance entre fieldsets et champs. Par ex : Prénom, Nom, Adresse (fieldset regroupant des champs logiques entre eux), Téléphone, Etc.

La règle algorithmique étant : il faut au moins voir la fin de tous les fieldsets qui sont suivis d'un élément n'étant pas un fieldset ni les boutons de fin.

Et je vois mal comment automatiser ça au niveau production du code puisque par exemple pour un objet, qui aurait à la fin un fieldset, on pourrait se dire qu'on n'a pas à voir sa fin, sauf que Champs Extras peut parfaitement ajouter des champs sans groupe après. Ou n'importe quel plugin.

Aussi pour aider à styler, comme je le disais tout à l'heure sur IRC, je pense qu'il faudrait corriger une incohérence actuellement : en gros 99% des formulaires dans la nature, core + plugins, ont les vrais fieldsets (pas des radios ensemble quoi), dans un conteneur div.fieldset en plus. Et seulement quelques forms de configs ont des fieldsets directement comme ça qui se baladent sans aucun conteneur dédié. Cela fait qu'on doit à la fois styler ".formulaire_spip .fieldset fieldset" et ".formulaire_spip fieldset" différemment avec des exceptions ajoutées, car ça change les marges !
Je propose pour ce ticket d'en profiter pour uniformiser tous les quelques formulaires qui ont des "vrais" fieldsets toujours dans un conteneur. Ainsi on stylera toujours une seule chose, et en plus ça sera encore plus simple de styler seulement ces vrais fieldsets par rapport à ceux des radios/checks.

#24 Updated by tcharlss 🐽 21 days ago

Je propose pour ce ticket d'en profiter pour uniformiser tous les quelques formulaires qui ont des "vrais" fieldsets toujours dans un conteneur.

Ah oui, je suis en plein confronté à ce problème pour gérer les marges et tout ça, si on peut uniformiser super.
Dans la charte c'est sans conteneur .fieldset, alors pour comprendre quel est le cas normal et quelles sont les exceptions, c'est sport.
Donc la vraie règle c'est avec conteneur .fieldset, c'est bien ça ? (Pour que j'adapte la charte au passage).

#25 Updated by marcimat 🌻 21 days ago

Je me demande si on pourrait pas proposer un petit nettoyage effectivement et clarifier tout ça.

On a vu le premier div du <form...><div> ne sert plus (c'était pour la validation xhtml stricte)

Avoir div.fielset + fieldset je ne sais pas pourquoi ça avait été fait ? par contrainte pour le plugin Saisies ?
Je verrais bien fieldset tout court (et ignorer la classe .fieldset des existants comme ça ça ne gêne pas les formulaires existants) ou fieldset.editer-fieldset pour rappeler .editer-groupe

Possiblement ce double div + fieldset pouvait venir d'une époque où on ne pouvait pas styler avec :before et :after ? Faudrait retrouver

#26 Updated by marcimat 🌻 21 days ago

Un peu d'archéologie :

La classe ".editer_type_fieldset" est Introduite là, là https://git-mirror.spip.net/spip/spip/-/commit/31ff8a5d58c4 avec un message de commit peu explicite (il y a les changements de <legend> en h3.legend aussi) donc ça doit concerner les facilités de stylages.

Sur ce commit, "editer_type_fieldset" est conservé (le seul, pour compat ie6 et 7), alors que tous les autres ".editer_type_input" "editer_type_select" et autres ont été supprimés.
https://git-mirror.spip.net/spip/spip/-/commit/f60b051a98

Remplacé ensuite de .editer.editer_type_fieldset+ fieldset en .editer.fieldet + fieldset qui sert a priori a enlever le padding du .editer
https://git-mirror.spip.net/spip/spip/-/commit/e78936ec8

#27 Updated by RastaPopoulos ♥ 21 days ago

AH mais je sais marcimat, tout simplement ! C'est parce qu'il n'y a encore pas si longtemps, tous les formulaires étaient en liste ul/li ! Et donc chaque "ligne" devait obligatoirement être dans un li avant d'avoir son vrai contenu dedans, interdit d'avoir autre chose. Ensuite on a transformé tous les li en div, en laissant le même contenu dedans.

Donc à voir si on l'enlève ou si on décide quand même de garder un conteneur uniforme, càd qu'au même niveau de blocs frères, ça doit toujours des conteneurs neutres (div avec une classe), et ensuite dedans les vrais éléments de formulaires. Mais techniquement on peut décider de l'enlever.

#28 Updated by marcimat 🌻 21 days ago

Oui, j'avais pas pensé au coup des ul / li d'avant.

Le constat que je vois c'est que
- soit tu as la structure :

form 
  .editer-groupe
    .editer.fieldset
       fieldet
         .editer-groupe
           .editer ...

- soit :

form 
  fieldet
    .editer-groupe
       .editer ...

La différence vient de "est-ce que j'ai d'autres champs à la racine que des fieldset" : si oui je dois mettre un .editer-groupe, sinon, le .editer-groupe + .editer.fieldset racine ne sert à rien et on peut enchainer des fieldset directement...

#29 Updated by tcharlss 🐽 21 days ago

Récapitulons tout ce qui existe :

1. fieldset : un fieldset
2. div.fieldset + fieldset : un fieldset mais dans un conteneur
3. fieldset.editer : conteneur pour les .choix, donc visuellement c'est un .editer avec le padding gauche
4. div.editer.fieldset + fieldset = un conteneur de fieldset mais qui a aussi la classe .editer, alors qu'il faut l'afficher comme un fieldset (vu sur un form de la dist)

Je suis plutôt de l'avis de marcimat : virer les conteneurs div.fieldset, donc ne garder que 1. et 3.

(edit : répondu avant de voir les 2 messages précédents)

#30 Updated by tcharlss 🐽 21 days ago

Le 2) c'est moins complexoïde je trouve @marcimat
Pour voir en ajoutant des .editer-groupe avant/après, et un fieldset.editer :

form
  .editer-groupe
    .editer
    fieldset.editer (.choix)
  fieldset
    .editer-groupe
       .editer ...
  .editer-groupe
    .editer ...

#31 Updated by tcharlss 🐽 21 days ago

Disgression : au fait, quelle était l'intention derrière le fait de mettre des <h3> à la place de <legend> dans les fieldsets ? Faut que je retourne voir comment c'était stylé avant, moi du coup je les affiche comme des <legend>, mais c'était peut-être pas le but ?

Et une dernière réflexion tardive pour la route : toujours avec le 2ème exemple de marcimat, en ajoutant une classe aux fieldsets je trouve que la structure devient plus naturelle, ne se pose plus la question de savoir s'il faut les encapsuler dans un conteneur ou pas.

form
  .editer-surgroupe (= fieldset)
    .legend
    .editer-groupe
       .editer
       .editer ...
  .editer-groupe
    .editer
    .editer ...

#32 Updated by RastaPopoulos ♥ 21 days ago

mmh ya plus de h3 à la place de legend depuis un bon moment normalement, t'as vu ça dans quels forms ? (c'était l'ancienne méthode avec h3.legend car mieux stylables, mais nawak niveau accessibilité donc retour aux legend partout normalement)

#33 Updated by tcharlss 🐽 21 days ago

#34 Updated by RastaPopoulos ♥ 21 days ago

c'est vraiment n'importe quoi là pour le coup, faudrait corriger :p

#35 Updated by marcimat 🌻 20 days ago

Je découvre les fieldset.editer qui sont des lignes pour les .choix, introduit assez récemment. Donc ça fait une option de plus à gérer.

Dans quelle mesure Tcharles il y a besoin du .editer-groupe dans le fieldset.editer-surgroupe ? Est-ce que ça pourrait servir pour passer les champs .editer dedans en colonne (flexbox horizontal ?) sur certains fieldset ? (Je suppose qu'on en aurait pas besoin pour ça). Et donc que ça simplifierait si on met directement fieldset.editer-groupe

form
  div.editer-groupe
    div.editer
    div.editer
    ...

  fieldset.editer-groupe
    legend
    div.editer
    div.editer

  div.editer-groupe
    div.editer
    fieldset.editer
      .choix 
    fieldset.editer-groupe
       legend
       div.editer
       div.editer
       fieldset.editer-groupe
          legend
          div.editer
          ...

  fieldset.editer-groupe
    legend
    div.editer
    fieldset.editer-groupe
       legend
       div.editer
       ...

Il me semble que dans ce cas on peut toujours différencier
- un form fieldset.editer-goupe (racine) (du moins avec style minimums = div.editer-groupe)
- d'un form .editer-groupe fieldset.editer-groupe (mélangé avec d'autres champs = style plus élaborés avec indentation)

En fait ça me parait assez cohérent de dire "Un fieldset c'est un groupe d'édition" (.editer-groupe) la seule grosse différence est la présence du legend. (et éventuellement de la démarcation / indentation)

#36 Updated by tcharlss 🐽 20 days ago

Dans quelle mesure Tcharles il y a besoin du .editer-groupe dans le fieldset.editer-surgroupe ?

Et bien écoute, maintenant que tu le dis, je ne sais pas :)
La sémantique de la balise fieldset et de la classe .editer-groupe est finalement la même oui, ton exemple semble plus logique.
Des fois même si c'est pas bien, on n'a pas d'autre choix que de rajouter un conteneur pour faciliter ou permettre des choix stylistiques, mais là ça semble pas nécessaire.

Je serais incliné à ajouter une classe complémentaire sur les fieldset.editer-groupe quand même, pour distinguer les « groupes avec légende » des « groupes lambdas ». Dans les CSS on peut certes se reposer sur la balise, mais ça simplifierait et serait un peu plus propre. Une déclinaison de .editer-groupe plus sémantique pour dire que c'est une variante ? Je mets « editer-groupe-xxx » dans l'exemple pour l'instant. Sinon la bonne vieille classe .fieldset.

form
  div.editer-groupe
    div.editer
    div.editer
    ...

  fieldset.editer-groupe.editer-groupe-xxx
    legend
    div.editer
    div.editer

  div.editer-groupe
    div.editer
    fieldset.editer
      .choix 
    fieldset.editer-groupe.editer-groupe-xxx
       legend
       div.editer
       div.editer

#37 Updated by marcimat 🌻 20 days ago

on peut mettre .editer_beatles parce que c'est un groupe de légende.
/me => []

#38 Updated by marcimat 🌻 20 days ago

Bon stop (ou pas) !

Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c'est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

J'ai fait quelques tests en partant du formulaire de préférences des menus (tiens d'ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
Il contient un fieldset + .editer-groupe.deux_colonnes (columns: 2)

Ce que j'ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)

fieldset.editer-groupe
    legend
    div.editer
    div.editer
    ...

1) Si on applique un columns: 2 sur ce fieldset,
- Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
- Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
- Tous : le legend est conservé comme tel
- le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
J'utilise .editer-section ensuite (mais peut importe)

A) fieldset.editer-section > div.editer-groupe

(le plus proche de l'actuel je pense)

  div.editer-groupe
      div.editer
      ...
  fieldset.editer-section
    legend
    div.editer-groupe
        div.editer
        ...

B) fieldset.editer-groupe > div.editer-section

L'autre possibilité si ça facilite vraiment le css, c'est d'inverser les classes (avec l'ennui principal de du coup devoir reprendre l'existant)

  div.editer-groupe
      div.editer
      ...
  fieldset.editer-groupe
    legend
    div.editer-fieldset
        div.editer
        ...

B) fieldset.editer-groupe.editer-section > div.editer-groupe

Ou du doubler d'une autre classe

  div.editer-groupe
      div.editer
      ...
  fieldset.editer-groupe.editer-section
    legend
    div.editer-groupe
        div.editer
        ...

Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;

#39 Updated by RastaPopoulos ♥ 20 days ago

À partir du moment où ya toujours un conteneur sous la legend, pour moi un fieldset n'est pas du tout comme un groupe, mais bien comme "une ligne de champ" (qui à l'intérieur peut avoir des choses multiples plus ou moins complexe, mais relativement à ses lignes sœurs, c'est au même niveau de les autres champs qui précèdent et suivent.

Donc je vois plus ça comme ça

form
  div.editer-groupe
    div.editer
    div.editer
    fieldset.fieldset (groupe racine)
      legend
      div.editer-groupe
        div.editer
        fieldset.fieldset (groupe imbriqué)
          legend
          div.editer-groupe
            div.editer
            fieldset.editer (faux groupe, champs radios)
              div.choix
    div.editer (autres champs après le groupe)
    div.editer

Les vrais groupes (que j'oppose aux groupes de choix radios etc), ne sont pas des "editer-groupe" puisqu'ils en ont un intérieur exprès. Ils ne doivent pas être aux mêmes niveaux que les autres div.editer-groupe. Ils sont toujours au même niveau que les champs normaux div.editer. Ces vrais groupes sont comme des champs aussi, des gros champs complexes, comme des gros div.editer, bien au même niveau.

Pour les styles, on style :
- ".fieldset" : les styles communs aux vrais groupes + ce qui est propre aux groupes racines
- ".fieldset .fieldset" : les styles propres aux vrais groupes imbriqués
- "fieldset.editer" : les faux groupes de choix

(ça peut être autre chose que .fieldset bien sûr mais l'idée quoi)

#40 Updated by marcimat 🌻 20 days ago

Ce que tu suggères Rasta, c'est que même s'il n'y a que des fieldset à la racine du formulaire, de les mettre dans un div.editer-groupe ? Qu'ils soient donc au même niveau que les div.editer et toujours dans un conteneur.

J'ai vaguement l'impression que c'est la seule différence par rapport à ce qu'on a à certains endroits dans certains formulaires.

#41 Updated by RastaPopoulos ♥ 20 days ago

Oui marcimat, pour moi la règle c'est qu'un fieldset c'est comme un autre champ en plus gros, donc toujours à utiliser au même niveau que les div.editer. Si on commence à avoir des exceptions dans la structure (parfois à tel endroit parfois pas) après pour les marges c'est l'horreur à styler, faire des exceptions etc. Je pense qu'il faut garder la règle un fieldset == un div.editer en plus gros.

Et c'est dans le fieldset qu'il y a un sous div.editer-groupe qui refait une "liste de lignes de champs", pouvant donc de nouveau contenir des div.editer et/ou des fieldset.fieldset (vrai groupe) et/ou fieldset.editer (groupe de choix comme un champ aussi)

La seule simplification c'est que les vrais fieldsets n'auraient plus à être eux-mêmes dans un div.fieldset, mais directement au même niveau que les champs frères div.editer et fieldset.editer.

#42 Updated by tcharlss 🐽 19 days ago

Je pense qu'il faut garder la règle un fieldset == un div.editer en plus gros.

Oui, ça se tient aussi. Je crois avoir vu cette structure utilisée sur un form de la dist d'ailleurs.
Pour les fieldsets on pourrait employer un nom qui rappelle que ça fait partie d'un .editer-groupe non ? Genre .editer-fieldset par exemple, au lieu de .fieldset tout court ?

Je signale pour pas oublier et ne pas exclure cette possibilité que certains formulaires ont besoin de plusieurs .editer-groupe à la racine, avec des choses entre. Par exemple pour le multi il y a des .boutons au milieu du formulaire :

form
  .editer-groupe
  .boutons
  .editer-groupe
  .boutons

On peut imaginer aussi un formulaire qui aurait besoin en cours de route d'un groupe de saisies en 2 colonnes, donc de plusieurs .editer-groupe consécutifs :

form
  .editer-groupe
  .editer-groupe.deux_colonnes
  .editer-groupe

Et aussi entre le legend et le .editer-groupe d'un fieldset, la charte permet d'insérer des explications (et autres ?).

#43 Updated by marcimat 🌻 19 days ago

ça me va très bien ".editer-fieldset".

Concernant les "exceptions" ou trucs à la marge que tu signales. Ça peut se régler sur chaque formulaire : je pense pas que ça soit une bonne idée de gérer le «multi boutons». Tant mieux si ça le fait mais je veux dire : pas la peine de promouvoir cette utilisation.

Sur les multiples .editer-groupe : oui je pense que c'est pas idiot de gérer la possibilité d'en avoir plusieurs à la racine...

#44 Updated by Maïeul Rouquette 19 days ago

Hum

Genre .editer-fieldset par exemple, au lieu de .fieldset tout court ?

le risque c'est la confusion possible avec fieldset.editer (les fieldsets pour les radios etc)

#45 Updated by nicod _ 19 days ago

Pour info j'ai travaillé sur le regroupement des radios et checkbox dans des fieldsets :
https://git.spip.net/spip-contrib-extensions/saisies/pulls/105

Pour l'instant, ça ne fait que mettre un fieldset à la place du div comme contenur, et un legend à la place de label, ça génère donc un simple fieldset.editer :

<fieldset class="editer editer_radio_2 saisie_radio editer_odd" data-id="@607d93aee2988">
    <legend class="label">Boutons radios</legend>
    <div class="choix choix_choix1">
        <input type="radio" name="radio_2" class="radio" id="champ_radio_2_1" value="choix1">
        <label for="champ_radio_2_1">Un</label>
    </div>
    <div class="choix choix_choix2">
        <input type="radio" name="radio_2" class="radio" id="champ_radio_2_2" value="choix2">
        <label for="champ_radio_2_2">Deux</label>
    </div>
    <div class="choix choix_choix3">
        <input type="radio" name="radio_2" class="radio" id="champ_radio_2_3" value="choix3">
        <label for="champ_radio_2_3">Trois</label>
    </div>
</fieldset>

PS : note au passage : les classes editer_odd et editer_even sont vraiment nécessaires ?

Also available in: Atom PDF