ecmascript 5 and the script tag
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: 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.
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: 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:
-
RFC 4329 (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. -
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. -
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).
On Apr 16, 2009, at 3:17 PM, Brendan Eich wrote:
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.
Er, "ES4-like namespaces."
ES5 is easier to type!
Watch out for the Start Trek Movie effect (odd numbers suck, even
numbers rule! ;-).
Thanks, Brendan, for an excellent summary of these issues. The question of script versioning, going forward, is of considerable interest to Microsoft/IE so we agree it is something that needs to be discussed and address, probably in the context of TC-39.
I just had a couple of things to add:
As, Brendan pointed out to me sometime in the past, the script type and version can be globally defaulted for a page using the "Content-Script-Type" Meta tag (www.w3.org/TR/REC-html40/interact/scripts.html ). We should probably also consider what, if anything, is globally implied about the global ECMAScript environment versions by the use of that tag.
- RFC 4329 (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. I think there would be considerable resistance to outright rejection of scripts that specify unknown or unsupported versions. The fear would be that we would reject too many unnecessarily over-specified version requests that might arise from copy and paste page authors.
- 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 (blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx ). We'll see how it works out...
On Apr 17, 2009, at 12:26 PM, Allen Wirfs-Brock wrote:
- RFC 4329 (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 (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!
-----Original Message----- From: Brendan Eich [mailto:brendan at mozilla.com]
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 (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!
That's right, it's an all-or-nothing configuration of the global object and the other built-in objects accessed via it. I would think that a similar interpretation might reasonably be applied to a version specified in the "Content-Script-Type" meta tag.
If a script (or Program) has the 'use strict' directive is there an api or flag for querying if the script is 'strict'. Both at the ecmascript level and at the api c/c++ level. Or should the developer (either in ecmascript or c/c++) examine the first line of source code for the 'use strict' directive. (The same goes for functions).
There currently isn't any such API and it is debatable whether or not one is actually needed.
In most cases, "strict mode" will be explicitly specified in lexically enclosing code (ie, in the same source file) so the code hypothetically wanting to make this test should already know whether or not it is strict mode code.
The only situation where strict mode might not be lexically obvious would be code that is injected via a direct call to eval. The strictness of direct eval'ed code (that does not have a "use strict" directive) is determined by the strict mode of the caller of eval so if the source code passed to eval came from a "foreign" source it might not have been known when it was written whether or not is was going to execute in strict mode.
There are a number of coding idioms that could be used to dynamically determine whether or not code is operating in strict mode. I guess the question really is whether those idioms are adequate for the above eval based scenario.
On Mon, Apr 20, 2009 at 1:03 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
[...] There are a number of coding idioms that could be used to dynamically determine whether or not code is operating in strict mode. I guess the question really is whether those idioms are adequate for the above eval based scenario.
if (function(){return this;}()) { // non-strict case } else { // strict case }
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: 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?
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?