UI Events

1.1.1. ~mouse~event, ~wheel~event

この仕様を成していた［ § ~mouse~event, § ~wheel~event ］は、 `POINTEREVENTS4$r へ移動された。 ◎ The Mouse Events and Wheel Events section of this specification have been moved to the Pointer Events specification [pointerevents4].

3.2.1. `UIEvent^I ~interface

DOM Level 2 にて導入された。 ◎ Introduced in DOM Level 2

`UIEvent^I ~interfaceは、 ~UI~eventに特有な文脈l情報を供する。 ◎ The UIEvent interface provides specific contextual information associated with User Interface events.

`UIEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `UIEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the UIEvent interface, use the UIEvent constructor, passing an optional UIEventInit dictionary.

注記： 新たに定義される~eventは、 単に~UIに関係するだけで， `UIEvent$I ~interfaceを継承する必要はない。 `UIEventInit$I の~memberのみ継承することでも，イミを成す。 ◎ For newly defined events, you don’t have to inherit UIEvent interface just because they are related to user interface. Inherit only when members of UIEventInit make sense to those events.

[`Exposed$=Window]
interface `UIEvent@I : `Event$I {
    `UIEvent@mc(`DOMString$ %type, optional `UIEventInit$I %eventInitDict = {});

    readonly attribute `Window$I? `view$m;
    readonly attribute `long$ `detail$m;
};

dictionary `UIEventInit@I : `EventInit$I {
    `Window$I? `view$m = null;
    `long$ `detail$m = 0;
};

3.2.2. `UIEvent^I 用の~algo

3.2.3. 各種~UI~event型

以下に，各種~UI~event型を挙げる。 これらの~eventのうち一部のものは、［ ~UIから生成されるときは `UIEvent$I ／ 他のときは `Event$I ］~interfaceを利用する。 詳細は各~eventに。 ◎ The User Interface event types are listed below. Some of these events use the UIEvent interface if generated from a user interface, but the Event interface otherwise, as detailed in each event.

各種~UI~eventに共通な文脈~情報

多くの~UI~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：

`UIEvent!I ：

`view$m

`Window$I ~obj ◎ UIEvent.view : Window

`detail$m

0 ◎ UIEvent.detail : 0

3.3.1. `FocusEvent^I ~interface

この仕様にて導入された。 ◎ Introduced in this specification

`FocusEvent^I ~interfaceは、 ~focus~eventに特有な文脈l情報を供する。 ◎ The FocusEvent interface provides specific contextual information associated with Focus events.

`FocusEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `FocusEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the FocusEvent interface, use the FocusEvent constructor, passing an optional FocusEventInit dictionary.

[`Exposed$=Window]
interface `FocusEvent@I : `UIEvent$I {
    `FocusEvent@mc(`DOMString$ %type, optional `FocusEventInit$I %eventInitDict = {});
    readonly attribute `EventTarget$I? `relatedTarget$m;
};

dictionary `FocusEventInit@I : `UIEventInit$I {
    `EventTarget$I? `relatedTarget@m = null;
};

3.3.2. ~focus~event序列

この仕様にて定義される~focus~eventは、 相互相対順序の下で生じる。 被focus要素が無い状態から要素 %A, 要素 %B の順に~focusが移転されたときの代表的な~event連列を次に示す： ◎ The focus events defined in this specification occur in a set order relative to one another. The following is the typical sequence of events when a focus is shifted between elements (this order assumes that no element is initially focused):

注記： この仕様は、 `focus()^m や `blur()^m などの~methodに際しての~focus~eventの挙動は定義しない。 そのような挙動については、 それらの~methodを定義している，関連な仕様を見よ。 ◎ This specification does not define the behavior of focus events when interacting with methods such as focus() or blur(). See the relevant specifications where those methods are defined for such behavior.

3.3.3. 文書~focusと~focus文脈

この~event~moduleは、 文書`~focus$の変化を通知するための~event型を含む。 この論点に関連な，3 種の別個な~focus文脈がある： ◎ This event module includes event types for notification of changes in document focus. There are three distinct focus contexts that are relevant to this discussion:

• ~OS~focus文脈 ⇒ この文脈の下では、 ~computer上で現在~稼働している多数の~appのうち一つが，~focusを持ち得るとされる。 ~browserは、 その一つを成し得る。 ◎ The operating system focus context which MAY be on one of many different applications currently running on the computer. One of these applications with focus can be a browser.
• ~app~focus文脈 ⇒ ~browserが~focusを得ているときが，この文脈である。 この文脈の下では、 利用者は、 ~browserの各種~UI~field （例： ~URL~bar, 探索~field, 等々） 間で~focusを切替えることもある （~tab~UIkeyなどにより）。 ~UItab内に示されている文書も、 これらの~UI~fieldの一つを成し得る。 ◎ When the browser has focus, the user can switch (such as with the tab key) the application focus context among the different browser user interface fields (e.g., the Web site location bar, a search field, etc.). One of these user interface fields can be the document being shown in a tab.
• 文書~focus文脈 ⇒ 文書~自身が~focusを得ているときが、 この文脈である。 この文脈の下では、 文書~内で~focus可能な要素が~focusを得ることができる。 ◎ When the document itself has focus, the document focus context can be set to any of the focusable elements in the document.

この仕様にて定義される各種~event型は、 もっぱら文書~focusのみを対象にする。 ~eventの詳細~にて識別される`~target$は、 ~window内の文書またその一部に限るモノトスル — ~focus文脈が別の文脈へ切替わったときでも，決して ~browserや~OSの一部にはならない。 ◎ The event types defined in this specification deal exclusively with document focus, and the event target identified in the event details MUST only be part of the document or documents in the window, never a part of the browser or operating system, even when switching from one focus context to another.

3.3.4. 各種~focus~event型

以下に，各種~focus~event型を挙げる： ◎ The Focus event types are listed below.

3.4.1. `InputEvent^I ~interface

[`Exposed$=Window]
interface `InputEvent@I : `UIEvent$I {
    `InputEvent@mc(`DOMString$ %type, optional `InputEventInit$I %eventInitDict = {});
    readonly attribute `USVString$? `data$m;
    readonly attribute `boolean$ `isComposing$m;
    readonly attribute `DOMString$ `inputType$m;
};

dictionary `InputEventInit@I : `UIEventInit$I {
    `DOMString$? `data@m = null;
    `boolean$ `isComposing@m = false;
    `DOMString$ `inputType@m = "";
};

3.4.2. 入力~event序列

この仕様にて定義される入力~eventは、 相互相対順序の下で生じるモノトスル。 ◎ The input events defined in this specification MUST occur in a set order relative to one another.

3.4.3. 各種~入力~event型

各種~入力~eventに共通な文脈~情報

各種~入力~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：

`target$m

更新されつつある／された`~event~target$。 ◎ event target that [ is about to be / was just ] updated

`UIEvent!I の各~属性：

`§ 各種~UI~eventに共通な文脈~情報$を見よ。

`InputEvent!I ：

`data$m

要素に追加された／されることになる~dataを包含する文字列。 内容が削除されることになる／された場合には、 ~eventの型に応じて，`空~文字列$または~NULLにされてもヨイ。 ◎ InputEvent.data : the string containing the data that [ has been | will be ] added to the element, which MAY be [ the empty string | null ] if the content [ will be | has been ] deleted

`isComposing$m

この~eventが`~dead-key＠#keys-dead$連列, または `~IME$が作動中な間に配送されたものであれば ~T （`組成~event$が配送されているときなど） ／ ~ELSE_ ~F ◎ InputEvent.isComposing : true if this event is dispatched during a dead key sequence or while an input method editor is active (such that composition events are being dispatched); false otherwise.

3.5.1. `KeyboardEvent^I ~interface

この仕様にて導入された。 ◎ Introduced in this specification

`KeyboardEvent!I ~interfaceは、 ~keyboard装置に特有な文脈l情報を供する。 各~keyboard~eventは、 値を利用して~UIkeyを参照する。 ~keyboard~eventは、 共通して，~focusを得ている要素へ向けられることが多い。 ◎ The KeyboardEvent interface provides specific contextual information associated with keyboard devices. Each keyboard event references a key using a value. Keyboard events are commonly directed at the element that has the focus.

`KeyboardEvent$I ~interfaceは、 一部の共通的な修飾~UIkey用の簡便な属性：［ `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m ］を供する。 これらの属性【への取得~access】は、 順に，［ `Control$kY, `Shift$kY, `Alt$kY, `Meta$kY ］を引数に `getModifierState()$m ~methodを利用するのと等価である。 ◎ The KeyboardEvent interface provides convenient attributes for some common modifiers keys: ctrlKey, shiftKey, altKey, metaKey. These attributes are equivalent to using the method getModifierState() with Control, Shift, Alt, or Meta respectively.

`KeyboardEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `KeyboardEventInit$I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the KeyboardEvent interface, use the KeyboardEvent constructor, passing an optional KeyboardEventInit dictionary.

[`Exposed$=Window]
interface `KeyboardEvent@I : `UIEvent$I {
    `KeyboardEvent@mc(`DOMString$ %type, optional `KeyboardEventInit$I %eventInitDict = {});

    // `location$m 属性がとり得る定数
    const `unsigned long$ `DOM_KEY_LOCATION_STANDARD$m = 0x00;
    const `unsigned long$ `DOM_KEY_LOCATION_LEFT$m = 0x01;
    const `unsigned long$ `DOM_KEY_LOCATION_RIGHT$m = 0x02;
    const `unsigned long$ `DOM_KEY_LOCATION_NUMPAD$m = 0x03;

    readonly attribute `DOMString$ `key$m;
    readonly attribute `DOMString$ `code$m;
    readonly attribute `unsigned long$ `location$m;

    readonly attribute `boolean$ `ctrlKey$m;
    readonly attribute `boolean$ `shiftKey$m;
    readonly attribute `boolean$ `altKey$m;
    readonly attribute `boolean$ `metaKey$m;

    readonly attribute `boolean$ `repeat$m;
    readonly attribute `boolean$ `isComposing$m;

    `boolean$ `getModifierState$m(`DOMString$ %keyArg);
};

dictionary `KeyboardEventInit@I : `EventModifierInit$I {
    `DOMString$ `key@m = "";
    `DOMString$ `code@m = "";
    `unsigned long$ `location@m = 0;
    `boolean$ `repeat@m = false;
    `boolean$ `isComposing@m = false;
};

注記： 既存の内容との互換性のため，~virtual~keyboard — ~screenに基づく入力~装置~上の~software~keyboardなど — は、［ 物理的~UIkeyを処理しなくとも，通常の範囲の~keyboard~eventを生産する ］ものと期待されている。 ◎ For compatibility with existing content, virtual keyboards, such as software keyboards on screen-based input devices, are expected to produce the normal range of keyboard events, even though they do not possess physical keys.

注記： 一部の実装／~system環境設定においては、 一部の~UIkey~eventやその値は，利用-中にある`~IME$により抑止されることがある。 ◎ In some implementations or system configurations, some key events, or their values, might be suppressed by the IME in use.

3.5.2. ~keyboard~eventに対する~UIkeyの所在

`location$m 属性は、 ~keyboard上の異なる物理的~UIkeyから同じ`~UIkey値$が生成される場合に， それらを~~区別するために利用できる。 例えば、 左右 `Shift^cap ~UIkey，あるいは 物理的~矢印~UIkeyと（ `NumLock^cap が off のときの）~numpad上の矢印~UIkey。 ◎ The location attribute can be used to disambiguate between key values that can be generated by different physical keys on the keyboard, for example, the left and right Shift key or the physical arrow keys vs. the numpad arrow keys (when NumLock is off).

~keyboard上に所在が複数あるような特別な~UIkey用の，妥当な `location$m 値は、 次の表tに定義される： ◎ The following table defines the valid location values for the special keys that have more than one location on the keyboard:

この表tに挙げられていない他のすべての~UIkey用の `location$m 属性は、 常に `DOM_KEY_LOCATION_STANDARD$m に設定するモノトスル。 ◎ For all other keys not listed in this table, the location attribute MUST always be set to DOM_KEY_LOCATION_STANDARD.

3.5.3. ~eventの~UIkey修飾~初期化子

［ `MouseEvent$I, `KeyboardEvent$I ］~interfaceは、 各種~keyboard修飾~属性を共有し， 追加的な修飾~状態を検索取得するための仕組みを~supportする。 `EventModifierInit$I 辞書は、 作者が［ これらの~interfaceの各種~keyboard修飾~属性 ］および［［ 前者の `getModifierState()＠~POINTEREVENTS#dom-mouseevent-getmodifierstate$m ／ 後者の `KeyboardEvent.getModifierState()$m ］を介して~queryされる追加的な修飾~状態 ］を初期化することを可能化する。 この辞書を利用して~mouse~eventを構築する手続きは、 `POINTEREVENTS4$r にて定義される†。 ◎ The MouseEvent and KeyboardEvent interfaces share a set of keyboard modifier attributes and support a mechanism for retrieving additional modifier states. The following dictionary enables authors to initialize keyboard modifier attributes of the MouseEvent and KeyboardEvent interfaces, as well as the additional modifier states queried via getModifierState(). The steps for constructing mouse events using this dictionary are defined in the [pointerevents4] specification.

【† `§ ~mouse~eventの構築-法＠~POINTEREVENTS#constructing-mouse-events$ — それは、 元々はこの仕様にて定義されたたものであり， そこに述べられる処理nは `KeyboardEvent$I を構築する際にも適用されるべきであろう （そこで `MouseEvent$I 用に定義される`内部~UIkey修飾~状態$は、 `KeyboardEvent$I 用にも定義されるものと見なすべきである）。 】

dictionary `EventModifierInit@I : `UIEventInit$I {
    `boolean$ `ctrlKey$m = false;
    `boolean$ `shiftKey$m = false;
    `boolean$ `altKey$m = false;
    `boolean$ `metaKey$m = false;

    `boolean$ `modifierAltGraph$m = false;
    `boolean$ `modifierCapsLock$m = false;
    `boolean$ `modifierFn$m = false;
    `boolean$ `modifierFnLock$m = false;
    `boolean$ `modifierHyper$m = false;
    `boolean$ `modifierNumLock$m = false;
    `boolean$ `modifierScrollLock$m = false;
    `boolean$ `modifierSuper$m = false;
    `boolean$ `modifierSymbol$m = false;
    `boolean$ `modifierSymbolLock$m = false;
};

3.5.4. `KeyboardEvent^I 用の~algo

3.5.5. ~keyboard~event序列

この仕様にて定義される~keyboard~eventは、 与えられたどの~UIkeyに対しても，相互相対順序の下で生じる： ◎ The keyboard events defined in this specification occur in a set order relative to one another, for any given key:

一定時間，~UIkeyが押下げられた場合、 環境に依存する~rateで，次の~eventが繰返されてもヨイ： ◎ If the key is depressed for a sustained period, the following events MAY repeat at an environment-dependent rate:

注記： 概して、 特定0の~UIkeyに結付けられた`既定~動作$があれば， `keyup$et ~eventが発火される前に完了する。 これは `keyup$et ~eventを少しばかり遅延し得る （おそらく，知覚される程の遅延にはならないであろうが）。 ◎ Typically, any default actions associated with any particular key are completed before the keyup event is dispatched. This might delay the keyup event slightly (though this is not likely to be a perceptible delay).

~UIkey~eventの`~target$は、 ~keyboard活動を処理している現在の被focus要素である。 これは、［ ~HTML `input^e 要素／編集-可能な~textな要素 ］になることが多いが、 `~host言語$における非~text目的の~keyboard入力 — 加速~UIkeyの作動化や 一部の他の挙動の誘発など — を受容するように定義された要素になることもある。 相応しい被focus要素が無い場合の~event~targetは、［ 可用なら~HTML`~body要素$ ／ 他の場合は`根~要素$ ］になる。 ◎ The event target of a key event is the currently focused element which is processing the keyboard activity. This is often an HTML input element or a textual element which is editable, but MAY be an element defined by the host language to accept keyboard input for non-text purposes, such as the activation of an accelerator key or trigger of some other behavior. If no suitable element is in focus, the event target will be the HTML body element if available, otherwise the root element.

注記： `~event~target$は、 一連の~UIkey~event間で変化し得る。 例えば， `Tab^cap ~UIkey用の `keydown$et ~eventの`~target$は、 同じ~keystroke用の `keyup$et ~eventと異なるであろう。 ◎ The event target might change between different key events. For example, a keydown event for the Tab key will likely have a different event target than the keyup event on the same keystroke.

3.5.6. 各種~keyboard~event型

各種~keyboard~eventに共通な文脈~情報

~keyboard~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：

`target$m

~UIkey~eventを処理している被focus要素。 被focus要素がない場合、 可用ならば`~body要素$ ／ 他の場合 `根~要素$ ◎ Event.target : focused element processing the key event or if no element focused, then the body element if available, otherwise the root element

`UIEvent!I の各~属性：

`§ 各種~UI~eventに共通な文脈~情報$を見よ。

`KeyboardEvent!I ：

`key$m

押された~UIkeyの`~UIkey値$。 ◎ KeyboardEvent.key : the key value of the key pressed.

`code$m

~UIkeyの~keyboard上での物理的~~位置に結付けられた~code値 ◎ KeyboardEvent.code : the code value associated with the key’s physical placement on the keyboard.

`location$m

装置~上の~UIkeyの所在。 ◎ KeyboardEvent.location : the location of the key on the device.

`altKey$m

`Alt^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.altKey : true if Alt modifier was active, otherwise false

`shiftKey$m

`Shift^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.shiftKey : true if Shift modifier was active, otherwise false

`ctrlKey$m

`Control^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.ctrlKey : true if Control modifier was active, otherwise false

`metaKey$m

`Meta^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.metaKey : true if Meta modifier was active, otherwise false

`repeat$m

~UIkeyの繰返nを誘発するに十分~長く~UIkeyが押下げられているならば ~T ／ 他の場合 ~F ◎ KeyboardEvent.repeat : true if a key has been depressed long enough to trigger key repetition, otherwise false

`isComposing$m

~UIkey~eventが，組成~sessionの一部として生じたならば ~T ／ 他の場合 ~F ◎ KeyboardEvent.isComposing : true if the key event occurs as part of a composition session, otherwise false

3.6.1. `CompositionEvent^I ~interface

この仕様にて導入された。 ◎ Introduced in this specification

`CompositionEvent^I ~interfaceは、 `組成~event$に特有な文脈l情報を供する。 ◎ The CompositionEvent interface provides specific contextual information associated with Composition Events.

`CompositionEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `CompositionEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the CompositionEvent interface, use the CompositionEvent constructor, passing an optional CompositionEventInit dictionary.

[`Exposed$=Window]
interface `CompositionEvent@I : `UIEvent$I {
    `CompositionEvent@mc(`DOMString$ %type, optional `CompositionEventInit$I %eventInitDict = {});
    readonly attribute `USVString$ `data$m;
};

dictionary `CompositionEventInit@I : `UIEventInit$I {
    `DOMString$ `data@m = "";
};

3.6.2. 組成~event序列

この仕様にて定義される`組成~event$は、 次による相互相対順序の下で生じるモノトスル： ◎ The Composition Events defined in this specification MUST occur in the following set order relative to one another:

3.6.3. 手書き認識~system

次の例に、［ ~pen~tabletなどの手書き認識~systemの下で，一節の~text "text" を組成する ］ときにアリな~event連列を，`組成~event$の~modelを利用して述べる。 ◎ The following example describes a possible sequence of events when composing a text passage "text" with a handwriting recognition system, such as on a pen tablet, as modeled using Composition Events.

3.6.4. 組成~eventの取消~法

`keydown$et ~eventが取消された場合、 その `keydown$et の結果として発火されることになる どの`組成~event$も，発火されるベキでない： ◎ If a keydown event is canceled then any Composition Events that would have fired as a result of that keydown SHOULD not be dispatched:

初期 `compositionstart$et ~eventが取消された場合、 ~text組成~sessionは，終了されるベキである。 `compositionend$et ~eventは、 組成~sessionが終了されたかどうかに関わらず，送信するモノトスル。 ◎ If the initial compositionstart event is canceled then the text composition session SHOULD be terminated. Regardless of whether or not the composition session is terminated, the compositionend event MUST be sent.

3.6.5. 組成~時における~UIkey~event

組成~sessionの最中でも、 依然として［ `keydown$et, `keyup$et ］~eventは送信するモノトスル — その `KeyboardEvent.isComposing$m 属性は ~T になるモノトスル。 ◎ During the composition session, keydown and keyup events MUST still be sent, and these events MUST have the isComposing attribute set to true.

3.6.6. 組成~sessionの間の入力~event

組成~sessionの間は、 その `compositionupdate$et は， `beforeinput$et が送信された後, かつ `input$et が送信される前に発火するモノトスル。 ◎ During the composition session, the compositionupdate MUST be dispatched after the beforeinput is sent, but before the input event is sent.

注記： ほとんどの~IMEは、 組成~sessionの間における更新の取消~法は~supportしない。 ◎ Most IMEs do not support canceling updates during a composition session.

［ `beforeinput$et ／ `input$et ］~eventは、 組成の一部として~DOMが更新されるときに， `compositionupdate$et ~eventに伴って送信される。 `compositionend$et ~eventに対しては，~DOMの更新はないので、［ `beforeinput$et ／ `input$et ］~eventは送信されるべきではない。 ◎ The beforeinput and input events are sent along with the compositionupdate event whenever the DOM is updated as part of the composition. Since there are no DOM updates associated with the compositionend event, beforeinput and input events should not be sent at that time.

3.6.7. 各種~組成~event型

各種~組成~eventに共通な文脈~情報

多くの組成~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：

`target$m

組成を処理している被focus要素。 ~access可能でないならば~NULL。 ◎ Event.target : focused element processing the composition, null if not accessible

`UIEvent!I の各~属性：

`§ 各種~UI~eventに共通な文脈~情報$を見よ。

4.1.1. ~UIkey銘

~UIkey銘（ `key legend^en ）とは、 その `~UIkey~cap^em （~UIkeyの物理的0な~switchを覆う “~cap” ） 上に印刷されたり, 彫り込まれている，視覚的な目印である。 この種の目印は、 通常は，その~UIkeyに対する~keystrokeが生産するような 1 個~以上の文字からなる（例： `G^kGl, `8^kGl, `ш^kGl ）, あるいは その~UIkeyの機能を指示する名前や記号 （例： `Shift^cap を指示する上向き矢印 `⇧^kGl, 文字列 "Enter" など）。 ~UIkeyは、 この目印で指されることが多い （例： “ Shift ＋ F ~UIkeyを押してください。” ）。 しかしながら、 ~UIkeyの視覚的な見かけは，その~digital表現とは~~関係ないものであり、 多くの環境設定で，まったく正確aでないものにもなり得る。 `Enter^cap などの［ 制御~UIkey／~function~UIkey ］であっても，［ 機能性が異なるものや文字~UIkey ］に対応付けられることすら あり得る。 ◎ The key legend is the visual marking that is printed or embossed on the key cap (the rectangular "cap" that covers the mechanical switch for the key). These markings normally consist of one or more characters that a keystroke on that key will produce (such as "G", "8", or "ш"), or names or symbols which indicate that key’s function (such as an upward-pointing arrow "⇧" indicating Shift, or the string "Enter"). Keys are often referred to by this marking (e.g., "Press the "Shift" and "G" keys."). Note, however, that the visual appearance of the key has no bearing on its digital representation, and in many configurations may be completely inaccurate. Even the control and function keys, such as Enter, may be mapped to different functionality, or even mapped as character keys.

注記： 多くの~keyboardは、 ~Unicode等価な記号があっても，通常は文字を生産しない~UIkeyを備えている。 例えば， `Shift^cap ~UIkeyには、 記号 `⇧^kGl （~Unicode符号位置 `21E7^U ）が付けられることもあるが， `Shift^cap ~UIkeyだけ押しても この`文字~値$を生産することはないし, `Shift^cap に対応する~Unicode符号位置もない。 ◎ Many keyboards contain keys that do not normally produce any characters, even though the symbol might have a Unicode equivalent. For example, the Shift key might bear the symbol "⇧", which has the Unicode code point U+21E7, but pressing the Shift key will not produce this character value, and there is no Unicode code point for Shift.

4.2.1. `code^m 属性の動機

標準的な~PC~keyboardが備えている一群の~UIkeyが生成する `key$m 値は、 利用者が現在~選択している（利用している書記体系に適切な）~keyboard~layoutにより異なる。 このような状況では、 ~UIkeyをその物理的~所在に基づいて検出するような~codeを書くことは困難になる — ~codeが，どの `key^m 値を検査すればよいか知るためには、 現在~有効な~layoutがどれなのかを知る必要があるので。 現実の例として、 ~playerの動きを制御するために［ `W^kGl, `A^kGl, `S^kGl, `D^kGl ］~UIkeyを利用する~gameがある。 `code$m 属性は、 それを検査するための，`現在の~keyboard~layoutに影響されない^em, 安定的な値を供して、 この問題を解消する。 ◎ The standard PC keyboard has a set of keys (which we refer to as writing system keys) that generate different key values based on the current keyboard layout selected by the user. This situation makes it difficult to write code that detects keys based on their physical location since the code would need to know which layout is in effect in order to know which key values to check for. A real-world example of this is a game that wants to use the "W", "A", "S" and "D" keys to control player movement. The code attribute solves this problem by providing a stable value to check that is not affected by the current keyboard layout.

加えて、 `key$m 属性がとる値は，現在の~keyboard状態にも依存する。 このため、 修飾~UIkeyと他の~UIkeyが［ 押される／離される ］順序も， `key$m 属性に格納される値に影響し得る。 `code$m 属性は、 `現在の~keyboard~layoutに影響されない^em, 安定的な値を供して、 この問題を解消する。 ◎ In addition, the values in the key attribute depend as well on the current keyboard state. Because of this, the order in which keys are pressed and released in relation to modifier keys can affect the values stored in the key attribute. The code attribute solves this problem by providing a stable value that is not affected by the current keyboard state.

4.2.2. `key^m と `code^m の関係性

`key^m

`key$m 属性に意図されている用途は、 押されている~UIkeyの意味に基づくふるまいを得ることである — その値には、 現在の~keyboard~layoutに加えて，~IMEも織り込まれる （`~dead-key＠#keys-dead$ には，一意な `key^m 値が与えられる）。 例えば、［ ~UIkeyが修飾~UIkeyを伴うかどうかや ~~素の修飾~UIkey ］を検出する利用事例がある （例：~keyboard~shortcutに呼応して何らかの動作を遂行するためなど）。 ◎ The key attribute is intended for users who are interested in the meaning of the key being pressed, taking into account the current keyboard layout (and IME; dead keys are given a unique key value). Example use case: Detecting modified keys or bare modifier keys (e.g., to perform an action in response to a keyboard shortcut).

`code^m

`code$m 属性に意図されている用途は、 利用者により押された~UIkeyそのもの — ~keyboard~layoutにより改変されないままの~UIkey — に基づくふるまいを得ることである。 例えば、 ~gameにおける動き制御~用に［ `W^cap, `A^cap, `S^cap, `D^cap ］~UIkeyを検出したり、 すべての~UIkeyを~trapする （例： すべての~UIkeyを~remote~hostに送信する~remote~desktop~client） などの利用事例がある。 ◎ The code attribute is intended for users who are interested in the key that was pressed by the user, without any layout modifications applied. Example use case: Detecting WASD keys (e.g., for movement controls in a game) or trapping all keys (e.g., in a remote desktop client to send all keys to the remote host).

4.2.3. ~code例

4.2.4. `code^m と~virtual~keyboard

`code$m 属性の有用性は、 ~virtual~keyboardに対しては明白でない （~remote-control~keyboardや複数~UIkeyの同時押下げに対しても）。 ~virtual（または~remote-control）~keyboardに対しては、 標準的な~keyboardの ~layout／機能性 を真似ているものについては， `code$m 属性を適切に設定するモノトスル。 真似ていない~keyboardについては、 標準的な~keyboardになるべく近いものに設定するか, または 未定義なままにしてもヨイ。 ◎ The usefulness of the code attribute is less obvious for virtual keyboards (and also for remote controls and chording keyboards). In general, if a virtual (or remote control) keyboard is mimicking the layout and functionality of a standard keyboard, then it MUST also set the code attribute as appropriate. For keyboards which are not mimicking the layout of a standard keyboard, then the code attribute MAY be set to the closest match on a standard keyboard or it MAY be left undefined.

修飾~状態に基づいて異なる値を生産する~UIkeyを伴うような~virtual~keyboardに対しては、 `code^m 値は，［ 装置がその工場出荷~状態にある下で~buttonが押された ］ときに生成される `key^m 値になるベキである。 ◎ For virtual keyboards with keys that produce different values based on some modifier state, the code value should be the key value generated when the button is pressed while the device is in its factory-reset state.

4.3.1. 修飾~UIkey

修飾~UIkeyを利用する~keyboard入力は、 ~UIkeyの通常の挙動を変化させる。 他の~UIkeyと同様、 修飾~UIkeyは，下の例に示すとおり［ `keydown$et ／ `keyup$et ］~eventを生成する。 修飾~UIkeyには、 押されている間 作動化されるものもあれば （ `Alt^cap, `Control^cap, `Shift^cap, `AltGraph^cap, `Meta^cap など）、 状態を持ち，その状態に依存して作動化されるものもある （ `CapsLock^cap, `NumLock^cap, `ScrollLock^cap など）。 状態の変化は、 修飾~UIkeyが押されたときに起こる。 `KeyboardEvent!I ~interfaceは、 一部の共通的な修飾~UIkeyに対し，簡便な属性 — `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m — を供する。 一部の~OSは、 修飾~UIkey `AltGraph^cap を，修飾~UIkey `Alt^cap, `Control^cap の組合nで模倣する。 実装には、 `AltGraph^cap 修飾~UIkeyを利用することが奨励される。 ◎ Keyboard input uses modifier keys to change the normal behavior of a key. Like other keys, modifier keys generate keydown and keyup events, as shown in the example below. Some modifiers are activated while the key is being pressed down or maintained pressed such as Alt, Control, Shift, AltGraph, or Meta. Other modifiers are activated depending on their state such as CapsLock, NumLock, or ScrollLock. Change in the state happens when the modifier key is being pressed down. The KeyboardEvent interface provides convenient attributes for some common modifiers keys: ctrlKey, shiftKey, altKey, metaKey. Some operating systems simulate the AltGraph modifier key with the combination of the Alt and Control modifier keys. Implementations are encouraged to use the AltGraph modifier key.

次の例に、 ~US~keyboardで, ~US用の`~UIkey対応付け$を利用している下で， ~Unicode文字 Q（ `0051^U `Latin Capital Letter Q^cn ） が生成されるときにアリな~event連列を述べる： ◎ This example describes a possible sequence of events associated with the generation of the Unicode character Q (Latin Capital Letter Q, Unicode code point U+0051) on a US keyboard using a US mapping:

次の例に、 上の例において， `Q^cap ~UIkeyを離す前に `Shift^cap ~UIkeyを離したとき， 代わりに生じ得る~UIkey連列を述べる。 ~UIkey `Q^cap 用の`~UIkey値$は、 `keyup$et ~eventに対しては，その無shift値に復帰することになる： ◎ Th example describes an alternate sequence of keys to the example above, where the Shift key is released before the Q key. The key value for the Q key will revert to its unshifted value for the keyup event:

次の例に、 ~Unicode文字を生成しないときにアリな~UIkeyの連列を述べる （前の例と同じ環境設定の下で）: ◎ The following example describes a possible sequence of keys that does not generate a Unicode character (using the same configuration as the previous example):

次の例に， `Shift^cap, `Control^cap が両者とも押されたときの~event連列を示す： ◎ The following example shows the sequence of events when both Shift and Control are pressed:

非~US~keyboard~layoutに対しても，~event連列は同じになるが、 ~UIkeyの値は，現在の~keyboard~layoutに基づく。 次の例に，~Arabic~keyboard~layoutが利用されるときの~event連列を示す： ◎ For non-US keyboard layouts, the sequence of events is the same, but the value of the key is based on the current keyboard layout. This example shows a sequence of events when an Arabic keyboard layout is used:

注記： ［ `keydown$et ／ `keyup$et ］~eventにおける値は、 ~UIkeyが押されたときに有効な現在の~keyboard~layoutに基づいて，様々になる。 これは、 同じ物理的~UIkeyであっても、 ~US~layout上の `v^cap ~UIkey と ~Arabic~layout上の `ر^cap ~UIkeyとでは， 異なる~eventを生成することを意味する。 これらの~eventを同じ物理的~UIkeyとして識別するためには、 `code$m 属性を利用する必要がある。 ◎ The value in the keydown and keyup events varies based on the current keyboard layout in effect when the key is pressed. This means that the v key on a US layout and the ر key on an Arabic layout will generate different events even though they are the same physical key. To identify these events as coming from the same physical key, you will need to make use of the code attribute.

修飾~UIkeyが，~UIkey~event用の`~UIkey値$を変化させる事例もある。 例えば，一部の MacOS ~keyboard上の “delete” ~UIkeyは、 未修飾~時にはWindows ~OS上の `Backspace^cap ~UIkeyと同じに機能するが、 `Fn^cap ~UIkeyで修飾されたときは `Delete^cap ~UIkeyとして動作し， ~UIkey値は 現在の修飾された状態に最も適切な~UIkeyの機能に合致することになる。 ◎ In some cases, modifier keys change the key value for a key event. For example, on some MacOS keyboards, the key labeled "delete" functions the same as the Backspace key on the Windows OS when unmodified, but when modified by the Fn key, acts as the Delete key, and the value of key will match the most appropriate function of the key in its current modified state.

4.3.2. ~dead-key

~keyboard入力では、 `~dead-key$を利用して組成-済み文字~連列を入力することもある。 手書き式に最初に基底~文字を手入力するのでなく、 そこでの~keyboard入力には，特別な状態に入ることが要求され、 `~dead-key$が押された~~直後では，限られた数の “合法な” 基底~文字が手入力されたときに限り，文字（たち）を発する。 ◎ Some keyboard input uses dead keys for the input of composed character sequences. Unlike the handwriting sequence, in which users enter the base character first, keyboard input requires to enter a special state when a dead key is pressed and emit the character(s) only when one of a limited number of "legal" base character is entered.

注記： ［ MacOS ／ Linux ~OS ］は、 `~dead-key$を処理するときに~IMEを利用する。 ◎ The MacOS and Linux operating systems use input methods to process dead keys.

`~dead-key$は、 （すべての~keyboard~layout, `~UIkey対応付け$に渡り，） `~UIkey値$ `Dead$kY で表現される。 ~dead-keyが押されたときは、 ~UAは それに呼応して，`組成~event$たちを発火するモノトスル。 加えて、 その `compositionupdate$et ~eventの `CompositionEvent.data$m 値は，~dead-key結合~連列の現在の状態の`文字~値$になるモノトスル。 ◎ The dead keys (across all keyboard layouts and mappings) are represented by the key value Dead. In response to any dead key press, composition events must be dispatched by the user agent and the compositionupdate event’s data value must be the character value of the current state of the dead key combining sequence.

~Unicode結合~文字は，常に［ 対応する普通字とそれに続く結合~文字による手書き連列 ］に倣う一方で、 代表的な~dead-key入力では，その結合~文字が対応する普通字の前に来るように連列を逆順にすることもある。 例えば，単語 "naïve" は、 結合~発音区別符 "¨" を利用して，~Unicodeでは "nai¨ve" として連列的に表現されるが、 "na¨ive" と打込まれ得る。 ~keystroke連列［ `0302^U （ `Combining Circumflex Accent^cn ~UIkey）, `0065^U （ `Latin Small Letter E^cn と印字される~UIkey） ］は，［ `NFC^em （ `Unicode Normalization Form^en ）に選好される ~Unicode文字 `ê^kGl （ `Latin Small Letter E With Circumflex^cn ） ］を生産するであろう （~French~keyboardでは、 修飾~UIkeyを作動化させずに，~French用の`~UIkey対応付け$を利用して）。 ◎ While Unicode combining characters always follow the handwriting sequence, with the combining character trailing the corresponding letter, typical dead key input MAY reverse the sequence, with the combining character before the corresponding letter. For example, the word naïve, using the combining diacritic ¨, would be represented sequentially in Unicode as nai¨ve, but MAY be typed na¨ive. The sequence of keystrokes U+0302 (Combining Circumflex Accent key) and U+0065 (key marked with the Latin Small Letter E) will likely produce (on a French keyboard using a french mapping and without any modifier activated) the Unicode character "ê" (Latin Small Letter E With Circumflex), as preferred by the Unicode Normalization Form NFC.

注記： 2 個目の `keydown^c ~event（段 5）では、 （~eventは抑止されていないとするとき，） 通常の状況下では`~UIkey値$ `e^kY （ `Latin Small Letter E^cn ~UIkey）`にはならない^em — ~UAに送達される値は、 すでに~dead-key操作oにより修飾されることになるので。 ◎ In the second keydown event (step 5), the key value (assuming the event is not suppressed) will not be "e" (Latin Small Letter E key) under normal circumstances because the value delivered to the user agent will already be modified by the dead key operation.

この処理nは、 利用者が［ `~dead-key$を押した後に， ~supportされない基底~文字 （すなわち，作動中な発音区別符号が可用でない基底~文字） を打込んだとき ］には，中止され得る： ◎ This process might be aborted when a user types an unsupported base character (that is, a base character for which the active diacritical mark is not available) after pressing a dead key:

4.3.3. ~IME（ `Input Method Editors^en ）

この仕様は、 `CompositionEvent$I ~interface＆~event を通して，`~IME$（ `Input Method Editor^en ）用の~modelを含めている。 しかしながら、 `組成~event$と`~keyboard~event$を一対一に対応付けるとは限らない。 例として、 `~UIkey値$ `Accept^cap を伴う `keydown$et を受取ったとしても，それは、 `~IME$において現在~選択された~textが受容されたことを含意するとは限らず，~keystrokeが起きたことのみを指示する — 受容されている`~IME$の機能性からは切離されて （それは、 ほとんどの`~IME$~systemにおいては， 通常は `compositionend$et ~eventを生じさせることになるが）。 ~keyboard~eventは、 ~IMEの現在の状態を決定する用途には，利用できない — その状態は `CompositionEvent.data$m 属性を通して得することができる。 加えて、 `~IME$~systemや装置の機能性は様々であり、 その機能性を作動化するために，どの~UIkey — `Convert^cap ／ `Accept^cap ~UIkeyなど — が利用されているかは、 他の可用な~UIkeyにより表現されることもある。 ~keyboard~eventは、 ~keyboard~layout用の`~UIkey対応付け$の後に，入力~装置により生成された~eventに対応する。 ◎ This specification includes a model for input method editors (IMEs), through the CompositionEvent interface and events. However, Composition Events and Keyboard Events do not necessarily map as a one-to-one relationship. As an example, receiving a keydown for the Accept key value does not necessarily imply that the text currently selected in the IME is being accepted, but indicates only that a keystroke happened, disconnected from the IME Accept functionality (which would normally result in a compositionend event in most IME systems). Keyboard events cannot be used to determine the current state of the input method editor, which can be obtained through the data attribute of the CompositionEvent interface. Additionally, IME systems and devices vary in their functionality, and in which keys are used for activating that functionality, such that the Convert and Accept keys MAY be represented by other available keys. Keyboard events correspond to the events generated by the input device after the keyboard layout mapping.

注記： 一部の実装／~system環境設定においては、 一部の~UIkey~eventやその値は，利用-中にある`~IME$により抑止されることがある。 ◎ In some implementations or system configurations, some key events, or their values, might be suppressed by the IME in use.

次の例に、 日本語~IMEを利用して， ~Unicode文字 `~~市^kGl （ `CJK Unified Ideographs^en の一部である漢字 ） が生成されるときにアリな~UIkey連列を述べる。 この例では、 ~IMEは作動化されていて，日本語~Romaji入力~mode下にあるとする。 ~UIkey `Convert^cap （ “~~変換” ）／ `Accept^cap （ “~~確定” ） は、 利用-中にある入力~装置や~IMEの環境設定に依存して，他に置換されることもある — 例えば `~SPACEBAR^cap （ `0020^U ）／ `Enter^cap にもなり得る。 ◎ The following example describes a possible sequence of keys to generate the Unicode character "市" (Kanji character, part of CJK Unified Ideographs) using Japanese input methods. This example assumes that the input method editor is activated and in the Japanese-Romaji input mode. The keys Convert and Accept MAY be replaced by others depending on the input device in use and the configuration of the IME, e.g., it can be respectively U+0020 (Space key) and Enter.

注記： `~~詩^kGl と `~~市^kGl は異形同音異義語であり， いずれも “し” と発音されるので、 利用者は， `Convert^cap ~UIkeyを利用して 適正な~optionを選択する必要がある。 ◎ "詩" ("poem") and "市" ("city") are homophones, both pronounced し ("shi"/"si"), so the user needs to use the Convert key to select the proper option.

~IME組成は、 前掲の例と一致する条件で，次の例のとおり取消され得る。 ~UIkey `Cancel^cap も利用-中にある入力~装置や~IMEの環境設定に依存して，他に置換され得る — 例えば `001B^U （ `Escape^cap ~UIkey ）にもなり得る。 ◎ IME composition can also be canceled as in the following example, with conditions identical to the previous example. The key 'Cancel' might also be replaced by others depending on the input device in use and the configuration of the IME, e.g., it could be U+001B (Escape key).

注記： `~IME$（ MacOS ~OS上など）によっては、 組成を取消す前に組成~data属性に`空~文字列$を設定するものもある。 ◎ Some input method editors (such as on the MacOS operating system) might set an empty string to the composition data attribute before canceling a composition.

4.3.4. 既定~動作と取消~可能~keyboard~event

`keydown$et ~eventの`既定~動作$が取消されたときは， それと対を成す `keyup$et ~eventには影響しないモノトスルが、 それに対応する［ `beforeinput$et ／ `input$et ／（~support有りなら） `keypress$et ］~eventは生成しないようにするモノトスル。 次の例に、 ~US~keyboardで, ~US用の`~UIkey対応付け$を利用している下で， ~Unicode文字 Q（ `Latin Capital Letter Q^cn ） が生成されるときにアリな~UIkey連列を述べる： ◎ Canceling the default action of a keydown event MUST NOT affect its respective keyup event, but it MUST prevent the respective beforeinput and input (and keypress if supported) events from being generated. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a US keyboard using a US mapping:

~UIkeyが修飾~UIkeyであった場合、 ~keystrokeは，依然として修飾~状態に織り込むモノトスル。 次の例に、 ~US~keyboardで, ~US用の`~UIkey対応付け$を利用している下で， ~Unicode文字 Q（ `Latin Capital Letter Q^cn ） が生成されるときにアリな連列を述べる： ◎ If the key is a modifier key, the keystroke MUST still be taken into account for the modifiers states. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a US keyboard using a US mapping:

~UIkeyが何回かの~keystrokeからなる連列の一部を成す場合， それが`~dead-key$であれ, ~IME連列に寄与しているものであれ、 その~keystrokeは， `keydown$et ~event上で`既定~動作$が取消された場合に限り，無視するモノトスル （織り込まれない）。 `~dead-key$による`keyup$et ~eventを取消しても， `beforeinput$et ／ `input$et ~eventには効果がない。 次の例に、 ~French~keyboardで, ~French用の`~UIkey対応付け$を利用し，どの修飾も作動化されない下で、［ ~dead-key `Dead$kY （ `0302^U `Combining Circumflex Accent^cn ~UIkey） ］, ［ `e^kY ~UIkey（ `0065^U `Latin Small Letter E^cn ~UIkey） ］を利用したときに生じる~event連列を示す： ◎ If the key is part of a sequence of several keystrokes, whether it is a dead key or it is contributing to an Input Method Editor sequence, the keystroke MUST be ignored (not taken into account) only if the default action is canceled on the keydown event. Canceling a dead key on a keyup event has no effect on beforeinput or input events. The following example uses the dead key "Dead" (U+0302 Combining Circumflex Accent key) and "e" (U+0065, Latin Small Letter E key) on a French keyboard using a French mapping and without any modifier activated:

5.2.1. ~pointer~lock用の大域的な状態

~UAは、 各`~window$の中で共有される値をとして，次を保守するモノトスル ⇒ `最後の~mousemove位置@ ⇒ 最後の `mousemove$et ~eventの位置を記録する — 初期~時は ε とする。 ◎ 5.2.1.1. Window-Level State ◎ The UA must maintain the following values that are shared for the Window. ◎ A last mouse move value (initially undefined) that records the position of the last mousemove event.

5.2.2. 各種~algo