Re: Extending Mutation Observers to address use cases of

I pushed the Web Components folks about exactly this issue (why aren't
these callbacks just MutationObservers?) early last year. They convinced me
(and I remain convinced) that these signals should be Custom Element
callbacks and not Mutation Observer records

Here's the logic that convinced me: Custom Element are a *strongly coupled
concern*, while Mutation Observers *allow for* multiple decoupled concerns
to peacefully co-exist.

In a certain sense, you can extend the argument that CE callbacks should be
MO records, and you arrive at the conclusion that you don't need Custom
Elements at all -- that everything can be implemented with Mutation
Observers. But the point of Custom Elements is two fold:

1) To allow implementation of Elements by user-space code in roughly the
same model as privileged code.
2) To explain the platform.

Put another way: the *implementation* of an element simply needs to be
privileged in some respects. For custom elements, this means

a) There can only be one. I.e., we don't allow multiple registration of the
same element: Primary behavior is the domain of custom elements, secondary
behavior is the domain of Mutation Observers
b) Callbacks need to fire ASAP. It's important that the implementation of
an element get a chance to respond to events before other concerns so that
it can create a synchronously consistent abstraction

To my mind, Custom Elements callbacks really *should* be fully sync (yes,
including firing createdCallback during parse), but various technical and
security constraints make that impossible.

In short, Custom Elements and Mutation Observers are servicing very
different needs. Custom Elements are privileged, but limited and singular
(I can only react to changes in myself and I'm the only responding party),
while Mutation Observers are unprivileged, pervasive and multiple (I get to
respond to anything in the document, and there are likely other parties
doing work in the same place I am).

Therefore, it is neither a good idea to make Custom Elements more async,
nor a good idea to make Mutation Observers more sync.

---

One final note. UNRELATED to custom elements' implementation.

I think there's an argument to be made that Mutation Observers *should* be
extended to allow for observation of trees which include DOM reachable
through shadowRoots. The motivation for this would be to allow existing
de-coupled concerns to operate faithfully in the presence of custom
elements implemented with shadowDOM. The obvious concern here is that
de-coupled code may interfere with the implementation of elements, but
that's no more true with custom elements than it is today, and shadowRoot
is imperatively public, it's consistent to allow MutationObservers to
continue to fully observe a document.

However, I don't think there's any rush to do this. Just something to think
about for a post-shadowDOM world.


On Wed, Feb 12, 2014 at 4:49 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> 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
>>
>>
>
>