UI Events — 適合性, 付録

UI Events を成す他の部分の日本語訳

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実装に対する一般的な考慮点が適用される。 適合性 についての追加的な情報は、 `DOM-Level-3-Core$r を見よ。 `~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]
  • `~event配送と~DOM~event~flow$の仕組み。 ◎ the Event dispatch and DOM event flow mechanism
  • この仕様にて定義される すべての[ ~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型 ]にて指定される,関係する`~event型$を実装する~browserは、 特定的に~UI~Eventsに適合する。 ◎ A browser conforms specifically to UI Events if it implements the interfaces and related event types specified in § 5 Event Types.

適合~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にて定義される[ `~event配送と~DOM~event~flow$の仕組み/~interface/~event/その他の特能 ]を利用する,この仕様には見出されない特能 ]も~supportして,その実装に適切な追加的な[ ~interface/`~event型$ ]を実装してもヨイ。 そのような特能は、 将来の仕様にて標準~化され得る。 ◎ 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に適合していると主張してはナラナイ。 そのような実装は、 この仕様の一部の事項に適合するならば, それらの特定の事項に適合していると主張してもヨイ。 ◎ 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.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 に適合していると主張してはナラナイ。 ◎ 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型$, ~interface ]すべてに対し,それらを利用する手段を内容~作者に供するベキである。 ◎ 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.

内容~作者は、 この仕様にて`非推奨に$された特能を利用するベキでない — この仕様や他所にて定義される代用の仕組みに依拠するベキである。 ◎ 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.

適合~内容は、[ ~interface/`~event型$ ]の意味論をこの仕様にて述べるとおりに利用しなければナラナイ。 ◎ 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$の仕組み, ~interface, ~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言語$ ]は、[[ 各~interface, § ~event型 ]にて指定される,関係する`~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 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言語$ ]は、 この仕様にて`非推奨に$された特能を[ 利用する/推奨する ](順不同)ことなく,(可用なら)その特能の代用として,この仕様にて指示されるものを[ 利用する/推奨する ](順不同)ベキである。 ◎ 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).

7. 旧来の~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.

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

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

7.1. 旧来の~event初期化子~interface

~INFORMATIVE

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

7.1.1. `UIEvent^I ~interface用の初期化子

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

7.1.2. `MouseEvent^I ~interface用の初期化子

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

7.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 (see § 12.2 Changes between different drafts of UI Events); it is necessary to preserve this inconsistency for compatibility with existing implementations.

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

7.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 (see § 12.2 Changes between different drafts of UI Events); it is necessary to preserve this inconsistency for compatibility with existing implementations.

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

8. 旧来の[~UIkey/~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$内に在ってもヨイが。 作者は、[ `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.

8.1. 旧来の `UIEvent^I 補足的~interface

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

8.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する
    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.

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

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

8.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する
    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 を見よ。 ◎ See § 8.3 Legacy key models for more details on how to determine the values for keyCode.

8.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する
    `unsigned long$ `charCode$d = 0;
    `unsigned long$ `keyCode$d = 0;
};
`charCode@d ◎ charCode, of type unsigned long, readonly
`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, readonly
`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.

8.3. 旧来の~UIkey~model

~INFORMATIVE

これらの属性~上にどの値が公開されるかは、 ~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).

8.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$が~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.
  2. 入力~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.
  3. 入力~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.
  4. 実装が ~OS/~platform用の~UIkey~code変換表を~supportしていて、 その表に,与えられた入力に対する代替の仮想~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.
  5. 実装に特有な仕方で決定される~UIkeyの機能が,[ 固定的な仮想~UIkey~code表 内のいずれかの~UIkey ]に対応する場合、 それに対応する~UIkey~codeを返す。 ◎ If the key’s function, as determined in an implementation-specific way, corresponds to one of the keys in the § 8.3.3 Fixed virtual key codes table, return the corresponding key code.
  6. ~OSの~event情報によるによる仮想~UIkey~codeが可用な場合: その~UIkey~codeを返す。 ◎ ↑Return the virtual key code from the operating system.
  7. 他の場合、 0 を返す。 ◎ If no key code was found, return 0.

8.3.2. `keypress^et~eventに対し `keyCode^m を決定する方法

`keypress$et ~event用の `keyCode$m は、 次に従って計算される: ◎ The keyCode for keypress events is calculated as follows:

  1. 実装が `~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.
  2. 実装が `~split~model^emを~supportする場合: `keyCode$m を 0 に設定する。 ◎ If the implementation supports a split model, set keyCode to 0.

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

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

次の一覧に,この仕様にて`非推奨に$された~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$な`標的$ ~DOM~interface 取消~可否 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$を立上げる/ `blur$et / `focus$et ~event/ `DOMActivate$et ~event/ 他の~event ◎ Varies: launch text composition system; blur and focus events; DOMActivate event; other event

9.1. 旧来の `UIEvent^I ~event

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

9.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を発火するモノトスル。 詳細は、 § 作動化の誘発と挙動 に。 ◎ 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型$を定義して保守してもヨイ。 ◎ 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.

したがって, `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型$を利用するベキである — 広く実装から~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
◎イ型 `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を発火するモノトスル。 標的~要素が~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
◎イ型 `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を発火するモノトスル。 要素は、 この型の~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される場合のみ

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

9.3.1. 旧来の各種 `KeyboardEvent^I ~event型

9.3.1.1. `keypress^et
◎イ型 `keypress@et ◎界面 `KeyboardEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element^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 ◎文脈

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

  • `charCode$m: この~event用の旧来の文字~値
  • `keyCode$m: この~UIkey用の旧来の数量的な~code
  • `which$m: この~UIkey用の旧来の数量的な~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.which : legacy numerical code for this key • KeyboardEvent.charCode : legacy character value for this event • KeyboardEvent.keyCode : 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するならば,[ ~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~mapping$の後に生成するモノトスル。 また、`~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.

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

9.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 ~interfaceに結付けられている どの~event型も,取消~可能とされてはいない。 その~~理由は、[ 既存の,文書を改変するような~DOM~interface ]を,[ それにより生じる~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~treeに対する単独の改変の多くは,複数の変異~eventを発火させ得る。 この仕様は、 ~treeに対しアリなあらゆる改変に因る変異~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 ~interface は、~DOM2 Events にて導入されたが、 未だ,`~UA$間で完全にも相互運用可能にも実装されていない。 加えて,この設計による~interfaceは、 処理能を保ったまま実装するのが~~困難であると批判されている。 ◎ 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 ~interfaceを利用する新たな仕組みが DOM4 `DOM$r にて供されている — それは、変異~eventが解決する利用事例に,より高処理能な方式で取組む。 したがって、 この仕様は,旧来の挙動の参照と完全さのため,変異~eventについて述べるが、 `MutationEvent$I ~interfaceの利用を`非推奨に$する。 ◎ 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.

9.4.1. `MutationEvent^I ~interface

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

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

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

[`Exposed$=Window]
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 `DOMString$      `prevValue$m;
    readonly attribute `DOMString$      `newValue$m;
    readonly attribute `DOMString$      `attrName$m;
    readonly attribute `unsigned short$ `attrChange$m;

    `undefined$ `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 ◎ relatedNode, of type Node, readonly, nullable
この属性は、 変異~eventに関係する副~nodeを識別するために利用するモノトスル。 例えば、~nodeに向けて,親が変更されたことを指示する変異~eventが発火された場合、 この属性の値は,その変更された親になる。 代わりに,下位treeの中のある~nodeが変化したことを指示する~eventが発火された場合、 この属性の値は,変更された~nodeになるモノトスル。 `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 ◎ prevValue, of type DOMString, readonly
この属性は、[ `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 ◎ newValue, of type DOMString, readonly
この属性は、[ `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 ◎ attrName, of type DOMString, readonly
この属性は、 `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 ◎ attrChange, of type unsigned short, readonly
この属性は、 `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 ◎ initMutationEvent(typeArg)
この~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.

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

9.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を発火するモノトスル。 この~eventの`~event標的$は、 変更が生じた `Element^I ~nodeになるモノトスル。 この型の~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.

9.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を発火するモノトスル。 この~eventの`~event標的$は、 その改変された~nodeになるモノトスル。 ◎ 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.

9.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を発火するモノトスル。 `~UA$は[ `Attr^I ~nodeが`Element^I ~node に追加された ]ときにも,この~eventを発火してヨイ(次の注記を見よ)。 この~eventは、 挿入し~~終えた後に配送するモノトスル。 この~eventの`~event標的$は、 挿入された~nodeになるモノトスル。 ◎ 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.

9.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を包含している下位treeが 文書の中へ挿入された ]とき,この型の~eventを発火するモノトスル。 `~UA$は、 `Attr^I ~nodeを `Element^I の下位treeの一部として扱ってもヨイ。 この~eventは、 挿入し~~終えた後に配送するモノトスル。 この~eventの`~event標的$は、 挿入された~nodeになるモノトスル。 ~nodeが直に挿入された場合、 この型の~eventの前に,型 `DOMNodeInserted$et の~eventが生じるモノトスル。 ◎ 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.

9.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を発火するモノトスル。 `~UA$は[ `Attr^I ~nodeが その `ownerElement^m から除去されつつある ]とき、 この~eventを発火してもヨイ(次の注記を見よ)。 この~eventは、 除去し~~終える前に配送するモノトスル。 この~eventの`~event標的$は、 除去されつつある~nodeになるモノトスル。 ◎ 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.

9.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を包含している下位treeが 文書から除去されつつある ]とき,この型の~eventを発火するモノトスル。 `~UA$は、 `Attr^I ~nodeを`Element^I の下位treeの一部として扱ってもヨイ。 この~eventは、 除去し~~終える前に配送するモノトスル。 この型の~eventの`~event標的$は、 除去されつつある~nodeになるモノトスル。 ~nodeが直に除去される場合、 この型の~eventの前に,型 `DOMNodeRemoved$et の~eventが生じるモノトスル。 ◎ 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.

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

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

  • `target$m: 改変された下位treeの親【根?】~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の代わりに利用できる。 実装は、[ 文書に対する単独の改変の後 ]に, あるいは自身の裁量により[ 複数の変更が生じた後 ]に,これを発火してもヨイ。 後者の事例は、 一般に,同時または頻繁に生じるような複数の変更に適応するために利用されるベキである。 この~eventの標的は、 変更に関わった~nodeたちに共通な親†のうち,最も子孫のものになるモノトスル 【† 共通な先祖? 一つの~nodeのみの場合は~node自身?】 。 この~eventは、 生じた変異(たち)により生じる他のどの~eventよりも後に配送するモノトスル。 ◎ 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^en )

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

変異~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

10. ~eventの拡張-法

~INFORMATIVE

10.1. 序論

この仕様は,いくつかの~interfaceと多数の~eventを定義するが、 あらゆる目的を網羅するわけではない。 この仕様は、 この[ ~interface/~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.

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

var chartData = ...;
var evt = document.createEvent("CustomEvent");
evt.initCustomEvent( "updateChart", true, false, { data: chartData });
document.documentElement.dispatchEvent(evt);

10.3. 実装に特有な拡張

新たに設計される原型的な~eventや,実装に特有な機能性~用に意図される~eventは、 標準~化された~eventから判別されることが望ましい。 その種の~eventを[ 他の実装による同じ~event/標準~化された~event ]と判別できるよう、 実装者は,当の~event型に[ 実装に特有な短い接頭辞 ]を付与するベキである。 これは、 CSS における ~vendorに特有な~keyword接頭辞 に類似する。 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).

10.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, 他)
◎ Prefix Web Engine Organization moz, Moz Gecko Mozilla ms, MS Trident Microsoft o, O Presto Opera Software webkit WebKit Apple, Google, others

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

12. 変更点

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

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

12.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を発火することは要求しない。 ◎ 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.

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

12.1.4. 新たな~interface

次の~interfaceが~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.

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

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

14. 用語集

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

`作者@ ( `author^en )
この仕様の文脈における[ `作者^em / `内容~作者^em / `~script作者^em ]は、 この仕様にて定義される ~interface, ~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^en )
~browserや内容~著作~toolなど、 通常は~client~machine上で稼働し,利用者に利するよう 内容を[ 検索取得-, 解釈-, 実行-, 呈示-, 作成- ]するために動作する~programを~~指す。 利用者は、 その時々に応じて,異なる~UAを異なる目的で利用して内容とやりとりすることもある。 `適合^em ~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.
`非推奨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.
`~DOM~app@ ( `DOM application^en )
~DOM~appは、[ 内容~作者により書かれた~script, または 自動的に生成された~code ]であって、 動的な または対話的な内容を作るために,[ ~interface, ~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^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.

13. 謝辞

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.