ReadonlyclientHorizontal position in client (viewport) pixels, +X right.
ReadonlyclientVertical position in client pixels, +Y down — the platform's sign.
ReadonlypointerWhich pointer this is: mouse, finger, or stylus.
Optional ReadonlypointerWhich kind of device it is, verbatim from the platform (2026-08-09, A-9).
Typed string, not PointerDeviceType, and the difference is
measured rather than defensive: lib.dom's PointerEvent.pointerType is
declared string, so narrowing this field makes a real PointerEvent stop
satisfying this interface — "Type 'string' is not assignable to type
'"mouse" | "pen" | "touch" | undefined'" — and the structural seam's whole
promise (a browser event needs no adapter) would be gone. The Pointer
Events specification agrees with the DOM's typing: it permits
vendor-defined values and "" for a device the platform cannot classify.
The narrowing therefore happens inside this module, once, and an unrecognized value becomes an absent ScenePointerEvent.pointerType rather than a rejected event. Refusing it outright would be the §85 reflex applied to the wrong kind of input: §85 refuses a configuration the application got wrong, where failing loudly costs nothing; this is hardware telemetry arriving mid-gesture, where a throw would break input on a device whose only sin is being newer than the union. Reporting "unknown" is neither a clamp nor a guess.
Optional so that a source with nothing to report — and every call site that predates this field — stays valid.
The platform pointer event this module reads — four fields out of the DOM's
PointerEvent.Structural on purpose: a browser
PointerEvent, a Playwright-synthesized one, and a plain object in a unit test are all equally acceptable, and namingPointerEventwould pull a DOM lib into a package that must build in Node.