- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 16:33:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position] position-area specified vs. computed value is weird`, and agreed to the following: * `RESOLVED: close no change` <details><summary>The full IRC log of that discussion</summary> <ydaniv> emilio: position-area has no reason for changing its computed value, and what we're doing is weird<br> <ydaniv> ... I have a preference if it both are consistent<br> <ydaniv> TabAtkins: right now the position-area is logical, and we do a canonicalization of speicifc set of keywords<br> <ydaniv> ... emilio says we can do that early so it's always in the right form<br> <ydaniv> ... we propose we leave that alone in a number of properties<br> <ydaniv> ... the big thing is we don't do canonicaliztion at compute value time<br> <ydaniv> ... I'm leaning against this<br> <ydaniv> fantasai: same position as TabAtkins, and current rules are what's implemented at WebKit<br> <ydaniv> astearns: and Gecko<br> <ydaniv> emilio: I'm ok with no change<br> <ydaniv> PROPOSED RESOLUTION: close no change<br> <ydaniv> astearns: objections?<br> <fantasai> [Tab pointed out that this allows authors to interact with the value as they specified is]<br> <ydaniv> RESOLVED: close no change<br> <fantasai> s/is/it/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12759#issuecomment-3779464931 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 16:33:37 UTC