Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A implementation of the EMCAScript standard is more than code that brings the specification rules to life. The ECMAScript standard is deliberately incomplete:</p> <blockquote> <p>Each Web browser and server that supports ECMAScript supplies its own host environment, completing the ECMAScript execution environment.</p> </blockquote> <p>An ECMAScript implementation must supply a "host environment". In the case of a Web browser, that host environment includes DOM manipulation APIs and other APIs specified by the W3C and WHATWG. The behaviors of (indeed, the <em>existence</em> of) these APIs are not specified by ECMAScript.</p> <p>Objects used to complete the "host environment" of an implementation are called "host objects". Host objects are not bound to follow normal object rules: they may throw errors for property access that would be valid on a native (non-host) object, or they might allow certain actions that would be natively disallowed.</p> <p>JScript and JavaScript might implement their DOM APIs differently. Which implementation is "correct" on some particular point is not a matter of ECMAScript compliance, but rather a matter of compliance with W3C standards. Even if a DOM object seems to exhibit some behavior that runs contrary to "normal" ECMAScript behaviors (like your <code>instanceof</code> error example), it's still legal ECMAScript according to <a href="http://www.ecma-international.org/ecma-262/5.1/#sec-8.6.2" rel="nofollow">section 8.6.2</a>:</p> <blockquote> <p>Host objects may support these internal properties with any implementation-dependent behaviour as long as it is consistent with the specific host object restrictions stated in this document.</p> </blockquote> <p>"Internal properties" here include logical operations like "getting the value of an object's property by name", codified as <code>[[Get]]</code>. A host object's custom <code>[[Get]]</code> implementation might throw an error, or ignore a previously-set property.</p> <p>API differences are distinct from actual <em>language</em> differences. A <em>language</em> difference suggests a difference either in supported lexical grammar or in the behavior of native (non-host) objects. Some differences in actual <em>language</em> include:</p> <ul> <li>JScript allows for <code>cc_on</code> comments that cause <a href="http://msdn.microsoft.com/en-us/library/ie/121hztk3%28v=vs.94%29.aspx" rel="nofollow">conditional compilation</a></li> <li>Mozilla's JavaScript supports the <code>yield</code> keyword, and generators, and a bunch of other stuff that is not in the ES5 spec (but likely will be in ES6)</li> <li><p>All browsers support function declarations in blocks, which is not legal ECMAScript syntax:</p> <pre><code>function foo() { bar(); if(condition) { function bar() { } // this is not legal } } </code></pre> <p>Browsers that support this (i.e., all of 'em) are extending the ECMAScript language. Also, JScript will <a href="http://www.adequatelygood.com/JavaScript-Scoping-and-Hoisting.html" rel="nofollow">hoist</a> <code>bar</code> in that example, while Mozilla's JavaScript will not. This is because the two browsers have extended the ECMAScript language in incompatible ways.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload