Skip to content
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

Merged
merged 1 commit into from
Jul 10, 2024

Conversation

cloydlau
Copy link
Contributor

@cloydlau cloydlau commented Jul 1, 2024

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.

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/nodejs-website
@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Jul 1, 2024
Copy link
Contributor

@AugustinMauroy AugustinMauroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@ovflowd ovflowd left a 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.

Copy link
Member

@RedYetiDev RedYetiDev left a 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.

@RedYetiDev
Copy link
Member

By the way, this fixes #53594

@yume-chan
Copy link

scroll-padding-top: 50vh; causes section titles to scroll to the center of the page when a link is clicked, which is confusing. Also, dragging to scroll triggers across the entire top half of the page, making it very difficult to select text (#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.

@ovflowd
Copy link
Member

ovflowd commented Jul 2, 2024

I 2nd what @yume-chan wrote abovd

@cloydlau
Copy link
Contributor Author

cloydlau commented Jul 3, 2024

@yume-chan @ovflowd @RedYetiDev

But it shouldn't be removed. It should be set to the real height of the header (plus some reasonable padding)

For the documentation of Node 17, yes, that is exactly what I did in this PR. However, adding scroll-padding-top to the documentation of Node 22 can instead cause extra padding.

After some testing, for the documentation of Node 22, sometimes it requires scroll-padding-top: 70px; and sometimes scroll-padding-top: 0; is needed. It is not very stable. Strangely, after I removed scroll-behavior: smooth;, everything works fine. Maybe there's a bug with it.

You can test it by following the steps below:

  1. Open https://nodejs.org/docs/latest-v22.x/api/assert.html

  2. Open the browser Console

  3. Run

    document.documentElement.style.scrollPaddingTop = 'initial'
    document.documentElement.style.scrollBehavior = 'initial'
    document.querySelector('#toc > ul > li > ul > li:nth-child(5) > a').click()

    but if you reload the page and then run

    document.documentElement.style.scrollPaddingTop = '70px'
    document.documentElement.style.scrollBehavior = 'initial'
    document.querySelector('#toc > ul > li > ul > li:nth-child(5) > a').click()

    or

    document.documentElement.style.scrollPaddingTop = 'initial'
    document.querySelector('#toc > ul > li > ul > li:nth-child(5) > a').click()

    you don't necessarily go to the desired location.

@jwueller
Copy link
Contributor

jwueller commented Jul 4, 2024

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.

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.

That is, in fact, already being accomplished by this bit in the same file:

h2 :target,
h3 :target,
h4 :target,
h5 :target {
scroll-margin-top: 55px;
}

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 55px to something like 4rem, so that it scales more cleanly with font size adjustments. And if you want to make it even prettier you can reduce it to like 1rem when the header is hidden.

Alternatively, replace the scroll-margin-top on the headings with scroll-padding-top: 4rem on the document. But having both makes no sense here, and making it relative to viewport height is definitely a bad idea in all cases.

tl;dr: Please consider merging this, since the header is already accounted for, and the current behavior is broken and also redundant.

@cloydlau
Copy link
Contributor Author

cloydlau commented Jul 4, 2024

  • Solution 1: scroll-margin-top on the headings, compatible with or without headings, but may not work when used with scroll-behavior: smooth; (I have removed it for now, does anyone know why?).

  • Solution 2: scroll-padding-top on the document, not compatible without headings, but works normally when used with scroll-behavior: smooth;.

@RedYetiDev
Copy link
Member

RedYetiDev commented Jul 6, 2024

Imo Solution 2 makes more sense, as there are cases where the user will want to highlight the headings, WDYT @ovflowd?

@ovflowd
Copy link
Member

ovflowd commented Jul 6, 2024

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?

@RedYetiDev
Copy link
Member

I don't think so, but I might be wrong.

@jwueller
Copy link
Contributor

jwueller commented Jul 7, 2024

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 scrollIntoView()).

I think it probably makes sense to put scroll-padding-top: 4rem on html, and then get rid of the entire heading rule, including the scroll-margin-top, since it doesn't do anything useful at that point.

@RedYetiDev RedYetiDev added the commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. label Jul 8, 2024
@RedYetiDev
Copy link
Member

@cloydlau IMO the commit message should be updated to better explain the change

I suggest:
doc: update `scroll-padding-top` to 4rem

But this is only a suggestion

@bukowa
Copy link

bukowa commented Jul 9, 2024

Docs are unusable, not sure if this is related but when you select some text it scrolls.=
lol

@RedYetiDev
Copy link
Member

RedYetiDev commented Jul 9, 2024

@bukowa, this PR intends to fix that issue, once it lands.


@cloydlau, could you remove the second clause of your commit, it's too long to pass validation. IMO you really only need the first part to update stand the change.


I've removed the squash label, as this PR has been squashed by the author.

@RedYetiDev RedYetiDev removed the commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. label Jul 9, 2024
@targos
Copy link
Member

targos commented Jul 10, 2024

@ovflowd Can you please review again? I hit the problem that makes it impossible to select text today and it is really annoying.

@ovflowd
Copy link
Member

ovflowd commented Jul 10, 2024

@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.

Copy link
Member

@ovflowd ovflowd left a 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.

@ovflowd ovflowd added commit-queue Add this label to land a pull request using GitHub Actions. author ready PRs that have at least one approval, no pending requests for changes, and a CI started. labels Jul 10, 2024
@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Jul 10, 2024
@nodejs-github-bot nodejs-github-bot merged commit 661ae62 into nodejs:main Jul 10, 2024
19 checks passed
@nodejs-github-bot
Copy link
Collaborator

Landed in 661ae62

@targos
Copy link
Member

targos commented Jul 10, 2024

I don't think this PR fixes that

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.

@ovflowd
Copy link
Member

ovflowd commented Jul 10, 2024

I don't think this PR fixes that

I'm not sure, but I downloaded the artifact from 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?

@targos
Copy link
Member

targos commented Jul 10, 2024

Yes. Documentation for a specific release, like other assets, is immutable.

@jwueller
Copy link
Contributor

jwueller commented Jul 10, 2024

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.

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.

@ovflowd
Copy link
Member

ovflowd commented Jul 10, 2024

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.

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.

aduh95 pushed a commit that referenced this pull request Jul 12, 2024
PR-URL: #53662
Reviewed-By: Claudio Wunder <cwunder@gnome.org>
Reviewed-By: James M Snell <jasnell@gmail.com>
@aduh95 aduh95 mentioned this pull request Jul 12, 2024
@jwueller
Copy link
Contributor

jwueller commented Jul 13, 2024

Well, if you read my last comment I actually acknowledge that it does.

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.

aduh95 pushed a commit that referenced this pull request Jul 16, 2024
PR-URL: #53662
Reviewed-By: Claudio Wunder <cwunder@gnome.org>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. doc Issues and PRs related to the documentations.