W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: What callbacks do custom elements need?

From: Daniel Buchner <daniel@mozilla.com>
Date: Mon, 11 Mar 2013 14:32:22 -0700
Message-ID: <CAHZ6zJE6wWKQwsM2LZLHhAEXr5evHtSCpLcWZMjuf=QGoRRBvQ@mail.gmail.com>
To: Elliott Sprehn <esprehn@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Dimitri Glazkov <dglazkov@google.com>, William Chen <wchen@mozilla.com>, Hajime Morrita <morrita@google.com>, Elliott Sprehn <esprehn@google.com>, Blake Kaplan <mrbkap@mozilla.com>, public-webapps <public-webapps@w3.org>, Steve Orvell <sorvell@google.com>, Scott Miles <sjmiles@google.com>
""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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT