W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: <element> Needs A Beauty Nap

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 12 Aug 2013 16:45:49 -0700
Message-ID: <CANr5HFU=fk5PdZZ_UR9ZKd1jpPpKx4zaPNhOitAsegPTC5-=fg@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, 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>
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.


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
Received on Monday, 12 August 2013 23:46:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:57 UTC