On Friday, September 18, 2015 at 5:09:33 AM UTC-7, smaug wrote:
> Hmm, or are you just missing childList from observerConfig.
Yeah, sorry for that! I meant to use childList.
> How would the filtering work for node removals? Would it need to run the filter right before removal?
I guess so. It the removed element matches the querySelector then yes.
> Are you thinking that querySelector filtering would map also to all the descendants of the actually added child node?
No. That's the big part that may be a big saving here. The API's I'm describing care about particular nodes, not their child nodes (unless they match the querySelector of course).
> That would be quite a big change how the API works currently. addedNodes wouldn't be about childNodes anymore, but any descendant. Would it be
> also about any removed descendants?
removedNodes, right? Yeah, I guess that's what I'm thinking. It seems to match the name - added/removed nodes that match the querySelector :)
> IIRC there were concerns selector based filtering being too slow, and also it is a higher level thing, so first
> we wanted a low level API. (one could say even attribute filtering should have been left out)
I understand. My point here is that if the API doesn't do that, customer code has to. In all scenarios where people need particular element type, they will have to filer out for them inside the MutationObserver callback.
The biggest difference from my perspective is that with querySelector you make the customer code simpler, give platform a chance to optimize the code better than customer code can and avoid firing MO callback for *every* node when in fact, there may be one element that matches the selector.
> If you want new web exposed changes to the API, better to file a spec bug
https://github.com/whatwg/dom/issues/new
> so that also other browser vendors and API users can easily comment the proposal.
Sure, will do. Wanted to check with this group first for feedback and consolidation of the idea.
> But in principle I think some kind of filtering would be nice. Implementing it for node removals would be a bit annoying in Gecko case (since our
> internal nsIMutationObserver::ContentRemoved happens after the removal) but it is doable.
Apologies for being naive, but that shouldn't be a problem, right? We're not talking here about blocking the removal, just notifying the library that an element that the library is operating on has been removed.
> However it is unclear to me what kind of performance
> characteristics we'd get - that is the main concern I have atm. (I'd like to avoid adding APIs which can be easily used in such way that it slows down
> all DOM operations dramatically.)
Yeah, I totally understand and at the same time, I'm requesting this API precisely because I believe that in the current MutationObserver API it is most likely to lead to heuristics that are wasting a lot of CPU for nothing (collect all of the nodes and fire the observer's callback just so that the callback can filter it out as irrelevant and do nothing).
I guess my biggest point here is that MutationObserver currently is designed to let customers operate on all elements of a given root, while in reality, it is used to operate on a specific, narrowly selected type of elements. If platform doesn't filter it out, then customer code does and it goes with a high cost.
I'll post to the WhatWG github.
Thanks!
zb.