(In reply to comment #0)

Hi Mike! Glad you decided to join the discussion :)

> As a normal person, I don't like writing out things that an engine should be
> able to automatically do for me, so the current element create and use feels
> like something that was never tested against user expecation: I expect to be
> able to do the following, for instance, rather than what the draft proposes:
> 
> Define an element in roughly the same way: <element extends="button"
> name="x-mybutton">...</element>
> 
> and then in my document, because I defined an x-mybutton element, I can now
> use *that* element. So I can do <x-button>...</x-button>. One reason is that
> it's clean - there is nothing that technically prevents this from how it
> should work; for backward compatibility we can use JS shims, and they'll
> work brilliantly. Another reason is that this is HTML code that others can
> use, too. Just include my template and off you go, you don't need to know
> what "x-mybutton" extends to use it, because that shouldn't matter. All that
> matters is that I tell you that if you're using my x-mybutton, it'll do how
> I described it.

There's something like that in the works. We need to update this intro doc to reflect the latest developments.

The actual (and more up-to-date) spec for custom elements is here: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

Unfortunately, you still won't be able to create custom tags that extend a button. See a long and sad story of why here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913

> Similarly, I shouldn't have to indicate what the JS constructor is called.
> If I define an element with name "x-mybutton", then the JS engine can pick
> up on that, and I should be able to do this:
> 
>   var newMB = new xMybutton();
> 
> I should not be responsible for defining JavaScript engine behaviour in
> HTML. Again, this is something that engines can easily automatically do.
> Just say "to support web components, the JS engine should offer a
> constructor for an element based on its camelcase name" and done, that's now
> the spec, and it'll be brilliant.

I disagree. It would turn less brilliant as soon as you need to organize your constructors into some namespace as stop polluting global namespace.

> I love the idea of web components, but the way it's drafted right now looks,
> genuinely, terrible for the general population. This draft is way more
> complicated than it needs to be, making the user responsible for a lot of
> things the HTML and JS engines can easily take care of perfectly.

This looks like a runaway rant to me. Less ranting, more specifics, please :)

That seems far more reasonable, nice! Interchangeability between <monkey> and <span is="monkey> is a nice solution.

although the "Instantiating Custom Elements" section is a bit hard to read; is omitting a constructor attribute permitted, in which case the JS engine will have built a global-scoped constructor with a sensible name for you to use, overridable with your own function if you need it? If so, no complaints. If the constructor element stays necessary, however, then I'd still suggest a spec change to allow for a default-global-override-if-you-need-to approach.

<<This looks like a runaway rant to me. Less ranting, more specifics, please :)>>

A fair point; I filed this because of genuine fear that this was (in any way) a near final draft. Consider it a sign of distress (which I guess is the best adjective to describe the feeling I got ;)

(In reply to comment #2)
> although the "Instantiating Custom Elements" section is a bit hard to read;
> is omitting a constructor attribute permitted, in which case the JS engine
> will have built a global-scoped constructor with a sensible name for you to
> use, overridable with your own function if you need it? If so, no
> complaints. If the constructor element stays necessary, however, then I'd
> still suggest a spec change to allow for a
> default-global-override-if-you-need-to approach.

That's still unspecified. Feel free to file a bug against the custom elements spec (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html) and make your opinion heard.

> A fair point; I filed this because of genuine fear that this was (in any
> way) a near final draft. Consider it a sign of distress (which I guess is
> the best adjective to describe the feeling I got ;)

You should totally help out. The intro doc (the one you're reading) was written ahead of time as a lightpath toward the actual, concrete specs and implementations. See http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1227.html for the explanation.

I have made a first pass at updating the Custom Elements section to more closely match the current Editor's Draft of the Custom Elements spec. While the explainer can only touch on topics in overview, and there is more to do, let me know if you have feedback.

<https://dvcs.w3.org/hg/webcomponents/rev/68f5a748cf54>