ecmascript 5 and the script tag

[Brendan Eich]

On Apr 16, 2009, at 2:56 PM, Maciej Stachowiak wrote:

> On Apr 16, 2009, at 2:37 PM, kevin curtis wrote:
>
>> Hi
>>
>> Has it been established how browsers will handle ecmascript 5? e.g.
>> <script type="application/ecmascript;version=5"> ...
>> The above is from the es4 proposal with 4 replaced with 5:
>> http://wiki.ecmascript.org/doku.php?id=proposals:versioning
>>
>> Also, how will ecmascript shells process ecmascript 5 scripts?
>> Spidermonkey has the -v flag (as well as the version() builtin):
>> ./js -v 5 -e "print('version: ' + version())"
>>
>> Is it likely that the the c/c++ 'script' objects in the test
>> implementations will have a property indicating the ecmascript  
>> version of
>> the script?
>
> I don't think there is a need for out-of-band declared versioning in  
> ES5 as specified. Browsers can and should handle all scripts as ES5  
> once they implement the standard.

A few things seem worth discussing:

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.

2. Ecma TC39 is the likely standards body to define version parameter  
values for the standard scripting media types from RFC 4329. We should  
add this to the agenda. It came up at the last face-to-face.

3. Before ES5 is supported by all user agents targeted by content  
authors, those authors will have to use a combination of object  
detection and user-agent sniffing to decide whether the ES5 features  
they want are supported. ES5 has little "new" syntax, but getters and  
setters targeting downrev IE are an obvious problem.

The idea of in-band version selection, akin to strict mode's backward- 
compatible pragma syntax, has come up:

"use version 5";  // wait, JS5? JScript5? Oh, ES5!

but this raises several issues:

* Versioning to "opt into" new keyword usage, e.g. let and yield,  
can't work this way, since the downrev engines will not respect those  
keywords and choke on 'let x = 42' and 'yield foo()' (and silently  
misinterpret 'yield(foo())').

* 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.

* How would you set the default for a "page" or "app" (graph of  
connected windows/frames)?

* Whose version? With RFC4329's media type parameter, you know  
application/ecmascript;version=5 is ES5 while application/ 
javascript;version=1.8 is Mozilla's (we respect this, always have --  
we gave up on version selection via <script language="JavaScript1.8">  
however, since IE ignores version suffix there). With "use version 5";  
there is greater distance between the version number and the media  
type used (or not used, rather defaulted) on the script tag -- the two  
may not be in the same file.

So there's actually a lot to discuss!

At the last TC39 meeting we realized that versioning script tags or  
other compilation units to opt into new keywords was a separate issue  
from versioning a shared global object, for which no mechanism exists  
(AFAIK) in browsers or extant web standards.

Opt-in versioning for new keywords is unavoidable in Mozilla's  
experience: we tried adding 'let' and 'yield' by default in JS1.7 pre- 
releases, and had to back off to opt-in; on the up side, ES5 strict  
mode reserves these two along with other future reserved identifiers.

Versioning the global object does not mean multiple version  
"namespaces". We have no goal or requirement for any such thing and  
strong requirements against if the only way to hide new APIs from some  
scripts, where those new APIs (properties) were exposed on the same  
global object to other scripts, amounted to ES5-like namespaces.

The question is: do we need a single-global-object-version opt-in  
mechanism? No such thing has evolved so far (again AFAIK).

/be

>
>
> - Maciej
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss