Both Gyroscope and Accelerometer APIs are rendered useless in their current state because of web devs inability to stop the content from rotating when the device does. This is a must-fix.

I don't quite understand this bug.

There is currently no way to stop the browser to reflow your content after a orientationchange. So when you rotate a mobile device, your content rotates as well. This is often not desired. If you want to use gyroscope information for instance (i.e. to move a ball on a gameboard), your device will switch orientation randomly and there's no way to translate or manage the action.

This bug is important for phone apps as well. When you put a phone up to your head it changes to a landscape orientation, making it more difficult to end the call, for example. I propose we add this to the <meta name="viewport"> tag. Perhaps something like this: <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, orientation=portrait, orientation-lock=yes">

+1. This makes sense. However, when cluttering the meta viewport namespace, I vote for the inclusion of a nice JS API to control the meta viewport. Something like navigator.viewport.orientation = 'portrait'; A simple key/value object like this might just be enough for the job.

We've been thinking about this for iOS too. Another option we're considering is firing an event after the device orientation has changed but before we rotate the viewport, and allowing the author to preventDefault. Paul's suggestion of a JS flag is also something we're considering - but it would likely be a bitfield of sorts (e.g. supportedOrientations = LandscapeLeft | LandscapeRight) I think we do need a flag in the meta viewport for setting the initial orientation on launch though. Or maybe a new meta keyword.

+ 1 for firing an event after the device orientation has changed.

Seems like all the good ideas are already there: preventDefault for orientation change event - this would be the most useful and important imo. Orientation setters and getters for fine control (and also a way to check what's available). Meta tags (initial-orientation, orientation-lock) for when you really don't need to rotate the device. Least necessary of all, but nice to have. I would use every single one the day you would release them - that's how badly we need them.

+1 to the idea of adding a preventDefault() method to the event fired by the orientation change event or to add something in the viewport meta tag to prevent the page from rotating. I also agree with Kamil Trebunia that we should be able to control the device rotation with a setter. This feature is an absolute must-have for game development.

The meta tag + preventDefault() solution feels natural. In terms of setter API, why not simply have the meta tag's value attribute change kick off the change?

Do we have some form of consensus here? How about an event "orientationwillchange" that is fired before the page rotates? Calling preventDefault() will stop the rotation. The current "orientationchange" event remains the same. Should these events be prefixed? "mozOrientationWillChange" and "webkitOrientationWillChange" (I don't know there is a tendency to camel case things when they are prefixed) Next up, a <meta> tag that suggests what the orientation should be. This works fine for pages launched from a home screen of sorts, but I'm not sure what should happen if you visit such a page. Should the browser rotate if the page says it must? That sounds like a possibly confusing user experience. <meta name="supported-orientations" content="portrait=yes,landscape=no"> available flags are: portrait portrait-upside-down landscape (alias for landscape-left and landscape-right) landscape-right landscape-left (Hopefully they are self-explanatory) I wonder if we need another meta tag for suggesting a launch orientation? Lastly, it seems that people think the API to rotating the device via JS should be setting this meta tag. Agreed?

beforeorientationchange would be a more consistent event name. As an aside, it would be great if these proposals were discussed on a standards list.

(In reply to Anne van Kesteren from comment #11) > beforeorientationchange would be a more consistent event name. Sure. That's me thinking Cocoa. Also, I forgot to mention the important case of the meta tag: no value means supports all orientations. I don't think we need to add an "all". > > As an aside, it would be great if these proposals were discussed on a > standards list. What list? Hopefully one I'm already subscribed to.

Hey Dean, slight changes: - beforeorientationchange (I agree with Anne here) - meta name "orientation" instead of "supported-orientations". I don't think there's need for more verbosity, "orientation" should be pretty self-explanatory imo. - flags: portrait portrait-primary portrait-secondary landscape landscape-primary landscape-secondary This works better for tablets and phones that per default are not in portrait (e.g. Motorola Xoom). Not sure if primary/secondary is better, looking forward to more suggestions. window.orientation uses degrees, which I don't think is any better. - don' think we need a meta tag for launch orientation. If you want to launch in portrait, you set the 'orientation' meta to only portrait. When the page is loaded, you can still use the JS API to override the meta tag. Solves the usecase. - JS API: window.lockOrientation() -> locks the orientation to the current value in window.orientation, writes to meta tag window.lockOrientation({ portrait: 1, landscapePrimary: 1 }) -> locks the orientation to the values passed in, changes orientation when the current doesn't match the passed values. Writes to meta tag. window.releaseOrientation() -> Removes all orientation locks. Rotates the viewport back to the 'natural' orientation if you're currently locked in. E.g. site is in portrait mode, but phone is held so it would be landscape naturally. window.changeOrientation would *not* work, as it would result in all weird side effects (you trigger a change, it rotates and then automatically rotates back as the device isn't locked.. etc).

<meta> would be www-style http://dev.w3.org/csswg/css-device-adapt/ beforeorientationchange would be public-geolocation I guess.

Following a discussion on IRC with Anne, it seems that he was confusing deviceorientation and orientation. The former has a spec which is part of geolocation [1] but doesn't fulfill this API goals. There were a lot of good ideas mentioned in this bug and we should definitely move to a more visible place to continue that discussion. I would suggest DAP WG [2] or www-style. I think DAP would be an appropriate place for the JS API and we should discuss CSS additions in www-style. For those interested, I might begin a discussion in mozilla's dev-webapi mailing list [3] in the next few days to get some feedbacks. [1] http://dev.w3.org/geo/api/spec-source-orientation.html [2] http://www.w3.org/2009/dap/ [3] https://www.mozilla.org/about/forums/#dev-webapi

Saw the spec, has this landed, didn't see any attachments so I wanted to find out if it's just the specification at the moment?

This is a tracker bug. The feature has landed, see bug 720794 and bug 740188.

Not blocking on metabugs for Basecamp.

This has been documented, some time ago ;-)