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

[hayatoito]

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:

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: (inside the component)

We could also allow components to specify an identifier for themselves. This might be done by using a 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.

[tuespetre]

@dglazkov I don't believe it should be too awesomely complex.

• Introduce a new term, import title, that is used to mean the value of the title property of the link element, or if that is the empty string, the value of the href property of the link element. This 'special' usage of the title attribute is similar to how the title property may already be used with the link element to identify 'themed' stylesheets, so such usage is not unprecedented.
• The import map should store imports as its items with their import titles as keys (instead of their import locations.)

While existing documents that use imports as defined by the current spec would experience no immediate difference (i.e. breaking changes), they would always be able to easily transition into this more flexible approach, which allows component authors to include links to their preferred CDNs or other servers while allowing component users to manage version conflict resolution on their own terms or even specify their own preferred CDN or forked/patched version of a dependency.

Example with the current spec

The author of a page would like to import two separate documents, each of which import a slightly different version of jQuery, resulting in two requests for jQuery.

https://example1.com/index.html (excerpt)

<link rel="import" href="https://example2.com/components/modal.html" />
<link rel="import" href="https://example3.com/components/carousel.html" />

https://example2.com/components/modal.html (excerpt)

<link rel="import" href="https://some-cdn.com/jquery/2.1.4/jquery.min.html" />

https://example3.com/components/carousel.html (excerpt)

<link rel="import" href="https://some-cdn.com/jquery/2.2.0/jquery.min.html" />

Example with proposed change

The author of a page would like to import two separate documents, each of which import a slightly different version of jQuery, but because each of the authors of the two imported documents were courteous enough to provide the import title ("jquery") for their import links, only one request will be made for "jquery". Better yet, the author of the page has in one way or another become aware of the mismatch of dependency versions, and has chosen to import the most desirable version of the dependency by placing their own import link in the master document.

https://example1.com/index.html (excerpt)

<link rel="import" title="jquery" href="https://some-cdn.com/jquery/2.2.0/jquery.min.html" />
<link rel="import" href="https://example2.com/components/modal.html" />
<link rel="import" href="https://example3.com/components/carousel.html" />

https://example2.com/components/modal.html (excerpt)

<link rel="import" title="jquery" href="https://some-cdn.com/jquery/2.1.4/jquery.min.html" />

https://example3.com/components/carousel.html (excerpt)

<link rel="import" title="jquery" href="https://some-cdn.com/jquery/2.2.0/jquery.min.html" />

[tuespetre]

Scratch my comment. I'm no longer on board with HTML imports. 🤷

[TakayoshiKochi]

As HTML Imports spec is no longer actively developed, closing this.

This discussion might be a good input for how HTML modules is going to be
(if it allows non-URL thing as an identifier).
#645