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

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

That is indeed already possible, by using the `flip-*` keywords in `position-try-options`. You only need to reach for the `@position-try` rule if you're doing non-trivial alternatives.
 
> 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?

Yes, the syntax is open for extension to other triggers. For example, a use-case we've already identified that might want to get solved in level 2 is providing a fallback for when your anchors aren't valid (like `position-visibility`'s trigger, but with options besides just hiding the element).
 
> 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.

By this do you mean anchoring to the mouse pointer, or having, like, popups with a little arrow on their edge pointing to the anchor, or something else?
 
> 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?

The big design consideration here is not whether or not they'd use different names, but whether they'd be set by the same code/authors at all. CSS in general has a problem with "additive" features, where two different selectors might want to set different (combinable) keywords in a single property. (This is one of the reasons we designed the individual transform properties, for example; it helps avoid clashes in at least some cases.) 

If we had a single property that handled the definition of names across multiple features, it's almost certain authors would run hard into this issue. The current design (across several specs) avoids that when the different bits of code are using different features, at the cost of repetitious design. I think the status quo is the best option at the moment, including as we design future features that need more names.

That said, nothing stops us from adding a shorthand covering them all in the future.

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

It was not part of our initial implementation, but it's being added now.

The effect of the property is well-defined in its description, and imo didn't need to be restated in the anchor-finding algo. Hm, you are right that it would aid clarity to mention it in the "acceptable anchor element" definition, tho. I'll fix that.

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

There already was an explanatory note there, but it was at the end of the algorithm and not the most obvious. I've shifted it to a more visible spot and slightly rephrased it so it should read a little better.

> 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-*`.

"Anchor" isn't a positioning scheme on its own; it's just a new capability added to existing positioning schemes. All the `position-*` properties defined in this draft do, in fact, apply at least somewhat even if nothing anchor-related is used at all. (They're generally *less useful*, as both 'position-visibility' and 'position-try-*' are about managing overflow, and that's mostly a concern when using anchors due to the substantially more dynamic placement options, but they still *can* be used without any anchoring going on.)

(Well, not `position-anchor`, but that already satisfies your comment.)

> * `position-visibility` affects visibility, not position. Therefore, we wondered if a `visibility` value may have been more appropriate.

The feature may not *affect* position, but it is *based* on it - all the non-initial values depend on the element being a positioned element. It's *possible* to have a property with some keywords that apply generally and some that apply only for certain types of elements, but it's often a slightly clumsy design as you have to define what the specialized keywords fall back to on invalid targets.

> * Why is this layered on top of `position: absolute` and `position: fixed` rather than a new `position: anchor` behavior?

Putting aside the bad design of the `position` property itself for a moment (the rel/sticky behaviors and abs/fixed behaviors are completely distinct layout modes, and shouldn't have been mixed), there was simply no need. This is an upgrade to the "absolute positioning" feature, which is triggered by `absolute` or `fixed`. It adds new options to that layout mode, but doesn't need or want to fundamentally change how it works.

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

The behavior difference is solely what containing block is used. There was no need to invent a new property duplicating that behavior switch. The CB has some implications on how anchoring works, such as what elements are valid anchors, but those implications are *fully* captured by the CB choice itself, and so `absolute` vs `fixed` is already the most appropriate way to do that. If we want any *more* CB options, we'll want them generally for positioned elements, so it wouldn't be an anchor-specific feature either.


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

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