std:x|y is not a valid URL

[hiroshige-g]

"|" 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.

[domenic]

@annevk do you have thoughts on this issue? Any reasons why | is not a valid URL code point?

We may not need to worry about this if we end up switching approaches for LAPI fallbacks entirely. But if we do stick with std:x|y in the long term, we should resolve this; it's not good to encourage web developers to use "invalid" URLs, even if browsers handle them fine.

Some quick fix ideas:

• Make | valid
• Use a different choice of punctuation. None of them communicate "alternate" the same way IMO, but something like + or @ or ! or ~ is not the worst plan.

[ojanvafai]

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!).

[annevk]

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 |.

[watilde]

Rather than implementation as a string, could not we allow import from to use ||?

[domenic]

How would that work with script src?

[watilde]

As the original proposal said, using attribute stdsrc works fine imo. Having both looks like bringing high affinity with current behavior. It still has a concern of standardizing attribute pairs for every place a layered API URL, but might be better for backward-compatibility.

[domenic]

Hmm, having to use a different syntax depending on the call site seems like a big disadvantage to me.

[annevk]

Any reason / is not acceptable here?

[devsnek]

even if | was valid in urls (or any other separator) it feels like a hack to get around making syntax, which i think would be more explicit with the intention and be easier to parse.

is amending the html parsing spec acceptable?

crazy: <script type=module src=[want, fallback1, fallback2]>

browsers supporting this feature could allow duplicate attributes which i think would also be backward compatable: <script type=module src=want src=fallback1 src=fallback2>

as for js syntax i like import x from want || fallback1 || fallback2

[domenic]

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.

[watilde]

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?

[domenic]

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.

[matthewp]

If | becomes valid, would this be something that developers could leverage some how? Meaning would the URL constructor be updated to include a fallback property? And if so, I'm assuming this would only be possible on std: type of URLs...

[domenic]

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 std:x?fallback=y as @ojanvafai suggested upthread. It seems like std:x|y causes a lot of confusion because people don't have the same intuition about | as they do about query params. But the semantic intent was the same. This wasn't meant to be a new feature of URLs in general, just a particular way of encoding how to locate the contents of a resource. I think the use of | just got too "cute".

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.

[wanderview]

Wouldn't ?fallback= require URL encoding the fallback URL in the search param? I thought one advantage of special syntax like "|" would be that it could avoid the URL encoding requirement and be more ergonomic.

[matthewp]

One advantage of add syntax like | is that it becomes a generic solution for fallbacks. The ?fallback query param will work for std: URLs if you define it that way, but won't work as a fallback for multiple http(s) URLs. This is something people have wanted for a very long time in order to prefer loading a script from a CDN but then falling back to a local resource.

If we had | we could do:

<script src="https://cdn.com/jquery.js | ./assets/jquery.js"></script>

Currently people use document.write() (yuck) to do the above.

[matthewp]

Ok, I see now that package name maps could possibly be a generic solution for fallbacks. If so that works for my use case.