Yep, that makes sense. We would be happy to adopt that as a resolution and ship the corresponding change in Chrome. Perhaps we can just call for an async resolution? Or we can try to get one at Wednesday’s meeting.

@fantasai I think you meant position-anchor being a longhand of position, not a shorthand.

The CSS Working Group just discussed [css-anchor-position] `position-anchor` should be defined as a longhand of `position` , and agreed to the following:

• RESOLVED: Make position a shorthand of position-anchor and a new position-type property. The shorthand resets both.

<flackr> astearns: this might be worth opening another issues to discover whether the pitfalls are better or worse

#8398

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 #8398 (comment) 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:

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

Let me walk through your examples with the position shorthand option:

1. You set position: fixed --foo; in a single declaration.
2. You set position: fixed --foo; in a single declaration.
3. You set position-type: fixed to switch from absolute to fixed without changing the anchor.
4. You set position: fixed which clears out all positioning properties (other than inset).

Shorthanding lets you reset everything or flip only the positioning type, whichever is appropriate to your use case.

This also gives us more time to resolve the general issues with shorthandifying a long-standing non-shorthand property, as explored in #8398

Let's dig into that issue. It's been looming over these discussions long enough.

Let's set aside the "can we even shorthandify position at this point" question. Assume we can, for the moment - I still think we shouldn't put position-anchor into it.

Looking at the wider design space, what things we'll want to put into position - at minimum, position-container will be included, which also has a dashed-ident value. So fixpos and abspos will want to be able to take two dashed-idents, and we need to tell them apart somehow. We've only got a few examples of that in shorthands so far, and they're generally not very good. For example, font separates the font-size from the line-height by requiring font-size to come first and using a / before the line-height (even if the font-size is omitted), like font: / 1.2em to set just the line-height to 1.2em.

And stickypos wants to be able to use position-container, but doesn't have a reasonable use for position-anchor; we'll want consistent syntaxes between the two keywords, so presumably position-container would be the first dashed-ident, and we'll need position-anchor to come second and hold the slash or whatever. This would make it position: fixed / --foo;, which feels weirder, since position-anchor is the more commonly useful value than position-container for abspos/fixpos; position: fixed --bar; would be easier to write but not used as much, most likely.

Beyond this smaller issue, the larger suite of anchor-pos-related properties that could potentially be folded into position also only make sense for abspos/fixpos, again meaning that we have divergent grammars for the shorthand between abspos/fixpos and relpos/stickypos. Most of our shorthands are very simple, just "any of the longhands, in any order" as a syntax; the few exceptions we have that have more specific grammars are, generally speaking, hard to use. (There's a few exceptions, like grid-template which benefits from having a specific grammar that mixes things in a 2d relationship. But font is definitely an examplar of this problem, despite being close to just being "all the longhands".)

If we were designing position today, this wouldn't be an issue, because we would never have packaged abspos/fixpos with relpos/stickypos in the first place; the two sets are completely different features. But we're stuck with the legacy mistakes we've made, and I think they constrain us sufficiently that position shouldn't become a shorthand, at least for the anchor pos properties (and generally anything that applies only to abspos/fixpos).

If the shorthanding compat issues are resolvable such that we could shorthandify position, I think it's reasonable to set position-container in it. That applies to abspos/fixpos and stickypos; its lack of applicability to relpos weighs comparatively less, imo, since relpos basically doesn't do anything anyway.

I could even see us introducing a new shorthand, designed just for abspos/fixpos, which sets position and the anchor-pos properties all together. Since it wouldn't be able to set the relpos/stickypos values, it woudln't have to worry about designing for it, so we could optimize the syntax for our use-case well. No idea what we would call it, tho. ^_^

Hi, this issue has received significant discussion within the Chrome team. Our conclusion:

Given all the compat risk, implementation difficulty and potential for developer confusion, Google doesn't think shorthand-ifying position is feasible or worth doing, so we object to doing so.

WebKit would like to take some time to understand and potentially address Chrome's concerns. To that end, we're fine with leaving the spec as-is for now (position unshorthanded). But we would appreciate a more detailed explanation of the Web-compat issues with shorthanding in #8398

The CSS Working Group just discussed [css-anchor-position] `position-anchor` should be defined as a longhand of `position` , and agreed to the following:

• RESOLVED: undo the previous resolution and not add position-anchor and position-type to the position shorthand for now

To me, the main question here is whether, when changing from one position-type to another, you get weird unexpected interference from other position-* if you fail to reset them. If so, we should make position a shorthand even if it doesn't include syntax to set them to explicit values, and it should at least reset them.

(Having syntax to set them is nice too, but if that's the challenge, I feel that can be dealt with later, including possibly never if that challenge turns out to be too hard to solve)

the main question here is whether, when changing from one position-type to another, you get weird unexpected interference from other position-* if you fail to reset them

Not particularly, no. It seems fairly unlikely, imo, that you'll switch from absolute to fixed or vice versa, which is the only case where the anchor positioning properties will continue to have an effect. If you do, I think there's a reasonable likelihood (like, roughly half the time, at least) that you do want to continue anchoring to the same element. Also if you do, there's a very high chance that you'll need to change your inset properties anyway (those seem highly unlikely to be useful with the same values in both modes), so changing more at the same time isn't unreasonable imo.

(I said in the call that changing inset and position-area together is much more likely to be the thing that we need to do, honestly. Our own devrel people keep getting confused by this issue, because the scroll adjustment relies partially on auto insets.)