masqués si l'entrée suit un fieldset.
Pour se faire on rend prioritaire le réglage de padding-top sur les
éventuels réglages de l'espace privé de SPIP.
règle d'ajustement CSS sur les fieldset de l'espace privé, qui
introduisait des margins negatifs sur les fieldset, y compris en onglet.
On en profite pour ajouter un peu de marge au dessus de la barre de
défilement sous firefox, pour mieux pouvoir la distinguer du bas des
onglets.
Close#202
- Lorsqu'on masque un onglet avec afficher_si, on se rend sur un autre
onglet
- Lorsqu'on affiche un onglet avec afficher_si, si c'est le seul onglet
visible, alors on s'y rend
- n'appeler les actions de masquage/demasquage que si on n'est pas déjà
masqué/démasqué
- quatre trigger possible :
- afficher_si_visible_pre -> avant de rendre visible
- afficher_si_visible_post -> après avoir rendu visible
- afficher_si_masque_pre -> avant de masquer
- afficher_si_masque_post -> après avoir masqué
depuis un enregistrement en base), décoder les entités html numérique
des planes UTF-8 > 0.
Cela permet que si une personne a saisie un emoji, elle retrouve l'emoji
et non pas l'entité HTML correspondante (qui est _de facto_ stockée en
base MySql, à cause du `utf8_noplanes()`).
On n'applique cela qu'aux entités numériques des planes > 0, ce qui
permet aux gens qui s'amuseraient à utiliser des entités numériques pour
le plane 0 (`Basic Multilingual Plane') de continuer à les voirs.
Evidemment une personne qui aurait insérée volontairement une entité
numérique pour un plane > 0, plutôt que d'avoir l'emoji, le verrait
transformé en emoji... mais ma foi, est-ce un problème ?
que non seulement les saisies pouvaient être décrite de 2 manière
différentes (slash, html), mais que le erreurs pouvaient être de trois
manières différentes aussi (slash, html, tableau PHP imbriqués).
Là on devrait être bon. En tout cas je met un gros message
d'explication.
l'environnement, c'est à dire du formulaire.
On avait donc pour id des fieldset du formulaire formidable n°5
`champ_5`, quelque soit le nom qu'on donnait effectivement au fieldset.
close#194
régenerait les saisies disponibles, et proposait les saisies obsolètes.
Cela venait du fait que saisies_lister_disponibles() était appelé deux
fois de suite (dans `traiter()` PUIS dans `charger()`), en demandant tantôt d'inclure les saisies obsolètes, tantot pas.
Hors la fonction `saisies_lister_disponibles()` utilise un `static` pour
des questions de perf de lecture du YAML. Mais ce static était faussé,
puisque du coup on incluait parfois des saisies obsolètes alors qu'on
demandait des les exclure ou réciproquement. On corrige donc cette
fonctionnalité, en tenant à jour deux tableaux, en static : les saisies
obsolètes et les autres. Et on ne fusionne qu'à la sortie, selon qu'on
demande d'inclure ou pas les obsolètes.
Conséquence : il faut corriger un moment l'appel à
`saisie_lister_disponibles()` dans `verifier()` lorsqu'on veut modifier
une saisie existante mais obsolète.
On en profite aussi pour du coup pour le faire également dans
`traiter()` pour ne pas avoir de surprise. Il n'y a donc que dans
`charger()` que l'on exclut les obsolètes, pour ne pas proposer aux gens
de les insérer.
La vue d'une saisie fieldset contient également des fieldset.
C'est parfaitement valable d'avoir des fieldset hors formulaire, et ca
permet que le stylage par défaut dans les emails soit plus correct.
Maïeul
danielquisbert
Salvatore
Alberto