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

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov <dglazkov@google.com>wrote:

> Here's one scenario where keeping components Documents might be a good
> idea. Suppose you just built a multi-threaded parser into your renderer
> engine, and you would like to hook it up to start loading multiple
> components in parallel. How difficult will it be for you to do this if they
> were all just DocumentFragments in the same document?
>

Given that having components be parsed in the same document complicates the
specification, complicates the implementation (for example resolving
relative resources), might threaten some optimizations (multi-threaded
parsing), and gives a benefit that authors could achieve using tools to
crunch multiple component files into one, I propose that:

Each resource is loaded in its own document.

What about the type of the Component's content attribute? Should that be
DocumentFragment or Document?

Dominic


> On Mon, Mar 11, 2013 at 4:13 PM, 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.
>>
>> 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.
>>
>> The only problem is that now I have to figure out how to specify this
>> without just flat-out stealing, err... I mean reusing, large swaths of
>> HTML5 spec. But I'll take this one for the team.
>>
>> :DG<
>>
>
>


-- 
Email SLA <http://goto.google.com/dc-email-sla> •
Google+<https://plus.sandbox.google.com/111762620242974506845/posts>