ecmascript 5 and the script tag

[Brendan Eich]

On Apr 17, 2009, at 12:26 PM, Allen Wirfs-Brock wrote:

>> 1. RFC 4329 (http://www.ietf.org/rfc/rfc4329.txt) mandates user agent
>> parsing of version parameter, but does not specify legal values. Not
>> all user agents comply (does IE8? I have not tested). This may become
>> important over time, so bug-fixing soonest is best.
>
> To the best of my knowledge, IE8 still ignores the version parameter  
> on script tags. The issue, is what to do with the version request  
> after it is parsed.  I think, that we would find considerable  
> support within Microsoft for interpreting the version as an explicit  
> opt-in requests for new functionality (or at least new syntax) where  
> the new functionality is not accessible without an explicit opt-in.

That's good to hear.


> I think there would be considerable resistance to outright rejection  
> of scripts that specify unknown or unsupported versions.

Here is what RFC 4329 has to say:
    Updates of this document may introduce new optional parameters;
    implementations MUST consider the impact of such an update.  For the
    application/ecmascript media type, implementations MUST NOT process
    content labeled with a "version" parameter as if no such parameter
    had been specified; this is typically achieved by treating the
    content as unsupported.  This error handling behavior allows
    extending the definition of the media type for content that cannot  
be
    processed by implementations of [ECMA].

> The fear would be that we would reject too many unnecessarily over- 
> specified version requests that might arise from copy and paste page  
> authors.

Maybe; any evidence for that? IE coerces media types elsewhere (CSS,  
historically), flouting the RFCs. In general this just makes for more  
interop problems. Those who configure their servers well are punished  
by IE overriding wrongly based on sniffing or a filename suffix, those  
who misconfigure still don't get "Do What I Mean" because that never  
works, in the long run or at scale.

On the other hand, script type= attribute overrides content-type  
header, in all browsers I know of, not just in IE.

None of this seems particularly "evidence-based" :-/. But the current  
cross-browser behavior is a settled de-facto standard.

Anyway, RFC 4329 is pretty plain. It leaves some wiggle room for  
perhaps evaluating the script tag content such that the content can  
tell it is not running under the configured version, instead of being  
run observably as if fetched or served with a version-free type. We  
should draw on expertise from Björn Höhrmann and others in this thread.


>> * Versioning to opt into new APIs on Object, or in the global object
>> (JSON, conspicuously, in ES5) will not work as expected: precedent
>> from ES1-3 and ongoing in Mozilla's JS number line, and in the
>> prototype ES5 implementations I've seen (Mozilla has one in open
>> source; there's a JScript DLL I've seen in action from Microsoft, not
>> released) all expose new properties unconditionally.
>
> IE8 does have a form of global object versioning.  In IE8 the JSON  
> object and associated toJSON methods,  the methods  
> Object.defineProperty and Object.getOwnPropertyDescriptor(they only  
> supports DOM objects in IE8), and a few other minor standards/interp  
> conformance fixes are only provided for pages/iframes operating in  
> "IE8 standards mode" (the default mode).  This was a very late  
> change in the IE development cycle a was primarily made in response  
> to user feedback concerning the IE8 release candidate (http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx 
>  ). We'll see how it works out...

Sorry, I think you mentioned this and I forgot. But this is an all-or- 
nothing mode, I take it -- not a subjective-programming (ES4  
namespaces) facility where one script might run in IE7 mode and see no  
JSON property on the very same global object on which another script  
in IE8 mode sees the ES5 JSON object. Or so I hope!

/be