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

Adding Blake and William, the Mozilla folks working on this. I
apologize for not thinking of you guys earlier :)

On Tue, Feb 19, 2013 at 7:01 PM, Scott Miles <sjmiles@google.com> wrote:
> 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<
>>
>

Received on Wednesday, 20 February 2013 03:04:41 UTC