Re: [webcomponents]: First stab at the Web Components spec

[Anne van Kesteren]

On Mon, Mar 18, 2013 at 10:46 AM, Tab Atkins Jr.  wrote:
> On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost  wrote:
>> Do you plan to allow the HTTP counterpart?
>>
>> Link: ; rel=component
>
> Does that need to be "allowed"?  I thought the Link header was just
> equivalent, in general, to specify a  in your head.

But it's not entirely clear we want to support HTTP Link long term
yet, so yes. And I  think that no, we don't want to do that for now as
the web platform has no dependency on HTTP Link thus far.


-- 
http://annevankesteren.nl/

Re: [webcomponents]: First stab at the Web Components spec

[Tab Atkins Jr.]

On Mon, Mar 18, 2013 at 7:51 AM, Brian Kardell  wrote:
> On Mar 18, 2013 10:48 AM, "Tab Atkins Jr."  wrote:
>> On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost  wrote:
>> > Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit :
>> >> Here's a first rough draft of the Web Components spec:
>> >>
>> >> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
>> >
>> > Cool.
>> >
>> > I see
>> >
>> > 
>> >
>> > Do you plan to allow the HTTP counterpart?
>> >
>> > Link: ; rel=component
>>
>> Does that need to be "allowed"?  I thought the Link header was just
>> equivalent, in general, to specify a  in your head.
>
> Just bringing this up on list as it has come up in conversations offlist:
> while not currently valid.for htmk, link for Web components will work in the
> body too? #justcheckin

Again, I don't think that's something anyone gets a choice on.  HTML
defines how -in- works, iirc.

~TJ

Re: [webcomponents]: First stab at the Web Components spec

[Brian Kardell]

On Mar 18, 2013 10:48 AM, "Tab Atkins Jr."  wrote:
>
> On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost  wrote:
> > Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit :
> >> Here's a first rough draft of the Web Components spec:
> >>
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
> >
> > Cool.
> >
> > I see
> >
> > 
> >
> > Do you plan to allow the HTTP counterpart?
> >
> > Link: ; rel=component
>
> Does that need to be "allowed"?  I thought the Link header was just
> equivalent, in general, to specify a  in your head.
>
> ~TJ
>

Just bringing this up on list as it has come up in conversations offlist:
while not currently valid.for htmk, link for Web components will work in
the body too? #justcheckin

Re: [webcomponents]: First stab at the Web Components spec

[Tab Atkins Jr.]

On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost  wrote:
> Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit :
>> Here's a first rough draft of the Web Components spec:
>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
>
> Cool.
>
> I see
>
> 
>
> Do you plan to allow the HTTP counterpart?
>
> Link: ; rel=component

Does that need to be "allowed"?  I thought the Link header was just
equivalent, in general, to specify a  in your head.

~TJ

Re: [webcomponents]: First stab at the Web Components spec

[Karl Dubost]

Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit :
> Here's a first rough draft of the Web Components spec:
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html

Cool.

I see
 


Do you plan to allow the HTTP counterpart?

Link: ; rel=component



-- 
Karl Dubost
http://www.la-grange.net/karl/

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Wed, Mar 13, 2013 at 5:41 AM, Anne van Kesteren  wrote:

> On Tue, Mar 12, 2013 at 4:53 PM, Dimitri Glazkov 
> wrote:
> > Yup, been doing this for a while now. The stylesheet-like behavior seems
> to
> > have settled as the least evil of the compromises. It's an
> over-constrained
> > problem, as usual :)
>
> If applications have issues with performance because of this today,
> how is increasing the number of external resources that exhibits this
> behavior going to help?
>

I am glad you're asking this question. It's been burning in the back of my
head for years now and I haven't gotten many good answers.

If we make components load completely asynchronously, we will have the
problem of creating instances of custom elements whose definitions haven't
loaded yet. The only solution to that problem is element upgrade (that is,
the equivalent of renameNode), and it will most definitely eat all (and
more) of your performance gains from asynchronous loads.

At least, with stylesheet-like load, a webdev can use good judgement and
take advantage the fact that the components are fetched and processed
asynchronously.

The sad truth is that most apps will probably choose to inline most (if not
all)  component documents into the master document for their production
builds. At this point, I am primarily hoping to help in 2 ways:

1) make it possible to achieve nice modularity in a development (or any
other non-mission critical) build, so that the webdevs don't need to use
complex and varying packaging shims that often use document.write and other
crazy hacks to get the right behavior;

2) make inlining as close to just concatenating files as possible.


>
> What's the scenario if there's a 

Re: [webcomponents]: First stab at the Web Components spec

[Dominic Cooney]

On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles  wrote:

> My issue is that the target of this link will not in general be an atomic
> thing like a 'component' or a 'module'. It's a carrier for resources and
> links to other resources. IMO this is one of the great strengths of this
> proposal.
>

To go on the record: I like link rel="component" and calling these
components.

Initially I was confused too; I have heard people casually refer to custom
elements as "components." But it makes sense to treat these are discrete
concepts:

Components are the units of reuse. Although they're not "atomic" they
should ideally be a usable unit which references all of its dependencies.

Custom elements are the units of instantiation. One component may contain
be comprised of many custom elements.


> For this reason, when it was rel="components" (plural) there was no
> problem for me.
>
> Having said all that, I'm not particularly up in arms about this issue.
> The name will bend to the object in the fullness of time. :)
>
> S
>
>
> On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn  wrote:
>
>>
>> On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton 
>> wrote:
>>
>>> Personally, I had no objection to rel="component". It's similar in
>>> usage to rel="stylesheet" in the fact that it's descriptive of what you're
>>> linking to.
>>>
>>> On the other hand, rel="include" is very broad. It could just as easily
>>> apply to a stylesheet as a Web component, and may limit the usefulness of
>>> the term if/when future rel values are introduced.
>>>
>>> (p.s. I'm new to this list and haven't read through all the previous
>>> discussions on Web components. Feel free to disregard this comment if I'm
>>> rehashing old topics)
>>>
>>>
>>>
>> +1, I like rel="component", document or include doesn't make sense.
>>
>> - E
>>
>
>


-- 
Email SLA  •
Google+

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Tue, Mar 12, 2013 at 3:46 AM, Anne van Kesteren  wrote:

>
> I recommend discussing this with the HTML parser crowd and performance
> crowd. I would've thought we would not want to repeat mistakes made in
> the past.
>

Yup, been doing this for a while now. The stylesheet-like behavior seems to
have settled as the least evil of the compromises. It's an over-constrained
problem, as usual :)

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Anne van Kesteren]

On Mon, Mar 11, 2013 at 8:00 PM, Dimitri Glazkov  wrote:
> The resources will only block script (just like CSS:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21218), so there's definitely
> opportunity for parallelism.

Blocking script for CSS is seen as a large pita and I've heard
requests for ways to prevent that (e.g. with ). Expanding the set of external resources that does that does
not seem like a great idea to me.


> I am not sure how the message port thing will work.

Never mind that suggestion. We can't have an async DOM (yet).


> b) making sub-resources not block on script sort of ruins my plan for
> integrating  registration. If there's no blocking script, I have no
> assurances that the s in subresources are registered before script
> starts running, which means that we'll have to do something like element
> upgrade, which I worked pretty hard to remove :)

I recommend discussing this with the HTML parser crowd and performance
crowd. I would've thought we would not want to repeat mistakes made in
the past.


-- 
http://annevankesteren.nl/

Re: [webcomponents]: First stab at the Web Components spec

[Elliott Sprehn]

On Mon, Mar 11, 2013 at 4:39 PM, Scott Miles  wrote:

> My issue is that the target of this link will not in general be an atomic
> thing like a 'component' or a 'module'. It's a carrier for resources and
> links to other resources. IMO this is one of the great strengths of this
> proposal.
>
> For this reason, when it was rel="components" (plural) there was no
> problem for me.
>
> Having said all that, I'm not particularly up in arms about this issue.
> The name will bend to the object in the fullness of time. :)
>
>
>
I guess that doesn't bother me because rel="stylesheet" isn't just one
stylesheet either, you can @import lots of them down there. :)

Similarly when I think of a "component" I don't think of one custom widget,
I think of lots of logically related bundled things.

- E

Re: [webcomponents]: First stab at the Web Components spec

[Scott Miles]

My issue is that the target of this link will not in general be an atomic
thing like a 'component' or a 'module'. It's a carrier for resources and
links to other resources. IMO this is one of the great strengths of this
proposal.

For this reason, when it was rel="components" (plural) there was no problem
for me.

Having said all that, I'm not particularly up in arms about this issue. The
name will bend to the object in the fullness of time. :)

S


On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn  wrote:

>
> On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton wrote:
>
>> Personally, I had no objection to rel="component". It's similar in
>> usage to rel="stylesheet" in the fact that it's descriptive of what you're
>> linking to.
>>
>> On the other hand, rel="include" is very broad. It could just as easily
>> apply to a stylesheet as a Web component, and may limit the usefulness of
>> the term if/when future rel values are introduced.
>>
>> (p.s. I'm new to this list and haven't read through all the previous
>> discussions on Web components. Feel free to disregard this comment if I'm
>> rehashing old topics)
>>
>>
>>
> +1, I like rel="component", document or include doesn't make sense.
>
> - E
>

Re: [webcomponents]: First stab at the Web Components spec

[Elliott Sprehn]

On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton wrote:

> Personally, I had no objection to rel="component". It's similar in
> usage to rel="stylesheet" in the fact that it's descriptive of what you're
> linking to.
>
> On the other hand, rel="include" is very broad. It could just as easily
> apply to a stylesheet as a Web component, and may limit the usefulness of
> the term if/when future rel values are introduced.
>
> (p.s. I'm new to this list and haven't read through all the previous
> discussions on Web components. Feel free to disregard this comment if I'm
> rehashing old topics)
>
>
>
+1, I like rel="component", document or include doesn't make sense.

- E

Re: [webcomponents]: First stab at the Web Components spec

[Philip Walton]

Personally, I had no objection to rel="component". It's similar in usage to
rel="stylesheet" in the fact that it's descriptive of what you're linking
to.

On the other hand, rel="include" is very broad. It could just as easily
apply to a stylesheet as a Web component, and may limit the usefulness of
the term if/when future rel values are introduced.

(p.s. I'm new to this list and haven't read through all the previous
discussions on Web components. Feel free to disregard this comment if I'm
rehashing old topics)



On Mon, Mar 11, 2013 at 2:28 PM, Dimitri Glazkov wrote:

> On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda  wrote:
>
>> rel="include" ?
>>
>
> And "Inclusions" as the name? Or "HTML Inclusions"? This could work.
>
> Any objections or better names? Rob might just win this one.
>
> :DG<
>

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda  wrote:

> rel="include" ?
>

And "Inclusions" as the name? Or "HTML Inclusions"? This could work.

Any objections or better names? Rob might just win this one.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Mon, Mar 11, 2013 at 10:14 AM, Anne van Kesteren wrote:

> On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov 
> wrote:
> > That's not the problem, that's a feature :) Think of it as a
> >  tag for documents.
>
> I'd think that author expectations would be different given how
> external CSS resources work, but maybe.
>
>
> As for the API, do we really want that to be a synchronous API? That
> seems future-hostile for two reasons: we want to do more in parallel
> (Servo) and we definitely do not want cross-origin to be synchronous
> in this manner I think. Maybe it's better if we provide message port
> access between the Document objects? And if this is mostly for
> applying components to documents, maybe we should not expose API for
> that so that it the declarative way can be optimized.
>

The resources will only block script (just like CSS:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21218), so there's
definitely opportunity for parallelism.

I am not sure how the message port thing will work.

a) It sounds icky from developer ergonomics perspective and

b) making sub-resources not block on script sort of ruins my plan for
integrating  registration. If there's no blocking script, I have
no assurances that the s in subresources are registered before
script starts running, which means that we'll have to do something like
element upgrade, which I worked pretty hard to remove :)


:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Anne van Kesteren]

On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov  wrote:
> That's not the problem, that's a feature :) Think of it as a
>  tag for documents.

I'd think that author expectations would be different given how
external CSS resources work, but maybe.


As for the API, do we really want that to be a synchronous API? That
seems future-hostile for two reasons: we want to do more in parallel
(Servo) and we definitely do not want cross-origin to be synchronous
in this manner I think. Maybe it's better if we provide message port
access between the Document objects? And if this is mostly for
applying components to documents, maybe we should not expose API for
that so that it the declarative way can be optimized.


-- 
http://annevankesteren.nl/

Re: [webcomponents]: First stab at the Web Components spec

[Bronislav Klučka]

hi
let's apply KISS here
how about just
rel="document"
or
rel="htmldocument"

Brona

On 8.3.2013 22:05, Dimitri Glazkov wrote:

On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell  wrote:

Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
modules. Perhaps "package" is better?

The name is difficult. My main point is that using "components" causes
unnecessary confusion.

I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules:

1) must reflect the intent and convey the meaning.
2) link type and name of the spec must match.
3) no biting.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Scott Miles]

Agree. Seems like Dimitri and Anne decided that these targets are
'document', did they not?

Scott


On Fri, Mar 8, 2013 at 1:12 PM, Bronislav Klučka <
bronislav.klu...@bauglir.com> wrote:

> hi
> let's apply KISS here
> how about just
> rel="document"
> or
> rel="htmldocument"
>
> Brona
>
>
> On 8.3.2013 22:05, Dimitri Glazkov wrote:
>
>> On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell  wrote:
>>
>>> Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
>>> modules. Perhaps "package" is better?
>>>
>>> The name is difficult. My main point is that using "components" causes
>>> unnecessary confusion.
>>>
>> I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules:
>>
>> 1) must reflect the intent and convey the meaning.
>> 2) link type and name of the spec must match.
>> 3) no biting.
>>
>> :DG<
>>
>>
>
>
>

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles  wrote:
> Agree. Seems like Dimitri and Anne decided that these targets are
> 'document', did they not?

rel="document" seems to communicate that the relation of the linked
resources to the document is "document", which is at least cyclical if
not totally wrong :)

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Bronislav Klučka]

yes, it actually is document related to current document... does not 
seem confusing to me at all,

but I can go with fragment or stub as well :]

B.


On 8.3.2013 22:25, Dimitri Glazkov wrote:

On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles  wrote:

Agree. Seems like Dimitri and Anne decided that these targets are
'document', did they not?

rel="document" seems to communicate that the relation of the linked
resources to the document is "document", which is at least cyclical if
not totally wrong :)

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Robert Ginda]

rel="include" ?


On Fri, Mar 8, 2013 at 1:05 PM, Dimitri Glazkov  wrote:

> On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell  wrote:
> > Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
> > modules. Perhaps "package" is better?
> >
> > The name is difficult. My main point is that using "components" causes
> > unnecessary confusion.
>
> I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules:
>
> 1) must reflect the intent and convey the meaning.
> 2) link type and name of the spec must match.
> 3) no biting.
>
> :DG<
>
>

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell  wrote:
> Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
> modules. Perhaps "package" is better?
>
> The name is difficult. My main point is that using "components" causes
> unnecessary confusion.

I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules:

1) must reflect the intent and convey the meaning.
2) link type and name of the spec must match.
3) no biting.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Steve Orvell]

Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
modules. Perhaps "package" is better?

The name is difficult. My main point is that using "components" causes
unnecessary confusion.


On Fri, Mar 8, 2013 at 12:24 PM, Dimitri Glazkov wrote:

> On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell  wrote:
> > I also find the name confusing. It's common to use the term 'component'
> when
> > describing the functionality of a custom element.
> >
> > What about "HTML Modules"?
>
> Then we probably need to rename link rel="module" for consistency?
>
> :DG<
>

Re: [webcomponents]: First stab at the Web Components spec

[Steve Orvell]

>
> Also, it sounds like this specification should be titled "Fetching
> components" or some such as that's about all it defines.


I also find the name confusing. It's common to use the term 'component'
when describing the functionality of a custom element.

What about "HTML Modules"?


On Fri, Mar 8, 2013 at 1:19 AM, Anne van Kesteren  wrote:

> On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov 
> wrote:
> > Please look over it. I look forward to your eagle-eyed insights in the
> > form of bugs and emails.
>
> You try to monkey patch the obtain algorithm but in doing so you
> invoke a different fetch algorithm. One which does not expose
> resources as CORS-cross-origin. Also, for rel=component tainted
> resources make no sense, so we should only use "No CORS" in
> combination with "fail".
>
> Why is Component not simply a subclass of Document? If you already
> have a Document object you might as well use that directly...
>
> Also, it sounds like this specification should be titled "Fetching
> components" or some such as that's about all it defines. Can't we just
> put all the component stuff in one specification? I find the whole
> organization quite confusing.
>
>
> --
> http://annevankesteren.nl/
>
>

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell  wrote:
> I also find the name confusing. It's common to use the term 'component' when
> describing the functionality of a custom element.
>
> What about "HTML Modules"?

Then we probably need to rename link rel="module" for consistency?

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 10:41 AM, Anne van Kesteren  wrote:
>> Components don't directly correlate with custom elements. They are
>> just documents that you can load together with your document. With
>> things like multi-threaded parser, these are useful on their own, even
>> without custom elements.
>
> Because they don't have an associated browsing context? What other use
> case are you describing here? That seems like a potential problem by
> the way. That subresources from such a document such as  will not
> load because there's no associated browsing context.

That's not the problem, that's a feature :) Think of it as a
 tag for documents.

The author can stash all of the markup that they don't need to render
on loading into components, and then use it when necessary as they
need it.

An easy example: suppose my webapp has multiple states/views that the
user goes through in random order. With components, I can leave the
starting view in master document, and move the rest into (multiple, if
needed) components. As I need the view, I simply grab it and move it
to the master document.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Anne van Kesteren]

On Fri, Mar 8, 2013 at 6:03 PM, Dimitri Glazkov  wrote:
> I just mirrored LinkStyle
> (http://dev.w3.org/csswg/cssom/#the-linkstyle-interface) here. Given
> that  document already has URL, you're right -- I don't need the
> Component interface at all. LinkComponent could just have a content
> attribute that returns Document. Also, there's no need for
> sub-classing anything. Components are just documents.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21225

If you still want to point to the embedding element though you'll need
to subclass Document in some way, but maybe that is not needed for
now.


>> Also, it sounds like this specification should be titled "Fetching
>> components" or some such as that's about all it defines. Can't we just
>> put all the component stuff in one specification? I find the whole
>> organization quite confusing.
>
> Components don't directly correlate with custom elements. They are
> just documents that you can load together with your document. With
> things like multi-threaded parser, these are useful on their own, even
> without custom elements.

Because they don't have an associated browsing context? What other use
case are you describing here? That seems like a potential problem by
the way. That subresources from such a document such as  will not
load because there's no associated browsing context.


-- 
http://annevankesteren.nl/

Re: [webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

On Fri, Mar 8, 2013 at 1:19 AM, Anne van Kesteren  wrote:
> On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov  wrote:
>> Please look over it. I look forward to your eagle-eyed insights in the
>> form of bugs and emails.
>
> You try to monkey patch the obtain algorithm but in doing so you
> invoke a different fetch algorithm. One which does not expose
> resources as CORS-cross-origin. Also, for rel=component tainted
> resources make no sense, so we should only use "No CORS" in
> combination with "fail".

That wasn't my intent. I'll look over that again. Thanks!

>
> Why is Component not simply a subclass of Document? If you already
> have a Document object you might as well use that directly...

I just mirrored LinkStyle
(http://dev.w3.org/csswg/cssom/#the-linkstyle-interface) here. Given
that  document already has URL, you're right -- I don't need the
Component interface at all. LinkComponent could just have a content
attribute that returns Document. Also, there's no need for
sub-classing anything. Components are just documents.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21225

>
> Also, it sounds like this specification should be titled "Fetching
> components" or some such as that's about all it defines. Can't we just
> put all the component stuff in one specification? I find the whole
> organization quite confusing.

Components don't directly correlate with custom elements. They are
just documents that you can load together with your document. With
things like multi-threaded parser, these are useful on their own, even
without custom elements.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Anne van Kesteren]

On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov  wrote:
> Please look over it. I look forward to your eagle-eyed insights in the
> form of bugs and emails.

You try to monkey patch the obtain algorithm but in doing so you
invoke a different fetch algorithm. One which does not expose
resources as CORS-cross-origin. Also, for rel=component tainted
resources make no sense, so we should only use "No CORS" in
combination with "fail".

Why is Component not simply a subclass of Document? If you already
have a Document object you might as well use that directly...

Also, it sounds like this specification should be titled "Fetching
components" or some such as that's about all it defines. Can't we just
put all the component stuff in one specification? I find the whole
organization quite confusing.


-- 
http://annevankesteren.nl/

[webcomponents]: First stab at the Web Components spec

[Dimitri Glazkov]

Hello fellow web-appanauts,

The day you've been waiting for had finally arrived (or not, depending
on the type of day been waiting for).

Here's a first rough draft of the Web Components spec:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html

This spec looks really small, and I am really hoping to keep it that way.

Thanks to Ian's excellent HTML spec (which allowed plugging most of
the existing behaviors straight in) and delegating most of the heavy
lifting to other specs under Web Components umbrella, there's very
little left in the actual bell cap.

Things missing:
* somehow processing  elements when loading components.
* unfixed bugs
* examples and nicer intro

Please look over it. I look forward to your eagle-eyed insights in the
form of bugs and emails.


:DG<