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 <[email protected]> wrote: > On Wed, Aug 17, 2011 at 5:39 PM, Dominic Cooney <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
