-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should a syntax within module specifiers be used for this data instead? #11
Comments
This comment has been minimized.
This comment has been minimized.
The fragment seems to be visible in |
@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. |
Oops, thanks, finished the sentence. (Is anyone aware of other references for this idea?) |
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? |
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? |
No —
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:
— but as a concept, specific issues aside, I believe it is ‘within bounds.’ |
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. |
Since we got consensus for stage 2, we can assume that we don't want to go down this way. Closing for now. |
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:
What are other people's thoughts here?
The text was updated successfully, but these errors were encountered: