Re: [csswg-drafts] [css-anchor-1] Can't anchor one popover to another (#8165)

<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>

I'm using this issue instead of creating a new one in order not to duplicate things. The issue topic that I wanted to give — “[css-anchor-1] Alternative acceptance criteria”. I did not read in details the existing discussion, and I think I don't have all the context around it, so if what I would describe is/would already be possible with the current specs — let me know!

While most of my experiments were ok with the way the current acceptance criteria work, one of them was heavily limited by it.

The experiment in question: https://kizu.dev/anchor-positioning-experiments/#sidenotes-layout

In this experiment I wanted to attach one absolutely positioned element to another absolutely positioned element, and do this in a chain. This is very similar to cases with multiple nested popovers.

The workaround I found with wrapping things in multiple wrappers and placing the absolutely positioned elements in each of them in a descending order kinda works, but not feasible in any manner for any kind of production code.

While I find the current way things work acceptable (after all, most my other experiments were not blocked by this limitation), I would really-really want to be able to chain-link absolutely positioned elements effortlessly.

What if we could define an alternative acceptance criteria via some additional CSS property? Or maybe even just add it to the current list of them, as the last fallback?

Of course, what I'm talking is — the DOM order. With it there can never be any circularity issues, and while it is not perfect, it would allow us to solve _a lot_ of things.

Can we add it to the existing list of criteria in a way where “if nothing above applies, the element that goes later in the DOM could target the one before it”. This way, we would get the best of two worlds — all the existing ways we can attach things would keep working, but then we would also get an ability to chain-link stuff easily.

The argument about “you'd have to order your DOM by how you expect popups to be invoked” does not work, as the current workaround already expects even more drastic DOM structure, and in absence of a working solution, people would actually use it. Would we want to have 20 wrapping divs for an article with 20 footnotes? Or to create N wrapping divs just so we could chain-link popovers, putting them in different layers?

DOM order is easy to work with, is intuitive and works for the existing chain-linking cases.

My second alternative/addition I wanted to propose — make things works similarly to the way variables can fail — as soon as the circularity is detected, all related attachments should just stop working. Similarly how `--foo: --bar; --bar: --baz; --baz: --foo`; results in all three being invalid, chain-linking elements in a loop could make all of them invalid.

Though, I imagine, this way of handling things is nearly impossible if we want to make things performant?


-- 
GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8165#issuecomment-1469912952 using your GitHub account


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

Received on Wednesday, 15 March 2023 12:25:56 UTC