Pointer Events — Level 4

4.1. `PointerEvent^I ~interface

dictionary `PointerEventInit$I : `MouseEventInit$I {
    `long$      `pointerId@mb = 0;
    `double$    `width@mb = 1;
    `double$    `height@mb = 1;
    `float$     `pressure@mb = 0;
    `float$     `tangentialPressure@mb = 0;
    `long$      `tiltX@mb;
    `long$      `tiltY@mb;
    `long$      `twist@mb = 0;
    `double$    `altitudeAngle@mb;
    `double$    `azimuthAngle@mb;
    `DOMString$ `pointerType@mb = "";
    `boolean$   `isPrimary@mb = false;
    `long$      `persistentDeviceId@mb = 0;
    `sequence$<`PointerEvent$I> `coalescedEvents@mb = [];
    `sequence$<`PointerEvent$I> `predictedEvents@mb = [];
};

[`Exposed$=Window]
interface `PointerEvent@I : `MouseEvent$I {
    constructor(DOMString %type, optional `PointerEventInit$I %eventInitDict = {});
    readonly attribute `long$      `pointerId$m;
    readonly attribute `double$    `width$m;
    readonly attribute `double$    `height$m;
    readonly attribute `float$     `pressure$m;
    readonly attribute `float$     `tangentialPressure$m;
    readonly attribute `long$      `tiltX$m;
    readonly attribute `long$      `tiltY$m;
    readonly attribute `long$      `twist$m;
    readonly attribute `double$    `altitudeAngle$m;
    readonly attribute `double$    `azimuthAngle$m;
    readonly attribute `DOMString$ `pointerType$m;
    readonly attribute `boolean$   `isPrimary$m;
    readonly attribute `long$      `persistentDeviceId$m;
    [`SecureContext$] sequence<`PointerEvent$I> `getCoalescedEvents()$m;
    sequence<`PointerEvent$I> `getPredictedEvents()$m;
};

`pointerId@m

~eventを生じさせた~pointerを一意に識別する識別子 — 以下、 ここでは，単に~IDと称する。 ◎ A unique identifier for the pointer causing the event.＼

~UAは、 値［ 0 または 1 ］を［ ~mouseによる`首~pointer$用の汎用な~ID ］用に予約してもヨイ。 ◎ User agents MAY reserve a generic pointerId value of 0 or 1 for the primary mouse pointer.＼

~ID用の値 −1 は、［ 当の~eventは，~pointing装置~以外の何かから生成されたこと ］を指示するものとして，［ 予約され，利用する ］モノトスル。 ◎ The pointerId value of -1 MUST be reserved and used to indicate events that were generated by something other than a pointing device.＼

他の~pointer用には、 ~UAは，~IDをアテガうための［ 策／~approach ］として何を実装してもかまわない。 ただし，~IDは、 所与の`~top-level閲覧~文脈$ `HTML$r において［ すべての`作動中な~pointer$にわたって一意になる ］かつ［ 他の`~top-level閲覧~文脈$から波及されない ］ようにするモノトスル （すなわち、 ある~pointerが［ ある~top-level閲覧~文脈から別の~top-level閲覧~文脈の中へ移動した ］とき，［ 当の~pointerの `pointerId$m が両~閲覧~文脈において同じになる ］ものとは見做せない）。 ◎ For any other pointers, user agents are free to implement different strategies and approaches in how they assign a pointerId value. However, all active pointers in the top-level browsing context (as defined by [HTML]) must be unique, and the identifier MUST NOT be influenced by any other top-level browsing context (i.e. one top-level browsing context cannot assume that the pointerId of a pointer will be the same when the pointer moves outside of the browsing context and into another top-level browsing context).＼

~UAは、［ 以前に`作動中$であった~pointer用の退役した~ID ］を~~再利用してもヨイ — あるいは、［ 特定0の~pointing装置~用には，常に同じ~IDを再利用する ］ことにしてもヨイ （一例として、 多人数協同~appにおいて， 特定の利用者による特定0の装置からの入力を一意に識別するため）。 しかしながら，後者の事例では、［ 異なる~pageや~domainにまたがる指紋収集や追跡 ］の機会cを最小化するため、 当の［ ~page／~session ］が存続する限り，当の~IDを当の装置のみに明示的に結付けるモノトスル — 次回に，当の装置が新たな~sessionにて再び利用されたときは、 新たな~IDを~randomに選ぶモノトスル。 ◎ The user agent MAY recycle previously retired values for pointerId from previous active pointers, or it MAY always reuse the same pointerId for a particular pointing device (for instance, to uniquely identify particular pen/stylus inputs from a specific user in a multi-user collaborative application). However, in the latter case, to minimize the chance of fingerprinting and tracking across different pages or domains, the pointerId MUST only be associated explicitly with that particular pointing device for the lifetime of the page / session, and a new randomized pointerId MUST be chosen the next time that particular pointing device is used again in a new session.

注記： ~IDの選定~algoは，実装に特有なので、 作者は， `pointerId$m の値を［ 上の意味で一意であること以外の意味を伝達するもの ］とは見做せない。 例として、 ~UAは，単純に［ どの~pointerにも，作動中になった順に 0 から開始する数をアテガう ］こともあろうが、 これらの値が単調増加することは保証されない。 ◎ Note The pointerId selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, user agents may simply assign a number, starting from 0, to any active pointers, in the order that they become active — but these values are not guaranteed to be monotonically increasing.

`width@m

`height@m

順に、 ~pointerの`接触~幾何$の［ 横幅, 縦幅 ］（ X, Y 軸~上の大きさ）を~CSS~pixel数（ `CSS21$r ）で表す。 この値は、 所与の~pointer用の各~eventごとに更新されてもヨイ。 ［ 概して`接触~幾何$を欠く入力（伝統的な~mouseなど） ／ 実際の幾何が~hardwareにより検出されない入力 ］に対しては、 既定の値として 1 を返すモノトスル。 ◎ The width (magnitude on the X axis), in CSS pixels (see [CSS21]), of the contact geometry of the pointer. This value MAY be updated on each event for a given pointer. For inputs that typically lack contact geometry (such as a traditional mouse), and in cases where the actual geometry of the input is not detected by the hardware, the user agent MUST return a default value of 1. ◎ The height (magnitude on the Y axis), in CSS pixels (see [CSS21]), of the contact geometry of the pointer. This value MAY be updated on each event for a given pointer. For inputs that typically lack contact geometry (such as a traditional mouse), and in cases where the actual geometry of the input is not detected by the hardware, the user agent MUST return a default value of 1.

`pressure@m

~pointer入力による押圧 — 値の範囲は、［ 0 以上, 1 以下 ］に正規化される。 値［ 0 ／ 1 ］は、 ~hardwareが検出できる［ 最小／最大 ］の押圧を表現する。 ~hardwareや~platformが押圧を~supportしないときの値は、［ ~buttonが`作動~状態$にあるなら 0.5 ／ ~ELSE_ 0 ］を返すモノトスル。 ◎ The normalized pressure of the pointer input in the range of [0,1], where 0 and 1 represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware and platforms that do not support pressure, the value MUST be 0.5 when in the active buttons state and 0 otherwise.

`tangentialPressure@m

~pointer入力の接線方向~圧†（ ~barrel圧としても周知） — 値の範囲は、［ −1 以上, 1 以下 ］に正規化される。 概して，追加的な制御により設定される（例： ~airbrush~stylusの手指~wheelなど）。 値 0 は、 中立な位置を指す。 ~hardwareによっては，範囲［ 0 以上, 1 以下 ］に入る正な値しか~supportしないものもあることに注意。 ~hardwareや~platformが接線方向~圧を~supportしないときは、 0 を返すモノトスル。 ◎ The normalized tangential pressure (also known as barrel pressure), typically set by an additional control (e.g. a finger wheel on an airbrush stylus), of the pointer input in the range of [-1,1], where 0 is the neutral position of the control. Note that some hardware may only support positive values in the range of [0,1]. For hardware and platforms that do not support tangential pressure, the value MUST be 0.

【† 接線方向~圧（ `tangential pressure^en ） — おそらく，~pen等をひねるときの力。 ~barrel（“樽”）の周に沿う，接線~方向。 】

注記： その名前にかかわらず、 実施においては， この~prop用の値を生成する~hardware［ ~control／~sensor ］は、 圧に敏感とは限らない。 例として、 ほとんどの事例では，ほとんどの［ ~airbrush／塗ng ］~stylus上の手指~wheel用の実装では，【この~propが返す値を】自由に設定できる — それが 0 を返すのを防止するために，~wheelに一定な圧を適用するよう利用者に要求しないよう。 ◎ Despite the property's name, in practice the hardware controls/sensors that generate the values for this property may not necessarily be pressure sensitive. As an example, in most cases the finger wheel on most airbrush/painting stylus implementations can be freely set, rather than requiring the user to apply a constant pressure on the wheel to prevent it from returning to the zero position.

`tiltX@m

［ `~digitizer$が成す Y-Z 平面 ］と［ ~transducer（例：~penや~stylus）軸と Y 軸を包含する平面 ］が成す角度。 値の範囲は［ −90° 以上, 90° 以下 ］。 正な `tiltX$m は、 X 値が増大する方向 — ~transducer軸が右に傾いていること — を表す。 絶対~値が大きいほど，~transducer軸が~digitizer面の法線から離れていることを表す。 ◎ The plane angle (in degrees, in the range of [-90,90]) between the Y-Z plane and the plane containing both the transducer (e.g. pen/stylus) axis and the Y axis. A positive tiltX is to the right, in the direction of increasing X values. tiltX can be used along with tiltY to represent the tilt away from the normal of a transducer with the digitizer.＼

~hardwareや~platformが［ 傾き／角度 ］を報告しないときの値は、 0 になるモノトスル。 ◎ For hardware and platforms that do not report tilt or angle, the value MUST be 0.

【 ~target要素に対する変形（回転など）が X, Y 軸の解釈に影響し得るのか, どう影響するのかについては、 この仕様には述べられていない。 】

`tiltY@m

［ `~digitizer$が成す Y-Z 平面 ］と［ ~transducer（例：~penや~stylus）軸と X 軸を包含する平面 ］が成す角度。 値の範囲は［ −90° 以上, 90° 以下 ］。 正な `tiltY$m は、 Y 値が増大する方向 — ~transducer軸が利用者~側に傾いていること — を表す。 絶対~値が大きいほど，~transducer軸が~digitizer面の法線から離れていることを表す。 ◎ The plane angle (in degrees, in the range of [-90,90]) between the X-Z plane and the plane containing both the transducer (e.g. pen/stylus) axis and the X axis. A positive tiltY is towards the user, in the direction of increasing Y values. tiltY can be used along with tiltX to represent the tilt away from the normal of a transducer with the digitizer.＼

~hardwareや~platformが［ 傾き／角度 ］を報告しないときの値は、 0 になるモノトスル。 ◎ For hardware and platforms that do not report tilt or angle, the value MUST be 0.

`twist@m

~transducer（例：~penや~stylus）自身の~~主~軸~周りにおける，時計回りによる回転~角度 — 値の範囲は、［ 0° 以上, 359° 以下 ］。 ◎ The clockwise rotation (in degrees, in the range of [0,359]) of a transducer (e.g. pen/stylus) around its own major axis.＼

~hardwareや~platformが~twist【ひねり？】を報告しないときの値は、 0 になるモノトスル。 ◎ For hardware and platforms that do not report twist, the value MUST be 0.

`altitudeAngle@m

~transducer（例：~penや~stylus）の仰角 — 値の範囲は、 ~radianで［ 0 以上, π/2 以下 ］。 0 は物理面（~X-Y平面）に平行, π/2 は物理面に垂直なことを表す。 ~hardwareや~platformが［ 傾き／角度 ］を報告しないときの値は、 π/2 になるモノトスル。 ◎ The altitude (in radians) of the transducer (e.g. pen/stylus), in the range [0,π/2] — where 0 is parallel to the surface (X-Y plane), and π/2 is perpendicular to the surface. For hardware and platforms that do not report tilt or angle, the value MUST be π/2.

注記： `altitudeAngle^m 用に ここで定義される既定の値は、 π/2 であり，~transducerの位置が物理面に垂直であることを表す。 これは、 `Touch Events ~level 2＠~TOUCHEVENTS$cite 仕様が，その `altitudeAngle＠~TOUCHEVENTS#dom-touch-altitudeangle$m 用に定義する既定の値 0 と相違する。 ◎ Note The default value defined here for altitudeAngle is π/2, which positions the transducer as being perpendicular to the surface. This differs from the Touch Events - Level 2 specification's definition for the altitudeAngle property, which has a default value of 0.

`azimuthAngle@m

~transducer（例：~penや~stylus）の方位角 — 値の範囲は、 ~radianで［ 0 以上, π/2 以下 ］。 値 0 は，~transducerの頭頂が~X-Y平面~上で正な~X軸~方向（真上から見て “3時” の方向）を指していることを表現し、 そこから時計回りに増大する （ π/2 なら “6時”, π なら “9時”, 3π/2 なら “12時” を指している）。 ~transducerが物理面に垂直になったとき（ `altitudeAngle$m ~EQ π/2 ）の値は、 0 になるモノトスル。 ~hardwareや~platformが［ 傾き／角度 ］を報告しないときの値は、 0 になるモノトスル。 ◎ The azimuth angle (in radians) of the transducer (e.g. pen/stylus), in the range [0, 2π] — where 0 represents a transducer whose cap is pointing in the direction of increasing X values (point to "3 o'clock" if looking straight down) on the X-Y plane, and the values progressively increase when going clockwise (π/2 at "6 o'clock", π at "9 o'clock", 3π/2 at "12 o'clock"). When the transducer is perfectly perpendicular to the surface (altitudeAngle of π/2), the value MUST be 0. For hardware and platforms that do not report tilt or angle, the value MUST be 0.

`pointerType@m

~eventを生じさせた装置の型（ ~mouse, ~pen, ~touch, 等々）を指示する。 ~UAは，［ ~mouse ／ ~penや~stylus ／ ~touch入力~装置 ］用に`~pointer~eventを発火する$ときは、 その `pointerType$m の値を， 次の表tに則って~~初期化するモノトスル： ◎ Indicates the device type that caused the event (mouse, pen, touch, etc.). If the user agent is to fire a pointer event for a mouse, pen/stylus, or touch input device, then the value of pointerType MUST be according to the following table:

~pointer装置の型	`pointerType$m 値
~mouse	`mouse^l
~pen／~stylus	`pen^l
~touch接触	`touch^l

◎ Pointer Device Type pointerType Value Mouse mouse Pen / stylus pen Touch contact touch

~UAが検出できない型の装置~用の値は、 空~文字列になるモノトスル。 上に挙げたもの以外の，~UAが~supportする型の~pointer装置~用の `pointerType$m 値は、 異なる型の装置~間で名前が競合しないよう，~vendor接頭辞が~~付与されるベキである。 将来の仕様は、 他の型の装置~用に規範的な値を追加し得る。 ◎ If the device type cannot be detected by the user agent, then the value MUST be an empty string. If the user agent supports pointer device types other than those listed above, the value of pointerType SHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types.

【 ~penも~stylusも，~penのように手で持って~~扱う装置であるが （ `stylus^en は `stylus pen ^en の略称でもある）、 一般に，機能が簡素なものは “~stylus”, より豊富なものは “~pen” と`称されるようだ＠https://en.wikipedia.org/wiki/Active_pen$ （~stylusには、座標しか供さないものもあろう）。 ~touchは、 そのような装置を介さない，手指による入力。 】

注記： `2$ex に、 `pointerType$m の基本的な利用-法のデモがある。 開発者は、 何らかの形で既定の取扱いを含めるべきであることに注意 — 自前の~customな `pointerType$m 値を実装している~UAや, `pointerType$m が単に空~文字列である状況に対応するために。 ◎ Note See Example 2 for a basic demonstration of how the pointerType can be used. Also note that developers should include some form of default handling to cover user agents that may have implemented their own custom pointerType values and for situations where pointerType is simply an empty string.

【 この仕様では、 同じ型の装置が複数~在る状況は~~想定されていない — 特に，`~mouse~eventは防止するか$の扱いに関して。 複数の~mouseについては、 `一つの装置に統合する＠#multiple-mouse-inputs$ものとみなしている。 ~mouse以外については、 そのような状況に関して何も言及されていないが。 】

`isPrimary@m

~pointerがこの`~pointer型$の`首~pointer$を表現するかどうかを指示する。 ◎ Indicates if the pointer represents the primary pointer of this pointer type.

`persistentDeviceId@m

~pointing装置~用の一意な識別子【を与える整数】 — 以下、 ここでは，単に~ID【！ persistentDeviceId 】と称する。 ◎ A unique identifier for the pointing device.＼

当の~hardwareは複数の~pointerを~supportする場合†、 同じ~pointing装置から生成された~pointer~eventは — それらの~pointerが~sessionを通して一意に識別-可能ならば†† — 一つの~IDに限り取得するモノトスル。 当の~pointerが一意に識別-可能になって以降は††、 その~pointing装置へアテガわれる~IDは， 当の~sessionを通して一定であり続けることになる。 ◎ If the hardware supports multiple pointers, pointer events generated from pointing devices MUST only get a persistentDeviceId if those pointers are uniquely identifiable over the session. If the pointer is uniquely identifiable, the assigned persistentDeviceId to that pointing device will remain constant for the remainder of the session.＼

【† 同じ`~digitizer$を複数の~pointing装置が共有する状況 （例： 用途が異なる複数の~pen（あるいは交換-可能な~pen先）を利用している，など） が~~想定されていると思われる。 】【†† 下の注記を見よ。 】【 原文からは明瞭でないが、 同じ~pointing装置を複数の`~digitizer$で利用している場合も含めて，それら［ `~digitizer$, ~pointing装置 ］の組合nごとに異なる~IDになろう。 】【 参考： `この属性についての説明書き＠https://github.com/WICG/pointer-event-extensions/blob/main/pointer-event-device-id-explainer.md$ 】

~ID用の値 0 は、［ 当の~eventを生成している装置を識別できなかったこと ］を指示するものとして［ 予約され, 利用する ］モノトスル。 ◎ The persistentDeviceId value of 0 MUST be reserved and used to indicate events whose generating device could not be identified.＼

`pointerId$m と同様に，［ 異なる~pageや~domainにまたがる指紋収集や追跡 ］の機会cを最小化するため、 当の［ ~page／~session ］が存続する限り，この~IDを当の装置のみに明示的に結付けるモノトスル — 次回に，当の装置が新たな~sessionにて再び利用されたときは、 新たな~IDを~randomに選ぶモノトスル。 ◎ Like pointerId, to minimize the chance of fingerprinting and tracking across different pages or domains, the persistentDeviceId MUST only be associated explicitly with that particular pointing device for the lifetime of the page / session, and a new randomized persistentDeviceId MUST be chosen the next time that particular pointing device is used again in a new session.

注記： ［ `~digitizer$／~pointing装置 ］~hardwareの拘束に因り、［ ~IDが，ある~pointing装置から生成される すべての~pointer~event用に可用になる ］ことは保証されない。 例えば、 当の装置は［ `pointerdown$et† が 0 でない~IDを有する ］よう［ その~hardware~IDを~digitizerへ報告する ］とは限らない。 そのような事例では、 `persistentDeviceId^m は，初期~時は 0 であっても妥当な値へ変化する†。 ◎ Due to digitizer and pointing device hardware constraints, a persistentDeviceId is not guaranteed to be available for all pointer events from a pointing device. For example, the device may not report its hardware id to the digitizer in time for pointerdown to have a persistentDeviceId. In such a case, the persistentDeviceId may initially be 0 and change to a valid value.

【† なぜ `pointerdown^et だけ挙げられているのか， 初期~時だけ~IDを取得できないことの背後に どんな論理があるのか （および，この 2 つには関連性があるのか）は、 よくわからない。 】

`getCoalescedEvents()@m

コレの`合体d~event~list$【！合体された~event群】を返す。 ◎ A method that returns the list of coalesced events.

`getPredictedEvents()@m

コレの`予測d~event~list$【！予測された~event群】を返す。 ◎ A method that returns the list of predicted events.

`PointerEventInit@I 辞書は、 `PointerEvent$I ~interfaceの構築子に， `~trusted$でない（合成な）`~pointer~event$を構築する仕組みを供する。 それは、 `UIEVENTS$r にて定義される `MouseEventInit$I 辞書を継承する。 `4$ex に、 `~trusted$でない`~pointer~eventを発火する$方法をデモる見本~codeがある。 ◎ The PointerEventInit dictionary is used by the PointerEvent interface's constructor to provide a mechanism by which to construct untrusted (synthetic) pointer events. It inherits from the MouseEventInit dictionary defined in [UIEVENTS]. See the examples for sample code demonstrating how to fire an untrusted pointer event.

`PointerEvent$I 用の`~event構築-時の手続き$は、 `PointerEventInit$I の［ `coalescedEvents$mb ／ `predictedEvents$mb ］を当の~eventの［ `合体d~event~list$／`予測d~event~list$ ］に~cloneする。 ◎ The event constructing steps for PointerEvent clones PointerEventInit's coalescedEvents to coalesced events list and clones PointerEventInit's predictedEvents to predicted events list.

注記： `PointerEvent$I ~interfaceは、 `UIEVENTS$r に定義される `MouseEvent$I を継承する。 また， `CSSOM-VIEW$r にて提案された拡張は、 種々の座標~propを — 小数付きな座標を許容するためとして — `long^c から `double^c 型に変更することに注意。 この提案された拡張を［ `PointerEvent$I 用にはすでに実装したが 定例の `MouseEvent$I 用には実装していない~UA ］に対しては、［ `click$et, `auxclick$et, `contextmenu$et ］~eventに際して，追加的な要件がある。 ◎ Note The PointerEvent interface inherits from MouseEvent, defined in UI Events. Also note the proposed extension in CSSOM View Module, which changes the various coordinate properties from long to double to allow for fractional coordinates. For user agents that already implement this proposed extension for PointerEvent, but not for regular MouseEvent, there are additional requirements when it comes to the click, auxclick, and contextmenu events.

const π = Math.PI;  /* 
【これは、以下を読み易くするための，この訳による追加。】
 */

function spherical2tilt(%altitudeAngle, %azimuthAngle) {
  const %radToDeg = 180/π;

  let %tiltXrad = 0;
  let %tiltYrad = 0;

  if (%altitudeAngle == 0) {
    /* 
~penは~X-Y平面~内にある
◎
the pen is in the X-Y plane
 */
    if (%azimuthAngle == 0 || %azimuthAngle == 2*π) {
      /* 
~penは正な~X軸~上にある
◎
pen is on positive X axis
 */
      %tiltXrad = π/2;
    }
    if (%azimuthAngle == π/2) {
      /* 
~penは正な~Y軸~上にある
◎
pen is on positive Y axis
 */
      %tiltYrad = π/2;
    }
    if (%azimuthAngle == π) {
      /* 
~penは負な~X軸~上にある
◎
pen is on negative X axis
 */
      %tiltXrad = -π/2;
    }
    if (%azimuthAngle == 3*π/2) {
      /* 
~penは負な~Y軸~上にある
◎
pen is on negative Y axis
 */
      %tiltYrad = -π/2;
    }
    if (%azimuthAngle > 0 && %azimuthAngle < π/2) {
      %tiltXrad = π/2;
      %tiltYrad = π/2;
    }
    if (%azimuthAngle > π/2 && %azimuthAngle < π) {
      %tiltXrad = -π/2;
      %tiltYrad = π/2;
    }
    if (%azimuthAngle > π && %azimuthAngle < 3*π/2) {
      %tiltXrad = -π/2;
      %tiltYrad = -π/2;
    }
    if (%azimuthAngle > 3*π/2 && %azimuthAngle < 2*π) {
      %tiltXrad = π/2;
      %tiltYrad = -π/2;
    }
  }

  if (%altitudeAngle != 0) {
    const %tanAlt = Math.tan(%altitudeAngle);

    %tiltXrad = Math.atan(Math.cos(%azimuthAngle) / %tanAlt);
    %tiltYrad = Math.atan(Math.sin(%azimuthAngle) / %tanAlt);
  }

  return {"tiltX": %tiltXrad * %radToDeg, "tiltY": %tiltYrad * %radToDeg};
}

function tilt2spherical(%tiltX, %tiltY) {
  const %tiltXrad = %tiltX * π/180;
  const %tiltYrad = %tiltY * π/180;

  /* 
方位角を計算する
◎
calculate azimuth angle
 */
  let %azimuthAngle = 0;

  if (%tiltX == 0) {
    if (%tiltY > 0) {
      %azimuthAngle = π/2;
    }
    else if (%tiltY < 0) {
      %azimuthAngle = 3*π/2;
    }
  } else if (%tiltY == 0) {
    if (%tiltX < 0) {
      %azimuthAngle = π;
    }
  } else if (Math.abs(%tiltX) == 90 || Math.abs(%tiltY) == 90) {
    /* 
方位角を計算するための情報が足らない
◎
not enough information to calculate azimuth
 */
    %azimuthAngle = 0;
  } else {
    /* 
非~境界~事例：
%tiltX, %tiltY どちらも 90 の倍数でない
◎
Non-boundary case: neither tiltX nor tiltY is equal to 0 or +-90
 */
    const %tanX = Math.tan(%tiltXrad);
    const %tanY = Math.tan(%tiltYrad);

    %azimuthAngle = Math.atan2(%tanY, %tanX);
    if (%azimuthAngle < 0) {
      %azimuthAngle += 2*π;
    }
  }

  /* 
仰角を計算する
◎
calculate altitude angle
 */
  let %altitudeAngle = 0;

  if (Math.abs(%tiltX) == 90 || Math.abs(%tiltY) == 90) {
      %altitudeAngle = 0
  } else if (%tiltX == 0) {
    %altitudeAngle = π/2 - Math.abs(%tiltYrad);
  } else if (%tiltY == 0) {
    %altitudeAngle = π/2 - Math.abs(%tiltXrad);
  } else {
    /* 
非~境界~事例：
%tiltX, %tiltY どちらも 90 の倍数でない
◎
Non-boundary case: neither tiltX nor tiltY is equal to 0 or +-90
 */
    %altitudeAngle =  Math.atan(1.0/Math.sqrt(Math.pow(Math.tan(%tiltXrad),2) + Math.pow(Math.tan(%tiltYrad),2)));
  }

  return {"altitudeAngle": %altitudeAngle, "azimuthAngle": %azimuthAngle};
}

4.2. 各種~pointer~event型

この仕様にて定義される各種~event型を以下に述べる。 ◎ Below are the event types defined in this specification.

`首~pointer$に対しては、 （ `gotpointercapture$et, `lostpointercapture$et を例外として） これらの~eventからは，`互換性~mouse~event$も発火され得る。 ◎ In the case of the primary pointer, these events (with the exception of gotpointercapture and lostpointercapture) may also fire compatibility mouse events.

8.1. `touch-action^p ~CSS~prop

`touch-action$p ~propは、 `直な操作$（~propの名前にもかかわらず，~touchのみに制限されない）により， ~UAによる~pan-zoom用の挙動が誘発されてよいかどうかを決定する。 § `touch-action^p 値 を見よ。 ◎ The touch-action CSS property determines whether direct manipulation interactions (which are not limited to touch, despite the property's name) MAY trigger the user agent's panning and zooming behavior. See the section on touch-action values.

［ ~pan／~zoom ］が開始される直前にて， ~AND↓ が満たされるときは、 `~pointer~event~streamを抑止する$モノトスル ◎ Right before starting to pan or zoom, the user agent MUST suppress a pointer event stream if all of the following conditions are true:

• ~UAは、 `直な操作$を~pan-zoom用に消費するものと決定した （その決定-法は、この仕様の視野から外れる）。 ◎ The user agent has determined (via methods out of scope for this specification) that a direct manipulation interaction is to be consumed for panning or zooming,
• 【当の`~event連列$の一部として】 ~pointer用の `pointerdown$et ~eventを すでに送信した。 ◎ a pointerdown event has been sent for the pointer, and
• ~pointer用の［ `pointercancel$et ／ （前項の `pointerdown$et に後続する） `pointerup$et ］~eventを まだ送信していない。 ◎ a pointerup or pointercancel event (following the above mentioned pointerdown) has not yet been sent for the pointer.

注記： 一部の~UAは、［ 一連の別個な~gestureを孕むが， それらが継続的な単独の~gestureを成すものとして扱われる ］ような挙動~用に， 複階的な~gestureを実装する。 例えば、 利用者が~touchscreen上で “投げつける” ように~scrollする（ “`fling to scroll^en” ）~gestureを考える — 敏捷な手指の動きで，文書の~panningを開始して, ~touchscreenから手指を~~離したとき、 文書は惰性で~panし続けるような。 文書がまだ動いている間、 利用者は，~touchscreenに手指を置いて別の “投げつけ” を実行するかもしれない — 現在の~panningに対し、 もっと勢いをつけるか，制動して［ 遅める／停止する／逆~方向にする ］ような。 この仕様は、［ ~gestureと挙動を どう実装するか，規範的に定義する ］ことはない — 2 度目の~touchが（現在の~panningに対する 2 度目の［ “投げつけ” ／制動 ］として解釈される前に）~pointer~eventを発火するか否か裁定することは、 ~UAに委ねられる。 ◎ Note Some user agents implement complex gestures for behaviors that involve a series of separate discrete gestures, but which are all treated as part of a single continuous gesture. For example, consider a "fling to scroll" gesture on a touchscreen: a user starts panning the document with a rapid finger movement, lifts the finger from the touchscreen, and the document continues panning with simulated inertia. While the document is still moving, the user may place their finger on the touchscreen and execute another "fling" to provide further momentum for the panning, or counteract the current panning to slow it down, stop panning altogether, or reverse the direction of the panning. As this specification does not normatively define how gestures and behaviors are implemented, it is left up to the user agent to decide whether or not the second touch (before it is interpreted as a second "fling" or counteraction of the current panning) fires pointer events or not.

注記： `touch-action$p は、 埋込まれた閲覧~文脈を通して適用される【！／~cascadeする】ことはない。 【！~cascadeしないのは他の~propも同様】 一例として、 `touch-action^p が ある `iframe$e に適用されたとしても， `iframe^e の中で【 `iframe^e が埋込んでいる文書における】`直な~pan-zoom$用の挙動に効果を及ぼすことはない。 ◎ Note touch-action does not apply/cascade through to embedded browsing contexts. For instance, even applying touch-action to an <iframe> won't have any effect on the behavior of direct manipulation interactions for panning and zooming within the <iframe> itself.

8.2. ~supportされる直な操作の挙動の決定-法

利用者が，`直な操作$による~pointer（~touchscreen上の~touchや~stylusなど）を利用して要素とヤリトリするとき、 その入力による効果は，［ 要素, その各~先祖 ］の［ `touch-action$p ~propの値, および `直な~pan-zoom$用の既定の挙動 ］により次に従って決定される： ◎ When a user interacts with an element using a direct manipulation pointer (such as touch or stylus on a touchscreen), the effect of that input is determined by the value of the touch-action property, and the default direct manipulation behaviors of the element and its ancestors, as follows:

• `直な~pan-zoom$は、 要素の座標~空間において許容されるならば，要素の `touch-action$p に `適合する@ とされる。 ~CSS変形が適用されている場合、 要素の座標~空間は，ここでの適合-度に影響する仕方で~screen座標から異なり得ることに注意。 例えば，要素の X 軸が~screenを基準に 90° 回転されている場合、 ~screen座標~空間の Y 軸に平行になる。 ◎ A direct manipulation interaction for panning and zooming conforms to an element's touch-action if the behavior is allowed in the coordinate space of the element. Note that if CSS transforms have been applied, the element's coordinate space may differ from the screen coordinate in a way that affects the conformity here; for example, the X axis of an element rotated by 90 degrees with respect to the screen will be parallel to the Y-axis of the screen coordinate.

• ~UAが［ `~pointing先$の要素に対する`直な~pan-zoom$ ］を~supportするかどうかは、 次に従う：

  • 【ある方向への】直な~panningは、 ~AND↓ が満たされるとき，~supportされる：

    • 当の~panningは、 要素の `touch-action$p ~propに`適合する$
    • ［ 要素は`~scroll容器$ `CSS-OVERFLOW-3$r である ］~OR［ 【同じ方向への】直な~panningは、 要素の親に対しても~supportされる ］
    ◎ A direct manipulation interaction for panning is supported if it conforms to the touch-action property of each element between the hit tested element and its nearest inclusive ancestor that is a scroll container (as defined in [CSS-OVERFLOW-3]).

  • 直な~zoomingは、 ~AND↓ が満たされるとき，~supportされる：

    • 当の~zoomingは、 要素の `touch-action$p ~propに`適合する$

    • 要素に応じて，次が満たされる：

      • `文書~要素$である場合 ⇒ 要素の`~node文書$が`属する閲覧~文脈$は、 次を満たす ⇒ ［ `~top-level閲覧~文脈$である ］~OR［ 直な~zoomingは、 その`容器$bcに対しても~supportされる ］
      • 他の場合 ⇒ 直な~zoomingは、 要素の親に対しても~supportされる
    ◎ A direct manipulation interaction for zooming is supported if it conforms to the touch-action property of each element between the hit tested element and the document element of the top-level browsing context (as defined in [HTML]).
• ~pan-zoomが開始され，［ その~gestureを`直な操作$による挙動として取扱うべきかどうか ］を~UAが決定して以降は、 その動作が終わるまでは，関連な `touch-action$p 値を変更しても無視されることになる。 一例として， 要素の `touch-action$p 値を，~scriptの `pointerdown$et ~handlerの中で~program的に `auto^v から `none^v に変更しても、 ~pointerが作動中にある限り，~UAが当の入力に対する［ ~pan／~zoom ］用の挙動を中止したり抑止することはない。 ◎ Once panning or zooming has been started, and the user agent has already determined whether or not the gesture should be handled as a user agent direct manipulation behavior, any changes to the relevant touch-action value will be ignored for the duration of the action. For instance, programmatically changing the touch-action value for an element from auto to none as part of a pointerdown handler script will not result in the user agent aborting or suppressing any of the pan or zoom behavior for that input for as long as that pointer is active.
• 類似に， `touch-action$p 用の各種 `pan-*^v 値の事例では、 ~UAは，~gestureの開始-時に~gestureを直に取扱うかどうか決定したなら， 後続して当の~gestureの方向が変化しても — 当の~pointerが作動中にある限り — 無視するベキである。 一例として， ある要素の `touch-action^p が `pan-y*^v に設定されている下で （すなわち、~UAは縦方向への~panningしか取扱わない）， ~touchによる~gestureが横方向から開始された場合、 その~gestureの方向が — 利用者の手指が まだ~screenに~touchしている間に — 縦方向に変化しても，縦方向への~panningは生じるべきでない。 ◎ Similarly, in the case of the various touch-action values of pan-*, once the user agent has determined whether to handle a gesture directly or not at the start of the gesture, a subsequent change in the direction of the same gesture SHOULD be ignored by the user agent for as long as that pointer is active. For instance, if an element has been set to touch-action: pan-y (meaning that only vertical panning is handled by the user agent), and a touch gesture starts off horizontally, no vertical panning should occur if the user changes the direction of their gesture to be vertical while their finger is still touching the screen.

注記： 一部の~UAは、 複数の同時並行な~pointerを孕むような~pan-zoomも~supportする （例： 複-~touch）。 複数の同時並行な~pointerに対し `touch-action$p 値を［ 処理する／結付ける ］ための手法は、 この仕様の視野から外れる。 ◎ Note Some user agents support panning and zooming interactions involving multiple concurrent pointers (e.g. multi-touch). Methods for processing or associating the touch-action values of multiple concurrent pointers is out of scope for this specification.

8.3. `touch-action^p 値の詳細

`touch-action$p ~propは、 `直な操作$用の挙動のうち，表示域の~pan-zoomに関係するものを受持つ。 この~propは、 他の追加的な~UAの挙動 — ［ ~textを選択したり強調する／ ~linkや~form~controlを作動化する ］など — には影響しないモノトスル。 ◎ The touch-action property covers direct manipulation behaviors related to viewport panning and zooming. Any additional user agent behaviors, such as text selection/highlighting, or activating links and form controls, MUST NOT be affected by this CSS property.

注記： 用語 “~panning” と “~scrolling” は、 同義語と見なされる （もっと詳しく言うなら、 “~panning” とは`直な操作$による入力を利用している “~scrolling” である）。 ［ ~panningや~scrollingを誘発する［ ヤリトリや~gesture ］を定義することや，値［ `auto$v ／ `none$v ］用の誘発の挙動は、 この仕様の視野から外れる。 ◎ Note The terms "panning" and "scrolling" are considered synonymous (or, more aptly, "panning" is "scrolling" using a direct manipulation input). Defining an interaction or gesture for triggering panning/scrolling, or for triggering behavior for the auto or none values, are out of scope for this specification.

`auto@v

~UAは、［ 要素から始まる`直な操作$ ］に対し，［ 表示域の~pan-zoomに関係する挙動 ］のうち許可されるものを考慮してもヨイ。 ◎ The user agent MAY consider any permitted direct manipulation behaviors related to panning and zooming of the viewport that begin on the element.

`none@v

［ 要素から始まる`直な操作$ ］に対し，［ 表示域の~pan-zoomに関係する挙動 ］を誘発しないモノトスル。 ◎ Direct manipulation interactions that begin on the element MUST NOT trigger behaviors related to viewport panning and zooming.

`pan-x@v

`pan-left@v

`pan-right@v

`pan-y@v

`pan-up@v

`pan-down@v

これらの~~成分~値の組み合わせに対しては、 ~UAは，［ 要素から始まる`直な操作$ ］を［ 指定された各~~成分が表す方向への~panningを開始する目的 ］に限って考慮してもヨイ。 【例： `pan-y^v のみなら縦のみ， `pan-x pan-up^v なら縦と上方。】 ◎ The user agent MAY consider direct manipulation interactions that begin on the element only for the purposes of panning that starts in any of the directions specified by all of the listed values.＼

逆~方向が許容されていない場合でも【例： `pan-right^v のときの左方】、 ~panningが開始されたなら，利用者は逆~方向にも~panできる。 対照的に，単独の軸に制約されている場合には（例： `pan-y^v のみ）、 利用者が~panできる方向は，常にその軸に限られる。 ◎ Once panning has started, the direction may be reversed by the user even if panning that starts in the reversed direction is disallowed. In contrast, when panning is restricted to a single axis (eg. pan-y), the axis cannot be changed during panning.

`manipulation@v

［ 要素から始まる`直な操作$ ］を［ ~panning／継続的な~zooming ］の目的において考慮してもヨイ — ただし，関係する他の挙動のうち［ 一定時間内に起こらなければならない複数の作動化 ］に依拠するもの（ 二連-~tapで~zoomする／ 二連-~tapの最後に手指を離さず（ `double-tap and hold^en ）動かして~zoomする など）は、 誘発しないモノトスル。 ◎ The user agent MAY consider direct manipulation interactions that begin on the element only for the purposes of panning and continuous zooming (such as pinch-zoom), but MUST NOT trigger other related behaviors that rely on multiple activations that must happen within a set period of time (such as double-tap to zoom, or double-tap and hold for single-finger zoom).

注記： 各 実装に共通な， `touch-action$p 用の`追加的な値＠~COMPAT#touch-action$も `COMPAT$r にて定義されている。 ◎ Note Additional touch-action values common in implementations are defined in [COMPAT].

注記： `touch-action$p ~propを適用し得る要素は、 ~CSS `width$p, `height$p ~prop `CSS21$r のいずれも適用し得るものに限られる。 この制約は、 ~UAが`直な~pan-zoom$に対する応答性を最適化を手助けするための設計である。 `span$e などの`置換され$ない`行内~要素$など，既定では~supportされない要素~用には、 作者は，~CSS `display$p ~propに［ `block^v などの `width^p, `height^p を適用し得る値 ］を設定できる。 将来の仕様は、 この~APIをすべての要素にまで拡張し得る。 ◎ Note The touch-action property only applies to elements that support both the CSS width and height properties (see [CSS21]). This restriction is designed to facilitate user agent optimizations for low-latency direct manipulation panning and zooming. For elements not supported by default, such as <span> which is a non-replaced inline element, authors can set the display CSS property to a value, such as block, that supports width and height. Future specifications could extend this API to all elements.

注記： 一部の`直な~pan-zoom$用の既定の挙動を不能化すると、 ~UAによる他の挙動に対する応答が素早くなることもある。 例えば，~UAによっては、 二連-~tap~gestureを取扱えるようにするため， `click$et の前に 300ms ほどの遅延を自動的に入れるものもある。 そのような事例では、 `touch-action$p に明示的に値［ `none$v ／ `manipulation$v ］を設定することにより，この遅延は除かれることになる。 ~tapや二連-~tap~gestureを決定するための手法については、 この仕様の視野から外れることに注意。 ◎ Note Disabling some default direct manipulation behaviors for panning and zooming may allow user agents to respond to other behaviors more quickly. For example, with auto user agents typically add 300ms of delay before click to allow for double-tap gestures to be handled. In these cases, explicitly setting touch-action: none or touch-action: manipulation will remove this delay. Note that the methods for determining a tap or double-tap gesture are out of scope for this specification.

9.1. 序論

`~pointer捕捉@ により、 特定0の~pointerから生じる各~event（`互換性~mouse~event$も含む）の~targetを［ 通常の`~pointing先$でない，特定0の要素 ］にすることが可能になる。 これは、 （ `<input type="range">^e ~control `HTML$r に類する）~custom~slider~controlを作るときなどに有用になる。 ~slider~thumbの要素に対し，~pointer捕捉を設定すれば、 利用者は，~pointerがその~thumbからそれたときにも ~controlを前後に~slideさせられるようになる。 ◎ Pointer capture allows the events for a particular pointer (including any compatibility mouse events) to be retargeted to a particular element other than the normal hit test result of the pointer's location. This is useful in scenarios like a custom slider control (e.g. similar to the [HTML] <input type="range"> control). Pointer capture can be set on the slider thumb element, allowing the user to slide the control back and forth even if the pointer slides off of the thumb.

9.2. ~pointer捕捉の設定-法

9.3. ~pointer捕捉の解放-法

9.4. 暗黙的な~pointer捕捉

`直な~pan-zoom$（~touchscreen上の~touchや~stylusなど）を実装する入力は、 正確に，［ `pointerdown$et 用の~listenerが呼出される直前に， ~target要素に対し `setPointerCapture()$m が~callされた ］かのように挙動するベキである。 これが生じたかどうかは、 `hasPointerCapture()$m ~APIを利用して決定できる （例えば `pointerdown$et ~listenerの中で）。 次回に~pointer~eventが発火される前に，~pointerに対し `releasePointerCapture()$m が~callされなかった場合、 `gotpointercapture$et ~eventは~targetに（通常通り）配送されることになり， その捕捉が作動中であることを指示する。 ◎ Inputs that implement direct manipulation interactions for panning and zooming (such as touch or stylus on a touchscreen) SHOULD behave exactly as if setPointerCapture() was called on the target element just before the invocation of any pointerdown listeners. The hasPointerCapture API may be used (eg. within any pointerdown listener) to determine whether this has occurred. If releasePointerCapture() is not called for the pointer before the next pointer event is fired, then a gotpointercapture event will be dispatched to the target (as normal) indicating that capture is active.

注記： これは， `PointerEvents$r 【~level 1 】を非互換化する変更であるが、 既存の内容の大勢には影響iしない。 この暗黙的な捕捉~用の設計は、 代表的な~platform~UX慣行に合致することに加え、 開発者による明示的な~opt-inなしに，~UAによる［［ ~touch移動による~eventに対し 接触判定を呼出す必要 ］を防止するような，処理能の最適化 ］を可能化する（既存の支配的な ~touch入力~用の［ ~native ／~web ］~APIの処理能~上の特質に整合する）。 ◎ Note This is a breaking change from [PointerEvents], but does not impact the vast majority of existing content. In addition to matching typical platform UX conventions, this design for implicit capture enables user agents to make a performance optimization which prevents the need to invoke hit-testing on touch movement events without explicit developer opt-in (consistent with the performance properties of existing dominant native and web APIs for touch input).

注記： 加えて，~UAは、 入力~範囲~controlなどの特定の~UI~widget上で， すべての入力~装置~用に暗黙的な~pointer捕捉の挙動を実装してよい （手指を動している間に ~form~controlの外側に それることも許容するような）。 ◎ Note In addition, user agents may implement implicit pointer capture behavior for all input devices on specific UI widgets such as input range controls (allowing some finger movement to stray outside of the form control itself during the interaction).

9.5. ~pointer捕捉の暗黙的な解放-法

ある`文書$に`接続されて$いた `DOM$r ［ ある`作動中な~pointer$の`捕捉~target$ ］がそうでなくなったときは、 当の~pointerの`捕捉~target$を当の文書に設定するべきである。 ◎ When the pointer capture target override is no longer connected [DOM], the pointer capture target override SHOULD be set to the document.

`接続されて$いた `DOM$r ［ ある`作動中な~pointer$の`処理待ち捕捉~target$ ］がそうでなくなったときは、 当の~pointerの`処理待ち捕捉~target$を ~NULL に設定するべきである。 ◎ When the pending pointer capture target override is no longer connected [DOM], the pending pointer capture target override node SHOULD be cleared.

前 2 つの段落による結果、 当の文書に向けて 当の~pointerに対応する `lostpointercapture$et ~eventが — 捕捉~nodeが除去された後【`捕捉~target$が接続されなくなった後】，次回に`処理待ち~pointer捕捉を処理する$間に — 発火されるようになる。 ◎ The previous two paragraphs result in a lostpointercapture event corresponding to the captured pointer being fired at the document during the next Process pending pointer capture after the capture node is removed.

要素が ある`作動中な~pointer$の［ `捕捉~target$／`処理待ち捕捉~target$ ］である間に［ 要素に~pointer~lock `PointerLock$r が成功裡に適用された ］ときは、 `releasePointerCapture()$m ~method用の手続きを走らすモノトスル。 ◎ When a pointer lock [PointerLock] is successfully applied on an element, the user agent MUST run the steps as if the releasePointerCapture() method has been called if any element is set to be captured or pending to be captured.

10.1. 合体された~event群

処理能の理由から、 ~UAは，~pointerの`測定-可能な~prop$ （［ 座標／押圧／接線方向~圧／傾き／~twist／`接触~幾何$ ］など） が更新される あらゆる回には `pointermove$et ~eventを送信しないことを選んで、 代わりに，それら複数回の変化を 1 個の［ `pointermove$et ／ `pointerrawupdate$et ］~eventの中に合体して（結合して／併合して）もヨイ。 この~approachは，~UAが遂行しなければならない~event取扱い量を抑制する助けになるが、 ~pointerの位置【など，それらの~prop】を追跡するときの粒度と忠実度も — 特に，速く大きな動きに対し — 自然に抑制されることになる。 `getCoalescedEvents()$m ~methodを利用すれば、 ~appは，合体されない生の位置~変化への~accessがアリになる — これは、 ~pointerの動き~dataに対し，もっと精確な取扱いを許容する。 一例として，描き~appの事例では、 合体されない~event群を，~pointer実際の動きに より近く合致する滑らかな曲線を描くために利用できる。 ◎ For performance reasons, user agents may choose not to send a pointermove event every time a measurable property (such as coordinates, pressure, tangential pressure, tilt, twist, or contact geometry) of a pointer is updated. Instead, they may coalesce (combine/merge) multiple changes into a single pointermove or pointerrawupdate event. While this approach helps in reducing the amount of event handling the user agent must perform, it will naturally reduce the granularity and fidelity when tracking a pointer position, particularly for fast and large movements. Using the getCoalescedEvents() method it is possible for applications to access the raw, un-coalesced position changes. These allow for a more precise handling of pointer movement data. In the case of drawing applications, for instance, the un-coalesced events can be used to draw smoother curves that more closely match the actual movement of a pointer.

各 `PointerEvent$I ~obj %~event には、 `合体d~event~list@ が結付けられる — それは、 `PointerEvent$I ~objたちが成す~listである。 この~listは： ◎ A PointerEvent has an associated coalesced events list (a list of zero or more PointerEvents).＼

• %~event は`~trusted$である場合 — %~event の~event型に応じて： ◎ ↓

  • `pointermove$et ／ `pointerrawupdate$et ⇒ %~event の中に合体された すべての `PointerEvent$I ~objが成す連列になる。 %~event は、 これら合体された~eventの累積を表現するが，追加的な処理も伴い得る （例えば、~displayの~refresh~rateに揃えるため）。 その結果、 この~listは，常に 1 個以上の~eventを包含する。 ◎ For trusted pointermove and pointerrawupdate events, the list is a sequence of all PointerEvents that were coalesced into this event. The "parent" trusted pointermove and pointerrawupdate event represents an accumulation of these coalesced events, but may have additional processing (for example to align with the display refresh rate). As a result, the coalesced events lists for these events always contain at least one event.＼

    注記： この場合， 開発者は［ %~event, %~event の`合体d~event~list$を成すすべて ］のうち一方しか処理する必要はないはずである — 前者は後者の要約あるいは集成なので。 ◎ ↓

  • 他の場合 ⇒ 空になる。 ◎ For all other trusted event types, it is an empty list.＼
• %~event は`~trusted$でない場合 ⇒ 構築子に渡された値に初期化される。 ◎ Untrusted events have their coalesced events list initialized to the value passed to the constructor.

注記： ある`合体d~event~list$ %~list を包含している~trustedな~eventが~JSから配送し直されたときは、 当の~event の `isTrusted$m は~event配送~algoにより ~F に設定されるが， %~list を成す各~eventの `isTrusted^m は元の値 ~T から変化しない。 ◎ ↑↑ Note Since a trusted parent event is a summary or aggregation of the coalesced events, developers should only need to process either the parent events or all of the coalesced events, but not both. ◎ Note When a trusted event containing a coalesced events list is re-dispatched from JavaScript, the event dispatch algorithm sets the isTrusted bit of the event to false but the same bits in the coalesced events list remain unchaged from their original true values.

`~trusted$な`~pointer~event$ %~event の`合体d~event~list$ — 配送された %~event に対し，その `getCoalescedEvents()$m ~methodを~callして得られるそれ — を成す各~eventは： ◎ The events in the coalesced events list of a trusted event will have:

• その `timeStamp$m 属性 `DOM$r の値は、 %~event の `timeStamp$m の値~以下になり，~list順に単調増加する。 ◎ Monotonically increasing timeStamp values [DOM]＼ — all coalesced events have a timeStamp that is smaller than or equal to the timeStamp of the dispatched pointer event that the getCoalescedEvents() method was called on.＼

  すなわち， %~event の`合体d~event~list$は、 各自の `timeStamp$m 値により時系列順に~sortするモノトスル — ~listを成す最初の~eventの `timeStamp$m が最~小になる。 ◎ The coalesced events list MUST be chronologically sorted by timeStamp, so the first event will have the smallest timeStamp.

• その［ `pointerId$m, `pointerType$m, `isPrimary$m ］属性の値は、 %~event のそれらと同じになる。 ◎ The same pointerId, pointerType, and isPrimary as the dispatched "parent" pointer event.
• その自前の［ `合体d~event~list$, `予測d~event~list$ ］は空になる。 ◎ Empty coalesced events list and predicted events list of their own.

<style>
  /* 
直な操作による挙動（~pan-zoomなど）を不能化して、
`canvas$e 要素に対する すべての~eventを，~appに仕向ける。
◎
Disable intrinsic user agent direct manipulation behaviors (such as panning or zooming) so that all events on the canvas element are given to the application instead.
 */

  canvas { `touch-action$p: none; }
</style>

<canvas
    id="drawSurface"
    width="500px" height="500px"
    style="border:1px solid black;"
></canvas>

<script>
    const %canvas = document.getElementById("drawSurface"),
    %context = %canvas.getContext("2d");

    %canvas.addEventListener("pointermove", (%e)=> {

        if (%e.getCoalescedEvents) {
            for (let %coalesced_event of %e.getCoalescedEvents()) {
                paint(%coalesced_event); /* 
合体されない生の点群をすべて塗る
◎
Paint all raw/non-coalesced points
 */
            }
        } else {
            paint(%e); /* 
合体された最終的な点を塗る
◎
Paint the final coalesced point
 */
        }
    });

    function paint(%event) {
        if (%event.buttons>0) {
            %context.fillRect(%event.clientX, %event.clientY, 5, 5);
        }
    }

</script>

注記： `PointerEvent$I の各~属性は、［ 合体d~event~listを成す各~eventを最良に表現する仕方 ］で初期化されることになる。 ~UAが これをどのような手法で行うベキかついては、 この仕様が受持つ所ではない。 ◎ Note The PointerEvent's attributes will be initialized in a way that best represents the events in the coalesced events list. The specific method by which user agents should do this is not covered by this specification.

これらの~eventが配送される順序は、 元の~eventたちと合致させるモノトスル。 例えば， 【~pointerの~buttonが押されることにより】 `pointerdown$et ~eventに加え，合体された `pointermove$et ~eventたちも配送される場合、 ~UAは最初に，それらの合体された［ 同じ `pointerId$m を伴う~event ］すべてを伴う 1 個の `pointermove$et ~eventを配送してから、 `pointerdown$et ~eventを配送するモノトスル。 ◎ The order of all these dispatched events MUST match the actual order of the original events. For example if a pointerdown event causes the dispatch for the coalesced pointermove events the user agent MUST first dispatch one pointermove event with all those coalesced events of a pointerId followed by the pointerdown event.

10.2. 予測された~event群

一部の~UAは、［ ~pointerに確認された一連の動きの後に，未来の~pointerの動きを成す位置は どうなるか ］について （［ 現在の~gestureにおいて先行する~eventたち, 当の動きの速さや軌跡 ］に基づいて） 予測を為せるような， 組込みの~algoを有する。 この情報は `getPredictedEvents()$m ~methodから得られる： ~appは、 それを利用して予測された位置を “事前に” 投機的に描くことにより， 知覚される待時間を抑制できる — 予測されたこれらの点群は、 実際の点群を受取った時点で破棄するようにして。 ◎ Some user agents have built-in algorithms which, after a series of confirmed pointer movements, can make a prediction (based on the preceding events for the current gesture, and the speed/trajectory of the movement) what the position of future pointer movements may be. Applications can use this information with the getPredictedEvents() method to speculatively "draw ahead" to a predicted position to reduce perceived latency, and then discarding these predicted points once the actual points are received.

各 `PointerEvent$I ~obj %~event には `予測d~event~list@ が結付けられる — それは、 `PointerEvent$I ~objたちが成す~listである。 この~listは： ◎ A PointerEvent has an associated predicted events list (a list of zero or more PointerEvents).＼

• %~event は`~trusted$である場合 ⇒ %~event の~event型は `pointermove$et ならば，［ ~UAが［ 未来に %~event に後続することになる ］ものと予測する `PointerEvent$I ~objが成す連列 ］になり、 他の場合は空になる。 ◎ For trusted pointermove events, it is a sequence of PointerEvents that the user agent predicts will follow the event in the future. For all other trusted event types, it is an empty list.＼
• %~event は`~trusted$でない場合 ⇒ 構築子に渡された値に初期化される。 ◎ Untrusted events have their predicted events list initialized to the value passed to the constructor.

注記： `pointerrawupdate$et ~eventは、 その`合体d~event~list$は，空でないこともあるが、 その`予測d~event~list$は，処理能の理由により通例的に空になる。 ◎ Note While pointerrawupdate events may have a non-empty coalesced events list, their predicted events list will, for performance reasons, usually be an empty list.

注記： ある`予測d~event~list$ %~list を包含している~trustedな~eventが~JSから配送し直されたときは、 当の~event の `isTrusted$m は~event配送~algoにより ~F に設定されるが， %~list を成す各~eventの `isTrusted^m は元の値 ~T から変化しない。 ◎ Note When a trusted event containing a predicted events list is re-dispatched from JavaScript, the event dispatch algorithm sets the isTrusted bit of the event to false but the same bits in the predicted events list remain unchaged from their original true values.

この~listを成す~eventの個数, および［ 各~eventが現在の時刻印から どれほど離れるか ］は、［ ~UA, ~UAが利用する予測~algo ］により決定される。 ◎ The number of events in the list and how far they are from the current timestamp are determined by the user agent and the prediction algorithm it uses.

`~trusted$な`~pointer~event$ %~event の`予測d~event~list$ — 配送された %~event に対し，その `getPredictedEvents()$m ~methodを~callして得られるそれ — を成す各~eventは： ◎ The events in the predicted events list of a trusted event will have:

• その `timeStamp$m 値 `DOM$r は、 %~event の `timeStamp$m 以上になる, かつ ~list順に単調増加する。 ◎ Monotonically increasing timeStamp values [DOM]＼ — all predicted events have a timeStamp that is greater than or equal to the timeStamp of the dispatched pointer event that the getPredictedEvents() method was called on.＼

  すなわち，`予測d~event~list$は、 `timeStamp$m 値により時系列順に~sortするモノトスル — ~listを成す最初の~eventの `timeStamp$m が最~小になる。 ◎ The predicted events list MUST be chronologically sorted by timeStamp, so the first event will have the smallest timeStamp.

• その［ `pointerId$m, `pointerType$m, `isPrimary$m ］属性は、 %~event のそれらと同じになる。 ◎ The same pointerId, pointerType, and isPrimary as the dispatched "parent" pointer event.
• その自前の［ `合体d~event~list$, `予測d~event~list$ ］は空になる。 ◎ Empty coalesced events list and predicted events list of their own.

注記： 作者は、 予測された~eventを［ 次回に~pointer~eventが配送されるまでの間に限り， 妥当な予測と見なすベキである ］ことに注意。 ~UAが未来のどこまで~eventを予測するかに依存するが、 定例の~pointer~eventは， 予測された~eventのうち いくつかの時刻印より早くに配送されることもアリである。 ◎ Note Note that authors should only consider predicted events as valid predictions until the next pointer event is dispatched. It is possible, depending on how far into the future the user agent predicts events, that regular pointer events are dispatched earlier than the timestamp of one or more of the predicted events.

let %predicted_points = [];
window.addEventListener("pointermove", function(%event) {
  /* 
それまでに描いた予測された点群を~clearする。
◎
Clear the previously drawn predicted points.
 */
  for (let %e of %predicted_points.reverse())
    clearPoint(%e.pageX, %e.pageY);

  /* 
最後に受取った~event以降に起きた，実際の動きを描く。
◎
Draw the actual movements that happened since the last received event.
 */
  for (let %e of %event.getCoalescedEvents())
    drawPoint(%e.pageX, %e.pageY);

  /* 
待時間の知覚を抑制するため，現在の予測された点群を描く。
◎
Draw the current predicted points to reduce the perception of latency.
 */
  %predicted_points = %event.getPredictedEvents();
  for (let %e of %predicted_points)
    drawPoint(%e.pageX, %e.pageY);
});

10.3. 合体d~event~list, 予測d~event~listの拡充-法と保守-法

【 これらの手続きの要件~levelは、 なぜ “ベキ” とされている？ 】

11.1. 旧来の~mouse~pointerに対する位置の追跡-法

`互換性~mouse~event$を生産し得るのは`首~pointer$に限られるが、 `複数の首~pointer＠#multiple-primary-pointers$が — 各自が自前の`互換性~mouse~event$を生産するように — 同時に作動中になり得る。 `MouseEvent$I に依拠している~scriptとの互換性を得るため、 ~mouse遷移~event （ `mouseover$et ／ `mouseout$et ／ `mouseenter$et ／ `mouseleave$et ） は，単独の旧来の~mouse入力の動きを模倣するベキである。 このことは、 どの~event~targetに対しても，［ ~mouseの出入り状態は， `UIEVENTS$r に則って妥当になる ］ことを意味する。 ~UAは、 文書~内の `旧来の~mouse~pointerの実効~位置@ を次に従って保守することにより，これを保証するベキである。 ◎ While only primary pointers can produce compatibility mouse events, multiple primary pointers can be active simultaneously, each producing its own compatibility mouse events. For compatibility with scripts relying on MouseEvents, the mouse transition events (mouseover, mouseout, mouseenter and mouseleave) SHOULD simulate the movement of a single legacy mouse input. This means that the entry/exit state for every event target is valid, in accordance with [UIEVENTS]. Users agents SHOULD guarantee this by maintaining the effective position of the legacy mouse pointer in the document as follows.

【 例えば、 同じ要素に向けて `mouseenter$et が（ `mouseleave$et を挟まずに）続けて発火されないようにするなど。 】

11.2. ~hoverを~supportする装置~用の対応付け

11.3. ~hoverを~supportしない装置~用の対応付け

ほとんどの~touchscreenなど、 `作動中$でない間は，座標（または座標たちが成す集合）に対する~hoverを~supportしない装置もある。 ~mouse~event向けに書かれている既存の多数の~codeは、 ~eventが~mouseにより生産されていて，次の~~性質が一般に成り立つものと見做している： ◎ Some devices, such as most touchscreens, do not support hovering a coordinate (or set of coordinates) while not in the active state. Much existing content coded to mouse events assumes that a mouse is producing the events and thus certain qualities are generally true:

• 入力は、 作動化と独立に~hoverできる （例：どの~buttonも押さないまま~mouse~cursorを動かす）。 ◎ The input can hover independently of activation (e.g. moving a mouse cursor without any buttons pressed).
• 入力は、 要素が~clickされる前に `mousemove$et ~eventを生産する見込みが高い。 ◎ The input will likely produce the mousemove event on an element before clicking it.

注記： ~hoverは、 ~mouse向けに設計された内容にて，~UI要素の可視性を~toggleするために利用されることもある （例： “~hover~menu” ）。 そのような内容は、 `~hoverを~supportしない装置$と互換にならないことが多い。 この仕様は、 この局面における互換性を得るための対応付けや挙動は定義しない。 それは、 将来~versionの仕様にて考慮されることになる。 ◎ Note Hover is sometimes used to toggle the visibility of UI elements in content designed for mouse (e.g. "hover menus"). This content is often incompatible with devices that do not support hover. This specification does not define a mapping or behavior for compatibility with this scenario. It will be considered in a future version of the specification.

［ `~pointer~event$, `TOUCH-EVENTS$r に定義される~touch~event ］どちらも~supportする~UAは、［ この節に述べた`互換性~mouse~event$, `TOUCH-EVENTS$r にて要旨される`~fallback~mouse~event＠~TOUCHEVENTS#mouse-events$ ］を両方とも生成しないモノトスル。 ◎ If the user agent supports both Touch Events (as defined in [TOUCH-EVENTS]) and Pointer Events, the user agent MUST NOT generate both the compatibility mouse events as described in this section, and the fallback mouse events outlined in [TOUCH-EVENTS].