Re: <element> Needs A Beauty Nap

As discussed face-to-face, I agree with this proposal. The declarative form
isn't essential to the project of de-sugaring the platform and can be added
later when we get agreement on what the right path forward is. Further,
<polymer-element> is evidence that it's not even necessary so long as we
continue to have the plumbing for loading content that is HTML Imports.

+1


On Mon, Aug 12, 2013 at 4:40 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> tl;dr: I am proposing to temporarily remove declarative custom element
> syntax (aka <element>) from the spec. It's broken/dysfunctional as
> spec'd and I can't see how to fix it in the short term.
>
> We tried. We gave it a good old college try. In the end, we couldn't
> come up with an <element> syntax that's both functional and feasible.
>
> A functional <element> would:
>
> 1) Provide a way to declare new or extend existing HTML/SVG elements
> using markup
> 2) Allow registering prototype/lifecycle callbacks, both inline and out
> 3) Be powerful enough for developers to prefer it over document.register
>
> A feasible <element> would:
>
> 1) Be intuitive to use
> 2) Have simple syntax and API surface
> 3) Avoid complex over-the-wire dependency resolution machinery
>
> You've all watched the Great Quest unfold over in public-webapps over
> the last few months.
>
> The two key problems that still remain unsolved in this quest are:
>
> A. How do we integrate the process of creating a custom element
> declaration [1] with the process of creating a prototype registering
> lifecycle callbacks?
>
> B. With HTML Imports [2], how do we ensure that the declaration of a
> custom element is loaded after the declaration of the custom element
> it extends? At the very least, how do we enable developers to reason
> about dependency failures?
>
> We thought we solved problem A first with the "incredible this" [3],
> and then with the "last completion value" [4], but early experiments
> are showing that this last completion value technique produces brittle
> constructs, since it forces specific statement ordering. Further, the
> technique ties custom element declaration too strongly to script. Even
> at the earliest stages, the developers soundly demanded the ability to
> separate ALL the script into a single, separate file.
>
> The next solution was to invent another quantum of time, where
>
> 1) declaration and
> 2) prototype-building come together at
> 3) some point of registration.
>
> Unfortunately, this further exacerbates problem B: since (3) occurs
> neither at (1) or (2), but rather at some point in the future, it
> becomes increasingly more difficult to reason about why a dependency
> failed.
>
> Goram! Don't even get me started on problem B. By far, the easiest
> solution here would have been to make HTML Imports block on loading,
> like scripts. Unlucky for us, the non-blocking behavior is one of the
> main benefits that HTML Imports bring to the table. From here, things
> de-escalate quickly. Spirits get broken and despair rules the land.
>
> As it stands, I have little choice but to make the following proposal:
>
> Let's let declarative custom element syntax rest for a while. Let's
> yank it out of the spec. Perhaps later, when it eats more cereal and
> gathers its strength, it shall rise again. But not today.
>
> :DG<
>
> [1]:
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-create-custom-element-declaration
> [2]:
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html
> [3]:
> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0152.html
> [4]:
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-last-completion-value
>
>