W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: Making <link rel="components"> produce DocumentFragments

From: Scott Miles <sjmiles@google.com>
Date: Wed, 13 Mar 2013 21:08:02 -0700
Message-ID: <CAHbmOLZp6cmPVYksL18eBvHYeTZKe+ShwP2cD=9+py+214CHCw@mail.gmail.com>
To: Dominic Cooney <dominicc@google.com>
Cc: Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>
Developers will absolutely concat components together, often the entire
apps worth. They will also use them separately. This flexibility is one of
the great strengths of this simple concept.

As Dimitri mentioned, Web Components solves a great many of the loader
issues (both at development and production time) that currently plague
developers and have a fragmented solution space.

Fwiw I posted a bug to address some of the script and load-order questions:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21229

Scott


On Wed, Mar 13, 2013 at 8:08 PM, Dominic Cooney <dominicc@google.com> wrote:

>
>
>
> On Thu, Mar 14, 2013 at 5:14 AM, Dimitri Glazkov <dglazkov@google.com>wrote:
>
>>
>>
>>
>> On Tue, Mar 12, 2013 at 10:20 PM, Dominic Cooney <dominicc@google.com>wrote:
>>
>>> On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>
>>>> Hi folks!
>>>>
>>>> Just had a quick discussion with Elliott and he suggested that instead
>>>> of building full-blown Documents, the <link rel="components"> just make
>>>> DocumentFragments, just like <template> does.
>>>>
>>>
>>> I am confused by what you are proposing here.
>>>
>>> Templates "produce" document fragments in the sense that the
>>> HTMLTemplateElement's content attribute is a DocumentFragment.
>>>
>>> On the other hand, templates use full-blown documents in the sense that
>>> "the template contents owner is a document which does not have a browsing
>>> context." <
>>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions
>>> >
>>>
>>>
>>>> Looking at
>>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object and
>>>> the bunch of APIs that will never be useful on a document without a
>>>> browsing context, I think it's a pretty good idea. It should make also
>>>> components more lightweight.
>>>>
>>>
>>> It you are proposing to make the Component interface's content attribute
>>> a DocumentFragment, I think that is OK. It does not make the components any
>>> lighter, because component.content.ownerDocument will inevitably point to
>>> that other document.
>>>
>>> Could you provide a more specific proposal? I don't understand what
>>> you're proposing here.
>>>
>>
>> Just like in HTML templates, you don't have to have a distinct document
>> for each component. They could share the same document. In fact, it might
>> be nice for both templates and components to all share the same document.
>>
>
> Now I understand.
>
> The concerns about resource resolution are tricky ones and having a
> separate document sounds straighforward.
>
> What is the plan for inline scripts in the linked file? Is it possible for
> components to have a top-level <script> which does some setup? If so,
> running script in a document fragment seems a bit weird.
>
> I think this in part depends on whether you think web apps will crunch
> their components into few files or not because the benefit of a shared
> document is limited if there are fewer components. There are reasons for
> developers to crunch components (minimize latency as with CSS spriting,
> script concatenating, and stylesheet merging) or not (it is an extra step;
> lazy loading wants multiple files anyway; SPDY will ameliorate the latency
> problem anyway; loading components from separate third-party sites).
>
> Dominic
>
> --
> Email SLA <http://goto.google.com/dc-email-sla>  Google+<https://plus.sandbox.google.com/111762620242974506845/posts>
>
Received on Thursday, 14 March 2013 04:08:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT