Package name support in HTML and CSS

[justinfagnani]

This proposal covers resolving module specifiers from JS imports and exports, but it doesn't cover an adjacent issue of how to utilize package names from HTML or CSS.

This is important when you're loading resources from a package like stylesheets or non-module script:.

In HTML, "bare specifiers" aren't reserved like they are in JS imports, and are interpreted as relative paths. We need some separate scheme, maybe package: to indicate that a path should be resolved though the map:

<link rel="stylesheet" href="package:prismjs/themes/prims.css">
<script src="package:prismjs/prism.js"></script>

In CSS we have the url() function, which could either support the new scheme, or we could add a new function, maybe like import(), to support names:

.foo {
  background: import('bar/bar.css');
}

[shannonmoeller]

Wouldn't the presence/installation of a manifest be enough to trigger a change in how HTML and CSS resolve bare paths, similar to the <base> element? I think a pseudo-protocol muddies things.

[justinfagnani]

I don't think that could for any resource except for the main page. As soon as you have resources that might not be aware of the package name map, like external CSS, or HTML modules, you can't safely have a top-level setting changing their behavior.

[Jessidhia]

Alternatively, a package-map attribute? It could even be extended to accept a string that's matched against an id to support multiple package maps.

[ljharb]

How is that different from a top-level map changing JS path behavior?

[Jessidhia]

It is different in that you specify the attribute on the individual tag. Just like type='module'.

If you don't specify, or if there's a reserved token to disable it (say, package-map="no"), you would have to opt-in (or opt-out) on a per-tag basis.

[ljharb]

Sorry for being unclear; my question was to @justinfagnani's "you can't safely have a top-level setting changing their behavior." - how is it safe for JS but not for HTML/CSS?

[matthewp]

A top-level map doesn't change JS (module) path behavior; there is no existing behavior. It would be unexpected if adding a packagemap all of the sudden changed a url() resolution in a CSS file. Although I can definitely see how that might be desirable as well...

[ljharb]

@matthewp ah, thanks for clarifying the difference.

[dcleao]

Many times, an HTML file is inside the folder for which a JS package is defined. Top level code in that page should have a corresponding "module" id (not ending in .js though).

If you use an import (or dynamic import) on a module script tag of an HTML page, what's the current module id for scoped package name resolution?

In similar AMD scenarios, lacking a way to specify the package/module that an HTML file belongs to, we map the global package scope (or map["*"] in AMD) to the version of the package that the HTML belongs to... I don't think this is ideal though. At a minimum, it forces you to generate a different map depending on where the top-level page which is consuming it directly lies.

So, I think it would make sense for it to be possible to specify the package that an HTML belongs to.

[domenic]

This is now a first-class part of the proposal, using import: URLs. \o/