- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Nov 2023 19:36:59 +0000
- To: public-css-archive@w3.org
> None of the issues listed with the first approach strike me as huge problems I think they are pretty reasonable usability issues. Nothing *technically* wrong with what's in the first post, but it's not a great layering. > a likely problematic layout dependency The second proposal is exactly identical in terms of power and layout dependency as the first. It allows literally no new abilities, save that it can interact directly with top/left/etc rather than requiring them to be packed into an inset-area value. Literally, this was intended to be *absolutely nothing* but a movement of syntax; rather than blessing inset-area as "the way to get good position animation" and relying on inset:auto to not override that (which then requires us to recreate top/left/etc in inset-area, so we can actually do the things those properties are good at), we just move the "good position animation" thing to a third property, so we can continue to use top/left/etc as normal *and* still have it interact with inset-area as necessary. If you're reading anything else into this, that's just a failure on our part to communicate it well. > 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". No, we have to have `split` because people can animate the inset properties today and get the existing not-particularly-great behavior. And if they got this by specifying `transition-property: all`, then that would apply to the new prop as well, and change their behavior. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1819682207 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 19:37:01 UTC