Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

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