Re: [webcomponents]: HTMLElementElement missing a primitive

Mostly it's cognitive dissonance. It will be easy to trip over the fact
that both things involve a user-supplied prototype, but they are required
to be critically different objects.

Also it's hard for me to justify why this difference should exist. If the
idea is that element provides extra convenience, then why not make the
imperative form convenient? If it's important to be able to do your own
prototype marshaling, then won't this feature be missed in declarative form?

I'm wary of defanging the declarative form completely. But I guess I want
to break it down first before we build it up, if that makes any sense.

Scott



On Fri, Mar 8, 2013 at 9:55 AM, Erik Arvidsson <arv@chromium.org> wrote:

> If you have a tag name it is easy to get the prototype.
>
> var tmp = elementElement.ownerDocument.createElement(tagName);
> var prototype = Object.getPrototypeOf(tmp);
>
> On Fri, Mar 8, 2013 at 12:16 PM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
> > On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles <sjmiles@google.com> wrote:
> >> Currently, if I document.register something, it's my job to supply a
> >> complete prototype.
> >>
> >> For HTMLElementElement on the other hand, I supply a tag name to
> extend, and
> >> the prototype containing the extensions, and the system works out the
> >> complete prototype.
> >>
> >> However, this ability of HTMLElementElement to construct a complete
> >> prototype from a tag-name is not provided by any imperative API.
> >>
> >> As I see it, there are three main choices:
> >>
> >> 1. HTMLElementElement is recast as a declarative form of
> document.register,
> >> in which case it would have no 'extends' attribute, and you need to make
> >> your own (complete) prototype.
> >>
> >> 2. We make a new API for 'construct prototype from a tag-name to extend
> and
> >> a set of extensions'.
> >>
> >> 3. Make document.register work like HTMLElementElement does now (it
> takes a
> >> tag-name and partial prototype).
> >
> > 4. Let declarative syntax be a superset of the imperative API.
> >
> > Can you help me understand why you feel that imperative and
> > declarative approaches must mirror each other exactly?
> >
> > :DG<
> >
>
>
>
> --
> erik
>