Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

"Second, I'm still very worried that people will interpret
screen.orientation.angle=0 as portrait. I don't expect to be able to
convince people here to remove the property. However I think it would
be good to at least make it clear in the spec that the .angle property
can not be used to detect portrait vs. landscape."

Maybe it should be clear in the spec if it

1. disregards coherence with other orientation related specs and their
implementations or
2. tries to look over the fence and address issues like: "on any particular
device, setting landscape-primary, if the user holds the device like *this*
the XYZ-readings from DeviceMotion will be *that*"  IMO - a very, very
common use case and a reason to use orientation lock in the first place.

if (1) - go ahead with whatever is done
if (2) - then *please* try to fix it (and involve DeviceMotion/Orientation)

I realize that there are also issues in the DeviceOrientation camp, where
at least iPhones, some Android devices and FirefoxOS KEON seems to report
back values with different orientation and scale using the same webapp
test.  It could be interesting to check with some modern "Landscape
oriented" devices (how the manufacturers decided to hook up the
accelerometer, the mapping to the web engine and if it should flip on
screen rotation) - but they seem hard to find these days.

Anyway - besides the complains about the spec itself, it's nice that there
is at least *some* sort of orientation locking available now ;). Check
these to see the differences between devices:

https://eu1.empirikit.com/mobile/darts/
and
https://eu1.empirikit.com/mobile/accdemo.html

(demos in flux.. I can send a copy if seen valuable)

br
Lars

On Fri, Sep 12, 2014 at 12:52 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow <art.barstow@gmail.com>
> wrote:
> > Mounir and Marcos would like to publish a LCWD of The Screen Orientation
> API
> > and this is a Call for Consensus to do using the latest ED (not yet in
> the
> > LCWD template) as the basis:
> >
> >   <https://w3c.github.io/screen-orientation/>
>
> Sorry, my first comment is a naming bikeshed issue. Feel free to
> ignore as it's coming in late, but I hadn't thought of it until just
> now.
>
> It's somewhat inconsistent that we use the term "natural" to indicate
> "the most natural direction based on hardware", but we use the term
> "primary" when indicating "the most natural portrait/landscape
> direction based on hardware".
>
> Why do we use "primary" for one and "natural" for the other?
>
> Second, I'm still very worried that people will interpret
> screen.orientation.angle=0 as portrait. I don't expect to be able to
> convince people here to remove the property. However I think it would
> be good to at least make it clear in the spec that the .angle property
> can not be used to detect portrait vs. landscape.
>
> A informative note in the description of the angle property saying
> something like:
>
> "The value of this property is relative to the "natural" angle of the
> hardware. So for some devices angle will be 0 when the device is in
> landscape mode, and on other devices when the device is in portrait
> mode. Thus this property can not be used to detect landscape vs.
> portrait. The primary use case for this property is to enable doing
> conversions between coordinates relative to the screen and coordinates
> relative to the device (such as the ones returned from the
> DeviceOrientationEvent interface).
>
> In order to check if the device is in portrait or landscape mode,
> instead use the orientation.type property."
>
> Also, I can't find any normative definition of if orientation.angle
> should increase or decrease if the user rotates a device 90 degrees
> clockwise?
>
> / Jonas
>
>