Open makotokato opened 2 years ago
Cannot. Blink and Gecko implement window.screen.orientation object even if Desktop version that is "lock" is unsupported, so it doesn't work.
-- Makoto
2022年1月31日(月) 16:14 Thomas Steiner @.***>:
Window.orientation https://developer.mozilla.org/en-US/docs/Web/API/Window/orientation is deprecated. You should instead use Screen.orientation https://developer.mozilla.org/en-US/docs/Web/API/Screen/orientation, which you can properly feature-detect via the snippet below:
if ('ScreenOrientation' in window) { // Supported.} `
— Reply to this email directly, view it on GitHub https://github.com/w3c/screen-orientation/issues/206#issuecomment-1025443201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLVWVBD4VILBZCD7DWZ4DUYYZGDANCNFSM5NFHUPBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
Sorry, yes, I realized this as well, which is why I deleted the comment. I guess it really boils down to try..catch
ing.
The only way to allow this would be to add a new method. However, this may never succeed for a variety of reasons. For example, the user may prevent the screen from being rotated for accessibility reasons. Then, privacy, we wouldn't want to reveal that fact about the user.
I think we should also consider gating this API on a user gesture, but it's a separate issue.
So yeah, I think at a minimum, we might need a supportsLocking
boolean or something, because locking to "any" is still a kind of locking.
The use case being, if you are building a UI that has rotate buttons, it doesn't make sense to enable them or show them if you can't rotate the screen.
Alternatively (I'm not sure this is better): we could tell user agents to not expose the .lock()
on platforms they are sure don't support locking at all (e.g., most desktops).
Alternatively (I'm not sure this is better): we could tell user agents to not expose the .lock() on platforms they are sure don't support locking at all (e.g., most desktops).
We might want to build a pattern for this. Could be great if we can have a list of APIs that always fail on certain session-permanent situation (that never changes in the current session).
@domenic is pushing a pattern of sorts whereby we use supports()
static methods (see HTMLScriptElement
for instance). That seems somewhat reasonable here. Could maybe also be used to determine whether a platform supports multiple portrait orientations or not (needs use cases first).
Cool, but I mean specifically for things that always fail, since it doesn't quite make sense to have functions that are never going to work.
That pattern is more for things which are not detectable in other ways, e.g. declarative markup features. In this case, just trying to call the function and seeing if it fails seems better... try/catch is just as good as if/else, in general.
@domenic, the problem here is that:
So, imagine (this would be really bad for users):
// lets' figure out what's supported
const supported = [];
for (const o in orientations) {
try {
await screen.orientation.lock(o);
supported.push(o);
} catch { continue; }
}
screen.orientation.unlock();
showUI(supported);
Indeed, try/catch only works if you're guaranteed the try never side effects. That's not the case here. Anyway, it sounds like ScreenOrientation.supports()
is a thing we could do.
Just thinking out loud here... a .canLock()
method could be an alternative.
To return true, the .canLock()
method presupposes that:
(The only thing it wouldn't check for is transient activation)
Additionally, I think all the preconditions of .canLock()
can be checked synchronously: it would basically perform all the synchronous checks that .lock()
performs before doing its "in parallel" steps.
Wouldn't that prevent using the API when you're not fullscreen to detect if you can go fullscreen and change the orientation?
yes, indeed. Ok, so scratch checking the preconditions.
If we assume the following invariant:
.lock()
must support all orientations in one way or another, even if those orientations get mapped to something else (e.g., landscape-secondary -> landscape-primary, natural -> portrait-primary).
Then that only requires a single check: ".canProbablyLock" (boolean) which would be: "they're nothing preventing user agent from attempting to lock the screen orientation".
On desktop platforms, this would return false
: it's not common convention to support lock()
'ing.
On other platforms, it would return true
- but .lock()
might still fail for a number of reasons.
Some down sides:
.lock()
at all. Just noting that it is hypothetically possible that a user could transfer the document from one "desktop class" screen to a mobile device, which could allow changing orientation. So this may require a companion event.
It might be prudent to go down the CSS route with this, as the primary use case revolves around showing/hiding bits of UI.
Would it be fair to say that the ability to change orientation is really describing a media feature? Like, can-lock-orientation
:
@media screen and (can-lock-orientation) {
}
Doesn't seem entirely unreasonable. 😊
@makotokato, what do you think? Should we pursue the CSS media feature route?
@makotokato, gentle ping. Would like gauge your level of interest before I set about specifying it.
I guess that it may not better to use media query. If using media query, I guess it is better to add orientation-lock
media feature like display-mode
of full screen. orientation
feature doesn't have all information of orientation lock.
I vote orientation.canLock
.
While I'm agnostic to the method used, it does seem potentially useful to expose a 'can probably lock' signal. Based on my novice reading of underlying OS APIs, user agents may be incapable of representing signals stronger than 'probably', right?
(If this is already discussed, please close this)
When I look this spec, I cannot find feature detection section. Even If
orientation.lock
isn't supported, Blink and Gecko have this method inorientation
. Then when calling it, NotSupportedError is throw if browser doesn't support it.For feature detection of
orientation.lock
, is there a way of feature detection without usingorientation.lock
like following? And I hope that we add feature detection section forlock
.