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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 8 Mar 2013 18:41:51 +0000
Message-ID: <CADnb78h4_mpL9hu-wYTDcZBXgM75bwSRi28Ow7ZT5gXTER8tzA@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>
On Fri, Mar 8, 2013 at 6:03 PM, Dimitri Glazkov <dglazkov@google.com> 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

>> 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 <img> will not
load because there's no associated browsing context.

Received on Friday, 8 March 2013 18:42:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC