Re: [csswg-drafts] [css-anchor-position] `position-anchor` should be defined as a longhand of `position` (#10321)

Reopening this issue, as after doing some implementation exploration we think this is harder than originally assumed. We've also come to somewhat disagree with the original motivation entirely.

First, see <https://github.com/w3c/csswg-drafts/issues/8398#issuecomment-2123561486> for the details of what we need to do to safely shorthandify a legacy property. It's definitely not *generally* safe to do so, and we'll have to do *something* special for a property that's been a longhand as long as `position` has.

(I think we want to shorthandify `position` eventually *anyway*, regardless of what we're doing in Anchor Positioning. `position-container`, at least, is *very obviously* something that should be part of the `position` "shorthand". So this is a problem we'll need to solve, regardless of what we decide about `position-anchor`.)

Second, the *main* motivation for making `position-anchor` a longhand of `position` is just the expectation that, since `position` is its prefix, you'll expect them to have a longhand/shorthand relationship. This isn't an unreasonable expectation, but after reviewing the full list of properties, this expectation is actually broken a lot more than I thought it was:

<details>
<summary>List of `foo` vs `foo-*` properties that are *not* shorthand/longhand pairs:</summary>

* `border` (vs `border-image`, `border-boundary`, `border-collapse`, `border-clip`)
* `color` (vs `color-adjust`, `color-interpolation`, `color-rendering`, `color-scheme`)
* `contain` (vs `contain-intrinsic-*`)
* `content` (vs `content-visibility`)
* `flex` (vs `flex-direction/flow/wrap`)
* `font` (vs `font-palette`, `font-synthesis`)
* `grid` (vs `grid-row`/etc)
* `margin` (vs `margin-trim`)
* `overflow` (vs `overflow-anchor`, `overflow-clip-margin`, `overflow-wrap`)
* `position` (vs `position-try`, `position-visibility`)
* `shape` from Round Display (vs `shape-*` from Shapes)
* `transform` (vs `transform-box`, `transform-origin`, `transform-style`)

(Obtained by visually scanning <https://drafts.csswg.org/indexes/#properties>.)
</details>

(Notably, there are several other `position-*` properties *in Anchor Positioning* that we're not planning to make part of the `position` shorthand; I'm not entirely clear why `position-anchor`, specifically, is requested here.)

Usability-wise, tho, I think we actually *don't* want these to be set together. If you switch from `position: absolute` to `position: fixed`, for example, it's not clear that you'll generally want to reset `position-anchor` as well. This is especially the case as a reset-only longhand. 

Like, there's four cases that you can fall in when switching from `position: absolute` to `position: fixed` (where the `absolute` comes from less specific general styles, and the `fixed` is intended to override it in a specific case):

1. You didn't have a default anchor under `absolute` but want to add one under `fixed`: you set `position: fixed; position-anchor: --foo;` whether it's a shorthand or not.
2. You had a default anchor under `absolute` and want a *different* default anchor under `fixed`: you set `position: fixed; position-anchor: --foo;` whether it's a shorthand or not.
3. You had a default anchor under `absolute` and want the *same* default anchor under `fixed`: you have to set `position: fixed; position-anchor: --bar;` if it's a shorthand; you only have to set `position: fixed` if they're unrelated.
4. You had a default anchor under `absolute` and you don't want a default anchor under `fixed`: you get to only set `position: fixed` if it's a shorthand; you have to set `position: fixed; position-anchor: none;` if they're unrelated.

So 1 and 2 don't care, 3 is slightly better if they're unrelated, and 4 is slightly better if they're related. Between 3 and 4, I think 3 is more likely to come up, if such scenarios happen *at all*. If you just *aren't using* a default anchor (for 4), you can generally just *not mention it* and it'll act like the same as not having one at all.

(Contrast this with `position-container`, which likely does want to be set differently if you're switching between abspos and fixpos, I think. It's very appropriate to be reset by `position`, imo.)

-----------

So, we'd like to revert this resolution, and instead resolve that `position-anchor` is *not* intended to be part of a future `position` shorthand. This also gives us more time to resolve the general issues with shorthandifying a long-standing non-shorthand property, as explored in #8398, rather than having to rush that issue just for this one case.

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


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

Received on Tuesday, 28 May 2024 21:05:57 UTC