On Wed, Nov 27, 2013, at 2:52, Marcos Caceres wrote:
> IMHO, it would be confusing to have an app that when you launch it the
> first time locks one way... but when you launch it the next time, locks
> another way.
>
> In the 300 apps we've been cataloguing for orientation [1], there is not
> a single instance of that exhibits this behaviour. I've also never
> personally seen any app do this on startup.
>
> Mounir, what is the use case for locking to "current" on startup? Which
> applications do you know that exhibit this behaviour?
Eh... My understanding was that there was a consensus for this to be
added. I was told that you pointed the iOS UC. I quite agree with you
that it does not sound like a nice UX. I was willing to spec that
because I assumed there was a consensus. If there is not, we should
discuss it further ;)
> > > the one with JavaScript seems more clear to me (as it's more evident that
> > > it's dynamically derived). "current" is kinda weird because setting the
> > > orientation is an async operation, so by the time you work out what
> > > "current" is, it might not longer be the "current" one... so it's kind or
> > > a race condition.
> >
> > Why? If it rotating at the moment you call it, it could just fail, if
> > it is not, it could lock immediately. It is no different from using
> > the window.screen.orientation.
>
> Sure, but it's more about setting expectations. For me personally, using
> "window.screen.orientation" is more explicit about what I want... like:
>
> var current = screen.orientation;
> console.log("ok! locking it to:", current );
> screen.lockOrientation(current);
>
> "current" is more like requesting. That's just me tho.
If 'current' is added, I wouldn't say that there is a race condition
issue because if you lock to 'current' you do not really care about the
actual orientation.
This said, I do not think that 'current' is very useful from the JS API,
it only saves a few characters.
--
Mounir
