J’ai un souci d’affichage dans le privé
http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png
J’ai un doute sur ces 2 règles css
.formulaire_spip .choix > :nth-child(2n+1) {
margin-right: calc(var(–spip-form-padding-input-x) * 3/4);
}
et
.formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip span.choix + span.choix {
margin-left: var(–spip-form-spacing-x);
}
On peut voir le squelette du formulaire et une capture de ce que ça donnait avant ?
Et est-ce qu’il y a des CSS personnalisées ?
Ces règles s’appuient sur les cas connus et documentés de la charte des formulaires.
Hello,
Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child dans .choix 
Je suppose que tu as voulu traiter le cas où on a juste un .choix et dedans une succession de input+label, mais c’est normalement pas un cas à traiter et ça me semble invasif et pas très robuste...
Quid du ou des input hidden dans un .choix qui viennent perturber le compteur comme ici
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 ?
Je vois que c’est parce que vous avec voulu permettre le cas de « On met tous les choix dans un seul .choix » comme ici
https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101
mais ça me parait pas pertinent ni robuste
Ce conteneur .choix a été introduit pour permettre justement d’identifier une unité semantique de choix, et qu’on puisse y mettre si besoin un markup un peu souple comme une explication, une image, ou que sais-je qui serais nécessaire dans des cas particuliers.
En présumant que le .choix est rempli de succession de label+input et uniquement ça on bloque à nouveau toute souplesse de balisage...
Il faut rester sur la convention .choix = 1 choix, en général composé d’un input+label, mais pas forcément uniquement.
Alternativement, si besoin pour certains cas de mise en forme, il faut introduire un .groupe-choix l’encadrant ?
Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...
Ce que ça donne sur spip 3.2
http://escal.ac-lyon.fr/spip4test/squelettes/Selection2.png
Le code est là
j’ai juste remplacé les
<img src="#CHEMIN{images/XXX.gif}"
par des
<img src="#CHEMIN_IMAGE{XXX.png}
JC
Ah mais c’est pas moi qui ai stylé ainsi, c’est spip !
Mais ok pour la suite, je vais essayé de coder plus proprement
JC
Oui pour les .choix c'était un peu compliqué d'inférer ce qui était permis ou pas, en se basant uniquement sur les exemples de la charte et les utilisations dans la dist, ça semblait n'être que des successions d'inputs + labels (ou l'inverse).
Et donc la règle c'est pour mettre une marge entre les "paires".
Mais si dedans il peut y avoir n'importe quoi, en effet c'est trop restrictif.
Par contre ça veut dire que pour ces cas simples, on n'a aucun moyen de mettre ces marges.
En tout ce qui est permis ou pas dans ces .choix est clairement à documenter dans la charte.
De ce que j'ai compris de l'explication justement ya aucune règle pour l'intérieur des .choix, à part cette seule règle : c'est un seul choix dedans. Mais ensuite on peut mettre n'importe quoi, input, explication, hidden, image que sais-je
En effet ça marche mieux avec un seul input par .choix
Merci !
JC
Oui mais le fait qu'on puisse mettre ce quon veut dedans, c'est une règle en soi. C'est pas pour jouer sur les mots, figurez-vous qu'après il y a des gens qui doivent styler tout ça et savoir à quoi s'attendre 
Donc quelque chose à indiquer clairement dans la charte au niveau des exemples de .choix.
Ensuite le fait qu'il puisse n'y avoir qu'un seul choix dedans, je sais pas exactement ce que ça veut dire.
Par exemple pour les trucs en oui/non t'as 2 inputs dedans (la règle trop restrictive c'était pour ce cas d'ailleurs).
Dans l'exemple d'Escal donné par JC Villeneuve, t'as un seul .choix avec pleins d'inputs dedans, avec des sortes de "groupes" séparés par des <br> : https://git.spip.net/spip-contrib-squelettes/escal/src/branch/master/formulaires/configurer_escal_layout.html#L44
Ça rentre dans la définition ? Charte, pas charte ?
Pour moi non, on appelle un choix un choix 
Après entre les .choix on peut mettre des sortes d'intertitres ou des explications pourquoi pas mais pas 50 radios dans un même choix
Bon sachant que là en plus dans le lien d'escal je sais pas si t'as vu mais tout est DANS un div.explication en plus ! Là ça m'a l'air vraiment du grand n'importe quoi par rapport à la charte des forms
Ya même des .choix dans le .choix qui entoure tout…
.editer (encore en ul li en plus alors que ça fait des années que c'est plus des li)
.explication
texte intertitre à l'extérieur du .choix
span.choix
input label moult fois
texte intertitre à l'intérieur
input label moult
texte intertitre
.choix etc
Bref c'est grave WTF là
Là ça devrait être des fieldsets contenant des radios : c'est la norme consacrée pour être accessibles pour les radios désormais.
Et après des .editer n'ayant rien à voir pour les input text de largeur etc, qui n'ont aucun rapport avec les .choix radio.
Hello
Merci pour ces explications, je vais essayer de corriger mon code.
Où peut-on trouver cette fameuse charte des forms dans spip ?
JC
Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip
Quand tu l'installes tu as alors accès à des pages de charte de l'admin.
Mais sinon sur le site spip.net il y a une page sur la normalisation des formulaires. Cependant elle n'est pas très à jour…
En résumé :
* Je vais retirer la règle trop stricte. On se contente de l'habillage extérieur (la bordure) sans présumer de ce qu'il y a dedans
* Les .choix des forms de config en oui/non vont être à nouveau collés, pour ces cas-là peut-être faudrait-il en effet introduire un .groupe-choix ou autre (uniquement pour mettre une marge entre 2 paires inputs+label successives)
* Escal prend d'énormes libertés avec la charte
Ah cool, en effet ça va bien m'aider ce plugin dev !
JC
Oui j'ai codé ça sans connaitre la charte.
Je vais recoder tout ça ... y'a du taf !
JC
Je comprends pas l’argument sur les choix oui/non collé : il y a pas de cas officiels et supportés avec un radio oui et un radio non dans un même .choix
Cf la charte 3.2
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L113
le choix « oui » est dans un .choix, le choix « non » est dans un autre .choix,
Et ici c’est une case à cocher « Oui » dans un .choix avec un hidden « non » pour avoir la valeur non si on coche pas
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L130
il y a donc un seul choix dans le .choix et c’est la seule chose à styler
Les gens qui mettent éventuellement pleins de trucs dans un .choix, y compris plusieurs choix (radio, case), doivent alors gérer d’ajouter du css pour gérer leurs marge ou leurs alignement ou que sais-je
Sur la mediabox, par exemple j’ai rusé en faisant un .choix pour regrouper et dedans plusieurs sous .choix sur lesquels j’enleve la bordure
https://git.spip.net/spip/mediabox/src/branch/master/inc/mediabox.php#L84
La démarche c’est pas que les css par défaut des formulaires doivent styler tous les cas inimaginables, mais bien uniquement les cas de la charte et ensuite les cas particuliers sont stylés comme des cas particuliers (formulaire par formulaire)
Oui mais le cas oui/non dans un même choix… c'est un cas du core !
Du coup je suppute que tcharlss pensait bien faire en se disant : si c'est utilisé par le core, c'est que ça doit être prévu dans les styles.
Mais on peut bien sûr parfaitement décider que c'est le core qui faisait n'importe quoi et prenait des libertés, et donc : corriger le core.
C'est ma préférence aussi, ce qui évite d'ajouter un concept rare en plus de groupe de choix, on corrige les forms de contenus d'articles, etc qui ont des oui/non dans la même ligne. D'ailleurs tcharlss disait que ça serait possiblement bien de les corriger pour des cases à cocher, mieux que des oui/non généralement, mais bon faut voir l'implication en terme de chaines.
Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant, utilisant un très moche pour gérer l'espacement
Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme d’accessibilité, et gagnerait à être remplacé par une case à cocher explicite
Mais sinon on peut en effet proposer un markup spécifique, soit un .choix-multiples qui du coup aurait le stylage proposé par Tcharlss, soit des .choix-inline regroupés dans un .groupe-choix ?
Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou quelque chose du genre ? (qui serait un flex row avec wrap auto)
moi j'ai envie de dire : quitte à rompre des choses, simplifions et virons les incohérences du core
Idéalement la case à cocher c'est mieux (même si pas tjr possible), reste à voir quoi faire du côté des chaines de langue.
sinon il y aussi le plugin "saisies" qui permet de juste déclarer le sens semantique de des saisies qu'on veut avoir et laisser le plugin se charger du marrkup