Re: Using readyCallback for built-in elements, was: [webcomponents]: Of weird script elements and Benadryl

On Tue, Apr 16, 2013 at 5:33 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >
> > I think we should go for one interface per element here. "abstract
> > classes" not being constructable seems fine. Node/CharacterData are
> > similar to that. This would mean HTMLH1Element, ..., of which
> > compatibility impact has not been measured.
> >
> > The other problem we need to solve is that document.createElement(<x>)
> > currently gives different results from new <x's interface>. E.g. new
> > Audio() sets an attribute, document.createElement("audio") does not. I
> > think we should settle for document.createElement("audio") also
> > creating an attribute here.
>
> What if we use the newly-found power if readyCallback here?
>
> Suppose that HTMLAudioElement has a readyCallback that, among other things
> does:
>
> if (!this.parentNode) // aha! I am created imperatively
>    this.setAttribute("controls");
>
> Several HTML elements will need to use the callback to build their
> shadow trees and set internal state, like <textarea>, <input>,
> <details>, <fieldset>, etc.
>
> If we just build readyCallback into DOM, we have cake.
>

Can someone point me to the discussion that lead to the name choice
"readyCallback"?

Thanks

Rick


>
> :DG<
>

Received on Tuesday, 16 April 2013 22:21:55 UTC