W3C home > Mailing lists > Public > public-geolocation@w3.org > February 2014

Re: Device Orientation specification co-editor

From: Rich Tibbett <richt@opera.com>
Date: Mon, 17 Feb 2014 11:13:56 +0100
Message-ID: <CAAsrAZCETfjVY6pUiBnrxWNA1hnvwGZsZCJjOQzgX1nQQhnp6w@mail.gmail.com>
To: Rob Manson <roBman@buildar.com>
Cc: public-geolocation <public-geolocation@w3.org>
On Mon, Feb 17, 2014 at 11:11 AM, Rich Tibbett <richt@opera.com> wrote:
> 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]

Minor ref clarifications :)

[A] http://www.html5rocks.com/en/tutorials/device/orientation/deviceorientationsample.html
[B] http://www.jeremyselier.com/s/demo/device_orientation.html
[C] http://wellcaffeinated.net/demos/device-orientation
(you can load up these demos, then rotate the screen and the demo
behaviour is inconsistent in different screen orientations).

>
> 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:14:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:07 UTC