fix: Affiner la compatibilité entre les fieldsets
en onglets et select2
.
#240
Closed
maieul
wants to merge 1 commits from select2_onglets_encore
into master
Loading…
Reference in New Issue
There is no content yet.
Delete Branch 'select2_onglets_encore'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Etant donné
select2
est excuté après la mise en onglet.et met la largeur à 0 pour les onglets initialement masqués
Il faut recalculer les champs qui sont en
.select2
à chaque fois quel'on bascule les onglets.
Voici un exemple Formidable pour reproduire.
@tcharlss je reste convaincu qu'il vaut mieux reconstruire les select2, le tout est de le faire au bon moment.
une ptite relance
Pour mémoire si tu sais, pourquoi est-ce que les onglets masqués ont une largeur de 0 ? C'est obligatoire ça ? Si c'était masqué autrement (juste display none, ou height 0 ou je sais pas quelle autre méthode), est-ce que yorait pas besoin de bidouiller bourrin select2 ?
Pour mémoire en ayant regardé, le module js sur lequel s'appuie les onglets met un
display:none
et du coup select2 considère que c'est également à unwidth:0
Reconstruire les selects2 à l'init des onglets puis à chaque changement me semble un peu violent quand même, mais j'ai pas encore de solution alternative à proposer.
Il y a des pistes à explorer pour régler le problème directement dans le plugin select2 amha. Genre rajouter
max-width:100%
en plus dewidth:N
, est-ce que ça pourrait pas régler le problème dans tous les cas (même hors saisies), et plus simplement ?c'est effectivement la piste alternative, mais ca implique d'imposer une largeur à select2. Ca se discute en terme de violence.
Ah my bad, là c'est pour les onglets masqués qu ont pas de largeur du tout, donc le max-width aura aucun effet.
Ah non, le width de base c'est toujours select2 qui le pose, on change pas.
On ajoute juste une règle pour éviter que ça dépasse.
Mais du coup ça c'est pour le problème de dépassement évoqué dans l'autre ticket.
En fait faudrait réussir à ce que les onglets soient initialisé après select2 sans doute. Peut être en jouant sur les dépendances des plugins.
5e0af8651a
to631aceba20
12 months ago631aceba20
tof790545418
12 months agof790545418
todd888c31d5
12 months agoBon, nouvelle solution, plus simple et sans destruction/recreation de select2 : on impose (via CSS) une largeur de 100% aux select2 qui sont dans des onglets.
Oui ça me semble déjà un meilleur compromis pour cette PR.
Pour voir ce qui pourrait être réglé en amont, j'ai continuer à regarder de mon côté et je pense qu'il y aurait un fix tout simple à apporter soit directement à la lib, soit au plugin.
Au lieu de mettre un
width: Npx
, la lib devrait mettre au choix une de ces 2 règles :Ça fonctionne très bien, et l'avantage du
clamp()
c'est qu'on se retrouve pas avec une largeur de 0 si la lib n'arrive pas à choper la largeur initiale du select (s'il est caché au chargement). Mais le support est pas aussi bon quemin()
: 94% vs 99%.Je vais proposer ça en PR dans la lib, mais en attendant que ça soit accepté et intégré, peut-être que le plugin Select2 pourrait le faire manuellement à l'init.
Et du coup, en complément ça devrait aussi être lui de mettre dans les styles du privé que les select2 ont une largeur de 100% pour reproduire l'apparence des select du privé.
Du coup on fait quoi sur cette PR ?
Ça dépend si t'es pressé :)
Normalement il y a moyen de régler cela directement dans le plugin Select2, mais il faudrait attendre une PR là-bas donc : spip-contrib-extensions/select2#4
Mais si ça peut pas attendre, bah intègre cette PR-ci. Mais ça fera des aller-retours s'il faut revert ça dans Saisies une fois le truc réglé directement dans Select2.
Mouais, de toute facon il y a déjà des bouts de code à reverter si jamais select2 sera corrigé. Donc allons y pour mettre cela dans saisies maintenant, et je met un commentaire dans le code.