Re: [w3ctag/design-reviews] Specification review for CSS Anchor Positioning (Issue #848)

This looks like a generally useful feature to have, addressing a host of prominent author pain points.

Discussions on blink-dev suggest that there might not be WG consensus on the maturity of the specification. The recently-opened issues also indicate some unresolved questions.

Regarding the design of the feature, our biggest concern is that it focuses on making complex things possible, but doesn't sufficienly make simple things easy. We think the simple cases of a popup that merely shifts or flips its position be always visible should not require a separate `@position-try` rule or writing out the logic, authors should be able to declare intent and have things Just Work™. Otherwise, this is prone to the same bugs as hand-rolled implementations, it's just that the bugs will now live in CSS, not JS. For example, a popular library for this sort of thing is https://floating-ui.com/ (but there are many more). Notice how [flipping](https://floating-ui.com/docs/flip) and [shifting](https://floating-ui.com/docs/shift) are high level abstractions, rather than something authors have to specify in detail. If these >80% use cases are covered by simple declarations, things like `@position-try` could be reserved for L2, so they can be more fully baked, and informed by actual usage.

Regarding position fallbacks, it currently seems that what triggers a fallback is overflow, with no way to specify additional triggers. Is there planning for authors being able to customize the trigger in the future?

Instead of focusing customizability efforts around niche positioning use cases, we’d love to see more work towards making it possible to specify pointers, which seem so common we worry about the use case coverage of an anchor positioning feature without *some* way to achieve them.

We understand the rationale for using `anchor-name` instead of HTML ids (e.g. scoping, markup edits), but we are concerned that new properties are being added to name elements in (likely) the same way. For example, there is currently `container-name`, which also names an element. Is it common for these names to need different identifiers? If so, would it make sense to have a shorthand (e.g. `name`) of all CSS properties that name an element?

`anchor-scope` does not appear in the explainer(s) and does not appear to feature in the algorithm that finds an anchor.

The [algorithm for finding anchors](https://drafts.csswg.org/css-anchor-position-1/#target) is quite complex. That is not necessarily an issue, internal complexity is often necesary to avoid external (author-facing) complexity, however the motivation needs to be explained more.

Some other notes on the current syntax:
- Properties that are unlikely to ever apply to position schemes beyond anchor should make this clear by being prefixed via `position-anchor-*` (or just `anchor-*`), not just `position-*`.
- `position-visibility` affects visibility, not position. Therefore, we wondered if a `visibility` value may have been more appropriate.
- Why is this layered on top of `position: absolute` and `position: fixed` rather than a new `position: anchor` behavior?
- It's not clear what the implications of using `position: absolute` vs `position: fixed` are. Perhaps the behavior difference would be better handled by an anchor-specific property.

Interactions with shadow DOM are not covered by the explainers (though they are in the specification).

Finally, we're concerned about the status of the explainer relative to the Chromium blog post. In general, we'd like to see an explainer, that starts with articulated user need, as a separate document that is written along side of the spec, and is kept up-to-date as the spec changes. The explainer thereby can become the seed for developer documentation when that's required. See https://tag.w3.org/explainers.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/848#issuecomment-2127911285
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/848/2127911285@github.com>