[CSS Anchored Positioning] Is "maintenance of logical order" really needed?

[mfreed7]

In this section of the explainer, there is a discussion of the maintenance of logical order based on the anchor attribute. My question is whether this is needed at all, or if so, why. The motivation section calls this out with this footnote:

Wherever possible, authors should ensure that the DOM and visual order match without requiring special handling. As this may prove difficult for some anchoring use cases, an anchored positioning scheme should provide a way to heal this mismatch and ensure accessible content traversal.

I'm wondering if we should enumerate the "difficult" use cases? For the typical <popup> use case, it would seem that the DOM order can be easily aligned with the logical/visual order, so that the existing logical content ordering will "just work". And adding complex rules to try to "heal" odd situations might prove to be a) difficult, and b) confusing. It might be necessary, of course, but if so, we should be able to enumerate those situations.

[melanierichards]

Thanks Mason! I like the idea of enumerating those use cases. Any concerns with porting this conversation to Open UI so that we can solicit input from web devs?

Beyond that, I think there's somewhat of a philosophical question here, i.e. to what extent should the platform prevent authors from doing silly things with a particular API? I've encountered a lot of web accessibility issues where effectively one element was visually anchored to another, but the two elements were very much separated in DOM structure. I believe that popup will actually address most of those issues (because authors were stuffing a popup in the root node to achieve top layer positioning w/o clipping), which is good. But anchor pos could also enable an author to really easily achieve a visual order that doesn't match the DOM order. So the question is, is it sufficient to tell authors "no, don't do that", or is it our responsibility to provide programmatic guardrails against mismatched content order?

Perhaps a different way to address this is to provide a more generic primitive that behaves sort of similarly to aria-flowto (hopefully with better support). An author could provide an IDREF to indicate: "hey, send focus or virtual focus to this other element next". The annoying bit about that is the author would have to maintain that attribute on the popup itself as well, unless we could provide some kind of loopback keyword.