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

On Fri, Sep 12, 2014 at 8:07 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote:
>> 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?
>
> "natural" and "primary" have very different meaning. There can be only
> one "natural" orientation for a device, it's when angle = 0. However,
> portrait-primary and portrait-secondary would depend of the context. For
> example, I have two monitors in front of me. They are both in portrait
> orientation but they could both have different angles, if that was the
> case, one device would have angle = 90, one would have angle = 270 but I
> would expect to both be portrait-primary.

I still think "landscape-primary" effectively means "the most natural
landscape orientation" just like "natural" means "the most natural
orientation".

I don't really know that it makes sense to talk about screen
orientation APIs for desktop monitors. In general the best solution
there is likely to not expose the API at all since any attempts to use
the API to accomplish any change would result in really poor UI.

But this is a bikeshedding topic, so I won't fight it.

>> 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."
>
> Isn't "Best Practice 1: orientation.angle and orientation.type
> relationship" what you are looking for?

Ah, I hadn't seen that. For me the natural place to read about the
relationship between those properties is at the description of the
properties themselves.

>> 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?
>
> I believe you found the definition in the specification according to
> your reply.

I think it's likely to result in many implementation bugs if we rely
on this being defined buried inside an algorithm rather than at least
mentioned at the definition of the property.

/ Jonas

Received on Monday, 15 September 2014 22:29:26 UTC