-
Notifications
You must be signed in to change notification settings - Fork 28.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: fix that 22.x docs scroll to wrong locations #53662
Conversation
Review requested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think your previous changes actually caused any issue, but gotta test by myself.
The comment you received on your merged PR was unrelated to your change and actually a bug caused by recent Chromium changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In favor of #53679, but I think this doesn't have to do with the wrong scrolling, but rather the highlighting scroll speed issue, see the linked PR for more info.
By the way, this fixes #53594 |
But it shouldn't be removed. It should be set to the real height of the header (plus some reasonable padding) so section titles won't be covered by the floating header when scrolling to them. |
I 2nd what @yume-chan wrote abovd |
@yume-chan @ovflowd @RedYetiDev
For the documentation of Node 17, yes, that is exactly what I did in this PR. However, adding After some testing, for the documentation of Node 22, sometimes it requires You can test it by following the steps below:
|
It seems like this scroll padding is an attempt at scrolling the clicked link target to the center of the viewport. It has a lot of nasty side-effects though, and breaks user expectation in my opinion. Usually the anchors are expected to scroll to the top.
That is, in fact, already being accomplished by this bit in the same file: Lines 43 to 48 in f1ac7df
So there is no reason to keep the scroll padding on the entire document in my opinion. Speaking of the real header size, I suggest changing the snippet above from Alternatively, replace the tl;dr: Please consider merging this, since the header is already accounted for, and the current behavior is broken and also redundant. |
|
Imo Solution 2 makes more sense, as there are cases where the user will want to highlight the headings, WDYT @ovflowd? |
Is there any situation where a page has no headings? |
I don't think so, but I might be wrong. |
Number 1) requires fewer changes from the current one, but 2) is definitely more universal, since it's not restricted to only aligning the headings correctly. It also works for any other element that might get scrolled into view by any other mechanism (like I think it probably makes sense to put |
@cloydlau IMO the commit message should be updated to better explain the change I suggest: But this is only a suggestion |
@ovflowd Can you please review again? I hit the problem that makes it impossible to select text today and it is really annoying. |
I don't think this PR fixes that, @targos. This PR is about when scrolling to a section, it being off by a bit or by a lot. To be honest I don't know what is the root cause of the issue you are facing, but it is indeed annoying as hell. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! This should fix the wrong offset.
Landed in 661ae62 |
I'm not sure, but I downloaded the artifact from https://github.com/nodejs/node/actions/runs/9851882411 and tested locally. The issue is gone. |
Interesting. Could be, since it is adding padding non-stop to the scroll itself. Yeah this should fix then. We landed it. I assume it will ship only with the next release? |
Yes. Documentation for a specific release, like other assets, is immutable. |
It does, because the padding was spanning 50% of the viewport. That caused browser select-auto-scroll thresholds to behave differently, and a bunch of other potential problems like the ones described here and in the linked issues. The scroll padding was (ab)used to achieve an effect that it isn't intended for, thereby changing unrelated semantics. |
Well, if you read my last comment I actually acknowledge that it does. |
PR-URL: #53662 Reviewed-By: Claudio Wunder <cwunder@gnome.org> Reviewed-By: James M Snell <jasnell@gmail.com>
Yeah, that's my bad. I should have read more thoroughly. I was mostly focused on summarizing the exact mechanism and not specifically trying to single you out. |
PR-URL: #53662 Reviewed-By: Claudio Wunder <cwunder@gnome.org> Reviewed-By: James M Snell <jasnell@gmail.com>
See: #45131 (comment)
That PR was proposed on Octobe 2022, at that time Node 22 had not yet been released. It might be caused by
scroll-padding-top: 50vh;
. Therefore I submitted a PR to fix that issue.However, that issue still exists in the Node 17 documentation. I submitted this PR to specifically address the documentation for Node 17.