UI イベント

1. はじめに

1.1. 概要

UI Eventsは主に2つの目的で設計されています。最初の目的は、event システムを設計することであり、これにより event listeners の登録を可能にし、イベントがツリー構造を通じて流れる仕組みを記述します。さらに、本仕様ではユーザーインターフェイス制御やドキュメントの変更通知のための標準的なイベントモジュールを提供し、これらの各イベントモジュールに関するコンテキスト情報も定義します。

UI Eventsの2つ目の目的は、現行のブラウザで使用されているイベントシステムの共通部分集合を提供することです。これは、既存のスクリプトやコンテンツの相互運用性を促進するためです。この目的が完全な後方互換性を持って達成されるとは期待されていませんが、可能な限りその達成を目指しています。

1.1.1. マウス及びホイールイベント

この仕様の「マウスイベント」と「ホイールイベント」のセクションは、Pointer Events仕様 [pointerevents4] に移動されました。

1.2. 適合性

このセクションは規範的です。

本仕様書内では、キーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、および OPTIONAL は [RFC2119] で説明されている通りに解釈されます。

本仕様はDOM Level 3 Core仕様書 [DOM-Level-3-Core] の文脈で理解されるべきであり、DOM実装に関する一般的な考慮事項が適用されます。例えば、namespace URIs の扱いについては XML Namespaces で論じられています。 適合性 についての追加情報は、DOM Level 3 Core仕様書 [DOM-Level-3-Core] を参照してください。user agent は本仕様に適合するために他の仕様全体に適合する必要はありませんが、本仕様で言及されている他仕様の特定部分には必ず適合しなければなりません（例：適合するUI Events user agent は DOMString データ型を [WebIDL] で定義されている通りにサポートしなければなりませんが、UI Eventsに適合するだけで [WebIDL] で定義されているすべてのメソッドやデータ型をサポートする必要はありません）。

本仕様では、異なる user agent、仕様、コンテンツ著者向けに複数の適合クラスを定義しています：

1.2.1. Webブラウザおよびその他の動的または対話的な user agents

動的または対話的な user agent、ここでは「ブラウザ」と呼びます（Webブラウザ、AT（アクセシビリティ技術）アプリケーション、またはそれに類するプログラムなど）、は次の条件を満たす場合UI Eventsに適合します：

• [DOM-Level-3-Core] で定義されているCoreモジュール

• 本仕様で定義されているすべてのインターフェイスおよびイベント、その関連メソッド、属性、および意味論（ただし deprecated と記されたものは除く。適合するuser agentは、後方互換性のためにdeprecatedなインターフェイス、イベント、APIを実装してもよいが、適合要件ではない）

• [UIEvents-Key] および [UIEvents-Code] で定義されている key および code の全値（プラットフォームで利用可能な場合）、および

• 本仕様で定義されているその他すべての規範的要件。

適合するブラウザは、条件が満たされたとき、適切な EventTarget に イベントを発火 しなければなりません。

ブラウザは、本ドキュメントで定義されたインターフェイスおよび関連する event types を実装している場合、UI Eventsに特化して適合しているといえます。

適合するブラウザは、スクリプティング、宣言型インタラクティビティ、またはその他の方法で、イベントの検出および発火を本仕様で記述された方法でサポートしなければならず、また event type 用に仕様されたAPIもサポートしなければなりません。

その他の適合基準をすべて満たすことに加えて、適合するブラウザは後方互換性のために deprecated と記された仕様の機能を実装してもかまいませんが、その実装は推奨されません。

適合するブラウザは、本仕様にない機能（ただし本仕様で定義されたインターフェイス、イベント、またはその他の機能を用いるもの）をサポートしたり、実装に応じて追加のインターフェイスや event types を実装してもかまいません。こうした機能は将来の仕様で標準化されることもあります。

本仕様の必須部分すべてに適合しないブラウザは、UI Eventsへの適合を主張してはなりません。部分的に本仕様に適合する実装は、その特定部分への適合のみを主張できます。

適合するブラウザは、Web IDL仕様 [WebIDL] で説明されているように、インターフェイス定義言語（IDL）断片の 適合する実装 でもなければなりません。

1.2.2. オーサリングツール

コンテンツオーサリングツールは、本仕様で定義された event types を一貫して使用するコンテンツを生成する場合、UI Eventsに適合しています。

オーサリングツールは、生成するコンテンツが本仕様で deprecated と記された機能を使用している場合、そのコンテンツについてUI Eventsへの適合を主張してはなりません。

適合するコンテンツオーサリングツールは、コンテンツ著者が、コンテンツ文書で使用されるすべての event types およびインターフェイスを、すべての host languages に対して使用できるよう手段を提供すべきです。

1.2.3. コンテンツ著者およびコンテンツ

コンテンツ 著者 は、そのコンテンツが本仕様で定義された event types を一貫して使用する場合、UI Events適合コンテンツを作成したことになります。

コンテンツ著者は、本仕様で deprecated とされる機能を使用すべきではなく、代替手段（本仕様や他仕様で定義されているもの）を利用すべきです。

適合するコンテンツは、本仕様で記述されるインターフェイスや event types の意味論を守らなければなりません。

コンテンツ著者は、アクセシビリティ や 国際化 のガイドライン仕様で説明されるベストプラクティスに従うことが推奨されます。

1.2.4. 仕様およびホスト言語

仕様または host language は、[DOM] で定義されているイベントフロー機構、インターフェイス、イベント、またはその他の機能を参照し、これらの機能を非互換な方法で拡張しない場合、UI Eventsに適合します。

仕様または host language が、本ドキュメントで定義されたインターフェイスおよび関連する event types を参照し、使用する場合、UI Eventsに特化して適合しています。適合する仕様は、仕様に応じて追加のインターフェイスや event types を定義したり、UI Eventsのインターフェイスや event types を、この仕様で定義されている内容と矛盾または衝突しない方法で拡張してもかまいません。

UI Eventsを参照する仕様や host languages は、本仕様で deprecated とされる機能を使用または推奨すべきではなく、可能ならば推奨される代替手段を利用または推奨すべきです。

2. 記述上の慣例

本仕様は提案されたW3C仕様記述慣例 に従っていますが、以下の追加事項があります：

• キーに印字されている キーキャップ は ↓、=、Q といった形で表されます。これは、ユーザー視点でキーを参照する際に使用され、生成される key や code の値は考慮しません。

• 文字を表すグリフは "𣧂" のように示されます。

• Unicode文字コードは U+003d のように表記されます。

• キー押下によって生成されるキー値名（すなわち KeyboardEvent.key の値）は "ArrowDown"、 "="、"q"、"Q" のように示されます。

• 物理キーに関連付けられているキーコード名（すなわち KeyboardEvent.code の値）は "ArrowDown"、 "Equal"、 "KeyQ" のように示されます。

さらに、本仕様では特定の用語が特別な意味で用いられます。「実装」という用語は、本仕様を実装するブラウザ、コンテンツオーサリングツール、その他の user agent を指します。一方、コンテンツ著者は、本仕様で説明されているインターフェイス、メソッド、属性、イベント等を利用してWebアプリケーションを作成する人を指し、ユーザーはそのWebアプリケーションを実装上で利用する人です。

最後に：

これは注記です。

これは未解決の課題です。

これは警告です。

interface Example {
    // This is an IDL definition.
};

3. 基本イベントインターフェイス

[DOM] で定義される基本的なイベントインターフェイスは、UI Eventsに不可欠です。これらの基本イベントインターフェイスは実装で常にサポートされなければなりません：

• Event インターフェイスおよび以下の定数、メソッド、属性：

  • NONE 定数

  • CAPTURING_PHASE 定数

  • AT_TARGET 定数

  • BUBBLING_PHASE 定数

  • type 属性

  • target 属性

  • currentTarget 属性

  • eventPhase 属性

  • bubbles 属性

  • cancelable 属性

  • composed 属性

  • timeStamp 属性

  • defaultPrevented 属性

  • isTrusted 属性

  • stopPropagation() メソッド

  • stopImmediatePropagation() メソッド

  • preventDefault() メソッド

  • initEvent() メソッド

• CustomEvent インターフェイスおよび以下のメソッドと属性：

  • initCustomEvent() メソッド

  • detail 属性

• EventTarget インターフェイスおよび以下のメソッド：

  • addEventListener() メソッド

  • removeEventListener() メソッド

  • dispatchEvent() メソッド

• EventListener インターフェイスおよび handleEvent() メソッド

• Document インターフェイスの createEvent() メソッド

本仕様で定義されるイベント型はこれらの基本インターフェイスから派生し、派生元のインターフェイスが持つすべての属性、メソッド、定数を継承しなければなりません。

以下の図は本仕様で記述されるインターフェイスの継承構造を示します。

3.1. イベント型一覧

各イベントは イベント型 と呼ばれる型に関連づけられ、イベントオブジェクトの type 属性として利用できます。イベント型は DOMString 型でなければなりません。

DOMのサポートレベルや表示（例：画面）・操作（例：マウス、キーボード、タッチスクリーン、音声）用デバイスによって、こうしたイベント型は実装によって生成されます。[XML] や [HTML5] アプリケーションで使用される場合、それぞれの言語仕様によってイベント型に関連する意味論や範囲（特に イベントターゲット の可能性）が制限されることがあります。詳細や、本ドキュメントに定義されていないイベント型を探す場合は、各言語仕様を参照してください。

次の表は、本仕様で記述されるイベント型の情報まとめです。

本仕様で非推奨とされるイベント一覧については、ドキュメント末尾の 旧イベント型 付録を参照してください。

上記の表の解釈例：load イベントは、そのイベント向けに Element ノード上でキャプチャおよびターゲットフェーズでイベントリスナーが発火します。このイベントはキャンセルできません。event listener が Window、Document、Element ノード以外や、バブリングフェーズのみで登録された場合、この event listener は発火しません。

上記の表は記載されたイベント型について決定的なものとして解釈しないでください。例えば load イベントは他仕様でも使用されています（例：XMLHttpRequest）。同様に、dispatchEvent() は 任意の EventTarget を実装するオブジェクトでリスナーに非信頼イベントを発火できます。

上記イベント型に関連付けられるイベントオブジェクトは追加のコンテキスト情報を持っています。詳細はDOMインターフェイスの説明を参照してください。

3.2. ユーザーインターフェイスイベント

ユーザーインターフェイスイベントモジュールは、ユーザーインターフェイスやドキュメント操作に関連する基本的なイベント型を含みます。

3.2.1. UIEvent インターフェイス

DOM Level 2 で導入

UIEvent インターフェイスは、ユーザーインターフェイスイベントに関連する特定のコンテキスト情報を提供します。

UIEvent インターフェイスのインスタンスを生成するには、UIEvent コンストラクタを使用し、必要に応じて UIEventInit 辞書を渡します。

新しく定義されるイベントについては、ユーザーインターフェイスに関連するからといって UIEvent インターフェイスを必ず継承する必要はありません。UIEventInit のメンバーがそのイベントに意味を持つ場合のみ継承してください。

3.2.1.1. UIEvent

[Exposed=Window]
interface UIEvent : Event {
  constructor(DOMString type, optional UIEventInit eventInitDict = {});
  readonly attribute Window? view;
  readonly attribute long detail;
};

UIEvent . view

view 属性は、そのイベントが生成された Window を示します。

この属性の 未初期化値 は null でなければなりません。

UIEvent . detail

Event の種類に応じて、そのイベントに関する詳細情報を指定します。

この属性の 未初期化値 は 0 でなければなりません。

3.2.1.2. UIEventInit

dictionary UIEventInit : EventInit {
  Window? view = null;
  long detail = 0;
};

UIEventInit . view

この値は、このイベントが発火されるグローバル環境の Window オブジェクトに初期化すべきです。このイベントが要素に対して発火される場合は、view プロパティはその要素の ownerDocument を含む Window オブジェクトに設定します。

UIEventInit . detail

この値はアプリケーション固有の数値で初期化されます。

3.2.2. UIEvent のアルゴリズム

3.2.3. UIEvent 型

ユーザーインターフェイスイベント型を以下に示します。これらのイベントの一部は、ユーザーインターフェイスから生成された場合 UIEvent インターフェイスを使用しますが、詳細は各イベントごとに記載されています。

3.2.3.1. load

DOM実装がリソース（例：ドキュメント）および依存リソース（画像、スタイルシート、スクリプトなど）の読み込みを完了したとき、user agent はこのイベントを発火しなければなりません。依存リソースのロード失敗は、親リソースがDOM経由でアクセス可能であれば、このイベントの発火を妨げてはなりません。このイベント型が発火される場合、少なくとも Document ノードでこのイベントを発火する必要があります。

旧来の理由により、ドキュメント内のリソース（例：画像）に対する load イベントは、HTML 実装では伝播パスに Window を含みません。詳細は [HTML5] を参照してください。

3.2.3.2. unload

DOM実装が環境からリソース（例：ドキュメント）や依存リソース（画像、スタイルシート、スクリプトなど）を除去したとき、user agent はこのイベントを発火しなければなりません。このイベント型の発火後にドキュメントはアンロードされる必要があります。このイベント型が発火される場合、少なくとも Document ノードでこのイベントを発火する必要があります。

3.2.3.3. abort

リソースのロードが中断されたとき（例：ユーザーがロード中にキャンセルした場合）、user agent はこのイベントを発火しなければなりません。

3.2.3.4. error

リソースのロードに失敗した場合や、ロードされたが意味的に解釈できない場合（例：不正な画像、スクリプト実行エラー、非整形式XMLなど）、user agent はこのイベントを発火しなければなりません。

3.2.3.5. select

ユーザーがテキストを選択したとき、user agent はこのイベントを選択後に発火しなければなりません。

本仕様では選択されたテキストへのアクセスに関するコンテキスト情報は提供しません。該当する場合、ホスト言語は、ユーザーがどのように内容を選択できるか（国際的な言語慣習も考慮）、select イベントがどのタイミングで発火されるか、コンテンツ著者がユーザー選択内容にどのようにアクセスできるかを定義するべきです。

ユーザー選択内容へアクセスするには、コンテンツ著者は ホスト言語のネイティブ機能（HTML 編集APIの Document.getSelection() メソッドなど）を使用します。[Editing]

select イベントはすべての要素や言語で利用できるとは限りません。例えば [HTML5] では select イベントはフォームの input や textarea 要素でのみ発火できます。 実装は、フォームコントロール外のテキスト選択やSVGなどの画像やマークアップ選択など、適切と判断されるコンテキストで select イベントを発火してもかまいません。

3.3. フォーカスイベント

このインターフェイスと関連するイベント型、および § 3.3.2 フォーカスイベント順序は、User Agent Accessibility Guidelines 2.0 [UAAG20] で定義された概念・指針に基づいて設計されています。 特に フォーカスメカニズム や glossary の focus の定義に注意しています。

3.3.1. FocusEvent インターフェイス

本仕様で導入

FocusEvent インターフェイスは、フォーカスイベントに関連する特定のコンテキスト情報を提供します。

FocusEvent インターフェイスのインスタンスを生成するには、FocusEvent コンストラクタを使用し、必要に応じて FocusEventInit 辞書を渡します。

3.3.1.1. FocusEvent

[Exposed=Window]
interface FocusEvent : UIEvent {
  constructor(DOMString type, optional FocusEventInit eventInitDict = {});
  readonly attribute EventTarget? relatedTarget;
};

FocusEvent . relatedTarget

イベントの種類に応じて、フォーカスイベントに関連する二次的な EventTarget を識別するために使用します。

ネストされたブラウジングコンテキストとのセキュリティ上の理由から、入出時に関連する EventTarget は null であるべきです。

この属性の 未初期化値 は null でなければなりません。

3.3.1.2. FocusEventInit

dictionary FocusEventInit : UIEventInit {
  EventTarget? relatedTarget = null;
};

FocusEventInit . relatedTarget

relatedTarget は、focus や focusin イベントの場合はフォーカスを失う要素、blur や focusout イベントの場合はフォーカスを得る要素に初期化してください。

3.3.2. フォーカスイベント順序

本仕様で定義されるフォーカスイベントは、相互間で一定の順序で発生します。以下は、フォーカスが要素間で移動する典型的なイベントシーケンスです（最初はどの要素にもフォーカスがないと仮定）：

本仕様では focus() や blur() といったメソッドを使った場合のフォーカスイベントの動作は定義しません。該当メソッドが定義されている仕様を参照してください。

3.3.3. ドキュメントフォーカスとフォーカスコンテキスト

このイベントモジュールには、ドキュメントの フォーカス の変更通知のイベント型が含まれます。フォーカスコンテキストには、次の3つの区分があります：

• OSフォーカスコンテキスト：コンピュータ上で現在実行中の複数のアプリケーションのいずれかにフォーカスがある可能性があります。そのうちフォーカスを持つアプリケーションとしてブラウザが含まれる場合があります。

• ブラウザがフォーカスを持つ場合、ユーザーは（例：Tabキーで）アプリケーションフォーカスコンテキストをブラウザのUIフィールド（Webサイトのロケーションバー、検索フィールド等）間で切り替えることができます。そのUIフィールドの一つがタブ内のドキュメントである場合があります。

• ドキュメント自体がフォーカスを持つ場合、ドキュメントフォーカスコンテキストはドキュメント内の任意のフォーカス可能要素に設定できます。

本仕様で定義されるイベント型はドキュメントフォーカスのみを対象にしており、イベント詳細で識別される event target はウィンドウ内のドキュメント（または複数ドキュメント）の一部でなければならず、ブラウザやOSの一部であってはなりません（フォーカスコンテキスト間の切り替え時も同様）。

通常、ドキュメントには常にフォーカスされた要素（ドキュメント要素自身の場合も含む）と持続的な フォーカスリング があります。フォーカスコンテキスト間を切り替える場合も、ドキュメントの現在のフォーカス要素とフォーカスリングは通常そのまま維持されます。例えば、3つのフォーカス可能要素があるドキュメントで、2番目の要素がフォーカスされている場合に、ユーザーがOSのフォーカスを他アプリに移し、再びブラウザに戻しても、ドキュメント内では2番目の要素がフォーカスされており、Tabキー操作で3番目の要素にフォーカスが移ります。ホスト言語 は、特定の要素がフォーカスを受け取る条件や方法、フォーカスの変更手段や順序などを定義してもかまいません。例えば、ある場合はポインタ移動でフォーカスを得たり、他の場合はクリックが必要だったりします。フォーカスできない要素や、クリックのみでフォーカスできTabキーではできない要素もあり得ます。ドキュメントは複数のフォーカスリングを持つ場合もあり、他仕様でより複雑なフォーカスモデル（複数要素が同時にフォーカスを持つ等）が定義されることもあります。

3.3.4. フォーカスイベント型

フォーカスイベント型を以下に示します。

3.3.4.1. blur

ユーザーエージェントは、イベントターゲットがフォーカスを失った時、このイベントを送信しなければなりません。フォーカスはこのイベントタイプの送信前に要素から外されなければなりません。このイベントタイプはfocusoutと似ていますが、バブリングしません。

3.3.4.2. focus

ユーザーエージェントは、イベントターゲットがフォーカスを受け取った時、このイベントを送信しなければなりません。フォーカスはこのイベントタイプの送信前に要素へ与えられなければなりません。このイベントタイプはfocusinと似ていますが、バブリングしません。

3.3.4.3. focusin

ユーザーエージェントは、イベントターゲット がフォーカスを受け取った時、このイベントを送信しなければなりません。イベントターゲットは、フォーカスを受け取った要素でなければなりません。focusイベントは、このイベントタイプの送信前に発生しなければなりません。このイベントタイプはfocusと似ていますが、バブリングします。

3.3.4.4. focusout

ユーザーエージェントは、イベントターゲット がフォーカスを失った時、このイベントを送信しなければなりません。イベントターゲットは、フォーカスを失った要素でなければなりません。blurイベントは、このイベントタイプの送信前に発生しなければなりません。このイベントタイプはblur と似ていますが、バブリングします。

3.4. 入力イベント

入力イベントは、DOM がユーザーの操作（例: 編集可能領域でのキーボード入力、テキストの削除や書式設定など）の直接の結果として更新されている（またはこれから更新されようとしている）際に通知として送信されます。

3.4.1. インターフェース InputEvent

3.4.1.1. InputEvent

DOM Level 3 で導入

[Exposed=Window]
interface InputEvent : UIEvent {
  constructor(DOMString type, optional InputEventInit eventInitDict = {});
  readonly attribute USVString? data;
  readonly attribute boolean isComposing;
  readonly attribute DOMString inputType;
};

data, of type USVString, readonly, nullable

data は入力方式（input method）によって生成された文字の値を保持します。これは単一の Unicode 文字、または空でない Unicode 文字列の列である場合があります [Unicode]。文字は [UAX15] に定義された Unicode 正規化形式 NFC に従って正規化されるべきです。 この属性は 空文字列 を含むことがあります。

未初期化値 は null でなければなりません。

isComposing, of type boolean, readonly

true は、入力イベントが合成セッションの一部として発生している場合、すなわち対応する compositionstart イベントの後で、対応する compositionend イベントの前であることを示します。

未初期化値 は false でなければなりません。

inputType, of type DOMString, readonly

inputType はイベントに関連付けられた入力の種類を識別する文字列を含みます。

この属性の有効な値の一覧については、[Input-Events] 仕様を参照してください。

未初期化値 は空文字列 "" でなければなりません。

3.4.1.2. InputEventInit

dictionary InputEventInit : UIEventInit {
  DOMString? data = null;
  boolean isComposing = false;
  DOMString inputType = "";
};

data, of type DOMString, nullable, defaulting to null

InputEvent オブジェクトの data 属性を初期化します。

isComposing, of type boolean, defaulting to false

InputEvent オブジェクトの isComposing 属性を初期化します。

inputType, of type DOMString, defaulting to ""

InputEvent オブジェクトの inputType 属性を初期化します。

3.4.2. 入力イベントの順序

この仕様で定義される入力イベントは、互いに対して一定の順序で発生しなければなりません。

3.4.3. 入力イベントの種類

3.4.3.1. beforeinput

ユーザーエージェントは、DOM がこれから更新されようとしているときにこのイベントを送信しなければなりません。

3.4.3.2. input

ユーザーエージェントは、DOM が更新された直後にこのイベントを送信しなければなりません。

3.5. キーボードイベント

キーボードイベントはデバイス依存であり、入力デバイスの機能やそれらがオペレーティングシステム上でどのようにマッピングされているかに依存します。詳細や、キーボードイベントが合成イベント（Composition Events）と組み合わせてどのように使用されるかの例については Keyboard events and key values を参照してください。文字生成デバイスによっては、キーボードイベントが生成されないことがあります。

キーボードイベントは文字入力を提供する一つのモダリティに過ぎません。編集シナリオでは、キーボードイベントの代替（または併用）として InputEvent の使用も検討してください。

3.5.1. インターフェース KeyboardEvent

この仕様で導入

The KeyboardEvent インターフェースは、キーボードデバイスに関連する特定の文脈情報を提供します。各キーボードイベントは値を使ってキーを参照します。キーボードイベントは通常、フォーカスを持つ要素に向けられます。

The KeyboardEvent インターフェースは、幾つかの一般的な修飾キーのための便利な属性を提供します: ctrlKey, shiftKey, altKey, metaKey. これらの属性は、それぞれ getModifierState() メソッドを Control、Shift、Alt、または Meta と共に使用するのと同等です。

インスタンスを作成するには KeyboardEvent コンストラクタを使用し、オプションの KeyboardEventInit 辞書を渡します。

3.5.1.1. KeyboardEvent

[Exposed=Window]
interface KeyboardEvent : UIEvent {
  constructor(DOMString type, optional KeyboardEventInit eventInitDict = {});
  // KeyLocationCode
  const unsigned long DOM_KEY_LOCATION_STANDARD = 0x00;
  const unsigned long DOM_KEY_LOCATION_LEFT = 0x01;
  const unsigned long DOM_KEY_LOCATION_RIGHT = 0x02;
  const unsigned long DOM_KEY_LOCATION_NUMPAD = 0x03;

  readonly attribute DOMString key;
  readonly attribute DOMString code;
  readonly attribute unsigned long location;

  readonly attribute boolean ctrlKey;
  readonly attribute boolean shiftKey;
  readonly attribute boolean altKey;
  readonly attribute boolean metaKey;

  readonly attribute boolean repeat;
  readonly attribute boolean isComposing;

  boolean getModifierState(DOMString keyArg);
};

DOM_KEY_LOCATION_STANDARD

キーのアクティベーションは左キーか右キーかを区別すべきではなく、（NumLock キーを除き）テンキー由来ではないことを示します。

PC 101 キー US 配列での Q キー。
PC 101 キー US 配列での NumLock キー。
PC 101 キー US 配列でキーボードの主要部にある 1 キー。

DOM_KEY_LOCATION_LEFT

キーのアクティベーションが左側のキー位置から発生したことを示します（当該キーに複数の位置がある場合）。

PC 101 キー US 配列での左側の Control キー。

DOM_KEY_LOCATION_RIGHT

キーのアクティベーションが右側のキー位置から発生したことを示します（当該キーに複数の位置がある場合）。

PC 101 キー US 配列での右側の Shift キー。

DOM_KEY_LOCATION_NUMPAD

キーのアクティベーションがテンキー上で発生したこと、またはテンキーに対応する仮想キーから発生したことを示します（当該キーに複数の位置がある場合）。なお、NumLock キーは常に location として DOM_KEY_LOCATION_STANDARD を用いるべきです。

PC 101 キー US 配列でテンキー上にある 1 キー。

key, of type DOMString, readonly

key は押されたキーに対応する key attribute value を保持します。

key 属性はレガシーな keyCode 属性とは関連しておらず、同じ値の集合ではありません。

未初期化値 は空文字列 "" でなければなりません。

code, of type DOMString, readonly

code は押された物理キーを識別する文字列を保持します。この値は現在のキーボード配列や修飾状態に影響されないため、特定のキーは常に同じ値を返します。

未初期化値 は空文字列 "" でなければなりません。

location, of type unsigned long, readonly

location 属性はデバイス上のキーの論理的な位置に関する指示を含みます。

この属性はデバイス上のキー位置を示すために DOM_KEY_LOCATION 定数のいずれかに設定されなければなりません。

もし ユーザーエージェント がキーの再割り当てを許可する場合、再割り当てされたキーの location 値は新しいキーに適切な値に設定されなければなりません。例えば、"ControlLeft" キーが "KeyQ" キーにマップされた場合、location 属性は DOM_KEY_LOCATION_STANDARD に設定されなければなりません。逆に、"KeyQ" キーが Control キーのいずれかにマップされた場合、location 属性は DOM_KEY_LOCATION_LEFT または DOM_KEY_LOCATION_RIGHT のいずれかに設定されなければなりません。

未初期化値 は 0 でなければなりません。

ctrlKey, of type boolean, readonly

true は Control（コントロール）修飾キーが有効であったことを示します。

未初期化値 は false でなければなりません。

shiftKey, of type boolean, readonly

true は Shift 修飾キーが有効であったことを示します。

未初期化値 は false でなければなりません。

altKey, of type boolean, readonly

true は Alt（または "Option"） 修飾キーが有効であったことを示します。

未初期化値 は false でなければなりません。

metaKey, of type boolean, readonly

true は Meta 修飾キーが有効であったことを示します。

Macintosh システムでの "Command"（"⌘"）キー修飾はこの修飾キーで表されます。

未初期化値 は false でなければなりません。

repeat, of type boolean, readonly

true はキーが持続的に押されている場合を示します。キーを押し続けると、システム設定により決定される速度で keydown、beforeinput、 input の各イベントがこの順序で繰り返されるべきです。スクリーン上のソフトウェアキーボードなど長押し動作（long-key-press）を持つモバイル機器では、最初に repeat 属性値が true のキーイベントが long-key-press の指標として扱われなければなりません。繰り返しが開始されるまでの時間は構成依存です。

未初期化値 は false でなければなりません。

isComposing, of type boolean, readonly

true はキーイベントが合成セッションの一部として発生している場合、すなわち compositionstart の後で対応する compositionend の前であることを示します。

未初期化値 は false でなければなりません。

getModifierState(keyArg)

修飾キーの状態をキー値を用いて照会します。

それが修飾キーであり、かつ修飾が有効であれば true、そうでなければ false を返します。

DOMString keyArg

修飾キーの値。妥当な 修飾キー は Modifier Keys table（[UIEvents-Key]）に定義されています。

アプリケーションが右側と左側の修飾キーを区別したい場合、この情報はキーボードイベントと location を用いて推測できます。

3.5.1.2. KeyboardEventInit

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

key, of type DOMString, defaulting to ""

KeyboardEvent オブジェクトの key 属性を初期化します。これはすべてのキーボード修飾（シフト状態など）を考慮した後のキーの意味を表す Unicode 文字列です。キーが印字可能な文字でない場合は、[UIEvents-Key] に定義されたキー値の一つであるべきです。

code, of type DOMString, defaulting to ""

KeyboardEvent オブジェクトの code 属性を初期化します。これはキーボード配列などの修飾を無視して押されたキーを表す文字列で、[UIEvents-Code] に定義されたコード値の一つであるべきです。

location, of type unsigned long, defaulting to 0

KeyboardEvent オブジェクトの location 属性を以下の数値定数のいずれかに初期化します:

• DOM_KEY_LOCATION_STANDARD （数値 0）

• DOM_KEY_LOCATION_LEFT （数値 1）

• DOM_KEY_LOCATION_RIGHT （数値 2）

• DOM_KEY_LOCATION_NUMPAD （数値 3）

repeat, of type boolean, defaulting to false

KeyboardEvent オブジェクトの repeat 属性を初期化します。現在の KeyboardEvent が長押しによって引き起こされる繰り返し系列の一部と見なされる場合は true、そうでなければ false を設定してください。

isComposing, of type boolean, defaulting to false

KeyboardEvent オブジェクトの isComposing 属性を初期化します。この属性は、構築中のイベントが合成シーケンスの一部である場合に true に設定してください。そうでなければ false にします。

既存コンテンツとの互換性のため、画面上のソフトウェアキーボードのような仮想キーボードは、物理キーを持たなくとも通常の範囲のキーボードイベントを生成することが期待されます。

一部の実装やシステム構成では、使用中の IME によって一部のキーイベントやその値が抑制されることがあります。

3.5.2. キーボードイベントのキー位置

The location 属性は、キーボード上の異なる物理キーから生成され得る key 値を区別するために使用できます。例えば、左右の Shift キーや物理的な矢印キーとテンキーの矢印キー（NumLock がオフのとき）などです。

次の表は、キーボード上で複数の位置を持つ特殊なキーに対する有効な location 値を定義します：

この表に含まれていないその他すべてのキーについては、 location 属性は常に DOM_KEY_LOCATION_STANDARD に設定されなければなりません。

3.5.3. イベント修飾子初期化

The MouseEvent と KeyboardEvent インターフェイスは一連のキーボード修飾子属性を共有し、追加の修飾子状態を取得する仕組みをサポートします。次の辞書は著者が MouseEvent および KeyboardEvent インターフェイスのキーボード修飾子属性や、getModifierState() を通じて問い合わせられる追加の修飾子状態を初期化できるようにします。辞書を用いてマウスイベントを構築する手順は [pointerevents4] 仕様で定義されています。

dictionary EventModifierInit : UIEventInit {
  boolean ctrlKey = false;
  boolean shiftKey = false;
  boolean altKey = false;
  boolean metaKey = false;

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

ctrlKey, of type boolean, defaulting to false

MouseEvent または KeyboardEvent オブジェクトの ctrlKey 属性を、Control キー 修飾子が有効と見なされる場合は true、そうでない場合は false に初期化します。

値が true の場合、実装はイベントオブジェクトのキー修飾子状態も初期化し、getModifierState() または getModifierState() に Control を渡した場合に true を返すようにしなければなりません。

shiftKey, of type boolean, defaulting to false

MouseEvent または KeyboardEvent オブジェクトの shiftKey 属性を、Shift キー修飾子が有効と見なされる場合は true、そうでない場合は false に初期化します。

値が true の場合、実装はイベントオブジェクトのキー修飾子状態も初期化し、getModifierState() または getModifierState() に Shift を渡した場合に true を返すようにしなければなりません。

altKey, of type boolean, defaulting to false

MouseEvent または KeyboardEvent オブジェクトの altKey 属性を、Alt （または Option）キー修飾子が有効と見なされる場合は true、そうでない場合は false に初期化します。

値が true の場合、実装はイベントオブジェクトのキー修飾子状態も初期化し、getModifierState() または getModifierState() に Alt を渡した場合に true を返すようにしなければなりません。

metaKey, of type boolean, defaulting to false

MouseEvent または KeyboardEvent オブジェクトの metaKey 属性を、Meta キー修飾子が有効と見なされる場合は true、そうでない場合は false に初期化します。

値が true の場合、実装はイベントオブジェクトのキー修飾子状態も初期化し、getModifierState() または getModifierState() に Meta を渡した場合に true を返すようにしなければなりません。

modifierAltGraph, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に AltGraph を渡した場合に true を返すようにします。

modifierCapsLock, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に CapsLock を渡した場合に true を返すようにします。

modifierFn, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に Fn を渡した場合に true を返すようにします。

modifierFnLock, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に FnLock を渡した場合に true を返すようにします。

modifierHyper, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に Hyper を渡した場合に true を返すようにします。

modifierNumLock, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に NumLock を渡した場合に true を返すようにします。

modifierScrollLock, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に ScrollLock を渡した場合に true を返すようにします。

modifierSuper, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に Super を渡した場合に true を返すようにします。

modifierSymbol, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に Symbol を渡した場合に true を返すようにします。

modifierSymbolLock, of type boolean, defaulting to false

イベントオブジェクトのキー修飾子状態を初期化し、getModifierState() または getModifierState() に SymbolLock を渡した場合に true を返すようにします。

3.5.4. KeyboardEvent のアルゴリズム

3.5.4.1. KeyboardEvent のグローバル状態

3.5.4.1.1. ユーザーエージェントレベルの状態

The UA must maintain the following values that are shared for the entire User Agent.

A key modifier state (initially empty) that keeps track of the current state of each modifier key available on the system.

3.5.5. キーボードイベントの順序

この仕様で定義されたキーボードイベントは、任意のキーについて互いに対して定められた順序で発生します：

If the key is depressed for a sustained period, the following events MAY repeat at an environment-dependent rate:

通常、特定のキーに関連付けられた任意のデフォルト動作は default actions、 keyup イベントが発火される前に完了します。これにより keyup イベントがわずかに遅延することがあります（ただし知覚できるほどの遅延になることはほとんどありません）。

キーイベントの event target は、現在入力がフォーカスされていてキーボード操作を処理している要素です。これは通常、HTMLの input 要素や編集可能なテキスト要素ですが、 ホスト言語 により定義された、非テキスト用途のキーボード入力（アクセラレータキーの有効化やその他の動作トリガーなど）を受け付ける要素の場合もあります。適切な要素がフォーカスされていない場合、event target は利用可能であればHTML body要素、そうでなければroot要素になります。

event target は異なるキーボードイベント間で変化することがあります。 例えば、Tabキーのkeydownイベントと 同じキー操作のkeyupイベントでは event target が異なることがあります。

3.5.6. キーボードイベントタイプ

3.5.6.1. keydown

ユーザーエージェントは、キーが押されているときにこのイベントを発火しなければなりません。 keydown イベントタイプはデバイス依存であり、 入力デバイスの能力やOSでのマッピングに依存します。このイベントタイプは キー割り当ての後で生成されなければなりません。またこのイベントタイプは 同じキーに関連する beforeinput, input, keyup イベントより前に発火されなければなりません。

keydown イベントのデフォルトアクションはキーによって異なります：

• キーが文字に関連付けられている場合、デフォルトアクションは beforeinput イベントの発火、その後 input イベントの発火です。マクロや「デッドキー」など、複数文字に対応するキーの場合は、 各文字ごとに beforeinput / input イベントセットを発火しなければなりません

• キーが テキスト合成システムに関連付けられている場合は デフォルトアクションはそのシステムを起動することです

• キーが Tab キーの場合、デフォルトアクションは現在フォーカスされている要素（存在する場合）から新しいフォーカス要素へ ドキュメントのフォーカスを移すことです。詳細は フォーカスイベントタイプを参照してください。

• キーが Enter または （スペース）キーで、 現在フォーカスされている要素が状態変更要素の場合、デフォルトアクションは click イベント、および DOMActivate イベント（ユーザーエージェントが対応している場合）を発火することです。

このイベントがキャンセルされた場合、関連するイベントタイプは発火されず、関連アクションも実行されません。

keydown および keyup イベントは伝統的に 文字値を生成するキーに限定されず、任意のキー検出と関連付けられています。

3.5.6.2. keyup

ユーザーエージェントは、キーが離されたときにこのイベントを発火しなければなりません。 keyup イベントタイプはデバイス依存であり、 入力デバイスの能力やOSでのマッピングに依存します。このイベントタイプは キー割り当ての後で生成されなければなりません。またこのイベントタイプは 同じキーに関連する keydown, beforeinput, input イベントより後に発火されなければなりません。

keydown および keyup イベントは伝統的に 文字値を生成するキーに限定されず、任意のキー検出と関連付けられています。

3.6. 合成イベント

合成イベントは、キーボードイベント以外の補助的または代替的な入力手段を提供し、 キーボード上では一般的に利用できない文字を使えるようにします。例えば合成イベントは、 標準の米国キーボードにない発音記号を文字へ付加したり、多くのアジア言語における表意文字を 基本部品やカテゴリから組み立てたり、モバイルデバイスのキーボードで複数のキー操作を組み合わせて 単語を選択したり、音声認識プロセッサを使って音声指令をテキストへ変換したりする用途に使われます。 合成イベントがキーボードイベントと組み合わせてどのように使用されるかの例は § 4 キーボードイベントとキー値 を参照してください。

概念的に、合成セッションは1つのcompositionstart イベント、1つ以上のcompositionupdateイベント、そして1つの compositionendイベントからなり、各セッション期間中、このイベントチェーンの各段階間でdata 属性の値が持続される。

注記： 合成セッションがアクティブな間、キーボードが入力デバイスとして使われる場合には、 キーボードイベントがDOMに発火される可能性があります。 詳しくは compositionstart イベントの詳細や IME セクション のイベント順序をご覧ください。

すべてのIMEシステムやデバイスが必要なデータをDOMに公開するとは限らないため、 アクティブな合成文字列（「読みウィンドウ」や「候補選択メニューオプション」）は このインターフェイス経由で利用できない場合があり、その場合選択は 空文字列で表現されることがあります。

3.6.1. インターフェイス CompositionEvent

この仕様で導入

CompositionEvent インターフェイスは、合成イベントに関連する 特定のコンテキスト情報を提供します。

CompositionEvent インターフェイスのインスタンスを作成するには、 オプションの CompositionEventInit 辞書を渡して CompositionEvent コンストラクタを使用してください。

3.6.1.1. CompositionEvent（合成イベント）

[Exposed=Window]
interface CompositionEvent : UIEvent {
  constructor(DOMString type, optional CompositionEventInit eventInitDict = {});
  readonly attribute USVString data;
};

data, 型 USVString（読み取り専用）

data は、入力方式によって生成された文字値を保持します。これは単一のユニコード文字または 非空のユニコード文字列となる場合があります [Unicode]。 文字列は Unicode 正規化形式 NFC（[UAX15]）に従い正規化されるべきです。 また、この属性は空文字列となることもあります。

この属性値の未初期化値は ""（空文字列）です。

3.6.1.2. CompositionEventInit（合成イベント初期化）

dictionary CompositionEventInit : UIEventInit {
  DOMString data = "";
};

data, 型 DOMString（初期値は ""）

CompositionEvent オブジェクトの data 属性を IME 合成で生成された文字値で初期化します。

3.6.2. 合成イベント順序

この仕様で定義された合成イベントは、互いに対して次のセット順序で発生しなければなりません：

3.6.3. 手書き認識システム

以下は、筆でタブレット上に「text」という文章を手書き認識システムで合成する場合のイベントシーケンス例です（合成イベントとしてモデル化）。

3.6.4. 合成イベントのキャンセル

keydown イベントがキャンセルされた場合、 その keydown により発火されるはずの合成イベントは 発火されないべきです：

最初の compositionstart イベントがキャンセルされた場合、 テキスト合成セッションは終了すべきです。合成セッションが終了するかどうかに関わらず、 compositionend イベントは必ず送信されなければなりません。

3.6.5. 合成中のキーイベント

合成セッション中は keydown と keyup イベントは引き続き送信され、 これらは isComposing 属性を true に設定した状態で発火されなければなりません。

3.6.6. 合成中の入力イベント

合成セッション中は、compositionupdate イベントは beforeinput の後、そして input イベントの前に発火されなければなりません。

多くの IME は合成セッション中の更新キャンセルをサポートしません。

beforeinput および input イベントは DOMが合成の一部として更新された都度、compositionupdate イベントとともに送信されます。 compositionend イベントには DOM 更新が伴わないため、 beforeinput や input イベントは送信すべきではありません。

3.6.7. 合成イベントタイプ

3.6.7.1. compositionstart

ある ユーザー エージェント MUST このイベントを送出しなければならない場合は、テキスト 合成システムが有効になっており、新しい合成セッションが 開始されようとしている（または既に開始されている場合がある、テキスト合成 システムに応じて）テキストの一節を作成する準備として。これは イベントの種類はデバイス依存であり、テキスト変換システムの能力やそれが オペレーティングシステムにどのようにマッピングされているかに依存してもよい(MAY)。キーボードが入力方式エディタに入力を渡すために使用される場合、このイベントの種類はkeydownイベントの後に生成されるが、 音声認識や手書き認識システムはキーボードイベントなしでこのイベント の種類を送信してもよい(MAY)。いくつかの実装はdata 属性をcompositionstart イベントに対して、文書で現在選択されているテキスト（編集および置換のため）で 埋めることがある(MAY)。そうでない場合、data 属性の値は 空 文字列 でなければならない(MUST)。

このイベントはテキスト合成システムが新しい合成セッションを始める直前、および合成プロセスによる DOM の修正前に必ず発火されなければなりません。 このイベントのデフォルトアクションはテキスト合成システムによる新しい合成セッションの開始です。 このイベントがキャンセルされた場合は テキスト合成システムは 現在の合成セッションを破棄するべきです。

compositionstart イベントタイプのキャンセルは、 テキスト合成システムそのもののキャンセル （例：キャンセルボタンを押す、IME ウィンドウを閉じるなど）とは異なります。

一部のIMEは進行中の合成セッションのキャンセル（例：GTK等、現時点でそのAPIがない）をサポートしません。 この場合 preventDefault() を呼び出しても本イベントのデフォルト動作は止まりません。

3.6.7.2. compositionupdate

ユーザーエージェントは 合成セッション中に テキスト合成システムがアクティブテキストに新しい文字を追加した際、 このイベントを発火するべきです。その結果は data に反映されます。

テキスト合成システムで 入力制御と進行中の合成内容を同期させる場合、compositionupdate イベントは制御が更新される前に発火されなければなりません。

テキスト合成システムによっては この情報をDOMに開示しない場合もあり、その場合合成処理中に本イベントは発火されません。

合成セッションがキャンセルされた場合、このイベントは compositionend イベントの直前に発火され、 data 属性値は空文字列になります。

3.6.7.3. compositionend

ユーザーエージェントは テキスト合成システムが現在の合成セッションを完了またはキャンセルした時、 compositionend イベントを発火しなければなりません。 またコントロール更新後に発火しなければなりません。

このイベントは テキスト合成システムが合成セッションを完了した直後 （例：IME が閉じられる、最小化される、フォーカスが失われるなどで フォーカスがユーザーエージェントに戻る）に必ず発火されます。

4. キーボードイベントとキー値

このセクションではキーボードイベントに関する必要な情報を示します：

• キーボードレイアウト・マッピング・キー値の説明。

• キー間の関係（デッドキーや修飾キーなど）。

• キーボードイベントとそのデフォルトアクションの関係。

• key値の集合と、その集合の拡張方法の指針。

このセクションではセルビア語や漢字文字を使用しています。PDF版や印刷版の現行標準では文字が正しく表示されない場合があります。

4.1. キーボード入力

このセクションは非規範的です

各キーとキーボード全体との関係は、以下の3つの側面から成り立ち、モデルや構成（特にロケール固有の場合）によって異なります：

• 機械的レイアウト：物理キーの寸法・サイズ・配置

• 視覚的マーキング：各キーに印字・刻印されているラベル（またはレジェンド）

• 機能的マッピング：各キーの抽象的なキー値の割当。

この現行標準では、key値とcode値に関する機能的マッピングのみ定義し、キーのレジェンドについては簡単な説明のみです。

4.1.1. キーのレジェンド

このセクションは参考情報です

キーのレジェンドは、キーキャップ（物理キーの長方形の「キャップ」部分）に印刷または刻印されている視覚的マークです。通常は、キー操作で生成される文字（"G"、"8"、"ш"など）や、そのキーの機能を示す記号や名称（上向き矢印"⇧"でShift、文字列"Enter"など）で構成されます。キーはこのマーキングで呼ばれることが多いです（例：「"Shift"キーと"G"キーを押してください」）。ただし、キーの見た目はデジタル表現に影響せず、多くの構成では見た目が完全に不正確な場合もあります。Enterなどのコントロール・ファンクションキーも、異なる機能や文字キーにマッピングされる場合があります。

多くのキーボードには通常文字を生成しないキーがあります（記号にUnicodeの対応があっても）。例えばShiftキーは"⇧"（UnicodeコードポイントU+21E7）の記号を持つ場合がありますが、Shiftキーを押してもこの文字値は生成されません。またShift自体にUnicodeコードポイントはありません。

4.2. キーコード

キーcode は、キーボードイベントに関連付けられた物理キーを識別する属性です。USB Usage IDに似ており、ベンダー非依存の低レベル値（スキャンコード類似）を提供します。

code 属性の主な目的は、物理位置に基づいてキーを一貫して識別する手段を提供することです。また、現在のキーボード状態に左右されない安定したキー名（各物理キーを一意に識別する）も提供します。

有効なcode 値の一覧は[UIEvents-Code]で定義されています。

4.2.1. code 属性の動機

標準PCキーボードには、ユーザーが選択した現在のキーボードレイアウトにより異なるkey 値を生成するキー（書記体系キー）があります。この状況では、物理位置に基づいてキーを検出するコードを書くのが困難です。現在どのレイアウトか把握して、どのkey 値を確認すべきか知る必要があるためです。実例：ゲームで"W"、"A"、"S"、"D"キーでプレイヤー移動を制御したい場合。code 属性なら、現在のキーボードレイアウトに影響されず安定した値で判定できます。

さらにkey 属性の値も現在のキーボード状態に依存します。修飾キーとの押下・解放順によってkey 属性に格納される値が変わります。code 属性は現在のキーボード状態に影響されない安定した値を提供します。

4.2.2. key とcodeの関係

key

key 属性は、現在のキーボードレイアウト（IMEも含む。デッドキーは固有のkey 値を持つ）を考慮したキーの意味を判定したい場合に使います。ユースケース例：修飾キー付きや修飾キー単体の検出（例：キーボードショートカットに反応するアクション）。

code

code 属性は、レイアウト変更無しでユーザーが押した物理キー自体を判定したい場合に使います。ユースケース例：WASDキー（ゲームの移動制御）やすべてのキーキャッチ（リモートデスクトップクライアントなど）。

4.2.3. codeの例

4.2.4. code と仮想キーボード

code 属性の有用性は、仮想キーボード（リモコンやコード入力型キーボードも含む）ではやや分かりづらい場合があります。一般的に、仮想（またはリモートコントロール）キーボードが標準キーボードのレイアウト・機能を模倣する場合は、適切にcode 属性も設定しなければなりません。標準キーボードのレイアウトを模倣しない場合は、code 属性を標準キーボード上の最も近い値に設定するか、未定義のままにしてもかまいません。

仮想キーボードで修飾状態に応じて異なる値を生成するキーの場合、code 値は端末が工場出荷時設定状態のときにボタンを押した場合に生成されるkey 値を基準にするべきです。

4.3. キーボードイベントkey値

キー値は、DOMStringとして、位置や状態に関係なく、キーボード上の任意のキーをその値で示すことができます。これらのkey値は、実装によって生成されたキーボードイベントの返値や、コンテンツ著者が希望入力の指定（キーボードショートカット等）で使う入力値として用いることができます。

有効なkey値の一覧は[UIEvents-Key]で定義されています。

key値は、key 属性を用いて、押されたキーの値を検出するのに利用できます。コンテンツ著者は、アルファベットの大文字・小文字、数字、記号、その他文字生成キーの文字値や、制御キー・修飾キー・ファンクションキーなど文字を生成しないキーのkey値を取得できます。これらの値は、特定の入力文字列の監視、修飾キー入力と他の入力（マウス等）の組み合わせ検出・動作、仮想キーボードの作成、その他さまざまな用途に利用できます。

key値は、文字列比較や、マークアップ属性値（HTMLのaccesskeyなど）としても利用でき、他の関連用途にも使えます。準拠したホスト言語は、コンテンツ著者がキー値として2種類の等価な文字列値（文字値またはkey値）のいずれも使えるようにすべきです。

実装はプラットフォームやキーボードレイアウトマッピングに関係なく、最も妥当な値をキーごとに利用しますが、コンテンツ著者はキーボードデバイスがそれらの値を生成できるとは限らないことを前提にすべきです。ショートカットキー組み合わせでkey値を使う場合は「数字やファンクションキー（F4、F5など）をアルファベットの代わりに使うことを検討してください」（[DWW95]）とされています。多くのレイアウトでそれらのキーは存在します。

key値は物理キーボード上の具体的なキーを示すものではなく、キーに印字された文字とも一致しません。key値は、現在の全ての有効キーと入力モード（シフトモード等）を考慮したイベントの値であり、キーボードのOSマッピングに従って実装に報告されます。つまり、QWERTYキーボードのOラベルのキーは、シフト無しで"o"、シフト付きで"O"となります。ユーザーはキーボードを任意のカスタム構成にマッピングできるため、著者はキーのシフト状態と文字表現（大文字・小文字）間の関係を前提とせず、key 属性の値だけを使うことが推奨されます。例えば、[UIEvents-Code]に示されたStandard「102」キーボードレイアウトは一例であり、他にも多数の標準・独自レイアウトが存在します。

デッドキー対応を簡略化するため、OSのキーボードマッピングでデッドキー状態を扱う場合、デッドキーシーケンスの現在状態はkey 属性では報告されません。代わりにkey値"Dead"が報告され、実装はデッドキーシーケンスの途中状態をdata 属性で持つ合成イベントを発生させます。前述の例のように、QWERTYキーボードのOラベルのキーは、デッドキー操作（ウムラウト付加）中に非シフトで"ö"、シフト時は"Ö"となります。

また、キーイベント状態とkey値の関係は1対1ではありません。特定のkey値を持つキーが複数存在する場合もあります。例：標準キーボードではShiftキー値を持つキーが複数あり（通常はlocation 値DOM_KEY_LOCATION_LEFTとDOM_KEY_LOCATION_RIGHTで区別）、8キー値も複数あり（location 値DOM_KEY_LOCATION_STANDARDとDOM_KEY_LOCATION_NUMPADで区別）、ユーザー設定のカスタムレイアウトでは任意のkey値が複数状態に割り当てられる場合もあります（location は標準レイアウト向けなので必ずしも意味のある区別を示せません）。

最後に、文字表現の意味は文脈依存で複雑です。例えばアスタリスク（星型）記号"*"は、文中で脚注や強調（文章の囲み）を表したり、ドキュメントやプログラムによっては乗算演算子とみなされたり、他の文書やプログラムでは乗算記号（"×"、Unicode値U+00D7）やラテン小文字"x"（多くのキーボードには乗算キーがなく、記号が似ているため）で表されることもあります。したがって、文字表現の意味や機能はこの現行標準の範囲外です。

4.3.1. 修飾キー

キーボード入力は修飾キーを用いてキーの通常の動作を変更します。 他のキーと同様に、修飾キーも下記例で示されるように keydown および keyup イベントを生成します。一部修飾キーは キーが押された／押し続けられている間に有効化されます（Alt, Control, Shift, AltGraph, Meta）。 他の修飾キーは状態によって有効化されます（CapsLock, NumLock, ScrollLock）。状態の変化は修飾キーが押される時に発生します。 KeyboardEvent インターフェイスはよく使われる修飾キーに便利な属性を提供します： ctrlKey, shiftKey, altKey, metaKey。 一部のOSはAltGraph修飾キーをAlt と Control の組み合わせで擬似的に実装しています。AltGraph修飾キーの直接利用が推奨されます。

keydownやkeyupイベントの値は、キー押下時の現在のキーボードレイアウトによって異なります。つまりUSレイアウトのvキーとアラビア語レイアウトのرキーは同じ物理キーでも異なるイベント値を生成します。同じ物理キーからのイベントを識別するにはcode 属性を使う必要があります。

一部の場合、修飾キーはキーイベントのkey 値を変更します。例えばMacOSキーボードでは「delete」ラベルのキーは未修飾時はWindowsと同じBackspaceキーとして動作しますが、Fn修飾時はDeleteキーとして動作し、key の値もその時の最適な機能に一致します。

4.3.2. デッドキー

一部のキーボード入力では、デッドキーを使って合成文字列を入力します。手書き入力と異なり、ユーザーはまずベース文字を入力するのではなく、デッドキーを押下して特殊状態に入り、限定された「正当な」ベース文字が入力された時のみ文字を出力します。

MacOSおよびLinuxのOSは入力メソッドでデッドキーを処理します。

すべてのキーボードレイアウト・マッピングにおけるデッドキーは、キー値Deadで表現されます。デッドキーを押下した際、ユーザーエージェントは合成イベントをディスパッチし、compositionupdateイベントのdata値は、デッドキー合成シーケンスの現在の文字値でなければなりません。

Unicode合成文字は常に手書き入力シーケンスの後に置かれ（合成文字が対応する文字の後ろに来る）、通常のデッドキー入力ではシーケンスが逆になる場合もあります（合成文字が対応する文字の前）。例えば、単語naïve（合成記号¨使用）は、Unicode上はnai¨veと順序付けされますが、入力時はna¨iveとなる場合もあります。キーストロークU+0302（合成サーカムフレックスアクセントキー）とU+0065（ラテン小文字eキー）をフランス語キーボードでフランス語マッピング・修飾なしで入力すると、Unicode文字"ê"（ラテン小文字eサーカムフレックス付）が生成され、Unicode正規化形式NFCが推奨する表現となります。

2番目の keydown イベント（ステップ5）では、key値（イベントが抑制されていない場合）は 通常 "e"（ラテン小文字eキー）にはならないことに注意してください。なぜなら、 この時点でユーザーエージェントに渡される値は既にデッドキー操作によって変更されているからです。

このプロセスは、ユーザーが（デッドキー押下後に）サポートされていない基底文字（アクティブなダイアクリティカル記号が利用できないもの）をタイプした場合、中断されることがあります：

4.3.3. 入力メソッドエディタ

この現行標準は、入力メソッドエディタ（IME）のモデルをCompositionEvent インターフェースとイベントを通じて含みます。 ただし、合成イベントとキーボードイベントは必ずしも1対1で対応しません。例えば、keydownでAcceptキー値を受け取っても、現在IMEで選択されているテキストが受理されたことを意味するわけではなく、単にキーストロークがあったことを示すだけです。IMEのAccept機能（多くのIMEではcompositionendイベントが発生）とは切り離されています。キーボードイベントだけでは入力メソッドエディタの現在状態は判断できません。状態はdata 属性（CompositionEvent インターフェース）で取得します。さらに、IMEシステムやデバイスは機能やキー割り当てが異なり、ConvertやAcceptキーが他のキーで代用される場合もあります。キーボードイベントは、デバイスのキーボードレイアウトマッピング後に生成されるイベントに対応します。

一部の実装やシステム構成では、IMEによって一部のキーイベントや値が抑制される場合があります。

以下は、日本語入力方式を使ってUnicode文字"市"（漢字、CJK統合漢字）を生成するキーシーケンス例です。この例はIMEがアクティブで日本語ローマ字入力モードになっていることを前提とします。ConvertやAcceptキーは、使用デバイスやIME構成により他のキーで代用される場合もあり（例：スペースキーU+0020やEnter）。

"詩"（詩）と"市"（市）は同音異義語（いずれも「し」）のため、ユーザーはConvertキーで適切な候補を選択する必要があります。

IME合成は下記のようにキャンセルすることもできます（条件は前例と同じ）。Cancelキーも、使用デバイスやIME構成により他のキー（例：U+001B（Escキー））で代用される場合があります。

一部の入力メソッドエディタ（MacOSなど）は、合成キャンセル前に合成データ属性へ空文字列を設定する場合があります。

4.3.3.1. 入力メソッドエディタモードキー

一部デバイスのキーは入力メソッドエディタ機能の起動や、アクティブな入力メソッドエディタのモード変更を目的としています。この目的のためのカスタムキーは、デバイスや言語モードごとに定義できます。この現行標準でこの目的で定義されているキーは、"Alphanumeric"、 "CodeInput"、 "FinalMode"、 "HangulMode"、 "HanjaMode"、 "Hiragana"、 "JunjaMode"、 "KanaMode"、 "KanjiMode"、 "Katakana"、 "Romaji"です。これらのキーが押された時、IMEがアクティブでなければ、該当モードでIMEが起動することが期待されます（利用可能な場合）。すでにIMEがアクティブな場合は、IMEが指定モードに切り替わるか、別のIMEが起動するか、あるいは無視される場合もあり、機種やアプリケーションごとに異なります。

現行標準ではIME用の操作を意図した他のキーも定義されています："Accept"、"AllCandidates"、 "Cancel"、"Convert"、"Compose"、"Zenkaku" （全角）、"Hankaku" （半角）、"NextCandidate"、 "NonConvert"、 "PreviousCandidate"です。これらのキーの機能は現行標準では定義されていません。IME機能の詳細については他の資料を参照してください。

IME機能付きキーはその目的専用に限らず、デバイスや実装ごとに他用途でも使われる場合があります。

4.3.4. デフォルトアクションとキャンセル可能なキーボードイベント

keydown イベントの デフォルト動作 をキャンセルしても、対応する keyup イベントには影響しませんが、対応する beforeinput や input（および keypress がサポートされている場合）イベントの生成を防止する必要があります。次の例は、USキーボードでUSマッピングを使って Unicode文字Q（ラテン大文字Q）を生成する一連のキー操作を示しています。

キーが修飾キーの場合でも、キーストロークは修飾キー状態の計算に必ず考慮されます。次の例もUSマッピングで ラテン大文字Q を生成する一連の操作です。

キーが複数キー操作列の一部（デッドキーや IME操作系列など）なら、デフォルト動作が keydown イベントでキャンセルされた場合のみ、そのキーストロークは無視する（計算から除外する）必要があります。keyup イベントで デッドキーをキャンセルしても、beforeinput や input イベントには影響しません。下記例はフランス配列のキーボードでフランスマッピング、修飾キーなしでデッドキー "Dead"（U+0302 サーカムフレックスアクセントキー）と "e"（U+0065、ラテン小文字eキー）を使用する操作例です：

5. 外部アルゴリズム

このセクションには本仕様で必要とされるアルゴリズムが記載されていますが、 本来は他仕様にて定義されるべきものです。

意図としては、このセクションが一時的な定義の置き場となっており、 いずれより適切な場所に移されたうえでこのセクション全体が削除されるべきです。

5.1. DOM コア アルゴリズム

以下のアルゴリズムは移設が必要です...どこかに。

5.2. PointerLock アルゴリズム

次のアルゴリズムは [PointerLock] 仕様に移設すべきです。

5.2.1. PointerLock のグローバル状態

5.2.1.1. Window レベルの状態

UA は Window 全体で共有される次の値を保持しなければなりません。

last mouse move 値（初期値は未定義）。直近の mousemove イベントの位置を記録します。

6. レガシーイベント初期化子

このセクションは規範的記述です。 以下の機能は既に廃止されており、レガシーソフトウェアとの互換性を必要とする ユーザーエージェントだけが実装すべきものです。

この仕様の初期バージョンでは、 インターフェイス上にイベント初期化メソッド（例：initMouseEvent）が含まれており、 多くの場合イベントオブジェクトの全属性を完全に初期化できない多数のパラメータを要求していました。 このため、基本のEvent インターフェイスから派生したイベントインターフェイスでは、 派生インターフェイスのそれぞれの初期化子を明示的に呼び出して イベントを完全初期化する必要がありました。

この標準の開発期間の長さもあり、いくつかの実装ではこの（現在は廃止された）初期化子に依存している場合があります。 完全性のために、これらレガシーイベント初期化子はこの付録で説明されています。

6.1. レガシーイベント初期化インターフェイス

このセクションは参考情報です

このセクションでは過去バージョンで導入されたレガシー初期化メソッドを記録します。

6.1.1. UIEventインターフェイスの初期化子

partial interface UIEvent {
  // この仕様で非推奨
  undefined initUIEvent(DOMString typeArg,
    optional boolean bubblesArg = false,
    optional boolean cancelableArg = false,
    optional Window? viewArg = null,
    optional long detailArg = 0);
};

initUIEvent(typeArg)

UIEvent オブジェクトの属性を初期化します。 このメソッドは initEvent() と同じ振る舞いをします。

initUIEvent メソッドは非推奨ですが、 広く展開されている実装との後方互換性のためにサポートされています。

DOMString typeArg

このパラメータの説明については initEvent() を参照してください。

boolean bubblesArg

このパラメータの説明については initEvent() を参照してください。

boolean cancelableArg

このパラメータの説明については initEvent() を参照してください。

Window? viewArg

view を指定します。 この値は null であってもよい (MAY)。

long detailArg

detail を指定します。

6.1.2. KeyboardEventインターフェイスの初期化子

このレガシーKeyboardEvent初期化子の引数リストは detailArg を含まず（他の初期化子にはある） locale 引数を追加しています。 既存実装との互換性保持のためこの不一致を維持する必要があります。

partial interface KeyboardEvent {
  // この仕様で導入（および非推奨）
  undefined initKeyboardEvent(DOMString typeArg,
    optional boolean bubblesArg = false,
    optional boolean cancelableArg = false,
    optional Window? viewArg = null,
    optional DOMString keyArg = "",
    optional unsigned long locationArg = 0,
    optional boolean ctrlKey = false,
    optional boolean altKey = false,
    optional boolean shiftKey = false,
    optional boolean metaKey = false);
};

initKeyboardEvent(typeArg)

KeyboardEvent の KeyboardEvent オブジェクトの属性を初期化します。This method has the same behavior as UIEvent.initUIEvent(). detail の値は未定義のままです。

initKeyboardEvent メソッドは非推奨です。

DOMString typeArg

このパラメータの説明については initEvent() メソッドを参照してください。

boolean bubblesArg

このパラメータの説明については initEvent() メソッドを参照してください。

boolean cancelableArg

このパラメータの説明については initEvent() メソッドを参照してください。

Window? viewArg

view を指定します。 この値は null であってもよい(MAY)。

DOMString keyArg

key を指定します。

unsigned long locationArg

location を指定します。

boolean ctrlKey

Control キー修飾子が有効かどうかを指定します。

boolean altKey

Alt キー修飾子が有効かどうかを指定します。

boolean shiftKey

Shift キー修飾子が有効かどうかを指定します。

boolean metaKey

Meta キー修飾子が有効かどうかを指定します。

6.1.3. CompositionEventインターフェイスの初期化子

このレガシーCompositionEvent初期化子の引数リストは detailArg を含まず（他の初期化子にはある） locale 引数を追加します。 既存実装との互換性保持のためこの不一致を維持する必要があります。

partial interface CompositionEvent {
  // この仕様で導入（および非推奨）
  undefined initCompositionEvent(DOMString typeArg,
    optional boolean bubblesArg = false,
    optional boolean cancelableArg = false,
    optional WindowProxy? viewArg = null,
    optional DOMString dataArg = "");
};

initCompositionEvent(typeArg)

CompositionEvent オブジェクトの属性を初期化します。 このメソッドは UIEvent.initUIEvent() と同じ振る舞いをします。detail の値は未定義のままです。

initCompositionEvent メソッドは非推奨です。

DOMString typeArg

initEvent() メソッドを参照してこのパラメータの説明を確認してください。

boolean bubblesArg

initEvent() メソッドを参照してこのパラメータの説明を確認してください。

boolean cancelableArg

initEvent() メソッドを参照してこのパラメータの説明を確認してください。

Window? viewArg

view を指定します。 この値は null であってもよい (MAY)。

DOMString dataArg

data を指定します。

7. レガシーキー・マウスイベント属性

このセクションは規範外です。以下の属性は廃止されており、レガシーなソフトウェアがこれらのキーボードイベントを必要とする場合に限定して ユーザーエージェントが実装すべきです。

これらの機能は正式に仕様化されたことはなく、現在のブラウザ実装間でも大きく異なります。
レガシーコンテンツ（スクリプトライブラリ等含む）が ユーザーエージェント判別に依存し挙動を変えるケースが多く、 こうしたレガシー属性やイベントの仕様化はむしろ互換性問題を引き起こしかねません。
また、国際化やアクセシビリティにも適していません。

したがって、この仕様はキーボード入力を扱う際によく用いられたイベントや属性を規範的に定義しませんが、 ユーザーエージェントによるレガシーコンテンツ互換のため 実装されている場合があります。著者は key 属性のみを用い、 charCode や keyCode 属性は使用しないことが推奨されます。

ただしこれら機能の現状と規範イベント属性との関係を記録する目的で、 本セクションは説明的記述を記載します。 もし実装がこれらの属性やイベントをサポートする場合、本セクションの定義に従うことを推奨します。

7.1. レガシー UIEvent 補助インターフェイス

このセクションは規範外です

ユーザーエージェントは which 属性を伝統的に備えており、 KeyboardEvent や MouseEvent の補助的イベント情報記録に利用されてきました。

以前は which 属性が KeyboardEvent や MouseEvent に直接定義されていましたが、 現在は UIEvent で共有される属性となっています。

7.1.1. インターフェイス UIEvent（補助）

部分 UIEvent インターフェイスは UIEvent インターフェイスの説明的拡張であり、which 属性を追加します。

partial interface UIEvent {
  // The following support legacy user agents
  readonly attribute unsigned long which;
};

which, 型 unsigned long（読み取り専用）

MouseEvent の場合、button+1 の値が入ります。 KeyboardEvent の場合、押されたキーの修飾無し識別子に対応するシステム/実装依存の数値コードが入ります。多くの場合、値は keyCode と同じです。

7.1.2. 辞書 UIEventInit（補助）

UIEvent で which をサポートするなら UIEventInit 辞書にも以下メンバーを追加すべきです。

部分 UIEventInit 辞書は UIEventInit 辞書の説明的拡張であり、 which メンバーを追加し、 属性初期化用に使えます。

partial dictionary UIEventInit {
  unsigned long which = 0;
};

which, 型 unsigned long（初期値0）

which 属性を UIEvent に初期化します。

7.2. レガシー KeyboardEvent 補助インターフェイス

このセクションは規範外です

キーボードのブラウザサポートは keyCode、 charCode、 および UIEvent のwhich という3つのアドホック属性に 伝統的に依存してきました。

これら3つの属性はすべて、押されたキーの何らかの側面を表す数値コードを返します：keyCode はキー自体のインデックスです。charCode は文字キーのASCII値を表します。 which は利用可能な場合は文字値を、それ以外はキーのインデックスを返します。これらの属性の値や属性の利用可否は、 プラットフォームやキーボードの言語・レイアウト、ユーザー エージェント、バージョン、そしてイベントタイプによって一貫性がありません。

7.2.1. インターフェイス KeyboardEvent（補助）

partial KeyboardEvent インターフェースは、KeyboardEvent インターフェースの情報的な拡張であり、 charCode および keyCode 属性を追加するものです。

部分 KeyboardEvent インターフェイスはこの拡張をサポートする実装で createEvent() メソッド呼び出しで取得できます。

partial interface KeyboardEvent {
  // The following support legacy user agents
  readonly attribute unsigned long charCode;
  readonly attribute unsigned long keyCode;
};

charCode, 型 unsigned long（読み取り専用）

charCode は keypress イベントで文字入力を生成した場合にその文字値を保持します。 値はその文字のUnicode参照番号（コードポイント）になります （例：印字文字なら event.charCode = event.key.charCodeAt(0)）。 keydown や keyup イベントでは値 0 となります。

keyCode, 型 unsigned long（読み取り専用）

keyCode は 押されたキーの修飾無し識別子に対応するシステム/実装依存の数値コードを保持します。 key 属性と異なり、値の集合はこの仕様では規範的に定義されません。 通常 keyCode の値は ASCII [RFC20][US-ASCII] または Windows 1252 [WIN1252] の10進コードポイントとなるべきですが、 他の適切な文字集合の場合もあります。 実装でキー識別不能な場合は 0 を用います。

詳細は § 7.3 レガシーキーモデル を参照してください。 keyCode の値判定方法について説明があります。

7.2.2. 辞書 KeyboardEventInit（補助）

KeyboardEvent で keyCode や charCode をサポートするなら KeyboardEventInit 辞書にも以下メンバーを追加すべきです。

部分 KeyboardEventInit 辞書は KeyboardEventInit 辞書の説明的拡張であり、 charCode や keyCode メンバーを追加し、 属性初期化用に使えます。

partial dictionary KeyboardEventInit {
  // The following support legacy user agents
  unsigned long charCode = 0;
  unsigned long keyCode = 0;
};

charCode, 型 unsigned long（初期値0）

charCode 属性を KeyboardEvent にイベントの文字のUnicodeコードポイントで初期化します。

keyCode, 型 unsigned long（初期値0）

keyCode 属性を KeyboardEvent に押されたキーの修飾無し識別子に対応するシステム/実装依存の数値コードで初期化します。

7.3. レガシーキーのモデル

このセクションは非規範的です

イベントタイプごとにこれら属性で公開される値は実装によって異なります。実装はkeyCode プロパティで仮想キーコードと文字コードを両方公開してもよく（混合モデル）、またはkeyCode とcharCode を分離して報告する（分離モデル）こともあります。

7.3.1. keyCode の算出方法（keydown／keyup）

keyCode （keydown／keyup）は次のように算出します：

• OSのイベント情報から仮想キーコードを読み取る（利用可能な場合）。

• IMEがキー入力を処理しておりイベントがkeydownなら229を返す。

• 修飾なしで押下した場合に数字文字（0-9）を挿入するなら、その数字文字のASCIIコードを返す。

• 修飾なしで押下した場合にa-zの小文字を挿入するなら、対応する大文字のASCIIコードを返す。

• OS・プラットフォーム向けのキーコード変換テーブルがあるなら、対応値を検索し、指定値があればそれを返す。

• 実装固有方法で判断したキー機能が§ 7.3.3 固定仮想キーコード表のキーに該当するなら、対応するキーコードを返す。

• OSから仮想キーコードを返す。

• キーコードが見つからなかった場合は0を返す。

7.3.2. keyCode の算出方法（keypress）

keyCode （keypress）は次のように算出します：

• 混合モデルの場合、入力される文字のUnicodeコードポイントをkeyCodeに設定する。

• 分離モデルの場合、keyCodeを0に設定する。

7.3.3. 固定仮想キーコード

以下のキーはデスクトップシステムでキーボードレイアウトに関係なく仮想キーコードが通常変わりません：

7.3.4. オプション固定仮想キーコード

以下の記号文字はキーボードレイアウトによって仮想コードが変化する場合もありますが、US英語キーボードレイアウトを期待するレガシーコンテンツとの互換性のため、これらの値で報告する方がより互換性があります：

8. レガシー イベントタイプ

このセクションは規範的です。以下のイベントタイプは廃止されており、 レガシーソフトウェアとの互換性を必要とするユーザーエージェントのみが実装すべきです。

このセクションの目的は、これらの機能の現状と規範的なイベントとの関係を記録することです。 これらのイベントをサポートする実装においては、本セクションに記載されている定義を使用することが推奨されます。

8.1. レガシー UIEvent イベント

8.1.1. レガシー UIEvent イベントタイプ

8.1.1.1. DOMActivate

ユーザー エージェントは、ボタン、リンク、またはその他の状態変更要素が活性化されたときにこのイベントを発火しなければなりません。

DOMActivate イベントタイプは参照と完全性のために本仕様で定義されていますが、 本仕様はこのイベントタイプの使用を関連するイベントタイプ click の使用に置き換えることを非推奨とします。他の仕様は後方互換のために独自に DOMActivate イベントタイプを定義・維持する場合があります。

DOMActivate と click は完全に同等ではありませんが、 実装上の挙動は、click のイベントタイプが、DOMActivate の設計時に想定された重要なアクセシビリティ要件を包含するように発展しており、 より広く実装されています。コンテンツ作者は、最大のアクセシビリティを確保するために関連する click イベントタイプを使用し、関連する mousedown や mouseup イベントタイプの代わりに利用することを推奨します。

もし実装が DOMActivate イベントタイプをサポートする場合、 実装はclick イベントのデフォルト動作として DOMActivate イベントを発火すべきです。ただし、そのような実装は任意の発生に対して関連するアクティベーション動作を一度だけ開始するべきです。

多くのユーザーエージェントでの DOMActivate の相互運用的なサポートをあてにしないでください。代わりに幅広い実装サポートがあるため、よりアクセシブルな振る舞いを提供する click イベントタイプを使用するべきです。

DOMActivate イベントタイプは本仕様では非推奨です。

8.1.2. アクティベーションイベント順序

もし DOMActivate イベントがユーザーエージェントによりサポートされるなら、 以下のように関連イベントは互いに対して定まった順序で発火されなければなりません（関係のあるイベントのみ列挙）：

もしフォーカスされた要素がキーイベントにより活性化されるなら、通常のイベント順序は次のとおりです（関係のあるイベントのみ列挙）：

8.2. レガシー FocusEvent イベント

8.2.1. レガシー FocusEvent イベントタイプ

8.2.1.1. DOMFocusIn

ユーザー エージェントは、イベントターゲットがフォーカスを受け取るときにこのイベントを発火しなければなりません。フォーカスはこのイベントタイプの発火前に要素に与えられていなければなりません。 このイベントタイプは focus イベントタイプの後で発火されなければなりません。

DOMFocusIn イベントタイプは参照と完全性のために本仕様で定義されていますが、本仕様はこのイベントタイプの使用を関連するイベントタイプ focus および focusin の使用に置き換えることを非推奨とします。

8.2.1.2. DOMFocusOut

ユーザー エージェントは、イベントターゲットがフォーカスを失うときにこのイベントを発火しなければなりません。フォーカスはこのイベントタイプの発火前に要素から取り除かれていなければなりません。 このイベントタイプは blur イベントタイプの後で発火されなければなりません。

DOMFocusOut イベントタイプは参照と完全性のために本仕様で定義されていますが、本仕様はこのイベントタイプの使用を関連するイベントタイプ blur および focusout の使用に置き換えることを非推奨とします。

8.2.2. レガシー FocusEvent イベント順序

以下は要素間でフォーカスが移る際の典型的なイベント順です。非推奨の DOMFocusIn および DOMFocusOut イベントを含みます。示される順序は、最初にフォーカスされている要素がないことを前提としています。

8.3. レガシー KeyboardEvent イベント

keypress イベントは、 伝統的にキーイベントを捕捉し、キー押下の効果によって DOM が更新される前に処理するための方法でした。keypress イベントを利用するコードは通常、レガシーな charCode, keyCode, および which 属性に依存しています。

注意: keypress イベントはキーイベント特有のものであり、より一般的なイベント列である beforeinput および input イベントに置き換えられています。これらの新しい input イベントはキーボード動作に特化したものではなく、元の入力源にかかわらずユーザー入力を捕捉するために使用できます。

8.3.1. レガシー KeyboardEvent イベントタイプ

8.3.1.1. keypress

もしユーザーエージェントがこのイベントをサポートするなら、 このイベントはキーが押されたときに（そのキーが通常文字値を生成する場合に限り）発火されなければなりません。 keypress イベントタイプはデバイス依存であり、 入力デバイスの能力や OS 上でのマッピングに依存します。

このイベントタイプは キー割り当て の後で生成されなければなりません。 入力方式エディタ を使用している場合は発火してはなりません。

もしこのイベントがキャンセルされた場合、input イベントの発火を防ぐべきであり、加えてデフォルト動作もキャンセルされるべきです。

作者は beforeinput イベントを keypress イベントの代わりに使用するべきです。

keypress イベントは伝統的に物理キーではなく 文字値の検出に関連付けられており、一部の構成ではすべてのキーで利用できない場合があります。

keypress イベントタイプは 参照と完全性のために本仕様で定義されていますが、本仕様はこのイベントタイプの使用を非推奨とします。編集コンテキストでは、代わりに beforeinput を購読することができます。

8.3.2. keypress イベント順序

keypress イベントタイプは、 同一キーに関連する keydown イベントの後かつ keyup イベントの前に発火されなければなりません。

keypress イベントタイプは、 同一キーに関連する beforeinput イベントの後かつ input イベントの前に発火されなければなりません。

keypress イベントをサポートするユーザーエージェントでのキーイベント列は、次の例で示されます: