[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: [] []

where could be none | local | global and 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 and 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?

[flackr]

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

You mean, if you call someDescendant.style.setProperty("initial-scroll-target", "local");?

Assuming we follow the fragment scrolling model https://html.spec.whatwg.org/#try-to-scroll-to-the-fragment ,
If parsing is not finished yet this would result in it finding and scrolling to the element.
If parsing is finished this would do nothing until the box is reattached, right?

I suppose there is an argument to say until the user does some scrolling in the box it perhaps should result in updating the scroller since it still doesn't have a user indicated position. Do we do this for changes to align-content?

[flackr]

@DavMila pointed out that the initial scroll position is used until you scroll, so i think in either case if the user hasn't scrolled the scrolling container it would update its scroll position to the target per https://www.w3.org/TR/css-overflow-3/#initial-scroll-position . Note I'm going by the spec since it seems like browsers don't do anything to keep your scroll position if you have scrolled today: https://codepen.io/flackr/pen/QwLEoPL

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap-2] scroll-start-target: auto doesn't match general meaning of auto, and agreed to the following:

• RESOLVED: `scroll-initial-target: none | nearest`

The full IRC log of that discussion

DavidA: scroll-start-target is set on the child of a scrollable container, that makes the container initiall scroll to that child
DavidA: got feedback from the TAG that, looking at the name of the property, the -start could be confusing (it's a logical direction in other properties)
DavidA: also the values are none|auto, was a question about -- currently auto means the element is a scroll-start target, but "auto" usually is used for something more magical
DavidA: so we're lookign for a repalcement value name
DavidA: for property name, scroll-container-target and initial-scroll-target are my suggestions. suggest the second one
(yeah, I like initial-scroll-target)
DavidA: for the values, i'm proposing `none | local`. proposing local because it only effects the nearest scroll container.
DavidA: in theory, in future we could expand the scope of the scrolling target, add "global" or something
flackr: the thinking is that a value which scrolls all ancestors could explain fragment navigation - that does scroll all scrollers up to the root
ack rachelandrew
ack fantasai
(i think i'd prefer something like "self")
https://drafts.csswg.org/scroll-animations-1/#scroll-notation
fantasai: we have scroll() from Scroll Animations. It uses the keyword "nearest", we should be consistent with that
+1
sorry was muted, yes was just leftover from before
fantasai: for property name, would it make sense to put "scroll" first, so scroll-initial-target?
DavidA: I think scroll-initial-target is fine too
flackr: or overflow-initial-target, since most other scorlling properties are overflow
fantasai: we have a lot of scroll-* prefixes, scroll-padding, scroll-snap, etc
flackr: fair, i do like it being grouped with other scrollers. tho it does go on the child rather than the scroll container
fantasai: also several scroll-* properties that are, like scroll-margin
fantasai: I do think these names are better, but we're not clearly managing that this is set on the item
fantasai: I think scroll-margin and scroll-snap-align are a little bit indicative, but my initial impression from the property name is it's set on the scroll container, and takes some reference to a child
(I think scroll-initial-target is reasonably child-indicative. not 100%, but doable)
DavidA: I was thinking scroll-container-target, but not sure if that helps
astearns: i think we're converging, at least for now, on scroll-initial-target. might come up with something better
astearns: shall we resolve on that?
+1
+1 on nearest
fantasai: and none|nearest for values?
DavidA: yeah
astearns: so proposed is `scroll-initial-target: none | nearest`
astearns: objections?
RESOLVED: `scroll-initial-target: none | nearest`
👍🏻
fantasai: can we have a comment soliciting better ideas?
astearns: specifically about something tha tmight more obviously indicate that it's on the child
DavidA: i can write something