[css-anchor-1] Ability for a single element to have multiple anchor names

[kizu]

Disclaimer and additional links

I'm submitting my feedback following my experiments with the current implementation of anchor positioning in Chrome Canary.

I wrote an article about my experiments, but decided to fill most of my feedback as separate issues here.

A quick summary of related links:

• anchor positioning specs
• my article with the experiments

---

While thinking of various use-cases for the anchor positioning, I was thinking: could we want to have multiple effects based on it applied to the same element? If so, for this, we could want to have multiple different anchor names assigned to the same element, so different positioned elements could be attached to the same item declaratively, without the need for them to know the exact name of this element.

For example, we could want to have a tooltip attached to an element, but also to cross-reference it with some other element, and/or have a footnote for it.

Without an ability to have multiple names to the same elements, we could only work around this in the following ways:

• Assign a unique id for the name, and then somehow communicate it to the “recipients”.
• Use multiple wrappers/added pseudo-elements just for the sake of having multiple names available.

Both of these are not ideal.

What if the anchor-name could be a <dashed-ident>+ instead of just a <dashed-ident>? There are other precedents like container-name which is defined as <custom-ident>+, so having the anchor-name follow the same logic would be consistent?

Are there reasons not to do this?

(On a related note — given that there would be cases where the anchor would get an implicit name, like when using the Popover API, what if those names could be always used via something like an implicit list-item counter, basically we could have a built-in ident just for those implicit cases, allowing an element that has a popover to still have other anchors attached to it etc).

[kizu]

Was reading the recent exploration by @fantasai, @jensimmons and @mirisuzanne and noticed that it also defined the anchor-name as <dashed-ident>, and not as <dashed-ident>+. Was there a reason for that as well?

Also, cc @tabatkins and @xiaochengh — allowing defining multiple names for a single element seems like an easy win unless there are caveats I'm not aware of. The need for this came up a lot in my experiments.

[xiaochengh]

I don't see any issue with <dashed-ident>+. We should change it so if that's useful.

[tabatkins]

Yeah there's no particular reason to limit it to one name, except simplicity. If it's useful to allow multiple that's fine, it doesn't change anything about the spec.

[fantasai]

+1 to @tabatkins and @xiaochengh. I think we should aim to be consistent with scroll-animations syntax, though, so that would be <dashed-ident>#.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-1] Ability for a single element to have multiple anchor names, and agreed to the following:

• RESOLVED: make the anchor-name property a comma-separated list of idents

The full IRC log of that discussion

<dbaron> TabAtkins: right now spec is written so an element can only have anchor name. Might want to allow something to be multiply named for different contexts. You *can* work around it, but it can be annoying. No reason to not allow multiple anchor names, not difficult in any way. So want to make anchor-name property a comma-separated list of names.
<dbaron> TabAtkins: fantasai said comma-separated
<dbaron> fantasai: yes, we should try to be consistent
<dbaron> RESOLVED: make the anchor-name property a comma-separated list of idents
<dbaron> TabAtkins: there's a sub-discussion: at the moment, with only one possible anchor name, it's unambiguous dealing with implicit anchors. If you give something an anchor name.... er, wait. There's something at the end of Romain's issue. It's either invalid or we'll deal with it later.