""inserted" and "removed" can probably be end of micro task, but attributeChanged definitely needs to be synchronous to model the behavior of <input type> where changing it from X to Y has an immediate effect on the APIs available (like stepUp)." Actually, I disagree. Attribute changes need not be assessed syncronously, as long as they are evaluated before critical points, such as before paint (think requestAnimationFrame timing). Can you provide a common, real-world example of where queued timing would not work? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 2:18 PM, Elliott Sprehn <esprehn@gmail.com> wrote: > On Wed, Mar 6, 2013 at 5:36 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> On 3/6/13 5:05 PM, Dimitri Glazkov wrote: >> >>> * attributeChangedCallback -- synchronously called when an attribute >>> of an element is added, removed, or modified >>> >> >> Synchronously in what sense? Why are mutation observers not sufficient >> here? > > >> * insertedCallback -- asynchronously called when an element is added >>> to document tree (TBD: is this called when parser is constructing the >>> tree?) >>> >> >> Again, why is this not doable with mutation observers? > > > "inserted" and "removed" can probably be end of micro task, but > attributeChanged definitely needs to be synchronous to model the behavior > of <input type> where changing it from X to Y has an immediate effect on > the APIs available (like stepUp). > > MutationObservers are not sufficient because childList mutations are about > children, but you want to observe when *yourself* is added or removed from > the Document tree. There's also no "inserted into document" and "removed > from document" mutation records, and since ShadowRoot has no "host" > property there's also no way to walk up to the root to find out if you're > actually in the document. (Dimtiri should fix this... I hope). > > The ready callback should probably also be synchronous (but at least it > happens in script invocation of the new operator, or after tree building), > since you want your widget to be usable immediately. > > - E > >
Received on Monday, 11 March 2013 21:33:22 UTC