Are you aware of https://javascript.spec.whatwg.org/? :) Thankfully that spec is almost obsolete as TC39 has moved much of it into the main spec over time. It used to be the only place important de-facto language features like __(define|lookup)(Getter|Setter)__, or String.prototype.blink, or Function.prototype.{arguments,caller} were specified. You can see the history of it getting smaller in https://github.com/whatwg/javascript/commits/master.
On the subject of the table, it's interesting that Firefox's only failure is in "Date.parse produces NaN for invalid dates". However, as far as I can tell this is not a requirement of the spec, since per https://tc39.github.io/ecma262/#sec-date.parse
> If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
IMHO, we should switch from that mess to common repository of JS libraries (CJSAN), which can be referred using tags like <lib name="foo" version="1.0"><script .../></lib>. Such libraries will act as polyfills for an API, while browsers will be able to provide optimized versions of these libraries.
I.e. instead of waiting for ecma262 to be implemented by all browsers, scripts can just load common polyfill, which then can be overridden by browser later:
Maybe I should have said a WATWG YavaScript standard...
I didn't know the standard existed.
Generally, agree with the "let's put back every piece of dung in place after paving the cowpath" approach the WHATWG follows. Anosmic folks come to rely on the reduced friction coefficient...
I suppose that the Date.parse stuff was updated between ES5 and the living stabdard.
You can pretty much consider Opera 12.10 100%. The only thing missing is "parseInt ignores leading zeros", which is such a minor issue (octal bugs I assume).
No browser is at 100%, BTW.
Waiting for a WATWG JavaScript standard that removes these parts from the spec...