0

We are starting a project and want to be cross-browser compatible - this would seem to suggest that we need to ensure that the version of JavaScript we're using is works in all of the browsers we intend to support. Is the following a reasonable way to test to see what the JavaScript level works in each browser?

<script language="javascript1.0">alert("Your browser at least supports JavaScript 1.0");</script>
<script language="javascript1.1">alert("Your browser at least supports JavaScript 1.1");</script>
<script language="javascript1.2">alert("Your browser at least supports JavaScript 1.2");</script>
<script language="javascript1.3">alert("Your browser at least supports JavaScript 1.3");</script>
<script language="javascript1.4">alert("Your browser at least supports JavaScript 1.4");</script>
<script language="javascript1.5">alert("Your browser at least supports JavaScript 1.5");</script>
<script language="javascript1.6">alert("Your browser at least supports JavaScript 1.6");</script>
<script language="javascript1.7">alert("Your browser at least supports JavaScript 1.7");</script>
<script language="javascript1.8">alert("Your browser at least supports JavaScript 1.8");</script>

Obviously the list of tests could be extended as further JavaScript versions are released.

Is there a better way (or source) for this information?

By the way, I did see the Wikipedia page on JavaScript versions and it doesn't seem to correspond to the results I get when I run the code snippet above.

My results are:

Firefox 43.0.4 - reports as supporting JavaScript 1.0 through 1.5
IE 10.0.9200.17566 - reports as supporting JavaScript 1.1 through 1.3
Chrome Version 47.0.2526.111 m - reports as supporting JavaScript 1.0 through 1.7
Safari 5.1.7 (7534572) - reports as supporting JavaScript 1.0 through 1.7
Opera 34.0.2036.50 - reports as supporting JavaScript 1.0 through 1.7

asked Jan 20, 2016 at 18:53
6
  • P.S. given my test results it would seem that JavaScript 1.3 is the common denominator for the latest versions of the browsers listed above... Commented Jan 20, 2016 at 18:54
  • 1
    kangax.github.io/compat-table/es6 Commented Jan 20, 2016 at 18:59
  • Before you do that, try to ask yourself this question: what is different between all those versions of JavaScript? All browsers these days basically support all < ES6 syntaxes. Is it really necessary to differentiate them? Commented Jan 20, 2016 at 19:05
  • The responses thus far prompted further research as to what was really going on with the script blocks that I listed above - apparently the language attribute is deprecated in favor of type where type would be expected to be application/javascript or not even referenced because javascript is considered the defacto scripting language for web pages. Therefore I'm left to conclude that the fact that my script blocks (above) seem to generate results that might be interpreted as meaningful, there is in fact no real meaning to be inferred... therefore the behavior should be considered as vestigial? Commented Jan 20, 2016 at 19:45
  • 2
    Downvotes on questions mean: This question does not show any research effort; it is unclear or not useful. It can also mean anything else. Commented Jan 20, 2016 at 20:14

1 Answer 1

8

Is the following a reasonable way to test to see what the JavaScript level works in each browser?

No.

Don't use the [language] attribute, it's only going to cause you incompatibility, especially as time goes on and newer browsers decide they only support javascript3.8 or whatever the version-du-jour happens to be. If you want to write a script, just write a script:

<script src="filename.js"></script>

As far as detecting versions, you don't need to detect JS versions. No developer worth their salt checks versions, they check features. Modernizr is one such feature detection resource. caniuse is another which describes which browsers support which features so you can determine if you're going to be able to use any particular feature at all.

In many cases, what you'll want for maximum backwards compatibility is a set of polyfills to replicate any newer features you'd like to use for older browsers.

answered Jan 20, 2016 at 18:58
Sign up to request clarification or add additional context in comments.

5 Comments

developers worth their salt check versions when features are broken/partial in some known browsers, tricking feature detection. like XMLHttpRequest on file:/// in IE7's status not working, or MutationObservers needing an extra DOMMutation subscription on Safari 5+6. that said, it's been a while since IE mattered, and that's where most of those kind of spec differences lie.
@dandavis, the only time when one should resort to hacky version checks is when there are no other features to detect.
no, feature detection lies when an implementation has bugs on a feature you need. for example, just asking if(window.MutationObserver) in old safari won't tell you that your code using MutationObservers which works everywhere else won't work as expected without an extra work-around. look deep into any large popular framework or dom library and you'll see plenty of browser-specific patches to cover specific sub-feature issues. i 110% agree that good devs don't write code like you saw in 2008 that started out if(ie){...}else{...}...
@dandavis, I'm going to assume you didn't misunderstood my previous statement, because you said "no", and then proceeded to describe exactly what I was talking about.
my point is that when supporting older devices/browsers, feature detection alone is sometimes not enough.

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.