On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we
have good collaboration without requiring every TC39 member to join
w3c (if possible).
Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.
Are invited experts time-bound in some way? We learned in Ecma that
experts were to be invited to one meeting only.
Do we have to agree on where the spec ends up before collaborating?
I hope not, especially since it seems likely both ES specs and W3C
ones may need to contain sub-specs that hook together, possibly
involving common pieces duplicated among the specs.
We already have a spec in progress and it already has a home, so
starting the conversation with a suggestion to move the work
elsewhere struck me as odd and potentially disruptive.
I've been writing my own opinion, qualified that way. Other TC39
members should opine. I really don't want to grab a spec from w3c,
even if there is some concern about expertise being split awkwardly.
I'm interested in fixing the split, not where the spec or specs end up.
ISO and Ecma will insist on some degree of self-contained status for
the ES specs. We refer to Unicode and IEEE-754 but for foundational
things like the global object(s) and the execution model.
There's probably a better future beyond prototype chains, and I
think the odds of finding that world and colonizing it are greater
if we collaborate somehow. The current situation is making the best
of de-facto standards, rationalizing what's out there.
Indeed, because the variance in what's out there makes life more
difficult for authors. I expect it's not possible to get rid of
prototypes from ECMAScript DOM bindings given the constraints of Web
compatibility.
Yes, the foreseeable future wants backward compatibility. But we might
find a better binding for new APIs, and possibly recast old ones
(minus old stuff that is not actually used much) in new, more usable
clothing.
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?)
are all violating, and likely will continue to violate for the
foreseeable future. That seems like a problem. (Unless we convince
ourselves that the split global object pattern somehow doesn't
actually violate the ECMAScript spec.)
It's a violation, for sure, but no one will be struck down by
lightning. We can live with it a bit longer.
Well, it seems bad to me for the spec to state a requirement that
won't be followed.
Yes, it's bad. Now what?
Specifying more about multiple global objects would be good, but I
think it's not a case where current browser behavior violates the
ECMAScript spec, so it's not really the same issue.
Multiple globals as in frame or window objects, probably not. Although
IE does some very strange dynamic scoping in its window.eval
implementation, or did -- see
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.x_working_docs&cache=cache&media=resources:jscriptdeviationsfromes3.pdf
This is not going to be standardized, so it's an IE bug to fix (if not
fixed already).
There are edge cases to do with split windows and whether you get
exceptions or !== true results, but these are the real multiple global
objects issue I had in mind. Even ignoring multiple frames or windows,
just a single WindowProxy with more than one Window global object is
outside the ES specs, which do not admit more than one global object.
WindowProxy and Window go a step beyond multiple globals, of
course, splitting each global in two (or one proxy and one or more
globals under navigation with cached history).
Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.
ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object.
That's backward: the outermost scope chain object must be the ES
global object, what HTML5 types in WebIDL as a Window.
It's the WindowProxy for that Window (and others forward and back in
session history) that must be bound to |this| in global code, contrary
to ES.
The main downside is that this is more loose than is needed and
could technically allow crazy unreasonable things.
This is not tenable -- the WindowProxy is shared among multiple
globals and possibly cross-origin scripts loaded in multiple globals.
Those globals not current but rather "back" and "forward" in the same
WindowProxy's history must be frozen in an informal sense -- not the
ES5 sense -- but other frames or windows can access certain
WindowProxy properties cross-origin.
But it may not be possible to fully specify the behavior at the
ECMAScript level, since it depends on the notion of navigation.
There may be a way to provide a more narrowly tailored hook.
Narrow tailoring could be good, we may not need navigation or even
multiple globals (either in history or among currently navigated
frames and windows).
Hixie's tests:
http://damowmow.com/playground/demos/global-object/001.html
http://damowmow.com/playground/demos/global-object/002.html
http://damowmow.com/playground/demos/global-object/005.html
002 and 005 behave differently among current browsers.
Can there exist a narrow tailoring that does not include some notion
of navigation, therefore multiple global (Window) objects, and (for |
this| binding) a global proxy (WindowProxy)? Would so narrow a
tailoring be useful and stand alone in ES well?
/be
