- From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
- Date: Tue, 26 Nov 2013 18:03:15 +0100
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: public-webapps <public-webapps@w3.org>
Hi On Tue, Nov 26, 2013 at 5:55 PM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On Wed, Nov 27, 2013, at 3:49, Kenneth Rohde Christiansen wrote: >> a) Will this be a delta from the current orientation? or relative to >> the default device orientation? I guess the former makes the most >> sense. > > Orientation angle compared to the native device orientation. OK, that is fine with me, and it would allow for things like requestOrientationLock(screen.orientationAngle), and we can get rid of portrait-secondary etc for advanced use-cases. >> b) What should happen if the device is already busy changing >> orientation when the request is done? I think failing might make the >> most sense. > > That sounds a bit orthogonal to the thread but I would say that if you > do > screen.lockOrientation(0); > screen.lockOrientation(90); > both calls should succeed even though the orientation might never be > locked to the 0 angle. and what if I do, -90 and 90 300ms after? so it will start rotating in one direction, and it might flip direction? It could of course continue on its current path. So it should succeed if the target value is possible. I am fine with that. > >> When we are moving to promises I would rename it to >> requestOrientationLock though as it fits more inline with other APIs. > > I was not aware of that convention. Do you have examples? (other than > fullscreen) That was my example. I like it more as it really is a request which might be rejected. There are other examples in Blink though: MIDIAccessPromise requestMIDIAccess(optional Dictionary options); and non-promise based requestQuota, requestPermission, requestAnimationFrame, requestAutocomplete. Kenneth -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Received on Tuesday, 26 November 2013 17:03:43 UTC