Enough ... I have gained one piece of useful advice from this entire thread. Namely RobG's comment:
> Why not just attempt to set a listener, plan for a default behaviour if not supported and provide enhanced functionality if it is? On Thu, Nov 25, 2010 at 5:49 AM, Jorge Chamorro <[email protected]>wrote: > 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]<iphonewebdev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/iphonewebdev?hl=en. > > -- 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.
