On Fri, 12 Jul 2013, Glenn Maynard wrote: > On Fri, Jul 12, 2013 at 2:45 PM, Ian Hickson <i...@hixie.ch> wrote: > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > In mobile accelerometer/gyro-based games, you don't want the user's > shifting the device around to cause the screen to change orientation > while they're playing. This means locking the current orientation, > though, rather than a specific orientation (for example, you'd probably > want to unlock it when the user is in a menu and not actually playing > the game).
I could see locking the orientation in full-screen mode, sure (as Kornel suggested in a later e-mail, see below). > On Fri, Jul 12, 2013 at 7:07 PM, Ian Hickson <i...@hixie.ch> wrote: > > > > Sure, some orientations might be better -- just like the HTML spec is > > more readable on a taller large screen than on a landscape phone > > screen -- but if the user wants to play the other way, it seems wrong > > to be able to prevent it. > > In practice, game developers are rarely willing to spend the time to > make their games work well in both portrait and landscape. That's certainly true, but the reality is that on the Web a web browser window might be any number of dimensions, so that's a problem you have to deal with regardless. > The Web solution is probably not to lock the display, though, but to > letterbox the display if the window's aspect ratio is too far off, as > with videos. Well, not so much letterbox as just fit in the given width, leaving a lot of space at the bottom (or centering vertically), sure. On Fri, 12 Jul 2013, Jonas Sicking wrote: > On Fri, Jul 12, 2013 at 12:45 PM, Ian Hickson <i...@hixie.ch> wrote: > > On Thu, 18 Apr 2013, David Bruant wrote: > >> > >> Currently working on a web project where tablet support (iPad > >> especially) is important, I'm facing a need which apparently the > >> platform doesn't support. I would need to lock the screen in > >> landscape mode. > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > If the content is sized better for portrait or landscape, then it's > generally good for the user if the mode is forced by the application. I disagree. The author doens't know better than I do what I want. > Otherwise the user will have to scroll, or will see content that is > smaller than it otherwise would be. Or rotate the device, which the user will have to do regardless if the application forces it. > Users can't always rotate the screen themselves to control this since > many times users disable screen rotation controlled by gravity. If the user disables it, the user can just as easily re-enable it... Also, if the user disabled it, I think it's even more of a reason not to rotate the display for the user. > Common cases when this is done is if they find that the screen too often > erratically rotates due to the user moving around the device. Another > scenario is if laying down with the device in bed in which case rotating > according to gravity will result in a screen that is off by 90 degrees > from the users orientation. Indeed. > The reason we don't do this on desktop systems is that desktop platforms > generally don't let the user adjust to an application rendering itself > sideways to fit in the current window size. On tablets and mobile > platforms, there is an established UI paradigm of simply rotating the > device when content renders itself sideways. A quite annoying UI paradigm... > If we don't provide webplatform support for setting orientation, content > will simply use things like CSS transformation to render itself > sideways. This results in a much poorer experience for the user since it > interacts poorly with for example gravitational orientation. I.e. the > user might see the content sideways, then rotate the device in order to > see the content correctly, resulting in the device then changing > rendering orientation. The page will then detect this and undo the > transformation. The result is a lot of back and forth which is > disruptive to the user. Any automatic rotation not under the control of the user, or locking of rotation not under the control of the user, is disruptive to the user. > Another problem that is likely to occur is authors accidentally applying > CSS transformation in on devices where the user can't reorient the > device. > > Not to mention that using CSS transformation will likely result in > content that has to use more javascript driven layout with all the > downsides that come with that. I'm certainly not advocating for authors manually rotating the content to be at 90 degrees to the device's native orientation. > By supporting pages setting the orientation we can put the user more in > charge by ignoring that orientation when appropriate. Such as on devices > where changing the orientation is bad, or when the user has explicitly > requested the orientation not to change. I'm confused as to what UI you are envisaging here. Would this be in addition to, or instead of, the native UI to prevent rotation? > In Firefox we have implemented the screen orientation spec > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html That is unfortuate. I don't think that API puts the user first. (I also don't understand what it means in non-mobile environments. It seems very medium-specific, which is not very Webby.) > However I personally would like to see declarative support in addition > to the script API. Can you elaborate on what user problems we are solving here and what such a declarative mechanism would look like? On Mon, 15 Jul 2013, Roger Hågensen wrote: > On 2013-07-13 06:17, Glenn Maynard wrote: > > > > Changing orientation is disruptive. > > > > I can hardly imagine how obnoxious Web browsing would be on a mobile > > device, if every second page I navigated to decided to flip my device > > to a different orientation. This feels like the same sort of > > misfeature as allowing pages to resize the browser window: "best > > viewed in 800x600" (so we'll force it), "best viewed in portrait" (so > > we'll force it). > > I have a tablet here that does that with a few apps. And one of them > actually does it within itself during certain parts of the program. > > And I can testify it's annoying as hell. For those curious it was a > banking app. And the main menu is forced/locked. But the rest like > account activity etc. is not. And you can imagine how stupid it is when > you have to rotate the tablet each time you go back to the main menu. Indeed. > I find responsive and scalable design (so it looks good) on multiple > aspects ratios and multiple PPIs is a must for modern coding. I agree. It also seems to be the only way to actually make things work on some media, such as desktop windows, which can't be rotated yet can have any aspect ratio. On Sat, 13 Jul 2013, Tobie Langel wrote: > > It is not uncommon for mobile experiences to rely on the accelerometer > as an input mechanism, for example to control page scrolling (e.g. > Instapaper) or for gameplay. > > In such cases, auto-rotation of the viewport is completely disruptive to > the user's experience and needs to be inhibited. Sure, but that's an OS-level feature. > So this isn't so much about forcing orientation as it is about > inhibiting auto-rotation. This would only work if the page was already in the orientation the user wants, but how can we ensure that? > Your desktop comparison is inadequate, as there aren't comparable > auto-rotation mechanisms there. It would be equivalent to forcing a particular window size. On Mon, 15 Jul 2013, Kornel Lesiński wrote: > > Since specific, locked screen orientation is mostly needed in games, and > forced rotation is disruptive to other things on the screen (e.g. moving > buttons/addressbar to other physical edge of the screen), maybe it > should be tied to the Fullscreen API? > > element.requestFullscreen({orientation:'landscape', autorotation:false}) That makes sense to me. Anne? In any case, this seems to be out of scope of HTML, so I haven't added anything to the HTML spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
