Yop,
Ça donne vraiment la gerbe d'éditer un formulaire formidable un peu long, ça remonte, ça redescend, on sait plus où on est, les yeux font le yoyo en haut en bas à chercher l'information sur laquelle on a cliqué ou qu'on a validé...
Mais pourquoi ça remonte *toujours* _tout en haut_, et que ça redescend aussitôt bordel ?
Je suis en train de me choper une migraine, c'est vraiment horrible cette UI.
--
nicod_
Le 02/11/2017 à 18:25, nicod_ a écrit :
Mais pourquoi ça remonte *toujours* _tout en haut_, et que ça redescend
aussitôt bordel ?
Chez moi ça amène au bon endroit quand on demande à configurer un champ
(que ça ouvre son form de config). Mais ça remonte toujours en haut
quand on valide la configuration d'un champ.
Le deuxième point étant qu'en CVT il est impossible de passe autre chose
à l'environnement après la fin de traiter() que "message_ok",
"message_erreur", "editable" et "redirect". Du coup impossible de passe
une autre variable pour "positionner". Ce qui est fait avec verifier()
parce que là c'est possible, enfin on utilise le tableau d'erreurs pour
mettre un "erreurs/positionner". Après ça utilise la fonctionnalité
noyau de positionnement dans les CVT, qui est de générer une ancre
<a name="ajax_ancre" href="[(#ENV{erreurs/positionner})]"></a>
en tout début de formulaire, que CVT sait utiliser pour lancer le
déplacement à l'endroit demandé.
Mais bon cette ancre n'est pour l'instant pas générée après un traiter()
(config d'un champ qui a bien marché), seulement après un verifier().
--
RastaPopoulos
--
Cédric
RastaPopoulos a écrit :
Le 02/11/2017 à 18:25, nicod_ a écrit :
Mais pourquoi ça remonte *toujours* _tout en haut_, et que ça redescend
aussitôt bordel ?Chez moi ça amène au bon endroit quand on demande à configurer un champ
(que ça ouvre son form de config). Mais ça remonte toujours en haut
quand on valide la configuration d'un champ.Le deuxième point étant qu'en CVT il est impossible de passe autre chose
à l'environnement après la fin de traiter() que "message_ok",
"message_erreur", "editable" et "redirect". Du coup impossible de passe
une autre variable pour "positionner". Ce qui est fait avec verifier()
parce que là c'est possible, enfin on utilise le tableau d'erreurs pour
mettre un "erreurs/positionner". Après ça utilise la fonctionnalité
noyau de positionnement dans les CVT, qui est de générer une ancre
<a name="ajax_ancre" href="[(#ENV{erreurs/positionner})]"></a>
en tout début de formulaire, que CVT sait utiliser pour lancer le
déplacement à l'endroit demandé.Mais bon cette ancre n'est pour l'instant pas générée après un traiter()
(config d'un champ qui a bien marché), seulement après un verifier().
Le 03/11/2017 à 10:15, Cédric Morin a écrit :
C'est rajouté :
Par contre ce n'est pas générique, comme expliqué dans le log, ça ne
marche que pour les gens qui valident par le bouton. Pas pour celleux
qui valident avec la touche Entrée. Alors que le truc d'utiliser l'ancre
ajax placée au début du bloc ajax, ça marche pour toutes les validations
puisque c'est après-coup que ça position où on le demande, peu importe
comment ça a été validé.
--
RastaPopoulos
Que crois tu qu'il se passe quand tu clic sur entrée ?
Surprise ! Ça valide automatiquement le premier bouton du formulaire
(c'est pourquoi on est parfois obligé de mettre un bouton caché en début de formulaire si le premier bouton n'est pas un bouton de validation)
Ajoute donc la class no-scroll sur ce bouton et ça marchera bien aussi.
--
Cédrique Généric
RastaPopoulos a écrit :
Le 03/11/2017 à 10:15, Cédric Morin a écrit :
C'est rajouté :
Connexion · GitLabPar contre ce n'est pas générique, comme expliqué dans le log, ça ne
marche que pour les gens qui valident par le bouton. Pas pour celleux
qui valident avec la touche Entrée. Alors que le truc d'utiliser l'ancre
ajax placée au début du bloc ajax, ça marche pour toutes les validations
puisque c'est après-coup que ça position où on le demande, peu importe
comment ça a été validé.
Hop
https://zone.spip.org/trac/spip-zone/changeset/107297
merci pour ta compassion
--
RastaPopoulos
Au passage je vois que ces boutons cachés sont en display:none et de mémoire ça ne fonctionne pas parfaitement dans tous les navigateurs (ou toutes les version) et il faut normalement préférer utiliser une classe over ou offscreen qui masque en le mettant en position absolute hors de l'écran
--
Cédric
RastaPopoulos a écrit :
Hop
Connexion · GitLab
merci pour ta compassion
Le 03/11/2017 à 12:17, Cédric Morin a écrit :
Au passage je vois que ces boutons cachés sont en display:none et de mémoire ça ne fonctionne pas parfaitement dans tous les navigateurs (ou toutes les version) et il faut normalement préférer utiliser une classe over ou offscreen qui masque en le mettant en position absolute hors de l'écran
Un article à jour sur le sujet : Cache-cache CSS — La vie en #ffoodd
Avec une note spécifique pour les boutons et autres éléments masqués qui doivent quand même recevoir le focus.
Et sinon, ma migraine vous dit bien merci 
--
nicod_
Le 03/11/2017 à 12:17, Cédric Morin a écrit :
Au passage je vois que ces boutons cachés sont en display:none et de
mémoire ça ne fonctionne pas parfaitement dans tous les navigateurs (ou
toutes les version) et il faut normalement préférer utiliser une classe
over ou offscreen qui masque en le mettant en position absolute hors de
l'écran
Ok j'ai mis la classe "invisible" en virant le none.
La technique indiquée par nico a l'air évidemment mieux et plus
accessible mais ce n'est pas à tel plugin précis de l'ajouter, mais au
thème de l'admin de le fournir, donc ce serait à corriger là.
--
RastaPopoulos