- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Nov 2023 13:26:40 +0000
- To: public-css-archive@w3.org
None of the issues listed with the first approach strike me as huge problems, whereas the "position package" proposal introduces a likely problematic layout dependency (the "magic"), and intermediate values that can't be represented. I'm not sure that's a net win as far as "issues" go, and I'm also not sure if this _can_ be reasonably implemented, but it's an interesting direction to explore regardless. Especially if it could solve the anchor change case. I'm confused by the model as stated, however. We seem to want to do layout of the box ignoring the "position package" (to determine what goes into the package), but then also it's really the position package that has the final say for the size/position? > provisionally called position-animation I see the "provisionally", but I'd avoid anything related to "animation" in the property name. The animated aspect of this should come from the act of animating/transitioning the thing, not as an intrinsic part of the property. > split or combo I don't think we actually need to have two values. Any interpolated state (that's not at the endpoints) can automatically behave as "combo". > getComputedStyle serializes split as split, and any other computed value as combo. (This way we don't need to expose syntax or serialization of position packages, they're internal to the UA.) It feels so wrong. :-) Would this be the first thing we can't even represent with Typed OM? -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1819062672 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 November 2023 13:26:42 UTC