[webcomponents] [Imports]: Consider changing component location to component identifier (bugzilla: 21253) (#235)

Title: [Imports]: Consider changing component location to component identifier (bugzilla: 21253)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21253

----
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21253#c0
*Steve Orvell* wrote on 2013-03-11 19:52:10 +0000.

The spec currently requires that 2 components have knowledge of the same url to share a dependency. This is often inconvenient and it's common for module loaders to use a name as a component identifier instead of a url (http://requirejs.org/docs/api.html#jsfiles) to avoid this problem.

Here some options for addressing this limitation:

Option 1: \<link rel="component" name="foo-component" href="...">

To support this type of usage, we could modify the "component location" concept to be "component identifier." We would allow an optional name attribute to be on the component link tag. The component identifier definition would be something like this: 

"component identifier
The component identifier must be the value of the link element's name content attribute. If that attribute does not exist or is empty string, it is the result of resolving the URL given by link element's href content attribute, relative to the element, or empty string if that fails."

Option 2: \<component name="foo-componnet"> (inside the component)

We could also allow components to specify an identifier for themselves. This might be done by using a \<component\> tag with name attribute inside the component.

----

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21253#c1
*James Simonsen* wrote on 2013-07-19 21:31:15 +0000.

I'd love to see something like this.

One of the things that's bothered us is having a dozen different copies of jQuery in the cache. They all come from different URLs and are fetched and cached separately. It'd be so much nicer if we could just download it once.

So, if we could expand this beyond components, or perhaps make sure that components can accommodate simple JS libraries, that'd be great. It could be a matter of being able to specify a script by name, or have components follow the same evaluation rules as \<script\>. That doesn't sound great though.

My biggest concern is management of the namespace. You wouldn't want to have conflicts between sites. Even worse would be if a site poisoned a name by injecting a malware script in there. Maybe we need a hash of the content as well?

----

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21253#c2
*William Chan* wrote on 2013-07-20 02:02:57 +0000.

RequireJS doesn't try to globally address resources by content/id. Instead, it relies on a component identifier + baseURL as described in Steve's link which says: "RequireJS loads all code relative to a baseUrl." What this encourages is every website self-hosting its own web components if they want to use these component identifiers. If we want to allow this to be done globally, then we start running afoul of security concerns, some of which are fixable by a hash, but there's also the Content-Security-Policy issue. See https://news.ycombinator.com/item?id=4516193 for details with explanations from agl & abarth.

AIUI, the main value of this proposal is making component loading easier for web developers. And I agree strongly with this. Component loading with explicit URLs can often be a PITA.

One downside of the RequireJS approach is that the module loading is all done in JS and is opaque to the rendering engine's preloader. It'd be great if any solution we propose here enables the preloader to understand the resource loading so it can issue resource requests sooner.

----

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21253#c3
*Dimitri Glazkov* wrote on 2013-09-18 19:48:05 +0000.

This is not something we'll tackle in this iteration of the spec. It sounds awesome and awesomely complex.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/235