[css-overflow] Proposing `scroll-start`: allowing overflow scroll to not always start at 0 on 1st layout pass

[argyleink]

📄 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]

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

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]

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]

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]

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]

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]

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! 👍🏻

[SebastianZ]

The idea itself is great! Thank you @argyleink for bringing that up!

I have some notes, though.

1. scroll-start-target looks like a longhand for scroll-start.
2. Talking of setting the scroll position with x and y coordinates, why not use a <position> value for that?
3. What happens when multiple scroll container children have scroll-start-target defined?
4. Both properties do the same thing, except one is set on the container, the other on a child?

To answer those questions here's my counter-proposal:

scroll-position = <position> || selector(<id-selector>)

Examples (rewritten from the initial comment):

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

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

.snap-scroll-inline {
  overflow-inline: scroll;
  scroll-snap-type: inline mandatory;
  scroll-position: selector(#snap-start);
}

Explanation:

We concentrate the functionality in one property set on the scroll container. As this initial scroll position only has effect on scrollport creation before any user interaction, it means the DOM already needs to be fully available at that point in time. So setting it on the container with a selector for the child should be fine.
If the selector matches multiple elements, the first one in document order is considered to be the target.
Also, allowing to set both the selector and the position allows to define offsetting from that element.

Additional note: The property is independent from the things defined in CSS Scroll Snap 1. I.e. you can define a scroll position without having any scroll snap containers.

---

Having said all that, another approach could be to align with CSS Scroll Snap 1, and there specifically with scroll-padding-* and/or scroll-margin-*. You'd then just need to have a way to specify the initial scroll snap position.

Sebastian

[argyleink]

2. Talking of setting the scroll position with x and y coordinates, why not use a value for that?

i suppose this could get discussed more, but i do still feel like <length-percentage> works better here? curious what the tradeoffs are.

3. What happens when multiple scroll container children have scroll-start-target defined?

Explainer says it's the 1st in the DOM order with the property. So competition is resolved by 1st node found. Matches your proposal too it looks like.

4. Both properties do the same thing, except one is set on the container, the other on a child?

Like scroll-snap, some of the style is specified by the scrollview and some by a child. The original explainer used selector() but I agree with other CSSWG members that selector() circumvents CSS's natural selection mechanism. So, the workflow maps closer to scroll-snap, where a child needs to specify the property on itself. No new functions need required for the feature, which is nice.

Thanks for the thoughts! Hopefully my answers seem reasonable 🙂

[SebastianZ]

2. Talking of setting the scroll position with x and y coordinates, why not use a <position> value for that?

i suppose this could get discussed more, but i do still feel like <length-percentage> works better here? curious what the tradeoffs are.

The tradeoff using <position> is that it forces the order to be horizontal first then vertical, which might not be the order you'd expect in this case. Though it provides every functionality related to positioning and additional features to just <length-percentage> (which is included, btw.) like offsetting from the center, for example.

3. What happens when multiple scroll container children have scroll-start-target defined?

Explainer says it's the 1st in the DOM order with the property. So competition is resolved by 1st node found. Matches your proposal too it looks like.

I don't see that in the explainer, though if it's meant to match my proposal, it's fine for me. 😄

4. Both properties do the same thing, except one is set on the container, the other on a child?

Like scroll-snap, some of the style is specified by the scrollview and some by a child.

My point was that it's not strictly necessary to have two properties for that because the use cases can be covered by a single one. Though I don't have a strong opposition against adding two.

The original explainer used selector() but I agree with other CSSWG members that selector() circumvents CSS's natural selection mechanism. So, the workflow maps closer to scroll-snap, where a child needs to specify the property on itself. No new functions need required for the feature, which is nice.

Just for the record, selector() is not new. See the related issue #5811.

My first point still stands, though. The names should be chosen so that it's clear that they don't have a shorthand-longhand relation.

Sebastian