A couple questions here:

1. Is scroll-start-target: auto a developer-friendly way to say "please scroll to me"? I'd expect auto to mean "do what the UA thinks is right", which is not the behavior it's currently specified to have. I could imagine on-first-appearance being a clearer way to describe what it's asking for. This sort of naming question is firmly within the CSSWG's area of expertise, so there's probably a long discussion thread about it, and I would just benefit from a link to it.
2. https://drafts.csswg.org/css-scroll-snap-2/#scroll-start-target-fragment-navigation says "While the document is being updated ...". This sort of COMEFROM statement is out of favor in modern specifications. Can y'all work to add an appropriate hook in HTML?
3. If a page is slow to load and has multiple scroll-start-target elements, it seems like the current definition might cause multiple scrolls, if the UA decides to partially render after getting the initial target. Developers might not see this if they test only on a fast connection, but users on slower devices could wind up with a bad experience. Does something in the definition subtly prevent this? Has the WG discussed how to prevent it?

Thanks!

1. Is scroll-start-target: auto a developer-friendly way to say "please scroll to me"? I'd expect auto to mean "do what the UA thinks is right", which is not the behavior it's currently specified to have. I could imagine on-first-appearance being a clearer way to describe what it's asking for. This sort of naming question is firmly within the CSSWG's area of expertise, so there's probably a long discussion thread about it, and I would just benefit from a link to it.

Great point but unfortunately, I'm afraid there isn't a discussion thread I can point to. I think you are right that this would be a bit of a departure from what auto in CSS means. A better keyword might be in order, something like: on-first-appearance or align or active or visible. I'll file an issue with the working group.

2. https://drafts.csswg.org/css-scroll-snap-2/#scroll-start-target-fragment-navigation says "While the document is being updated ...". This sort of COMEFROM statement is out of favor in modern specifications. Can y'all work to add an appropriate hook in HTML?

That seems like a good idea, thanks. I’ll write a PR to add a hook to the HTML spec.

3. If a page is slow to load and has multiple scroll-start-target elements, it seems like the current definition might cause multiple scrolls, if the UA decides to partially render after getting the initial target. Developers might not see this if they test only on a fast connection, but users on slower devices could wind up with a bad experience. Does something in the definition subtly prevent this? Has the WG discussed how to prevent it?

The spec prioritizes selecting the scroll-start-target element which is first in DOM order. For the UA to select and scroll to a different target, the UA would have to have inserted the late-arriving target into the DOM in a position that is before the position of the already-selected target in DOM order. We think that it isn’t very common for pages to load elements out-of-order and so having multiple scroll-start-target elements is not likely to lead to unfriendly jumps.

1. Thanks!
2. Thanks!
3. Ah, ok. After re-reading the spec, I agree that it says to always use the first candidate element, and nothing in the explainer contradicts that. I was thinking that the page could add a scroll-start-target element in response to user interaction, and the UA was supposed to scroll to the new one even if there were old ones earlier in tree order, but that's not correct.

I don't see any other issues, and I'll see if we can close this this week.

Thanks for bringing us this review. In addition to the comments above, we think "start" in the property name may be confused with the start vs end edges of a box. Could the CSSWG look into another term there?

Aside from that, we think this feature can't be considered ready until the WG has discussed using a property value other than auto, but once those two discussions have happened, it looks like a good feature, and we expect to be happy to switch this review to Resolution: satisfied if you ping us.

Just a quick update here:

• the CSS working group resolved to use scroll-initial-target instead of scroll-start-target and nearest instead of auto, and
• an HTML spec PR (which has some preliminary approval) is in progress to add a hook as requested.