[csswg-drafts] [css-anchor-1] Ability for a single element to have multiple anchor names (#8837)

kizu has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-1] Ability for a single element to have multiple anchor names ==
<details>
<summary>Disclaimer and additional links</summary>

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](https://drafts.csswg.org/css-anchor-position-1/)
- [my article with the experiments](https://kizu.dev/anchor-positioning-experiments/)

- - -
</details>

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`](https://drafts.csswg.org/css-contain-3/#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).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8837 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 13 May 2023 14:35:09 UTC