[Bug 21969] [Custom]: add attributeChangedCallback to the set of prototype callbacks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21969

--- Comment #16 from Dominic Cooney <dominicc@chromium.org> ---
(In reply to comment #13)
> Dominic, Olli is correct that what you are proposing is similar to an option
> we discussed for mutation observers.
> 
> The danger with it is the same as it was for mutation observers. Think about
> it this way: the abstract danger is inviting "foreign" code to run that may
> invalidate your assumptions.
> 
> By delaying delivery until the DOM is finished, you've removed the danger
> for the (C++) DOM, but you've left page script still vulnerable.

*I'm* a huge fan of this argument. Here I'm really trying to close the loop
between implementers and web devs so I have something to go implement. But I
may have misjudged the appetite for synchronous callbacks from web devs.

> The design of mutation observers has at its core two invariants:
> 
> -When an observer is invoked, he can be sure that no other "actor" is in the
> middle of making modifications
> -When an observer wants to do further work on the DOM, he won't invite other
> observers to pre-empt him.
> 
> You're proposal does not provide either of these invariants.

Just out of curiosity if you've seen infinite chains of callbacks of battlin'
mutations in the wild?

> I'm willing to be persuaded that the use here is fundamentally different and
> therefore should be allowed to be morepowerful (and thus dangerous), but I'm
> not really seeing anyone make the case that specific uses require it.
> 
> In particular, having talked in person with Scott & Steve, it's not obvious
> to me that more synchronous semantics are actually neccessary. Steve pointed
> out that you misintepretted the meaning of his jsbin example. The point
> wasn't that it was important that the callback was synchronous. The point
> was that the callback wasn't firing at all.

If that's the case, that asynchronous is good--woohoo.

Dimitri has mentioned the "input type" use case. I think use cases like this
boil down to two things:

1. If you just need to *appear* to have responded synchronously, how onerous is
it to wrap methods and properties in things that check for changes to respond
to? At one level that is just a pain (one more thing to do.) At another level
it is tricky if you try to split up your element's reaction to state changes
(eg try to work out which API depend on the "type" attribute versus which
depend on the "disabled" attribute and process the minimal set of things you
depend on.)

2. Are there times when you really need to respond synchronously, you will kick
off some observable side-effect, it can't wait? I can't think of any use cases
like this. If there was such a case it would justify the synchronous callback.
Maybe a creative person can come up with one.

(In reply to comment #15)
> IMO, 'readyCallback' really needs to be synchronous (relative to imperative
> javscript instantiation anyway), otherwise you cannot simply make an element
> and use it.

You can. The prototype will be fixed up immediately, regardless of when the
readyCallback is fired. So just like you could takeRecords to see if your
attributes have changed, you could check some property on "this" to see if
readyCallback had run and run it.

> For the rest, I'm really torn. 
> 
> I would be happy to simply keep most everything asynchronous, but my concern
> is that users will complain and developers will start working around it.
> 
> The working around it will be messy and will bring back the
> synchrony-dragons anyway.

I didn't realize there was apathy towards making this synchronous from web
devs. In that case, let's implement the asynchronous one and get feedback from
web devs. Possible outcomes:

1. Everyone ends up using MutationObservers (so that they can do takeRecords)
and is happy => we kill the callbacks.

2. Everyone ends up using MutationObservers and is unhappy => we think about
synchronous callbacks.

3. Everyone uses the callbacks and is happy => hammocks and beverages for
everyone.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 9 June 2013 23:59:24 UTC