[css-anchor-position] Allow multiple names in position-anchor, for fallback

[tabatkins]

Currently, position-anchor takes only a single anchor reference, which is used by several features (position-area, an unspecified reference in anchor(), etc).

However, there are good use-cases to want to do fallback between anchors, using one if it exists, and using another if it doesn't. For example, this use-case written by Una has the outline track the currently-hovered element if it exists (from a :hover rule setting a --hovered anchor name), and otherwise uses the currently-selected element (from a .selected class setting a --selected anchor name).

You must use separate anchor names + fallback for this example; if you try to use only a single anchor name, it will appear to "work" when you hover things after the selected element (because we take the last valid anchor in DOM order), but will never anchor against things that are before the selected element in DOM order.

This is a bit awkward to write today, as it means you have to repeat yourself a lot in the styles, and don't get to rely on position-anchor setting the default so you can omit the anchor name. It also simply will not work for position-area and similar features that depend on position-anchor; you'd have to do some awkward :has(button:hover) rules to instead manually swap between position-anchor: --hovered; and position-anchor: --selected;.

---

So, I propose that position-anchor extends its grammar to a comma-separated list of values, and just uses the first anchor reference that successfully resolves. So the example I linked above could just use position-anchor: --hovered, --selected;, and then all the anchor() and anchor-size() references could just omit the anchor reference and wouldn't need fallback at all.

(This does somewhat break the correspondence between position-anchor: X; top: anchor(top); and top: anchor(X top);, but I'm okay with that since you can just desugar in a slightly more verbose way using fallback.)

/cc @una

[una]

Thanks for opening this @tabatkins! Here's the pen that describes the issue. The CSS specificity of the selector which updates anchor-name on :hover/:focus is higher than the specificity of the anchor-name set on .selected. It updates as-expected when the DOM order of the .selected item is before the :hover/:focus item, but not when it comes after.

For example, this works as expected when the first item is the .selected one. However, when the 3rd item is .selected, the styles will apply to the 4th and 5th item, but not the 1st and 2nd.

While this works as specced, from an authoring perspective it feels unexpected.

[tabatkins]

Yup, just noting that all cross-element name references like this in CSS don't pay attention to specificity when resolving name conflicts; they all consistently resolve such conflicts just by looking at the DOM structure (generally (always?) "last wins", like what anchor references do).

Involving specificity in this process would be a novel change, and I think usually not what you want. For example, if the "selected" element sets its anchor-name via the style attribute, then hovering would need to use !important to get anchor-name to win.