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

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

--- Comment #17 from Scott Miles <sjmiles@chromium.org> ---
I think there has been a fairly dramatic miscommunication. :/

> 1. If you just need to *appear* to have responded synchronously

While I believe this is possible, it's completely onerous for the developer.

> 2. Are there times when you really need to respond synchronously

Not in terms of achieving correctness, but yes in terms of user ergonomics.

> I didn't realize there was apathy towards making this synchronous from web devs.

The is the opposite of what I tried to say. I believe it would *theoretically*
be possible to have a world where all these effects are asynchronous, and force
web developers to adapt, but the expect the reality of the situation is that
there would be a tremendous hew and cry and effigy-burning. 

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

That's the opposite of 'you can'. A user is not going to do those steps, and
the only way to make the component do it is to gate all the accessors and have
an 'ready before ready' fixup step, which is a non-starter. To require
something like this is to completely gum-up the component lifecycle.

> 1. Everyone ends up using MutationObservers

I don't understand this bit. Unless you simply do not provide callbacks, why
would anybody use MutationObservers to do the same work?

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

Received on Monday, 10 June 2013 02:38:03 UTC