[webcomponents] Packaging as the umbrella spec

Folks,

Over the last few weeks, while trying to flesh out the Custom DOM
Elements spec (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html),
meeting with various folks and talking to actual developers who would
be using Web Components (hello, Twitterfolk!), I am starting to see
the value of of the <link rel="components"> machinery that's described
in http://www.w3.org/TR/components-intro/ as "just plain packaging",
distinct from custom DOM elements, decorators, templates, or Shadow
DOM.

The developers already use various (nasty) venues to package their
application dependencies. Things get even crazier when the
dependencies require more dependencies, each layer potentially using a
different bootstrapping mechanism. There's now a whole ecosystem of
packaging/module libraries out there, each with its own advantages and
idiosyncrazies.

If we, as a platform could provide a neat way to package the
application/framework/library assets and help manage the dependency
tree, we would be doing a Good Deed

Here's a simple proposal:

1) <link rel="components" href=URL> (synchronously?) fetches the
resource at URL, then
2) parses it as an HTML document, with a special set of exceptions:
3) only <link>, <script>, <style>, <element>, and <template> elements
are recognized during tree construction, and
4) all other elements are skipped;
5) parsing results in creating of a DOM subtree (a fragment?),
6) however, all constructed elements in this subtree act as if they're
part of the document:
7) styles resolve as document styles,
8) scrips run in document's context,
9) custom DOM elements register with document,
10) elements fetch external resources, etc.;
11) the corresponding HTMLLinkElement has something similar to
LinkStyle, which adds an accessor to the constructed subtree.

There are several issues that immediately jump out:

A) Synchronous fetch sounds bad. However, the timing of executing
scripts in the components file is not obvious otherwise.

B) Are we defining a whole new tree construction mode? Hopefully not,
but it will be a change. Good news is that there aren't any
compatibility issues.

C) What is this tree that's being constructed? That's a good question
-- I welcome any ideas.

D) What about dependency cycles? We have to manage them, yes. Just
like we did before :)

Any other issues, concerns?

Thoughts/comments/better ideas are appreciated.

:DG<

Received on Friday, 24 August 2012 18:30:24 UTC