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

On Sat, Mar 16, 2013 at 2:29 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> On Thu, Mar 14, 2013 at 8:09 PM, Dominic Cooney <dominicc@google.com>wrote:
>
>> 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?
>>
>
> Might as well be Document, then. Why create an extra DocumentFragment,
> right?
>
>
Because it simplifies the interface for interacting with things, and means
we can possibly share the Document between some components that are same
origin in the future.

ex. Where is the component "body"? document.documentElement ? document.body
? Why are we creating a <body> and <head> on this thing? Do I need to add a
<!DOCTYPE html> ?

I'd rather like it if the spec said "the component document is a document
that's always in standards mode and has no children" and then the contents
of the component were put into a DocumentFragment.

- E

Received on Sunday, 17 March 2013 20:47:11 UTC