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

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov <>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?


> On Mon, Mar 11, 2013 at 4:13 PM, Dimitri Glazkov <>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
>> 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 <> •

Received on Friday, 15 March 2013 03:10:06 UTC