On Tue, May 23, 2023 at 3:46 AM Yoav Weiss <[email protected]> wrote:
> Thanks for taking that on!! > I may regret it, but thanks. > On Thu, May 18, 2023 at 9:29 PM Mason Freed <[email protected]> wrote: > >> Motivation >> >> Mutation Events have been deprecated for over a decade, with the >> replacement (Mutation Observer) available also for over a decade. The fact >> that these events are still supported in browsers makes the addition of new >> features much more difficult, prohibitively so in some cases. For example, >> these feature requests and projects are all negatively impacted by the >> existence of Mutation Events: - iFrame reparenting: >> https://github.com/whatwg/html/issues/5484 and >> https://github.com/whatwg/dom/issues/891 - Child reordering: >> https://github.com/whatwg/dom/issues/586 - DOM Parts and batch DOM >> updates: >> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md >> Given that the feature has been spec-deprecated for a decade, it makes >> sense to officially deprecate these APIs in Chrome, and work toward >> removing them. >> > > Was the impact due to the supporting these events in the code or due to > the fact that we needed to actually run them? > If we'd have to run a long deprecation trial, would that still negatively > impact the platform's evolution? > Some of both, I suppose. Supporting Mutation Events means that engineers *always* have to think about what might happen when a mutation is made, and it's easy to overlook that and create a bug. If no listeners are added by the page, then there's not much performance penalty, so actually running them only penalizes sites that use them. But these events are always hanging over new API additions, such as iframe reparenting <https://github.com/whatwg/html/issues/5484> and DOM Parts <https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md#batching-template-or-not> . It'd obviously be better to get this over quickly, but that'll be very hard. Indeed it might prove impossible. These events will continue to negatively impact the platform's evolution until we get rid of them. Interoperability and Compatibility >> >> There are technically 9 Mutation Events, but Chromium only implements 6 >> of them. Their use counters vary significantly: - >> DOMNodeInsertedIntoDocument: 0.006% - DOMNodeRemovedFromDocument: 0.012% - >> DOMCharacterDataModified: 0.016% - DOMNodeRemoved: 0.77% - >> DOMSubtreeModified: 0.81% - DOMNodeInserted: 1.58% The first three could >> likely be fairly easily removed after some time. The last three have quite >> significant usage, and more study and outreach will be required to bring >> this usage down below safe removal limits, which will take significant >> time. >> > > Turning those use counters into UKM can be interesting. > Definitely! That's on my to-do list. > Tentatively, we're aiming for M126 as the last version of Chrome that >> supports the events above, ending July 30, 2024. >> > > Are you planning to remove all of them at the same time, despite the order > of magnitude difference in usage? > I'm playing that question by ear. My guess would be that we will be able to remove DOMNodeInsertedIntoDocument, DOMNodeRemovedFromDocument, and DOMCharacterDataModified more quickly than the other three. If their usage falls low enough at some point, I'll come back here for approval to remove them sooner. *Gecko*: No signal ( >> https://github.com/whatwg/dom/issues/305#issuecomment-241686139) Old >> comments indicate support, but no official position yet. >> >> *WebKit*: No signal >> > > Can we file for positions? A joint effort could help here. > Yep! Here are Mozilla <https://github.com/mozilla/standards-positions/issues/807> and WebKit <https://github.com/WebKit/standards-positions/issues/192> position requests. I'm hoping they'll be supportive and perhaps we can jointly remove the APIs, or at least work together. Other suggestions would always be appreciated. Thanks, Mason > >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Flag name >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/1446498 >> >> Estimated milestones >> Shipping on desktop 127 >> Shipping on Android 127 >> Shipping on WebView 127 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5083947249172480 >> >> Links to previous Intent discussions >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgP1mWEoDABHmKfCXSSFO9ZyQDQ5p7h_TtN51ZnyvxSSg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgP1mWEoDABHmKfCXSSFO9ZyQDQ5p7h_TtN51ZnyvxSSg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjOAhyVYMuWjL3ks_CVfP-i95nvPjDjT5hsERLsDY5JXA%40mail.gmail.com.
