[webkit-dev] Replacing DOM Mutation Events

Adam Klein adamk at chromium.org
Fri Sep 23 14:35:12 PDT 2011


An update:

After further prototyping on the previously-posted patch, and much
discussion with developers from Mozilla, we've solidified on an API.
We've proposed it under the name "Mutation Observers" to
public-webapps in
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html.
 If you're interested in discussing details of that proposal, that
thread is the place to do it.

Meanwhile, I plan to get started on implementing that API
(vendor-prefixed, behind an ENABLE flag) in WebKit.  My first step
will be to add a flag, "ENABLE_MUTATION_OBSERVERS", and then begin
uploading implementation patches in small chunks.  I've opened a
meta-bug at https://bugs.webkit.org/show_bug.cgi?id=68729, and aim to
coordinate the various pieces by making them block that bug.

Cheers,
- Adam

On Thu, Aug 18, 2011 at 9:41 AM, Adam Klein <adamk at chromium.org> wrote:
> On Wed, Aug 17, 2011 at 5:39 PM, Dominic Cooney <dominicc at chromium.org> wrote:
>> This looks awesome.
>>
>> Do you have a link to Jonas‘ latest proposal? Because the original one
>> you linked to <http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html>
>> seems to be different to your patch (eg in API names, etc.) The
>> asymmetry between addMutationListener, which can incrementally
>> register for specific types, and removeMutationListener, which is a
>> blunt instrument, is curious… I would like to read the specific
>> proposal.
>
> This is the proposal mine is based on (it's also linked from the
> ChangeLog in my patch):
>
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0369.html
>
> Note that I say "based on"; the biggest divergence is that I don't do
> any coalescing of mutations, so:
>
> node.appendChild(...)
> node.appendChild(...)
> node.appendChild(...)
>
> will result in a MutationRecordList with three MutationRecords, one
> for each of those called. This makes the implementation simpler than
> it would be otherwise, and allows MutationRecords to be 1) immutable
> and 2) shared by all MutationListeners.
>
>> It would be nice if there was an open source test suite that is easily
>> accessible to UA implementors to ensure implementations are
>> consistent.
>
> Agreed, though we'll want to move a little closer together before we
> get there (discussion is still ongoing about details of the API).
>
> - Adam
>
>> Dominic
>>
>> On Wed, Aug 17, 2011 at 11:07 AM, Adam Klein <adamk at chromium.org> wrote:
>>> Greetings webkit-dev,
>>>
>>> It's generally agreed upon in the web community, and in WebKit
>>> specifically, that DOM Mutation Events are a bad thing. See, e.g.,
>>> discussion on https://bugs.webkit.org/show_bug.cgi?id=8191 (relating
>>> to DOMAttrModified, and why WebKit does not wish to implement it) and
>>> https://lists.webkit.org/pipermail/webkit-dev/2010-August/013805.html
>>> (a discussion of replacing DOM mutations with something better, or
>>> removing them entirely).
>>>
>>> In late June, Jonas Sicking and Olli Pettay from Mozilla put forward
>>> proposals on public-webapps
>>> (http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html)
>>> to replace mutation events with a different API, one that avoids the
>>> problems associated with the existing spec.
>>>
>>> Rafael Weinstein has helpfully summarized the public-webapps thread
>>> (which is now upwards of 200 messages long) in
>>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html,
>>> and discussion is ongoing in
>>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
>>> Any WebKit folks interested in the future of mutation events in the
>>> DOM are invited to join that discussion, and their input would be much
>>> appreciated.
>>>
>>> I've also put together a partial implementation of Jonas' most recent
>>> proposal and uploaded my
>>> work-in-progress patch to
>>> https://bugs.webkit.org/show_bug.cgi?id=66079. Note that this is very
>>> early work, and if I were submitting it for review it would be in much
>>> smaller chunks, but I welcome any comments or questions on the code
>>> as-is.
>>>
>>> - Adam
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>


More information about the webkit-dev mailing list