I am certainly aware of existing elements that have synchronous actions triggered as a result of attribute changes. Are you specifically worried about cases where you inherit from an existing element using the is="" syntax and require immediate notification of an attribute change because you want to modify or prevent the way the native element behaves in response to native attribute changes? In retrospect, that is a valid point. Is this an instance of an important use-case/requirement colliding with a hard constraint? Can someone with more expertise on the platform side explain the options we have in addressing the case Elliot presents? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 2:42 PM, Elliott Sprehn <esprehn@gmail.com> wrote: > 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 22:36:33 UTC