1.2. 適合性
`この節は規範的である。^em ◎ This section is normative.
この仕様における，次に挙げる~keywordは、 `RFC2119$r に則って解釈するとする ⇒＃ “〜しなければ（〜しては）ナラナイ” （ `MUST^en, `MUST NOT^en ）, “要求される” （ `REQUIRED^en ）, “〜するベキである（でない）” （ `SHOULD^en, `SHOULD NOT^en ）, “推奨される” （ `RECOMMENDED^en ）, “〜してもヨイ” （ `MAY^en ）†, “任意選択” （ `OPTIONAL^en ） ◎ Within this specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
【† 原文の `MAY^en は、 この意味の `MAY^en でないもの（許可でない “`may^en” ）も多量に含まれている （ほぼすべて~~機械的に大文字の “`MAY^en” にされている）ので、 それらは和訳には反映されていない。 】
この仕様は `DOM-Level-3-Core$r 仕様 の文脈で解され，~DOM実装に対する一般的な考慮点が適用される。 【！不要：例えば，名前空間~URI$の取扱いは `XML Namespaces＠~TR/DOM-Level-3-Core/core.html#Namespaces-Considerations$ にて論じられる。】 適合性についての追加的な情報は、 `DOM-Level-3-Core$r `§ 適合性＠~TR/DOM-Level-3-Core/introduction.html#ID-Conformance$ を見よ。 `~UA$は、［ この仕様に適合するために，別の仕様に全面的に適合すること ］は要求されないが，［ その中の，この仕様が~~参照している部分 ］には適合するモノトスル（例： 適合~UI~Events `~UA$は、［ `WebIDL$r にて定義される `DOMString^c ~data型 ］を~supportするモノトスルが，［ ~UI~Eventsに適合するために， `WebIDL$r にて定義される あらゆる［ ~method／~data型 ］を~supportする ］必要はない）。 ◎ This specification is to be understood in the context of the DOM Level 3 Core specification [DOM-Level-3-Core] and the general considerations for DOM implementations apply. For example, handling of namespace URIs is discussed in XML Namespaces. For additional information about conformance, please see the DOM Level 3 Core specification [DOM-Level-3-Core]. A user agent is not required to conform to the entirety of another specification in order to conform to this specification, but it MUST conform to the specific parts of any other specification which are called out in this specification (e.g., a conforming UI Events user agent MUST support the DOMString data type as defined in [WebIDL], but need not support every method or data type defined in [WebIDL] in order to conform to UI Events).
この仕様が定義する適合性は、 以下の各下位節に挙げる~class — `~UA$／仕様／内容~作者 — を対象にする： ◎ This specification defines several classes of conformance for different user agents, specifications, and content authors:
1.2.1. ~Web~browserその他の［動的／対話的］な~UA
［ 動的／対話的 ］な`~UA$ — ここでは単に “~browser” と総称する（ ~Web~browser, AT（ `Accessibility Technology^en — ~accessibility技術）~app, その他の類似な~programなど） — が~UI~Eventsに適合するためには、 次を~supportする必要がある： ◎ A dynamic or interactive user agent, referred to here as a "browser" (be it a Web browser, AT (Accessibility Technology) application, or other similar program), conforms to UI Events if it supports:
- `DOM-Level-3-Core$r にて定義される中核~module。 ◎ the Core module defined in [DOM-Level-3-Core]
- この仕様にて定義される すべての［ ~interface, ~event ］, および それらに結付けられた すべての［ ~method, 属性, 意味論 ］。 ただし、`非推奨に$されたものは除く （適合~UAは、後方-互換性を得るために，非推奨にされた［ ~interface／~event／~API ］を実装してもヨイが，適合するためには要求されない）。 ◎ all the interfaces and events with their associated methods, attributes, and semantics defined in this specification with the exception of those marked as deprecated (a conforming user agent MAY implement the deprecated interfaces, events, or APIs for backwards compatibility, but is not required to do so in order to be conforming)
- ［ `UIEVENTS-KEY$r ／ `UIEVENTS-CODE$r ］にて定義される［ `key$m ／ `code$m ］値の完全な集合（~platform可用性の~subjectになる）。 ◎ the complete set of key and code values defined in [UIEvents-Key] and [UIEvents-Code] (subject to platform availability), and
- この仕様にて定義される，他のすべての規範的な要件。 ◎ all other normative requirements defined in this specification.
適合~browserは、 与えられた `EventTarget$I に適切な~eventを， その`~event型$に定義された条件を満たしたときに配送するモノトスル。 ◎ A conforming browser MUST dispatch events appropriate to the given EventTarget when the conditions defined for that event type have been met.
この文書にて指定される［ ~interface, 関係する`~event型$ ］を実装する~browserは、 特定的に~UI~Eventsに適合する。 ◎ A browser conforms specifically to UI Events if it implements the interfaces and related event types specified in this document.
適合~browserは、 この仕様に述べる方式で［ ~scripting／ 宣言的な対話性／~eventを検出して発火する他の何らかの手段 ］を~supportする, かつ その`~event型$用に指定された~APIを~supportするモノトスル。 ◎ A conforming browser MUST support scripting, declarative interactivity, or some other means of detecting and dispatching events in the manner described by this specification, and MUST support the APIs specified for that event type.
適合~browserは、 この仕様にて`非推奨に$された特能を — 他のすべての適合性~判定基準を満たすことに加えて，既存の内容との後方-互換性を得るために — 実装してもヨイが，実装しないことが奨励される。 ◎ In addition to meeting all other conformance criteria, a conforming browser MAY implement features of this specification marked as deprecated, for backwards compatibility with existing content, but such implementation is discouraged.
適合~browserは、［ ~UI~Eventsにて定義される［ ~interface／~event／その他の特能 ］を利用する，この仕様には見出されない特能 ］も~supportして，その実装に適切な追加的な［ ~interface／`~event型$ ］を実装してもヨイ。 そのような特能は、 将来の仕様にて標準~化され得る。 ◎ A conforming browser MAY also support features not found in this specification, but which use the interfaces, events, or other features defined in this specification, and MAY implement additional interfaces and event types appropriate to that implementation. Such features can be later standardized in future specifications.
~browserは、 この仕様から要求される事項すべてに適合していない限り， ~UI~Eventsに適合していると主張してはナラナイ。 そのような実装は、 この仕様の一部の事項に適合するならば， それらの特定の事項に適合していると主張してもヨイ。 ◎ A browser which does not conform to all required portions of this specification MUST NOT claim conformance to UI Events. Such an implementation which does conform to portions of this specification MAY claim conformance to those specific portions.
適合~browserは、 この仕様における各種~IDL片に対しても， `WebIDL$r 仕様に述べられる適合~実装でなければナラナイ。 ◎ A conforming browser MUST also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification [WebIDL].
1.2.4. 仕様／~host言語
［ 仕様／`~host言語$ ］は、［ ~event~flowの仕組み, ~interface, ~event, `DOM$r にて定義される他の特能 ］を参照して利用する, かつ［ これらの特能を互換でない仕方で拡張しない ］ならば，~UI~Eventsに適合する。 ◎ A specification or host language conforms to UI Events if it references and uses the event flow mechanism, interfaces, events, or other features defined in [DOM], and does not extend these features in incompatible ways.
［ 仕様／`~host言語$ ］は、 この文書にて指定される［ ~interface, 関係する`~event型$ ］を参照して利用するならば，特定的に~UI~Eventsに適合する。 適合~仕様は、 この仕様の［ ~interface／`~event型$ ］に 相反したり競合しない方式で，その仕様に適切な［ ~interface／`~event型$ ］を追加的に定義したり, この仕様の［ ~interface／`~event型$ ］を拡張してもヨイ。 ◎ A specification or host language conforms specifically to UI Events if it references and uses the interfaces and related event types specified in this document. A conforming specification MAY define additional interfaces and event types appropriate to that specification, or MAY extend the UI Events interfaces and event types in a manner that does not contradict or conflict with the definitions of those interfaces and event types in this specification.
~UI~Eventsを参照する各［ 仕様／`~host言語$ ］（順不同）は、 この仕様にて`非推奨に$された特能を［ 利用する／推奨する ］ことなく，［ 当の特能~用の置換として，この仕様にて指示されるもの ］を（可用なら）［ 利用する／推奨する ］ベキである。 ◎ Specifications or host languages which reference UI Events SHOULD NOT use or recommend features of this specification marked as deprecated, but SHOULD use or recommend the indicated replacement for that the feature (if available).
6. 旧来の~event初期化子
`この節は規範的である。^em 以下の特能は、廃用にされた。 これらは、旧来の~softwareとの互換性が要求される`~UA$に限り，実装されるべきである。 ◎ This section is normative. The following features are obsolete and should only be implemented by user agents that require compatibility with legacy software.
この仕様の早期の~versionには、 ~interface上に，~parameterの長〜い~listが要求されるような初期化~method （例えば `initMouseEvent()$m ） が含まれていた — それは、ほとんどの事例で，~event~objの属性すべてを全部的に初期化しない。 このため、 基本 `Event$I ~interfaceから派性された~event~interfaceを実装する~eventを全部的に初期化するためには， 派性された`それぞれの^em ~interfaceの初期化子を明示的に~callすることが要求されていた。 ◎ Early versions of this specification included an initialization method on the interface (for example initMouseEvent) that required a long list of parameters that, in most cases, did not fully initialize all attributes of the event object. Because of this, event interfaces which were derived from the basic Event interface required that the initializer of each of the derived interfaces be called explicitly in order to fully initialize an event.
`UIEvent$I の属性を すべて初期化するためには、 2 つの初期化子~method［ `initEvent()$m, `initUIEvent()$m ］の~callを要する。 ◎ Initializing all the attributes of a UIEvent requires calls to two initializer methods: initEvent and initUIEvent.
この標準は長く開発され続けていたため、 これらの（今や非推奨dな）初期化子~methodに依存している実装もある。 完全さのため，これらの旧来の~event初期化子をこの付録にて述べる。 ◎ Due in part to the length of time in the development of this standard, some implementations MAY have taken a dependency on these (now deprecated) initializer methods. For completeness, these legacy event initializers are described in this Appendix.
6.1. 旧来の~event初期化子~interface
◎非規範的この節では、この仕様の早期の~versionにて導入されたが 今や`非推奨に$された，旧来の初期化子~methodを文書化する。 ◎ This section documents legacy initializer methods that were introduced in earlier versions of this specification.
6.1.1. `UIEvent^I ~interface用の初期化子
partial interface `UIEvent$I {
/*
この仕様により非推奨にされた
◎
Deprecated in this specification
*/
`undefined$ `initUIEvent@m(~MANYARGS);
};
~OMIT0
6.1.2. `MouseEvent^I ~interface用の初期化子
partial interface `MouseEvent$I {
/*
この仕様により非推奨にされた
◎
Deprecated in this specification
*/
`undefined$ `initMouseEvent@m(~MANYARGS);
};
~OMIT0
6.1.3. `KeyboardEvent^I ~interface用の初期化子
注記： この旧来の `KeyboardEvent^I 初期化子に対する引数~listは、 （他の初期化子には在る） %detailArg 引数を含まない代わりに， %locale 引数が追加されている。 既存の実装との互換性のため、 この不整合は保全される必要がある。 ◎ The argument list to this legacy KeyboardEvent initializer does not include the detailArg (present in other initializers) and adds the locale argument; it is necessary to preserve this inconsistency for compatibility with existing implementations.
partial interface `KeyboardEvent$I {
/*
この仕様により導入されたが非推奨にされた
◎
Originally introduced (and deprecated) in this specification
*/
`undefined$ `initKeyboardEvent@m(~MANYARGS);
};
~OMIT0
6.1.4. `CompositionEvent^I ~interface用の初期化子
注記： この旧来の `CompositionEvent^I 初期化子に対する引数~listは、 （他の初期化子には在る） %detailArg を含まない代わりに， %locale 引数が追加されている。 既存の実装との互換性のため、 この不整合は保全される必要がある。 ◎ The argument list to this legacy CompositionEvent initializer does not include the detailArg (present in other initializers) and adds the locale argument; it is necessary to preserve this inconsistency for compatibility with existing implementations.
partial interface `CompositionEvent$I {
/*
この仕様により導入されたが非推奨にされた
◎
Originally introduced (and deprecated) in this specification
*/
`undefined$ `initCompositionEvent@m(~MANYARGS);
};
~OMIT0
7. 旧来の［~UIkey／~mouse］属性
◎非規範的以下の属性は、廃用にされた。 これらは、［ これらの~keyboard~eventが要求される旧来の~software ］との互換性が要求される`~UA$に限り，実装されるべきである。 ◎ This section is non-normative. The following attributes are obsolete and should only be implemented by user agents that require compatibility with legacy software that requires these keyboard events.
これらの特能は，正式には指定されたことがなく、 現在の~browser実装は，有意な仕方で変わる。 ~script~libraryも含む多数の旧来の内容が `~UA$の検出-法に依拠し, それに則って動作することから、 これらの旧来の属性や~eventを正式~化するような どの試みも，［ それが何かを固定化したり可能化するに伴い，内容を壊す~riskをもたらす ］ことを意味する。 加えて，これらの属性は、 国際的~用法に相応でなく，~accessibilityへの懸念にも取組まない。 ◎ These features were never formally specified and the current browser implementations vary in significant ways. The large amount of legacy content, including script libraries, that relies upon detecting the user agent and acting accordingly means that any attempt to formalize these legacy attributes and events would risk breaking as much content as it would fix or enable. Additionally, these attributes are not suitable for international usage, nor do they address accessibility concerns.
したがって，この仕様は、 ~keyboard入力を取扱うために共通的に使役される~eventや属性を規範的に定義しない — 旧来の内容との互換性のために`~UA$内に在ってもヨイが。 作者は、［ `charCode$m ／ `keyCode$m ］属性の代わりに `key$m 属性を利用するベキである。 ◎ Therefore, this specification does not normatively define the events and attributes commonly employed for handling keyboard input, though they MAY be present in user agents for compatibility with legacy content. Authors SHOULD use the key attribute instead of the charCode and keyCode attributes.
しかしながら，これらの特能の現在の状態, および規範的な［ ~event／属性 ］と これらとの関係を文書化する目的で、 この節にて，参考な記述を供する。 これらの属性や~eventを~~実際に~supportする実装には、 この節にて供される定義を利用することを勧める。 ◎ However, for the purpose of documenting the current state of these features and their relation to normative events and attributes, this section provides an informative description. For implementations which do support these attributes and events, it is suggested that the definitions provided in this section be used.
7.1. 旧来の `UIEvent^I 補足的~interface
◎非規範的伝統的に，`~UA$は、［ `KeyboardEvent$I ／ `MouseEvent$I ］が補足的な~event情報を記録できるよう， `which$m 属性を含めていた。 ◎ User agents have traditionally included a which attribute so that KeyboardEvents and MouseEvents could record supplemental event info.
注記： この仕様の以前の~versionでは、 別々な `which$m 属性を［ `KeyboardEvent$I, `MouseEvent$I ］上に直に定義していた — `which$m 属性を `UIEvent$I 上に定義して共有させるのでなく。 ◎ Previous versions of this specification defined separate which attributes directly on KeyboardEvent and MouseEvent rather than having a shared which attribute defined on UIEvent.
7.1.1. `UIEvent^I ~interface（補足的）
`UIEvent^I 部分的~interfaceは、 `UIEvent$I ~interfaceの参考な拡張であり， `which$m 属性を追加する，。 ◎ The partial UIEvent interface is an informative extension of the UIEvent interface, which adds the which attribute.
partial interface `UIEvent$I {
/*
次に挙げるものは旧来の~UAを~supportする
◎
The following support legacy user agents
*/
readonly attribute `unsigned long$ `which$m;
};
- `which@m ◎ which, of type unsigned long, readonly
- `MouseEvent$I 用には、 この属性は ( `button$m の値 ~PLUS 1 ) に等しくなる。 `KeyboardEvent$I 用には、 この属性は［ 押された~UIkeyに結付けられた, 未修飾な, ［ ~system／実装 ］に依存する識別子 ］を~~表す数量的な~codeを保持する。 大方の事例では、 値は `keyCode$m と一致する。 ◎ For MouseEvents, this contains a value equal to the value stored in button+1. For KeyboardEvents, this holds a system- and implementation-dependent numerical code signifying the unmodified identifier associated with the key pressed. In most cases, the value is identical to keyCode.
7.1.2. `UIEventInit^I 辞書（補足的）
`UIEvent$I にて `which$m 用の~supportを含める~browserは、 `UIEventInit$I 辞書に次の~memberも追加するべきである。 ◎ Browsers that include support for which in UIEvent should also add the following members to the UIEventInit dictionary.
`UIEventInit^I 部分的~辞書は、 `UIEventInit$I 辞書の参考な拡張であり， `which$m ~member を追加する — それは、対応する `UIEvent^I 属性を初期化する。 ◎ The partial UIEventInit dictionary is an informative extension of the UIEventInit dictionary, which adds the which member to initialize the corresponding UIEvent attributes.
partial dictionary `UIEventInit$I {
`unsigned long$ `which$d = 0;
};
- `which@d ◎ which, of type unsigned long, defaulting to 0
- `UIEvent$I の `which$m 属性を初期化する。 ◎ Initializes the which attribute of the UIEvent.
7.2. 旧来の `KeyboardEvent^I 補足的~interface
~browserによる~keyboardの~supportは、 伝統的に 3 個の場当的な属性［ `keyCode$m, `charCode$m, `UIEvent^I の `which$m ］に依拠している。 ◎ Browser support for keyboards has traditionally relied on three ad-hoc attributes, keyCode, charCode, and UIEvent's which.
これらの属性は、 いずれも，押された~UIkeyのある側面を表現する数量的な~codeを返す：
- `keyCode$m は，~UIkey自身の~index。
- `charCode$m は， 文字~UIkeyの~ASCII値。
- `which$m は，可用な所では文字~値／他の場合は~UIkey~index。
これらの属性に対する値, および 属性の可用性は、［ ~platform, ~keyboardの言語と~layout, `~UA$, ~version, 各種~event型 ］に渡り，一貫でない。
◎ All three of these attributes return a numerical code that represents some aspect of the key pressed: keyCode is an index of the key itself. charCode is the ASCII value of the character keys. which is the character value where available and otherwise the key index. The values for these attributes, and the availability of the attribute, is inconsistent across platforms, keyboard languages and layouts, user agents, versions, and even event types.7.2.1. `KeyboardEvent^I ~interface（補足的）
`KeyboardEvent^I 部分的~interfaceは、 `KeyboardEvent$I ~interfaceの参考な拡張であり，［ `charCode$m, `keyCode$m ］属性を追加する。 ◎ The partial KeyboardEvent interface is an informative extension of the KeyboardEvent interface, which adds the charCode and keyCode attributes.
`KeyboardEvent^I 部分的~interfaceは、 実装がこの拡張を~supportするならば， `KeyboardEvent^l を引数に `createEvent()$m ~methodを~callして得せる。 ◎ The partial KeyboardEvent interface can be obtained by using the createEvent() method call in implementations that support this extension.
partial interface `KeyboardEvent$I {
/*
次に挙げるものは旧来の~UAを~supportする
◎
The following support legacy user agents
*/
readonly attribute `unsigned long$ `charCode$m;
readonly attribute `unsigned long$ `keyCode$m;
};
- `charCode@m ◎ charCode, of type unsigned long, readonly
- この属性は、 文字~入力を生成する `keypress$et ~event用に，文字~値を保持する。 その値は、 その文字の~Unicode符号位置をとる （例：印字可能な文字に対しては， `charCode^m は `event.key.charCodeAt(0)^m と同じになる）。 `keydown$et ／ `keyup$et ~eventに対する `charCode^m の値は， 0 である。 ◎ charCode holds a character value, for keypress events which generate character input. The value is the Unicode reference number (code point) of that character (e.g. event.charCode = event.key.charCodeAt(0) for printable characters). For keydown or keyup events, the value of charCode is 0.
- `keyCode@m ◎ keyCode, of type unsigned long, readonly
- この属性は、 押された~UIkeyに結付けられた未修飾な識別子を~~表す，~system／実装に依存する数量的な~codeを保持する。 `key$m 属性と違って、 この仕様では，アリな値の集合は規範的に定義されない。 これらの `keyCode^m の値は、 概して， ASCII `RFC20$r`US-ASCII$r ／ Windows 1252 `WIN1252$r 内の 10 進~符号位置を表現するベキであるが、 適切な他の文字集合から取り出してもヨイ。 ~UIkeyを識別できない実装は、 `~UIkey値$ `0^cap を利用する。 ◎ keyCode holds a system- and implementation-dependent numerical code signifying the unmodified identifier associated with the key pressed. Unlike the key attribute, the set of possible values are not normatively defined in this specification. Typically, these value of the keyCode SHOULD represent the decimal codepoint in ASCII [RFC20][US-ASCII] or Windows 1252 [WIN1252], but MAY be drawn from a different appropriate character set. Implementations that are unable to identify a key use the key value 0.
- `keyCode^m に対する値を決定する方法についての詳細は、 `§ 旧来の~UIkey~model＠#legacy-key-models$ を見よ。 ◎ See § 7.3 Legacy key models for more details on how to determine the values for keyCode.
7.2.2. `KeyboardEventInit^I 辞書（補足的）
`KeyboardEvent^I において［ `charCode$m, `keyCode$m ］を~supportする~browserは、 `KeyboardEventInit$I 辞書に，次の~memberも追加するベキである。 ◎ Browsers that include support for keyCode and charCode in KeyboardEvent should also add the following members to the KeyboardEventInit dictionary.
`KeyboardEventInit^I 部分的~辞書は、 `KeyboardEventInit$I 辞書の参考な拡張であり，［ `charCode$m, `keyCode$m ］~memberを追加する — それらは、対応する `KeyboardEvent^I 属性を初期化する。 ◎ The partial KeyboardEventInit dictionary is an informative extension of the KeyboardEventInit dictionary, which adds charCode and keyCode members to initialize the corresponding KeyboardEvent attributes.
partial dictionary `KeyboardEventInit$I {
/*
次に挙げるものは旧来の~UAを~supportする
◎
The following support legacy user agents
*/
`unsigned long$ `charCode$d = 0;
`unsigned long$ `keyCode$d = 0;
};
- `charCode@d ◎ charCode, of type unsigned long, defaulting to 0
- `KeyboardEvent^I の `charCode$m 属性を ~eventの文字に対する~Unicode符号位置に初期化する。 ◎ Initializes the charCode attribute of the KeyboardEvent to the Unicode code point for the event’s character.
- `keyCode@d ◎ keyCode, of type unsigned long, defaulting to 0
- `KeyboardEvent^I の `keyCode$m 属性を［ ~system／実装に依存する，押された~UIkeyに結付けられた未修飾な識別子 ］を~~表す数量的な~codeに初期化する。 ◎ Initializes the keyCode attribute of the KeyboardEvent to the system- and implementation-dependent numerical code signifying the unmodified identifier associated with the key pressed.
7.3. 旧来の~UIkey~model
◎非規範的これらの属性~上にどの値が公開されるかは、 ~event型により，実装~間で相違する。 実装は、次のいずれを公開することを選んでもヨイ — `keyCode$m ~property内に仮想~UIkey~codeと文字~codeを（`~conflated~model^em）, または 別々な† `keyCode$m, `charCode$m ~property内に報告する（`~split~model^em）。 【† “別々な（ `separate^en ）” — 何が別々？ 別々な~event？】 ◎ Implementations differ on which values are exposed on these attributes for different event types. An implementation MAY choose to expose both virtual key codes and character codes in the keyCode property (conflated model), or report separate keyCode and charCode properties (split model).
7.3.1. `keydown^et ／ `keyup^et ~eventに対し `keyCode^m を決定する方法
［ `keydown$et ／ `keyup$et ］~event用の `keyCode$m は、 次に従って計算される： ◎ The keyCode for keydown or keyup events is calculated as follows:
- `~IME$が~UIkey入力を処理していて，~eventが `keydown$et である場合： 229 を返す。 ◎ ↓↓Read the virtual key code from the operating system’s event information, if such information is available. ◎ If an Input Method Editor is processing key input and the event is keydown, return 229.
- 入力~UIkeyが修飾なしで押されたときに，数量的な文字（ 0 〜 9 ）が挿入されることになる場合： その文字の~ASCII~codeを返す。 ◎ If input key when pressed without modifiers would insert a numerical character (0-9), return the ASCII code of that numerical character.
- 入力~UIkeyが修飾なしで押されたときに， a 〜 z の小文字が挿入されることになる場合： それに対応する大文字の~ASCII~codeを返す。 ◎ If input key when pressed without modifiers would insert a lower case character in the a-z alphabetical range, return the ASCII code of the upper case equivalent.
- 実装が ~OS／~platform用の~UIkey~code変換~表tを~supportしていて、 その表tに，与えられた入力に対する代替な仮想`~UIkey値$が指定された場合： その値を返す。 ◎ If the implementation supports a key code conversion table for the operating system and platform, look up the value. If the conversion table specifies an alternate virtual key value for the given input, return the specified value.
- 実装に特有な仕方で決定される~UIkeyの機能が［ `§ 固定的な仮想~UIkey~code表t＠#fixed-virtual-key-codes$内のいずれかの~UIkey ］に対応する場合、 それに対応する~UIkey~codeを返す。 ◎ If the key’s function, as determined in an implementation-specific way, corresponds to one of the keys in the § 7.3.3 Fixed virtual key codes table, return the corresponding key code.
- ~OSの~event情報によるによる仮想~UIkey~codeが可用な場合： その~UIkey~codeを返す。 ◎ ↑Return the virtual key code from the operating system.
- 他の場合、 0 を返す。 ◎ If no key code was found, return 0.
7.3.2. `keypress^et~eventに対し `keyCode^m を決定する方法
`keypress$et ~event用の `keyCode$m は、 次に従って計算される： ◎ The keyCode for keypress events is calculated as follows:
- 実装が `~conflated~model^emを~supportする場合： `keyCode$m を手入力された文字の~Unicode符号位置に設定する。 ◎ If the implementation supports a conflated model, set keyCode to the Unicode code point of the character being entered.
- 実装が `~split~model^emを~supportする場合： `keyCode$m を 0 に設定する。 ◎ If the implementation supports a split model, set keyCode to 0.
7.3.3. 固定的な仮想~UIkey~code
次の~UIkeyに対する仮想~UIkey~codeは、 通例的に，~desktop~system上の~keyboard~layout間では変化しない： ◎ The virtual key codes for the following keys do not usually change with keyboard layouts on desktop systems:
| ~UIkey | 仮想~UIkey~code | 備考 |
|---|---|---|
| `Backspace$kY | 8 | |
| `Tab$kY | 9 | |
| `Enter$kY | 13 | |
| `Shift$kY | 16 | |
| `Control$kY | 17 | |
| `Alt$kY | 18 | |
| `CapsLock$kY | 20 | |
| `Escape$kY | 27 | `Esc^cap |
| `~SPACEBAR^kY | 32 | |
| `PageUp$kY | 33 | |
| `PageDown$kY | 34 | |
| `End$kY | 35 | |
| `Home$kY | 36 | |
| `ArrowLeft$kY | 37 | |
| `ArrowUp$kY | 38 | |
| `ArrowRight$kY | 39 | |
| `ArrowDown$kY | 40 | |
| `Delete$kY | 46 | `Del^cap |
7.3.4. 固定的な仮想~UIkey~code（任意選択）
次に挙げる約物は，~keyboard~layout間で仮想~codeが変わり得るが、 これらの値を報告することは， US-English ~keyboard~layoutを期待している旧来の内容において より互換になる~~可能性が高い： ◎ The following punctuation characters MAY change virtual codes between keyboard layouts, but reporting these values will likely be more compatible with legacy content expecting US-English keyboard layout:
| ~UIkey | 文字 | 仮想~UIkey~code |
|---|---|---|
| Semicolon | `;^kGl | 186 |
| Colon | `:^kGl | 186 |
| Equals sign | `=^kGl | 187 |
| Plus | `+^kGl | 187 |
| Comma | `,^kGl | 188 |
| Less than sign | `<^kGl | 188 |
| Minus | `-^kGl | 189 |
| Underscore | `_^kGl | 189 |
| Period | `.^kGl | 190 |
| Greater than sign | `>^kGl | 190 |
| Forward slash | `/^kGl | 191 |
| Question mark | `?^kGl | 191 |
| Backtick | ``^kGl | 192 |
| Tilde | `~^kGl | 192 |
| Opening square bracket | `[^kGl | 219 |
| Opening curly brace | `{^kGl | 219 |
| Backslash | `\^kGl | 220 |
| Pipe | `|^kGl | 220 |
| Closing square bracket | `]^kGl | 221 |
| Closing curly brace | `}^kGl | 221 |
| Single quote | `'^kGl | 222 |
| Double quote | `"^kGl | 222 |
9. 旧来の~event型
`この節は規範的である。^em 以下の~event型は、 廃用にされた。 これらは、 旧来の~softwareとの互換性が要求される`~UA$に限り，実装されるべきである。 ◎ This section is normative. The following event types are obsolete and should only be implemented by user agents that require compatibility with legacy software.
この節の目的は、 これらの特能の現在の状態, および 規範的な~eventと これらとの関係を文書化することである。 これらの~eventを~~実際に~supportする実装には、 この節に供される定義を利用することを勧める。 ◎ The purpose of this section is to document the current state of these features and their relation to normative events. For implementations which do support these events, it is suggested that the definitions provided in this section be used.
次の表tに，この仕様にて`非推奨に$された~event型の（参考な）要約を供する。 それらは、参照と完全さのために ここに含められている。 ◎ The following table provides an informative summary of the event types which are deprecated in this specification. They are included here for reference and completeness.
| ~event型 | 同期c？ | `浮上-$？ | `~trusted$な`~target$ | ~DOM~interface | 取消~可否 | Composed | `既定~動作$（空欄は動作なし） |
|---|---|---|---|---|---|---|---|
| `DOMActivate$et | あり | する | `Element^I | `UIEvent$I | 可 | Yes | |
| `DOMFocusIn$et | あり | する | `Window$I, `Element^I | `FocusEvent$I | 不可 | Yes | |
| `DOMFocusOut$et | あり | する | 同上 | `FocusEvent$I | 不可 | Yes | |
| `keypress$et | あり | する | `Element^I | `KeyboardEvent$I | 可 | Yes | 既定~動作（文脈依存） ⇒＃ `~text組成~system$を立上げる／ `blur$et ／ `focus$et ~event／ `DOMActivate$et ~event／ 他の~event ◎ Varies: launch text composition system; blur and focus events; DOMActivate event; other event |
| `textInput$et | あり | する | `Element^I | `TextEvent$I | 可 | Yes | 定義を見よ。 |
9.1. 旧来の `UIEvent^I ~event
9.1.1. 旧来の各種 `UIEvent^I ~event型
9.1.1.1. `DOMActivate^et
次を除き，`各種~UI~eventに共通な文脈~情報$を見よ：
- `target$m： 作動化されている要素
`~UA$は、［ ~button, ~link, その他 状態が変化し得る要素が作動化された ］とき， 【~supportするならば】 この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when a button, link, or other state-changing element is activated.
`DOMActivate$et `~event型$は， 参照と完全さのために この仕様にて定義されるが、 この仕様は， 関係する`~event型$ `click$et への支持を受けて， この型の~eventの利用を`非推奨に$する。 他の仕様は、 後方-互換性を得るために， 自前の `DOMActivate$et `~event型$を定義して保守してもヨイ。 ◎ The DOMActivate event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type in favor of the related event type click. Other specifications MAY define and maintain their own DOMActivate event type for backwards compatibility.
注記： `DOMActivate$et と `click$et は完全に等価ではないが、 `click$et `~event型$用に実装される挙動は、［ `DOMActivate$et `~event型$の最も要を成す ~accessibility設計の側面 ］を包摂するように開発されており， `DOMActivate$et よりも広範に実装されている。 内容~作者には、 ~accessibilityを最大限に確保するため， `click$et `~event型$を利用することが奨励される — 関係する［ `mousedown$et ／ `mouseup$et ］`~event型$でなく。 ◎ While DOMActivate and click are not completely equivalent, implemented behavior for the click event type has developed to encompass the most critical accessibility aspects for which the DOMActivate event type was designed, and is more widely implemented. Content authors are encouraged to use the click event type rather than the related mousedown or mouseup event type to ensure maximum accessibility.
`DOMActivate$et `~event型$を~supportする実装は、 `作動化の誘発$に結付けられた `click$et ~eventの`既定~動作$として， `DOMActivate$et ~eventも発火するベキである。 しかしながら，そのような実装は、［ `作動化の誘発$が生じた回ごとに，それに結付けられた`作動化の挙動$を起動する ］のは，一度限りにするベキである。 ◎ Implementations which support the DOMActivate event type SHOULD also dispatch a DOMActivate event as a default action of a click event which is associated with an activation trigger. However, such implementations SHOULD only initiate the associated activation behavior once for any given occurrence of an activation trigger.
`DOMActivate$et `~event型$は、 `~host言語$において実装が意図された XForms `XFORMS11$r 用に~supportすることが要求される。 XForms が［ この仕様の `DOMActivate$et `~event型$を~supportしない~native実装 ］内に~installするものと意図された［ ~plugin／~script ］に基づいて実装されるような所では、 XForms `~UA$は、 自前の `DOMActivate$et ~eventを適切な`作動化の誘発$に基づいて， 合成して発火する必要がある。 ◎ The DOMActivate event type is REQUIRED to be supported for XForms [XFORMS11], which is intended for implementation within a host language. In a scenario where a plugin or script-based implementation of XForms is intended for installation in a native implementation of this specification which does not support the DOMActivate event type, the XForms user agent has to synthesize and dispatch its own DOMActivate events based on the appropriate activation triggers.
したがって， ~UI~Eventsに適合する XForms `~UA$は、 `click$et ~eventを発火するときには，［ その`既定~動作$として， 同じ関連な各種~propertyを伴う `DOMActivate$et ~eventを合成するかどうか ］を決定する必要がある。 それを決定するときは、 当の~eventの［ `isTrusted$m ~EQ ~T かどうか／ `~event~target$に `DOMActivate$et 用の`~event~listener$が登録されたかどうか ］に基づくのが適切になるであろう。 ◎ Thus, when a click event is dispatched by a user agent conforming to UI Events, the XForms user agent has to determine whether to synthesize a DOMActivate event with the same relevant properties as a default action of that click event. Appropriate cues might be whether the click event isTrusted, or whether its event target has a DOMActivate event listener registered.
注記： `DOMActivate$et が多くの`~UA$で相互運用可能に~supportされることに依拠しないこと。 代わりに， `click$et `~event型$を利用するベキである — 広く実装から~supportされており，より~access可能な挙動を供するので。 ◎ Don’t rely upon the interoperable support of DOMActivate in many user agents. Instead, the click event type should be used since it will provide more accessible behavior due to broader implementation support.
`DOMActivate$et `~event型$は、 この仕様にて`非推奨に$された。 ◎ The DOMActivate event type is deprecated in this specification.
9.1.2. 作動化~event序列
`DOMActivate^et ~eventを~supportする`~UA$は、 ~eventを相互相対順序で発火するモノトスル（~~関係する~eventのみ挙げる）: ◎ If the DOMActivate event is supported by the user agent, then the events MUST be dispatched in a set order relative to each other: (with only pertinent events listed):
| ~event型 | 備考 | |
|---|---|---|
| 1. | `click$et | |
| 2. | `DOMActivate$et | `既定~動作$により生じる（ `~UA$が~supportするなら） — 合成され， `isTrusted$m は ~T になる。 ◎ default action, if supported by the user agent; synthesized; isTrusted="true" |
| `作動化の挙動$も含む，他のすべての`既定~動作$ ◎ All other default actions, including the activation behavior |
被focus要素が~UIkey~eventで作動化された場合の，代表的な~event連列（~~関係する~eventのみ挙げる）を次に示す： ◎ If the focused element is activated by a key event, then the following shows the typical sequence of events (with only pertinent events listed):
| ~event型 | 備考 | |
|---|---|---|
| 1. | `keydown$et | `Enter^cap ／ `~SPACEBAR^cap ~UIkeyなど，要素を作動化できる~UIkeyでなければナラナイ。 さもなければ要素は作動化されない。 ◎ MUST be a key which can activate the element, such as the Enter or (spacebar) key, or the element is not activated |
| 2. | `click$et | `既定~動作$により生じる — 合成され， `isTrusted$m は ~T になる。 ◎ default action; synthesized; isTrusted="true" |
| 3. | `DOMActivate$et | 同上。 ◎ default action, if supported by the user agent; synthesized; isTrusted="true" |
| `作動化の挙動$も含む，他のすべての`既定~動作$ ◎ All other default actions, including the activation behavior |
9.2. 旧来の `FocusEvent^I ~event
9.2.1. 旧来の各種 `FocusEvent^I ~event型
9.2.1.1. `DOMFocusIn^et
次を除き、 `focus$et と同じ：
- `relatedTarget$m ： ~NULL
`~UA$は、［ `~event~target$が~focusを受取った ］とき，この~eventを発火するモノトスル。 ~target要素が~focusを受取るのは、 この型の~eventが配送される前になるモノトスル。 この型の~eventが発火されるのは、 `focus$et ~eventの後になるモノトスル。 ◎ A user agent MUST dispatch this event when an event target receives focus. The focus MUST be given to the element before the dispatch of this event type. This event type MUST be dispatched after the event type focus.
`DOMFocusIn$et ~event型は、 参照と完全さのためにこの仕様にて定義されるが、 この仕様は， 関係する~event型 `focus$et ／ `focusin$et への支持を受けて，この型の~eventの利用を`非推奨に$する。 ◎ The DOMFocusIn event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type in favor of the related event types focus and focusin.
9.2.1.2. `DOMFocusOut^et
次を除き、 `blur$et と同じ：
- `relatedTarget$m ： ~NULL
`~UA$は、［ `~event~target$が~focusを失った ］とき，この~eventを発火するモノトスル。 要素は、 この型の~eventが配送される前に~focusを失うモノトスル。 この型の~eventは、 `blur$et ~eventより後に発火するモノトスル。 ◎ A user agent MUST dispatch this event when an event target loses focus. The focus MUST be taken from the element before the dispatch of this event type. This event type MUST be dispatched after the event type blur.
`DOMFocusOut$et ~event型は，参照と完全さのためにこの仕様にて定義されるが、 この仕様は，関係する~event型 `blur$et, `focusout$et への支持を受けて，この型の~eventの利用を`非推奨に$する。 ◎ The DOMFocusOut event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type in favor of the related event types blur and focusout.
9.2.2. 旧来の `FocusEvent^I ~event序列
非推奨dな［ `DOMFocusIn$et ／ `DOMFocusOut$et ］~eventも含まれる下で、［ 被focus要素がない状態から，~focusが要素 `A^v, `B^v の順に移転したとき ］の代表的な~event連列を次に示す： ◎ The following is the typical sequence of events when a focus is shifted between elements, including the deprecated DOMFocusIn and DOMFocusOut events. The order shown assumes that no element is initially focused.
| ~event型 | 備考 | |
|---|---|---|
| 利用者が~focusを移転させた ◎ User shifts focus | ||
| 1. | `focusin$et | 要素 `A^v が~focusを受取る前に送信される ◎ Sent before first target element receives focus |
| 2. | `focus$et | 要素 `A^v が~focusを受取った後に送信される ◎ Sent after first target element receives focus |
| 3. | `DOMFocusIn$et | ~supportされる場合のみ |
| 利用者が~focusを移転させた ◎ User shifts focus | ||
| 4. | `focusout$et | 要素 `A^v が~focusを失う前に送信される ◎ Sent before first target element loses focus |
| 5. | `focusin$et | 要素 `B^v が~focusを受取る前に送信される ◎ Sent before second target element receives focus |
| 6. | `blur$et | 要素 `A^v が~focusを失った後に送信される ◎ Sent after first target element loses focus |
| 7. | `DOMFocusOut$et | ~supportされる場合のみ |
| 8. | `focus$et | 要素 `B^v が~focusを受取った後に送信される ◎ Sent after second target element receives focus |
| 9. | `DOMFocusIn$et | ~supportされる場合のみ |
8.3. 旧来の `KeyboardEvent^I ~event
`keypress$et ~eventは、［ ~UIkeyが押された効果により~DOMが更新される前に， ~UIkey~eventを捕捉して処理する ］伝統的~methodである。 `keypress$et ~eventを用立てる~codeは、 概して， `KeyboardEvent$I の旧来の［ `charCode$m, `keyCode$m, `which$m ］属性に依拠する。 ◎ The keypress event is the traditional method for capturing key events and processing them before the DOM is updated with the effects of the key press. Code that makes use of the keypress event typically relies on the legacy charCode, keyCode, and which attributes.
`keypress$et ~eventは~UIkey~eventに特有であり，より一般的な［ `beforeinput$et, `input$et ］~eventによる~event連列に置換されることに注意。 これらの新たな入力~eventは、 ~keyboard動作に特有でなく，［ 元の~sourceに関わらず，利用者-入力を捕捉する ］ために利用できる。 ◎ Note that the keypress event is specific to key events, and has been replaced by the more general event sequence of beforeinput and input events. These new input events are not specific to keyboard actions and can be used to capture user input regardless of the original source.
8.3.1. 旧来の各種 `KeyboardEvent^I ~event型
8.3.1.1. `keypress^et
文脈依存：
- `~text組成~system$を立上げる
- `blur$et ＆ `focus$et ~event
- `DOMActivate$et ~event
- その他の~event
次を除き，`各種~keyboard~eventに共通な文脈~情報$を見よ：
- `charCode$m： この~event用の旧来の文字~値
- `keyCode$m： この~UIkey用の旧来の数量的な~code
- `which$m： この~UIkey用の旧来の数量的な~code
- `repeat$m： `false^c
`~UA$ は、 ~supportするならば，［ ~UIkeyが押されたとき，その~UIkeyは 通常は`文字~値$を生産する ］とき, そのときに限り，この型の~eventを発火するモノトスル。 `keypress$et ~event型は装置~依存であり，［ 入力~装置の能力, それらが~OSにて~mapされる方法 ］に依拠する。 ◎ If supported by a user agent, this event MUST be dispatched when a key is pressed down, if and only if that key normally produces a character value. The keypress event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system.
この型の~eventは、 `~UIkey対応付け$の後に生成するモノトスル。 また、`~IME$の利用~時には発火されないモノトスル。 ◎ This event type MUST be generated after the key mapping. It MUST NOT be fired when using an input method editor.
この~eventが取消された場合、 `既定~動作$を取消すことに加えて， `input$et ~eventも発火させなくするベキである。 ◎ If this event is canceled, it should prevent the input event from firing, in addition to canceling the default action.
作者は `keypress$et ~eventの代わりに， `beforeinput$et ~eventを利用するベキである。 ◎ Authors SHOULD use the beforeinput event instead of the keypress event.
注記： `keypress$et ~eventは、 伝統的に，物理的~UIkeyでなく `文字~値$の検出-法に結付けられており、 環境設定によって，すべての~UIkeyに可用とは限らない。 ◎ The keypress event is traditionally associated with detecting a character value rather than a physical key, and might not be available on all keys in some configurations.
`keypress$et ~event型は，参照と完全さのためにこの仕様にて定義されるが、 この仕様は，この型の~eventの利用を`非推奨に$する。 編集~文脈の下では、 作者は，代わりに `beforeinput$et ~eventを~~利用できる。 ◎ The keypress event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type. When in editing contexts, authors can subscribe to the beforeinput event instead.
8.3.2. `keypress^et ~event序列
`keypress$et ~event型は、 同じ~UIkeyに結付けられた［ `keydown$et ~eventより後, かつ `keyup$et ~eventより前 ］に発火するモノトスル。 ◎ The keypress event type MUST be dispatched after the keydown event and before the keyup event associated with the same key.
`keypress$et ~event型は、 同じ~UIkeyに結付けられた［ `beforeinput$et ~eventより後, かつ `input$et ~eventより前 ］に発火するモノトスル。 ◎ The keypress event type MUST be dispatched after the beforeinput event and before the input event associated with the same key.
次の例に、 `keypress$et ~eventを~supportする~UAによる~UIkey~eventの連列をデモる： ◎ The sequence of key events for user-agents the support the keypress event is demonstrated in the following example:
| ~event型 | `key$m | `data$m | |
|---|---|---|---|
| 1. | `keydown$et | `a^kY | |
| 2. | `beforeinput$et | `a^kGl | |
| 3. | `keypress$et | `a^kY | |
| この~UIkeyに関係する`既定~動作$ — 文字を~DOMの中へ挿入するなど — があれば，それが行われる。 ◎ Any default actions related to this key, such as inserting a character in to the DOM. | |||
| 4. | `input$et | ||
| 5. | `keyup$et | `a^kY | |
8.4. 旧来の `TextEvent^I ~event
[`Exposed$=Window]
interface `TextEvent@I : `UIEvent$I {
readonly attribute `DOMString$ `data＠#dom-textevent-data@m;
`undefined$ `initTextEvent＠#dom-textevent-inittextevent@m(~MANYARGS);
};
`TextEvent$I ~interface, `textInput@et ~eventについては、 `UI Events Algorithms^cite 内の `§ ~text~event＠https://w3c.github.io/uievents/event-algo.html#textevent$ を見よ。 ◎ See Text Event section in UI Events Algorithms for the TextEvent interface and the textInput event.
9. ~eventの拡張-法
◎非規範的9.1. 序論
この仕様は，いくつかの~interfaceと多数の~eventを定義するが、 あらゆる目的を網羅するわけではない。 この仕様は、 この［ ~interface／~event ］の集合を［ 競合することなく拡張して，欲される機能性を追加する ］ことを内容~作者や実装者に許容するため， 2 つの仕組み — `~custom~event＠#extending-events-Custom_Events$, `実装に特有な拡張＠#extending-events-Impl_Extensions$ — を供する。 ◎ This specification defines several interfaces and many events, however, this is not an exhaustive set of events for all purposes. To allow content authors and implementers to add desired functionality, this specification provides two mechanisms for extend this set of interfaces and events without creating conflicts: custom events and implementation-specific extensions.
9.2. ~custom~event
~script作者は、 機能単位を通して，~appをその~architectureに有意義な~event型により定義したいと望むこともあろう。 内容~作者は、 `CustomEvent$I ~interfaceを利用して， 利用している抽象-化~levelに適切な自前の~eventを作成できる。 ◎ A script author MAY wish to define an application in terms of functional components, with event types that are meaningful to the application architecture. The content author can use the CustomEvent interface to create their own events appropriate to the level of abstraction they are using.
内容~作者は、 動的に生成される図表を備える~appを作成したとする。 この図表は、［ 5 分ごと ／ 新たな情報が投入されてきたとき ／ 利用者が手動で~buttonを~clickしたとき ］に，更新されるとする。 図表の更新を要するときに~callされる必要がある，いくつかの~handlerがある： ~appは、［ 最新の~dataを~fetchする ／ 更新~中にあることを表す~iconを利用者に示す ／ 図表を築直す ］などを行う必要がある。 内容~作者は、 これを管理するためとして，［ いずれかの誘発~条件が満たされたとき発火される，~customな “`updateChart^et” ~event ］を利用できる： ◎ A content author might have created an application which features a dynamically generated bar chart. This bar chart is meant to be updated every 5 minutes, or when a feed shows new information, or when the user refreshes it manually by clicking a button. There are several handlers that have to be called when the chart needs to be updated: the application has to fetch the most recent data, show an icon to the user that the event is being updated, and rebuild the chart. To manage this, the content author can choose to create a custom "updateChart" event, which is fired whenever one of the trigger conditions is met:
const %chartData = ... /* 図表~data */;
const %evt = new CustomEvent("updateChart", {
bubbles: true,
cancelable: false,
detail: { data: %chartData }
});
document.documentElement.dispatchEvent(%evt);
◎
var chartData = ...;
var evt = document.createEvent("CustomEvent");
evt.initCustomEvent( "updateChart", true, false, { data: chartData });
document.documentElement.dispatchEvent(evt);
9.3. 実装に特有な拡張
新たに設計される原型的な~eventや，実装に特有な機能性~用に意図される~eventは、 標準~化された~eventから判別されることが望ましい。 その種の~eventを［ 他の実装による同じ~event／標準~化された~event ］と判別できるよう、 実装者は，当の~event型に［ 実装に特有な短い接頭辞 ］を付与するベキである。 これは、 CSS における `~vendorに特有な~keyword接頭辞＠~CSS22/syndata.html#vendor-keywords$ に類似する。 ~CSSで利用されている~dash（ `-^l ）は無いが — それは~JSにて属性~名に利用するときに問題になるので。 ◎ While a new event is being designed and prototyped, or when an event is intended for implementation-specific functionality, it is desirable to distinguish it from standardized events. Implementors SHOULD prefix event types specific to their implementations with a short string to distinguish it from the same event in other implementations and from standardized events. This is similar to the vendor-specific keyword prefixes in CSS, though without the dashes ("-") used in CSS, since that can cause problems when used as an attribute name in Javascript.
ある~browser~vendor “FooCorp” は、 新たな~event `jump^et を導入したいと望んだとする。 この~vendorは、 自身に特有な接頭辞 `foo^l を利用して，自身の~browserにて `fooJump^et を実装したとする。 早期の採用者は、 `someElement.addEventListener("fooJump", doJump, false )^m を利用して，その~eventを実験し始め, FooCorp へ~feedbackを供し， FooCorp はそれに則って `fooJump^et の挙動を変更する。 ◎ A particular browser vendor, "FooCorp", might wish to introduce a new event, jump. This vendor implements fooJump in their browser, using their vendor-specific prefix: "foo". Early adopters start experimenting with the event, using someElement.addEventListener("fooJump", doJump, false ), and provide feedback to FooCorp, who change the behavior of fooJump accordingly.
しばらくして後、 別の~vendor “BarOrg” も，同じ機能性を取り入れたいと裁定したが、 実装は少しばかり異なるものにされ、 ~event型~名は，~vendorに特有な自前の接頭辞 `"bar"^c を利用して `barJump^et にされたとする。 この~versionの `jump^et ~event型を実験している内容~作者は、 BarOrg の~event型~名で~event~listenerを登録する。 両~browserに対応する様に~codeを書く内容~作者は、 各~event型に特有な~handlerを別々に登録するか, または 同じ~handlerを利用しつつ，その中で~event型~名に応じて動作を切替えることもできる。 したがって、 異なる~codebaseにおける早期の実験は競合することなく、 早期の採用者は，複数の実装に対応する保守し易い~codeを書けるようになる。 ◎ After some time, another vendor, "BarOrg", decides they also want the functionality, but implement it slightly differently, so they use their own vendor-specific prefix, "bar" in their event type name: barJump. Content authors experimenting with this version of the jump event type register events with BarOrg’s event type name. Content authors who wish to write code that accounts for both browsers can either register each event type separately with specific handlers, or use the same handler and switch on the name of the event type. Thus, early experiments in different codebases do not conflict, and the early adopter is able to write easily-maintained code for multiple implementations.
最終的に，内容~作者や利用者からの~feedback, または 正式な標準~化を通すことに因り、 ~browserの挙動は，安定化され, 一つに収束した特能として成熟するであろう。 このように安定化され, 競合-の~riskが低下した頃合いに、 （正式に標準~化される前であっても）内容~作者は、 分岐した~codeを除去し, 同じ`~event~handler$と より汎用な登録~method `someElement.addEventListener( "jump", doJump, false)^c を利用して， ~event型名 `jump^et を利用できるようになる。 ◎ Eventually, as the feature matures, the behavior of both browsers stabilizes and might converge due to content author and user feedback or through formal standardization. As this stabilization occurs, and risk of conflicts decrease, content authors can remove the forked code, and use the jump event type name (even before it is formally standardized) using the same event handler and the more generic registration method someElement.addEventListener( "jump", doJump, false).
9.3.1. 既知かつ実装に特有な接頭辞
この仕様が書かれた時点で既知な［ ~event型~名 接頭辞 ］には、次に挙げるものがある： ◎ At the time of writing, the following event-type name prefixes are known to exist:
| 接頭辞 | ~Web~engine（~~開発元） |
|---|---|
| `moz^c, `Moz^c | Gecko (Mozilla) |
| `ms^c, `MS^c | Trident (Microsoft) |
| `o^c, `O^c | Presto (Opera Software) |
| `webkit^c | WebKit (Apple, Google, 他) |
10. ~securityの考慮点
この付録では、 ~UI~Eventsの実装における~securityの考慮点について論じる。 論点は、［ この仕様にて定義される ~event~model, ~API, ~event ］の実装から直に発生する~securityの課題に限られる。 実装は，概して、［ ~scripting言語 ／ 他の~API ／ この文書にて定義されない追加的な~event ］の様な，他の特能を~supportする。 これらの特能は，未知な要因を成すので、 この文書の視野から外れる。 実装者は、 そのような特能に関する~securityの考慮点については， それを~~規定している仕様に諮るベキである。 ◎ This appendix discusses security considerations for UI Events implementations. The discussion is limited to security issues that arise directly from implementation of the event model, APIs and events defined in this specification. Implementations typically support other features like scripting languages, other APIs and additional events not defined in this document. These features constitute an unknown factor and are out of scope of this document. Implementers SHOULD consult the specifications of such features for their respective security considerations.
この仕様にて定義される~event型の多くは、 利用者-動作に呼応して発火される。 これは、悪意的な`~event~listener$が［ 利用者が概して機密的と見なす情報 ］への~accessも得られるようにする。 例えば： 利用者が~formを埋めるときの誤入力 ／ ~formを提出する前に，複数から選ぶ問いに対する答えを再考したかどうか ／ 打込みの速さ ／ 入力~時に首に利用される仕組み，等々。 最悪の場合、 悪意的な`~event~listener$は、利用者-ヤリトリをすべて捕捉して，それらを［ `XMLHttpRequest^I ~interfaceなどの，~DOM実装にて一般に可用な手段 ］を通して第三者-主体へ提出することもできる。 ◎ 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., typos they might have made when filling out a form, if they reconsider their answer to a multiple choice question shortly before submitting a form, their typing rate or primary input mechanism. In the worst case, malicious event listeners could capture all user interactions and submit them to a third party through means (not defined in this specification) that are generally available in DOM implementations, such as the XMLHttpRequest interface.
外部~dataを読込む利便性を~supportする~DOM実装は、 `error$et ~eventの様な~eventが［ ~computer~systemや~networkの環境に関する敏感な情報 ］への~accessを供し得る。 例として，［ ~local~networkや, 異なる~port上の~localhost ］上の資源を埋込もうと試みる，悪意的な~HTML文書が挙げられる。 埋込まれた~DOM~appは、 `error$et, `load$et ~eventを~listenすることにより， ~network内の他のどの~computerが ~local~systemから~access可能なのか, あるいは ~systemのどの~portが~openされたかを決定して，更なる攻撃に役立てることも可能になる。 ◎ In DOM implementations that support facilities to load external data, events like the error event can provide access to sensitive information about the environment of the computer system or network. An example would be a malicious HTML document that attempts to embed a resource on the local network or the localhost on different ports. An embedded DOM application could then listen for error and load events to determine which other computers in a network are accessible from the local system or which ports are open on the system to prepare further attacks.
~UI~Eventsのみの実装は，この種類の攻撃を遂行するには一般に不十分であり、 ~securityの考慮点は，そのような攻撃を~supportし得る利便性に適用される。 ~DOM実装は、この仕様への適合性においては， ~DOM~appが［ 機密的／敏感 ］な情報へ~accessできなくするような適理な手続きを採ってもヨイ。 例えば、 ~local~network上の資源を埋込もうと試みる~nodeへは， `load$et ~eventを発火しないことにするなど。 ◎ An implementation of UI Events alone is generally insufficient to perform attacks of this kind and the security considerations of the facilities that possibly support such attacks apply. For conformance with this specification, DOM implementations MAY take reasonable steps to ensure that DOM applications do not get access to confidential or sensitive information. For example, they might choose not to dispatch load events to nodes that attempt to embed resources on the local network.
11. 変更点
11.1. ~DOM2~eventと~UI~Eventsとの間の変更点
~interfaceと~event型に対しいくつもの明確化がなされた。 `HTMLEvents^I ~moduleは、 この文書では もはや定義されない。 `focus$et／`blur$et ~eventは `UIEvent$I ~moduleに追加され， `dblclick$et ~eventは `MouseEvent$I ~moduleに追加された。 この新たな仕様は、［ ~DOM~event~flow, ~event型, ~DOM~interface ］を より良く分離する。 ◎ Numerous clarifications to the interfaces and event types have been made. The HTMLEvents module is no longer defined in this document. The focus and blur events have been added to the UIEvent module, and the dblclick event has been added to the MouseEvent module. This new specification provides a better separation between the DOM event flow, the event types, and the DOM interfaces.
11.1.1. ~DOM2~event~flowに対する変更点
この新たな仕様は、 ~event~flowに次の新たな概念を導入した： ◎ This new specification introduced the following new concepts in the event flow:
- `~event~listener$は、 今や順序付けられた。 ~DOM2では，~eventの順序付けは指定されてなかった。 ◎ Event listeners are now ordered. In DOM Level 2, the event ordering was unspecified.
- 既存の実装を反映するため、 ~event~flowは，今や `Window$I も含む。 ◎ The event flow now includes the Window, to reflect existing implementations.
11.1.2. ~DOM2~event型に対する変更点
~event型には多くの明確化がなされた。 適合性は、 今や明示的に 各~event型に対し定義される — ~event型に利用される~interfaceを通してのみならず。 ◎ Many clarifications have been made on the event types. The conformance is now explicitly defined against the event types, and not only in terms of interfaces used by the event types.
`MutationEvent^I【！"MutationEvents"】 は`非推奨に$された。 【今や，この仕様からも除去された。】 この仕様の早期の草案には在った名前空間~付き~eventの~supportも，除去された。 ◎ "MutationEvents" have been deprecated. Support for namespaced events, present in early drafts of this specification, has also been removed.
［ `DOMNodeInserted^et ／ `DOMNodeRemoved^et ］~event型を~supportする~UAに対しては、 この仕様は，もはや `Attr^I ~nodeに向けて~eventを発火することは要求しない。 【これらの~event型は、今や，この仕様からも除去された。】 ◎ For user agents which support the DOMNodeInserted and DOMNodeRemoved event types, this specification no longer requires that the event type be fired for Attr nodes.
既存の実装を反映するため ⇒＃ `resize^et ~eventは、もはや浮上しない／ `mousemove$et ~eventは、今や`取消~可能$にされた ◎ The resize event type no longer bubbles and the mousemove event is now cancelable, reflecting existing implementations.
11.1.3. ~DOM2~event~interfaceに対する変更点
- `Event$I ~interface
- 新たな属性として `defaultPrevented$m, 新たな~methodとして `stopImmediatePropagation()$m が加えられた。 ◎ The Event interface has one new attribute, defaultPrevented, and one new method, stopImmediatePropagation().
- `timeStamp$m 属性の型は，今や ECMAScript 言語束縛の `Number^c に 【整数ではなく `DOMHighResTimeStamp$I 型に】 。 提案された訂正は `DOM-Level-3-Core$r にも同じ変更を加えることになる。 ◎ timeStamp is now a Number in the ECMAScript binding. A proposed correction to make the same change in [DOM-Level-3-Core] is forthcoming.
- ~DOM2~Eventsでは `type$m 属性の値を文字大小無視と見なしていたが、 この仕様では文字大小区別と見なす。 ◎ This specification considers the type attribute to be case-sensitive, while DOM Level 2 Events considers type to be case-insensitive.
- `EventTarget$I ~interface
- `dispatchEvent()$m ~methodは、改変された。 ◎ The method dispatchEvent() was modified.
- `MouseEvent$I ~interface
- 新たな~method `getModifierState()$m が加えられた。 ◎ The MouseEvent interface has one new method getModifierState().
- `EventException^E 例外
- この例外は、 この仕様から除去された。 ~~以前の `DISPATCH_REQUEST_ERR^m ~codeは，名前 `InvalidStateError$E の `DOMException^I に対応付けられた。 ◎ The exception EventException is removed in this specification. The prior DISPATCH_REQUEST_ERR code is re-mapped to a DOMException of type InvalidStateError.
11.1.4. 新たな~interface
次の~interfaceが~Events~moduleに追加された：
- `CustomEvent$I
- `FocusEvent$I
- `KeyboardEvent$I
- `CompositionEvent$I
- `WheelEvent$I
11.2. ~UI~Eventsの各 草案における変更点
DOM3 ~Events文書は、 元々は 2000年 〜 2003年に開発され、実装者からの更なる~feedbackと関心を待つべく， W3C Note として公表された。 2006年には、 標準化過程における 改訂と進捗のために取り上げられ， 実装の現在の状態と~script作者の必要性を反映するように改訂された。 ◎ The DOM Level 3 Events document was originally developed between 2000 and 2003, and published as a W3C Note, pending further feedback and interest from implementers. In 2006, it was picked up for revision and progress on the Recommendation Track, and was then revised to reflect the current state of implementation and the needs of script authors.
その位置付けが公式的な勧告ではなく W3C Note に過ぎないにも関わらず、 DOM3 Events は，一部の実装を見ていて, 他の仕様からも参照されているので、 この仕様を現在の環境に依然として収容させつつ，妨害を極力抑えるように~careされてきた。 ◎ Despite its status only as a W3C Note, rather than an official Recommendation, DOM 3 Events saw some implementation, and was also referenced by other specifications, so care is being taken to cause minimal disruption, while still adapting the specification to the current environment.
現在の仕様は、 題材を明確化するため、 早期の W3C Note から, および DOM2 Events の構造からも，有意に再編成されている。 階層と~event~flowをより明瞭に表現するため、 新たな図式も~~挿入された。 草案の変遷に伴う重要な変更点の一部をここに示す： ◎ The current specification has been reordered significantly from the earlier W3C Note form, and also from the structure of DOM2 Events, in order to clarify the material. New diagrams have been put in place to represent hierarchies and events flows more clearly. Here are some of the more important changes between drafts:
- ~UIkeyに対する一意な識別子と~~区別するため、 “~UIkey識別子” の特能を “`~UIkey値$” に改称した。 ◎ The "key identifier" feature has been renamed "key value" to disambiguate them from unique identifiers for keys.
- `KeyboardEvent$I ~interfaceは，しばらくの間は（ 2003年から 2010年まで）［ `keyIdentifier^m, `keyLocation^m ］属性を持つように定義されていたが、 現在の［ `key$m, `location$m ］属性の支持を受けて，これらは除去された。 これらの属性は、 広範に実装されてはいない。 ◎ The KeyboardEvent interface was briefly (from 2003-2010) defined to have keyIdentifier and keyLocation attributes, but these were removed in favor of the current key and location attributes. These attributes were not widely implemented.
- ［ `KeyboardEvent$I ／ `CompositionEvent$I ］~interfaceに `locale^m 属性が定義された。 この属性は、 ~~策定中にあり，必要十分に指定されるまでは `technical note^en へ移行された。 詳細は、 この~UI~Events仕様の `旧~version＠~TR/2014/WD-uievents-20140612/$ （ DOM3Events 仕様が "~UI~Events" に改称される前のもの）を~~参照されたし。 ◎ The KeyboardEvent and CompositionEvent interfaces defined a locale attribute. This attribute was underspecified and moved into a technical note until it can be specified adequately. Refer to this old version of UI Events (before the DOM3Events spec was renamed "UI Events") for details.
- `KeyboardEvent$I には， `keypress$et ~eventのみに利用されていた `char^m 属性が在ったが、 その~eventは`非推奨に$されたので， もはや有用でなくなった この属性は除去された。 ◎ The KeyboardEvent also had a char attribute that was only used by the keypress event. Since the keypress event has been deprecated, this attribute was no longer useful and was removed.
- ［ `change^et, `submit^et, `reset^et ］~eventは除去された — それらは~HTML~formに特有であり， `HTML$r【！`HTML5$r】 にて指定されるので。 ◎ The change, submit, and reset events were removed, since they were specific to HTML forms, and are specified in [HTML5].
- 元々は `keypress$et 用の置換として提案された `textInput^et ~eventは、 現在の［ `beforeinput$et, `input$et ］~eventへの支持を受けて，除去された。 ◎ The textInput event, originally proposed as a replacement for keypress, was removed in favor of the current beforeinput and input events.
- 名前空間~付き~eventは除去した。 ◎ Namespaced events have been removed.
- `WebIDL$r を利用するよう更新した。 ◎ Updated to use [WebIDL].
- `EventException^E 例外を除去した。 ◎ EventException has been removed.
12. 謝辞
DOM ~WG, DOM Interest Group, WebAPI ~WG, WebApps ~WG に携わった方々を含め，多くの方々が~DOM仕様（ Level 1, 2, 3 ）に寄与された。 とりわけ次の方々に感謝する： ◎ Many people contributed to the DOM specifications (Level 1, 2 or 3), including participants of the DOM Working Group, the DOM Interest Group, the WebAPI Working Group, and the WebApps Working Group. We especially thank the following:
Andrew Watson (Object Management Group), Andy Heninger (IBM), Angel Diaz (IBM), Anne van Kesteren (Opera Software), Arnaud Le Hors (W3C and IBM), Arun Ranganathan (AOL), Ashok Malhotra (IBM and Microsoft), Ben Chang (Oracle), Bill Shea (Merrill Lynch), Bill Smith (Sun), Björn Höhrmann, Bob Sutor (IBM), Charles McCathie-Nevile (Opera Software, `Co-Chair^em), Chris Lovett (Microsoft), Chris Wilson (Microsoft), Christophe Jolif (ILOG), David Brownell (Sun), David Ezell (Hewlett-Packard Company), David Singer (IBM), Dean Jackson (W3C, `W3C Team Contact^em), Dimitris Dimitriadis (Improve AB and invited expert), Don Park (invited), Doug Schepers (Vectoreal), Elena Litani (IBM), Eric Vasilik (Microsoft), Gavin Nicol (INSO), Gorm Haug Eriksen (Opera Software), Ian Davis (Talis Information Limited), Ian Hickson (Google), Ian Jacobs (W3C), James Clark (invited), James Davidson (Sun), Jared Sorensen (Novell), Jeroen van Rotterdam (X-Hive Corporation), Joe Kesselman (IBM), Joe Lapp (webMethods), Joe Marini (Macromedia), John Robinson (AOL), Johnny Stenback (Netscape/AOL), Jon Ferraiolo (Adobe), Jonas Sicking (Mozilla Foundation), Jonathan Marsh (Microsoft), Jonathan Robie (Texcel Research and Software AG), Kim Adamson-Sharpe (SoftQuad Software Inc.), Lauren Wood (SoftQuad Software Inc., `former Chair^em), Laurence Cable (Sun), Luca Mascaro (HTML Writers Guild), Maciej Stachowiak (Apple Computer), Marc Hadley (Sun Microsystems), Mark Davis (IBM), Mark Scardina (Oracle), Martin Dürst (W3C), Mary Brady (NIST), Michael Shenfield (Research In Motion), Mick Goulish (Software AG), Mike Champion (Arbortext and Software AG), Miles Sabin (Cromwell Media), Patti Lutsky (Arbortext), Paul Grosso (Arbortext), Peter Sharpe (SoftQuad Software Inc.), Phil Karlton (Netscape), Philippe Le Hégaret (W3C, `W3C Team Contact and former Chair^em), Ramesh Lekshmynarayanan (Merrill Lynch), Ray Whitmer (iMall, Excite@Home, and Netscape/AOL, `Chair^em), Rezaur Rahman (Intel), Rich Rollman (Microsoft), Rick Gessner (Netscape), Rick Jelliffe (invited), Rob Relyea (Microsoft), Robin Berjon (Expway, `Co-Chair^em), Scott Hayman (Research In Motion), Scott Isaacs (Microsoft), Sharon Adler (INSO), Stéphane Sire (IntuiLab), Steve Byrne (JavaSoft), Tim Bray (invited), Tim Yu (Oracle), Tom Pixley (Netscape/AOL), T.V. Raman (Google). Vidur Apparao (Netscape) and Vinod Anupam (Lucent).
前任の編集者たち：
Former editors: Tom Pixley (Netscape Communications Corporation) until July 2002; Philippe Le Hégaret (W3C) until November 2003; Björn Höhrmann (Invited Expert) until January 2008; and Jacob Rossi (Microsoft) from March 2011 to October 2011.
WebApps ~WGの中では、 次の方々が，この仕様を改良し, 改訂する過程に大きく貢献された： ◎ Contributors: In the WebApps Working Group, the following people made substantial material contributions in the process of refining and revising this specification:
Bob Lund (Cable Laboratories), Cameron McCormack (Invited Expert / Mozilla), Daniel Danilatos (Google), Gary Kacmarcik (Google), Glenn Adams (Samsung), Hallvord R. M. Steen (Opera), Hironori Bono (Google), Mark Vickers (Comcast), Masayuki Nakano (Mozilla), Olli Pettay (Mozilla), Takayoshi Kochi (Google) and Travis Leithead (Microsoft).
用語集に貢献された方々： ◎ Glossary contributors:
Arnaud Le Hors (W3C) and Robert S. Sutor (IBM Research).
test suite に貢献された方々： ◎ Test suite contributors:
Carmelo Montanez (NIST), Fred Drake, Mary Brady (NIST), Neil Delima (IBM), Rick Rivello (NIST), Robert Clary (Netscape), with a special mention to Curt Arnold.
提言や訂正を送信して（~bugがあれば、課題を~~提出されたし！）, あるいは 参考本や~Web~siteを書いて，この仕様の改善に助力された、以下の方々に： ◎ Thanks to all those who have helped to improve this specification by sending suggestions and corrections (please, keep bugging us with your issues!), or writing informative books or Web sites:
Al Gilman, Alex Russell, Alexander J. Vincent, Alexey Proskuryakov, Arkadiusz Michalski, Brad Pettit, Cameron McCormack, Chris Rebert, Curt Arnold, David Flanagan, Dylan Schiemann, Erik Arvidsson, Garrett Smith, Giuseppe Pascale, James Su, Jan Goyvaerts (regular-expressions.info), Jorge Chamorro, Kazuyuki Ashimura, Ken Rehor, Magnus Kristiansen, Martijn Wargers, Martin Dürst, Michael B. Allen, Mike Taylor, Misha Wolf, Ojan Vafai, Oliver Hunt, Paul Irish, Peter-Paul Koch, Richard Ishida, Sean Hogan, Sergey Ilinsky, Sigurd Lerstad, Steven Pemberton, Tony Chang, William Edney and Øistein E. Andersen.
13. 用語集
【 ここでは、原文の用語集の中から，主に適合性に関する用語を挙げる。 他の用語は、`別~page＠~UIEVENTS#glossary$にて。 】
- `作者@ （ `author^en ）
- この仕様の文脈における［ `作者^em ／ `内容~作者^em ／ `~script作者^em ］は、 この仕様にて定義される ~interface, ~event, ~event~flowを利用する ~scriptや他の実行-可能な内容を書く者である。 詳細は、 `§ 内容~作者と内容＠#conf-authors$ における適合性の類別を見よ。 ◎ In the context of this specification, an author, content author, or script author is a person who writes script or other executable content that uses the interfaces, events, and event flow defined in this specification. See § 1.2.3 Content authors and content conformance category for more details.
- `非推奨d@ （ `deprecated^en ）
- 非推奨dと~markされた特能は、 古い実装や仕様への参照として，この仕様に含まれてはいるが、 任意選択~であり，利用しないことが奨励される。 ある特能が非推奨にされるためには、 それを置換するものとして，この仕様において［ 既存の／進捗-中にある ］特能がなければナラナイ。 特能をまだ~supportしていない実装は、 既存の内容との後方-互換性の理由で，非推奨dな特能を実装してもヨイが、 内容~作者は — 利用事例を解決する仕方が他にあるならば — 非推奨dな特能を利用するベキでない。 この仕様を参照する他の仕様は、 特能が非推奨にされたことへの支持を受けて， 非推奨dな特能は利用せずに，その置換を参照するベキである。 この仕様にて非推奨dと~markされた特能は、 将来の仕様からは落とされるものと期待されている。 ◎ Features marked as deprecated are included in the specification as reference to older implementations or specifications, but are OPTIONAL and discouraged. Only features which have existing or in-progress replacements MUST be deprecated in this specification. Implementations which do not already include support for the feature MAY implement deprecated features for reasons of backwards compatibility with existing content, but content authors creating content SHOULD NOT use deprecated features, unless there is no other way to solve a use case. Other specifications which reference this specification SHOULD NOT use deprecated features, but SHOULD point instead to the replacements of which the feature is deprecated in favor. Features marked as deprecated in this specification are expected to be dropped from future specifications.
- `~host言語@ （ `host language^en ）
- 別の言語や~API仕様の各種~特能を統合する言語 — それらの特能を定義し直すことなく，その出自の仕様を規範的に参照し、 それらの特能を その出自の仕様にて定義される仕方のみに従って拡張するような。 出自の仕様は，概して，自立的な言語でなく、 いくつかの~host言語の文脈の下でのみ実装されることが意図される。 例えば， ~XHTML, ~HTML, ~SVG は、 ~UI~Events用の~host言語に該当する — それらは、この仕様にて定義される~objと~modelを統合し, 拡張する。 ◎ Any language which integrates the features of another language or API specification, while normatively referencing the origin specification rather than redefining those features, and extending those features only in ways defined by the origin specification. An origin specification typically is only intended to be implemented in the context of one or more host languages, not as a standalone language. For example, XHTML, HTML, and SVG are host languages for UI Events, and they integrate and extend the objects and models defined in this specification.