W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2011

[DeviceOrientation] General editorial comments

From: timeless <timeless@gmail.com>
Date: Wed, 27 Jul 2011 12:01:04 -0400
Message-ID: <CAACrNNdy_aqHoh8D_HYFghi0VQ9fYYv13cQTNA5z+ho-VnBv+Q@mail.gmail.com>
To: public-geolocation@w3.org

> The information provided by the events is not raw sensor data,
> but rather high-level data which is is agnostic of the underlying

s/is is/is/

> source of information.

> The second DOM event provided by this specification, devicemotion,
> supplies the acceleration of the device, specified in cartesian

s/cartesian/Cartesian/ [1][2]

> coordinates relative to a coordinate frame defined in the device.

>    East (X) is in the ground plane, perpendicular to the North axis
> and positive towards the East.

What happens if I'm at the North Pole?

>    North (Y) is in the ground plane and positive towards True North
> (towards the North Pole).

What happens if I'm at the North Pole? Is North beneath me? :)

> For a laptop computer, the device coordinate frame is defined
> relative to the keyboard.

s/keyboard/integrated-keyboard/ -- if I use a USB keyboard, you really
don't want to define it relative to that.

Also, if I use my laptop on an angle with the screen pointing "up"
[3], is this likely to be the right answer?

>    x is in the plane of the screen or keyboard and is positive towards
> the right hand side of the screen or keyboard.
>    y is in the plane of the screen or keyboard and is positive towards
> the top of the screen or keyboard.
>    z is perpendicular to the screen or keyboard, positive out of the
> screen or keyboard.

What happens if my display swivels? [4][5][6]

> This event must fire on the window object.

Do you mean 'must only'? The must here is a bit confusing wrt a should later.

> Registration for, and firing of the compassneedscalibration event must
> follow the usual behavior of DOM Level 2 Events, [DOMEVENTS]

This thought didn't end with a period.

> This event must only be fired when one or more event listeners are
> registered for the deviceorientation event

My understanding is that MUSTs should be testable. I don't think this
must is testable. I also think that whether an implementation
optimizes away useless events is an implementation detail.

> and the user agent determines that a compass used to obtain orientation
> data is in need of calibration.

This part of the MUST is problematic when one takes into account the
following should.

> Furthermore, user agents should only fire the event if calibrating
> the compass will increase the accuracy of the data provided by the
> deviceorientation event.

> The default action of this event should be for the user agent to
> present the user with details of how to calibrate the compass.

> User agents implementing this specification must allow a new DOM
> event type, named devicemotion.

This text doesn't make sense. Must _allow_ a type to <what>? Perhaps
<must allow registration for> ? and `new event type` is strange.

> The corresponding event must be of type DeviceMotionEvent and must
> fire on the window object.

> A Web application monitors the device's acceleration and applies signal
> processing in order to recognise certain specific gestures.


> For example, using a shaking gesture to clear a web form.

This example is distressing. I walk around with my tablets, and I run
around with my tablets.

I strongly believe that examples and other items enshrined in
specifications should be reasonably good instead of demonstrably

[1] http://en.wikipedia.org/wiki/Cartesian
[2] http://en.wikipedia.org/wiki/Cartesian_coordinate_system
[3] http://www.hardwarelogic.com/articles/reviews/cooling/Vizo_Xena_II/Vizo_Xena_II_Laptop_Side_3.jpg
[4] http://i00.i.aliimg.com/photo/v0/374350374/Rotate_Touch_Screen_Mini_Laptop_netbook.jpg
[5] http://img.alibaba.com/wsphoto/v0/473537160/10_2_inch_Mini_Laptop_Netbook_Windows_XP_7_1GB_RAM_160GB_HDD_1_60GHz_Intel_Atom_N270_180_Degree_Rotate_Touch_Screen_Notebook_PC.jpg_200x200.jpg
[6] http://image.dhgate.com/upload/201010/24/ff8080812838585801286704c0cd20e4/productimg1287947301975.jpg
Received on Wednesday, 27 July 2011 16:01:45 UTC

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