Take the 2-minute tour ×

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?

share|improve this question
Since this question may have multiple answers, you may want to make it a community wiki. –  Sidnicious Nov 8 '10 at 18:54
@Sidnicious I doubt that I will get even one answer :) My guess is that not a single undocumented cross-browser JavaScript feature exists. Let's first wait for the first valid answer... –  Šime Vidas Nov 8 '10 at 19:18
add comment

4 Answers

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
share|improve this answer
Yes, I am aware that prior to the publishing of the 5th edition, there were several features already "out there". However, for this topic I am exclusively interested in features that are cross-browser and undefined in the 5th edition. I am not interested in ES3-to-ES5 features. The example with the leading-zero number sounds promising (although it might not be considered a feature). –  Šime Vidas Nov 8 '10 at 17:15
@Šime: Ok, I have talked about the ES3-ES5 gap just for your JSON example, it is exactly in the same position. Yeah, 08 it is for sure an ancient bug, it has been on implementations since 1995!, it also known as "noctal". More info on this... –  CMS Nov 8 '10 at 17:27
@Šime: I've forgotten an important non-standard feature, Callable RegExps, see my edited answer... –  CMS Nov 13 '10 at 21:07
Unfortunately it doesn't work in IE (I get an "TypeError: Function expected" in IE9 beta). I guess that there are dozens of features in Mozilla's JavaScript implementation that got picked up by the other alternative browsers. However, I am searching for cross-browser non-standard features, specifically features that are implemented in both Mozilla's JavaScript and Microsoft's JScript dialects. –  Šime Vidas Nov 13 '10 at 22:08
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
innerText if/when it is speced, will probably not be in any part of an EcmaScript standard. I believe the related innerHTML is already part of HTML 5 and another logical home would be DOM Level 2 (w3.org/TR/DOM-Level-2-HTML/html.html#ID-011100101) –  Mike Samuel Nov 8 '10 at 16:28
@Robusto Well, The ECMAScript standard is both: there is stuff in there that got in because it was already implemented in major browsers, but there is also stuff in there that is based entirely on the expertise of the standards body and browsers still have to implement it. For example, the strict mode was standardized one year ago (with ECMAScript 5th edition), and we are still waiting for the first browsers to support it (IE9 and FF4). –  Šime Vidas Nov 8 '10 at 17:03
@Mike Samuel: At that point in my discourse I had moved past a discussion of ECMAScript to a more general discussion of indvidual browser makers vs. standards bodies. –  Robusto Nov 8 '10 at 17:08
@Šime Vidas: Good point. The trouble is, it may never be fully supported. I think of all the energy I wasted on XHTML, which is water under the bridge now. –  Robusto Nov 8 '10 at 17:15
@Robusto I don't know about IE9, but I am confident that the other browser vendors will implement strict mode pretty soon (like in a year or so). Let's just hope that IE9 does it. –  Šime Vidas Nov 8 '10 at 17:21
show 2 more comments

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.
share|improve this answer
1. that feature is not cross-browser (different browsers interpret if differently), so it doesn't qualify as an answer, 2. what do you mean by "they agree on insertion order"?, 3. I am very weak at regular expressions, so I am going to need a confirmation on this, 4. Could you please elaborate on that? Do you mean frames as in iframes? –  Šime Vidas Nov 8 '10 at 16:50
@Šime 1. Granted. Semantics differ. 2. By insertion order, I mean that the order keys are returned in is the order they were inserted (layered by depth in the prototype chain), though different interpreters differ over what happens when a property is deleted during for...in iteration and other corner cases. 3. You don't have to be strong in regular expressions. See the CharacterEscape production in chapter 15.10.1 of the spec, and note that the IdentityEscape production says "SourceCharacter but not IdentifierPart" and that "$" is an IdentifierPart. 4. Yes. An iframe is a kind of frame. –  Mike Samuel Nov 8 '10 at 21:32
2. and 3. are not distinct features, but "details" bound to existing ECMAScript features. What I am asking for are full-blown distinct cross-browser features. 4. goes beyond the scope of ECMAScript. Interaction between web-pages is documented in browser-related APIs (like DOM and HTML5). –  Šime Vidas Nov 8 '10 at 21:58
add comment

Your Answer


