Re: spip 4 - retour d'usage

tcharlss <[email protected]> Wed, 5 May 2021 22:53:50 +0200
Newsgroups gmane.comp.web.spip.devel
Message-ID <[email protected]>
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.

Le 05/05/2021 à 22:30, Cerdic a écrit :
> 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 
> <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 
> <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...
>
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip