- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Oct 2022 19:33:42 +0000
- To: public-css-archive@w3.org
> The main concern I have is how this all plays with the nested transitions extension. The nested transition extension shouldn't be an issue with this. We have 2 selector options, the chaining pseudo-element syntax that you mentioned above. With nested transition, the chaining syntax would look something like: ```css ::transition::view(name)::view(name-child)::view(name-granchild)::set::old ``` Would it be fair to converge on a name with the assumption that a redundant prefix will be present depending on whether we shorter CSS functions or only the long pseudo-element chaining selector. Your comment above captures the chaining version. Same thing but with CSS function that has an extra "transition-" at the beginning: ``` html::transition html::transition-view(name) html::transition-set(name) html::transition-old(name) html::transition-new(name) ``` With nested transitions extension, html::transition-view(name) selects the corresponding view no matter where it is in the pseudo-element hierarchy. s/transition/swap or s/transition/change in the above for Alan's name options. I'm still biased towards transitions. Partly because that's the keyword used by the same functionality in JS frameworks or native platforms. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1268870649 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 October 2022 19:33:43 UTC