Re: [webcomponents]: Building HTML elements with custom elements

I think you captured it well, thank you for distillation.

Perhaps one other COST of the localName issue is the question of
document.createElement.

document.createElement('x-button') creates <button is='x-button'>, people
complain because the tag names do not match.
document.createElement('button').setAttribute('is', 'x-button'), doesn't
work this way, "is" is not a standard attribute (according to me)
document.createElement('button', 'x-button'), now I cannot encode my tag in
a single variable (i.e. document.createElement(someTag))
document.createElement('button/x-button'), I just made this up, but maybe
it would work.

Scott


On Tue, Feb 19, 2013 at 3:52 PM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> Hi folks!
>
> Since the very early ages of Web Components, one of the use cases was
> implementing built-in HTML elements
> (
> http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements
> ).
>
> So, I spent a bit of time today trying to understand how our progress
> with custom elements aligns with that cooky idea of "explaining the
> magic" in Web platform with existing primitives.
>
> Here are the three things where we've found problems and ended up with
> compromises. I don't think any of those are critically bad, but it's
> worth enumerating them here:
>
> 1) For custom elements, the [[Construct]] internal method creates a
> platform object (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20831)
> and eventually, this [[Construct]] special behavior disappears --
> that's when an HTML element becomes nothing more than just a JS
> object.
>
> PROBLEM: This is a lot of work for at least one JS engine to support
> overriding [[Construct]] method, and can't happen within a reasonable
> timeframe.
>
> COMPROMISE: Specify an API that produces a generated constructor
> (which creates a proper platform object), then later introduce the API
> that simply changes the [[Construct]] method, then deprecate the
> generated constructor API.
>
> COST: We may never get to the deprecation part, stuck with two
> slightly different API patterns for document.register.
>
> 2) Custom element constructor runs at the time of parsing HTML, as the
> tree is constructed.
>
> PROBLEM: Several implementers let me know that allowing to run JS
> while parsing HTML is not something they can accommodate in a
> reasonable timeframe.
>
> COMPROMISE: Turn constructor into a callback, which runs in a
> microtask at some later time (like upon encountering </script>).
>
> COST:  Constructing an element when building a tree != createElement.
> Also, there's an observable difference between the callback and the
> constructor. Since the constructor runs before element is inserted
> into a tree, it will not have any children or the parent. At the time
> the callback is invoked, the element will already be in the tree--and
> thus have children and the parent.
>
> 3) Since the elements could derive from other existing elements, the
> localName should not be used for determining custom element's type
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913)
>
> PROBLEM: The localName checks are everywhere, from C++ code to
> extensions, to author code, and a lot of things will break if a custom
> element that is, for example, an HTMLButtonElement does not have
> localName of "button". Addressing this issue head on seems
> intractable.
>
> COMPROMISE: Only allow custom tag syntax for elements that do not
> inherit from existing HTML or SVG elements.
>
> COST:  Existing HTML elements are forever stuck in type-extension
> world (
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-type-extension
> ),
> which seems like another bit of magic.
>
> I think I got them all, but I could have missed things. Please look
> over and make noise if stuff looks wrong.
>
> :DG<
>
>