This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think the API should probably not be exposed if the device do not allow orientation changes. There isn't much value in reading the orientation if the orientation can't change. If it is only a presentation problem, CSS solves that already with media queries.
What is "mobile" here. There are all sorts of laptops which are almost tablets, or are in some cases laptops and in some cases tablets. (Lenovo Yoga for example) So the spec certainly shouldn't say that it is supported on mobile only.
(In reply to Olli Pettay from comment #1) > What is "mobile" here. > There are all sorts of laptops which are almost tablets, > or are in some cases laptops and in some cases tablets. > (Lenovo Yoga for example) > > So the spec certainly shouldn't say that it is supported on mobile only. "I think the API should probably not be exposed if the device do not allow orientation changes." I think the spec should say that ^ What do you think?
I think it is up to the implementation to decide what to do. What is the harm to have the API always there? Also, you can change the screen orientation even on desktop.
(In reply to Mounir Lamouri from comment #0) > I think the API should probably not be exposed if the device do not allow > orientation changes. There isn't much value in reading the orientation if > the orientation can't change. The computer 'device' (if that's what you mean) should be irrelevant. That API is not particularly targeted for mobile devices. It has a broader 'screen' context. > If it is only a presentation problem, CSS solves that already with media queries. No. Media queries don't match for all devices, and we shouldn't assume so. The orientation media query looks at the viewport (in relation to the window width and height, which only solves most modern/mobile or fullscreen view cases), not the screen. The screen orientation can be used to account for that difference. In IE snap-mode for example, you can get a 'portrait' media query on a 'landscape' screen rotation. So the Screen Orientation has a value, for alternatives contexts. (In reply to Olli Pettay from comment #3) > I think it is up to the implementation to decide what to do. > What is the harm to have the API always there? > > Also, you can change the screen orientation even on desktop. Indeed, there are large monitors that pivot from portrait to landscape. And some people have stations with both a vertical and a horizontal screen. Additionally the screen on a fixed Windows touch laptop can be locked to portrait at the system level.
I think we could do the following then: - OrientationType, nothing to do - we can always define it; - OrientationAngle, if the UA can't define it, MUST be 0; - unlockOrientation(), no-op if such things can't happen; - lockOrientation(), the promise would be rejected with "NotSupportedError" exception if the device can't lock the screen orientaiton. Olli and Bruneaux, what do you think of that?
So an implementation could just implement lockOrientation so that it never rejects, but never accepts either.
(In reply to Olli Pettay from comment #6) > So an implementation could just implement lockOrientation so that it never > rejects, but never accepts either. I'm not sure why you say that. The idea is to add a step 0 were lockOrientation would reject with "NotSupportedError" if locking is not supported. Otherwise, it should do business as usual. There should be no situation were a promise is returned but stay in a pending state for ever.
Implementations are allowed to deny locking by rejecting the promise with NotSupportedError. https://github.com/w3c/screen-orientation/commit/6cc33d3e871274963044b8db28f5007ff31b1dd5