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 (7534.57.2) - reports as supporting JavaScript 1.0 through 1.7
Opera 34.0.2036.50 - reports as supporting JavaScript 1.0 through 1.7
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.
Related
We have written a lot of horrible jscript code for server side classic ASP (the current platform of some very big blue chip companies which are our customers). jscript is more or less javascript version 1.3. It doesn't have built in JSON libs, and doesn't have some of the newer loop constructs for example
The question is, can the dart JavaScript compiler target older versions of JavaScript?
No. See Q. What browsers do you plan to support as JavaScript compilation targets?.
We're currently aiming to support the following browsers:
Internet Explorer, latest two versions that are 9 or higher.
Firefox, latest two versions that are 7 or higher.
Chrome, latest version.
Safari, latest two versions that are 5.1 or higher.
Opera, latest version that is 12 or higher.
That's a goal; we don't actually support all of these browsers yet. The goal may change to be either more restrictive or more permissive. We'll refine this further as Dart matures.
I think the main reason is to have a browser that contains a quite recent version of javascript.
For instance, you can find some calls to Object.create (requires JavaScript 1.8.5) in the js file resulting of dart2js compilation.
So let's pretend that Chrome and Firefox start supporting yield and other JavaScript.next niceties in their X and Y versions respectively.
Are there any recommended strategies (set by W3C, for example) for how to use them while letting our Web apps also run in Chrome X-1 and FF Y-1?
I would recomend to use a new feature in HTML, CSS or JS only when all stable versions of most popular browsers support it (these are >90%), but with a notification for the users that do not have them, like "Please upgrade your browser to the last version". Some of the features can be simulated, other - not, so if it's possible, do it, but every time try do the best for the user.
What are cons of force a web site viewed in IE to compatible mode? Say we force IE9 to IE8 compatiblity mode?
Performance drawbacks
Can't use any new IE9 specific features like HTML5/CSS3/SVG
Why?
We run legacy web app which is developed since 2000 so it's a mess ball fighting to be compatible with Chrome, Opera, Firefox, IE6/7/8 and now we decide to add IE9 to the list. But with IE9 we run in issues with printing, "Permission deniend" JavaScript errors (probably something about cross-frame JavaScript calls) and next issues - the easy workaround is to force IE9 to behave as a IE8 and then everything works fine. But I am still not sure if it's way to go...
first our app is public site (for our clients)
You have a public website developed in 2000 and it doesn't work on modern browsers? Deprecate it or re-write it.
Don't hack your code to support modern browsers, the website is clearly poorly written and doesn't apply to standards. You can't get away with this.
The only place where you can get away with this level of incompatibility is intranet applications and even then you should simply state "it works on browser X, live with it"
You can't say that to public facing clients. I mean you can try, but have fun losing business to your competitors.
Re-develop your website to match the W3C HTML/CSS standards and the ES5 standards and it will be completely future facing (for some years).
Alas, the way the web works is that anything more then 5 years old is deprecated. So either re-write it every 5 years or get out of the web business.
In terms of actually using compatibility mode, don't. IE6-8 are horrible engines and should be avoided like the plague. If you use them then you can't write future facing standards compliant code.
Your code needs to match the standards and you should fix / shim / patch any browser specific bugs where those browsers don't implement the standards.
You cannot say you have tested in IE6/7/8/9 until you have tested in those different versions. Emulating the test environment is not the same as using the test environment. To my knowledge IE7/8 compatibility modes are the older render engines, not the underlying browser as a whole, bugs and all. It is closed source so you will never know.
Convert Microsoft's free to download virtual disk images for cross-browser testing to Virtualbox images and put them on a machine that just runs Virtualbox. An old machine will do, run the VMs headless and access them with remote desktop. In that way you will be able to test in all browsers without burdening your machine with MS/Spyware.
I believe your system admins can set IE to compatibility mode for all intranet traffic using the Group Policy Editor. Any site you create will from this point forward, you can add a meta tag to force IE9 to render natively and use all the newer features...
I'm having to do that on my current project using the following doctype and meta tag in my header:
<!DOCTYPE HTML >
<meta http-equiv="X-UA-Compatible" content="IE=100" />
Compatability mode is something that MS introduced to give people some chance to upgrade their applications, not for long term use. AFAIU.
If you want your application to be compatible with IE9, then you will have to change it. If you are trying to maintain IE6-9 compatibility then you have a real challenge, and you should consider whether this is really practical - in essence, you need at least 2 distinct sets of html. Is this practical for you?
IE9 compatibility mode is different form IE9 and IE8 - it draws bits from both. So you need to do a full test agaisnt the compatibility mode version, and ensure that it remains working against this.
So in answer to the question, the cons are that you are not being IE9 compatible, and there is a danger that when IE10 comes out, your code will not run against that in any mode. You are putting the effort into compatibilty testing without providing for future changes. You would do better, in the longer term, to make your code IE9 compatible. Also, the message you are giving your clients is that your code base is not going to be compatible for much longer. Unless you are talking to them about a re-work, this is a real negative.
However, it sounds like your entire code needs a re-work, to forget about IE6 and be written for modern working browsers. Using compatibility mode until that happens is probably OK. If you do this - and tell your clients - then staying in compatibility mode is viable.
Using compatibility mode will NOT cause the browser to use the JavaScript engine that was present in the old version of IE.
By that I mean it will run any JavaScript code using the IE9 engine. Which was a problem for us when debugging an old product that had a problem with IE7/8.
The Mozilla Foundation continues to add new language features to JavaScript. They're up to version 1.8 now where 1.5 was more or less the ECMA baseline.
However, Firefox is the only browser that supports the latest version and IE is firmly stuck at a 1.5-equivalent JScript.
What purpose do the Firefox-only extensions serve? Or are they just lying dormant until (and if) the rest of the browsers catch up?
Firefox, Thunderbird, and other XUL apps also have large portions of themselves written in JavaScript. A more featureful JavaScript means a better development environment for Firefox and other Mozilla apps.
Extending the language is a good idea, even if only one browser is doing it - eventually it will prove itself and be made into the standard at which time other browsers will have to catch up.
Otherwise, how can progress be made - Microsoft does this all the time: would XMLHttpRequest have ever made it into the standards if Internet Explorer wouldn't have implemented it first?
From the Mozilla perspective the purpose of these changes, except for adding more capabilities for use by web developers, is to lead up to JavaScript 2.0, that is being developed as the next revision of ECMA 262 (revision 4) TC39 workgroup.
Future browsers will support JavaScript 2.0. In the mean time, developers are invited to take advantage of these extra features - natively in Firefox and using JavaScript libraries that provide backward compatibility with Internet Explorer. I find this very useful.
Also, it may be interesting to note that Webkit (the engine developed by KDE and used by Safari, Chrome and several free software browsers) supports JavaScript 1.7.
The biggest reason at the moment for improved JavaScript is for extension writers, who need not worry about cross-browser compatiblity.
JavaScript is a trademark by Sun which was licensed to Netscape and is now held by the Mozilla Foundation. Microsoft has their own implementation of the language called JScript, but there are others (eg. DMDScript).
ECMAScript was an afterthought to add a common baseline to the various implementations. So it's only natural that language development continues outside the standards committee, which is free to add the changes pioneered by the implementors in future revisions of the standard (eg the array extras introduces in JS1.6 will be in ES3.1).
Which version of JavaScript does Google Chrome support in relation to Mozilla Firefox? In other words, does Chrome support JavaScript 1.6, 1.7, or 1.8 which Firefox also supports or some combination of them?
While Chrome will execute Javascript marked as "javascript1.7", it does not support JS1.7 features like the "let" scoped variable operator.
This code will run on Firefox 3.5 but not on Chrome using V8:
<script language="javascript" type="application/javascript;version=1.7">
function foo(){ let a = 4; alert(a); }; foo();
</script>
If you change language to "javascript1.7" and omit the type, it won't run with JS 1.7 features in Firefox 3.5. The type section is necessary.
This seems to be related to a general WebKit bug, https://bugs.webkit.org/show_bug.cgi?id=23097; it may be that Chrome emulates the Safari behavior even though it uses a different engine.
When asked about supporting JS 1.8 features, the V8 team said they were trying to track the version used in Safari so pages would act the same in both browsers.
This thread is still relevant. As of 2012, Chrome supports most of Javascript 1.6, not including string and array generics. It supports none of 1.7. It supports reduce and reduceRight from 1.8, all of 1.8.1, and Getters and setters and all the non-version specific things listed on this page. This page is linked from the Mozilla Developer Network, which specifies the versions of javascript, found here.
Google Chrome uses the V8 javascript engine, which currently states that it implements ECMA-262, 3rd edition. This would imply it supports at least version 1.5.
Here's a simple Javascript 1.6 feature Chrome (and V8 users, like node.js) won't run: for each … in
for each (variable in object)
statement
As it is JS 1.5 (per J c's answer) is the only version Chrome claims to completely implement.
In fact the Chrome team has mostly aimed for compatibility with Safari (most prominent Webkit user at the time), and refused features on those grounds.
Google Chrome supports up to Javascript 1.7:
<script language="javascript1.7">alert(1.7);</script> - Alerts
<script language="javascript1.8">alert(1.8);</script> - Doesn't alert
This is an old thread, however here goes. Google Chrome does not respond to the following
function foo(){
let a = 4;
alert(a);
}
foo();
hence it does not support JavaScript 1.7