Lorsque j’inclus un lien vers une section d’une page, ce lien, une fois cliqué, ne modifie pas l’historique du navigateur. Le fait de revenir en arrière permet de quitter la page plutôt que de retourner à la position de la page où le lien est défini.
Édition : Eh bien, sur ce Discourse, je ne peux pas créer un élément avec un ID, donc je ne peux pas le démontrer ici. Le code source ci-dessous est ce que j’aimerais faire – mais ceci n’est qu’une illustration et n’affecte pas le fond de mon problème :
<div id="link-target"></div>
*Cette section est liée depuis le haut. Rien à voir ici.*
C’est en quelque sorte attendu. Si vous cliquez sur un lien vers un autre message dans le même sujet, il n’est pas non plus ajouté à la pile d’historique, et il s’agit d’un lien complet sans fragments, nous n’ajoutons donc jamais les liens dans le sujet à l’historique.
Voici un exemple de page sans JavaScript. Sur Chromium, cliquer sur ce lien vous emmène en bas de la page. Cliquer sur « retour » vous ramène à l’endroit où vous avez cliqué. C’est le comportement attendu que l’on observe sur tous les autres sites web qui ne consomment pas cet historique.
Je suppose que Discourse gère les fragments d’URL en JavaScript en faisant défiler jusqu’à l’emplacement, et que l’historique doit donc être explicitement poussé.
@codinghorror exprime une opinion forte et définitive à ce sujet ici. Il est surprenant de voir une opinion aussi tranchée sur un changement du comportement standard des navigateurs web. Pour être juste, je n’ai pas encore utilisé Discourse pour une navigation intensive dans les sujets, et je ne peux donc pas apprécier l’évidence de son argument.
J’utilise Discourse en partie pour ma documentation, et ce comportement est extrêmement perturbant, au point que j’ai peur de cliquer sur un lien et de perdre ma place sur une page.
Si vous êtes tenté de cliquer sur l’un des liens de la table des matières, puis de revenir à votre point de départ via l’historique du navigateur, vous ne pouvez pas.
Pourquoi fournir une table des matières dès le départ ?
Pour les sites qui souhaitent prendre en charge la navigation standard des navigateurs, avez-vous des suggestions ?
Je me penche sur le monkeypatching du comportement de défilement vers l’élément, que je soupçonne être à l’origine de ce problème, mais je pars de zéro concernant la base de code J’y arriverai éventuellement, mais si quelqu’un a des pistes, je vous remercie pour votre aide !
Selon le contexte dans lequel vous utiliserez vos ancres, ce plugin table des matières pourrait être utile (et à mon avis, il conviendrait bien sur les pages CGU et FAQ) ?
Exemple ici.
Je ne réalisais pas que cela me dérangeait jusqu’à ce que tu me le signales. J’ai souvent essayé de revenir là où j’avais cliqué sur un lien dans Discourse, mais j’atterrissais sur une page précédente. Très irritant. J’ai toujours attribué cela à une combinaison de l’application iOS, que j’utilise pour presque tout ce qui concerne Discourse, et à une erreur de ma part.
Ce composant de sommaire est vraiment bien réalisé et nous l’utilisons sur chaque page de documentation – nous sommes très reconnaissants pour le travail accompli !
Le problème de navigation subsiste cependant. Cliquer sur un lien dans le sommaire ne modifie pas l’historique du navigateur et, par conséquent, revenir en arrière permet de quitter la page.
C’est tout à fait exact. Ce serait bien de corriger cela, @Johani, mais j’ai l’impression que c’est très compliqué. Peut-être devrions-nous simplement utiliser pushState lorsque vous cliquez sur un lien de la table des matières.
J’ai mis en place une solution de contournement (qui pourrait être considérée comme une approche appropriée pour personnaliser un site, selon la vision de Discourse en matière de navigation par lien) via un composant de thème. Cela suit le modèle utilisé par DiscoTOC, où un marqueur est ajouté à un message pour déclencher le comportement. Le code concerné se trouve ici.
Je pense que modifier DiscoTOC pour utiliser des fragments d’URL et l’historique du navigateur est une bonne idée. Cela nécessite de changer l’approche de navigation du composant, ce qui n’est pas une modification mineure. DiscoTOC utilise des attributs de données pour transmettre les cibles plutôt que les attributs href des liens. Aucune tentative n’est faite pour refléter la nouvelle localisation de la page dans l’URL du navigateur (window.location).
Je pense que le modèle que j’utilise ci-dessus pourrait fonctionner pour DiscoTOC, mais cela aurait des implications plus larges pour ce composant, compte tenu de son approche actuelle.
Je pense à pushState dans ce cas. L’objectif est de permettre le retour à la position précédente, ce qui nécessite un ajout à l’historique car l’événement est empêché.
