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

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

From: Dimitri Glazkov <dglazkov@google.com>
Date: Mon, 11 Mar 2013 13:00:02 -0700
Message-ID: <CADh5Ky362ptpt=_1qeGkv95O3BOnzWC2YyB3RpBk10LF_uTtiw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Mar 11, 2013 at 10:14 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov <dglazkov@google.com>
> wrote:
> > That's not the problem, that's a feature :) Think of it as a
> > <template> 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 <element> registration. If there's no blocking script, I have
no assurances that the <element>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 :)

Received on Monday, 11 March 2013 20:00:30 UTC

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