This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
'orientationchange' should fire on Window so that there can be a <body> event handler for it. That would also mean we don't have to retroactively turn Screen into an EventTarget object. This would also make this API more consistent with the rest of the platform.
(In reply to Ian 'Hixie' Hickson from comment #0) > 'orientationchange' should fire on Window so that there can be a <body> > event handler for it. That would also mean we don't have to retroactively > turn Screen into an EventTarget object. This would also make this API more > consistent with the rest of the platform. That would conflict with the current window.orientationchange event that already exists on webkit mobile devices. We can't mix the two APIs/features.
What's the difference between the webkit one and this spec's one?
(In reply to Ian 'Hixie' Hickson from comment #2) > What's the difference between the webkit one and this spec's one? Most people get confused between the two. Mainly, the webkit one is only exposed for mobile devices and provides rotation angles at the window level, while this one provides screen.orientation(s) with primary and secondary notions, and the ability to lock the screen. I have tried to highlight the distinctions in this thread: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0479.html My take, is that the webkit legacy api should only apply to device embedded screens like a mobile phone, watch, etc (i.e. at the window level), and keep that legacy alive by implementing it into IE and Firefox for mobile devices. (separately from this api) https://bugzilla.mozilla.org/show_bug.cgi?id=920734 Mozilla seems inclined to implement the webkit window.orientation for mobile and has two bugs filed to that effect. I don't know about IE. It seem like IE saw this API as a better substitute to window.orientation, but that's not really clear. This spec's one can apply to a broader concern of screens, either remotely attached to a device or embedded. IMO, the locking aspect of the screen is tricky because a viewport does not necessarily reflect the full coverage of a monitor. The viewport could be windowed and not necessarily cover the screen like a mobile device does. Yet this Screen Orientation API is trying to address mobile devices at the same time for locking purpose, and there has been confusion with specs implementation in that regard. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054#c4 Along Mounir mentioned incorporating angles into this API to allow mapping to angles: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698 So things still need to be sorted out.
The fact that we have bugs on file doesn't mean much. We've been reluctant to add window.orientation since the API appears to be partially broken. It returns 0 when the device is in the "default" orientation. If that orientation is landscape or portrait mode is device specific. That said, if window.onorientation seems like it might fire under the same circumstances, so we might be able to reuse that event. But I don't feel strongly. I don't think that being able to use <body onorientationchange="..."> provides that much value.
(In reply to Jonas Sicking from comment #4) > The fact that we have bugs on file doesn't mean much. Well I only speak of Mike Taylor's expressed agreement via twitter, with the fact that the Screen API lacks that ability to detect left and right rotations. > We've been reluctant to add window.orientation since the API appears to be > partially broken. It returns 0 when the device is in the "default" > orientation. If that orientation is landscape or portrait mode is device > specific. I don't really understand the reluctance. window.orientation may be broken as per initial Apple documentation of portrait default. But it's consistent around 0 default with mobile devices. It can be specced and understood as such in Gecko. 'landscape' or 'portrait' in relation to the viewport are not technically tied to the device anyway. They only are if the viewport match the screen context. So the fact that the relation between angles and window/viewport orientation is not consistent is technically correct. No one should expect more from window.orientation than what it currently provides. That is: Giving the angle relationship of the window in relation to the device default. > But I don't feel strongly. I don't think that being able to use <body > onorientationchange="..."> provides that much value. Right, and a body handler would be irrelevant to screen orientation, so those value wouldn't necessarily match.
I use <body onfoo=""> to hook Window event listeners all the time, FWIW. Anyway, sounds like this spec should subsume the legacy non-standard API (ideally in a backwards-compatible fashion that augments the legacy, but failing that, by replacing the legacy API with a new non-conflicting one), so that we end up with just one API. Either way, it doesn't seem to be a problem to reuse the event handler here, since as Jonas says, surely the events would fire at the same time.
I applied the change. The event now fires on the Window object: https://dvcs.w3.org/hg/screen-orientation/rev/f526e8b215f4 We might want to move the event handler to the HTML specification.
(In reply to Ian 'Hixie' Hickson from comment #6) > I use <body onfoo=""> to hook Window event listeners all the time, FWIW. > > Anyway, sounds like this spec should subsume the legacy non-standard API > (ideally in a backwards-compatible fashion that augments the legacy, but > failing that, by replacing the legacy API with a new non-conflicting one), > so that we end up with just one API. Either way, it doesn't seem to be a > problem to reuse the event handler here, since as Jonas says, surely the > events would fire at the same time. I don't think they will. As inconvenient as it may be to consider, I believe there is a conflict with that, as further explained at: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0075.html
Mounir: Happy to take the event listeners to HTML; if you want me to do that, file a bug at http://whatwg.org/newbug or reassign this one to me. Thanks!