- From: Daniel Buchner <daniel@mozilla.com>
- Date: Tue, 13 Aug 2013 06:15:19 -0700
- To: Alex Russell <slightlyoff@google.com>
- Cc: William Chen <wchen@mozilla.com>, Dominic Cooney <dominicc@google.com>, Blake Kaplan <mrbkap@mozilla.com>, public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>, Steve Orvell <sorvell@google.com>, Scott Miles <sjmiles@google.com>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAHZ6zJHJgKn9jBSmrbsJtfxCadmx4hha+wNgPf7T6G8gmikm6Q@mail.gmail.com>
I concur. On hold doesn't mean forever, and the imperative API affords us nearly identical feature capability. Nailing the imperative and getting the APIs to market is far more important to developers at this point. On Aug 12, 2013 4:46 PM, "Alex Russell" <slightlyoff@google.com> wrote: > 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 >> >> >
Received on Tuesday, 13 August 2013 13:15:47 UTC