On 25/11/2010, at 07:12, RobG wrote:
> On Nov 25, 12:46 pm, Jorge Chamorro <[email protected]> wrote:
>> On 25/11/2010, at 03:12, RobG wrote:
>>> On Nov 24, 9:48 pm, Jorge Chamorro <[email protected]> wrote:
>>>> Quoting Mr. Brendan Eich, here, FYI :
>>
>>>> "The ECMAScript global object is not on the prototype chain of some other
>>>> (Window) really-global object. The two are the same (which means Window
>>>> must not be a "host object" in ES5 terms; see 8.6.2). ECMA-262 requires
>>>> builtins such as parseInt and eval to be "own" properties of the global
>>>> object (|this| in global code, AKA |window| and |self| in browsers)."
>>
>>> There is no point to quoting comments out of context with no link or
>>> citation.
>>
>> http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/00...
>
> Thank you. That comment is not normative. Consider what Ian Hickson
> says in an earlier thread: "The global object in browsers":
>
> 'For HTML5, this behaviour has been defined in more detail. The
> global
> object is a Window object. This object is per-Document. The object
> returned by the "window" attribute on that global object is actually
> a
> WindowProxy object, which forwards everything to the "current" Window
> object."
>
> <URL: http://www.mail-archive.com/[email protected]/msg01930.html
>>
>
> Note the distinction between "W" for Window, and the lower case "w"
> for the window attribute. In the realm that these guys are discussing,
> "Window" is not "window". Now apply that to your Brendan Eich quote.
Because in a browser -unlike in the ES specs- there's more than a global
object, exactly one per window/frame/iframe.
> Regardless, onorientationchange is not a built-in property or object.
> It might be native, but that is not relevant here.
It's not relevant, because onorientationchange is not what we're talking about,
we're talking about window, you know.
> At the point it was
> being tested (i.e. before any assignment has been made to it) if it
> has any sensible value it will be a host property or object. If it
> exists, it is a property of window and typeof
> window.onorientationchange might return function, or object, or
> undefined, or null, or unknown, or whatever.
Again, I've got nothing to say about onorientationchange (which is a global,
btw).
> Once an assignment has been made, e.g.
>
> window.onorientationchange = function() {...};
>
> now typeof window.onorientationchange *should* return "function" as a
> native function has been assigned. However, it may not as window may
> not allow an onorientationchange property to be assigned (and we are
> back to "typeof <host object> may return anything").
window is the global object -except in IEs-, so -except in IEs- assigning to a
property of window creates a global... and it's always a valid operation.
> The bottom line, still, is that typeof window.onorientationchange is
> not a reliable cross-browser test for support for the
> onorientationchange event.
On this, we agree. But please stop harping on about onorientationchange.
>>> Window will be a built-in object when it is defined as such
>>> in some version of ECMA-262 (it is not in either ed3 or ed5). Until
>>> then, it is, by definition, a host object.
>>
>> The global object "is not required to follow many basic ECMAScript rules,
>> such as the result of a typeof test" ?
>
> That phrase was referring to the window object, not the global object.
> In most browsers, the window object is effectively the global object,
> which I think is the point Brendan Eich was making. However, it is not
> *required* to be and it has been shown to not be in some browsers.
Right. It has been shown to not be in IEs.
> Even if it is the built-in global object, only those properties that
> are built-in or native must behave per ECMA-262. Host objects and
> properties (like onorientationchange) can do what they like.
But they don't, except in IEs, where its behaviour is absolutely bizarre, most
of the times.
> All this is a red herring and has little to do with an effective
> feature test for event support.
Right.
>>> Any further discussion should be in comp.lang.javascript. You should
>>> take the advice offered there and just let it go.
>>
>> c.l.js... don't even get me started.
>
> Because you know your view is not supported there.
c.l.js... dominated by a bunch of... don't even get me started.
--
Jorge.
--
You received this message because you are subscribed to the Google Groups
"iPhoneWebDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/iphonewebdev?hl=en.
