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

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

From: Elliott Sprehn <esprehn@gmail.com>
Date: Mon, 11 Mar 2013 14:42:00 -0700
Message-ID: <CAPJYB1gXXkt7e75jx-xOTcT9cRFN5f64r=phiX3w_ELucYMdkw@mail.gmail.com>
To: Daniel Buchner <daniel@mozilla.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>
On Mon, Mar 11, 2013 at 2:32 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> ""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?
Yes, I already gave one. Where you go from input type="text" to input
type="range" and then stepUp() suddenly starts working.

I guess we could force people to use properties here, but that doesn't
model how the platform itself works.

An even more common example is <iframe src>. Setting a different @src value
synchronously navigates the frame. Also inserting an <iframe> into the page
synchronously loads an about:blank document.

Neither of theses cases are explained by the end-of-microtask behavior
you're describing.

- E
Received on Monday, 11 March 2013 21:43:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC