Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Progressive enhancement for script tags #801

Closed
bertyhell opened this issue Feb 17, 2017 · 2 comments
Closed

Progressive enhancement for script tags #801

bertyhell opened this issue Feb 17, 2017 · 2 comments

Comments

@bertyhell
Copy link

ES6 is great, unfortunately we cannot use it yet, because some browsers that we want to support do not support ES6 yet.

My proposal tries to get around this issue.
By providing multiple JavaScript source files we could have the browser pick their best version, similar to how video source elements work.

imaging something like this:

<script src="http://myserver.com/index.v5.js">
  <source src="http://myserver.com/index.v6.js" type="text/ecmascript6">
  <source src="http://myserver.com/index.v7.js" type="text/ecmascript7">
</script>

From my tests, it seems that most browsers still work even though the script tag contains html. They just execute the index.v5.js file. Tested on Windows Chrome, Firefox, IE11 and Edge.

But if for some reason the above isn't valid according to the HTML5 spec or gives problems with older browsers:

This would still load index.js but if the browser supports the "versions" attribute. it can check what the highest ecmascript version is that it does support from the list and append that version number just before the ".js". eg: index6.js

<script src="http://myserver.com/index.js" versions="5,6,7"></script>

Once this syntax is supported in all modern browsers, some browsers will be able to run a higher ECMAScript version than others if the programmer provides those versions as separate files.

Many companies use build systems like grunt, gulp and webpack, so outputting those files would not be a lot of work.

@patrickdark
Copy link

There's already a version parameter for the application/ecmascript media type that no one's implemented. My guess is this proposal will meet the same fate because versioning a language means that if a client doesn't support a single feature, they have to report that the entire language is unsupported, which then results in lying about support if content would work by doing so, which then defeats the point of declaring versions.

If you're going to write three versions anyway, you're probably already writing polyfills, so there's no reason to have multiple versions unless there's a dramatic syntax shift like with the defunct ECMAScript 4.

@chaals
Copy link
Collaborator

chaals commented Mar 7, 2017

This seems like it's not getting a lot of interest, and there is no implementation. I suggest incubating it e.g. in WICG to get some more buy in before we follow up further. Closing for now.

Explicit browser commitment - or implementation - would be grounds for re-opening.

@chaals chaals closed this as completed Mar 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants