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

ʕ´•ᴥ•`ʔ

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!

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?

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

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.

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

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

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 🙂

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

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

Using a selector() is a last-resort kind of thing, when there's no way to scope the element you're associating with. Requiring an ID is onerous, and still doesn't actually give you uniqueness; allowing more general selectors gives you the same non-uniqueness issues you're trying to avoid.

Here, it's straightforward - you want a descendant of the scroll container. Having the target self-select is a pretty straightforward and normal way to handle this.

When there's more than one element advertising itself as the target, you just take the first in tree order or something.

Related problem: baseline alignment to arbitrary child #1339
Should use a consistent method model in both cases.

I think this is also related to #6225, which is about integration with history and navigations.

Two issues that the explainer should address:

1. If the target element moves around (or the scroller gets resized), does the scroll position track it?
2. If the target element is close to the bottom of the scrolled content, you need to apply constraining logic to avoid over-scrolling.

Also need to spec how this interacts with scroll anchoring: https://drafts.csswg.org/css-scroll-anchoring/

The CSS Working Group just discussed [css-overflow] Proposing scroll-start: allowing overflow scroll to not always start at 0 on 1st layout pass, and agreed to the following:

• RESOLVED: Accept the proposal for scroll-start and add to scroll snap L2
• RESOLVED: Add argyle as a co-editor of scroll snap L2

When there is multiple scroll-start-targets, can we let the author choose the selection mechanism?

Say that we had a property called scroll-start-target-selection with possible values ['safe' | 'unsafe']? && ['first' | 'last']. first and last would select the first or last start target in DOM order, while safe would make a start-target invalid if scrolling to that start-target would result in a previous start-target being partially or fully scrolled out of the scrollport.

One use case is a scroll snap image gallery.

If the container is narrow, you’d want to start at the snap position of the first image. But, if the scrollport have space enough, you’d want to start at the snap position of the second image so that more images are visible from the start.

.snap-scroll-inline {
  overflow-inline: scroll;
  scroll-snap-type: inline mandatory;
  scroll-start-target-selection: safe last;
}

.snap-scroll-inline > :nth-child(-n+2) {
  scroll-start-target-inline: auto;
}

cool use case, totally makes sense.

to me though, sounds like container queries are the perfect way to handle this:

.snap-scroll-inline {
  overflow-inline: scroll;
  scroll-snap-type: inline mandatory;
  container-type: inline-size;
  container-name: carousel;
}

@container carousel (width >= 720px) {
  .snap-scroll-inline > :nth-child(-n+2) {
    scroll-start-target-inline: auto;
  }
}

So mobile does no scroll start adjusting, aligns inline-start nicely with the rest of a column layout design. but if width goes above 720, then set the scroll start target as to "peek" and "hint" at the carousel breadth of content by setting the scroll start target to something other than the first item. thoughts on using container queries to manage a carousels available space and dynamic scroll start positioning?

to me though, sounds like container queries are the perfect way to handle this:

Container queries can definitively be used to handle this in many cases. However it requires that you know the approximate size and scroll snap alignment of the target elements, and possibly the scroll padding and margins as well.

Say that you have a user editable gallery, where users can add images of any aspect-ratio. The images are sized so that that have the same area, so that a 16:9 and a 9:16 image are the same “size”.

The only way to know if you can safely scroll to the second image is to calculate all the snap positions, and check them against the border-box of the first image to see if it is partly or fully scrolled out of the scroll container.

I quite like how ‘overflow-position’ in css-align-3 works, and would love a similar approach here: Try to align the initial scroll with the last scroll-start-target, but only if it can be done without obscuring any previous elements.

I agree with Sebastian that <position> can replace the current value definition:

[ auto | start | end | center | left | right | top | bottom | <length-percentage [0,∞]> ]{1,2}

<position> is more powerfull. But it would need to accept flow-relative keywords start and end (like in CSS Backgrounds 4, cf. #549).

I am a bit confused by start as the second value when it is omitted in the shorthand, and auto (not defined) as the initial value of the longhands.

CSS is not very consistent with default values in shorthands. Sometimes they resolve to a previous value (margin, border-color, etc), or the initial longhand value (animation, font, etc), or an arbitrary value (background-position, there does not seem to be many examples in this category).

The behavior of the first category feels more natural to me when specifying a logical shorthand value, ie. end would expand to end end instead of end start. This could also apply to scroll-start-target (the second value defaults to none).

I am not sure scroll-start and scroll-start-target can map to both their physical and flow-relative longhands. Which of the physical longhand should the first/second value map to?

All logical shorthands currently map to their physical longhands.

Related: #1282

Just in case: today I wrote a post where I shared a workaround for this that uses scroll-snap — https://blog.kizu.dev/snappy-scroll-start/

That workaround is not very convenient, mostly due to the interop issues with the current scroll-snap (I'll investigate them at a later time), but if someone needs scroll-start today — maybe this workaround would be useful to you