Force affichage message si cible ancre #5949
Conversation
AmauryCarrade
added
C-Front
|
Ah oui j'avais oublié ça… Après quand on clique sur le lien de base il reste présent pareil une fois le message affiché. Ça change au final pas tant que ça le comportement, à part que ça ne cache pas le message vu que l'ancre reste active (ce qui pourrait se corriger dans le JS du lien/bouton en question) |
|
Effectivement. C'est d'ailleurs une question que je m'étais posée pour l'implémentation de #5039, où l'emphase serait également persistante tant que l'ancre n'est pas retirée. On peut remarquer que GitHub gère ça en retirant l'ancre de l'URL quand on clique hors du message ciblé. On pourrait peut-être s'inspirer d'une solution comme cela. |
|
On peut. Faudra que je regarde le JS du lien/bouton du coup, et je mettrai quelques lignes pour retirer l'ancre de l'URL sans casser le scroll. |
|
Stocker le défilement du |
|
Oui c'est ce que je pensais faire, mais il y a une API changer l'ancre/URL de façon transparente directement de mémoire, ce serait plus simple/propre. |
|
Si ça existe, alors oui, partons là dessus. 👍 |
|
Bon ça a l'air jouable, mais C'est un comportement connu des navigateurs : https://bugs.webkit.org/show_bug.cgi?id=83490 Y'aurait un fix, mais je trouve ça lourd/sale pour pas grand chose : whatwg/html#639 (comment) |
|
À voir, parce qu'on va avoir besoin de quelque chose comme ça quand les messages ciblés auront une aura, de toute façon. Donc si c'est pas maintenant (dans une fonction à part réutilisable idéalement)… ce sera plus tard. (Je ne pensais pas que tu parlais de l'API d'historique initialement, j'imaginais qu'il y avait une API quelconque pour retirer l'ancre sans déplacer la vue) |
|
@AmauryCarrade J'ai poussé ma version, à tester quand même on sait jamais, c'est peut-être ma version de Firefox qui délire. |
|
Il faudra reprendre ici une fois #5960 fusionnée. |
|
Est-ce que c'est toujours d'actualité ? Y'a des conflits de merge mais ça devrait pas être catastrophique |
|
On fait quoi ici ? Il suffit de rebase en résolvant les conflits ? |
|
Il faudrait, mais j'ai l'impression que ça a pas mal dévié entre les deux branches… faudrait reprendre ça en local pour tester |
|
@viki53 tu as toujours envie de terminer cette PR (si ça te rappelle encore quelque chose :D) ? C'est une fonctionnalité pratique, ça serait dommage que nous ne fassions pas aboutir le développement si près du but ! |
|
Alors oui… faut "juste" que je me motive à rebase pour m'assurer que rien ne soit cassé :D |
viki53
force-pushed
the
afficher-message-cache-ancre
branch
2 times, most recently
from
a4912ac
to
12be18b
Compare
|
J'ai rebase en local, faut que je relance le projet pour tester que c'est toujours fonctionnel mais "en théorie" c'est bon |
viki53
force-pushed
the
afficher-message-cache-ancre
branch
from
12be18b
to
670559f
Compare
|
C'est confirmé en local, c'est bon 👍 Le seul "problème" c'est le bloc "Un message a été masqué" qui reste apparent mais c'est plus compliqué à faire avec juste du CSS (peut-être voir si un sélecteur du style |
Corrige le troisième point de ce sujet.
Actuellement si un message caché est la cible d'un lien avec une ancre (par exemple lorsqu'on suit une notification), l'ancre ne mène à rien et le message est caché.
Cette PR corrige cela en forçant l'affichage du message en question si l'ancre de la page le cible directement.
Contrôle qualité
make build-front;msg-are-hiddenqui va bien) ;À noter que j'ai dû déplacer l'
idqui sert pour l'ancre, cela peut risque de casser autre chose, par exemple si du JS l'utilise (ce qui a priori ne devrait pas être le cas).