[Bug 22459] [Custom]: Consider explicitly emptying callback queue in more cases

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

--- Comment #5 from Dominic Cooney <dominicc@chromium.org> ---
(I started this on bug 22426 but I think it is more relevant here:)

I think callback-queue-draining is a blunt instrument that will make web
developers miserable.

Is it not reentrant? Then you basically have to code for the asynchronous case
anyway, because there might be another lifecycle dispatch loop operating at the
top level--it would be simpler to just make everything asynchronous.

Is it reentrant? Then you get consistency problems where you can't trust some
callbacks that are stale because the stack is unwinding.

(Aside: One way you could avoid a lot of teh suck with reentrancy is not to
provide the state in the callback, but just notify that the state changed. For
example instead of inserted and removed as separate callbacks, just one
callback that says "in document may be different." Instead of attribute values,
one callback that says "this attribute may have a different value." Then the
element can poll. It may even make sense to coalesce changes that have not been
delivered yet.)

Here's my thinking.

A custom element's "affect" (behavior, appearance, etc.) depends on its state,
which includes:

- Whether it is in the tree.
- What its attributes are.
- JavaScript state (eg in properties).

(Interestingly what is *not* included here is the state of the tree around the
custom element. That can be observed, and changes reacted to with Mutation
Observers, but you're not proposing any new behavior, and no synchronous
behavior, related to that.)

We desire custom elements that, when their state changes, their "affect" is
immediately changed.

One observation is that the most important "affect" is how a custom element
appears to script--its JavaScript properties, and what its methods do.

What about this:

Each custom element has its own lifecycle callbacks queue. There's a method to
flush the queue. And maybe there's sugar, in the spec or provided by
frameworks, to wrap the methods and properties of a custom element which flush
that queue.

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

Received on Wednesday, 26 June 2013 02:13:24 UTC