[css-anchor-1] The anchor-scroll property name is confusing/overloaded

[xiaochengh]

"CSS anchor-scroll" and "CSS scroll anchoring" are completely irrelevant things, but the names are almost identical, which may lead to confusions.

More notes/clarifications are needed. Or if possible, rename the property.

[tabatkins]

Very much open to alternate names. Suggestions?

[wangxianzhu]

A clarification paragraph in each spec (css-scroll-anchroing and css-anchor-positioning) may be good enough.

Some SEO measures to improve google search results of "anchor-scroll" will be good, too. Currently the first Google search result of css "anchor-scroll" is about overflow-anchor from css-scroll-anchoring.

[xiaochengh]

Another idea: do we really need to expose anchor-scroll to developers? Especially now it defaults to the default/implicit anchor element, and there really doesn't seem to be any legit use case of anchor-scroll: none

Maybe we can just keep it as an internal detail of calculating the snapshotted scroll offset that:

• If the element has a default anchor element that is acceptable, use that element
• Otherwise, if the element has an implicit anchor element that is acceptable, use that element
• Otherwise, use some anchor element from some anchor() or anchor-size() (with some rules when multiple anchors are used)

This only makes the behavior less controllable (for a developer) when using multiple anchors in different scrollers; But again, the current anchor-scroll is already broken in this case

[tabatkins]

Yeah, I suppose that works? I'd probably just do the first two bullet points, tho; trying to magically infer an element from the anchor functions seems fragile and confusing. The authoring advice will probably end up just being "use anchor-default and don't specify the anchor manually in the function, unless you're doing something special".

[xiaochengh]

The authoring advice will probably end up just being "use anchor-default and don't specify the anchor manually in the function, unless you're doing something special".

But that means scrolling will break for sure when "doing something special", including all use cases that involve multiple anchor elements, which is still an important use case we want to support.

And it doesn't need to be too magical. For example, find the lexicographically first property with an anchor() or anchor-size(), and then use the anchor element in the first anchor function there.

[tabatkins]

But that means scrolling will break for sure when "doing something special", including all use cases that involve multiple anchor elements, which is still an important use case we want to support.

That's fine, you can still set anchor-default and then just manually specify all your anchors. Or use anchor-default for your "main" anchor (which'll be recommended by tutorials, I assume) and manually specify the rest.

For example, find the lexicographically first property with an anchor() or anchor-size(), and then use the anchor element in the first anchor function there.

That's exactly the sort of unpredictability I'm talking about. Switching from setting 'top' to setting 'bottom' can change whether or not an anchor() in 'left' gets used for the scroll adjustment or not. It's deterministic, but with no author-facing rhyme or reason behind it; we just set up a completely arbitrary ordering that they can't predict without reading the spec.

For an example of a predictable behavior, we could go with "if all your anchor() functions are for the same target element, use that as the scroll adjuster". This would handle the most common case in a predictable and useful way, but it would cause scroll adjustment to break if they anchored to a second element, especially if they only did it sometimes, like in a fallback.

[xiaochengh]

I see. Then let's hide anchor-scroll and just use the default/implicit anchor element.