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鈥檒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

Open
argyleink opened this issue Jan 25, 2022 · 7 comments

Comments

@argyleink
Copy link
Contributor

@argyleink argyleink commented Jan 25, 2022

馃搫 Explainer

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-start position with a specific or by giving a child element scroll-start-target: auto at which point an absolute length is derived from the element and the scroll direction.


Example: set the start position to an absolute value:

:root { --nav-height: 100px }

.snap-scroll-y {
  scroll-start-y: var(--nav-height);
}

Example: set the start position to a snap child

.snap-scroll-inline {
  overflow-inline: scroll;
  scroll-snap-type: inline mandatory;
}

.snap-scroll-inline > #snap-start {
  scroll-start-target-inline: auto;
}

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 馃檪

@scottkellum
Copy link

@scottkellum scottkellum commented Jan 25, 2022

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

@jh3y
Copy link

@jh3y jh3y commented Jan 25, 2022

Hey 馃憢

In addition to scroll-start where I'm assuming this is short for scroll-start: <scroll-start-x> <scroll-start-y> 馃槑

Would be great to have keyword values like those used with the Flexbox API 鉁�

scroll-start: < center | auto | end | start | explicit value >;

蕰麓鈥⑨触鈥蕯

argyleink added a commit to argyleink/ScrollSnapExplainers that referenced this issue Jan 25, 2022
@argyleink
Copy link
Contributor Author

@argyleink argyleink commented Jan 25, 2022

Would be great to have keyword values like those used with the Flexbox API 鉁�

center, start and end added to the explainer! great suggestions thanks!

@MadeByMike
Copy link

@MadeByMike MadeByMike commented Jan 26, 2022

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?

@argyleink
Copy link
Contributor Author

@argyleink argyleink commented Jan 26, 2022

If this is a < length > value I assume percentages would work and you might not need keywords. Although you could always have both.

they're already specced as <length-percentage> 馃檪


Or do they remain relative until the scroll is interacted with thus changing the scroll position?

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

@Sheraff
Copy link

@Sheraff Sheraff commented Jan 26, 2022

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.

@argyleink
Copy link
Contributor Author

@argyleink argyleink commented Jan 26, 2022

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 tabindex properly on their markup so tabbing into the (carousel, tabs, testimonials, etc) didnt scroll them to the beginning.

tab/focus management should pair closely with this prop. it'd be a good idea to mention that in the explainer/docs though thanks! 馃憤馃徎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants