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

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

--- Comment #18 from Dominic Cooney <dominicc@chromium.org> ---
(In reply to comment #17) 
> > 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.

OK. I misinterpreted the "really torn" part. It seems like there's confusion,
see Comment 13, "In particular, having talked in person with Scott & Steve,
it's not obvious to me that more synchronous semantics are actually neccessary.
(sic)"

Raf, Olli, are you convinced?

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

I have a sinking fear that if you want to be really robust you will need to do
that anyway. If you have a dozen custom elements in the tree, we're going to
fire that callback one at a time. Therein lies opportunity for misadventure.

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

Because if the callbacks are asynchronous, but what web devs really need is to
appear synchronous, they are going to switch to MutationObservers so that they
can call takeRecords to eagerly grab and process the mutations they need to
respond to.

This is down in the weeds, but do you think readyCallback and attributeChanged
need to be synchronous, but insertedCallback and removedCallback could be
asynchronous?

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

Received on Tuesday, 11 June 2013 01:45:52 UTC