Enforce document scroll position when loading URLs with fragments

[Šime Vidas]

Steps to reproduce issue:

1. Open http://w3c.github.io/aria-in-html/#aria-touch in Chrome
2. The document scroll position will be set somewhere around section 2.10. instead of section 6. which corresponds to the #aria-touch fragment (i.e. that’s where the id="aria-touch" attribute is set).

What Chrome could do:

In the above example (and on many other sites, from my experience), the document’s height changes during page load (e.g. JS mutates the DOM structure, styles are applied dynamically, etc.). I think, these changes are the culprit of this issue. What Chrome could do, is, as long as the user doesn’t scroll manually during page load, enforce the correct scroll position continuously, until the page “stabilizes”.

This is similar to what scroll anchoring does (which is behind flag), and it would be a big UX win for the user, I think. As of right now, URL fragments are unreliable, and an intervention is the only fix I can think of.

[PhistucK]

I am not sure this is an "intervention", but perhaps.

I seem to recall that Chrome actually does what you ask. Perhaps the images are loaded after the "load" event of the window? That would break the heuristics, I guess.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/61b32fb9-2004-4777-b2a6-08912bc89033%40chromium.org.

[Ojan Vafai]

You say this is similar to what scroll anchoring does. In what way is it different?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CABc02_KDAF0%3D5XZco6FKoEnqdeo5KE3wPvLGGeBWwFSCs4Oiiw%40mail.gmail.com.

[Šime Vidas]

I have determined that the issue in my example is caused by a JavaScript library which is loaded with the page and which tries (and fails) to set the scroll position (more info here; it will hopefully be fixed soon). I’m assuming Chrome should not interfere in these scenarios.

[PhistucK]

I believe there is a heuristic where if the page scrolls (at or after a certain point in time), the browser stops trying to scroll.

☆PhistucK