JavaScript Device Orientation Table

They are Tait-Bryan angles of the device relative to a coordinate frame: beta is rotation around the x axis (the phone's left-right edge) - flat on a table is 0, tilted toward you grows positive, standing upright is 90; gamma is rotation around the y axis (top-bottom edge) - flat is 0, rolled onto its left side approaches 90; alpha is rotation around the z axis (pointing out of the screen) and is the compass-flavored one: 0 when the top of the phone points toward the reference direction. The compass trouble is the reference frame. In the default non-absolute mode, alpha 0 is wherever the device was oriented when the page loaded - perfectly fine for relative controls (steering, tilting), useless for navigation. For true north you need either the absolute orientation event (alpha measured against Earth's coordinate frame, where supported) or Safari's non-standard webkitCompassHeading, which directly reports the compass heading in degrees clockwise from north. And the second trap: all three angles are in device coordinates, so a landscape device reports beta/gamma as if you had rotated the world - production code combines the angles with the current screen orientation angle before trusting any of them. The recipe: relative controls use raw alpha/beta/gamma; anything that claims a compass direction uses webkitCompassHeading on Safari or the absolute event elsewhere, with a screen-orientation correction and a visible calibration state.

It is a function, not an event: DeviceOrientationEvent.requestPermission() returns a promise resolving to 'granted' or 'denied', and it must be invoked from a user gesture - a tap handler on a button you showed for exactly this purpose. Call it from script context (a load handler, a timer) and it rejects; that rejection is not a bug you can route around, it is the platform enforcing visible consent for motion sensors, motivated by the 2019 wave of motion-sensor fingerprinting and advertising abuse. The UX that works: an explicit 'enable motion' button (or gate the motion feature behind the first natural tap), with the Android path silently skipping the gate - feature-detect the function itself (typeof DeviceOrientationEvent.requestPermission === 'function') to know which world you are in. Handle all three outcomes of the promise: granted means attach listeners and go; denied means the user said no at the system prompt - respect it, show the manual fallback, and do not re-prompt on every interaction (iOS will keep denying and your button looks broken); rejected promise means the gesture-context violation or a system-level restriction - the same fallback UI, plus a console note for debugging. One grant covers both deviceorientation and devicemotion for the session; it does not persist across reloads, so a motion-heavy page should remember the choice in its own UI state and re-gate quietly on next visit rather than nagging.

Three separate phenomena with three separate counters. Jitter is sensor noise: MEMS gyros and accelerometers produce values that wobble by a degree or two sample to sample, so direct rendering shivers - the standard counter is a low-pass filter (keep 90 percent of the previous smoothed value, blend in 10 percent of the new sample) or requiring a stable window (N consecutive readings within a threshold) before acting; for games, raw values feel responsive, for instruments, filtered values feel precise. Drift is thermal and mechanical: sensors recalibrate as the device heats up or after being dropped, so a level that read true at minute one may sit a degree off at minute twenty - counter it with a visible re-zero control (let the user place the phone on a known-flat surface and capture the current values as the new baseline). Compass error is environmental: the magnetometer that backs alpha-in-absolute-mode and webkitCompassHeading deflects near steel frames, car bodies, magnetic mounts and even some laptop lids - the counter is honesty in the UI: show a calibration hint when readings disagree across device movement (the classic figure-eight wave is the platform convention for forcing magnetometer recalibration), and never present a compass heading to more precision than the hardware deserves (whole degrees, no decimals). The meta-rule: treat every reading as an estimate with a confidence, and design the interface so users can see when the instrument is unsure.

DeviceMotionEvent is the acceleration half of the same physical story: its event object carries acceleration (m/s squared in the three device axes, optionally excluding gravity via accelerationIncludingGravity), rotationRate (deg/s of alpha/beta/gamma-style rotation), and interval (the nominal sample period in ms). Orientation tells you pose - which way the phone is facing; motion tells you dynamics - is it accelerating, shaking, falling, being shaken like a maraca. The classic motion use cases are gesture detection (shake to undo, flip to mute), step counting, and impact or fall detection; the classic orientation use cases are levels, compasses, and tilt controls. They are separate listeners (devicemotion vs deviceorientation) but share the platform's privacy settlement: on iOS both sit behind the same requestPermission() call and one grant covers both; both are secure-context-only; both stop flowing when the tab is backgrounded; and both are high-frequency enough that battery-conscious engineering applies - remove listeners when the tool is not on screen, prefer setInterval throttling of your own handler work over raw event frequency, and never leave a motion listener attached on a page the user has merely paused. The deprecation wind blowing through generic sensor APIs is worth knowing: the W3C's newer Generic Sensor API (Accelerometer, Gyroscope classes) is the long-term direction, but cross-browser reality still runs on these events - so build on devicemotion/deviceorientation today, isolate the sensor access in one small module, and the migration cost stays contained when the platform eventually moves.