Repository navigation
doc: weird scrolling/anchor behavior in Chrome and Firefox #40099
Description
Activity
We're using the CSS property
content-visibility(https://web.dev/content-visibility/) on the HTML version of the docs so it doesn't take forever to render pages on Chromium-based browsers. One of the downside of using this property is the scroll bar makes indeed some strange jumps. It was introduced in #37301.I wonder if the kind of solution described here or something similar would solve these problems?
It's very frustrating not being able to properly navigate the documentation a page at a time or by sliding the scroll bar. It seems to me like the browser should keep elements rendered after it's rendered the first time, which should solve the scrolling problem. It seems like the solution I linked to explicitly does this?
Yep that looks promising indeed. Would you be interested in sending a PR? On the mean time (and I know this is not a satisfactory answer to that issue, more a temporary workaround), you may find Firefox more suitable to browse the docs as they haven't implemented
content-visibilityand they also able to render large pages in a reasonable time.It works fine on macOS Chrome
I think this also causes an issue if you try to open any URL with a hash in a new tab. It doesn't scroll to the desired method / property.
Reacted by MalcolmI am working on this rn
I hate to pile on but this issue has made browsing the API docs an exercise in frustration for a while now. The scrollbar jumps all over the place when trying to drag it, as well as the yellow indicators when you do a ctrl+f. I never end up in the correct place when following an anchor link.
I'm surprised there haven't been more reports after all this time, surely it's more than just a handful of us affected? Chrome on Windows here. Firefox seems fine as mentioned.
@mscdex, for reading the current open Issue, for me, the takes are the following:
- The original
content-visibilitywas introduced to reduce the re-paint on resizing of pages or other shenanigans - It also had the benefit of a smaller initial rendering footprint
Then there's the discussion about if it should be removed:
- It would fix anchor link positioning behaviour, which is an important aspect of the experience
- It would allow scrolling behaviour to be respected
There's, of course, the approach of doing some JavaScript spaghetti, as I saw in some random blog post. Still, I'm severely against having arbitrary JavaScript code that tries to "fix" the web (by inherently trying to change how certain behaviours happen).
What I imagine as an "ideal" solution for now:
- Remove the content-visibility API.
- 99th percentile of devices nowadays are efficient enough to render even the longest pages hassle-free. Of course, constant resizes of the page on desktop browsers will increase the CPU heap during the resize by a lot, but that's an OKAY outcome. People will only sometimes resize their pages; that is an edge case, imho.
- Add CSS grids for the two columns.
- This page was probably done before the time of CSS grids.
- It would allow us to remove a few margin-padding hacks
- It would fix the width issue that happens due to content-visibility being removed
- Enforces the maximum width of the second column and respects the page size
Regarding modern technologies:
Modern browsers and rendering engines are already smart enough to offload computing from complex parts.
I did some synthetic loads on the current API website with
content-visibilitydisabled and requested Chrome to profile the page. I tried to do intensive scrolling behaviour to check for bottlenecks. I saw no significant bottlenecks, CPU-heap increase or significant delays/increase on the repainting/re-rendering of the page.Moreover, disabling
content-visibilityshouldn't be a problem. I tried the same behaviour on an iPhone by using remote DevTools to disable those CSS rules. Didn't see any noticeable lag.Of course, some real old phones or hardware would struggle a little. But given that technology is ever-evolving, I doubt someone would consistently open our API docs on a tiny smartphone from 7 years ago...
I feel inclined toward the approach/solution I mentioned above.
- The original
- 99th percentile of devices nowadays are efficient enough to render even the longest pages hassle-free.
I wonder where you get that figure from, in my experience loading the
all.htmlon a Chromium browser was a real struggle for my 2019 MBP, and I’m pretty sure that’s not the lowest spec you’ll find out there. But maybe Google or Microsoft fixed that since I made the measurements reported in #37301 (comment)Well, the percentile is based on Browserslists on which browsers supporting supporting the 95th percentile. (https://browserslist.dev/?q=Y292ZXIgOTUl)
And sorry, I meant the 95th percentile not the 99th.
I can at least on all my devices open it perfectly without any issues. Using Chrome DevTools to mimic hardware constrained situations it also seems to work fine.
Of course to a certain degree I'm doing an opinionated guess.
To clarify, do you mean that building the docs locally commenting out the
content-visibilityfrom the CSS has no effect on the rendering time? That’s surprising to say the least, but a very good news if true (I can’t confirm, I’m away from computer). Can you share the rendering time on both versions please?To clarify, do you mean that building the docs locally commenting out the content-visibility from the CSS has no effect on the rendering time?
No need to rebuild the docs; just disable the property directly on the browser.
That’s surprising to say the least, but a very good news if true (I can’t confirm, I’m away from computer). Can you share the rendering time on both versions please?
I'm not sure I can give you a reliable rendering time or statistics as they're bound to my computer. But by even doing a 6x CPU slow down and checking GPU raster it sounds OK. Feel free to check by yourself.
19 remaining items
It’s also the case for e.g.
fs.html, or any doc page that’s large enough.I don't think we need content-visibility on other pages, even if they are large. On nodejs.dev the experiment worked nicely and the pages rendered nicely, and that's by knowing those pages were way more complex than the current docs.
I'm just throwing this out there:
If we are redesigning the docs, is it worth it to fix these small UI bugs when it's all gonna be overhauled soon anyway?
- changed the title
[-]doc: weird scrolling behavior in Chrome and Firefox[/-][+]doc: weird scrolling/anchor behavior in Chrome and Firefox[/+]on Jun 19, 2024 - added a commit that references this issue
on Jun 19, 2024 Well, the only reason for such
content-visibilityflag to exist, is that otherwise rendering the massiveall.htmlpage would be pretty much disgraceful for devices (in terms of performance)If that is quite literally the only reason, can we just set the flag for
all.html? I personally never use that page and we don't cross-reference it to point to specific APIs either as far as I am aware.This has been annoying me for years. #53510 only applies the CSS rule to
all.html.If we are redesigning the docs, is it worth it to fix these small UI bugs when it's all gonna be overhauled soon anyway?
Well, it's a simple fix.
Reacted by Zach Bjornson, Tobias Nießen and Adam FreidinReacted by Tobias Nießen- added a commit that references this issue
on Jun 19, 2024 - added a commit that references this issue
on Jun 20, 2024 - added a commit that references this issue
on Jun 20, 2024 @nodejs/releasers do we have a plan to push this change out soon?
BTW closing this issue as the PR to "fix it" was merged.
Reacted by Adam Freidin
📗 API Reference Docs Problem
Location
Affected URL(s):
Description
At least on Linux and with Chrome, if you load a very long page, like the CommonJS modules API page, and you either press the End key or otherwise scroll to the bottom and then attempt to scroll up or hold down the Page Up key, the scroll bar makes a lot of strange jumps (backwards and forwards). Even starting at the top of the page and scrolling down causes the scroll bar to do some large, sudden, and unexpected jumps. However, using the Home and End keys seemingly work just fine.
My guess is there is either some javascript on the page listening for scrolling events in general or on particular elements (like code blocks) and that is somehow causing the weird issues.