- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Sep 2024 16:21:41 +0000
- To: public-css-archive@w3.org
^ I'm ok with figuring out a way to avoid exposing generated strings. The CSS targeting being limited to view transition classes seems reasonable, we'll need something reasonable to use for pseudo element strings in script APIs (maybe just `::view-transition-*(auto)`? > auto in CSS tries to "use context to do the right thing". I think in this case reflecting the element's ID, if it has one, is pretty obviously the right thing to do given context. Wrapping functions within functions in order to be super explicit about exactly how we're doing the right thing is how programming languages work, but this is CSS: we use keywords to express concepts, and make the browser do the work. My worry with using ID if available is the subtlety of it which is so not obvious with a keyword like "auto". Someone not working on view transitions at all could add an id to a node for a completely unrelated reason and not realize the side-effect it would have on view transitions. The worst being that the ID happens to collide with an existing view transition name, resulting in a collision which is an error. @vmpstr had a good idea of namespacing auto generated vs explicit names such that the `view-transition-name: foo` won't match with `view-transition-name: auto` on an element with id `foo`. With that, I'm ok if we take this route. That said, if there's other use-cases for `ident(attr())` that will allow authors to explicitly derive the name from ID anyway, then I don't see the advantage of `auto` also doing it implicitly. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2344114034 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 September 2024 16:21:42 UTC