Re: Extending Mutation Observers to address use cases of

On 02/12/2014 04:27 AM, Ryosuke Niwa wrote:
>
>> On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>
>> * Olli Pettay wrote:
>>> We could add some scheduling thing to mutation observers. By default we'd use microtask, since that tends to be good for various performance
>>> reasons, but normal tasks or nanotasks could be possible too.
>
> Right, we need some sort of a switch.  I'm not certain if we want to add it as a per-observation option or a global switch when we create an
> observer. My guy feeling is that we want the latter.  It would be weird for some mutation records to be delivered earlier than others to the same
> observer.
>

Yeah, I was thinking per observer.
Something like

var m = new MutationObserver(callback, { interval: "task"} );
m.observe(document, { childList: true, subtree: true});


Some devtools devs have asked for adding 'interval: "nanotask"' thing
I was thinking to add such thing only for addons and such in Gecko, because it brings
back some of the performance problems Mutation Events have.
But if web components stuff would be less special with such option, perhaps it should be enabled for all.




-Olli


> I'd like to know exact semantics requirements before start jumping into details though.
>
>> This sounds like adding a switch that would dynamically invalidate assumptions mutation observers might make, which sounds like a bad idea. Could
>> you elaborate?
>
> I don't really follow what the problem is. Could you elaborate on what you see as a problem?
>
> - R. Niwa
>

Received on Wednesday, 12 February 2014 12:50:22 UTC