[css-highlight-api][css-anchor-position] Allow `anchor-name` on `::highlight(...)`

[nicolo-ribaudo]

I am writing a little editor using ::highlight() to mark some errors in the text, and when hovering over the errors it shows a popup with more details:

Screen.Recording.2024-10-28.at.17.58.47.mov

Right now I'm positioning these popups using JavaScript. However, it would be great to be able to give those highlights a name through anchor-name: --error-1, anchor-name: --error-2, ... and then set anchor-name on the popup to automatically show it in the right place.

Another use case for this would be to show a popup with spelling suggestions.

[fantasai]

The main issue with this is that the boundaries of a highlight pseudo are not well-defined; so properties that need to reference it (e.g. for positioning) aren't currently allowed.

[nicolo-ribaudo]

For the JavaScript implementation of this, I'm using .getBoundingClientRect() on the ranges that are part of the highlight. Maybe it could behave similarly?

[Westbrook]

My team and I are also looking at ways to further reduce our reliance on user land tools like Floating UI in exchange for platform primitives like CSS Anchor Positioning. In our case, our application can sometime provide explanations of its work to a user like:

Say a user doesn't understand some of this, they can highlight the text they want to know more about about are provided an "Explore this" button to dig deeper into the concept:

This is quite similar to some of the newer output from a Google search:

Here too you can highlight parts of the explanation to act on that content in various way:

For these types of experiences, the ability to leverage things like position-try-fallbacks and the like are highly important to ensure the smoothest consumption of the interaction.

Here's hoping we can leverage CSS Anchor Positioning via ::highlight(...) in the (near 😉) future. 🤞🏼

[frivoal]

The main issue with this is that the boundaries of a highlight pseudo are not well-defined; so properties that need to reference it (e.g. for positioning) aren't currently allowed.

given that anchor positioning has collision avoidance / positioning fallbacks built it, I wonder if that's something we could just look past: even if you don't know exactly where/how big the highlight is, the positioning should still be robust.