[webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

[Dimitri Glazkov]

On Mon, Aug 9, 2010 at 9:28 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> As Ojan indicated,
>> the use cases for DOM Mutation events are extremely limited and to me,
>> most of them feel like we should be solving them differently anyway.
>
> This is the question I'm most interested in.
>
> You say the use cases are limited. How do you know? Are you speaking about when you would use mutation events, or do you have data on when authors use them on the web? Is one of the limited use cases on a high traffic web site?

I don't have any data -- just my own intuition at this point.

> Does Mozilla share your opinion? Do others?

It would be awesome if Mozilla shared my opinion. We should hook up
with them and have a beer-laden discussion. I heard they like beer.

> I have the same questions about Ojan's claim.

Good! Let's try to answer them together.

For example, in every one of the use cases listed in Wiki, the
mutation events are  just workarounds for deficiencies of today's Web.
Just take a gander:

Keeping updated statistics of page DOM -- these are things that a
browser should do. If we have a JS developer who writes a selector
engine (for justifiable reasons, of course) -- we as browser
developers have failed our users. We should be providing this
functionality out-of-the-box.

Widgetify dynamically created markup -- this cries for a decent
behavior attachment construct.

Poor man's XBL -- dude, the title says it all.

For browser extensions (not for web page authors) -- again, we should
be solving this with allowing XBL-like behavior attachment
capabilities and certainly not mutation events.

>> However, with the introduction of extensions into Chromium and Safari,
>> DOM Mutation events experience a sort of renaissance, being used to
>> sense the DOM changes to re-apply modifications (rewrite URLs, text,
>> etc.).
>
> This is an interesting data point.
>
> If we just need an event for an extension to reapply its magic to new content, a global, asynchronous DOMContentChanged event might work.

Yes. After extensions launched, I managed to get into fixing some of
the mysterious isolated-world-related crashes and was amazed to find
out how many extensions use this anti-pattern:

document.body.addEventListener("DOMNodeInserted", function() {
process() }, false);

>
> If we introduced an API like that, and gave extensions developers time to update, we could probably remove mutation events without harming extensions.
>
> I'd like to give the same kind of consideration to data about web content.
>
>> With this in mind, I think we should do #1 and #3, then #2 after some
>> time and loud over-communication (like Inspector warnings, blog posts,
>> billboards on Hwy 101 etc.).
>
> I'm not sure this plan makes sense. If we plan to do #2 (remove mutation events), #1 (make mutation events asynchronous) may not be worth the effort.

You're probably right.

> Also, I'm not sure that the best time to remove mutation events depends on what we do (communication) -- it most likely depends on what others do (changing web content not to use mutation events, or not).
>
> On the other hand, I would be willing to chip in to see "Friends Don't Let Friends Use DOM Mutation Events" in big letters over highway 101 :).

Yes! Yes! Big Comic Sans letters! :)

> Geoff