[css-scroll-snap-2] scroll-start-target: auto doesn't match general meaning of auto

[DavMila]

The scroll-start-target spec specifies 2 keywords for the scroll-start-target property:

• none, meaning: this element is not to be used to determine the initial scroll position of its nearest scroll container, and
• auto, meaning: this element should be used to determine the initial scroll position of its nearest scroll container.

The use of auto in this way is a bit of a departure from what auto means in CSS, i.e. "the UA should do what it thinks is best."

Should we change auto to a different keyword? Here are a few we could consider: on-first-appearance or align or active or visible. My preference would be align.

[DavMila]

FYI @flackr, @argyleink

[argyleink]

time to bikeshed! lol. I do think a different value is better.

options?

1. first-paint
2. page-load
3. me
4. scroll-ready
5. loaded
6. on-first-appearance
7. align
8. active
9. visible
10. init
11. here

[flackr]

Since we have ideas that we might try to include all scroll-start-targets, we could consider something like include?

Or, we could consider other values we may want to eventually support. E.g. if we wanted to eventually have options that align with / explain scrolling to a fragment, we could consider what the names might be if we want to describe the ways that this is currently different from that and/or if we eventually wanted to be able to specify a scroll that was roughly equivalent to scrolling to a fragment.

In particular, scrolling to a fragment:

• Scrolls all ancestor scrollers as well, e.g. scroll-start-target: none | local | global?
• Only scrolls if discovered during the navigation, but not if you later add the node to the document, e.g. scroll-start-target: none | navigation | always

[DavMila]

Thanks @argyleink & @flackr, I like these suggestions.

In particular, scrolling to a fragment:

• Scrolls all ancestor scrollers as well, e.g. scroll-start-target: none | local | global?
• Only scrolls if discovered during the navigation, but not if you later add the node to the document, e.g. scroll-start-target: none | navigation | always

I think it would be nice to keep these options open so I wonder if we could simply replace auto with local in the current implementation, allowing us to later include global as an alternative option in the future. This wouldn't break any pages using local as local would still match the "nearest scrolling ancestor" interpretation in the current implementation.

We would also be able to, in the future, expand the syntax to address both questions, i.e. have scroll-start-target take one or two values:

scroll-start-target: [<scope>] [<timing>]

where <scope> could be none | local | global and <timing> could be navigation | always.

[DavMila]

It's also been pointed out that within CSS it might be very common to assosciatestart with the edges of a box, e.g. "start" occurs in margin-block-start, inset-block-start, border-block-start, padding-block-start, etc., and could therefore be confusing in scroll-start-target. Perhaps we we could give the property a better name.
Some suggestions:

• scroll-origin-anchor
• scroll-origin-target

It probably makes sense to talk about the name of the property before talking about what keywords are appropriate.

[argyleink]

i like scroll-origin 👍🏻

[johannesodland]

Wouldn't scroll-origin-* possibly be confusing, as we're not affecting the scroll origin, but the initial scroll position of the container?

[flackr]

I agree with @johannesodland. I think we should try to use terminology that either conveys initial scroll position or something from the html spec try to scroll to the fragment.

[DavMila]

Wouldn't scroll-origin-* possibly be confusing, as we're not affecting the scroll origin, but the initial scroll position of the container?

I also agree, but I felt since scroll origin is more of a spec detail rather than an API exposed to developers, it wouldn't be much of a concern. But maybe some future property might use "scroll-origin-*" in a way that aligns with scroll origin so it would be better to avoid that potential source of confusion if we can.

I've also thought of initial-scroll-target (it just sounds better than scroll-initial-target :) ) but I felt it might sound like it's specifying what the affected element should scroll to rather than that it should be scrolled to by its containing scroll container (though the same can be said of scroll-start-target) so I wondered if scroll-container-target might be a better name. It doesn't convey initial scroll position quite as directly but it might work well if we combine it with options that reflect <scope> and <timing> like I mention above. E.g.:

.target {
    scroll-container-target: local always;
}

To be clear I'm not proposing we adopt all these names right away, but that scroll-container-target is a name we can use now which would work well with other options we might think about in the future.

[DavMila]

Thinking about this a little more, perhaps initial-scroll-target best represents what we are trying to express here.

Firstly for the property name, I think options we should consider are:

• scroll-container-target, and
• initial-scroll-target,

between which my preference is for initial-scroll-target because it more directly expresses that the affected element should be scrolled to when its scroll container is first displayed than scroll-container-target does.

Then, for the property values, I think we should consider:

• none | local,
• none | nearest, and
• none | include,

among which my preference would be none | local because I think it would work nicely with a future expansion of the options to include global.

[argyleink]

I like initial-scroll-target, nice! Value proposals work for me.

[fantasai]

Related to the property name discussion: #10913

[fantasai]

I think the interesting question is, what happens if you set this property via the CSSOM?