[webcomponents]: Building HTML elements with custom elements

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<

Received on Tuesday, 19 February 2013 23:53:07 UTC