w3c / csswg-drafts Public
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-overflow] Proposing scroll-start: allowing overflow scroll to not always start at 0 on 1st layout pass
#6986
Comments
|
+1 this would make scroll up for search or scroll up for nav really easy. These are common patterns in some native apps, for example iOS uses scroll up for search in numerous places. |
|
Hey In addition to Would be great to have keyword values like those used with the Flexbox API scroll-start: < center | auto | end | start | explicit value >;蕰麓鈥⑨触鈥蕯 |
center, start and end added to the explainer! great suggestions thanks! |
|
If this is a < length > value I assume percentages would work and you might not need keywords. Although you could always have both. I also assume if you set it to a value like 50vh this would scroll down to half the height of the viewport on initial render but not be relative going forward? Similar with percentage values? Or do they remain relative until the scroll is interacted with thus changing the scroll position? |
they're already specced as
they're active until interacted with yep, at which point they not longer apply. from the explainer "Once the user has interacted with the scroll area, scroll-start and scroll-start-target has no effect. The styles must be present during scrollport creation or they have otherwise missed their timing." |
|
For people who use the keyboard to navigate : would this impact the starting position of the focus ? Otherwise the first time you press TAB you'll be taken back to the beginning of the scroll area. |
Excellent consideration. I imagine a developer using this new prop could/would have already been managing tab/focus management should pair closely with this prop. it'd be a good idea to mention that in the explainer/docs though thanks! 馃憤馃徎 |
Currently, JavaScript needs to show up at "never the right time" to adjust a scroll position to a specific starting place. This CSS property proposal seeks to remedy page load scroll jank by allow specifying a
scroll-startposition with a specific or by giving a child elementscroll-start-target: autoat which point an absolute length is derived from the element and the scroll direction.Example: set the start position to an absolute value:
Example: set the start position to a snap child
There's a lot more use cases and details (like interaction with fragment navigation) about the proposal in the Explainer
Would love to present the details of the explainer to the CSSWG for feedback馃檪
The text was updated successfully, but these errors were encountered: