you can read, re-read, etc. the spec to get a good feel of the language
but at the end of the day, some hosts could implement things a bit differently,
especially on the "blurry" parts of the spec.
For example, two engines could support regexp but have a slightly different implementation
and be both valid ECMA-262 edition 3, idem for number precisions, etc.
So if your main concern is to avoid browser-centric JS features, test with the engine of those browsers
http://en.wikipedia.org/wiki/JavaScript_engine
* Chrome => V8
* Firefox => SpiderMonkey / TraceMonkey
* Internet Explorer => IE JScript / Chakra
* Safari => JavaScriptCore / SquirrelFish
* etc.
and simply put, you can run your JS code base on those tools
to find the common denominator and/or limitations, imho
it is simpler to run tests on the command line than in the browser itself.
If already your library work with all the engines you're in pretty good shape.
Another way to be in "good shape" is to simply re-use one of the popular
JS libraries, like JQuery, as those are pretty well tested.
But to be honest it depends on how far you want to go,
most likely testing only the JS engine will not be enough if you deal a lot
with the browser DOM, you will have to test in the browsers anyway,
and there that's where the fun begin, because as much as you can find slight difference
of implementations in JS engine, you can find bigger differences in browser implementations,
yep even if all that is supposed to be "standard".
Sure sticking to ECMA-262 can help http://www.ecma-international.org/publications/standards/Ecm...
you can read, re-read, etc. the spec to get a good feel of the language but at the end of the day, some hosts could implement things a bit differently, especially on the "blurry" parts of the spec.
For example, two engines could support regexp but have a slightly different implementation and be both valid ECMA-262 edition 3, idem for number precisions, etc.
So if your main concern is to avoid browser-centric JS features, test with the engine of those browsers http://en.wikipedia.org/wiki/JavaScript_engine * Chrome => V8 * Firefox => SpiderMonkey / TraceMonkey * Internet Explorer => IE JScript / Chakra * Safari => JavaScriptCore / SquirrelFish * etc.
most of the browsers will provide their engine as a command line tool ex: https://developer.mozilla.org/en/Building_only_SpiderMonkey (for IE you can use Windows Script Host).
and simply put, you can run your JS code base on those tools to find the common denominator and/or limitations, imho it is simpler to run tests on the command line than in the browser itself.
If already your library work with all the engines you're in pretty good shape.
Another way to be in "good shape" is to simply re-use one of the popular JS libraries, like JQuery, as those are pretty well tested.
But to be honest it depends on how far you want to go, most likely testing only the JS engine will not be enough if you deal a lot with the browser DOM, you will have to test in the browsers anyway, and there that's where the fun begin, because as much as you can find slight difference of implementations in JS engine, you can find bigger differences in browser implementations, yep even if all that is supposed to be "standard".
here few links that may help
http://www.quirksmode.org/js/support.html http://www.quirksmode.org/compatibility.html http://www.quirksmode.org/js/introevents.html http://ejohn.org/blog/building-a-javascript-library/ http://code.google.com/speed/articles/optimizing-javascript....