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.

These seem to revolve around flipping, while offset would still require `@position-try`. Is that not the case?


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

Fair, it seems that a shorthand would alleviate this, while authors could still use the longhands for composability? 

Also, an idea that was proposed during the review was what if instead of `anchor-name` one could specify a (subset of) relative selectors? That seems much more flexible, and arguably easier to understand than the current complex algorithm of finding the anchor, and the mechanism could be reused in the future by other properties that need to reference elements (e.g. `element()`). Though it would also be a much more substantial undertaking. Perhaps the feature could be designed in a way that allows for something like this to be retrofitted in later?


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

Presumably they would simply have no effect if the element is not positioned? This is not the first time this pattern is employed… Yes, it typically causes author confusion, but so does having to hunt down multiple properties to figure out why an element is or isn't displaying…


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

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