Re: Device Orientation specification co-editor

Hi Rob,

On Sun, Feb 16, 2014 at 8:15 PM, Rob Manson <roBman@buildar.com> wrote:
>
>> It would be great if you could send us some pictures/3D models you have
>> that you think would clarify the specification.
>
>
> We'll refine what we've got then send them through for discussion.

Looking forward to your feedback :)

>
>> Was there anything in particular you would like to see improved in the
>> current specification aside from visual examples?
>
>
> I think if we want more general js developers to use the API successfully
> then some more worked examples might be good - and no I don't think the
> current matrix-based examples are what most js devs would think of as
> "worked examples" 8).

I agree and we should discuss what examples to include could be more
helpful for web developers.

FWIW, I think the current worked example included in the spec is
useful but a little hard to parse for developers. Here is a JavaScript
implementation of the worked example currently provided in the
specification: http://people.opera.com/richt/release/tests/orientation/spec_workedexample.html.

It may be good to include accompanying JavaScript code for any
mathematical notation used.

>
> I know there's a lot of blog posts explaining how the API works...but I
> couldn't find any that dealt with the additive nature of Euler angles - they
> really just show how to access the events and the data returned. I know it's
> a standard part of this concept...but it took us a while to work out this
> issue as we were thinking of the 3 axes as independent. It was really only
> when we noticed the third "code extract" in the spec that we realised the
> flawed assumption in our code/approach.
>
> {alpha: 270 - alpha,
>        beta: 0,
>        gamma: 90};
>
> Just describing this more explicitly would lead to more developers
> understanding this and then better implementations.

Perhaps we can clarify this with additional JavaScript examples being
added to the spec. Let us know what would you like to see.

>
> Another issue we have is with capability detection, especially on excluding
> PC browsers.
>
> Many PC browsers have the window.DeviceOrientationEvent function
> defined...yet never ever return a deviceorientation event. e.g. this code
> registers a listener that never gets called...so we are left falling back to
> some sort of timeout based assumption 8/
>
> if (!!window.DeviceOrientationEvent) {
>   window.removeEventListener('deviceorientation', function() {
>     // clearly supported
>   }, true);
>   // not clear at all until deviceorientation event called or some timeout
> occurs 8(
> } else {
>   // clearly not supported
> }
>
> This is the same for both DeviceOrientation and DeviceMotion.
>
> Having browsers NOT implement window.DeviceOrientationEvent unless they
> truly do support it would be best. But I'm open to discussion of other
> options or tips on how we could code around this more effectively.

Would the following addition to the specification suffice here?

"When support for a feature is disabled (e.g. as an emergency measure
to mitigate a security problem, or to aid in development, or for
performance reasons), user agents must act as if they had no support
for the feature whatsoever, and as if the feature was not mentioned in
this specification. For example, if a particular feature is accessed
via an attribute in a Web IDL interface, the attribute itself would be
omitted from the objects that implement that interface - leaving the
attribute on the object but making it return null or throw an
exception is insufficient."

Of course, this would be entirely dependent on implementers following
this requirement.

Until then it is likely developers will need to fallback with
timeout-based DeviceOrientation feature detection as you mention
above. I wonder whether we should include that in the spec considering
it is (hopefully) a short-term problem.

>
>
> Plus, as I mentioned earlier. I think Rich's point about having some way
> from the API to clearly know how the device frame is related to the origin
> orientation would be very good. Maybe just describing how it could/should
> relate to screen-orientation would be useful - but I know that's still just
> in draft http://www.w3.org/TR/screen-orientation/

Yep. Just to clarify this issue: the key problem is if a user loads a
web page using a non-default screen orientation (i.e. they rotate
their screen and then load the page or the user rotates their screen
at runtime). A web developer using DeviceOrientation is always
required to currently do the following:

1. Obtain DeviceOrientation data as provided by our DeviceOrientation
Event specification.
2. Hotfix returned DeviceOrientation data depending on the current
screen orientation (if window.orientation <> 0 then real device
rotation no longer matches provided the default DeviceOrientation
data).
3. Listen for ongoing window.onorientationchange events and hotfix
DeviceOrientation data whenever this event fires and
window.orientation !== 0.

We already find that _most_ DeviceOrientation demos do not respond
correctly as screen orientation changes [A] [B] [C]

[2] http://www.html5rocks.com/en/tutorials/device/orientation/deviceorientationsample.html
[3] http://www.jeremyselier.com/s/demo/device_orientation.html
[4] http://wellcaffeinated.net/demos/device-orientation

There are a few different fixes we could pursue here at the
spec/implementation level:

1. We could mandate that DeviceOrientation should always align to the
current screen orientation (i.e. implementations hotfix
DeviceOrientation to match screen orientation changes themselves).
2. We could provide developers with the necessary JavaScript-based
DeviceOrientation axis hotfixes required as window.orientation moves
through 90, 180, -90 degrees (i.e. away from the default
window.orientation === 0).
3. We could provide developers with alternative solutions for fixing
DeviceOrientation if window.orientation changes. e.g. developers can
rotate a displayed HTML canvas element by -window.orientation to
offset the change in screen orientation but continue to maintain the
correct DeviceOrientation event behaviour.

This problem needs more discussion on this list and in the spec :)
Feedback on the three 'fixes' above would help to inform what we put
in to the specification regarding this.

>
>
>> Regarding Quaternion representation I think it would be good to have more
>> justification for it's inclusion in the specification. Euler angles have
>> known issues (at least theoretically e.g. gimbal lock) and were more or less
>> abandoned in Android in favor of the quaternion representation. It is not
>> clear though if this would be a useful addition for developers in Chrome.
>> This may probably be worth a survey actually ;).
>>
>
> Now that we've worked out how we should really be coding for this API and
> that the main browsers have implemented it correctly then we're happy to
> just work with Euler angles. But I think a survey could definitely be a good
> idea.

I'd like to see if there is further interest from developers or
implementors for different rotation representations here. Step 1 is
likely to be improving the clarity of the spec and the state of
current implementations though (using the currently specified
Tait-Bryan angles).

- Rich

Received on Monday, 17 February 2014 10:11:42 UTC