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

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;andreubotella> TabAtkins: A while back, we resolved to make position a shorthand for position-type (setting the absolute, fixed... keywords) and position-anchor<br>
&lt;andreubotella> We've experimented since then, and the Chrome team would like to reverse this resolution<br>
&lt;andreubotella> Compat reason: we'd thought there would be a stronger compat reason to not shorthand position or other properties, but upon further review, while there's still risk, it's not that bad<br>
&lt;andreubotella> so we should consider shorthanding these older property<br>
&lt;andreubotella> we don't want to do it without a good reason because it's risky though<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/10321#issuecomment-2136102979<br>
&lt;andreubotella> Also, after some thought, we don't agree with shorthand position being part of the position shorthand<br>
&lt;andreubotella> while we have a pretty strong tradition of prefix name shorthands being shorthands for properties with the same prefix, but it's not as strong as thought<br>
&lt;andreubotella> there's a list in that thread<br>
&lt;andreubotella> THe argument from langauge design is weaker than we thought, and that strengthens the argument for not making it<br>
&lt;andreubotella> to make a reasonable shorthand out of this, you need more complex grammar, which makes it harder to use<br>
&lt;astearns> q+<br>
&lt;andreubotella> this is in the category of properties that are adjacent to other properties but shouldn't be reset together<br>
&lt;astearns> ack fantasai<br>
&lt;andreubotella> shouldn't reset, especially if you're switching from static to fixed<br>
&lt;andreubotella> so we object to making position a shorthand right now, and in particular with making position anchor a part of that shorthand<br>
&lt;andreubotella> astearns: is the complexity of the shorthand across all the value spaces, or does it only get complex when trying to set anchor positioning values?<br>
&lt;andreubotella> TabAtkins: both. The first, because anchor positioning only appliies to static or fixed, ...<br>
&lt;andreubotella> fantasai: That's not true, if you set to sticky it would ignore all of the anchor positioning stuff<br>
&lt;andreubotella> TabAtkins: I think none is one of the few obvious counterexamples, but more complex distinctions we don't do too often<br>
&lt;astearns> ack astearns<br>
&lt;andreubotella> the second bit of complexity: ... and ... are custom idents, so we'd need to make them distinguishable<br>
&lt;TabAtkins> like, `position: absolute --foo / --bar`<br>
&lt;andreubotella> explicitly setting position: absolute, maybe with container in there, and then ... gives a more readable CSS in our opinion<br>
&lt;andreubotella> fantasai: We are interested in trying to adress Chrome's concerns. We're happy with the spec as it is now until those concerns are solved, but not happy with reverting before<br>
&lt;andreubotella> florian: I agree with TabAtkins about the language not being consistent with the prefix not always being the shorthand. About position resetting all of the longhands, how important is it?<br>
&lt;andreubotella> fantasai: it depends on whether we want a shorthand that sets it together<br>
&lt;andreubotella> we'd have to design that and put it out to the whole working group<br>
&lt;andreubotella> florian: Even if the shorthand doesn't set it together, for the things that are set by position, would you have interference from the other things set by it?<br>
&lt;andreubotella> If we're reverting and leaving the issue open for now, I'm good with it<br>
&lt;andreubotella> TabAtkins: ... and inset-area being set together ...<br>
&lt;andreubotella> fantasai: That's a problem with the UA stylesheet<br>
&lt;TabAtkins> s/inset-area/insets and position-area/<br>
&lt;andreubotella> RESOLVED: undo the previous resolution and not add position-anchor and position-type to the position shorthand for now<br>
&lt;florian> s/from the other things set by it/from the other things set by it if they don't get reset<br>
&lt;fantasai> scribenick: fantasai<br>
</details>


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


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

Received on Wednesday, 4 September 2024 23:51:17 UTC