- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 17 Feb 2014 11:11:07 +0100
- To: Rob Manson <roBman@buildar.com>
- Cc: public-geolocation <public-geolocation@w3.org>
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