UI Events 仕様

付録, および適合性

UI Events の他の部分の日本語訳

1.2. 適合性

この節は規範的である。 ◎ This section is normative.

この仕様における,各種~keyword: “〜しなければ(〜しては)ならない” ( MUST, MUST NOT ), “要求される” ( REQUIRED ), “〜するべきである(でない)” ( SHOULD, SHOULD NOT ), “推奨される” ( RECOMMENDED ), “〜してよい” ( MAY ), “任意選択” ( OPTIONAL ) は、 `RFC2119$r に則って解釈されるとする。 【原文の MAY は、この意味の MAYでないもの(許可でない “may” )も多量に含まれている(ほぼすべて~~機械的に大文字の “MAY” にされている)ので、それらは和訳には反映されていない。】 ◎ 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].

この仕様は DOM Level 3 Core 仕様 `DOM-Level-3-Core$r の文脈で解され,~DOM実装に対する一般的な考慮点が適用される。 適合性 についての追加の情報は、 `DOM-Level-3-Core$r を見よ。 `~UA$は、この仕様に適合するために,別の仕様に全面的に適合することは要求されないが、その中の,この仕様に~~関わる部分には適合し~MUST(例: 適合~UI~Events `~UA$は, `WebIDL$r にて定義される ~DS ~data型を~supportし~MUSTが、 ~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 [[Web IDL]], but need not support every method or data type defined in [[Web IDL]] 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 ー ~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]
  • `~eventの配送と~DOM~event~flow$の仕組み。 ◎ the Event dispatch and DOM event flow mechanism
  • この仕様にて定義される,[ ~ifc, ~event, および それらに結付けられている ~method, 属性, 意味論 ]すべて。 ただし、`非推奨に$されたものを除く( 適合~UAは,後方互換性のためとして,非推奨にされた[ ~ifc/~event/~API ]を実装して~MAYが、適合するためには要求されない)。 ◎ 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可用性の~~対象になる)。 ◎ 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型$に定義されている条件を満たしたときに`発火-$し~MUST。 ◎ A conforming browser MUST dispatch events appropriate to the given EventTarget when the conditions defined for that event type have been met.

~ifc&`~event型~節$にて指定される,関係する`~event型$を実装する~browserは、特に ~UI~Eventsに適合する。 ◎ A browser conforms specifically to UI Events if it implements the interfaces and related event types specified in §4 Event Types.

適合~browserは、この仕様に述べる方式で,[ ~scripting/ 宣言的な対話性 / ~eventを検出して発火する他の何らかの手段 ]を~supportし, かつ その`~event型$に対し指定されている~APIを~supportし~MUST。 ◎ 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は、他のすべての適合性~判定基準を満たすことに加えて,既存の内容との後方互換性のために,[ この仕様にて`非推奨に$された特色機能 ]を実装して~MAYが、実装しないことが奨励される。 ◎ 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は、[[ `~eventの配送と~DOM~event~flow$の仕組み, ~ifc, ~event, ~UI~Eventsにて定義される他の特色機能 ]を利用する,この仕様に見出されない特色機能 ]も~supportして,その実装に適切な追加の[ ~ifc/`~event型$ ]を実装して~MAY。 そのような特色機能は、将来~仕様にて標準~化され得る。 ◎ A conforming browser MAY also support features not found in this specification, but which use the §3.1 Event dispatch and DOM event flow mechanism, 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に適合していると主張しては~MUST_NOT。 そのような実装で,この仕様の一部の事項に適合するものは、それらの特定の事項に適合していると主張して~MAY。 ◎ 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 仕様に述べられる適合~実装で~MUST。 ◎ 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.2. 著作tool

内容~著作toolは、各種`~event型$, および `~eventの配送と~DOM~event~flow$~modelを,この仕様にて定義される方式と整合するように利用する内容を生産するならば、~UI~Eventsに適合するとされる。 ◎ A content authoring tool conforms to UI Events if it produces content which uses the event types and §3.1 Event dispatch and DOM event flow model, consistent in a manner as defined in this specification.

この仕様にて`非推奨に$された特色機能を利用する内容を生産するような 内容~著作toolは、 ~UI~Events に適合していると主張しては~MUST_NOT。 ◎ A content authoring tool MUST NOT claim conformance to UI Events for content it produces which uses features of this specification marked as deprecated in this specification.

適合 内容~著作toolは、[ 自身が生産する内容~文書における どの`~host言語$に対しても,それに適切な `~event型$&~ifc すべて ]に対し,それらを利用する手段を,内容~作者に供する~SHOULDである。 ◎ A conforming content authoring tool SHOULD provide to the content author a means to use all event types and interfaces appropriate to all host languages in the content document being produced.

1.2.3. 内容~作者/内容

作者が作成する内容は、[ `~event型$, および `~eventの配送と~DOM~event~flow$~model ]を,この仕様に定義される方式と整合するように利用するとき、~UI~Eventsに適合するとされる。 ◎ A content author creates conforming UI Events content if that content uses the event types and §3.1 Event dispatch and DOM event flow model, consistent in a manner as defined in this specification.

内容~作者は,この仕様にて`非推奨に$された特色機能を利用する~SHOULDでない — この仕様や他所にて定義される代用の仕組みに依拠する~SHOULDである。 ◎ A content author SHOULD NOT use features of this specification marked as deprecated, but SHOULD rely instead upon replacement mechanisms defined in this specification and elsewhere.

適合~内容は、~ifc/`~event型$の意味論をこの仕様にて述べるように利用し~MUST。 ◎ Conforming content MUST use the semantics of the interfaces and event types as described in this specification.

注記: 内容~作者には、 ~accessibility国際化 の指針~仕様に述べられる 最善実施に従うことを勧める。 ◎ Content authors are advised to follow best practices as described in accessibility and internationalization guideline specifications.

1.2.4. 仕様/~host言語

仕様/`~host言語$は、[ `~eventの配送と~DOM~event~flow$の仕組み, ~ifc, ~event, `DOM$rにて定義される他の特色機能 ]を参照して利用する, かつ これらの特色機能を非互換な仕方で拡張しないならば、~UI~Eventsに適合する。 ◎ A specification or host language conforms to UI Events if it references and uses the §3.1 Event dispatch and DOM event flow mechanism, interfaces, events, or other features defined in [DOM4], and does not extend these features in incompatible ways.

仕様/`~host言語$は、 ~ifc&`~event型~節$にて指定される,関係する`~event型$ を参照して利用するならば,特に~UI~Eventsに適合する。 適合~仕様は、この仕様の[ ~ifc/`~event型$ ]に 相反したり競合しない方式で,その仕様に適切な[ ~ifc/`~event型$ ]を追加で定義したり, この仕様の[ ~ifc/`~event型$ ]を拡張して~MAY。 ◎ A specification or host language conforms specifically to UI Events if it references and uses the interfaces and related event types specified in Event Types. 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言語$は、この仕様にて `非推奨に$された特色機能を[ 利用する/推奨する ]ことなく,(可用ならば)その特色機能の代用として,この仕様にて指示されるものを[ 利用する/推奨する ]~SHOULDである。 ◎ 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初期化子

この節は規範的である。 以下の特色機能は、廃用にされた。 これらは、旧来の~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には、~ifc上に,~parameterの長〜い~listが要求されるような初期化~method(例えば `initMouseEvent()$m )が含まれていた — それは、ほとんどの事例で,~event~objの属性すべてを全部的に初期化しない。 このため、基本 `Event$I ~ifcから派性された~event~ifcを実装する~eventを全部的に初期化するためには,派性されたそれぞれの ~ifcの初期化子を明示的に~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.

`MutationEvent$I の属性すべてを初期化するためには、 2 つの初期化子~method `initEvent()$m, `initMutationEvent()$m の~callを要する。 ◎ Initializing all the attributes of a MutationEvent requires calls to two initializer methods: initEvent and initMutationEvent.

この標準は長く開発され続けていたため、これらの(今や非推奨の)初期化子~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初期化子~ifc

~INFORMATIVE

この節では、この仕様の早期の~versionにて導入されたが 今や`非推奨に$された,旧来の初期化子~methodを文書~化する。 ◎ This section documents legacy initializer methods that were introduced in earlier versions of the this specification.

6.1.1. `UIEvent^I ~ifc用の初期化子

partial interface `UIEvent$I {
    // この仕様により非推奨にされた
    void `initUIEvent@m (~MANYARGS);
};
~OMIT0

6.1.2. `MouseEvent^I ~ifc用の初期化子

partial interface `MouseEvent$I {
    // この仕様により非推奨にされた
    void `initMouseEvent@m (~MANYARGS);
};
~OMIT0

6.1.3. `WheelEvent^I ~ifc用の初期化子

partial interface `WheelEvent$I {
    // この仕様により導入されたが非推奨にされた
    void `initWheelEvent@m (~MANYARGS);
};
~OMIT0

6.1.4. `KeyboardEvent^I ~ifc用の初期化子

注記: この旧来の `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 (see §11.2 Changes between different drafts of UI Events); it is necessary to preserve this inconsistency for compatibility with existing implementations.

partial interface `KeyboardEvent$I {
    // この仕様により導入されたが非推奨にされた
    void `initKeyboardEvent@m (~MANYARGS);
};
~OMIT0

6.1.5. `CompositionEvent^I ~ifc用の初期化子

注記: この旧来の `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 (see §11.2 Changes between different drafts of UI Events); it is necessary to preserve this inconsistency for compatibility with existing implementations.

partial interface `CompositionEvent$I {
    // この仕様により導入されたが非推奨にされた
    void `initCompositionEvent@m (~MANYARGS);
};
~OMIT0

7. 旧来の~key&~mouse属性

~INFORMATIVE

以下の属性は、廃用にされた。 これらは、[ これらの~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$内に在っても~MAYが。 作者は、 `charCode$m / `keyCode$m 属性の代わりに `key$m 属性を利用する~SHOULDである。 ◎ 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 追補的~ifc

~INFORMATIVE

伝統的に,`~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. ~ifc `UIEvent^I (追補的)

`UIEvent^I 部分的~ifcは、 `UIEvent$I ~ifcに `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する
    readonly attribute unsigned long `which$m;
};
`which@m ◎ which, of type unsigned long, readonly
`MouseEvent$I に対しては、この属性は, ( `button$m の値 + 1 ) に等しくなる。 `KeyboardEvent$I に対しては、この属性は,[ 押された~keyに結付けられている, 未修飾の, [ ~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 辞書に,[ 対応する `UIEvent^I 属性を初期化する `which$m ~member ]を追加する,参考の拡張である。 ◎ 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
`UIEvent$I の `which$m 属性を初期化する。 ◎ Initializes the which attribute of the UIEvent.

7.2. 旧来の `KeyboardEvent^I 追補的~ifc

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

これらの属性は、いずれも,押された~keyのある側面を表現する数的~codeを返す:

  • `keyCode$m は,~key自身の~index。
  • `charCode$m は, 文字~keyの ASCII 値。
  • `which$m は,可用な所では文字~値/他の場合は~key~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. ~ifc `KeyboardEvent^I (追補的)

`KeyboardEvent^I 部分的~ifcは、 `KeyboardEvent$I ~ifcに `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 部分的~ifcは、実装がこの拡張を~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する
    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
この属性は、押された~keyに結付けられている未修飾の識別子を~~表す,~system/実装に依存する数的~codeを保持する。 `key$m 属性と違って、この仕様では,可能な値の集合は規範的に定義されない。 これらの `keyCode^m の値は、概して, ASCII `RFC20$r`US-ASCII$r / Windows 1252 `WIN1252$r 内の 10 進~符号位置を表現する~SHOULDであるが、適切な他の文字集合から取り出しても~MAY。 ~keyを識別できない実装は、~key値 `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 に対する値を決定する方法についての詳細は、 旧来の~key~model を見よ。 ◎ See §7.3 Legacy key models for more details on how to determine the values for keyCode.

7.2.2. 辞書 `KeyboardEventInit^I (追補的)

`KeyboardEvent^I において[ `keyCode$m, `charCode$m, `which$m ]を~supportする~browserは、 `KeyboardEventInit$I 辞書に,次の~memberも追加する~SHOULDである。 ◎ Browsers that include support for keyCode, charCode, and which in KeyboardEvent should also add the following members to the KeyboardEventInit dictionary.

`KeyboardEventInit^I 部分的~辞書は、 `KeyboardEventInit$I 辞書に,[ 対応する `KeyboardEvent^I 属性を初期化する `charCode$m, `keyCode$m, ~member ]を追加する,参考の拡張である。 ◎ The partial KeyboardEventInit dictionary is an informative extension of the KeyboardEventInit dictionary, which adds charCode, keyCode, and which members to initialize the corresponding KeyboardEvent attributes.

partial dictionary `KeyboardEventInit$I {
    // 次のものは旧来の~UAを~supportする
    unsigned long `charCode$d = 0;
    unsigned long `keyCode$d = 0;
};
`charCode@d
`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
`KeyboardEvent^I の `keyCode$m 属性を[ ~system/実装に依存する,押された~keyに結付けられている未修飾の識別子 ]を~~表す数的~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. 旧来の~key~model

~INFORMATIVE

これらの属性~上にどの値が公開されるかは、~event型により,実装~間で相違する。 実装は、次のいずれを公開することを選んでも~MAY — `keyCode$m ~property内に仮想~key~codeと文字~codeを(~conflated~model), または 別々の† `keyCode$m, `charCode$m ~property内に報告する(~split~model)。 【† “別々の( separate )” — 何が別々? 別々の~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:

  1. `~IME$が~key入力を処理していて,~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.
  2. 入力~keyが修飾なしで押されたときに,数的~文字( 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.
  3. 入力~keyが修飾なしで押されたときに, 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.
  4. 実装が ~OS/~platform用の~key~code変換表を~supportしていて、その表に,与えられた入力に対する代替の仮想~key値が指定されている場合: その値を返す。 ◎ 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.
  5. 実装~特有の仕方で決定される~keyの機能が,[ 固定的な仮想~key~code表 内のいずれかの~key ]に対応する場合、それに対応する~key~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.
  6. ~OSの~event情報によるによる仮想~key~codeが可用な場合: その~key~codeを返す。 ◎ ↑Return the virtual key code from the operating system.
  7. 他の場合、 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:

  1. 実装が ~conflated~modelを~supportする場合: `keyCode$m を手入力された文字の~Unicode符号位置に設定する。 ◎ If the implementation supports a conflated model, set keyCode to the Unicode code point of the character being entered.
  2. 実装が ~split~modelを~supportする場合: `keyCode$m を 0 に設定する。 ◎ If the implementation supports a split model, set keyCode to 0.

7.3.3. 固定的な仮想~key~code

次の~keyに対する仮想~key~codeは、通例的に,~desktop~system上の~keyboard~layout間では変化しない: ◎ The virtual key codes for the following keys do not usually change with keyboard layouts on desktop systems:

~key 仮想~key~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. 固定的な仮想~key~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:

~key 文字 仮想~key~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

8. 旧来の~event型

この節は規範的である。 以下の~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.

次の一覧に,この仕様にて`非推奨に$された~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型◎ Event Type `同期$?◎ Sync / Async `浮上-$?◎ Bubbling Phase `~trusted$ ~event標的◎ Trusted event target types DOM ~ifc◎ DOM Interface 取消~可否◎ Cancelable Composed
`DOMActivate$et あり する `Element^I `UIEvent$I Yes
`DOMAttrModified$et あり する `Element^I `MutationEvent$I 不可 No
`DOMCharacterDataModified$et あり する `Text^I, `Comment^I, `ProcessingInstruction^I `MutationEvent$I 不可 No
`DOMFocusIn$et あり する `Window$I, `Element^I `FocusEvent$I 不可 Yes
`DOMFocusOut$et あり する 同上 `FocusEvent$I 不可 Yes
`DOMNodeInserted$et あり する `Element^I, `Attr^I, `Text^I, `Comment^I, `DocumentType^I, `ProcessingInstruction^I `MutationEvent$I 不可 No
`DOMNodeInsertedIntoDocument$et あり しない 同上 `MutationEvent$I 不可 No
`DOMNodeRemoved$et あり する 同上 `MutationEvent$I 不可 No
`DOMNodeRemovedFromDocument$et あり しない 同上 `MutationEvent$I 不可 No
`DOMSubtreeModified$et あり する `Window$I, `Document^I, `DocumentFragment^I, `Element^I, `Attr^I `MutationEvent$I 不可 No
`keypress$et あり する `Element^I `KeyboardEvent$I Yes
既定動作(文脈依存):
  • `~text組成~system$を起動0する
  • `blur$et / `focus$et ~event
  • `DOMActivate$et ~event
  • 他の~event
◎ Varies: launch text composition system; blur and focus events; DOMActivate event; other event

8.1. 旧来の `UIEvent^I ~event

8.1.1. 旧来の各種 `UIEvent^I ~event型

8.1.1.1. `DOMActivate^et
◎イ型 `DOMActivate@et ◎界面 `UIEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈

次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:

  • `target$m: 作動化されている要素
◎ • Event.target : element being activated • UIEvent.view : Window • UIEvent.detail : 0 ◎表終

`~UA$は、[ ~button, ~link, その他 状態が変化し得る要素が作動化された ]とき, 【~supportするならば】 この~eventを発火し~MUST。 詳細は、`作動化の誘発と挙動$ 節に。 ◎ A user agent MUST dispatch this event when a button, link, or other state-changing element is activated. Refer to §3.5 Activation triggers and behavior for more details.

`DOMActivate$et `~event型$は、参照と完全さのために この仕様にて定義されるが、この仕様は,関係する`~event型$ `click$et への支持を受けて,この型の~eventの利用を`非推奨に$する。 他の仕様は、後方互換性のために,自前の `DOMActivate$et `~event型$を定義して保守して~MAY。 ◎ 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も発火する~SHOULDである。 しかしながら,そのような実装は、各`作動化の誘発$ごとに,結付けられている`作動化の挙動$を一度だけ起動する~SHOULDである。 ◎ 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.

したがって, `click$et ~eventが~UI~Eventsに適合する`~UA$により発火されるときには、 XForms `~UA$は,[ その `click$et ~eventの`既定~動作$として,同じ関連する各種~propertyを伴う `DOMActivate$et ~eventを合成する ]かどうかを決定する必要がある。 それを決定するときは、[ `click$et ~eventが`~trusted$かどうかや, その`~event標的$に `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 is trusted, or whether its event target has a DOMActivate event listener registered.

注記: `DOMActivate$et が多くの`~UA$で相互運用可能に~supportされることに依拠しないこと。 代わりに, `click$et `~event型$が利用される~SHOULDである — 広く実装から~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.

8.1.2. 作動化~event序列

`DOMActivate^et ~eventを~supportする`~UA$は、~eventを相互相対順序で発火し~MUST(~~関係する~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要素が~key~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 ~keyなど,要素を作動化できる~keyで~MUST。 さもなければ要素は作動化されない。 ◎ 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

8.2. 旧来の `FocusEvent^I ~event

8.2.1. 旧来の各種 `FocusEvent^I ~event型

8.2.1.1. `DOMFocusIn^et
◎イ型 `DOMFocusIn@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 する ◎標的 `Window$I, `Element^I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈

次を除き、 `focus$et と同じ:

  • `relatedTarget$m : ~NULL
◎ • Event.target : event target receiving focus • UIEvent.view : Window • UIEvent.detail : 0 • FocusEvent.relatedTarget : null ◎表終

`~UA$は、[ `~event標的$が~focusを受け取った ]とき,この~eventを発火し~MUST。 標的~要素が~focusを受け取るのは、この型の~eventが配送される前で~MUST。 この型の~eventが発火されるのは、 `focus$et ~eventの後で~MUST。 ◎ 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.

8.2.1.2. `DOMFocusOut^et
◎イ型 `DOMFocusOut@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 する ◎標的 `Window$I, `Element^I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈

次を除き、 `blur$et と同じ:

  • `relatedTarget$m : ~NULL
◎ • Event.target : event target losing focus • UIEvent.view : Window • UIEvent.detail : 0 • FocusEvent.relatedTarget : null ◎表終

`~UA$は、[ `~event標的$が~focusを失った ]とき,この~eventを発火し~MUST。 要素が~focusを失うのは、この型の~eventが配送されるより前で~MUST。 この型の~eventは、 `blur$et ~eventの後に発火され~MUST。 ◎ 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.

8.2.2. 旧来の `FocusEvent^I ~event序列

非推奨 `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は、[ ~keyが押された効果により~DOMが更新される前に, ~key~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は~key~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
◎イ型 `keypress@et ◎界面 `KeyboardEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^I ◎取消 可 ◎構 Yes ◎既定動作

文脈依存:

  • `~text組成~system$を起動0させる
  • `blur$et & `focus$et ~event
  • `DOMActivate$et ~event
  • その他の~event
◎ Varies: launch text composition system; blur and focus events; DOMActivate event; other event ◎文脈

次を除き,`各種~keyboard~eventに共通する文脈~情報$にて与えられる:

  • `charCode$m: この~eventに対する旧来の文字~値
  • `keyCode$m: この~keyに対する旧来の数的~code
  • `which$m: この~keyに対する旧来の数的~code
  • `repeat$m: `false^c
◎ • Event.target : focused element processing the key event or if no element focused, then the body element if available, otherwise the root element • UIEvent.view : Window • UIEvent.detail : 0 • KeyboardEvent.charCode : legacy character value for this event • KeyboardEvent.keyCode : legacy numerical code for this key • KeyboardEvent.which : legacy numerical code for this key • KeyboardEvent.key : the key value of the key pressed. • KeyboardEvent.code : the code value associated with the key’s physical placement on the keyboard. • KeyboardEvent.location : the location of the key on the device. • KeyboardEvent.altKey : true if 'Alt' modifier was active, otherwise false • KeyboardEvent.shiftKey : true if 'Shift' modifier was active, otherwise false • KeyboardEvent.ctrlKey : true if 'Control' modifier was active, otherwise false • KeyboardEvent.metaKey : true if 'Meta' modifier was active, otherwise false • KeyboardEvent.repeat : false • KeyboardEvent.isComposing : true if the key event occurs as part of a composition session, otherwise false ◎表終

`~UA$ は、~supportするならば,[ ~keyが押されたとき,その~keyは 通常は`文字~値$を生産する ]とき, そのときに限り,この型の~eventを発火し~MUST。 `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が生成されるのは、`~key~mapping$の後で~MUST。 また、`~IME$の利用~時に発火されては~MUST_NOT。 ◎ 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も発火させなくする~SHOULDである。 ◎ 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を利用する~SHOULDである。 ◎ Authors SHOULD use the beforeinput event instead of the keypress event.

注記: `keypress$et ~eventは、伝統的に,物理的~keyでなく `文字~値$の検出に結付けられており、環境設定によって,すべての~keyに可用とは限らない。 ◎ 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型が発火されるのは、同じ~keyに結付けられている `keydown$et ~eventの後, かつ `keyup$et ~eventの前で~MUST。 ◎ The keypress event type MUST be dispatched after the keydown event and before the keyup event associated with the same key.

`keypress$et ~event型が発火されるのは、同じ~keyに結付けられている `beforeinput$et ~eventの後, かつ `input$et ~eventの前で~MUST。 ◎ 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による~key~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
この~keyに関係する`既定~動作$ — 文字を~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. 旧来の `MutationEvent^I ~event

変異~event~moduleは、 属性, ~text, 名前 に対する改変を含め,文書~構造における変化を通知できるようにするために設計されている。 ◎ The mutation and mutation name event modules are designed to allow notification of any changes to the structure of a document, including attribute, text, or name modifications.

注記: `MutationEvent$I ~ifcに結付けられている どの~event型も,取消~可能とされてはいない。 その~~理由は、[ 既存の,文書を改変するような~DOM~ifc ]を,[ それにより生じる~eventが取消されたときには,その変化が生じなくさせる ]ように用立てることが,とても困難である事実に因る。 これは,依然として 欲されている能力であるが、~DOMに対する~transaction~~機能の追加まで,~~延期された方が良いであろうと決められた。 ◎ None of the event types associated with the MutationEvent interface are designated as cancelable. This stems from the fact that it is very difficult to make use of existing DOM interfaces which cause document modifications if any change to the document might or might not take place due to cancelation of the resulting event. Although this is still a desired capability, it was decided that it would be better left until the addition of transactions into the DOM.

多くの場合、~DOM木に対する単独の改変から,複数の変異~eventの発火が生じ得る。 それらの変異~eventが発火される順序は,この仕様では指定されない — それは、実装に委ねられる。 ◎ Many single modifications of the tree can cause multiple mutation events to be dispatched. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation.

`MutationEvent^I ~ifc は、~DOM2 Events にて導入されたが、未だ,`~UA$間で完全にも相互運用可能にも実装されていない。 加えて,この設計による~ifcは、処理能を保ったまま実装するのが~~困難であると批判されている。 ◎ The MutationEvent interface was introduced in DOM Level 2 Events, but has not yet been completely and interoperably implemented across user agents. In addition, there have been critiques that the interface, as designed, introduces a performance and implementation challenge.

`MutationObserver^I ~ifcを利用する新たな仕組みが DOM4 `DOM$r にて供されている — それは、変異~eventが解決する利用~事例に,より高性能な方式で取組む。 したがって、この仕様は,旧来の挙動の参照と完全さのため,変異~eventについて述べるが、 `MutationEvent$I ~ifcの利用を`非推奨に$する。 ◎ DOM4 [DOM4] provides a new mechanism using a MutationObserver interface which addresses the use cases that mutation events solve, but in a more performant manner. Thus, this specification describes mutation events for reference and completeness of legacy behavior, but deprecates the use of the MutationEvent interface.

8.4.1. ~ifc `MutationEvent^I

~DOM2にて導入され、この仕様にて`非推奨に$された。 ◎ Introduced in DOM Level 2, deprecated in this specification

`MutationEvent^I ~ifcは、変異~eventに特有の文脈的~情報を供する。 ◎ The MutationEvent interface provides specific contextual information associated with Mutation events.

`MutationEvent^I ~ifcの~instanceを作成するためには、 `createEvent()$m ~methodを利用する。 ◎ To create an instance of the MutationEvent interface, use the createEvent() method call.

interface `MutationEvent@I : `Event$I {
    // `attrChange$m 値
    const unsigned short `MODIFICATION$m = 1;
    const unsigned short `ADDITION$m = 2;
    const unsigned short `REMOVAL$m = 3;

    readonly attribute `Node^I?          `relatedNode$m;
    readonly attribute ~DS      `prevValue$m;
    readonly attribute ~DS      `newValue$m;
    readonly attribute ~DS      `attrName$m;
    readonly attribute unsigned short `attrChange$m;

    void `initMutationEvent$m (~MANYARGS);
};
`MODIFICATION@m
`ADDITION@m
`REMOVAL@m
これらの定数は、順に, `Attr^I が[ 改変された/追加された/除去された ]ことを表す。 ◎ MODIFICATION • The Attr was modified in place. ◎ ADDITION • The Attr was just added. ◎ REMOVAL • The Attr was just removed.
`relatedNode@m
この属性は、変異~eventに関係する副~nodeを識別するために利用され~MUST。 例えば、~nodeに向けて,親が変更されたことを指示する変異~eventが発火された場合、この属性の値は,その変更された親になる。 代わりに,部分木の中のある~nodeが変化したことを指示する~eventが発火された場合、この属性の値は,変更された~nodeで~MUST。 `DOMAttrModified$et ~eventの事例では、それは, 【 `attrChange$m 属性の値に応じて】 [ 改変された / 追加された / 除去された ] `Attr^I ~nodeを指示する。 ◎ relatedNode MUST be used to identify a secondary node related to a mutation event. For example, if a mutation event is dispatched to a node indicating that its parent has changed, the relatedNode will be the changed parent. If an event is instead dispatched to a subtree indicating a node was changed within it, the relatedNode MUST be the changed node. In the case of the DOMAttrModified event, it indicates the Attr node which was modified, added, or removed.
`未初期化~値$: ~NULL ◎ The un-initialized value of this attribute MUST be null.
`prevValue@m
この属性は、[ `DOMAttrModified$et ~eventにおける `Attr^I ~node / `DOMCharacterDataModified$et ~eventにおける `CharacterData^I ~node ]の以前の値を指示する。 ◎ prevValue indicates the previous value of the Attr node in DOMAttrModified events, and of the CharacterData node in DOMCharacterDataModified events.
`未初期化~値$: `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
`newValue@m
この属性は、[ `DOMAttrModified$et ~eventにおける `Attr^I ~node / `DOMCharacterDataModified$et ~eventにおける `CharacterData^I ~node ]の新たな値を指示する。 ◎ newValue indicates the new value of the Attr node in DOMAttrModified events, and of the CharacterData node in DOMCharacterDataModified events.
`未初期化~値$: `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
`attrName@m
この属性は、 `DOMAttrModified$et ~eventにて変更された `Attr^I ~nodeの名前を 指示する。 ◎ attrName indicates the name of the changed Attr node in a DOMAttrModified event.
`未初期化~値$: `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
`attrChange@m
この属性は、 `DOMAttrModified$et ~eventを誘発した変更の種類 — `MODIFICATION$m / `ADDITION$m / `REMOVAL$m のいずれか — を指示する。 ◎ attrChange indicates the type of change which triggered the DOMAttrModified event. The values can be MODIFICATION, ADDITION, or REMOVAL. ◎ The un-initialized value of this attribute MUST be 0.
`未初期化~値$: 0
注記: `未初期化~値$ 0 に対しては、定義される定数は無い。 ◎ There is no defined constant for the attrChange value of 0 (the un-initialized value).
`initMutationEvent()@m
この~methodは、 `MutationEvent$I ~objの各種~属性を初期化する。 その挙動は `initEvent()$m と同じである。 いずれの引数も省略不可。 %relatedNodeArg のみ,~NULL もとり得る。 ◎ Initializes attributes of a MutationEvent object. This method has the same behavior as initEvent().
引数 説明
%typeArg `initEvent()$m ~methodのそれと同じ ◎ Refer to the initEvent() method for a description of this parameter.
%bubblesArg 同上 ◎ Refer to the initEvent() method for a description of this parameter.
%cancelableArg 同上 ◎ Refer to the initEvent() method for a description of this parameter.
%relatedNodeArg `relatedNode$m を指定する。 ◎ Specifies MutationEvent.relatedNode.
%prevValueArg `prevValue$m を指定する。 `空~文字列$でもよい。 ◎ Specifies MutationEvent.prevValue. This value MAY be the empty string.
%newValueArg `newValue$m を指定する。 `空~文字列$でもよい。 ◎ Specifies MutationEvent.newValue. This value MAY be the empty string.
%attrNameArg `attrName$m を指定する。 `空~文字列$でもよい。 ◎ Specifies MutationEvent.attrName. This value MAY be the empty string.
%attrChangeArg `attrChange$m を指定する。 0 でもよい。 ◎ Specifies MutationEvent.attrChange. This value MAY be 0.

8.4.2. 各種~旧来の変異~event型

以下に,各種~変異~event型を挙げる。 ◎ The mutation event types are listed below.

この仕様は、この節に挙げる~event型を,参照と完全さのために定義するが、これらの どの~event型の利用も`非推奨に$する。 ◎ The XXXXX event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.1. `DOMAttrModified^et
◎イ型 `DOMAttrModified@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈
  • `target$m: 属性が改変されている要素。 ◎ Event.target : element whose attribute is being modified
  • `MutationEvent$I :

    • `attrName$m: 変更された `Attr^I ~nodeの名前。 ◎ MutationEvent.attrName : the name of the changed Attr node
    • `attrChange$m: `Attr^I が[ 改変された/追加された/除去された ]かに応じて,対応する定数。 ◎ MutationEvent.attrChange : the numerical code corresponding to the most applicable attrChangeType
    • `relatedNode$m: [ 改変された/追加された/除去された ] `Attr^I ~node。 ◎ MutationEvent.relatedNode : the Attr node that has been modified, added, or removed.
    • `newValue$m: `Attr^I ~nodeが[ 改変された/追加された ]場合は,その新たな値。 ◎ MutationEvent.newValue : new value of the attribute, if the Attr node has been added or modified
    • `prevValue$m: `Attr^I ~nodeが[ 改変された/除去された ]場合は,その以前の値。 ◎ MutationEvent.prevValue : previous value of the attribute, if the Attr node has been removed or modified
◎表終

`~UA$は、[ `Attr.value^m が改変された, あるいは `Attr^I ~nodeが `Element^I に追加された/から除去された ]とき,この型の~eventを発火し~MUST。 この~eventの`~event標的$は、変更が生じた `Element^I ~nodeで~MUST。 この型の~eventが,[ 新たな値が `Attr.value^m に設定されたが,その値は元の値と同じである ]場合にも生じるかどうかは、実装~依存である。 ◎ A user agent MUST dispatch this event after an Attr.value has been modified and after an Attr node has been added to or removed from an Element. The event target of this event MUST be the Element node where the change occurred. It is implementation dependent whether this event type occurs when the children of the Attr node are changed in ways that do not affect the value of Attr.value. ◎ The DOMAttrModified event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.2. `DOMCharacterDataModified^et
◎イ型 `DOMCharacterDataModified@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 する ◎標的 `Text^I, `Comment^I, `ProcessingInstruction^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈

次を除き,`各種~変異~eventに共通する文脈~情報$にて与えられる:

  • `target$m: 内容が改変された~obj
  • `MutationEvent$I :

    • `relatedNode$m: 内容が改変された~objの親~node
    • `newValue$m: ~objの新たな値
    • `prevValue$m: ~objの以前の値
◎ • Event.target : object whose content is being modified • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : parent node of the object whose content is being modified • MutationEvent.newValue : new value of the object • MutationEvent.prevValue : previous value of the object ◎表終

`~UA$は、[ `CharacterData.data^m ]が改変されたとき,この型の~eventを発火し~MUST。 この~eventの`~event標的$は、その改変された~nodeで~MUST。 ◎ A user agent MUST dispatch this event after CharacterData.data or ProcessingInstruction.data have been modified, but the node itself has not been inserted or deleted. The event target of this event MUST be the CharacterData node or the ProcessingInstruction node. ◎ The DOMCharacterDataModified event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.3. `DOMNodeInserted^et
◎イ型 `DOMNodeInserted@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^I, `Attr^I, `Text^I, `Comment^I, `DocumentType^I, `ProcessingInstruction^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈

次を除き,`各種~変異~eventに共通する文脈~情報$にて与えられる:

  • `target$m: 挿入されている要素
  • `relatedNode$m: 挿入された~nodeの親~node, あるいは `Attr^I ~nodeの場合は その `ownerElement^m
◎ • Event.target : element which is being inserted • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : parent node of the node that has been inserted, or the ownerElement in the case of Attr nodes • MutationEvent.newValue : the empty string • MutationEvent.prevValue : the empty string ◎表終

`~UA$は、[ `Attr^I ~node以外の~nodeが 別の~nodeの子として追加された ]とき,この型の~eventを発火し~MUST。 `~UA$は[ `Attr^I ~nodeが`Element^I ~node に追加された ]ときにも,この~eventを発火して~MAY(次の注記を見よ)。 この~eventは、挿入し~~終えた後に配送され~MUST。 この~eventの`~event標的$は、挿入された~nodeで~MUST。 ◎ A user agent MUST dispatch this event type when a node other than an Attr node has been added as a child of another node. A user agent MAY dispatch this event when an Attr node has been added to an Element node (see note below). This event MUST be dispatched after the insertion has taken place. The event target of this event MUST be the node being inserted.

注記: 属性の挿入を検出するためには、代わりに `DOMAttrModified$et ~event型を利用する。 ◎ For detecting attribute insertion, use the DOMAttrModified event type instead. ◎ The DOMNodeInserted event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.4. `DOMNodeInsertedIntoDocument^et
◎イ型 `DOMNodeInsertedIntoDocument@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Element^I, `Attr^I, `Text^I, `Comment^I, `DocumentType^I, `ProcessingInstruction^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈 `DOMNodeInserted$et と同じ ◎ • Event.target : element which is being inserted • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : parent node of the node that has been inserted, or the ownerElement in the case of Attr nodes • MutationEvent.newValue : the empty string • MutationEvent.prevValue : the empty string ◎表終

`~UA$は、[ ~nodeが直に, または ~nodeを包含している部分木が 文書の中へ挿入された ]とき,この型の~eventを発火し~MUST。 `~UA$は、 `Attr^I ~nodeを `Element^I の部分木の一部として扱って~MAY。 この~eventは、挿入し~~終えた後に配送され~MUST。 この~eventの`~event標的$は、挿入された~nodeで~MUST。 ~nodeが直に挿入された場合、この型の~eventの前に,型 `DOMNodeInserted$et の~eventが生じ~MUST。 ◎ A user agent MUST dispatch this event when a node has been inserted into a document, either through direct insertion of the node or insertion of a subtree in which it is contained. A user agent MAY treat an Attr node as part of an Element’s subtree. This event MUST be dispatched after the insertion has taken place. The event target of this event MUST be the node being inserted. If the node is being directly inserted, the event type DOMNodeInserted MUST occur before this event type. ◎ The DOMNodeInsertedIntoDocument event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.5. `DOMNodeRemoved^et
◎イ型 `DOMNodeRemoved@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^I, `Attr^I, `Text^I, `Comment^I, `DocumentType^I, `ProcessingInstruction^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈

次を除き,`各種~変異~eventに共通する文脈~情報$にて与えられる:

  • `target$m: 除去された要素
  • `relatedNode$m: 除去された~nodeの親~node, あるいは `Attr^I ~nodeの場合は その `ownerElement^m
◎ • Event.target : element which is being removed • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : the parent node of the node being removed, or the ownerElement in the case of Attr nodes • MutationEvent.newValue : the empty string • MutationEvent.prevValue : the empty string ◎表終

`~UA$は、[ `Attr^I ~node以外の~nodeが その親~nodeから除去されつつある ]とき,この型の~eventを発火し~MUST。 `~UA$は[ `Attr^I ~nodeが その `ownerElement^m から除去されつつある ]とき、この~eventを発火しても~MAY(次の注記を見よ)。 この~eventは、除去し~~終える前に配送され~MUST。 この~eventの`~event標的$は、除去されつつある~nodeで~MUST。 ◎ A user agent MUST dispatch this event when a node other than an Attr node is being removed from its parent node. A user agent MAY dispatch this event when an Attr node is being removed from its ownerElement (see note below). This event MUST be dispatched before the removal takes place. The event target of this event MUST be the node being removed.

注記: 属性の除去を依拠-可能に検出するためには、代わりに `DOMAttrModified$et ~event型を利用する。 ◎ For reliably detecting attribute removal, use the DOMAttrModified event type instead. ◎ The DOMNodeRemoved event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.6. `DOMNodeRemovedFromDocument^et
◎イ型 `DOMNodeRemovedFromDocument@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Element^I, `Attr^I, `Text^I, `Comment^I, `DocumentType^I, `ProcessingInstruction^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈 `DOMNodeRemoved$et と同じ ◎ • Event.target : element which is being removed • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : the parent node of the node being removed, or the ownerElement in the case of Attr nodes • MutationEvent.newValue : the empty string • MutationEvent.prevValue : the empty string ◎表終

`~UA$は、[ ~nodeが直に, または ~nodeを包含している部分木が 文書から除去されつつある ]とき,この型の~eventを発火し~MUST。 `~UA$は、 `Attr^I ~nodeを`Element^I の部分木の一部として扱って~MAY。 この~eventは、除去し~~終える前に配送され~MUST。 この型の~eventの`~event標的$は、除去されつつある~nodeで~MUST。 ~nodeが直に除去される場合、この型の~eventの前に,型 `DOMNodeRemoved$et の~eventが生じ~MUST。 ◎ A user agent MUST dispatch this event when a node is being removed from a document, either through direct removal of the node or removal of a subtree in which it is contained. A user agent MAY treat an Attr node as part of an Element’s subtree. This event MUST be dispatched before the removal takes place. The event target of this event type MUST be the node being removed. If the node is being directly removed, the event type DOMNodeRemoved MUST occur before this event type.

注記: 属性の除去を依拠-可能に検出するためには、代わりに `DOMAttrModified$et ~event型を利用する。 ◎ For reliably detecting attribute removal, use the DOMAttrModified event type instead. ◎ The DOMNodeRemovedFromDocument event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

8.4.2.7. `DOMSubtreeModified^et
◎イ型 `DOMSubtreeModified@et ◎界面 `MutationEvent$I ◎同期 あり ◎浮上 する ◎標的 `Window$I, `Document^I, `DocumentFragment^I, `Element^I, `Attr^I ◎取消 不可 ◎構 No ◎既定動作 なし ◎文脈

次を除き,`各種~変異~eventに共通する文脈~情報$にて与えられる:

  • `target$m: 改変された部分木の親【根?】~node
◎ • Event.target : parent node of subtree being modified • MutationEvent.attrName : the empty string • MutationEvent.attrChange : 0 • MutationEvent.relatedNode : null • MutationEvent.newValue : the empty string • MutationEvent.prevValue : the empty string ◎表終

これは、文書に対するすべての変更を通知するための一般~eventである、より特定の変異~eventの代わりに利用できる。 これは、文書に対する単独の改変の後,あるいは 実装の裁量により 複数の変更が生じた後に発火されて~MAY。 後者の事例は、一般に,同時または頻繁に生じるような複数の変更に適応するために利用される~SHOULDである。 この~eventの標的は、変更に関わった~nodeたちの共通の親†のうち,最も子孫のもので~MUST 【† 共通の先祖? 一つの~nodeのみの場合は~node自身?】 。 この~eventは、生じた変異(たち)により生じる他のどの~eventよりも後に配送され~MUST。 ◎ This is a general event for notification of all changes to the document. It can be used instead of the more specific mutation and mutation name events. It MAY be dispatched after a single modification to the document or, at the implementation’s discretion, after multiple changes have occurred. The latter case SHOULD generally be used to accommodate multiple changes which occur either simultaneously or in rapid succession. The target of this event MUST be the lowest common parent of the changes which have taken place. This event MUST be dispatched after any other events caused by the mutation(s) have occurred. ◎ The DOMSubtreeModified event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

各種~変異~eventに共通する文脈~情報(trusted events)

【 この訳では、各所に共通する記述をこの節に集約する。 】

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

`MutationEvent$I :
`attrName$m
`空~文字列$ ◎ MutationEvent.attrName : the empty string
`attrChange$m
0 ◎ MutationEvent.attrChange : 0
`relatedNode$m
~NULL ◎ MutationEvent.relatedNode : null
`newValue$m
`空~文字列$ ◎ MutationEvent.newValue : the empty string
`prevValue$m
`空~文字列$ ◎ MutationEvent.prevValue : the empty string

9. ~eventの拡張-法

~INFORMATIVE

9.1. 序論

この仕様は,いくつかの~ifcと多数の~eventを定義するが、あらゆる目的を網羅するわけではない。 この仕様は、内容~作者や実装者が,この~ifc&~eventの集合を,競合することなく拡張して、 欲される機能性を追加できるようにするための, 2 つの仕組み ~custom~event, および 実装~特有の拡張 を供する。 ◎ 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 ~ifcを利用して,利用している抽象化~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:

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型に[ 実装~特有の 短い接頭辞 ]を付与する~SHOULDである。 これは、 CSS における ~vendor特有の~keyword接頭辞 に類似する。 CSS で利用されている~dash( `"-"^c )はないが。 それは Javascript にて属性~名に利用するときに問題になるので。 ◎ 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:

接頭辞◎ Prefix Web Engine ( 開発元 )◎ Web Engine (Organization)
`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. 保安上の考慮点

この付録では、 UI Events の実装における保安上の考慮点について論じる。 論点は、[ この仕様にて定義される ~event~model, ~API, ~event ]の実装から直に発生する保安上の課題に限られる。 実装は,概して、[ ~scripting言語 / 他の~API / この文書にて定義されない追加の~event ]の様な,他の特色機能を~supportする。 これらの特色機能は,未知の因子を成すので、この文書の視野~外である。 実装者は、そのような特色機能に関する保安上の考慮点については,それを~~規定している仕様にあたる~SHOULDである。 ◎ 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 ~ifcなどの,~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の環境に関する~sensitive情報 ]への~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 のみの実装は,この種類の攻撃を遂行するには一般に不十分であり、保安上の考慮点は,そのような攻撃を~supportし得る利便性に適用される。 この仕様への適合性においては、~DOM実装は、 `~DOM~app$が 機密的/~sensitive な情報へ~accessできなくするために必要とされる手続きを採って~MAY。 例えば、~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との間の変更点

~ifcと~event型に対しいくつもの明確化がなされた。 `HTMLEvents^I ~moduleは、この文書では最早~定義されない。 `focus$et/`blur$et ~eventは `UIEvent$I ~moduleに追加され, `dblclick$et ~eventは `MouseEvent$I ~moduleに追加された。 この新たな仕様は、 ~DOM~event~flow, ~event型, ~DOM~ifc の間を より良く分離する。 ◎ 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型に利用される~ifcを通してのみならず。 ◎ 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.

`MutationEvents^I は`非推奨に$された。 この仕様の早期の草案には在った名前空間付き~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を発火することを要求しない。 ◎ 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~ifcに対する変更点

`Event$I ~ifc
新たな属性 `defaultPrevented$m, および 新たな~method `stopImmediatePropagation()$m が加えられた。 ◎ The Event interface has one new attribute, defaultPrevented, and one new method, stopImmediatePropagation().
`timeStamp$m 属性は,今や ECMAScript 言語束縛の `Number^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 ~ifc
`dispatchEvent()$m ~methodは、改変された。 ◎ The method dispatchEvent() was modified.
`MouseEvent$I ~ifc
新たな~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. 新たな~ifc

次の~ifcが~Events~moduleに追加された:

  • `CustomEvent$I
  • `FocusEvent$I
  • `KeyboardEvent$I
  • `CompositionEvent$I
  • `WheelEvent$I
◎ The interfaces CustomEvent, FocusEvent, KeyboardEvent, CompositionEvent, and WheelEvent were added to the Events module.

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 は,一部の実装を見ていて, 他の仕様からも参照されているので、この仕様を現在の環境に依然として適応させつつ,分裂を極力抑えるように配慮されてきた。 ◎ 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:

  • ~keyに対する一意な識別子と~~区別するため、 “~key識別子”の特色機能は,“`~key値$”に改称された。 ◎ The "key identifier" feature has been renamed "key value" to disambiguate them from unique identifiers for keys.
  • `KeyboardEvent$I ~ifcは、( 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 ~ifcに, `locale^m 属性が定義された。 この属性は、~~策定中にあり,必要十分に指定されるまで, technical note へ移行された。 詳細は、 この UI Events 仕様の旧~version ( 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特有であり, `HTML5$r にて指定されるので。 ◎ The change, submit, and reset events were removed, since they were specific to HTML forms, and are specified in [HTML5].
  • 現在の `beforeinput$et, `input$et ~eventへの支持を受けて,[ 元々は `keypress$et 用の代用として提案された `textInput^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.

13. 用語集

【 ここでは、原文の用語集の中から,主に適合性に関する用語を挙げる。 他の用語は、別ページにて。 】

`作者@ ( author )
この仕様の文脈においては、 作者内容~作者~script作者 は、この仕様にて定義される ~ifc, ~event, ~event~flowを利用する ~scriptや他の実行-可能な内容を書く者である。 詳細は、適合性の類別における 内容~作者と内容 を見よ。 ◎ 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.
`~UA@ ( user agent )
~browserや内容~著作toolなど、通常は~client~machine上で稼働し,利用者の利益を代表して 内容を[ 検索取得-, 解釈-, 実行-, 呈示-, 作成- ]するために動作するような~programを~~指す。 利用者は、その時々に応じて,異なる~UAを異なる目的で利用して,内容とやりとりすることもある。 適合 ~UAに課される要件の詳細は、 ~Web~browserその他の 動的/対話的 ~UA, 著作tool を見よ。 ◎ A program, such as a browser or content authoring tool, normally running on a client machine, which acts on a user’s behalf in retrieving, interpreting, executing, presenting, or creating content. Users MAY act on the content using different user agents at different times, for different purposes. See the §1.2.1 Web browsers and other dynamic or interactive user agents and §1.2.2 Authoring tools for details on the requirements for a conforming user agent.
`非推奨@ ( deprecated )
非推奨と~markされた特色機能は、古い実装や仕様への参照として,この仕様に含まれてはいるが、任意選択であり,利用しないことが奨励される。 非推奨にされるのは、この仕様において,既存のまたは進捗~中の代用があるものに限られ~MUST。 特色機能をまだ~supportしていない実装は、既存の内容との後方互換性の理由で,非推奨の特色機能を実装しても~MAYが、内容~作者は,利用~事例を解決する仕方が他にあるならば,非推奨の特色機能を利用する~SHOULDでない。 この仕様を参照する他の仕様は、特色機能が非推奨にされたことへの支持を受けて,非推奨の特色機能は利用せずに,その代用を参照する~SHOULDである。 この仕様にて非推奨と~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.
`~DOM~app@ ( DOM application )
~DOM~appは、[ 内容~作者により書かれた~script, または 自動的に生成された~code ]であって、動的な または対話的な内容を作るために,[ ~ifc, ~method, 属性, ~event, その他,この仕様にて述べられた特色機能 ]を利用するものである。 例えば、~UAにて利用者に公開される~Web~app。 ◎ A DOM application is script or code, written by a content author or automatically generated, which takes advantage of the interfaces, methods, attributes, events, and other features described in this specification in order to make dynamic or interactive content, such as Web applications, exposed to users in a user agent.
`~host言語@ ( host language )
別の言語や~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.

12. 謝辞

DOM Working Group, DOM Interest Group, WebAPI Working Group, WebApps Working Group に携わった方々を含め,多くの方々が~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), 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), 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), 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), Ramesh Lekshmynarayanan (Merrill Lynch), Ray Whitmer (iMall, Excite@Home, and Netscape/AOL, Chair), Rezaur Rahman (Intel), Rich Rollman (Microsoft), Rick Gessner (Netscape), Rick Jelliffe (invited), Rob Relyea (Microsoft), Robin Berjon (Expway, Co-Chair), 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 Working Group の中では、次の方々が,この仕様を改良し, 改訂する過程に大きく貢献された: ◎ 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.

提言や訂正を送信して(バグがあれば、課題を~~提出されたし!), あるいは 参考本や~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.

参照文献

【 ここには、この付録ページに固有のもののみ挙げる。 】