Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Allow multiple fallback URLs #5

Open
domenic opened this issue Mar 9, 2018 · 2 comments
Open

Allow multiple fallback URLs #5

domenic opened this issue Mar 9, 2018 · 2 comments
Labels
fallback semantics An issue with the proposed model for falling back from a LAPI to a polyfill

Comments

@domenic
Copy link
Collaborator

domenic commented Mar 9, 2018

@kmiller68 suggested we should allow multiple fallback URLs, and let the browser pick among them. For example, the browser could pick the one it already has in its cache.

I'm unsure whether the semantic would be picking one among them, and failing if that one doesn't work, or the browser picking an ordering among them, and trying each in turn if the first one fails.
@dtruffaut
Copy link

Plus the pipe trick looks really cheap.

Why not a srcset attribute ?

<script type=module srcset='..., ..., ...'></script>

@domenic
Copy link
Collaborator Author

domenic commented Apr 30, 2018

That seems like a separate issue; if you'd like to discuss syntax alternatives please open a new one.

(Quick answer: that doesn't work in import statements.)

@domenic domenic added the fallback semantics An issue with the proposed model for falling back from a LAPI to a polyfill label May 7, 2018
domenic added a commit that referenced this issue Aug 3, 2018
@domenic
Rewrite with a stronger dependency on package name maps
bb0c0de 
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.
domenic added a commit that referenced this issue Aug 3, 2018
@domenic
Rewrite with a stronger dependency on package name maps
bedc20a 
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.
@domenic domenic mentioned this issue Aug 3, 2018
Closed
@domenic domenic mentioned this issue Aug 20, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fallback semantics An issue with the proposed model for falling back from a LAPI to a polyfill
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dtruffaut @domenic