- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 May 2024 08:28:46 +0000
- To: public-css-archive@w3.org
> > It would only address the use case of animating grid positions if the underlying mechanism used for it is an SPA, with a framework that doesn't replace elements. > > This is fine. Not everyone is building an "SPA". View Transitions can be used to do nice animations for simpler changes within a web page, such as in @jensimmons's demo. Fancy counting functions and string concatenation for building out custom IDs is nice but... if you don't need them, why do we need to require them? We shouldn't require authors to use complicated mechanisms to do simple things. A lot of use cases fall in the middle between that demo and a full-blown SPA, there's no clear dichotomy. By allowing `auto` (or `element-uuid()`) we're guiding author into a "why did this stop working?" corner at some point in their development journey. In some organization the person writing the CSS and the person deciding on these frameworky underlying mechanism would not even be the same one... Since 1. the not-yet-implemented ident concatenation does solve the issue to a great extent 2. the ergonomic simple solutions are kind of a shorthand version 3. for the full-blown SPA/MPA use case we anyway need something like ident/attr, so auto/element-uuid doesn't cover the range of use-cases perhaps we should spec & implement ident+attr *first*, and defer this conversation until after we've received feedback from developers that they're too verbose for some use cases? -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2100038394 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 May 2024 08:28:47 UTC