- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 17 Feb 2014 11:13:56 +0100
- 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