Opposite z-axis for example 7

[jipodine]

Should not the value of z of example7 be the opposite?

Example 7 says

A device lying flat on a horizontal surface with the screen upmost has an acceleration of zero and the following value for accelerationIncludingGravity:

{x: 0, y: 0, z: 9.8};

While everywhere, the specification consistently states the orientation of the z axis is down to up.

Up (Z) is perpendicular to the ground plane and positive upwards.

Even example 8 says:

A device in free-fall, with the screen horizontal and upmost, has an accelerationIncludingGravity of zero and the following value for acceleration: {x: 0, y: 0, z: -9.8};

[rakuco]

Here's my understanding of it:

accelerationIncludingGravity is supposed to represent "the acceleration of the hosting device, plus an acceleration equal and opposite to the acceleration due to gravity", so if the device is lying flat on a horizontal surface, the host device's acceleration is 0, gravity is -9.8 and therefore accelerationIncludingGravity.z is 9.8.

In example 8, it's acceleration.z that is -9.8, while accelerationIncludingGravity.z would be -9.8 from acceleration.z + 9.8 of an acceleration equal and opposite to the acceleration due to gravity = 0.

[jipodine]

@rakuco Yes, you should be correct. I did not see the phrasing, and was mislead by the term including in the name. So accelerationIncludingGravity includes the opposite of the acceleration due to gravity.

Apparently I am not the only one confused.. See MDN not including the opposite term:

Unlike DeviceMotionEvent.acceleration which compensates for the influence of gravity, its value is the sum of the acceleration of the device as induced by the user and the acceleration caused by gravity.

[jipodine]

We could also add a clarification: unlike the name suggests, it represents the sum of all accelerations, except the gravity.

Examples:

7. {x=0, y=0, z=+9.81} when lying flat on a horizontal surface (acceleration from the underlying surface)
8. {x=0, y=0, z=0} in case of free fall (the only acceleration is gravity)

[rakuco]

I agree this is very confusing, I had to spend some time re-learning a lot of these concepts before commenting :-)

mdn/content#6675 should make the text in MDN less confusing, while #97 adds a note to the spec that hopefully makes things a bit more clear.

We could also add a clarification: unlike the name suggests, it represents the sum of all accelerations, except the gravity.

Examples:

1. {x=0, y=0, z=+9.81} when lying flat on a horizontal surface (acceleration from the underlying surface)
2. {x=0, y=0, z=0} in case of free fall (the only acceleration is gravity)

I'm not so sure about this though when it comes to how precise this definition is (assuming it's supposed to be part of the normative text). If it's supposed to go into a note, I was hoping the change I mentioned above would suffice.

[chaals]

We could also add a clarification: unlike the name suggests, it represents the sum of all accelerations, except the gravity.

I think "unlike the name suggests" isn't helpful. The name suggests different things to different people. But the rest of the clarification, and the example, are useful.

I presume the point is that if you had a device on the moon, you would have a different value for sitting on the ground, and if your device was sitting somewhere on a space station it would be approximately in freefall (around the earth and sun) so the value would be below the threshold of 0.1. I wonder if it's worth expanding the examples to include that?

It might also be helpful to provide an example of walking in a straight line, the phone held at a 30º angle from horizontal...

(Example 9 also seems to be wrong: If the phone is in the vertical plane, accelerationIncludingGravity should be { x: v^2/r, y: 9.8, z:0 }. Do you want a separate issue for that?

[rakuco]

(Example 9 also seems to be wrong: If the phone is in the vertical plane, accelerationIncludingGravity should be { x: v^2/r, y: 9.8, z:0 }. Do you want a separate issue for that?

Yes, please, I feel it's easier to handle this separately.

[rakuco]

@jipodine @reillyeon is everyone OK with the work done here? Can we close this ticket?

[jipodine]

Thank you for your work, it is much clearer now, both in the spec and in MDN.

[rakuco]

Thanks, @jipodine, please feel free to close this issue.