Re: <element> Needs A Beauty Nap

On Tue, Aug 13, 2013 at 9:15 AM, Daniel Buchner <daniel@mozilla.com> wrote:

> 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
>>>
>>>
>>

+1 - this is my preferred route anyway.  Concepts like register and shadow
dom are the core elements... Give projects like x-tags and polymer and even
projects like Ember and Angular some room to help lead the charge on asking
those questions and helping to offer potentially competing answers -- there
need be no rush to standardize at the high level at this point IMO.

-- 
Brian Kardell :: @briankardell :: hitchjs.com