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

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

--- Comment #20 from Rafael Weinstein <rafaelw@chromium.org> ---
I still want to get my head around the inserted/removed callback use cases, but
yes: I am now convinced that ready & attributeChanged should be "as synchronous
as possible".

Here are the arguments which convinced me:

-readyCallback is really a stand in for a constructor. We accepted the
constraint that the parser can't synchronously call custom element
constructors, but the requirement is an implementation constraint not a design
constraint. It's simply unreasonable to take away the invariant that the
constructor is the first method invoked on an instance of a class.

-While it's theoretically possible that readyCallback and attributeChanged can
be fully asynchronous and all accessors start by ensuring the element is
initialized and any dependent attribute changes are flushed -- This model of
custom elements is already (almost) entirely implementable using Mutation
Observers. In other words, if we thought this programming model was reasonable,
there would be no need for a custom element mechanism. The very fact that we
are discussing a mechanism which allows page script to implement DOM elements
implies that those elements implementation model should be *roughly* similar to
that of the native elements (IOW, largely synchronous).

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

Received on Wednesday, 12 June 2013 00:04:09 UTC