Should a syntax within module specifiers be used for this data instead?

[littledan]

In comments like WICG/webcomponents#839 (comment) and #3 (comment), various people have proposed that the existing module specifier be used to communicate the module type, perhaps with a scheme-like syntax at the beginning of the specifier.

I wouldn't really be in favor of this approach due to the following downsides:

1. Various existing interpretations of module specifiers--e.g., URLs and paths--already have very complicated grammars, and it would add additional technical complexity to incorporate
2. It will take time for existing URL parsers and processers to learn about the new syntax, and given all the manipulation they do, this seems bound to lead to security issues (h/t @slightlyoff for pointing this out)
3. More importantly, it would be difficult for a human to parse out the module type and to write it
4. A pseudo-scheme syntax wouldn't cleanly scale to multiple parameters, and a fragment/query parameter syntax would not work as it'd change semantics

What are other people's thoughts here?

[littledan]

The fragment seems to be visible in import.meta.url.

[annevk]

@littledan first sentence in OP is incomplete. I'm assuming you're asking about overloading the module specifier somehow. I agree that's not a great solution for the reasons you mention.

[littledan]

Oops, thanks, finished the sentence. (Is anyone aware of other references for this idea?)

[bathos]

I think distinct ES syntax for module type specifiers is justified, but FWIW, here is an example of a (compile time) custom scheme for specifiers that I made for weird reasons:

https://github.com/bathos/rollup-plugin-realm-uri

The reason I mention it is that although it may not look it, those specifiers are kosher WHATWG URLs. Would it definitely be necessary to extend the URL language itself, given URL has built-in extensibility via scheme?

[annevk]

I think there's a variety of ways to avoid some of the downsides there, yes. But playing with schemes in that matter is using them for something they were not quite designed for. Did you formally register your scheme?

[bathos]

No —

Just to be clear: the realm: scheme is not a formally registered URI scheme. It is defined here and implemented only by this library.

I don’t agree though that such things are outside the scope of the design of schemes. Each scheme may have an associated refinement grammar so long as it describes the same set or a subset of the base grammar.

There is at least one misuse here. The grammar defined in that lib constrains the shape of and attaches semantics to fragment ids, and schemes are not allowed to do this per RFC 3986:

Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.

— but as a concept, specific issues aside, I believe it is ‘within bounds.’

[littledan]

I wanna go with "no" for this, for the reasons I explained in #11 (comment) . If we get consensus on Stage 2, that would constitute agreeing that we're not going this way.

[xtuc]

Since we got consensus for stage 2, we can assume that we don't want to go down this way. Closing for now.