Re: <element> Needs A Beauty Nap

Quick question: Will we still be able to land HTML Imports sans any Custom
Element reliance/support? I'd like to retain the ability to import HTML
files unbound from the parsing of <element> declarations. A significant
use-case is easily importing a bunch of <template> elements for use in the
main document - let's not throw the baby out with the bath water (maybe
this is already the thinking?)

- Daniel


On Tue, Aug 13, 2013 at 8:06 AM, Brian Kardell <bkardell@gmail.com> wrote:

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