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

>> 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. The main  
> downside is that this is more loose than is needed and could  
> technically allow crazy unreasonable things. 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.
> 
> Regards,
> Maciej
ECMA-262 allows (in 15.1) the prototype of the global object to be anything (including a host object with catchall semantics, or with properties existing for all names, just with value undefined, custom [[Put]] and [[Get]], etc.). Would implementing WindowProxy on that object and Window on the global object solve the use cases?
Is there actually a comprehensive list of use cases for this splitting anywhere, to facilitate checking any potential solutions against them?

Best regards,

Krzysztof
HTML WG

Received on Friday, 25 September 2009 23:35:54 UTC