

<element> Needs A Beauty Nap

From: Dimitri Glazkov <dglazkov@google.com>
Date: Mon, 12 Aug 2013 16:40:14 -0700
Message-ID: <CADh5Ky2EVhMiedgLjDBL-3oCGdD0bHN4uaPD0Y95Atb3BuayUA@mail.gmail.com>
Cc: Scott Miles <sjmiles@google.com>, Steve Orvell <sorvell@google.com>, Daniel Buchner <daniel@mozilla.com>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>, Elliott Sprehn <esprehn@gmail.com>, Dominic Cooney <dominicc@google.com>
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

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.


[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
Received on Monday, 12 August 2013 23:40:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 August 2013 23:40:42 UTC