CODEWITHSUNDEEP
javascriptcross-browser
Šime Vidas
Šime Vidas

Reputation: 185883

Are there any cross-browser JavaScript features that are not documented by the ECMAScript standard?

By cross-browser feature I mean a feature that is implemented in all of the 5 major browsers. (Beta versions are OK, too)

An example of such a feature was the JSON object which became cross-browser with the release of IE8, but wasn't standardized until ECMAScript 5th edition (nine months later).

Now that the 5th edition is out, are there still any other features that are cross-browser (and therefore can be safely used) but are not documented by the ECMAScript standard?

Upvotes: 2

Views: 292

Answers (4)

Christian C. Salvadó
Christian C. Salvadó

Reputation: 827198

Something that resembles to your JSON object example are Array.prototype methods.

They were implemented by a lot of browser vendors a lot of time before ES5, for example Mozilla, started implementing them for it's JavaScript(tm) 1.6 version, as of September 2005.

Other things between the ES3-ES5 gap -not described until ES5- are:

  • Not throwing on for (var prop in null) or undefined, in ES3 a TypeError should happen

  • Not throwing on FunctionDeclarations inside blocks, e.g.:

     { function foo () {} }

    FunctionDeclarations are allowed at the level of Program (global code outside anything) or within the FunctionBody of a function, Blocks can contain only Statements.

  • Strings with LineContinuations, e.g.:

    var s = 'foo \
bar'; // 'foo bar'

Other interesting things exist, like not-quite octal numbers, for example:

var n = 08;

The above NumericLiteral is invalid in any version of the ECMAScript Standard.

The DecimalLiteral syntax doesn't allows a literal to start with 0 (with the exception of course of the 0 literal) and the grammar of OctalIntegerLiterals is specified to take a zero, and then numbers from 0 to 7 (only 0[0-7]+), therefore the literals 08 or 09, should produce a SyntaxError

But that doesn't happen in any implementation I've tested ever, they are treated just like DecimalLiteral, (08 produces 8).

Firefox is the only implementation that will show you a warning:

08 warning

Edit: Another widely spread non-standard feature that exist nowadays are Callable RegExps.

This feature was introduced by Mozilla, time ago, later cloned by WebKit JSC, V8, and the Opera JS engine.

Basically you are allowed to invoke RegExp objects, like if they were functions, being just syntactic sugar alias for the RegExp.prototype.exec method:

var re = /foo/;
re('foobar');      // ["foo"], just an alias for:
re.exec('foobar'); // ["foo"]

This feature is completely non-standard since ES3 and ES5 do not allow [[Call]] to be defined on RegExp instances, because their internal methods and semantics are fully specified.

Since in those implementations RegExp objects implement the [[Call]] internal method, they are recognized as Functions by the typeof operator:

typeof /foo/; // "function" in some implementations

Upvotes: 3

Mike Samuel
Mike Samuel

Reputation: 120486

Getters and setters were almost uniformly implemented (not in IE) but not speced in ES3 and were recently standardized in ES5.

Still not speced in ES5:

  1. The ability to declare functions other than at the top level of a program or function. E.g. if (...) { function f() { ... } }
  2. Key iteration order for for (... in ...) loops. ES5 still does not specify the key order. There is still some debate over how this should be specified for arrays, and browsers differ over corner-cases, but all seem to agree on insertion order.
  3. Ability to escape arbitrary characters in regexs. The ES3 & ES5 syntaxes forbid regexs like /\$/ (since it is an IdentifierPart) but that works in all major interpreters.
  4. Ability to have objects from multiple JavaScript contexts (frames) interact. No ES spec says anything about what should happen when there are multiple JavaScript contexts each with their own version of Object.prototype and the other intrinsics.

Upvotes: 0

Robusto
Robusto

Reputation: 31883

In some ways, ECMAScript standards are what stock analysts would call a trailing indicator. That is, they reflect what has already happened, not what should happen. And in a sense, this is a good thing. As you yourself probably are well aware, all the planning in the world can't prepare you for the unexpected. We didn't know we would need JSON until we found out we needed it, and so we had to invent it. And once it was invented and in use and popular and useful, various browser makers elected to support it. Even Microsoft.

OK, enough soapbox. As a practical matter, given finite time and resources, you really have to be aware of developing standards and constantly make trade-offs between what is supported now, what is mostly supported now, what is not likely to be supported and what is just too damn much of a risk. You have to be careful. There are plenty of pie-in-the-sky good ideas that never survived. Witness the "layers" concept utilized by Netscape and nobody else. Does it make sense to support innerText? You ultimately make the call, and you ultimately have to be the one who makes the call.

Upvotes: 0

Jaydee
Jaydee

Reputation: 4158

There might be but you have no guarantee it would be there tomorrow.

Upvotes: -1

Related Questions