Pointer Events Level 4 （日本語訳）

1. 序論

今日のほとんどの `HTML$r 内容は、 ~mouse入力~向けに利用され／設計されている。入力を~custom方式で取扱う~codeは、概して `~mouse~event$向けに書かれている。しかしながら，今日のより新たな~computing機器は、 ~touchscreen, ~pen入力, 等々も含む，他の形による入力も組入れている。これらの入力~形の各々に対し，それを取扱うための~event型が個別に提案されてきている。しかしながら，そのような~approachでは、新たな型の入力~用に~supportが追加される度に，不必要な~logicの重複や, ~eventの取扱いにおける~overheadも招かれ易くなる。これはまた、内容がある型の装置のみを念頭に書かれるときにも，互換性の問題を生じさせ易い。加えて，~mouse用に書かれている既存の内容との互換性を得るため、ほとんどの`~UA$は，どの型の入力に対しても`~mouse~event$を発火する。このため、 `~mouse~event$が［実際の~mouse装置を表現している］のか, ［別の型の入力~装置から，互換性を得るために生産されたもの］なのか，多義的になり、双方の型の装置に対応する~codeを書くのも難しくなっている。 ◎ Today, most [HTML] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [UIEVENTS] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens, pen input, etc. Event types have been proposed for handling each of these forms of input individually. However, that approach often incurs unnecessary duplication of logic and event handling overhead when adding support for a new input type. This often creates a compatibility problem when content is written with only one device type in mind. Additionally, for compatibility with existing mouse-based content, most user agents fire Mouse Events for all input types. This makes it ambiguous whether a Mouse Event represents an actual mouse device or is being produced from another input type for compatibility, which makes it hard to code to both device types simultaneously.

複数の入力~型に対応する~codeを書く手間を減らすため，および上に述べた`~mouse~event$の多義性に~~対処し易くするため、この仕様は，`~pointer$と呼ばれるより抽象的な入力~形を定義する。［ ~mouse~cursor, ~pen, ~touch（複-~touchも含む）, その他］の~pointing装置により ~screen上に入力されるどの接触~点も，~pointerになり得る。この~modelにより、［利用者~側の~hardwareを問わず，~siteや~appを上手く働くように書く］ことは，より容易になる。装置に特有な取扱いが欲される局面においては、この仕様は，当の~eventを生産した装置の型を検分するための属性も定義する。 ◎ To reduce the cost of coding to multiple input types and also to help with the above described ambiguity with Mouse Events, this specification defines a more abstract form of input, called a pointer. A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. This model makes it easier to write sites and applications that work well no matter what hardware the user has. For scenarios when device-specific handling is desired, this specification also defines properties for inspecting the device type which produced the event.＼

この仕様の首な目標は、［装置に依らない~pointer入力に対応する著作は、より容易にする］一方で［利用者体験の~~向上に必要yな所では、装置に特有な取扱いに限り許容する］ような，一式の［ ~event, および~interface ］を供することである。 ◎ The primary goal is to provide a single set of events and interfaces that allow for easier authoring for cross-device pointer input while still allowing for device-specific handling only when necessary for an augmented experience.

~~第二の目標は、 ~UAが`直な~pan-zoom$による動作（一例として、 ~touchscreenに対する手指や~stylusによるそれ）を — ~script実行を阻むことなく — 取扱えるよう，複-~thread化も可能化することである。 ◎ An additional key goal is to enable multi-threaded user agents to handle direct manipulation actions for panning and zooming (for instance, with a finger or stylus on a touchscreen), without blocking on script execution.

注記：この仕様は、種々の~pointer入力~用に統一された~event~modelを定義する。 ~keyboardに類する~UIなど，他の形の入力は、この~modelは受持たない（一例として、 ~touchscreenのみの装置~上で稼働中の~screen~readerや類似な支援技術 — ~focus可能な［ ~controlや要素］を通して，利用者による連列的~naviを許容するような）。その種の~UIに呼応して~pointer~eventを生成する~UAもあるかもしれないが、それについては，この仕様は受持たない。 ◎ Note While this specification defines a unified event model for a variety of pointer inputs, this model does not cover other forms of input such as keyboards or keyboard-like interfaces (for instance, a screen reader or similar assistive technology running on a touchscreen-only device, which allows users sequential navigation through focusable controls and elements). While user agents might choose to also generate pointer events in response to these interfaces, this scenario is not covered in this specification.

注記：作者には、まず~~第一に，［どの形の入力に対しても、高~levelな~event — `focus$et, `blur$et, `click$et など — で応答することにより，等価な機能性を供する］ことが奨励される。しかしながら，低~levelな~event（`~pointer~event$など）を利用するときは、［すべての型の入力~用の~supportを確保する］ことが奨励される。 ~keyboardに類する~UIの事例においては、そのためには，［ ~keyboard~event用の明示的な取扱い］の追加が要求されることもある。詳細は、 `WCAG22$r `§ 指針 2.1：~keyboard~access可能＠~TR/WCAG/#keyboard-accessible$ を見よ。 ◎ Note In the first instance, authors are encouraged to provide equivalent functionality for all forms of input by responding to high-level events such as focus, blur and click. However, when using low-level events (such as Pointer Events), authors are encouraged to ensure that all types of input are supported. In the case of keyboards and keyboard-like interfaces, this might require the addition of explicit keyboard event handling. See WCAG Guideline 2.1 Keyboard Accessible [WCAG22] for further details.

~pointerは、［ ~screen上の特定の座標（または座標たちが成す集合）を~targetに捉えられる入力~装置］の~hardwareに不問な表現である。 ◎ Figure 1＼ A pointer is a hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen.

汎用~pointer入力を取扱うための~eventは、 ~mouse用のものとよく似る： `pointerdown$et, `pointermove$et, `pointerup$et, `pointerover$et, `pointerout$et, 等々。これは、［内容を各種`~mouse~event$から`~pointer~event$への容易な移行］を手助けする。 `~pointer~event$は、各種`~mouse~event$に在る通例の属性すべて（~client座標, ~target要素, ~button状態, 等々）を供することに加え，他の形の入力 — 押圧（ `pressure^en ）, `接触~幾何$（ `contact geometry^en ）, 傾き（ `tilt^en ）, 等々 — 用の新たな属性も供する。作者は、 `~pointer~event$の~codeを［異なる【装置】型の入力~間で同じ~logicを共有する］ように書くことが容易になり、最良な利用者体験に必要yな所に限って，特定0の型の入力を~custom化できる。 ◎ The events for handling generic pointer input look a lot like those for mouse: pointerdown, pointermove, pointerup, pointerover, pointerout, etc. This facilitates easy content migration from Mouse Events to Pointer Events. Pointer Events provide all the usual properties present in Mouse Events (client coordinates, target element, button states, etc.) in addition to new properties for other forms of input: pressure, contact geometry, tilt, etc. So authors can easily code to Pointer Events to share logic between different input types where it makes sense, and customize for a particular type of input only where necessary to get the best experience.

様々な入力~装置が`~pointer~event$の~sourceになり得るが、 `~pointer~event$が他の［何らかの装置に特有な~eventたちが成す集合（例：各種 `~mouse~event$, ~touch~event, 等々）］に属する~eventに伴って生成されるものとして定義されることはない。この仕様は、他の装置に特有な~eventの~supportは，要求しない。そうすることもアリであり，互換性を得るために奨励されるが。 ~UAは、他のどの装置~eventも~supportすることなく， ~pointer~eventを~supportできる。［ ~mouseに特有な~event用に書かれた内容］との互換性を得るため、この仕様は，［ ~mouse以外の装置による~pointer入力に基づいて，`互換性~mouse~event$を生成する］ための方法も述べる。 ◎ While Pointer Events are sourced from a variety of input devices, they are not defined as being generated from some other set of device-specific events. While possible and encouraged for compatibility, this spec does not require other device-specific events be supported (e.g. mouse events, touch events, etc.). A user agent could support pointer events without supporting any other device events. For compatibility with content written to mouse-specific events, this specification does provide an optional section describing how to generate compatibility mouse events based on pointer input from devices other than a mouse.

この仕様は、［ `~pointer~event$, `TOUCH-EVENTS$r に定義される~touch~event ］の両者を~supportする~UAに対し期待される挙動については，何も~~述べない。これら二つの仕様の関係性についての更なる情報は、 `Touch Events Community Group＠https://www.w3.org/community/touchevents/$ を見よ。 ◎ This specification does not provide any advice on the expected behavior of user agents that support both Touch Events (as defined in [TOUCH-EVENTS]) and Pointer Events. For more information on the relationship between these two specifications, see the Touch Events Community Group.

2. 適合性

【以下、この節の他の内容は `~W3C日本語訳共通~page＠~W3Ccommon#conformance$ に移譲。】

【この訳に特有な表記規約】

◎表記記号

3. 例

◎非規範的

以下では、この仕様における一部の~APIを作者がどう利用し得るかをデモる基本的な例を与える。さらには、より特定な例も，この文書を成す関連な節に供される。 ◎ The following are basic examples that demonstrate how some of the APIs in this specification might be used by authors. Further, more specific examples are provided in the relevant sections of this document.

`1@ex： ~pointer~event特能を検出して，~eventを~bindする： ◎ Example 1: Feature detection and event binding

/* 
`~pointer~event$, または［
伝統的 ~touch／~mouse
］のいずれかを~bindする
◎
Bind to either Pointer Events or traditional touch/mouse
 */

if (window.PointerEvent) {
    /* 
`~pointer~event$が~supportされる場合は、
~pointer~eventのみを~listenする
◎
if Pointer Events are supported, only listen to pointer events
 */
    %target.addEventListener("pointerdown", function(%event) {
        /* 
必要yなら、［
~touch／~pen／~mouse
］に対する異なる挙動~用に，
%event`.pointerType^c
に基づいて，別々な~logicを適用する
◎
if necessary, apply separate logic based on e.pointerType for different touch/pen/mouse behavior
 */
        ...
    });
    ...
} else {
    /* 
伝統的な ~touch／~mouse ~event~handler
◎
traditional touch/mouse event handlers
 */
    %target.addEventListener('touchstart', function(%event) {
        /* 
互換性~mouse~eventと~clickを防止する
◎
prevent compatibility mouse events and click
 */
        %event.preventDefault();
        ...
    });
    ...
    %target.addEventListener('mousedown', ...);
    ...
}

/* 
~keyboardを取扱うための，追加的な~event~listener
◎
additional event listeners for keyboard handling
 */
...

`2@ex：利用者による入力を検出する例： ◎ Example 2: Detecting the type of input from a user

window.addEventListener("pointerdown", %detectInputType);

function detectInputType(%event) {
    switch(%event.pointerType) {
        case "mouse":
            /* 
~mouse入力が検出された
◎
mouse input detected
 */
            break;
        case "pen":
            /* 
~penや~stylusからの入力が検出された
◎
pen/stylus input detected
 */
            break;
        case "touch":
            /* 
~touch入力が検出された
◎
touch input detected
 */
            break;
        case "":
            /* 
空~文字列は、
~UAが検出できない装置を意味する
◎
↓ */
            break;
        default:
            /* 
~UAに特有な~custom型
◎
pointerType is empty (could not be detected) or UA-specific custom type
 */
    }
}

`3@ex：要素~sizeを`接触~幾何$に合わせる例： ◎ Example 3: Resizing an element to match the contact geometry

<div style=
    "position:absolute;
    top:0px; left:0px;
    width:100px; height:100px;"
></div>
<script>
window.addEventListener("pointerdown", checkPointerSize);

function checkPointerSize(%event) {
    %event.target.style.width = %event.width + "px";
    %event.target.style.height = %event.height + "px";
}
</script>

`4@ex： ~scriptから`~trusted$でない~pointer~eventを発火する例： ◎ Example 4: Firing untrusted pointer events from script

const %event1 = new PointerEvent("pointerover", {
    bubbles: true,
    cancelable: true,
    composed: true,
    pointerId: 42,
    pointerType: "pen",
    clientX: 300,
    clientY: 500
});
%eventTarget.dispatchEvent(%event1);

let %pointerEventInitDict = {
  bubbles: true,
  cancelable: true,
  composed: true,
  pointerId: 42,
  pointerType: "pen",
  clientX: 300,
  clientY: 500,
};
const %p1 = new PointerEvent("pointermove", %pointerEventInitDict);
%pointerEventInitDict.clientX += 10;
const %p2 = new PointerEvent("pointermove", %pointerEventInitDict);
%pointerEventInitDict.coalescedEvents = [%p1, %p2];
const %event2 = new PointerEvent("pointermove", %pointerEventInitDict);
%eventTarget.dispatchEvent(%event2);

`5@ex： `pointerdown^et に対し，~penの色をアテガう例 ◎ Example 5: Assigning a pen color on PointerDown

<div style="position:absolute; top:0px; left:0px; width:100px;height:100px;"></div>

window.addEventListener("pointerdown", assignPenColor);
window.addEventListener("pointermove", assignPenColor);
const %colorMap = new Map();

function assignPenColor(%event) {
    const %uniqueId = %event.persistentDeviceId;
    /* 
一意な~IDが存在するか否か検査する
◎
Check if a unique Id exists.
 */
    if (%uniqueId == 0) {
        return;
    }
    /* 
当の装置には色はアテガわれたか否か検査する
◎
Check if a color has been assigned to the device.
 */
    if (%colorMap【！map】.has(%uniqueId)) {
        return;
    }
    /* 
当の装置に色をアテガう
◎
Assign a color to the device.
 */
    let %newColor = getNewColor();
    %colorMap【！map】.set(%uniqueId, %newColor);
    return %newColor;
}

function getNewColor() {
    /* 
何らかの色~値を返す
◎
return some color value
 */
}

4. 各種~pointer~eventと各種~interface

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 軸の解釈に影響し得るのか, どう影響するのかについては、この仕様には述べられていない。】

正な `tiltX$m 。 ◎ Figure 2＼ Positive tiltX.

`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.

正な `tiltY$m 。 ◎ Figure 3＼ Positive tiltY.

`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.

`altitudeAngle^m が π/4 をとるとき（~X-Y平面から 45° ）。 ◎ Figure 4＼ Example altitudeAngle of π/4 (45 degrees from the X-Y plane).

`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.

`azimuthAngle^m が π/6 をとるとき（ “4 時” を指す）。 ◎ Figure 5＼ Example azimuthAngle of π/6 ("4 o'clock").

`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.

4.1.1. ~button状態

4.1.1.1. ~buttonの追加押下げ

~mouseや~penなどの一部の~pointer装置は、複数の~buttonを~supportする。 `~mouse~event$~model `UIEVENTS$r においては、どの~buttonが押されたときも［ `mousedown$et, `mouseup$et ］~eventが生産される。この~hardware相違をより良く抽象-化して，入力に対する装置に依らない著作を単純~化するため、`~pointer~event$においては， `~buttonの追加押下げ@ （ `chorded button press^en ） — ~pointer装置の別の~buttonがすでに押下されている間に，追加的な~buttonを押下すること — に対し［ `pointerdown$et, `pointerup$et ］~eventが重ねて発火されることはない†。 ◎ Some pointer devices, such as mouse or pen, support multiple buttons. In the [UIEVENTS] Mouse Event model, each button press produces a mousedown and mouseup event. To better abstract this hardware difference and simplify cross-device input authoring, Pointer Events do not fire overlapping pointerdown and pointerup events for chorded button presses (depressing an additional button while another button on the pointer device is already depressed).

【† ~button A, B をこの順に押して，同じ順に離した場合、 `pointerup$et は，最後に B を離したときに呼応して発火される？それとも A を離したときに発火される？】

~buttonの追加押下げは、［ `button$m, `buttons$m ］属性の変化を検分すれば検出できる†。これらの属性は `MouseEvent$I ~interfaceから継承されるが、意味論と値には，次~節~以下に要旨する変更が加えられている。 ◎ Instead, chorded button presses can be detected by inspecting changes to the button and buttons properties. The button and buttons properties are inherited from the MouseEvent interface, but with a change in semantics and values, as outlined in the following sections.

【† 追加押下げに対しては、少なくとも，何らかの（ `pointerdown$et, `pointerup$et 以外の）~pointer~eventが発火される。 `pointermove$et を見よ。】

［ `button^m ／ `buttons^m ］属性に対する改変が適用されるのは、 ~pointer~eventに限られる。しかしながら，［ `click$et, `auxclick$et, `contextmenu$et ］~eventの［ `button^m ／ `buttons^m ］の値は、 `互換性~mouse~event$の事例と同じく， `UIEVENTS$r に従うモノトスル。 ◎ The modifications to the button and buttons properties apply only to pointer events. However for click, auxclick and contextmenu the value of button and buttons MUST follow [UIEVENTS], as is the case for compatibility mouse events .

4.1.1.2. `button^m 属性

~pointer~eventにおける~button状態の（単なる `pointerdown$et, `pointerup$et を超える）遷移を識別するため、 `button$m 属性は，状態~変化により~eventを発火させた装置~buttonを指示する。 ◎ To identify button state transitions in any pointer event (and not just pointerdown and pointerup), the button property indicates the device button whose state change fired the event.

装置の~button変化 ◎ Device Button Changes	`button^m
前回の~eventから，どの~buttonも, どの~touch／~pen接触も変化していない ◎ Neither buttons nor touch/pen contact changed since last event	−1
~mouseの左~buttonが押されている／ ~touch接触がある／ ~pen接触がある ◎ Left Mouse, Touch contact, Pen contact	0
~mouseの中央~buttonが押されている ◎ Middle Mouse	1
~mouseの右~buttonが押されている／ ~penの~barrel~buttonが押されている ◎ Right Mouse, Pen barrel button	2
~mouseの x1（ `back^en ）~buttonが押されている ◎ X1 (back) Mouse	3
~mouseの x2（ `forward^en ）~buttonが押されている ◎ X2 (forward) Mouse	4
~penの~eraser~buttonが押されている ◎ Pen eraser button	5

注記： ~mouse~dragの間、 `pointermove$et ~eventにおける `button^m 属性の値は， `mousemove$et ~eventから異なることになる。例えば，右~buttonを押しながら~mouseを動かしている間、 `pointermove$et ~eventの `button^m 値は −1 になる一方で， `mousemove$et ~eventの `button^m 値は 2 になる。 ◎ Note During a mouse drag, the value of the button property in a pointermove event will be different from that in a mousemove event. For example, while moving the mouse with the right button pressed, the pointermove events will have the button value -1, but the mousemove events will have the button value 2.

4.1.1.3. `buttons^m 属性

`buttons$m 属性は、装置の個々の~buttonの現在の状態を~bitmaskとして与える（ `MouseEvent$I におけるそれと同じだが、アリな値は拡げられている）。 ◎ The buttons property gives the current state of the device buttons as a bitmask (same as in MouseEvent, but with an expanded set of possible values).

装置の現在の~button状態 ◎ Current state of device buttons	`buttons^m
［ ~mouse ／ ~hoverしている~pen ］はどの~buttonも押されずに動いている ◎ Mouse moved with no buttons pressed, Pen moved while hovering with no buttons pressed	0
~mouseの左~buttonが押されている／ ~touch接触がある／ ~pen接触がある ◎ Left Mouse, Touch contact, Pen contact	1
~mouseの中央~buttonが押されている ◎ Middle Mouse	4
［ ~mouseの右~button ／ ~penの~barrel~button ］が押されている ◎ Right Mouse, Pen barrel button	2
~mouseの x1（ `back^en ）~buttonが押されている ◎ X1 (back) Mouse	8
~mouseの x2（ `forward^en ）~buttonが押されている ◎ X2 (forward) Mouse	16
~penの~eraser~buttonが押されている ◎ Pen eraser button	32

4.1.2. 首~pointer

複-~pointer装置（例：複-~touch）【複数の装置ではなく，複数の同時並行な接触を~supportする~pointer装置】に対しては、 `isPrimary$m 属性が，`首~pointer$を識別するために利用される。各`~pointer型$に対し， `首~pointer@ （ `primary pointer^en ）とは、その型の~pointer用の`作動中な~pointer$たちが成す集合の中で，主導的とされる~pointerである： ◎ In a multi-pointer (e.g. multi-touch) scenario, the isPrimary property is used to identify a master pointer amongst the set of active pointers for each pointer type.

どの時点であれ、 `首~pointer$は，各`~pointer型$に対し高々一つまでとする。 ◎ At any given time, there can only ever be at most one primary pointer for each pointer type.
特定0の`~pointer型$に対し最初に作動中になる~pointer（例えば複-~touchによるヤリトリなら，手指による~screenへの最初の~touch）が、その`~pointer型$の`首~pointer$になる。 ◎ The first pointer to become active for a particular pointer type (e.g. the first finger to touch the screen in a multi-touch interaction) becomes the primary pointer for that pointer type.
`首~pointer$のみが`互換性~mouse~event$を生産することになる。【複数の型の~pointer装置が同時並行に利用されていて】`首~pointer$が複数ある事例では、各~首~pointerが`互換性~mouse~event$を生産することになる。 ◎ Only a primary pointer will produce compatibility mouse events. In the case where there are multiple primary pointers, these pointers will all produce compatibility mouse events.

注記：作者は、欲するなら，首~pointer以外を無視することで単独の~pointerによるヤリトリを達成できる（しかしながら，下の `複数の首~pointerについての注記＠#multiple-primary-pointers$ を見よ）。 ◎ Note Authors who desire single-pointer interaction can achieve this by ignoring non-primary pointers (however, see the note below on multiple primary pointers).

注記：複数の型の~pointer装置が同時並行に利用されている場合、それぞれの~pointer（各`~pointer型$【！pointerType】ごとに一つ）が首と見なされる。例えば，同時に動いた［ ~touch接触と~mouse~cursor ］は、どちらも首と見なされる~pointerを生産することになる。 ◎ Note When two or more pointer device types are being used concurrently, multiple pointers (one for each pointerType) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.

注記： ~OSや~UAは、一部の装置に対し — 偶発的なヤリトリを避けるため — 複数の型の~pointer入力の同時並行な利用を無視することもある。一例として，［ ~touch, ~pen ］両者によるヤリトリを~supportする装置は、 ~penが利用-中にある間は — 利用者が~touchscreen上で手を休めれるよう — ~touch入力を無視することもある（この特能は “`palm rejection^en” 【 “手のひらが触れても~~無視する” 】と共通的に称されている）。現時点では、作者がこの挙動を抑止することはアリでない。 ◎ Note Some devices, operating systems and user agents may ignore the concurrent use of more than one type of pointer input to avoid accidental interactions. For instance, devices that support both touch and pen interactions may ignore touch inputs while the pen is actively being used, to allow users to rest their hand on the touchscreen while using the pen (a feature commonly referred to as "palm rejection"). Currently, it is not possible for authors to suppress this behavior.

注記： ~UAが、どの~pointerも`首~pointer$とされていない下で， ~pointer~eventを発火する可能性もある。一例として、特定0の型の`作動中な~pointer$が複数あって（例：複-~touchによるヤリトリ）， `首~pointer$が除去された場合（例：~screenから離された）、首~pointerは無いことになろう。また、 `首~pointer$が［ ~UAを~targetにしていないものも含む，装置~上で作動中かつ型も同じ~pointerすべて］を利用して決定される~platformにおいては、首~pointerが~UAの外側にあって，別の~pointerが~UAの内側を~targetにしている場合、 ~UAは，後者の~pointer用に `isPrimary$m が ~F にされた`~pointer~eventを発火-$し得る。 ◎ Note In some cases, it is possible for the user agent to fire pointer events in which no pointer is marked as a primary pointer. For instance, when there are multiple active pointers of a particular type, like a multi-touch interaction, and the primary pointer is removed (e.g. it leaves the screen), there may end up being no primary pointers. Also on platforms where the primary pointer is determined using all active pointers of the same type on the device (including those targeted at an application other than the user agent), if the first (primary) pointer is outside of the user agent and other (non-primary) pointers targeted inside the user agent, then the user agent may fire pointer events for the other pointers with a value of false for isPrimary.

注記：現在の~OSや~UAは、通例的に複数の~mouseによる入力の概念を備えていない。複数の~mouse装置が在る場合（一例として、 ~trackpadと外部~mouseを備える~laptopなど）、一般に，それらは一まとめに単独の装置として扱われる — どの装置による動きも，単独の~mouse~pointerの動きに翻訳され、異なる~mouse装置で押される~buttonは~~区別されない。この理由から、 ~mouse~pointerは通例的に一つだけあり，それが首~pointerになることになる。【したがって、 2 個の~mouseが接続されていて，互いに同種の~button（例：左~button）が［順に押されてから, 同じ順に離された］とするとき、［ 2 回目に押されたとき, 1 回目に離されたとき］は，無視されることになろう。】 ◎ Note Current operating systems and user agents don't usually have a concept of multiple mouse inputs. When more than one mouse device is present (for instance, on a laptop with both a trackpad and an external mouse), all mouse devices are generally treated as a single device — movements on any of the devices are translated to movement of a single mouse pointer, and there is no distinction between button presses on different mouse devices. For this reason, there will usually only be a single mouse pointer, and that pointer will be primary.

4.1.3. `PointerEvent^I ~interfaceを利用する~eventの発火-法

名前 %e の `~pointer~eventを発火する@ ~algoは： ◎ To fire a pointer event named e means to fire an event named e＼

【！`~eventを発火する$】 %~event ~LET `~eventを作成する$( `PointerEvent$I ) ◎ using PointerEvent＼
%~event の各種~属性を［ `PointerEvent$I ~interface, および `§ 各種属性と既定~動作＠#attributes-and-default-actions$ ］の定義に従って設定する ◎ whose attributes are set as defined in PointerEvent Interface and Attributes and Default Actions.
%~pointer ~LET この %~event を生じさせた`作動中な~pointer$ （ %~eventの `pointerId$m で識別されるそれ） ◎ ↓
~IF［ %e ~NIN { `gotpointercapture$et, `lostpointercapture$et, `click$et, `auxclick$et, `contextmenu$et } ］ ⇒ `処理待ち~pointer捕捉を処理する$( %~pointer ) ◎ If the event is not a gotpointercapture, lostpointercapture, click, auxclick or contextmenu event, run the process pending pointer capture steps for this PointerEvent.
%~target ~LET ［ %~pointer の`捕捉~target$ ~NEQ ~NULL ならばそれ／ ~ELSE_ 通常の`~pointing先$ ］ ◎ Determine the target at which the event is fired as follows: ◎ • If the pointer capture target override has been set for the pointer, set the target to pointer capture target override object. ◎ • Otherwise, set the target to the object returned by normal hit test mechanisms (out of scope for this specification).
~IF［ %e ~IN { `pointerdown$et, `pointermove$et, `pointerup$et } ］ ⇒ %~pointer にて`作動中な文書$ ~SET %~target の`~node文書$ `DOM$r ◎ Let targetDocument be target's node document [DOM]. ◎ If the event is pointerdown, pointermove, or pointerup, set active document for the event's pointerId to targetDocument.
~IF［ %e ~EQ `pointerdown$et ］~AND［ %~pointer を動かしている装置は、 `直な操作$を~~為すものである］~AND［ %~target は `Element^I である］ ⇒ `~pointer捕捉を設定する$( %~target, %~pointer ) （ `§ 暗黙的な~pointer捕捉＠#implicit-pointer-capture$に述べられるとおりに） ◎ If the event is pointerdown, the associated device is a direct manipulation device, and the target is an Element, then set pointer capture for this pointerId to the target element as described in implicit pointer capture.
~UAは，`~event順序付けを確保する＠~UIEVENTS#events-mouseevent-event-order$ `UIEVENTS$r ためとして、 %~event を発火する【次の段で配送する】前に，［当の~pointing装置は %~pointer の`前回の~target$から %~target 上へ移動した］かのように~targetを扱うベキである。 %~pointer の`~over~eventは必要か$ ~EQ ~T の場合、 `pointerover$et ~eventが必要になる【いつ配送するのかは明瞭に述べられていない】 — ~target要素が同じ【`前回の~target$ ~EQ %~target 】であった場合でも。 ◎ Before firing this event, the user agent SHOULD treat the target as if the pointing device has moved over it from the previousTarget for the purpose of ensuring event ordering [UIEVENTS]. If the needsOverEvent flag is set, a pointerover event is needed even if the target element is the same.
【！`~eventを発火する$】 `~eventを配送する$( %~target, %~event ) ◎ Fire the event to the determined target.
%~pointer 【！the given pointer】の`前回の~target$ ~SET %~target【！the determined target】 ◎ Save the determined target as the previousTarget for the given pointer,＼
%~pointer の`~over~eventは必要か$ ~SET ~F ◎ and reset the needsOverEvent flag to false.＼

この~algoの目的においては：

各`作動中な~pointer$には，次に挙げるものが結付けられる：
- `前回の~target@ （ `previousTarget^en ） ⇒ ε／ある要素 — 初期~時は ε とする。
  
  【初期~時の値は、原文には定義されていない — ~UIwindowの外を表現すると思われる。】
- `~over~eventは必要か@ （ `needsOverEvent^en ） ⇒ 真偽値 — 初期~時は ~F とする。
これらは、 %~pointer の`前回の~target$が`切断された$ときには，次に従って更新するとする：
1. %~pointer の`前回の~target$ ~SET 配送している~eventの`~event経路＠~DOM4#event-path$の中で`前回の~target$から【`接続されて$いたときの】`親＠~DOM4#get-the-parent$を順に追っていって，まだ`接続されて$いる最初のもの `DOM$r
2. %~pointer の`~over~eventは必要か$ ~SET ~T
【 `前回の~target$が影響する箇所は，上で %~event を配送する直前の段なので、 `接続されて$いるか否かの検査は，その前のどこかで行われることになろう。】

◎ If the previousTarget at any point will no longer be connected [DOM], update the previousTarget to the nearest still connected [DOM] parent following the event path corresponding to dispatching events to the previousTarget, and set the needsOverEvent flag to true.

注記：通常の`~pointing先$に代えて`捕捉~target$を利用することは、 `UIEVENTS$r に定義されるとおり，何らかの`境界~event$を発火する結果になり得る。これは、 ~pointerがそれまでの~targetから出て【 `pointerleave$et 】，この新たな［それを`捕捉している~target$ ］に入った【 `pointerenter$et 】場合と同じになる。捕捉が解放されたときにも — ~pointerが、それを`捕捉している~target$から出て，接触判定による~targetに入るに伴い — 同じことが起こり得る。 ◎ Note Using the pointer capture target override as the target instead of the normal hit-test result may fire some boundary events, as defined by [UIEVENTS]. This is the same as the pointer leaving its previous target and entering this new capturing target. When the capture is released, the same scenario may happen, as the pointer is leaving the capturing target and entering the hit-test target.

4.1.3.1. 各種属性と既定~動作

この仕様にて定義される各種~event型~用の `bubbles$m, `cancelable$m ~prop および既定~動作を，次の表tに示す。これらの各~event型の詳細は、 `§ 各種 ~pointer~event型＠#pointer-event-types$ にて供される： ◎ The bubbles and cancelable properties and the default actions for the event types defined in this specification appear in the following table. Details of each of these event types are provided in Pointer Event types.

`mousedown$et と同じ (1)

`pointermove$et

する

可

`mousemove$et と同じ (1)

`gotpointercapture$et

する

不可

なし

`lostpointercapture$et

する

不可

なし

上の表tにおける (1), (2) は：

(1) `既定~動作$が生じるのは，`首~pointer$に限られ、対応する`~mouse~event$に対するとき同様に，文脈に依存する — 文脈に応じて適切な既定~動作が行われることになる。

【とは言え、挙げられた`~mouse~event$のうち［ `mousemove$et, `mouseup$et ］は，既定~動作 “なし” として定義されている。】
(2) `pointerdown$et を取消した場合、この~eventの `pointerType$m 用の後続の`互換性~mouse~event$の発火も防止される。

◎ Event Type｜Bubbles｜Cancelable｜Default Action pointerover ｜Yes ｜Yes ｜None pointerenter ｜No ｜No ｜None pointerdown ｜Yes ｜Yes ｜Varies: when the pointer is primary, all default actions of the mousedown event Canceling this event also prevents subsequent firing of compatibility mouse events. pointermove ｜Yes ｜Yes ｜Varies: when the pointer is primary, all default actions of mousemove pointerrawupdate ｜Yes ｜No ｜None pointerup ｜Yes ｜Yes ｜Varies: when the pointer is primary, all default actions of mouseup pointercancel ｜Yes ｜No ｜None pointerout ｜Yes ｜Yes ｜None pointerleave ｜No ｜No ｜None gotpointercapture ｜Yes ｜No ｜None lostpointercapture ｜Yes ｜No ｜None

表示域の操作（~pan-zoom） — 一般に，`直な操作$の結果として生じる — は、意図的に，~pointer~eventの`既定~動作$にされていない — すなわち，これらの挙動（例：~touchscreen上で手指を動かした結果として，~pageを~panすること）は、 ~pointer~eventを取消しても抑止できない。作者は、代わりに `touch-action$p を利用して，文書の領域に対し `直な操作~用の挙動を明示的に宣言し＠#declaring-direct-manipulation-behavior$なければナラナイ。このようにしてあるのは、 ~eventの取消nに対する依存関係を除去して， ~UAによる処理能の最適化を手助けするためである。 ◎ Viewport manipulations (panning and zooming) — generally, as a result of a direct manipulation interaction — are intentionally NOT a default action of pointer events, meaning that these behaviors (e.g. panning a page as a result of moving a finger on a touchscreen) cannot be suppressed by canceling a pointer event. Authors must instead use touch-action to explicitly declare the direct manipulation behavior for a region of the document. Removing this dependency on the cancelation of events facilitates performance optimizations by the user agent.

上の表tに挙げた`~pointer~event$に対しては： ◎ ↓

その `composed$m 属性 `DOM$r は、［［ `pointerenter$et, `pointerleave$et ］においては ~F ／他においては ~T ］にされるべきである。 ◎ For pointerenter and pointerleave events, the composed [DOM] attribute SHOULD be false; for all other pointer events in the table above, the attribute SHOULD be true.
その `detail$m 属性 `UIEVENTS$r は 0 にされるべきである。 ◎ For all pointer events in the table above, the detail [UIEVENTS] attribute SHOULD be 0.

注記：多くの~UAは、旧来の内容を~supportするため， `MouseEvent$I 内に標準でない属性［ `fromElement^m, `toElement^m ］を公開している。それらの~UAには、［標準~化された代替-（すなわち， `target^m, `relatedTarget^m ）を利用するよう，作者に促す］ため，［ `PointerEvent$I 内の（継承された）それらの属性の値を ~NULL に設定する］ことが奨励される。 ◎ Note Many user agents expose non-standard attributes fromElement and toElement in MouseEvents to support legacy content. We encourage those user agents to set the values of those (inherited) attributes in PointerEvents to null to transition authors to the use of standardized alternates (i.e. target and relatedTarget).

`MouseEvent$I の `relatedTarget$m と類似に、 `relatedTarget^m は，［ `pointerover$et ／ `pointerenter$et ］~event用には直前の`捕捉~込みの~pointing先$, ［ `pointerout$et ／ `pointerleave$et ］~event用には新たな`捕捉~込みの~pointing先$ に初期化されるべきである。他の~pointer~event用には、この値は既定で~NULLになる。 ◎ Similar to MouseEvent relatedTarget, the relatedTarget should be initialized to the element whose bounds the pointer just left (in the case of a pointerover or pointerenter event) or the element whose bounds the pointer is entering (in the case of a pointerout or pointerleave). For other pointer events, this value will default to null. Note that when an element receives the pointer capture all the following events for that pointer are considered to be inside the boundary of the capturing element.

［ `gotpointercapture$et ／ `lostpointercapture$et ］~event用には、上の表tに定義されるものを除くすべての属性は，［ ~UAに`処理待ち~pointer捕捉を処理-＠#process-pending-pointer-capture$させ, その~event発火させた`~pointer~event$ ］のそれらと同じにされるべきである。 ◎ For gotpointercapture and lostpointercapture events, all the attributes except the ones defined in the table above should be the same as the Pointer Event that caused the user agent to run the process pending pointer capture steps and fire the gotpointercapture and lostpointercapture events.

4.1.3.2. 処理待ち~pointer捕捉の処理-法

`~pointer捕捉を暗黙的に解放する$とき, および［ `gotpointercapture$et, `lostpointercapture$et ］以外の`~pointer~eventを発火する$ときは、 `処理待ち~pointer捕捉を処理する@ モノトスル — それは、所与の ( `作動中な~pointer$ %~pointer ) に対し，次の手続きを走らす：

%旧-~target ~LET %~pointer の`捕捉~target$
%新-~target ~LET %~pointer の`処理待ち捕捉~target$
%~pointer の`捕捉~target$ ~SET %新-~target
~IF［ %旧-~target ~EQ %新-~target ］ ⇒ ~RET
~IF［ %旧-~target ~NEQ ~NULL ］ ⇒ %旧-~target に向けて名前 `lostpointercapture$et の`~pointer~eventを発火する$
~IF［ %新-~target ~NEQ ~NULL ］ ⇒ %新-~target に向けて名前 `gotpointercapture$et の`~pointer~eventを発火する$

注記： § `click^et ／ `auxclick^et ／ `contextmenu^et ~event にて定義されるとおり、 `lostpointercapture$et ~eventを配送した後であっても，［対応している［ `click$et ／ `auxclick$et ／ `contextmenu$et ］~eventがある場合、それらを`捕捉している~target$に向けて配送される］ことになる。 ◎ Note As defined in the section for click, auxclick, and contextmenu events, even after the lostpointercapture event has been dispatched, the corresponding click, auxclick or contextmenu event, if any, would still be dispatched to the capturing target.

4.1.3.3. ~pointer~event~streamの抑止-法

~UAは、 `~pointer~event~streamを抑止する局面$を検出したときは， `~pointer~event~streamを抑止する$モノトスル。 `~pointer~event~streamを抑止する局面@ とは、 ~UAが［当の~pointerは、それ以上~eventを生産し続ける見込みは低い］とみなす局面である — 次に挙げる局面は、これに含まれるとする（他にも追加的な局面があってもヨイ）： ◎ The user agent MUST suppress a pointer event stream when it detects that a pointer is unlikely to continue to produce events. Any of the following scenarios satisfy this condition (there MAY be additional scenarios):

~UAが［ ~modal~dialog／~menu ］を開いたとき。 ◎ The user agent has opened a modal dialog or menu.
~pointer入力~装置が物理的に切断されたとき。 ◎ A pointer input device is physically disconnected,＼
~hover可能な~pointer入力~装置（例：~penや~stylus）が， `~digitizer$により検出-可能な~hover範囲から出たとき。 ◎ or a hoverable pointer input device (e.g. a hoverable pen/stylus) has left the hover range detectable by the digitizer.
当の~pointerは、引き続き，~UAが~page表示域を操作する（例： ~pan-zoom）ために利用されたとき。詳細は、 § `touch-action$p ~propを見よ。 ◎ The pointer is subsequently used by the user agent to manipulate the page viewport (e.g. panning or zooming). See the section on touch-action CSS property for details.

注記： ~UAは，［ ~pan／~zoom ］動作を複数の`~pointer型$（~touchや~penなど）を通して誘発し得るので、その動作を開始した結果，同じ~pointer型に限らず様々な~pointerが抑止されることもある。 ◎ Note User agents can trigger panning or zooming through multiple pointer types (such as touch and pen), and therefore the start of a pan or zoom action may result in the suppression of various pointers, including pointers with different pointer types.
当の~pointerは、 `HTML$r `§ ~drag＆~drop処理~model＠~HTMLdnd#drag-and-drop-processing-model$ にて定義されるとおり — `~drag操作oの起動~algo＠~HTMLdnd#initiate-the-drag-and-drop-operation$の一部として — ~drag操作oを生じさせたとき。 ◎ As part of the drag operation initiation algorithm as defined in the drag and drop processing model [HTML], for the pointer that caused the drag operation.

注記： `~pointer~event~streamを抑止する局面$には、他にも，次が含まれ得る： ◎ Note Other scenarios in which the user agent MAY suppress a pointer event stream include:

~pointerが`作動中$な間に，装置の~screen方位が変化したとき。 ◎ A device's screen orientation is changed while a pointer is active.
利用者が、装置が~supportするより多い~pointer入力を同時に利用してヤリトリしようと試みたとき。 ◎ The user attempts to interact using more simultaneous pointer inputs than the device supports.
~UAが、入力を不意なものと解釈したとき（例えば、 `palm rejection^en 【 “手のひらは~~無視する” 】を~supportする~hardware）。 ◎ The user agent interprets the input as accidental (for example, the hardware supports palm rejection).

これらの局面を検出する手法は、この仕様の視野から外れる。 ◎ Methods for detecting any of these scenarios are out of scope for this specification.

`~pointer~event~streamを抑止する@ ~algoは： ◎ The user agent MUST run the following steps to suppress a pointer event stream:

名前 `pointercancel$et の`~pointer~eventを発火する$ ◎ Fire a pointercancel event.
名前 `pointerout$et の`~pointer~eventを発火する$ ◎ Fire a pointerout event.
名前 `pointerleave$et の`~pointer~eventを発火する$ ◎ Fire a pointerleave event.
~IF［当の~pointer %~pointer は現在`捕捉-$されている］ ⇒ `~pointer捕捉を暗黙的に解放する$( %~pointer ) ◎ Implicitly release the pointer capture if the pointer is currently captured.

4.1.4 ~layout変化

~pointing装置が静止中（ `stationary^en ）であるとは、［当の装置が~screenの物理面に相対的に移動していない］かつ［ ~screenの各~prop【（~displayにおける）その方位や位置など】に何ら変化は生じていない］ことをいう。 ~pointing装置は、静止中でない間は， `§ 各種 ~pointer~event型＠#pointer-event-types$ にて定義されるとおりに`~pointer~event$を発火する。静止中であっても，~layoutが変化したときは、 `~pointing先$に影響する結果，`境界~event$を発火させ得る【！モノトスル】。 ~UAは、処理能の理由があるときは，これら`境界~event$の発火を遅延してもヨイ（例：境界~event用の~event~handler【！~listener】により生じる［接触判定／~layout変化］†が多過ぎになることを避けるため）。 ◎ A pointing device that moved relative to the screen surface or underwent some change in any of its properties fires various events as defined in Pointer Event types. For a stationary pointing device (that neither moved relative to the screen surface nor underwent any change in any properties), the user agent MUST fire certain boundary events after a layout change that affected the hit test target for the pointer, see pointerover, pointerenter, pointerout and pointerleave for details. The user agent MAY delay the firing of these boundary events because of performance reasons (e.g. to avoid too many hit-tests or layout changes caused by boundary event listeners).

【† 例えば，~event~handlerが~pageの~styleを変更することにより。したがって， “遅延する”とは、 `~event~loop$の各~反復におけるそのような発火の回数を抑制することを意味する。】

注記：静止中な~pointing装置は、 `pointermove$et ~eventを決して発火しない。 ◎ Note A stationary pointing device (that neither moved relative to the screen surface nor underwent any change in any properties) never fires a pointermove event.

4.1.5. ［ `tiltX^m, `tiltY^m ］と［ `altitudeAngle^m, `azimuthAngle^m ］の間の変換-法

`~pointer~event$は、 ~transducerに相対的な~X-Z平面の方位を表出するためとして， 2 つの相補的な属性~組を含む： ◎ Pointer Events include two complementary sets of attributes to express the orientation of a transducer relative to the X-Y plane:＼

(T)： `tiltX$m, `tiltY$m （元の Pointer Events 仕様にて導入された） ◎ tiltX / tiltY (introduced in the original Pointer Events specification), and＼
(A)： `altitudeAngle$m, `azimuthAngle$m （ `Touch Events, ~level 2＠~TOUCHEVENTS$cite 仕様から採用された） ◎ azimuthAngle / altitudeAngle (adopted from the Touch Events - Level 2 specification).

特定の［ ~hardware, ~platform ］に依存して、 ~UAは，~transducer方位に相対的な~screen平面~用の値として［上の属性~組 (T), (A) ］のうち片方しか受取らない見込みが高い。 ~UAは，これらの値を変換するときは、以下の~algo【 `6$ex 】を利用するモノトスル。 ◎ Depending on the specific hardware and platform, user agents will likely only receive one set of values for the transducer orientation relative to the screen plane — either tiltX / tiltY or altitudeAngle / azimuthAngle. User agents MUST use the following algorithm for converting these values.

~UAは，上の (A) から (T) を計算するときは、 `Math.round$c の規則 `ECMASCRIPT$r を利用して，整数~値を最終的に丸めるベキである。 ◎ When the user agent calculates tiltX / tiltY from azimuthAngle / altitudeAngle it SHOULD round the final integer values using Math.round [ECMASCRIPT] rules.

`6@ex：［ `tiltX$m ／ `tiltY$m ］と［ `azimuthAngle$m ／ `altitudeAngle$m ］の間の変換-法： ◎ Example 6: Converting between tiltX/tiltY and altitudeAngle/azimuthAngle ◎ /* Converting between tiltX/tiltY and altitudeAngle/azimuthAngle */

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.

4.2.1. `pointerover@et ~event

~UAは、所与の要素 %要素に関して［ ~pointerの`捕捉~込みの~pointing先$が %要素以外から %要素になった］ことを検出したときは，当の要素に向けて名前 `pointerover$et の`~pointer~eventを発火する$モノトスル。

この~eventは、入力~装置が`~hoverを~supportしない$場合でも， `pointerdown$et ~eventを発火する前に発火されることになる（ `pointerdown$et を見よ）。

◎ The user agent MUST fire a pointer event named pointerover when any of the following occurs: • The step to determine the target of a pointer detects that the pointer has moved into an element. • A layout change causes the hit test boundaries of an element to move underneath an uncaptured pointer of a stationary pointing device. • Before the user agent fires a pointerdown event for a device that does not support hover (see pointerdown).

4.2.2. `pointerenter@et ~event

~UAは、所与の要素 %要素に関して［ ~pointerの`捕捉~込みの~pointing先$が %要素の`広義-子孫$以外からそれらいずれかになった］ことを検出したときは，当の要素に向けて名前 `pointerover$et の`~pointer~eventを発火する$モノトスル。

【したがって、 `捕捉~込みの~pointing先$が変化したとき， ~AND↓ を満たす`各^em 要素に向けて発火されることになる：

新たな~pointing先の`広義-先祖$である（新たな~pointing先 ~EQ ~NULL の場合は無条件）。
以前の~pointing先の`広義-先祖$でない（以前の~pointing先 ~EQ ~NULL の場合は無条件）。

該当する要素が複数~在る場合、（ `mouseenter$et のときと同様に）最も先祖のものから順に，この~eventを発火することになろう。】

この~eventは、入力~装置が`~hoverを~supportしない$場合でも， `pointerdown$et ~eventを発火する前に発火されることになる（ `pointerdown$et を見よ）。

◎ The user agent MUST fire a pointer event named pointerenter when any of the following occurs: • The step to determine the target of a pointer detects that the pointer has moved into an element or one of its descendants. • A layout change causes the hit test boundaries of an element or one of its descendants to move underneath an uncaptured pointer of a stationary pointing device. • Before the user agent fires a pointerdown event for a device that does not support hover (see pointerdown).

注記： `pointerenter$et は、 `pointerover$et に類似するが，次において相違する ⇒＃浮上しない。その配送には子孫~要素の`接触判定$境界も考慮される。 ◎ Note This event type is similar to pointerover but with two differences: pointerenter does not bubble, and its dispatch considers the hit test boundaries of even descendant elements.

注記：［この型の~event , `mouseenter$et ~event `UIEVENTS$r , ~CSS~hover_ps 疑似類 `CSS21$r ］の間には類似性がある。 `pointerleave$et ~eventも見よ。 ◎ Note There are similarities between this event type, the mouseenter event described in [UIEVENTS], and the CSS :hover pseudo-class described in [CSS21]. See also the pointerleave event.

4.2.3. `pointerdown@et ~event

［ ~pointerの~buttonが非`作動~状態$から`作動~状態$へ遷移した］とき，`~pointing先$が要素である（ ~NULL でない）ならば、その要素に向けて名前 `pointerdown$et の`~pointer~eventを発火する$モノトスル。【この段落の他の内容は，作動~状態の定義に移譲。】 ◎ The user agent MUST fire a pointer event named pointerdown when a pointer enters the active buttons state. For mouse, this is when the device transitions from no buttons depressed to at least one button depressed. For touch, this is when physical contact is made with the digitizer. For pen, this is when the pen either makes physical contact with the digitizer without any button depressed, or transitions from no buttons depressed to at least one button depressed while hovering.

注記： ~mouse（または他の複-~button~pointer装置）に対しては、このことは，［［ `mousedown$et ／ `mouseup$et ］が発火されるときと同じ状況下で，常に［ `pointerdown$et ／ `pointerup$et ］が発火されるとは限らない］ことを意味する。 `~buttonの追加押下げ$を見よ。 ◎ Note For mouse (or other multi-button pointer devices), this means pointerdown and pointerup are not fired for all of the same circumstances as mousedown and mouseup. See chorded buttons for more information.

入力~装置が`~hoverを~supportしない$場合には、 `pointerdown$et ~eventを配送するより先に，順に，名前［ `pointerover$et, `pointerenter$et ］の`~pointer~eventを発火する$モノトスル。 ◎ For input devices that do not support hover, the user agent MUST also fire a pointer event named pointerover followed by a pointer event named pointerenter prior to dispatching the pointerdown event.

【 ~hoverを~supportする装置の~pointerが［ ~UIwindow外から瞬時に移動してきて，一瞬だけ静止した後、作動~状態に遷移した］ときの挙動と同様になる。】

注記：作者は、 `pointerdown$et ~eventを取消して（その `isPrimary$m 属性が ~T ならば），ある種の`互換性~mouse~event$の発火を防止できる。これは、 ~pointerの`~mouse~eventは防止するか$を ~T にする。ただし、［ `mouseover$et ／ `mouseenter$et ／ `mouseout$et ／ `mouseleave$et ］~eventの発火は防止されないことに注意。 ◎ Note Authors can prevent the firing of certain compatibility mouse events by canceling the pointerdown event (if the isPrimary property is true). This sets the PREVENT MOUSE EVENT flag on the pointer. Note, however, that this does not prevent the mouseover, mouseenter, mouseout, or mouseleave events from firing.

4.2.4. `pointermove@et ~event

~pointerの~propのうち［ `pointerdown$et ／ `pointerup$et ］~eventを発火しないものが変化したときは、その`~pointing先$に向けて名前 `pointermove$et の`~pointer~eventを発火する$モノトスル。 ◎ The user agent MUST fire a pointer event named pointermove when a pointer changes any properties that don't fire pointerdown or pointerup events.＼

該当する~propには、次に挙げるものが含まれる ⇒＃座標／押圧／接線方向~圧／傾き／ ~twist／ `接触~幾何$（例： `width$m, `height$m ）／ `~buttonの追加押下げ$ ◎ This includes any changes to coordinates, pressure, tangential pressure, tilt, twist, contact geometry (i.e. width and height) or chorded buttons.

~UAは、 `pointermove^et ~eventの配送を遅延してもヨイ（一例として，処理能の理由で）。 `合体された~event群$の情報は、それ用に配送される 1 個の `pointermove$et ~event内に， `getCoalescedEvents()$m ~methodを介して公開されることになる。 ~UAは、この~eventの~targetを合体された~event群の最終-座標を利用して見出すベキである。 ◎ User agents MAY delay dispatch of the pointermove event (for instance, for performance reasons). The coalesced events information will be exposed via the getCoalescedEvents() method for the single dispatched pointermove event. The final coordinates of such events should be used for finding the target of the event.

4.2.5. `pointerrawupdate@et ~event

~pointerの~propのうち［ `pointerdown$et ／ `pointerup$et ］~eventを発火しないものが変化したときには（該当する~propについては、 `pointermove$et を見よ）、 `~secureな文脈$enVの中に限り，名前 `pointerrawupdate$et の`~pointer~eventを発火する$モノトスル： ◎ The user agent MUST fire a pointer event named pointerrawupdate, and only do so within a secure context, when a pointer changes any properties that don't fire pointerdown or pointerup events. See pointermove event for a list of such properties.

~UAは、 `pointerrawupdate$et ~eventを［アリな限り早く, ~JSが~eventを取扱える限りの頻度］で配送するベキである — `pointermove$et とは対照的に。 ◎ In contrast with pointermove, user agents SHOULD dispatch pointerrawupdate events as soon as possible and as frequently as the JavaScript can handle the events.
`pointerrawupdate$et ~eventの `target$m は、 `pointermove$et ~eventのそれとは異なるかもしれない — 後者は、遅延されたり合体され得るので。また， `target^m を見出すために利用される最終-位置は、合体された各~eventとは異なり得る。 ◎ The target of pointerrawupdate events might be different from the pointermove events due to the fact that pointermove events might get delayed or coalesced, and the final position of the event which is used for finding the target could be different from its coalesced events.
`~event~loop$内に［同じ `pointerId$m を伴う別の `pointerrawupdate$et ~event ］を配送する`~task$がまだある場合、 ~UAは — 新たな`~task$を作成する代わりに — その~eventに新たな `pointerrawupdate$et を合体してもヨイことに注意。よって，それらの~eventは、 `~event~loop$内で処理される時点で［ 1 個の `pointerrawupdate$et ~eventに`合体された~event群$ ］として送達され得ることになる。さらなる情報は `getCoalescedEvents()$m を見よ。 ◎ Note that if there is already another pointerrawupdate with the same pointerId that hasn't been dispatched in the event loop, the user agent MAY coalesce the new pointerrawupdate with that event instead of creating a new task. This may cause pointerrawupdate to have coalesced events, and they will all be delivered as coalesced events of one pointerrawupdate event as soon as the event is processed in the event loop. See getCoalescedEvents() for more information.
【！In terms of ordering of ...】 ~platformから［ `pointerrawupdate$et, `pointermove$et ］両~eventを生じさせるような更新を受取った場合には、 ~UAは， `pointerrawupdate$et ~eventから先に配送するモノトスル。 ◎ In terms of ordering of pointerrawupdate and pointermove, if the user agent received an update from the platform that causes both pointerrawupdate and pointermove events, then the user agent MUST dispatch the pointerrawupdate event before the corresponding pointermove.
`target$m 以外の~event属性については、［最後の `pointermove$et ~event以降に配送されたすべての `pointerrawupdate$et ~event ］が成す合体d~event~listたちが成す連結（ `concatenation^en ）【意図不明】は、次回の `pointermove$et ~eventの合体d~eventたちと同じになる。 ◎ Other than the target, the concatenation of coalesced events lists of all dispatched pointerrawupdate events since the last pointermove event is the same as the coalesced events of the next pointermove event in terms of the other event attributes.＼
`pointerrawupdate$et の各種~属性のほとんどは、 `pointermove$et のそれらと同じになる — 例外として， `pointerrawupdate$et 用には、 `cancelable$m は ~F にするモノトスル。 ◎ The attributes of pointerrawupdate are mostly the same as pointermove, with the exception of cancelable which MUST be false for pointerrawupdate.
~UAは、 `pointerrawupdate$et 用には，`互換性~mouse~event$を発火しないベキである。 ◎ User agents SHOULD not fire compatibility mouse events for pointerrawupdate.

注記： `pointerrawupdate$et ~event用の~listenerを追加すると、 ~UAの実装によっては，~web~pageの処理能に悪影響を及ぼすかもしれない。ほとんどの利用事例では、他の型の~pointer~eventで足るはずである。そのような~listenerは、 ~scriptが［高頻度な~eventが必要で，それだけ速くそれらを取扱える場合］に限り，追加されるベキである。これらの事例では、他の型の~pointer~eventを~listenする必要はおそらく無い。 ◎ Note Adding listeners for the pointerrawupdate event might negatively impact the performance of the web page, depending on the implementation of the user agent. For most use cases the other pointerevent types should suffice. A pointerrawupdate listener should only be added if JavaScript needs high frequency events and can handle them just as fast. In these cases, there is probably no need to listen to other types of pointer events.

4.2.6. `pointerup@et ~event

~pointerの~buttonが`作動~状態$から非`作動~状態$へ遷移したときは、その`~pointing先$に向けて名前 `pointerup$et の`~pointer~eventを発火する$モノトスル。【この段落の他の内容は，作動~状態の定義に移譲。】 ◎ The user agent MUST fire a pointer event named pointerup when a pointer leaves the active buttons state. For mouse, this is when the device transitions from at least one button depressed to no buttons depressed. For touch, this is when physical contact is removed from the digitizer. For pen, this is when the pen is removed from the physical contact with the digitizer while no button is depressed, or transitions from at least one button depressed to no buttons depressed while hovering.

入力~装置が`~hoverを~supportしない$場合には、 `pointerup$et ~eventを配送した後に，［順に，名前 `pointerout$et, `pointerleave$et の`~pointer~eventを発火する$ ］モノトスル。 ◎ For input devices that do not support hover, the user agent MUST also fire a pointer event named pointerout followed by a pointer event named pointerleave after dispatching the pointerup event.

【 ~hoverを~supportする装置の~pointerが［非~作動~状態に遷移してから、一瞬だけ静止した後，瞬時に~UIwindow外へ移動した］ときの挙動と同様になる。】

どの `pointerup$et ~eventにおいても、 `pressure$m の値は 0 になる。 ◎ All pointerup events have a pressure value of 0.

~UAは，また、当の~pointerが現在`捕捉-$されている場合には， `~pointer捕捉を暗黙的に解放する$モノトスル。 ◎ The user agent MUST also implicitly release the pointer capture if the pointer is currently captured.

4.2.7. `pointercancel@et ~event

`~pointer~event~streamを抑止する局面$を検出したときは、名前 `pointercancel$et の`~pointer~eventを発火する$モノトスル： ◎ The user agent MUST fire a pointer event named pointercancel when it detects a scenario to suppress a pointer event stream.

`pointercancel$et ~eventは、次に従うモノトスル： ◎ ↓

次に挙げる~propは、［その取消nに先行して配送された~pointer~event ］のうち［同じ `pointerId$m を伴うもの］のうち［最後のもの］と同じ値をとる ⇒＃ `width$m, `height$m, `pressure$m, `tangentialPressure$m, `tiltX$m, `tiltY$m, `twist$m, `altitudeAngle$m, `azimuthAngle$m, `pointerType$m, `isPrimary$m, `UIEVENTS$r から継承した各~座標 ◎ The values of the following properties of the pointercancel event MUST match the values of the last dispatched pointer event with the same pointerId: width, height, pressure, tangentialPressure, tiltX, tiltY, twist, altitudeAngle, azimuthAngle, pointerType, isPrimary, and the coordinates inherited from [UIEVENTS].＼
［ `合体d~event~list$, `予測d~event~list$ 【！the coalescedEvents and predictedEvents lists】］は空。 ◎ The coalescedEvents and predictedEvents lists in the pointercancel event MUST be empty,＼
`cancelable$m 属性は ~F をとる。 ◎ and the event's cancelable attribute MUST be false.

4.2.8. `pointerout@et ~event

~UAは、所与の要素 %要素に関して，次に挙げるいずれかが生じたときは、 %要素に向けて名前 `pointerout$et の`~pointer~eventを発火する$モノトスル：

~pointerの`捕捉~込みの~pointing先$が %要素から %要素以外になったことを検出したとき。
【 %要素に向けて `pointerover$et ~eventを発火した後，】 `~pointer~event~streamを抑止する局面$を検出したとき。

この~eventは、入力~装置が`~hoverを~supportしない$場合でも， `pointerup$et ~eventを発火した後に発火されることになる（ `pointerup$et を見よ）。

◎ The user agent MUST fire a pointer event named pointerout when any of the following occurs: • The step to determine the target of a pointer detects that the pointer has moved out of an element. • A layout change causes the hit test boundaries of an element to move away from underneath an uncaptured pointer of a stationary pointing device. • After the user agent fires a pointerup event for a device that does not support hover (see pointerup). • The user agent has detected a scenario to suppress a pointer event stream.

4.2.9. `pointerleave@et ~event

~UAは、所与の要素 %要素に関して，次に挙げるいずれかが生じたときは、 %要素に向けて名前 `pointerleave$et の`~pointer~eventを発火する$モノトスル：

~pointerの`捕捉~込みの~pointing先$が %要素の`広義-子孫$からそれら以外になったことを検出したとき。
【したがって、 `捕捉~込みの~pointing先$が変化したとき， ~AND↓ を満たす`各^em 要素に向けて発火されることになる：
- 以前の~pointing先の`広義-先祖$である（以前の~pointing先 ~EQ ~NULL の場合は無条件）
- 新たな~pointing先の`広義-先祖$でない（新たな~pointing先 ~EQ ~NULL の場合は無条件）
該当する要素が複数~在る場合（例：新たな~pointing先が存在しない場合、（ `pointerenter$et のときとは逆順に）最も子孫のものから順に，この~eventを発火することになろう。】
【 %要素に向けて `pointerenter$et ~eventを発火した後，】 `~pointer~event~streamを抑止する局面$を検出したとき。

この~eventは、入力~装置が`~hoverを~supportしない$場合でも， `pointerup$et ~eventを発火した後に発火されることになる（ `pointerup$et を見よ）。

◎ The step to determine the target of a pointer detects that the pointer has moved out of an element and all of its descendants. ◎ The user agent MUST fire a pointer event named pointerleave when any of the following occurs: • A layout change causes the hit test boundaries of an element and all of its descendants to move away from underneath an uncaptured pointer of a stationary pointing device. • After the user agent fires the pointerup event for a device that does not support hover (see pointerup). • The user agent has detected a scenario to suppress a pointer event stream.

注記： `pointerleave$et は、 `pointerout$et に類似するが，次において相違する ⇒＃浮上しない。その配送には子孫~要素の`接触判定$境界も考慮される。 ◎ Note This event type is similar to pointerout but with two differences: pointerleave does not bubble, and its dispatch considers the hit test boundaries of even descendant elements.

注記：［この型の~event, `mouseleave$et ~event `UIEVENTS$r, ~CSS~hover_ps 疑似類 `CSS21$r ］の間には類似性がある。 `pointerenter$et ~eventも見よ。 ◎ Note There are similarities between this event type, the mouseleave event described in [UIEVENTS], and the CSS :hover pseudo-class described in [CSS21]. See also the pointerenter event.

4.2.10. `gotpointercapture@et ~event

~pointerが要素に`捕捉-$されたときは、その要素に向けて名前 `gotpointercapture$et の`~pointer~eventを発火する$モノトスル。その~pointer用の後続な~eventは、この要素に向けて発火されることになる。［ `§ ~pointer捕捉の設定-法＠#setting-pointer-capture$ ／ `§ 処理待ち~pointer捕捉の処理-法＠#process-pending-pointer-capture$ ］を見よ。 ◎ The user agent MUST fire a pointer event named gotpointercapture when an element receives pointer capture. This event is fired at the element that is receiving pointer capture. Subsequent events for that pointer will be fired at this element. See the setting pointer capture and process pending pointer capture sections.

4.2.11. `lostpointercapture@et ~event

要素による`~pointer捕捉$が解放されたときは、その要素に向けて名前 `lostpointercapture$et の`~pointer~eventを発火する$モノトスル。この~eventは、 ~pointerが捕捉から解放された後に生じるどの~eventよりも先に発火するモノトスル。 ~pointerによる後続な~eventのうち［ `click$et, `auxclick$et, `contextmenu$et ］~eventを除くすべてにおいて、その~targetは，通常の`~pointing先$になる。［ `§ ~pointer捕捉の解放-法＠#releasing-pointer-capture$ ／ `§ ~pointer捕捉の暗黙的な解放-法＠#implicit-release-of-pointer-capture$ ／ `§ 処理待ち~pointer捕捉の処理-法＠#process-pending-pointer-capture$ ］を見よ。 ◎ The user agent MUST fire a pointer event named lostpointercapture after pointer capture is released for a pointer. This event MUST be fired prior to any subsequent events for the pointer after capture was released. This event is fired at the element from which pointer capture was removed. All subsequent events for the pointer except click, auxclick, and contextmenu events follow normal hit testing mechanisms (out of scope for this specification) for determining the event target. See the releasing pointer capture, implicit release of pointer capture, and process pending pointer capture sections.

4.2.12. `click^et ／ `auxclick^et ／ `contextmenu^et ~event

この節は、 `UIEVENTS$r にて定義される［ `click$et, `auxclick$et, `contextmenu$et ］~eventに対する追加である。これらの~eventは、概して~UIの作動化に束ねられており， ~pointerでない入力~装置（~keyboardなど）からも発火されるので。 ◎ This section is an addition to click, auxclick and contextmenu events defined in [UIEVENTS]. These events are typically tied to user interface activation, and are fired even from non-pointer input devices, such as keyboards.

これらの~eventは、 `PointerEvent$I になるモノトスル — 加えて、この節を成す以降に言及される追加的な要件の~subjectになる。 ◎ These events MUST be of type PointerEvent, and are subject to the additional requirements mentioned in the rest of this section.

4.2.12.1. ~event属性

これらの~event用の `PointerEvent$I に特有な属性（この仕様にて定義されるもの）は、次を除き，既定の値をとるモノトスル ⇒ ［ `pointerId$m ／ `pointerType$m ］属性は、当の~eventを生成させたものに応じて ⇒＃ ~pointing装置ならば，当の~eventを生じさせた`~pointer~event$と同じになるモノトスル／他の装置（~voice認識~softwareや~keyboardとのヤリトリなど）ならば，［ −1 ／空~文字列］になるモノトスル ◎ For these events, all PointerEvent specific attributes (defined in this spec) other than pointerId and pointerType MUST have their default values. In addition: • If the events are generated by a pointing device, their pointerId and pointerType MUST be the same as the PointerEvents that caused these events. • If the events are generated by a non-pointing device (such as voice recognition software or a keyboard interaction), pointerId MUST be -1 and pointerType MUST be an empty string.

4.2.12.2. ~event座標

`CSSOM-VIEW$r は、 § `PointerEvent^I にて注記したとおり，各種~座標~prop （ `screenX^m, `screenY^m, `pageX^m, `pageY^m, `clientX^m, `clientY^m, `x^m, `y^m, `offsetX^m, `offsetY^m ）の型を — 小数付きな座標を許容するため — `double^c として定義し直すよう提案する。しかしながら、この変更が［定例の `MouseEvent$I ではない `PointerEvent$I に限って適用される］と，［ `click$et ／ `auxclick$et ／`contextmenu$et ］の事例で［旧来の~codeとの~web互換性の課題に至る］ことが立証された。この理由から、 `CSSOM-VIEW$r にて提案された変更を `PointerEvent$I に限って実装した~UAは，［ `click$et ／ `auxclick$et ／ `contextmenu$et ］用の各種~座標~propを `Math.floor$c `ECMASCRIPT$r を利用して（元の `UIEVENTS$r にて定義されたとおりに） `long^c 値に変換するモノトスル。 ◎ As noted in PointerEvent, CSSOM View Module proposes to redefine the various coordinate properties (screenX, screenY, pageX, pageY, clientX, clientY, x, y, offsetX, offsetY) as double, to allow for fractional coordinates. However, this change — when applied only to PointerEvent, but not to regular MouseEvent — has proven to lead to web compatibility issues with legacy code in the case of click, auxclick, and contextmenu. For this reason, user agents that have implemented the proposed change in CSSOM View Module only for PointerEvent MUST convert the various coordinate properties for the click, auxclick, and contextmenu to long values (as defined in the original UI Events) using Math.floor [ECMASCRIPT].

4.2.12.3. ~event配送

［ `click$et ／ `auxclick$et ／ `contextmenu$et ］~event %~event は、 `UIEVENTS$r にて定義される配送~処理nに従うモノトスル — ただし、 %~event の`~target$は，次の~algoの結果に上書きするモノトスル： ◎ A click, auxclick or contextmenu event MUST follow the dispatch process defined in the [UIEVENTS] spec except that the event target is overridden using the algorithm below:

%利用者~event ~LET %~event を発火させた利用者ヤリトリ~event 【 %~event に先行して（直前に） %~event と同期的に発火された~event】 ◎ Let event be the click, auxclick or contextmenu event being dispatched, and userEvent be the user interaction event that caused the firing of event.
注記： %利用者~event は、 `PointerEvent$I でない場合もある — 例えば， `click$et ~eventが~checkboxに対し~space~barを叩いて生じたときは、 `KeyboardEvent$I になる。 ◎ Note Event userEvent could be a non-PointerEvent; for example, it is a KeyboardEvent when a click event dispatch is caused by hitting the spacebar on a checkbox element.

%利用者~event が `PointerEvent$I である場合、 %利用者~event は %~event に応じて： ◎ When userEvent is a PointerEvent,＼
- ［ `click$et ／ `auxclick$et ］~eventであるならば `pointerup$et になる。 ◎ userEvent is a pointerup for a click or auxclick event,＼
- `contextmenu$et ~eventであるならば［ `pointerdown$et ／ `pointerup$et ］~eventいずれかになる（どちらになるかは、 ~native~platformの規約に依存する）。 ◎ and either a pointerdown or a pointerup event (depending on native platform convention) for a contextmenu event.
~IF［ ~OR↓ ］…
- %利用者~event は `PointerEvent$I でない
- %~event は `contextmenu$et ~eventである
- %利用者~event はそれに対応する~pointerが捕捉されている間に配送された
…ならば ⇒ ~RET %~event の`~target$ （すなわち、~targetを上書きしない）
◎ If userEvent is not a PointerEvent,＼ ↑↑ dispatch event following the [UIEVENTS] spec without overriding event target and＼ skip the remaining steps below. ◎ Define target as follows: ◎ If event is a contextmenu event, or userEvent was dispatched while the corresponding pointer was captured, then let target be the target of userEvent.
~Assert：［ %~event は［ `click$et ／ `auxclick$et ］~eventである］~AND［ %利用者~event は `pointerup$et ~eventである］ ◎ Otherwise (event is a click or auxclick event for which userEvent is a pointerup event that was dispatched uncaptured)＼
~RET %~event が配送される時点における［ %利用者~event に対応する `pointerdown$et の`~target$, %利用者~event の`~target$ ］に`共通な広義-先祖$ ◎ let target be the nearest common inclusive ancestor of the corresponding pointerdown and pointerup targets in the DOM at the moment event is being dispatched. ◎ ↑↑ Dispatch event to target following the [UIEVENTS] spec.

注記： %利用者~event が捕捉されていた場合、同じ `pointerId$m を伴う `lostpointercapture$et ~eventがすでに配送された場合でも， %~event は %利用者~event を`捕捉している~target$へ配送される。 ◎ Note If userEvent was captured, event is dispatched to the capturing target of userEvent even though the lostpointercapture event with the same pointerId has been dispatched already.

5. `Element^I ~interfaceに対する拡張

以下の各~節では、既存の `Element$I ~interfaceに対する — ~scriptが~pointer捕捉を［設定する／解放する］ことを手助けするための — 拡張を述べる。 ◎ The following section describes extensions to the existing Element interface to facilitate the setting and releasing of pointer capture.

partial interface `Element$I {
    `undefined$ `setPointerCapture$m(`long$ %pointerId);
    `undefined$ `releasePointerCapture$m(`long$ %pointerId);
    `boolean$ `hasPointerCapture$m(`long$ %pointerId);
};

`setPointerCapture(pointerId)@m: コレが［ %pointerId により識別される~pointer ］を`捕捉-$するよう設定する — `§ ~pointer捕捉の設定-法＠#setting-pointer-capture$を見よ。この~pointerにより生じる後続な~eventに対しては、通常の接触判定の結果は — 当の~pointerが，常にそれを捕捉している~target（コレ）に重なっているかのように — コレで代用されることになる — この捕捉が解放されるまでは、常にコレを~targetにするモノトスル。 ◎ Set pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked.＼ For subsequent events of the pointer, the capturing target will substitute the normal hit testing result as if the pointer is always over the capturing target, and they MUST always be targeted at this element until capture is released.＼; この~methodが有効果であるのは、 ~pointerの~buttonが`作動~状態$にあるときに限られる — そうでないときは、何もしないモノトスル。 ◎ The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently.＼; %pointerId が`作動中$などの~pointerにも合致しない場合、 `NotFoundError$E 例外が投出される。 ◎ When the provided method's argument does not match any of the active pointers, throw a "NotFoundError" DOMException.
`releasePointerCapture(pointerId)@m: コレが`捕捉-$している［ %pointerId により識別される~pointer ］を明示的に解放する — `§ ~pointer捕捉の解放-法＠#releasing-pointer-capture$を見よ。すなわち，~pointerにより生じる後続な~eventにおける~targetは、通常の`~pointing先$になる。 ◎ Releases pointer capture for the pointer identified by the argument pointerId from the element on which this method is invoked.＼ Subsequent events for the pointer follow normal hit testing mechanisms (out of scope for this specification) for determining the event target.＼; %pointerId が`作動中$などの~pointerにも合致しない場合、 `NotFoundError$E 例外が投出される。 ◎ When the provided method's argument does not match any of the active pointers, throw a "NotFoundError" DOMException.
`hasPointerCapture(pointerId)@m: コレが［ %pointerId により識別される~pointer ］を`捕捉-$しているかどうかを指示する。すなわち、［ %pointerId 用の`処理待ち捕捉~target$ ~EQ コレならば ~T ／ ~ELSE_ ~F ］を返す。 ◎ Indicates whether the element on which this method is invoked has pointer capture for the pointer identified by the argument pointerId. In particular, returns true if the pending pointer capture target override for pointerId is set to the element on which this method is invoked, and false otherwise.; 注記：この~methodは、 `setPointerCapture()$m を~callした直後において当の要素がまだ `gotpointercapture$et ~eventを受取っていなくても， ~T を返す。その結果、 `pointerdown$et ~event用の~listenerの内側から`暗黙的な~pointer捕捉＠#implicit-pointer-capture$を検出するときに有用になる。 ◎ Note This method will return true immediately after a call to setPointerCapture(), even though that element will not yet have received a gotpointercapture event. As a result it can be useful for detecting implicit pointer capture from inside of a pointerdown event listener.

6. `GlobalEventHandlers^I ~mixinに対する拡張

この節では、既存の `GlobalEventHandlers$I ~mixinに対する — ~event~handlerの登録を手助けするための — 拡張を述べる ◎ The following section describes extensions to the existing GlobalEventHandlers mixin to facilitate the event handler registration.

partial interface mixin `GlobalEventHandlers$I {
    attribute `EventHandler$I `onpointerover@m;
    attribute `EventHandler$I `onpointerenter@m;
    attribute `EventHandler$I `onpointerdown@m;
    attribute `EventHandler$I `onpointermove@m;
    [`SecureContext$] attribute `EventHandler$I `onpointerrawupdate@m;
    attribute `EventHandler$I `onpointerup@m;
    attribute `EventHandler$I `onpointercancel@m;
    attribute `EventHandler$I `onpointerout@m;
    attribute `EventHandler$I `onpointerleave@m;
    attribute `EventHandler$I `ongotpointercapture@m;
    attribute `EventHandler$I `onlostpointercapture@m;
};

これらの属性は、いずれも，対応する名前の~event （ `ongotpointercapture$m は `gotpointercapture$et に対応する, 等々）用の`~event~handler~IDL属性$ `HTML$r である。 ◎ onpointerover • The event handler IDL attribute for the pointerover event type. ◎ onpointerenter • The event handler IDL attribute for the pointerenter event type. ◎ onpointerdown • The event handler IDL attribute for the pointerdown event type. ◎ onpointermove • The event handler IDL attribute for the pointermove event type. ◎ onpointerrawupdate • The event handler IDL attribute for the pointerrawupdate event type. ◎ onpointerup • The event handler IDL attribute for the pointerup event type. ◎ onpointercancel • The event handler IDL attribute for the pointercancel event type. ◎ onpointerout • The event handler IDL attribute for the pointerout event type. ◎ onpointerleave • The event handler IDL attribute for the pointerleave event type. ◎ ongotpointercapture • The event handler IDL attribute for the gotpointercapture event type. ◎ onlostpointercapture • The event handler IDL attribute for the lostpointercapture event type.

7. `Navigator^I ~interfaceに対する拡張

装置の検出~supportを供するため、この仕様は， `Navigator^I ~interface `HTML$r を拡張する。 ◎ The Navigator interface is defined in [HTML]. This specification extends the Navigator interface to provide device detection support.

partial interface `Navigator$I {
    readonly    attribute `long$ `maxTouchPoints$m;
};

`maxTouchPoints@m: 装置により~supportされる同時~touch接触の最大~数。複数の`~digitizer$を備える装置の事例では（例：複数の~touchscreen）、値は，［個々の~digitizerにより~supportされる最大~接触~数］のうちの最大になるモノトスル。 ◎ The maximum number of simultaneous touch contacts supported by the device. In the case of devices with multiple digitizers (e.g. multiple touchscreens), the value MUST be the maximum of the set of maximum supported contacts by each individual digitizer.; 例えば、装置が 3 つの~touchscreenを備えていて ~supportする同時~touch接触~数が 2, 5, 10 ならば、 `maxTouchPoints$m 値は `10^c にされるべきである。 ◎ For example, suppose a device has 3 touchscreens, which support 2, 5, and 10 simultaneous touch contacts, respectively. The value of maxTouchPoints should be 10.

注記： `maxTouchPoints$m に対する 0 より大きい値が，利用者の装置が~touch入力を~supportすることを指示するとしても、利用者が~touch入力を利用している`とは限らない^em。作者は、［ ~mouse, ~pen, ~screen~reader, 等々］，~system上に在り得る他の入力~様式も考慮するよう気を付けるべきである。 ◎ Note While a maxTouchPoints value of greater than 0 indicates the user's device is capable of supporting touch input, it does not necessarily mean the user will use touch input. Authors should be careful to also consider other input modalities that could be present on the system, such as mouse, pen, screen readers, etc.

注記： `maxTouchPoints$m は、［現在の~hardwareでも，内容のヤリトリ~modelを認識できる］ことを確保するために利用されることが多い。 ~hardware~~能力がより限られた下でも、利用者に~UI~affordanceを供することはできる。精確な最大~接触~数が既知でない~platform上では、認識されることが保証される最小~数が供される。したがって、認識される~touch接触~数が `maxTouchPoints$m の値を超過する可能性もある。 ◎ Note maxTouchPoints is often used to ensure that the interaction model of the content can be recognized by the current hardware. UI affordances can be provided to users with less capable hardware. On platforms where the precise number of touch points is not known, the minimum number guaranteed to be recognized is provided. Therefore, it is possible for the number of recognized touch points to exceed the value of maxTouchPoints.

8. 直な操作の挙動の宣言-法

`§ 各種属性と既定~動作＠#attributes-and-default-actions$ にて注記したとおり、表示域~操作（~pan-zoom）は，~pointer~eventを取消しても抑止できない。作者は，代わりに、 `touch-action$p ~CSS~propを利用して，［これらの挙動のうち，どれを許容してどれを抑止したいと求めるか］を宣言的に定義しなければナラナイ。 ◎ As noted in Attributes and Default Actions, viewport manipulations (panning and zooming) cannot be suppressed by canceling a pointer event. Instead, authors must declaratively define which of these behaviors they want to allow, and which they want to suppress, using the touch-action CSS property.

注記：表示域を操作するために利用される~pointerに関する課題は，一般に~touch入力に限られるが（利用者の手指が［内容とヤリトリする, ~pageを［ ~panする／~zoomする］］どちらにも利用され得る所で）、他の`~pointer型$に対しても，（直接間接を問わず）同じ型の操作を許容する~UAもある。一例として，［ ~mobile／~tablet ］機器においては、利用者は~stylusを利用して~scroll可能かもしれない。歴史的な理由から、［この仕様に定義される `touch-action$p ~CSS~propは， ~touch入力のみを指す］ように見受けられるが，事実においては［ `直な~pan-zoom$を許容する形を成す~pointer入力］すべてに適用される。 ◎ Note While the issue of pointers used to manipulate the viewport is generally limited to touch input (where a user's finger can both interact with content and pan/zoom the page), certain user agents may also allow the same types of (direct or indirect) manipulation for other pointer types. For instance, on mobile/tablet devices, users may also be able to scroll using a stylus. While, for historical reasons, the touch-action CSS property defined in this specification appears to refer only to touch inputs, it does in fact apply to all forms of pointer inputs that allow direct manipulation for panning and zooming.

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

◎名 `touch-action@p ◎値 `auto$v | `none$v | [ [ `pan-x$v | `pan-left$v | `pan-right$v ] || [ `pan-y$v | `pan-up$v | `pan-down$v ] ] | `manipulation$v ◎初 `auto$v ◎適次を除くすべての要素 ⇒ `置換され$ない行内~要素【すなわち，`行内~box$】／~tableの［ `row^v, `row-group^v, `column^v, `column-group^v ］ ◎ all elements except: non-replaced inline elements, table rows, row groups, table columns, and column groups. ◎継されない ◎百受容しない ◎算指定されたとおり ◎表終

`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値は、一部の “過~scroll（ `overscroll^en ）” 時の挙動†を~custom化するときに有用になる。例えば、文書の `touch-action$p を［ ~scroll位置が 0 のときは `pan-x pan-down^v ／他の場合は `pan-x pan-y^v ］に設定すれば，単純な “引っ張ったら~~更新する（ `pull-to-refresh^en ）” 効果††を実装できる。これは、 ~pointer~event~handlerが［文書の上端から上方への［ ~panning／~scrolling ］が開始されたときの挙動］を定義することを許容する。 ◎ Note The direction-specific pan values are useful for customizing some overscroll behaviors. For example, to implement a simple pull-to-refresh effect the document's touch-action can be set to pan-x pan-down whenever the scroll position is 0 and pan-x pan-y otherwise. This allows pointer event handlers to define the behavior for upward panning/scrolling that start from the top of the document.

【† 終端まで~scrollし切った所で，同じ方向に更に~scrollしようと~~操作した際に、ある程度まで（空間が現れるように）~scrollしつつ， ~~操作し終えたときは ~scroll位置を終端に戻すような効果。利用者にとっては、内容がそこで終わりであること（~touchの不正確さや~UIの~~操作~modelに因り~scrollできないわけではないこと）が認識されやすくなる。】【†† 過~scroll時に，新たな更新~内容を要請し、何か更新があれば，~~空いた空間をその内容で埋めるように挙動する~UI。】

方向に特有な各種~pan値は、［ ~nativeに~scrollする要素の中で，~pointer~eventの取扱いを伴う（あるいは，その逆にする）］ような，~customな~panningを実装する~componentを構成するためにも利用できる。例えば，ある “画像~回転台” に `pan-y$v を利用すれば、［文書の縦方向への~panningに干渉することなく，横方向の~pan操作oに対し~pointer~eventを受取る］ことを確保できるようになる。回転台が~~右端に達したとき，その `touch-action$p を `pan-y pan-right^v に変更すれば、その端を超える後続な~scroll操作oは，アリなら表示域の中で文書を~scrollできるようになる。［ ~panning／~scrolling ］の挙動を途中で変更することは、アリでない。 ◎ The direction-specific pan values can also be used for composing a component that implements custom panning with pointer event handling within an element that scrolls natively (or vice-versa). For example, an image carousel may use pan-y to ensure it receives pointer events for any horizontal pan operations without interfering with vertical panning of the document. When the carousel reaches its right-most extent, it may change its touch-action to pan-y pan-right so that a subsequent scroll operation beyond its extent can scroll the document within the viewport if possible. It's not possible to change the behavior of a panning/scrolling operation while it is taking place.

注記：一部の`直な~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.

`7@ex： `直な操作$用の挙動をすべて許容しない例： ◎ Example 7: Disallowing all direct manipulation behaviors

<div style="touch-action: none;">

この要素は、
`直な操作$のうち［
`touch-action^p が指定されていなければ~pan-zoomに至るもの
］に対しても，~pointer~eventを受取る。
◎
This element receives pointer events for all direct manipulation interactions that otherwise lead to panning or zooming.

</div>

`8@ex：横方向への~panningに限り許容する例： ◎ Example 8: Allowing horizontal panning only

<div style="touch-action: pan-x;">

この要素は、
横方向へ~panしていないときは~pointer~eventを受取る
◎
This element receives pointer events when not panning in the horizontal direction.

</div>

`9@ex： `直な~pan-zoom$用の挙動を許容しない子~領域がある例： ◎ Example 9: Child regions that disallow direct manipulation behaviors for panning and zooming

<div style="overflow: auto;">
    <div style="touch-action: none;">

この要素は、
`直な操作$のうち［
`touch-action^p が指定されていなければ~pan-zoomに至るもの
］に対しても，~pointer~eventを受取る。
◎
This element receives pointer events for all direct manipulation interactions that otherwise lead to panning or zooming.

    </div>
    <div>

この要素に対する`直な操作$は、
親を操作するために消費されてもヨイ。
◎
Direct manipulation interactions on this element MAY be consumed for manipulating the parent.

    </div>
</div>

`10@ex： `直な~pan-zoom$用の挙動を許容しない親が挟まれている例： ◎ Example 10: Intermediate parent that disallows direct manipulation behaviors for panning and zooming

<div style="overflow: auto;">
    <div style="touch-action: pan-y;">
        <div style="touch-action: pan-x;">

この要素は、
すべての`直な操作$に対し~pointer~eventを受取る
— 横方向への~panningに限り許容する要素と~scroll可能な要素（ `overflow: auto^css ）との間には、
縦方向の~panningに限り許容する先祖があるので。
したがって、
`直な~pan-zoom$用の挙動は，~UAにより取扱われない。
◎
This element receives pointer events for all direct manipulation interactions because
it allows only horizontal panning yet an intermediate ancestor
(between it and the scrollable element) only allows vertical panning.
Therefore, no direct manipulation behaviors for panning/zooming are
handled by the user agent.

        </div>
    </div>
</div>

`11@ex：許容される`直な~pan-zoom$用の挙動を制約する親が挟まれている例： ◎ Example 11: Intermediate parent that restricts allowed direct manipulation behaviors for panning and zooming

<div style="overflow: auto;">
    <div style="touch-action: pan-y pan-left;">
        <div style="touch-action: pan-x;">

この要素は、
左方へ~panしていないときは~pointer~eventを受取る。
◎
This element receives pointer events when not panning to the left.

        </div>
    </div>
</div>

9. ~pointer捕捉

9.1. 序論

◎非規範的

`~pointer捕捉@ （ `pointer capture^en ）により、特定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.

`slider^dgm

~thumb要素を前後に~slideして値を選ぶような，~custom~slider~controlの例。 ~thumb上で `pointerdown$et が生じたとき，~pointer捕捉を利用すれば、利用者は，~pointerが~sliderからそれても ~slideできるようになる。 ◎ Figure 6＼ Example of a custom slider control that chooses a value by sliding the thumb element back and forth. After pointerdown on the thumb, pointer capture can be used to allow the user to slide the thumb even if the pointer drifts off of it.

9.2. ~pointer捕捉の設定-法

要素による`~pointer捕捉$は、要素に対し `setPointerCapture(pointerId)$m ~methodを~callすることにより設定される — その~method手続きは：

%~pointer ~LET %pointerId に合致する`作動中な~pointer$は［在るならばそれ／無いならば ε ］
~IF［ %~pointer ~EQ ε ］ ⇒ ~THROW `NotFoundError$E
`~pointer捕捉を設定する$( コレ, %~pointer )

◎ Pointer capture is set on an element of type Element by calling the element.setPointerCapture(pointerId) method.＼ When this method is invoked, the user agent MUST run the following steps: • If the pointerId provided as the method's argument does not match any of the active pointers, then throw a "NotFoundError" DOMException. • Let the pointer be the active pointer specified by the given pointerId.

`~pointer捕捉を設定する@ ~algoは、所与の ( `Element$I %要素, `作動中な~pointer$ %~pointer ) に対し： ◎ ↑

~IF［ %要素は`接続されて$いない `DOM$r ］ ⇒ ~THROW `InvalidStateError$E ◎ If the element is not connected [DOM], throw an "InvalidStateError" DOMException.
%文書 ~LET %要素の`~node文書$ `DOM$r ◎ ↓
~IF［ %文書には現在~lockされている要素がある（ `PointerLock$r `pointerLockElement$m 【は ~NULL 以外を返す要素がある】）］ ⇒ ~THROW `InvalidStateError$E ◎ If this method is invoked while the element's node document [DOM] has a locked element ([PointerLock] pointerLockElement), throw an "InvalidStateError" DOMException.
~IF［ %~pointer の~buttonは`作動~状態$でない］~OR［ %文書 ~NEQ %~pointer にて`作動中な文書$ ］ ⇒ ~RET ◎ If the pointer is not in the active buttons state or the element's node document is not the active document of the pointer, then terminate these steps.
%~pointer の`処理待ち捕捉~target$ ~SET %要素 ◎ For the specified pointerId, set the pending pointer capture target override to the Element on which this method was invoked.

［ `~pointer捕捉を設定する$／`~pointer捕捉を解放する$ ］~callが処理待ち状態にある間に（`処理待ち~pointer捕捉を処理する$を見よ），［ ~pointer捕捉を設定する／~pointer捕捉を解放する］~call（順不同）が為された場合、後者の~callが成功裡であるならば，後者の~callが前者の~callを上書きする — 他の場合は，前者の~callが有効果であり続ける。このことは、 `pointerdown$et 用の~listenerにて，`暗黙的な~pointer捕捉＠#implicit-pointer-capture$を解放する試みが失敗した場合にも該当する。 ◎ If a call to set or release a pointer capture is made while a previous set or release call is in a pending state (see process pending pointer capture), the second call overrides the first call if the second call is successful, otherwise the first call remains effective. This is true for a failed attempt to release an implicit pointer capture at a pointerdown listener.

9.3. ~pointer捕捉の解放-法

要素による`~pointer捕捉$は、要素に対し `releasePointerCapture(pointerId)$m ~methodを~callすることにより，明示的に解放できる — その~method手続きは：

%~pointer ~LET %pointerId に合致する`作動中な~pointer$は［在るならばそれ／無いならば ε ］
~IF［ %~pointer ~EQ ε 【！and these steps are not being...】］ ⇒ ~THROW `NotFoundError$E
`~pointer捕捉を解放する$( コレ, %~pointer )

◎ Pointer capture is released on an element explicitly by calling the element.releasePointerCapture(pointerId) method.＼ When this method is called, the user agent MUST run the following steps: ◎ • If the pointerId provided as the method's argument does not match any of the active pointers and these steps are not being invoked as a result of the implicit release of pointer capture, then throw a "NotFoundError" DOMException.

`~pointer捕捉を解放する@ ~algoは、所与の ( `Element$I %要素, `作動中な~pointer$ %~pointer ) に対し ⇒ ~IF［ %~pointer の`処理待ち捕捉~target$ ~EQ %要素（すなわち，%要素の `hasPointerCapture$m ~EQ ~T ）］ ⇒ %~pointer の`処理待ち捕捉~target$ ~SET ~NULL ◎ • If hasPointerCapture is false for the Element with the specified pointerId, then terminate these steps. • For the specified pointerId, clear the pending pointer capture target override, if set.

注記： `§ ~pointer捕捉の設定-法＠#setting-pointer-capture$ の注記も見よ。 ◎ Note See the note in the section Setting pointer capture.

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捕捉の暗黙的な解放-法

［ `pointerup$et ／ `pointercancel$et ］~eventを発火した直後には、 `~pointer捕捉を暗黙的に解放する@ モノトスル — それは、所与の ( `作動中な~pointer$ %~pointer ) に対し，次の手続きを走らす：

%~pointer の`処理待ち捕捉~target$ ~SET ~NULL
`処理待ち~pointer捕捉を処理する$( %~pointer )
~IF［ %~pointer は~hoverを~supportする］ ⇒ 必要yなら、 %~pointer の現在の位置を反映するよう，対応する`境界~event$ 【以前に送信した`境界~event$と対になるそれ】を — 捕捉なしに — 送信する

◎ Immediately after firing the pointerup or pointercancel events, the user agent MUST clear the pending pointer capture target override for the pointerId of the pointerup or pointercancel event that was just dispatched, and then run process pending pointer capture steps to fire lostpointercapture if necessary. After running process pending pointer capture steps, if the pointer supports hover, user agent MUST also send corresponding boundary events necessary to reflect the current position of the pointer with no capture.

ある`文書$に`接続されて$いた `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. 合体された~event群と予測された~event群

注記：この仕様は、 ~UAが，~pointerの動き~dataをどう［合体する／予測する］べきかは定義しない。この情報へ~accessするための~APIを指定するだけである。 ◎ Note This specification does not define how user agents should coalesce or predict pointer movement data. It only specifies the API for accessing this information.

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.

描き~appにおける曲線の例。 `pointermove$et ~eventからの合体された座標のみを利用して（黒っぽい丸）描いた曲線は，角張った様子が目立つ。同じ線を `getCoalescedEvents()$m が供するもっときめ細かな点群（赤い中空な丸）利用して描いた結果は，~pointerの動きをもっと滑らかに近似する。 ◎ Figure 7＼ Example of a curve in a drawing application — using only the coalesced coordinates from pointermove events (the grey dots), the curve is noticeably angular and jagged; the same line drawn using the more granular points provided by getCoalescedEvents() (the red circles) results in a smoother approximation of the pointer movement.

各 `PointerEvent$I ~obj %~event には、 `合体d~event~list@ （ `coalesced events list^en ）が結付けられる — それは、 `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 unchanged 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.

`12@ex：合体d~event~listを利用している基本的な~canvasの描き~app ◎ Example 12: Basic canvas drawing application using the coalesced events list

<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.

注記：次の例に、実際に起きた~event列と， ~UAにより配送される~event列を~~時系列順に示す（すなわち、各~eventの `timeStamp$m 値は順に増大する）： ◎ Note Here is an example of the actual events happening with increasing timeStamp values and the events dispatched by the user agent:

カッコ内の数は~pointerの `pointerId$m
実際の~pointerの状態~変化	配送される~event／合体される~eventの個数
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個【 0 個？】
（ 1 ）座標~変化	`pointerrawupdate$et（ 1 ）／ 1 個
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個
（ 1 ）座標~変化	`pointerrawupdate$et（ 1 ）／ 1 個
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個
（ 1 ）~buttonが押された	`pointermove$et（ 1 ）／ 2 個 `pointermove$et（ 2 ）／ 4 個 `pointerdown$et（ 1 ）／ 0 個
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個
（ 2 ）座標~変化	`pointerrawupdate$et（ 2 ）／ 1 個
（ 1 ）~buttonが離された	`pointermove$et（ 2 ）／ 2 個 `pointerup$et（ 1 ）／ 0 個

◎ Actual events｜Dispatched events pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=1) coordinate change｜pointerrawupdate (pointerId=1) w/ one coalesced event pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=1) coordinate change｜pointerrawupdate (pointerId=1) w/ one coalesced event pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=1) button press｜pointermove (pointerId=1) w/ two coalesced events pointermove (pointerId=2) w/ four coalesced events pointerdown (pointerId=1) w/ zero coalesced events pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=2) coordinate change｜pointerrawupdate (pointerId=2) w/ one coalesced event pointer (pointerId=1) button release｜pointermove (pointerId=2) w/ two coalesced events pointerup (pointerId=1) w/ zero coalesced events

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.

描き~appにおける線の例（ `pointermove$et ~eventからの合体された座標~群を利用して，左下から右上へ~gestureを描いた結果） — ~UAが予測した未来の点群（中空な丸）を示している。 ◎ Figure 8＼ Example of a line in a drawing application (the result of a drawing gesture from the bottom left to the top right), using the coalesced coordinates from pointermove events, showing the user agent's predicted future points (the grey circles).

各 `PointerEvent$I ~obj %~event には `予測d~event~list@ （ `predicted events list^en ）が結付けられる — それは、 `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 unchanged 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.

`13@ex：合体された~event群, 予測された~event群を利用して何か描く概念的な~approach。 ◎ Example 13: Conceptual approach to drawing using coalesced events and 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の拡充-法と保守-法

~UAは，`~trusted$な `PointerEvent$I %~pointer~event の作成-時には、その［ `合体d~event~list$, `予測d~event~list$ ］を成す ~EACH( %~event ) に対し，次の手続きを走らすベキである： ◎ When a trusted PointerEvent is created, user agents SHOULD run the following steps for each event in the coalesced events list and predicted events list:

%~event の次に挙げる属性を %~pointer~event の対応する属性と合致するように設定する ⇒＃ `pointerId$m, `pointerType$m, `isPrimary$m, `isTrusted$m ◎ Set the event's pointerId, pointerType, isPrimary and isTrusted to match the respective properties of the "parent" pointer event.
%~event の ⇒＃ `cancelable$m ~SET ~F, `bubbles$m ~SET ~F ◎終（当の~listを成す~eventたちは、常に一緒に配送されるので） ◎ Set the event's cancelable and bubbles to false (as these events will never be dispatched in isolation).
%~event の`合体d~event~list$ ~SET 空~list ◎ Set the event's coalesced events list and predicted events list to an empty list.
%~event の`予測d~event~list$ ~SET 空~list ◎ ↑
%~event の他の属性を `PointerEvent$I 用の既定の値に初期化する ◎ Initialize all other attributes to default PointerEvent values.

~UAは，`~trusted$な `PointerEvent$I %~pointer~event の`~target$【！`target$m】が変化したときは、その［ `合体d~event~list$, `予測d~event~list$ ］を成す ~EACH( %~event ) に対し，次の手続きを走らすベキである： ◎ When a trusted PointerEvent's target is changed, user agents SHOULD, for each event in the coalesced events list and predicted events list:

%~event の`~target$ ~SET %~pointer~event の`~target$【！`target$m】 ◎ Set the event's target to match the target of the "parent" pointer event.

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

11. ~mouse~eventとの互換性を得るための対応付け

今日の~web内容では、 `~mouse~event$向けのみに書かれている~codeが大勢を占めている。 ~UAは、その種の内容との互換性を得るためとして、以下に与える~algoにより，汎用~pointer入力を~mouse~eventに対応付けてもヨイ。 ◎ The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how the user agent MAY map generic pointer input to mouse events for compatibility with this content.

互換性を得るための ~mouse~eventへの対応付けは、この仕様の任意選択な特能である。 ~UAには、既存の旧来の内容との最良な互換性を得るために，この特能を~supportすることが奨励される。 ◎ The compatibility mapping with mouse events is an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content.

注記：高~levelからは、互換性~mouse~eventは，各自に対応する~pointer~eventと “互いに差し挟まれる” ものと意図される。しかしながら、この特定の順序は，義務ではない — 互換性~mouse~eventを実装する~UAは、 ~mouse~eventの配送を［遅延する／~group化］するものと裁定してもヨイ — それらの相対的な順序が一貫する限り。 ◎ At a high level, compatibility mouse events are intended to be "interleaved" with their respective pointer events. However, this specific order is not mandatory, and user agents that implement compatibility mouse events MAY decide to delay or group the dispatch of mouse events, as long as their relative order is consistent.

特に，~touchscreen入力の事例では、 ~UAは，~gesture認識~用に追加的な経験則を適用してもヨイ（作者により `touch-action$p を通して明示的に抑止されてない限り）。 `pointerdown$et ~eventから `pointerup$et ~eventまでを成す`~event連列$の間、 ~gesture認識は — ~gestureを検出するか無視するか決定するために — `pointerup$et ~eventまで待機する必要もあろう。その結果，~UAが［当のヤリトリが特定0の~gestureとして意図されたものでない］ことを決定した場合、当の連列~用の互換性~mouse~eventは，最後の `pointerup$et ~eventの後に一緒に配送され得る。これらの~UAに特有な~gesture認識は、この仕様では定義されないので，実装ごとに相違し得る。 ◎ Particularly in the case of touchscreen inputs, user agents MAY apply additional heuristics for gesture recognition (unless explicitly suppressed by authors through touch-action). During a sequence of events between a pointerdown event and a pointerup event, the gesture recognition may have to wait until the pointerup event to detect or ignore a gesture. As a result the compatibility mouse events for the whole sequence may be dispatched together after the last pointerup event, if the user agent determined that an interaction was not intended as a particular gesture. These specifics of user agent gesture recognition are not defined in this specification, and they may differ between implementations.

~UAは、［ `click$et, `auxclick$et, `contextmenu$et ］~eventを — `互換性~mouse~event$を~supportするかどうかに関わらず，常に — ~supportするモノトスル — これらの~eventは、 `PointerEvent$I 型であり，`互換性~mouse~event$ではないので。 `~pointer~event$の間に `preventDefault()$m が~callされても，これらの~eventが発火されるか否かに対する効果は無いモノトスル。 ◎ Regardless of their support for compatibility mouse events, the user agents MUST always support the click, auxclick and contextmenu events because these events are of type PointerEvent and are therefore not compatibility mouse events. Calling preventDefault during a pointer event MUST NOT have an effect on whether click, auxclick, or contextmenu are fired or not.

注記：これらの高~levelな~eventのうち一部（ `contextmenu$et, `focus$et, `blur$et, 等々）と`~pointer~event$との相対的な順序は、未定義であり，~UAごとに変わり得る。例えば、［ `pointerup$et, `contextmenu$et ］の順に発火されることが多い~UAもあれば，その逆順に発火されることが多い~UAもある。また、対応する`~pointer~event$を伴わずに発火される状況もある（一例として、 ~keyboardによるヤリトリの結果として）。 ◎ Note The relative order of some of these high-level events (contextmenu, focus, blur, etc.) with pointer events is undefined and varies between user agents. For example, in some user agents contextmenu will often follow a pointerup, while in others it'll often precede a pointerup or pointercancel, and in some situations it may be fired without any corresponding pointer event (for instance, as a result of a keyboard interaction).

加えて，~UAは、［ `click^et ／ `auxclick^et ／ `contextmenu^et ］~eventを発火するべきかかどうか決定するときに，自前の経験則を適用し得る。一部の~UAは、これらの~eventを［同じ型の他の（首~pointerでない）~pointer／異なる型の他の首~pointer ］がある場合には，発火しないことを選ぶこともある。 ~UAは、特定0の動作を “~clean” な［ ~tap／~click／長押し］ではなかったものと決定して（一例として、手指による~touch~screenとのヤリトリが， ~screenと接触-中にある間に多過ぎる動きを含むとき），［ `click^et ／ `auxclick^et ／ `contextmenu^et ］~eventを発火しないものと裁定することもある。 ~UAの挙動を成すこれらの側面は、この仕様では定義されないので，実装ごとに相違し得る。 ◎ In addition, user agents may apply their own heuristics to determine whether or not a click, auxclick, or contextmenu event should be fired. Some user agents may choose not to fire these events if there are other (non-primary) pointers of the same type, or other primary pointers of a different type. User agents may determine that a particular action was not a "clean" tap, click, or long-press (for instance, if an interaction with a finger on a touch screen includes too much movement while the finger is in contact with the screen) and decide not to fire a click, auxclick, or contextmenu event. These aspects of user agent behavior are not defined in this specification, and they may differ between implementations.

対応付けられた`~mouse~event$は、他が注記されない限り，次で与えられる~targetに向けて発火されるべきである：

~mouse~eventを発火する時点で，`~pointer~event$の~targetがまだ`文書~tree内$にあるならば、それと同じ~target。
他の場合、［ `~pointer~event$を発火した時点で，その~targetの先祖であった~nodeたち］のうち，［ `~mouse~event$を発火する時点で`文書~tree内$にあるもの］のうち，最も子孫の~node†。特に、 ~mouse~eventの伝播~経路は，この先祖に基づく新たなものにされることになる。

【† ~event~handlerにより，~nodeたちが文書~内で他所に移動された場合、そのような子孫は一意に定まらなくなる場合もあり得るが、はっきりしない。そのような子孫は除外されるべきようにも思われる。また、 ~targetが除去されず文書の他所へ移動された場合も，同様になるかもしれない（`関係する課題＠https://github.com/w3c/pointerevents/issues/285$）。】

◎ Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its ownerDocument's tree. In this case, the mouse event should be fired at the original target's nearest ancestor node (at the time it was removed from the tree) that still participates in its ownerDocument's tree, meaning that a new event path (based on the new target node) is built for the mouse event.

作者は、 `pointerdown$et ~eventを取消すことにより，ある種の`互換性~mouse~event$の生産を防止できる — ただし： ◎ Authors can prevent the production of certain compatibility mouse events by canceling the pointerdown event.

防止できるのは、 ~pointerの~buttonが押されたときに限られる。 ~hoverしている~pointer （例：どの~buttonも押されていない~mouse）による~mouse~eventは、防止できない。 ◎ Mouse events can only be prevented when the pointer is down. Hovering pointers (e.g. a mouse with no buttons pressed) cannot have their mouse events prevented.
次に挙げる~eventは、決して防止されない（~pointerの~buttonが押されていても） ⇒＃ `mouseover$et, `mouseout$et, `mouseenter$et, `mouseleave$et ◎ The mouseover, mouseout, mouseenter, and mouseleave events are never prevented (even if the pointer is down).

`互換性~mouse~event$は、 `~pointer~event$用の`~event~listener$【！EventListener】の`受動的か$evLが ~T に設定された所では，防止し得ない。 `DOM$r ◎ Compatibility mouse events can't be prevented when a pointer event EventListener is set to be passive [DOM].

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の実効~位置@ （ `effective legacy mouse pointer position^en ）を次に従って保守することにより，これを保証するベキである。 ◎ 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 を挟まずに）続けて発火されないようにするなど。】

~UAは、［ `pointerdown$et ／ `pointerup$et ／ `pointermove$et ］~eventを発火するとき, あるいは［ `~window$に向けて `pointerleave$et ］~eventを発火するときは、その~event %event を発火する直前に，次の手続きを走らすベキである： ◎ Right before firing a pointerdown, pointerup or pointermove event, or a pointerleave event at the window, the user agent SHOULD run the following steps:

%旧~位置 ~LET 現在の`旧来の~mouse~pointerの実効~位置$ ◎ ↓
%新~位置 ~LET ［ %event が `pointerleave$et ならば `域外^i ／ ~ELSE_ %event の~target ］ ◎ Let T be the target of the pointerdown, pointerup or pointermove event being dispatched. For the pointerleave event, unset T.
~IF［ %新~位置 ~EQ %旧~位置］ ⇒ ~RET ◎ If T and current effective legacy mouse pointer position are both unset or they are equal, terminate these steps.
`UIEVENTS$r に従って、［ ~mouseが %旧~位置から %新~位置へ移動した］ものと見なした下で［ `mouseover$et ／ `mouseout$et ／ `mouseenter$et ／ `mouseleave$et ］~eventを発火する — ここでの［ %旧~位置／ %新~位置］に対する値 `域外^i は、 ~mouse位置が~UIwindow外にあると見なす ◎ Dispatch mouseover, mouseout, mouseenter and mouseleave events as per [UIEVENTS] for a mouse moving from the current effective legacy mouse pointer position to T. Consider an unset value of either current effective legacy mouse pointer position or T as an out-of-window mouse position.
`旧来の~mouse~pointerの実効~位置$ ~SET %新~位置 ◎ Set effective legacy mouse pointer position to T.

注記： ~pointer遷移~event （すなわち， `pointerover^et, `pointerout^et, `pointerenter^et, `pointerleave^et ）から対応する旧来の~mouse遷移~event （すなわち， `mouseover^et, `mouseout^et, `mouseenter^et, `mouseleave^et ）への直な対応付けは、常に可能とは限らない — `旧来の~mouse~pointerの実効~位置$は、その事実を~model化する。 ~UAが［単独の旧来の~mouse入力を利用している 2 つの`首~pointer$ ］の~~調和を図るために［旧来の~mouse遷移~eventを~pointer遷移~eventより多く配送する］ことが必要になる事例を次の~animationで~~説明する。 ◎ Note The effective position of the legacy mouse pointer models the fact that we cannot always have a direct mapping from pointer transition events (i.e., pointerover, pointerout, pointerenter and pointerleave) to corresponding legacy mouse transition events (i.e., mouseover, mouseout, mouseenter and mouseleave). The following animation illustrates a case where a user agent needs to dispatch more legacy mouse transition events than pointer transition events to be able to reconcile two primary pointers using a single legacy mouse input.

同時な 2 つ~pointer — ~mouse~pointer（白い~cursor）と~touch~pointer（白い “手形” ~cursor） — が，単独の旧来の~mouse入力（橙色~cursor）を移動させる様子。 ◎ Simultaneous mouse pointer (white cursor) and touch pointer (white "hand" cursor) causing the single legacy mouse input (orange cursor) to move between the two pointers.

この~animationにおいては、 ~button 1 は： ◎ In this animation, note the time period between the mouse click and the touch tap.＼

~mouse~clickから~touch~tapまでの間は， `pointerout^et ~eventを受取らない（その間， “本物の” ~mouse~pointerは~button矩形を去らないので）が、 `旧来の~mouse~pointerの実効~位置$が~touch~tapにより ~button 2 へ移動したとき， `mouseout^et ~eventを受取る。 ◎ Button 1 receives no pointerout event (because the "real" mouse pointer didn't leave the button rectangle within this period), but Button 1 receives a mouseout event when the effective position of the legacy mouse pointer moves to Button 2 on touch tap.＼
類似に， ~touch~tapから~mouseが~button 1 を去る直前までの間は，同じ理由で `pointerover^et ~eventを受取らないが、 `旧来の~mouse~pointerの実効~位置$が移動して ~button 1 の内側へ戻ったとき， `mouseover^et ~eventを受取る。 ◎ Similarly, in the time period between the touch tap and the moment before the mouse leaves Button 1, Button 1 receives no pointerover event for the same reason, but Button 1 receives a mouseover event when the effective position of the legacy mouse pointer moves back inside Button 1.

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

~UAは、 ~hoverを~supportする装置による`~pointer~event$ %event を配送するときは，次の手続きを走らすベキである： ◎ Whenever the user agent is to dispatch a pointer event for a device that supports hover, it SHOULD run the following steps:

~IF［ %event の `isPrimary$m 属性 ~EQ ~F ］ ⇒＃ %event を配送する； ~RET ◎ If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
~IF［ %event の型 ~IN { `pointerdown$et, `pointerup$et, `pointermove$et } ］~OR［［ %event の型 ~EQ `pointerleave$et ］~AND［ %event の~targetは`~window$である］］ ⇒ `§ 旧来の~mouse~pointerに対する位置の追跡-法＠#tracking-the-effective-position-of-the-legacy-mouse-pointer$に従って，互換性~mouse遷移~eventを配送する ◎ If the pointer event to be dispatched is a pointerdown, pointerup or pointermove event, or a pointerleave event at the window, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
%event を`互換性~mouse~eventも込みで配送する$ ◎ ↓

`~pointer~event$ %event を `互換性~mouse~eventも込みで配送する@ ~algoは： ◎ ↓

%event を配送する ◎ Dispatch the pointer event.
%装置~型 ~LET %event の `pointerType$m ◎ ↓
~IF［ %event の型 ~EQ `pointerdown$et ］~AND［ %event は`取消された$ ］ ⇒ %装置~型用の`~mouse~eventは防止するか$ ~SET ~T ◎ If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType.

~IF［ %装置~型用の`~mouse~eventは防止するか$ ~EQ ~F ］ ⇒ %event の型に応じて、次の表tの 2 列目に与える型の~mouse~eventを， 3 列目に与える~targetに向けて発火する：

%event の型	~mouse~event型	~target
`pointerdown$et	`mousedown$et	%event の~target
`pointermove$et	`mousemove$et	%event の~target
`pointerup$et	`mouseup$et	%event の~target
`pointercancel$et	`mouseup$et	`~window$

◎ If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: ◎ pointerdown, then fire a mousedown event. ◎ pointermove, then fire a mousemove event. ◎ pointerup, then fire a mouseup event. ◎ pointercancel, then fire a mouseup event at the window.

~IF［ %event の型 ~IN { `pointerup$et, `pointercancel$et } ］ ⇒ %装置~型用の`~mouse~eventは防止するか$ ~SET ~F ◎ If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.

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.

このことから，~UAには、これらの型の入力~装置に対しては，異なる対応付けを供することが要求される。 ~UAは、所与の %~target に向けて［ `~hoverを~supportしない装置$による`~pointer~event$ ］ %event を配送するときは，次の手続きを走らすベキである： ◎ This requires that user agents provide a different mapping for these types of input devices. Whenever the user agent is to dispatch a pointer event for a device that does not support hover, it SHOULD run the following steps:

~IF［ %event の `isPrimary$m 属性 ~EQ ~F ］ ⇒＃ %event を配送する； ~RET ◎ If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
%~pointer ~LET %event を生じさせた~pointer ◎ ↓
~IF［ %event の型 ~EQ `pointerover$et ］~AND［ %~pointer による `pointerdown$et ~eventはまだ生じていない］ ⇒ `mousemove$et ~eventを発火する（旧来の~mouse向け~codeとの互換性を得るために） ◎ If the pointer event to be dispatched is pointerover and the pointerdown event has not yet been dispatched for this pointer, then fire a mousemove event (for compatibility with legacy mouse-specific code).
~IF［ %event の型 ~IN { `pointerdown$et, `pointerup$et, `pointermove$et } ］~OR［［ %event の型 ~EQ `pointerleave$et ］~AND［ %event の~targetは`~window$である］］ ⇒ `§ 旧来の~mouse~pointerに対する位置の追跡-法＠#tracking-the-effective-position-of-the-legacy-mouse-pointer$に従って，互換性~mouse遷移~eventを配送する ◎ If the pointer event to be dispatched is a pointerdown, pointerup or pointermove event, or a pointerleave event at the window, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
%event を，`互換性~mouse~eventも込みで配送する$ ◎ Dispatch the pointer event. ◎ If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType. ◎ If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: ◎ pointerdown, then fire a mousedown event. ◎ pointermove, then fire a mousemove event. ◎ pointerup, then fire a mouseup event. ◎ pointercancel, then fire a mouseup event at the window. ◎ If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.

［ `~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].

注記： `~hoverを~supportしない装置$の`首~pointer$による要素の作動化（ `click$et ）（例： ~touchscreen上の単独の手指）は、概して，次の`~event連列$を生産することになる：

`mousemove$et
`pointerover$et
`pointerenter$et
`mouseover$et
`mouseenter$et
`pointerdown$et — この~eventが取消された場合、以降における［ `mousedown$et, `mousemove$et, `mouseup$et ］は生産されない。
`mousedown$et
~pointerの動きに依存して， 0 回以上の［ `pointermove$et ／ `mousemove$et ］~event
`pointerup$et
`mouseup$et
`pointerout$et
`pointerleave$et
`mouseout$et
`mouseleave$et
`click$et

◎ Note The activation of an element (click) with a primary pointer that does not support hover (e.g. single finger on a touchscreen) would typically produce the following event sequence: • mousemove • pointerover • pointerenter • mouseover • mouseenter • pointerdown • mousedown • Zero or more pointermove and mousemove events, depending on movement of the pointer • pointerup • mouseup • pointerout • pointerleave • mouseout • mouseleave • click ◎ If, however, the pointerdown event is canceled during this interaction then the sequence of events would be: • mousemove • pointerover • pointerenter • mouseover • mouseenter • pointerdown • Zero or more pointermove events, depending on movement of the pointer • pointerup • pointerout • pointerleave • mouseout • mouseleave • click

~security／~privacyの考慮点

この付録では、 Pointer Events 実装における［ ~security／~privacy ］の考慮点について論じる。論点は、この仕様に定義される［ ~event~model, ~API, ~event ］の実装から直に発生する［ ~security／~privacy ］の課題に限られる。 ◎ This appendix discusses security and privacy considerations for Pointer Events implementations. The discussion is limited to security and privacy issues that arise directly from implementation of the event model, APIs and events defined in this specification.

この仕様に定義される~event型の多くは、利用者の動作に呼応して配送される。これは、悪意的な~event~listenerが［概して，利用者が機密的と考える情報］ — 例：利用者が~pageとヤリトリしている間の［ ~mouse／~stylus／手指］の正確な経路や動きなど — への~accessを得られるようにする。 ◎ Many of the event types defined in this specification are dispatched in response to user actions. This allows malicious event listeners to gain access to information users would typically consider confidential, e.g., the exact path/movement of a user's mouse/stylus/finger while interacting with a page.

~pointer~eventは、追加的な情報を（利用者の装置が~supportする所で）包含する — ~pen入力に保持されている角度や傾き／接触~物理面の幾何／ ~stylusや~touch~screen上に~~感知された押圧など。［角度, 傾き, 幾何, 押圧］の情報は、利用者~機器の~sensorに直に関係する。すなわち、この仕様は，そのような~sensorへの~accessを生成元に許容する。 ◎ Pointer events contain additional information (where supported by the user's device), such as the angle or tilt at which a pen input is held, the geometry of the contact surface, and the pressure exerted on the stylus or touch screen. Information about angle, tilt, geometry and pressure are directly related to sensors on the user's device, meaning that this specification allows an origin access to these sensors.

この~sensor~dataは、［どの型の仕組み（~mouse, ~touch, ~pen, 等）が入力に利用されているか］を決定する能とともに，［利用者, あるいは利用者の装置や環境］についての特性を推定するために利用され得る。このように推定された特性, および装置や環境の情報それ自体も敏感になり得る — 一例として、［悪意的な~siteが，利用者が支援技術を利用しているか否か推定すること］をさらに許容する。この情報はまた、特定0の利用者を追跡しようと試みるために［利用者~profileを築く, あるいは “指紋収集する” ］目的に利用されるものにもなり得る。 ◎ This sensor data, as well as the ability to determine the type of input mechanism (mouse, touch, pen) used, may be used to infer characteristics of a user, or of the user's device and environment. These inferred characteristics and any device/environment information may themselves be sensitive — for instance, they may allow a malicious site to further infer if a user is using assistive technologies. This information can also be potentially used for the purposes of building a user profile and/or attempting to "fingerprint" and track a particular user.

~UAは、軽減策として，［特定0の~sensor~data（角度, 傾き, 押圧など）への~access ］を［利用者が不能化する能を含める］ことや，それを［利用者から明示的に~~許可された後に限り，可用にする］ことを考慮してもよい。 ◎ As mitigation, user agents may consider including the ability for users to disable access to particular sensor data (such as angle, tilt, pressure), and/or to make it available only after an explicit opt-in from the user.

この仕様は、［作者が “予測された~event群” へ~accessできる］ような~methodを定義する。この仕様~自体は、 ~UAがそのような予測~用に利用するべき~algoを定義しない。この仕様の策定者は、そのような~algoが依拠するものは，先行する［利用者が遂行している現在の~gestureに関係する`~pointer~event$ ］に限られるものと想定している。 ~UAに特有な予測~algoの実装が［利用者についての敏感な情報も露呈し得る／利用者を “指紋収集して” 追跡するためにも利用し得る］ような追加的な~data — 複数~siteにわたる利用者-ヤリトリの全部的な履歴など — に依拠しないことを確保することは、 ~UAの責務である。 ◎ This specification defines the method by which authors can access "predicted events". The specification does not, itself, define the algorithms that user agents should use for their prediction. The specification authors envisage the algorithms to only rely on preceding pointer events related to the current gesture that a user is performing. It is the responsibility of user agents to ensure that their specific implementation of a prediction algorithm does not rely on any additional data - such as the user's full interaction history across different sites - that could reveal sensitive information about a user or be used to "fingerprint" and track them.

当~WGは、上述を超えるような考慮点は，この仕様には無いものと予見している： ◎ Beyond these considerations, the working group believes that this specification:

個人識別可能な情報は、公開しない。 ◎ Does not expose personally-identifiable information.
高価値な~dataを処することはない。 ◎ Does not deal with high-value data.
複数の閲覧~sessionに持続するような，生成元~用の新たな状態は、導入しない。 ◎ Does not introduce new state for an origin that persists across browsing sessions.
異なる生成元にわたって持続するような状態は、 ~webに公開しない。 ◎ Does not expose persistent, cross-origin state to the web.
現在~accessできない他のどのような~dataも、生成元に公開しない。 ◎ Does not expose any other data to an origin that it doesn’t currently have access to.
~scriptを［実行する／読込む］ような新たな仕組みは、可能化しない。 ◎ Does not enable new script execution/loading mechanisms.
利用者の所在への~accessは、生成元に許容しない。 ◎ Does not allow an origin access to a user’s location.
~UAが “私的閲覧” ~mode下にあるときの特別な取扱いは、要求しない。 ◎ Does not require any special handling when the user agent is in "incognito" mode.
他の装置への~accessは、生成元に許容しない。 ◎ Does not allow an origin access to other devices.
~UAに~nativeな~UI越しの制御は、生成元に許容しない。 ◎ Does not allow an origin control over a user agent’s native UI.
一時的な識別子は、 ~webに公開しない。 ◎ Does not expose temporary identifiers to the web.
挙動が［当事者-主体, 第三者-主体］どちらの文脈におけるものかは、判別しない。 ◎ Does not distinguish between behavior in first-party and third-party contexts.
利用者に局所的な装置には、 ~dataを持続しない。 ◎ Does not persist data to a user’s local device.
既定の~security特性へ降格することは、許容しない。 ◎ Does not allow downgrading default security characteristics.

用語集

◎非規範的

~pointerの~buttonが `作動~状態@ （ `active buttons state^en ）にある

`~pointer~event$の `buttons$m 属性が 0 以外の値をとる条件を満たしていることを意味する：

~mouseに対しては、装置にて何らかの~buttonが押下されているとき。
~touchに対しては、 `~digitizer$との物理的~接触があるとき。
~penに対しては、 ~penによる`~digitizer$との物理的~接触があるとき, または ~hover中にいずれかの~buttonが押下されているとき。

◎ The condition when a pointer has a non-zero value for the buttons property. For mouse, this is when the device has at least one button depressed. For touch, this is when there is physical contact with the digitizer. For pen, this is when either the pen has physical contact with the digitizer, or at least one button is depressed while hovering.

`作動中な文書@ （ `active document^en ）

所与の`作動中な~pointer$に対し，その~pointerからの【一定の型の】~eventを最後に受取った文書【に設定されることになる（初期~時は “未設定” ）】。 ◎ For every active pointer, the document that received the last event from that pointer.

`作動中な~pointer@ （ `active pointer^en ）, または単に~pointer†

~touch接触, ~penや~stylus, ~mouse~cursor, その他，~eventを生産し得るような~pointer。所与の~pointer（ `pointerId$m により一意に識別される）が，文書の中で追加的な~eventを生産し得るならば、その~pointerは，依然として作動中と見なされる。例えば： ◎ Any touch contact, pen/stylus, mouse cursor, or other pointer that can produce events. If it is possible for a given pointer (identified by a unique pointerId) to produce additional events within the document, then that pointer is still considered active. Examples:

機器に接続された~mouseは、常に作動中と見なされる。 ◎ A mouse connected to the device is always active.
~screen上の~touch接触は、作動中と見なされる。 ◎ A touch contact on the screen is considered active.
~touch接触／~penや~stylus が`~digitizer$の範囲を超えるように持上げられた場合、それはもはや作動中とは見なされない。 ◎ If a touch contact or pen/stylus is lifted beyond the range of the digitizer, then it is no longer considered active.

注記： ~platformによっては、 `作動中な~pointer$たちが成す集合には，~UAを~targetにしていないもの（例：他の~appを~targetにしているもの）も含め，装置へのすべての~pointer入力も含まれる。 ◎ Note On some platforms, the set of active pointers includes all pointer input to the device, including any that are not targeted at the user agent (e.g. those targeted at other applications).

【† `~pointer~event$を生産する装置を意味する用語として “`~pointer$” が下に定義されていて，紛らわしいが、 ~event処理の文脈における語 “~pointer” は，この`作動中な~pointer$を（暗黙的に）指している — 定義により，作動中でない~pointer`装置^emからは~eventは生じ得ないので。すなわち，~pointerは、装置が同じであっても，`作動中$な各~期間ごとに別々の~instanceを表現する（原文には明示的にそう記されていないが、そう解釈しなければ，~modelをきちんと定義できなくなる）。】

各 `作動中な~pointer$には、次に挙げるものが結付けられる — これらは、 `~pointer捕捉$の制御に利用され，当の~pointerにより生じる~eventの~targetを上書きする：

`捕捉~target@ （ `pointer capture target override^en ） ⇒ ~NULL／ある要素／`文書$ — 初期~時は ~NULL とする（`文書$に設定されるのは、 ~pointerが`作動中$な間に~targetが~DOMから除去された場合に起こる）。
`処理待ち捕捉~target@ （ `pending pointer capture target override^en ） ⇒ ~NULL／ある要素 — 初期~時は ~NULL とする。

【これらの用語は，原文では他所（~algo内）で定義されているが、この訳では，ここに集約する（規範的）。】

`取消された@ ~event（ `canceled event^en ）

`UIEVENTS$r, `HTML$r の定義に従って，`既定~動作$が防止された~event — `preventDefault()$m により／ ~event~handlerから ~F が返されたため／他の手段により。 ◎ An event whose default action was prevented by means of preventDefault(), returning false in an event handler, or other means as defined by [UIEVENTS] and [HTML].

`接触~幾何@ （ `contact geometry^en ）

`~digitizer$上で入力された~~地点を囲う矩形域（最も共通的なものは，~touch ）。これは概して、 ~pointer入力の分解能が単独の画素より粗い装置を指す【指先の大きさなど】。この~dataをまったく報告しない装置もある。 ◎ The bounding box of an input (most commonly, touch) on a digitizer. This typically refers to devices with coarser pointer input resolution than a single pixel. Some devices do not report this data at all.

`~digitizer@ （ `digitizer^en ）

物理面に接触-あるいは近接している入力を検出できる型の入力~感知器。最も共通的なものは、 ~touch接触や~penや~stylusからの入力を感知する物理面である。 ◎ A type of input sensing device in which a surface can detect input which is in contact and/or in close proximity. Most commonly, this is the surface that senses input from the touch contact or a pen/stylus.

`直な操作@ （ `direct manipulation^en ／ `direct manipulation interaction^en† ） ◎ direct manipulation

ある種の~UA（~touchscreen装置~上の~browserなど）は、 “直な操作” の~metaphorを実装する — そこでの~pointerは、各種~controlとヤリトリするのみならず，現在の~pageを直に［ ~panする／~zoomする］ためにも利用され、物理的に直に接触しているかのように錯覚させる。例として，~touchscreen装置の利用者は、一般に［手指や~stylusを利用して~pointerを動かすことにより， ~pageを “掴んで” いるかのように~panする］ことで，~pageを直に操作できる。対照的に，定例の［ ~desktop／~laptop ］用の~mouse~pointerでは、 ~panningは~scrollbarを利用して行われる — ~pageを “~dragする” のではなく。 ◎ Certain user agents (such as browsers on a touchscreen device) implement a "direct manipulation" metaphor where a pointer not only interacts with controls, but is also used to directly pan or zoom the current page, providing the illusion of direct physical contact. As an example, users on a touchscreen device are generally able to use a finger or a stylus to "grab" a page and pan it by moving the pointer, directly manipulating the page. Contrast this with a mouse pointer on a regular desktop/laptop, where panning is done by using a scrollbar, rather than by "dragging" the page.

注記： “~dragする” ことにより~scrollすることを利用者に許容する事例には、（~laptop上に見出される様な）~touchpadも挙げられる。しかしながら，これは、一般に［ “捏造な” ~mouse~wheel~eventを生成することにより達成される］ので，直な操作には数えられない。 ◎ Note In some cases, touchpads (like those found on a laptop) will allow the user to scroll by "dragging" on the touchpad. However, this is generally achieved by the touchpad generating "fake" mouse wheel events, so this wouldn't count as a direct manipulation.

【† この訳では、 `direct manipulation interaction^en （`直な操作$によるヤリトリ）も単に “`直な操作$” と略記する — この仕様における`直な操作$は、常に，それによる（~pageとの）ヤリトリを含意するので。

`直な~pan-zoom@ （ `direct manipulation for panning and zooming^en ）

“~pan-zoom用の`直な操作$” の【この訳による】略記。

【 `直な操作$のうち，何が~pan-zoom用とされるかは、 ~UAに委ねられる。】

`接触判定@ （ `hit test^en ）

~UAが `~pointer~event$用の~target要素を決定する処理-。これは概して、 ~pointerの所在, および ~screen媒体~上の文書~内の要素たちの視覚的な~layoutを考慮して決定される。接触判定の仕組みは、この仕様の視野から外れる。 ◎ The process by which the user agent determines a target element for a pointer event. Typically, this is determined by considering the pointer's location and also the visual layout of elements in a document on screen media.

【 `~pointer捕捉$は，この仕組みを上書きする。】

`測定-可能な~prop@ （ `measurable properties^en ）

連続的な~pointer~sensor~dataに関係していて［実数／整数］【！from a large domain】を利用して表出される値を表現する~prop。 `~pointer~event$においては、次に挙げるものが測定-可能な~propとされる ⇒＃ `width$m, `height$m, `pressure$m, `tangentialPressure$m, `tiltX$m, `tiltY$m, `twist$m, `altitudeAngle$m, `azimuthAngle$m, （以下は `UIEVENTS$r に定義される `MouseEvent$I の~prop） `screenX$m, `screenY$m, `clientX$m, `clientY$m ◎ Measurable properties represent values relating to continuous pointer sensor data that is expressed using a real number or an integer from a large domain. For pointer events, width, height, pressure, tangentialPressure, tiltX, tiltY, twist, altitudeAngle, azimuthAngle, and the [UIEVENTS] Mouse Event model properties screenX, screenY, clientX, clientY are measurable properties.

対照的に，次に挙げるものは、 ~sensor~dataには関係しないので，測定-可能な~propとは見なされない ⇒＃ `pointerId$m, `pointerType$m, `isPrimary$m, （以下は `UIEVENTS$r に定義される `MouseEvent$I の~prop） `button$m, `buttons$m, `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m ◎ In contrast pointerId, pointerType, isPrimary, and the [UIEVENTS] Mouse Event model properties button, buttons, ctrlKey, shiftKey, altKey, and metaKey are not considered measurable properties, as they don't relate to sensor data.

`~pointer@ （ `pointer^en ）

~screen上の特定の座標（または座標たちが成す集合）を~targetに捉えられる入力~装置 — ~mouse, ~pen, ~touch接触など — の，~hardwareに不問な表現。 ◎ A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

【上で述べたとおり、この語は，文脈によっては`作動中な~pointer$を意味することもある。】

`~UA@ （ `user agent^en ）

~browserや内容~著作~toolなど，通常は~client~machine上で稼働中の~programであって、利用者に利するよう，内容を［検索取得-／解釈-／実行-／呈示-／作成- ］するものとして動作するもの。 ◎ A program, such as a browser or content authoring tool, normally running on a client machine, which acts on a user's behalf in retrieving, interpreting, executing, presenting, or creating content.

【以下に挙げる用語は、この訳による［補完／明示的な定義／他の各所にある記述の集約］。】

`~event連列@ （ `event sequence^en ）

`作動中な~pointer$から所定の順序で同期的に生じる一連の~event。

`~mouse~event@ （ `Mouse Events^en ）

`UIEVENTS$r にて定義される各種~mouse~eventのうち， `click$et, `dblclick$et を除くものの総称（ `mouseXXX^et ~event — 概ね、 `MouseEvent$I ~interfaceを実装しつつ， `PointerEvent$I など，拡張された~interfaceは実装しない~event）。

`~pointer~event@ （ `Pointer Events^en ）

この仕様にて定義される各種~pointer~eventの総称（ § `click^et ／ `auxclick^et ／ `contextmenu^et ~event による追加を除けば、 `PointerEvent$I ~interfaceを実装する~eventとほぼ同義）。

`~pointing先@ （ `pointing^en 先）

`作動中な~pointer$に対し，`接触判定$により決定される要素 — 無い場合は ~NULL とする。 ~pointing先は、当の~pointerが静止中であっても，`~layout変化＠#boundary-events-caused-by-layout-changes$により変化し得る。

`捕捉~込みの~pointing先@

ある`作動中な~pointer$ %~pointer を捕捉している要素が在る場合、 ~event配送の目的において`~pointing先$になり得るものは，要素の`広義-子孫$に拘束されることもある。すなわち，ある要素 %要素に関して［ ~AND↓ が満たされるならば %要素／ ~ELSE_ %~pointer の`~pointing先$ ］：

%要素 ~EQ %~pointer の`処理待ち捕捉~target$ （すなわち， %要素は %~pointer を`捕捉-$している）
%~pointer の`~pointing先$は、 %要素の`広義-子孫$でない

`境界~event@ （ `boundary event^en ）

`~pointing先$が要素~境界をまたいだときに生じる~eventの総称 — 具体的には，次に挙げるもの ⇒ `pointerover$et, `pointerout$et, `pointerenter$et, `pointerleave$et

接触（ `contact^en ）

`~digitizer$が検出できる程に，物理的に［接触している／近接している］ことを意味する。【！ touch と contact の概念的な相違は、前者には，何らかの~~操作が含意されることにある？】

`~mouse~eventは防止するか@ （ `PREVENT MOUSE EVENT^c ~flag ）

真偽値 — 初期~時は ~F とする。

これは、 ~pointer装置の各~型に結び付けられる。 ~T をとる間は、当の型の~pointer装置からは`互換性~mouse~event$は，生成されなくなる。

謝辞

たくさんの方々からの提案や助言に感謝する。それらの一部は、この文書に組入れられている。次に挙げる，~~現在／~~過去の~group~memberの方々による貢献にも： ◎ Many thanks to lots of people for their proposals and recommendations, some of which are incorporated into this document. The group's Chair acknowledges contributions from the following past and present group members and participants:＼

Mustaq Ahmed, Arthur Barstow, Ben Boyle, Matt Brubeck, Rick Byers, Marcos Cáceres, Cathy Chan, Bo Cupp, Domenic Denicola, Ted Dinklocker, Robert Flack, Dave Fleck, Mike Fraser, Ella Ge, Scott González, Kartikaya Gupta, Dominique Hazael-Massieux, Philippe Le Hégaret, Hayato Ito, Patrick Kettner, Patrick H. Lauke, Scott Low, Sangwhan Moon, Olli Pettay, Alan Pyne, Antoine Quint, Jacob Rossi, Kagami Sascha Rosylight, Doug Schepers, Ming-Chou Shih, Brenton Simpson, Dave Tapuska, Liviu Tinta, Asir Vedamuthu, Lan Wei, Navid Zolghadr

この~modelの最初の版のために先駆的な仕事をされた方々にも特別な謝意を — とりわけ次の方々に： ◎ Special thanks to those that helped pioneer the first edition of this model, including especially:＼

Charu Chandiram, Peter Freiling, Nathan Furtwangler, Thomas Olsen, Matt Rakow, Ramu Ramanathan, Justin Rogers, Jacob Rossi, Reed Townsend and Steve Wright.

改訂~履歴

◎非規範的

`PointerEvents3$r 仕様からの［ ~~主要な, および編集上の~~主な変更点］を以下に要約する（この仕様の編集者草案の `完全な改訂~履歴＠https://github.com/w3c/pointerevents/commits$ を見よ）。 ◎ The following is an informative summary of substantial and major editorial changes between publications of this specification, relative to the [PointerEvents3] specification. See the complete revision history of the Editor's Drafts of this specification.

`PointerEvent$I に `persistentDeviceId$m を追加した。（ `495$pull ） ◎ Add persistentDeviceId to PointerEvent

◎要約

W3C 勧告である Pointer Events は、［ ~mouse, ~pen, ~touchscreen, 等々を含む装置］からの［ ~hardwareに不問な~pointer入力］を取扱うための~eventと関係する各種~interfaceについて述べている。この仕様は、その勧告に見出される特能を拡張する／改変するものである。また、［既存の，~mouseを~~念頭に書かれた内容］との互換性を得るため，［他の型の~pointer装置による~eventから`~mouse~event$を発火するための対応付け］についても述べる。 ◎ The features in this specification extend or modify those found in Pointer Events, a W3C Recommendation that describes events and related interfaces for handling hardware agnostic pointer input from devices including a mouse, pen, touchscreen, etc. For compatibility with existing mouse based content, this specification also describes a mapping to fire Mouse Events for other pointer device types.

1. 序論

2. 適合性

【この訳に特有な表記規約】

3. 例

4. 各種~pointer~eventと各種~interface

4.1. `PointerEvent^I ~interface

4.1.1. ~button状態

4.1.1.1. ~buttonの追加押下げ

4.1.1.2. `button^m 属性

4.1.1.3. `buttons^m 属性

4.1.2. 首~pointer

4.1.3. `PointerEvent^I ~interfaceを利用する~eventの発火-法

4.1.3.1. 各種 属性と既定~動作

4.1.3.2. 処理待ち~pointer捕捉の処理-法

4.1.3.3. ~pointer~event~streamの抑止-法

4.1.4 ~layout変化

4.1.5. ［ `tiltX^m, `tiltY^m ］と［ `altitudeAngle^m, `azimuthAngle^m ］の間の変換-法

4.2. 各種~pointer~event型

4.2.1. `pointerover@et ~event

4.2.2. `pointerenter@et ~event

4.2.3. `pointerdown@et ~event

4.2.4. `pointermove@et ~event

4.2.5. `pointerrawupdate@et ~event

4.2.6. `pointerup@et ~event

4.2.7. `pointercancel@et ~event

4.2.8. `pointerout@et ~event

4.2.9. `pointerleave@et ~event

4.2.10. `gotpointercapture@et ~event

4.2.11. `lostpointercapture@et ~event

4.2.12. `click^et ／ `auxclick^et ／ `contextmenu^et ~event

4.2.12.1. ~event属性

4.2.12.2. ~event座標

4.2.12.3. ~event配送

5. `Element^I ~interfaceに対する拡張

6. `GlobalEventHandlers^I ~mixinに対する拡張

7. `Navigator^I ~interfaceに対する拡張

8. 直な操作の挙動の宣言-法

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

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

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

9. ~pointer捕捉

9.1. 序論

9.2. ~pointer捕捉の設定-法

9.3. ~pointer捕捉の解放-法

9.4. 暗黙的な~pointer捕捉

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

10. 合体された~event群と予測された~event群

10.1. 合体された~event群

10.2. 予測された~event群

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

11. ~mouse~eventとの互換性を得るための対応付け

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

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

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

~security／~privacyの考慮点

用語集

謝辞

改訂~履歴

4.1.3.1. 各種属性と既定~動作