-
Notifications
You must be signed in to change notification settings - Fork 12
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
std:x|y is not a valid URL #15
Comments
@annevk do you have thoughts on this issue? Any reasons why We may not need to worry about this if we end up switching approaches for LAPI fallbacks entirely. But if we do stick with Some quick fix ideas:
|
There's also: std:x?fallback=y. It's less pretty, but it's clear, it's a valid URL, and would allow us to add extra parameters in the future if needed (not sure if that's a good thing though!). |
For validity the URL Standard follows https://tools.ietf.org/html/rfc3987 to encourage producers to make URLs that work in most places. I don't really know the rationale behind |
Rather than implementation as a string, could not we allow |
How would that work with script src? |
As the original proposal said, using attribute |
Hmm, having to use a different syntax depending on the call site seems like a big disadvantage to me. |
Any reason |
even if is amending the html parsing spec acceptable? crazy: browsers supporting this feature could allow duplicate attributes which i think would also be backward compatable: as for js syntax i like |
The intention is specifically to use the existing string and URL infrastructure, and not to invent some new thing besides URLs (such as bracketed collections of strings, or logical-ORed-together strings) for loading modules. |
Is that something like an indispensable condition to use the existing string at the two different places(import/script module <= URL), or it's fine to use the two different ways(the above suggestions) if both of them solve the same problem and if it's even better at fewer dependencies? |
I think any solution which introduces two separate ways of creating fallbacks, and requires developers to have to memorize which apply in which contexts, is significantly worse than any solution which only has one such way. I don't think it's a requirement that you only use one, but the benefits of using two (or more) would have to be extremely compelling, and so far nobody has really presented any reasons why two is good that I was able to understand. |
If |
We had a productive discussion in IRC that people might find illuminating. I think right now, for a fallback syntax in the URL, I'm tending toward But that said, I'm also continuing to think we should remove the fallback syntax for now, in favor of a package name map based solution. I'll post a pull request about that soon. |
Wouldn't |
One advantage of add syntax like If we had <script src="https://cdn.com/jquery.js | ./assets/jquery.js"></script> Currently people use |
Ok, I see now that package name maps could possibly be a generic solution for fallbacks. If so that works for my use case. |
This incorporates some of the ideas touched on in the issue tracker, mostly around using package name maps to provide a better fallback story and web developer control. It touches on the following issues: * Fixes #10, fixes #14, fixes #15, and fixes #24 by moving away from std:x|y and its attendant problems. * Opens the door to solutions for #5 based on the speculative package name map fallback ideas. It also adds a bit more motivation to the intro, and rearranges to emphasize the standards process, before diving into many details on the importing infrastructure. For now we delete the "Trying these ideas out" section, and spec.md, as they are all about the old infrastructure.
This incorporates some of the ideas touched on in the issue tracker, mostly around using package name maps to provide a better fallback story and web developer control. It touches on the following issues: * Fixes #10, fixes #14, fixes #15, and fixes #24 by moving away from std:x|y and its attendant problems. * Opens the door to solutions for #5 based on the speculative package name map fallback ideas. It also adds a bit more motivation to the intro, and rearranges to emphasize the standards process, before diving into many details on the importing infrastructure. For now we delete the "Trying these ideas out" section, and spec.md, as they are all about the old infrastructure.
"|" is not a valid URL code point.
https://url.spec.whatwg.org/#url-code-points
Also related to #14 that proposes adding " " which is also not a valid URL code point.
The text was updated successfully, but these errors were encountered: