Clarify browser behaviour
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation, web-dev
Research direction
Read the existing documentation alongside the linked HTML specification sections and both CodePen examples. Clarify that browsers can restore nested scroll containers, while restoration may fail when the element is removed and later remounted; confirm the final wording against the examples.
Written by the indexing model from the issue text.
Description
Hey! 👋 I just wanted to drop a note about something in the documentation that I think is incorrect:
If the user scrolls a list, then navigates back and forth, the browser will scroll the page to the top, but the list will still be scrolled to the position it was at when the user left the page.
Browsers can actually restore scroll positions for nested scroll containers. Here's a reduced test case to demonstrate that scroll restoration does work for non-body aka nested scroll containers: https://codepen.io/OliverJAsh/pen/bGPqyRw
Relevant specs:
- https://html.spec.whatwg.org/multipage/browsing-the-web.html#restore-persisted-state
- https://html.spec.whatwg.org/multipage/browsing-the-web.html#restorable-scrollable-regions
I think the issue you're referring to is what happens when an element is removed from the DOM after leaving one page and then restored when navigating back. In this case, the browser can't restore scroll because it has no way of knowing that we're remounting the same element as before. Reduced test case: https://codepen.io/OliverJAsh/pen/gONmJZM
Perhaps we could clarify this in the documentation? Or perhaps I've misunderstood 😄
- Dominant language
- TypeScript
- Stars
- 261
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from epicweb-dev/restore-scroll
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
epicweb-dev/restore-scroll#12 · 1 comment ·
-
Requires a loader Openhelp wanted
Difficulty 3/5 1-2 days Newbie friendliness 45/100
epicweb-dev/restore-scroll#9 · 4 comments ·
-
help wanted
Difficulty 4/5 3-5 days Newbie friendliness 25/100
epicweb-dev/restore-scroll#3 · 4 comments ·
-
help wanted
Difficulty 4/5 3-5 days Newbie friendliness 25/100
All issues in epicweb-dev/restore-scroll
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fullcalendar/fullcalendar#8106 ·