- From: Jessica Janiuk via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Oct 2023 22:07:10 +0000
- To: public-css-archive@w3.org
I think the biggest thing here to me is that this addresses a developer need. As @LeaVerou pointed out, writing the code to handle element removal, even with a view transition, is not just a single line, and that code ends up having to be used everywhere an element is removed. That includes the overhead of adding an event listener for `onanimationend` and then the removal / garbage collection of it afterwards. If someone chooses to use a `setTimeout` instead, they have to match their CSS's duration and keep them in sync. And with a view transition, you have to match identifiers between JS and CSS. `@exit-style` would effectively eliminate all of that extra code. Yes, frameworks and libraries can obfuscate this so users don't have to write it, but that means we're shipping that removal javascript along in everyone's bundle sizes, and we're still dealing with overhead of the event listener. We're constantly looking for ways to shave off as much as we can from bundle sizes as we can. So if we can eliminate the need to have code to handle the removal, that would be ideal for us in the framework space. And of course, the symmetry of `@starting-style` and `@exit-style` is really nice and very discoverable for what it does. That's obviously not a strong reason for adopting it, but it is a nice bonus. -- GitHub Notification of comment by jessicajaniuk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1786121131 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 October 2023 22:07:11 UTC