1. 序論
1.1. 概観
~UI~Eventsは、 ~~主に二つの目標を念頭に設計されている。 第一の目標は、 `~event$~systemを，`~event~listener$を登録できるように, および ~event~flowを~tree構造を通して述べ得るように設計することである。 加えて，この仕様は、 ~UI~controlや文書の変異† — これら各~event~module用に定義済みな文脈的~情報を含む — を通知するための，~eventの標準的な~moduleを供する。 ◎ UI Events is designed with two main goals. The first goal is the design of an event system which allows registration of event listeners and describes event flow through a tree structure. Additionally, the specification will provide standard modules of events for user interface control and document mutation notifications, including defined contextual information for each of these event modules.
【† `変異~event＠~UIEVENTS-A#legacy-mutationevent-events$hrefは、 `非推奨に$され， `DOM$r により `MutationObserver$I として定義し直された。 】
~UI~Eventsの第二の目標は、 既存の~browserに利用されている，現在の~event~systemに共通な~~機能を供することである。 これには、 既存の［ ~script, 内容 ］との相互運用能を~~促進することが意図されている。 この目標には、 後方-互換性を全部的に満たすことは，期待されていない。 しかしながら，この仕様は、 アリな所では これを達成しようと試みる。 ◎ The second goal of UI Events is to provide a common subset of the current event systems used in existing browsers. This is intended to foster interoperability of existing scripts and content. It is not expected that this goal will be met with full backwards compatibility. However, the specification attempts to achieve this when possible.
1.2. 適合性
`ui-events-conformance^APX2. ~style上の規約
この仕様では、 次の表記が用いられる 【！`Proposed W3C Specification Conventions＠http://www.w3.org/People/Schepers/spec-conventions.html$ に従う】： ◎ This specification follows the Proposed W3C Specification Conventions, with the following supplemental additions:
| 表記~例 | 意味 |
|---|---|
| `↓^cap, `=^cap, `Q^cap | ~UIkey上に印字される `~UIkey~cap＠#key-legends$href。 この表記は、 生成される `KeyboardEvent!I の `key$m, `code$m 値には関わらない，利用者~視点の~UIkeyを指すときに利用される。 |
| `ア^kGl, `~~漢字^kGl | 文字／文字~並びを表現している~glyph並び |
| `003D^U | ~Unicode文字 |
| `ArrowDown$kY, `=^kY, `q^kY, `Q^kY | ~UIkeyを押して生成される~UIkey値 （すなわち、 `KeyboardEvent^I の `key$m 値） の名前 |
| `ArrowDown$kC, `Equal$kC, `KeyQ$kC | 物理的な~UIkeyに結付けられた~UIkey~code （すなわち、 `KeyboardEvent^I の `code$m 値） の名前 |
加えて，この仕様における一定の用語は、 特定0の意味で利用される。 語 “実装”は、 ~browser, 内容~著作~tool, その他，この仕様を実装する`~UA$を~~指す。 語 内容~作者は、 ~interface, ~method, 属性, ~event, その他，この仕様にて述べる他の特能を利用する~scriptや~codeを書いて，~Web~appを作る者を~~指す。 利用者とは，ある実装の下で それらの~Web~appを利用する者を~~指す。 ◎ In addition, certain terms are used in this specification with particular meanings. The term "implementation" applies to a browser, content authoring tool, or other user agent that implements this specification, while a content author is a person who writes script or code that takes advantage of the interfaces, methods, attributes, events, and other features described in this specification in order to make Web applications, and a user is the person who uses those Web applications in an implementation. ◎ And finally: • This is a note. • This is an open issue. • This is a warning. interface Example { // This is an IDL definition. }
3. ~DOM~event~architecture
この節は規範的ではない。 ~DOM~event~architectureの規範的な記述は `DOM$r を見よ。 ◎ This section is non-normative. Refer to [DOM] for a normative description of the DOM event architecture
3.1. ~event配送-と~DOM~event~flow
この節では、 ~event`配送-$の仕組みの概観を与え， ~eventが~DOM~treeを通してどう伝播するかについて述べる。 ~appは， `dispatchEvent()$m ~methodを利用して~event~objを配送して、 ~event~objは，~DOM~event~flowにより決定されるとおり~DOM~treeを通して伝播する。 ◎ This section gives a brief overview of the event dispatch mechanism and describes how events propagate through the DOM tree. Applications can dispatch event objects using the dispatchEvent() method, and the event object will propagate through the DOM tree as determined by the DOM event flow.
~event~objは，`~event~target$に向けて配送されるが、 その前に~event~objの`伝播~経路$を決定する必要がある。 ◎ Event objects are dispatched to an event target. But before dispatch can begin, the event object’s propagation path must first be determined.
`伝播~経路$は，`現在の~event~target$たちからなる有順序~listであり、 ~eventはそれらを通過する。 この伝播~経路は、 文書の階層的~tree構造を反映する。 ~list内の最後の~itemが`~event~target$になり、 ~list内で先行する~itemは `~targetの先祖^emとされ, 直前の~itemが `~targetの親^emとされる。 ◎ The propagation path is an ordered list of current event targets through which the event passes. This propagation path reflects the hierarchical tree structure of the document. The last item in the list is the event target, and the preceding items in the list are referred to as the target’s ancestors, with the immediately preceding item as the target’s parent.
`伝播~経路$が決定されたなら、 ~event~objは， 1 つ以上の`~event相$を経る。 ~event相には、［ `捕捉-相$, `~target相$, `浮上-相$ ］の 3 つがある。 ~event~objは、 これらの相を下に述べるように完了する。 ~supportされない相は，飛ばされる。 相はまた，~event~objの伝播が停止された場合にも飛ばされる。 例えば、 `bubbles$m 属性が ~F に設定された場合，浮上-相は飛ばされ、 配送するに先立って `stopPropagation()$m が~callされた場合， すべての相は飛ばされることになる。 ◎ Once the propagation path has been determined, the event object passes through one or more event phases. There are three event phases: capture phase, target phase and bubble phase. Event objects complete these phases as described below. A phase will be skipped if it is not supported, or if the event object’s propagation has been stopped. For example, if the bubbles attribute is set to false, the bubble phase will be skipped, and if stopPropagation() has been called prior to the dispatch, all phases will be skipped.
- `捕捉-相@ （ `capture phase^en ） ◎ The capture phase:＼
- この相の下では、 ~event~objは，`伝播~経路$を順方向に通って~targetの手前まで伝播する。 すなわち、 `~window$から~targetの親まで，~targetの各~先祖を通ることになる。 ◎ The event object propagates through the target’s ancestors from the Window to the target’s parent. This phase is also known as the capturing phase.
- `~target相@ （ `at-target phase^en ） ◎ The target phase:＼
- ~event~objは、 その`~target$に到着する。 `~event型$にて，~eventは浮上しないものと指示されている場合、 ~eventの伝播は，この相の完了を以って終える。 ◎ The event object arrives at the event object’s event target. This phase is also known as the at-target phase. If the event type indicates that the event doesn’t bubble, then the event object will halt after completion of this phase.
- `浮上-相@ （ `bubble phase^en ） ◎ The bubble phase:＼
- この相の下では、 ~event~objは，`捕捉-相$のときと同じ`伝播~経路$を，その逆順に通ることになる。 すなわち、 ~targetの親から`~window$まで，~targetの各~先祖を通って伝播することになる。 ◎ The event object propagates through the target’s ancestors in reverse order, starting with the target’s parent and ending with the Window. This phase is also known as the bubbling phase.
3.2. 既定~動作と取消~可能な~event
~eventは、 概して，［ 利用者-動作の結果として ／ ~taskの完了に呼応して ／ 非同期的~活動（~network要請など）の進捗を通達するために ］実装により発火される。 ~eventには、 その後に実装が次に採り得る挙動を制御する （または すでに採った動作を元に戻す） ために利用されるものもある。 この類の~eventは， `取消~可能@ と称され、 それが取消す挙動は`既定~動作$と称される。 `取消~可能$な~event~objには、 複数の`既定~動作$が結付けられることもある。 ~eventを取消すためには、 `preventDefault()$m ~methodを~callする。 ◎ Events are typically dispatched by the implementation as a result of a user action, in response to the completion of a task, or to signal progress during asynchronous activity (such as a network request). Some events can be used to control the behavior that the implementation may take next (or undo an action that the implementation already took). Events in this category are said to be cancelable and the behavior they cancel is called their default action. Cancelable event objects can be associated with one or more 'default actions'. To cancel an event, call the preventDefault() method.
`mousedown$et ~eventは、 利用者が~pointing装置（概して~mouse）の~buttonを押した直後に発火される。 実装に採り得る`既定~動作$の一つには、［ 利用者が 画像や選択~textを~dragできるように，状態~machineを設定しておく ］ことが挙げられる。 `既定~動作$は，次に何が起きるかに依存する — 例えば、 利用者の~pointing装置が~text上を指していれば，~text選択が始まり、 画像~上を指していれば，画像の~drag動作が始まるであろう。 `mousedown$et ~eventの`既定~動作$を防止すると、 これらの動作は生じなくなる。 ◎ A mousedown event is dispatched immediately after the user presses down a button on a pointing device (typically a mouse). One possible default action taken by the implementation is to set up a state machine that allows the user to drag images or select text. The default action depends on what happens next — for example, if the user’s pointing device is over text, a text selection might begin. If the user’s pointing device is over an image, then an image-drag action could begin. Preventing the default action of a mousedown event prevents these actions from occurring.
`既定~動作$は，通例、 ~event配送-が完了した後に遂行されるベキであるが、 例外的~事例では，~eventが配送される直前に遂行されることもある。 ◎ Default actions are usually performed after the event dispatch has been completed, but in exceptional cases they may also be performed immediately before the event is dispatched.
`input type="checkbox"^e 要素~上の `click$et ~eventに結付けられた既定~動作は、 その要素の `checked^c ~IDL属性~値を 【~eventが配送される前に】 ~toggleする。 `click$et ~eventの既定~動作が取消された場合、 値は~~元の状態に戻される。 ◎ The default action associated with the click event on <input type="checkbox"> elements toggles the checked IDL attribute value of that element. If the click event’s default action is cancelled, then the value is restored to its former state.
~eventが取消されたときは、 ~eventに結付けられた条件付き`既定~動作$は，飛ばされる （あるいは，上に言及したように、 `既定~動作$が配送-前に遂げられていたなら，その効果は~~元に戻される）。 ~event~objが`取消~可能$かどうかは、 `cancelable$m 属性に指示される。 `preventDefault()$m の~callは、 ~event~objに関係するすべての`既定~動作$を 【その~eventが取消~可能ならば】 停止する。 `defaultPrevented$m 属性は、 ~eventが （例えば，先に呼ばれた`~event~listener$により） すでに取消されたかどうかを指示する。 `~DOM~app$自身が `dispatchEvent()$m ~methodで配送-を起動した場合、 その返り値は，~event~objが取消されたかどうかを指示する。 ◎ When an event is canceled, then the conditional default actions associated with the event is skipped (or as mentioned above, if the default actions are carried out before the dispatch, their effect is undone). Whether an event object is cancelable is indicated by the cancelable attribute. Calling preventDefault() stops all related default actions of an event object. The defaultPrevented attribute indicates whether an event has already been canceled (e.g., by a prior event listener). If the DOM application itself initiated the dispatch, then the return value of the dispatchEvent() method indicates whether the event object was cancelled.
注記： 多くの実装は、 `~event~listener$の返り値を上述に加えて解釈する — 値 ~F に対しては、 `取消~可能$な~eventの`既定~動作$を取消すことを意味するなど （~~例外として、 `window.onerror^m ~handlerでは， ~T を返すことにより取消されるが）。 ◎ Many implementations additionally interpret an event listener’s return value, such as the value false, to mean that the default action of cancelable events will be cancelled (though window.onerror handlers are cancelled by returning true).
3.3. 同期的／非同期的~event
~eventは、 他の~eventと同期的に配送されることもあれば, そうでない（非同期的）こともある。 ◎ Events may be dispatched either synchronously or asynchronously.
~eventのうち，同期的とされているもの（ “同期c~event” ）は、 同じ時機に生じた［ 他の~event ／ ~DOMにおける変更 ／ 利用者-ヤリトリ ］による~eventたちが成す`連列^em（ `sequence^en ）の中で互いに順序付けられた，［ FIFO（ `first-in-first-out^en ）~modelにおける，仮想の~queue ］内にあるかのように扱われる。 この~queue内の各~eventは、 前の~eventにおける伝播の挙動が［ 完了するか, 取消される ］まで遅延される。 一部の同期c~eventは、 ~mouse~button~eventなど，特定の［ 装置／処理n ］により駆動される。 この種の~eventは、 そのような~event連列に対し定義され，`~event序列$~algoにより統治される — ~UAは、 この種の~eventを定義済みな順序で配送することになる。 ◎ Events which are synchronous ("sync events") are treated as if they are in a virtual queue in a first-in-first-out model, ordered by sequence of temporal occurrence with respect to other events, to changes in the DOM, and to user interaction. Each event in this virtual queue is delayed until the previous event has completed its propagation behavior, or been canceled. Some sync events are driven by a specific device or process, such as mouse button events. These events are governed by the event order algorithms defined for that set of events, and user agents will dispatch these events in the defined order.
【 同期c／非同期c の定義は，他の~eventとの関係に基づく — 現在は非同期cとされている~eventであっても，新たな~eventが導入されたときは、 それと同期的な関係になり得ることになる。 】
非同期的な~event（ “非同期c~event” ）は、［ 他の~event ／ ~DOMにおける他の変更 ／ 利用者-ヤリトリ ］には関係なく，動作が完了した結果として発火され得る。 ◎ Events which are asynchronous ("async events") may be dispatched as the results of the action are completed, with no relation to other events, to other changes in the DOM, nor to user interaction.
~inline~script要素は、 文書の読込n中に構文解析されて実行される。 `load$et ~eventは、 その~script要素にて，非同期的に発火されるように~queueされる。 しかしながら，それは非同期c~eventなので、 文書の読込n中に発火される他の同期c~event（ `HTML5$r の `DOMContentLoaded^et など）との順序~関係は，保証されない。 ◎ During loading of a document, an inline script element is parsed and executed. The load event is queued to be fired asynchronously at the script element. However, because it is an async event, its order with relation to other synchronous events fired during document load (such as the DOMContentLoaded event from [HTML5]) is not guaranteed.
3.4. ~trusted~event
利用者-ヤリトリの結果として, あるいは ~DOMに対する変更の直接的な結果として，`~UA$により生成される~eventは、 `~UA$により~trustされ、［ ~scriptにより［ `createEvent()$m ~method【または構築子】を通して生成された ／ `initEvent()$m ~methodを利用して改変された ／ `dispatchEvent()$m ~methodを介して配送された ］~event ］には~~付与されない，特権を伴う。 `isTrusted$m 属性の値は、 ~trusted~eventに対しては ~T になり， ~trustedでない~eventに対しては ~F になる。 ◎ Events that are generated by the user agent, either as a result of user interaction, or as a direct result of changes to the DOM, are trusted by the user agent with privileges that are not afforded to events generated by script through the createEvent() method, modified using the initEvent() method, or dispatched via the dispatchEvent() method. The isTrusted attribute of trusted events has a value of true, while untrusted events have a isTrusted attribute value of false.
【 ~scriptにより間接的に~trusted~eventが発火されることはあり得る。 例えば`~pointing先$の要素が~DOM~treeから除去された場合、 その背後にある要素に向けて `mouseover$et が発火され得る — その~eventの `isTrusted^m は ~T になる。 】
`click$et ~eventを除くほとんどの~trustedでない~eventは、 `既定~動作$を誘発することはない。 `click$et ~eventは、 `isTrusted$m 属性が ~F であっても，`既定~動作$を誘発する （この挙動は、 後方-互換性を得るために維持されている）。 他のすべての~trustedでない~eventは、［ その~eventに対し `preventDefault()$m ~methodが~callされていた ］かのように挙動する。 ◎ Most untrusted events will not trigger default actions, with the exception of the click event. This event always triggers the default action, even if the isTrusted attribute is false (this behavior is retained for backward-compatibility). All other untrusted events behave as if the preventDefault() method had been called on that event.
3.5. 作動化の誘発と挙動
ある種の`~event~target$（~link要素／~button要素など）には、［ 実装が`作動化の誘発$（~linkを~clickするなど）に呼応して遂行する ］ような`作動化の挙動$（例：~linkを追う）が結付けられることもある。 ◎ Certain event targets (such as a link or button element) may have associated activation behavior (such as following a link) that implementations perform in response to an activation trigger (such as clicking a link).
~HTML, ~SVGのいずれも ~linkを指示する `a^e 要素を備えている。 `a^e 要素に関連な`作動化の誘発$には、［ `a^e 要素の内容~上での `click$et ~event ］, ［ `a^e 要素が~focusを得ている下での， `KeyboardEvent.key$m 属性~値が `Enter$kY ~UIkeyである `keydown$et ~event ］がある。 `a^e 要素~用の通常の`作動化の挙動$は、 外部~linkならば ~windowの内容を新たな文書に一新し， 内部~linkならば 現在の文書にて~link先の~anchorへ~~移動することである。 ◎ Both HTML and SVG have an <a> element which indicates a link. Relevant activation triggers for an <a> element are a click event on the text or image content of the <a> element, or a keydown event with a key attribute value of "Enter" key when the <a> element has focus. The activation behavior for an <a> element is normally to change the content of the window to the content of the new document, in the case of external links, or to reposition the current document relative to the new anchor, in the case of internal links.
`作動化の誘発$は、［ 利用者-動作, または~event ］であって，［ `作動化の挙動$が起動されるべきことを，実装に指示するもの ］である。 ◎ An activation trigger is a user action or an event which indicates to the implementation that an activation behavior should be initiated.＼
利用者により起動される`作動化の誘発$には、 作動化-可能な要素に対する次の動作が含まれる ⇒＃ その要素~上で~mouse~buttonを~clickする ／ その要素が~focusを得ている下で `Enter^cap ~UIkeyを押す ／ その要素が~focusを得ているかどうかに関わらず，何らかの方法で その要素に~linkされている~UIkey（ “~hotkey” ／ “~access-key” ）を押す ◎ User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a "hotkey" or "access key") even when that element does not have focus.＼
~eventに基づく`作動化の誘発$には、 次のものがあり得る ⇒＃ 一定~時刻に, あるいは一定~時間が経過したとき要素を作動化するような，~timerに基づく~event／ 一定の動作の完了~時に生じるような，`進捗~event$ ／ 他の 条件／状態に基づくような，多数の~event ◎ Event-based activation triggers may include timer-based events that activate an element at a certain clock time or after a certain time period has elapsed, progress events after a certain action has been completed, or many other condition-based or state-based events.
3.6. `Mouse^I ／ `Keyboard^I ~eventの構築-法
一般に、 `Event$I ~interface またはそれを継承する~interfaceの構築子が呼出されたときは， `DOM$r に述べられる手続きに従うべきであるが、 それに加え，［ `KeyboardEvent$I ／ `MouseEvent$I ］~interfaceは、［ `Event$I ~objにおける`~UIkey修飾＠#keys-modifiers$hrefの内部~状態を初期化する ］ための追加的な辞書~memberも供する。 この内部~状態は、 特定的には［ `KeyboardEvent.getModifierState()$m ／ `MouseEvent.getModifierState()$m ］~methodを用いて~queryできる。 この節では、 DOM4 による新たな `Event$I ~objを初期化する手続きに，この修飾~状態の初期化も補足する。 ◎ Generally, when a constructor of an Event interface, or of an interface inherited from the Event interface, is invoked, the steps described in [DOM] should be followed. However the KeyboardEvent and MouseEvent interfaces provide additional dictionary members for initializing the internal state of the Event object’s key modifiers: specifically, the internal state queried for using the getModifierState() and getModifierState() methods. This section supplements the DOM4 steps for intializing a new Event object with these optional modifier states.
［ `KeyboardEvent$I, `MouseEvent$I, または これらから派性する~interface ］を実装する，各~objは、 各`~UIkey修飾~名$ごとに対応する `内部~UIkey修飾~状態@ を持つ。 それは：
- `UIEvents-Key$r の`修飾~UIkeyの表t$内に述べられる `~UIkey修飾~名@ を用いて検索取得できる。
-
次に与える~algoを利用して，~objを構築する際に設定できる — DOM4 による~eventの構築-法に定義される~algoには、 次の手続きが補足される：
◎ For the purposes of constructing a KeyboardEvent, MouseEvent, or object derived from these objects using the algorithm below, all KeyboardEvent, MouseEvent, and derived objects have internal key modifier state which can be set and retrieved using the key modifier names described in the Modifier Keys table in [UIEvents-Key]. ◎ The following steps supplement the algorithm defined for constructing events in DOM4: • If the Event being constructed is a KeyboardEvent or MouseEvent object or an object that derives from either of these, and a EventModifierInit argument was provided to the constructor, then run the following sub-steps: • For each EventModifierInit argument, if the dictionary member begins with the string "modifier", then let the key modifier name be the dictionary member’s name excluding the prefix "modifier", and set the Event object’s internal key modifier state that matches the key modifier name to the corresponding value.~event~obj %~event を構築するとき，構築子に ( `EventModifierInit$I 引数 %eventInitDict ) が供された場合は、 次を走らす：
-
~EACH( `~UIkey修飾~名$ %名前 ) に対し：
- %~member名 ~LET 次を順に連結した結果 ⇒＃ `modifier^l, %名前
- ~IF［ %eventInitDict[ %~member名 ] ~NEQ ε ］ ⇒ %名前 に対応する， %~event の `内部~UIkey修飾~状態$ ~SET %eventInitDict[ %~member名 ]
-
4. 基本~event~interface
基本~event~interfaceは `DOM$r にて定義され，~UI~Eventsの基礎を成す。 実装は、 以下に挙げる基本~event~interfaceを常に~supportするモノトスル： ◎ The basic event interfaces defined in [DOM] are fundamental to UI Events. These basic event interfaces MUST always be supported by the implementation:
- `Event$I ~interface, および その［ 定数, ~method, 属性 ］のうち次に挙げるもの ⇒＃ `NONE$m `CAPTURING_PHASE$m, `AT_TARGET$m, `BUBBLING_PHASE$m, `type$m, `target$m, `currentTarget$m, `eventPhase$m, `bubbles$m, `cancelable$m, `composed$m, `timeStamp$m, `defaultPrevented$m, `isTrusted$m, `stopPropagation()$m, `stopImmediatePropagation()$m, `preventDefault()$m, `initEvent()$m ◎ The Event interface and its following constants, methods and attributes: • NONE constant • CAPTURING_PHASE constant • AT_TARGET constant • BUBBLING_PHASE constant • type attribute • target attribute • currentTarget attribute • eventPhase attribute • bubbles attribute • cancelable attribute • composed attribute • timeStamp attribute • defaultPrevented attribute • isTrusted attribute • stopPropagation() method • stopImmediatePropagation() method • preventDefault() method • initEvent() method
- `CustomEvent$I ~interface, および その ⇒＃ `initCustomEvent()$m ~method, `detail＠~DOM4#dom-customevent-detail$m 属性 ◎ The CustomEvent interface and its following method and attribute: • initCustomEvent() method • detail attribute
- `EventTarget$I ~interface, および その~methodのうち次に挙げるもの ⇒＃ `addeventlistener()$m, `removeeventlistener()$m, `dispatchEvent()$m ◎ The EventTarget interface and its following methods: • addEventListener() method • removeEventListener() method • dispatchEvent() method
- `EventListener$I ~interface, および その `handleEvent()$m ~method ◎ The EventListener interface and its handleEvent() method
- `Document$I ~interfaceの `createEvent()$m ~method ◎ The Document interface’s createEvent() method
この仕様に定義される各種~event型【用の~interface】は、 これらの基本~interfaceいずれかから派性し，そのすべての［ 属性, ~method, 定数 ］を継承するモノトスル。 ◎ The event types defined in this specification derive from these basic interfaces, and MUST inherit all of the attributes, methods, and constants of the interfaces they derive from.
この仕様に述べる各種~interfaceの継承~構造を，次の図表に述べる： ◎ The following chart describes the inheritance structure of the interfaces described in this specification.
4.1. 各種~event型の~list
各~eventには、 `~event型^emと称される，ある型が結付けられ、 ~event~obj上の `type$m 属性にて可用にするモノトスル。 ~event型は `DOMString^c 型でなければナラナイ。 ◎ Each event MUST be associated with a type, called event type and available as the type attribute on the event object. The event type MUST be of type DOMString.
実装は、［ ~DOM~supportの~level／ 表示~用に利用される装置（例： ~screen）／ 対話~用に利用される装置（例： ~mouse, ~keyboard, ~touch~screen, ~voice） ］に依存して，これらの~event型を生成し得る。 `XML$r や `HTML5$r の応用に利用されるときは、 その言語の仕様は，~event型に結付けられる意味論と視野（特に，アリな`~target$）を制約し得る／してもヨイ。 ［ それらの制約／この文書にて定義されない~event型 ］を見出すには、 利用される言語を定義している仕様を見よ。 ◎ Depending on the level of DOM support, or the devices used for display (e.g., screen) or interaction (e.g., mouse, keyboard, touch screen, or voice), these event types can be generated by the implementation. When used with an [XML] or [HTML5] application, the specifications of those languages MAY restrict the semantics and scope (in particular the possible event targets) associated with an event type. Refer to the specification defining the language used in order to find those restrictions or to find event types that are not defined in this document.
次の表tに，この仕様に述べる各種~event型の参考な要約を供する： ◎ The following table provides an informative summary of the event types described in this specification.
| ~event型 | 同期c？ | 浮上-？ | `~trusted$な~target | ~DOM~interface | 取消~可否 | `既定~動作$（空欄は動作なし） |
|---|---|---|---|---|---|---|
| `abort$et | あり | しない | `Window$I, `Element$I | `Event$I | 不可 | |
| `auxclick$et | あり | する | `Element$I | `PointerEvent$I | 可 | 文脈依存 |
| `beforeinput$et | あり | する | `Element$I | `InputEvent$I | 可 | ~DOM要素を更新する ◎ Update the DOM element |
| `blur$et | あり | しない | `Window$I, `Element$I | `FocusEvent$I | 不可 | |
| `click$et | あり | する | `Element$I | `PointerEvent$I | 可 | 文脈依存 ⇒＃ `作動化の挙動$が結付けられた`~target$に対しては，それを実行する／ ~focus可能な要素である`~target$に対しては，それを~focusする ◎ Varies: for targets with an associated activation behavior, executes the activation behavior; for focusable targets, gives the element focus. |
| `compositionstart$et | あり | する | `Element$I | `CompositionEvent$I | 可 | `~text組成~system$の候補~窓を示す ◎ Show a text composition system candidate window |
| `compositionupdate$et | あり | する | `Element$I | `CompositionEvent$I | 不可 | |
| `compositionend$et | あり | する | `Element$I | `CompositionEvent$I | 不可 | |
| `contextmenu$et | あり | する | `Element$I | `PointerEvent$I | 可 | ~supportされるなら、 文脈~menuを呼出す ◎ Invoke a context menu if supported |
| `dblclick$et | あり | する | `Element$I | `MouseEvent$I | 不可 | 文脈依存 ⇒＃ `作動化の挙動$が結付けられた`~target$に対しては，それを実行する／ ~focus可能な要素である`~target$に対しては，それを~focusする ◎ Varies: for targets with an associated activation behavior, executes the activation behavior; for focusable targets, gives the element focus. |
| `error$et | なし | しない | `Window$I, `Element$I | `Event$I | 不可 | |
| `focus$et | あり | しない | `Window$I, `Element$I | `FocusEvent$I | 不可 | |
| `focusin$et | あり | する | `Window$I, `Element$I | `FocusEvent$I | 不可 | |
| `focusout$et | あり | する | `Window$I, `Element$I | `FocusEvent$I | 不可 | |
| `input$et | あり | する | `Element$I | `InputEvent$I | 不可 | |
| `keydown$et | あり | する | `Element$I | `KeyboardEvent$I | 可 | 文脈依存 — 次に挙げるいずれかを誘発する ⇒＃ `beforeinput$et, `input$et ~event／ `~text組成~system$を立上げる／ `blur$et, `focus$et ~event／ `keypress$et ~event（~supportされるならば）／ `作動化の挙動$／ その他の~event ◎ Varies: trigger beforeinput and input events; launch text composition system; blur and focus events; keypress event (if supported); activation behavior; other events |
| `keyup$et | あり | する | `Element$I | `KeyboardEvent$I | 可 | |
| `load$et | なし | しない | `Window$I, `Document$I, `Element$I | `Event$I | 不可 | |
| `mousedown$et | あり | する | `Element$I | `MouseEvent$I | 可 | 文脈依存 — 次に挙げるいずれかを開始する ⇒＃ ~drag＆~drop操作o／ ~text選択／ ~scrollや~panによるヤリトリ （~supportされるなら，中央~mouse~buttonとの組合nで） ◎ Varies: start a drag/drop operation; start a text selection; start a scroll/pan interaction (in combination with the middle mouse button, if supported) |
| `mouseenter$et | あり | しない | `Element$I | `MouseEvent$I | 不可 | |
| `mouseleave$et | あり | しない | `Element$I | `MouseEvent$I | 不可 | |
| `mousemove$et | あり | する | `Element$I | `MouseEvent$I | `可＠#mousemove-now-cancelable$ | |
| `mouseout$et | あり | する | `Element$I | `MouseEvent$I | 可 | |
| `mouseover$et | あり | する | `Element$I | `MouseEvent$I | 可 | |
| `mouseup$et | あり | する | `Element$I | `MouseEvent$I | 可 | |
| `select$et | あり | する | `Element$I | `Event$I | 不可 | |
| `unload$et | あり | しない | `Window$I, `Document$I, `Element$I | `Event$I | 不可 | |
| `wheel$et | なし | する | `Element$I | `WheelEvent$I | 可 | 文書を~scrollする （または~zoomする） ◎ Scroll (or zoom) the document |
この仕様にて非推奨にされた~eventたちが成す~listは、 `§ 旧来の~event型＠~UIEVENTS-A#legacy-event-types$href を見よ。 ◎ For a list of events which are deprecated in this specification, see the Legacy Event Types appendix at the end of this document.
上の表tを解釈する仕方の一つは： `load$et ~eventは、［ その~event用に `Element$I ~nodeに添付された`~event~listener$ ］を［ `捕捉-相$, `~target相$ ］にて誘発することになる。 この~eventは取消~可能でない。 `load$et ~event用の`~event~listener$は、［ `Window$I, `Document$I, `Element$I ］以外の~nodeに添付されても，`浮上-相$のみに添付されても誘発されない。 ◎ The following is one way to interpret the above tables: the load event will trigger event listeners attached on Element nodes for that event and on the capture and target phases. This event is not cancelable. If an event listener for the load event is attached to a node other than Window, Document, or Element nodes, or if it is attached to the bubbling phase only, this event listener would not be triggered.
注記： 上の表tを そこに挙げられた~event型~用に確たるものとして解釈しないこと。 例えば `load$et ~eventは、 `XMLHttpRequest$I などの他の仕様にも利用される。 同様に，`~trusted$でない~eventは、 `EventTarget$I も実装するどの~objにも，それ用の~listenerへ `dispatchEvent()$m を利用して配送できる。 ◎ Don’t interpret the above tables as definitive for the listed event types. For example, the load event is used in other specifications, for example, in XMLHttpRequest. Similarly, dispatchEvent() can be used to dispatch untrusted events to listeners on any object that also implements EventTarget.
注記： 上に述べた各~event型に結付けられる~event~objは、 追加的な文脈~情報を包含する — 更なる情報は、 ~DOM~interfaceの記述を見よ。 ◎ The event objects associated with the event types described above contain additional context information--refer to the description of the DOM interfaces for further information.
~event定義~表t
【 この節は、 この訳による追加である。 】
この仕様に現れる，各種`~event型$の定義は、 次のような表tとして与えられる：
◎イ型 この欄には、 当の~event型の名前が記される （例： `click^et ）。 この名前が、 ~eventの `type$m 属性の値になる。 ◎界面 この欄には、 この型の~event~objが実装する~interfaceが示される （例： `MouseEvent^I ）。 ◎同期 この欄には、 この型の~eventが他の~eventと`同期c$して生じ得るならば “あり”／ 他の場合は “なし” と記される。 ◎浮上 この欄には、 この型の~eventが `浮上-$するならば “する” ／ 他の場合は “しない” と記される。 後者の場合、 この型の~event用の`~event~listener$が`浮上-相$に対し登録されても，誘発されないことになる。 ◎標的 この欄には、 この型の~eventの`~target$になり得る~objが挙げられる （例： `Element$I ）。 ◎取消 この欄には、 この型の~eventが`取消~可能$ならば “可” ／ 他の場合は “不可” と記される。 ◎構 `composed$m 属性に関係する — 単に［ “Yes” ／ “No” ］と記されているなら その値は［ ~T ／ ~F ］になると見受けられる — が、 実際の定義は不明 （ “Yes”, “No” の他にも とり得る値や何らかの記述があり得るかなど）。 この欄が無い~event型もあり、 その不在が何を意味するのかも不明 （ “No” を意味するのか 単に策定されていないのか判別できない）。 ◎既定動作 この欄には、 この型の~eventに結付けられ得る`既定~動作$が挙げられる （例：~pageを~scrollする）。 ◎文脈 この欄には、 この型の~eventが実装する（~interface欄に挙げられている）~interfaceの各種~memberが，どのような値に初期化されるかが述べられる。 ◎表終注意： 前節に注記されたように，この表tは、 ~scriptが作成して配送する~event （常に、 `~trusted$でない~eventになる）には，適用されない （適用されるのは、 ~UAが発火する~eventに限られる） — 一部の例外を除いて（§ `~trusted$を見よ）。
5. ~event型
~DOM~Event ~modelでは、 ~DOM実装が複数の~moduleからなる~eventを~supportすることも許容される。 ~modelは、 将来における新たな~event~moduleを追加できるように，設計されている。 この文書は、 アリな~eventすべてを定義することは試みない。 相互運用能の目的においては、 ~DOMが~UI~eventの~module（低~levelの装置~依存~eventを含む）, および 文書~変異~eventの~moduleを定義する。 ◎ The DOM Event Model allows a DOM implementation to support multiple modules of events. The model has been designed to allow addition of new event modules in the future. This document does not attempt to define all possible events. For purposes of interoperability, the DOM defines a module of user interface events including lower level device dependent events and a module of document mutation events.
【 参考： `DOM Event Viewers＠https://domeventviewer.com/$href にて、 この仕様に定義される各種~event型の挙動を試すことができる。 】
5.1. ~UI~event
~UI~event~moduleは、 ~UIや文書の操作に結付けられた，基本的な~event型を包含する。 ◎ The User Interface event module contains basic event types associated with user interfaces and document manipulation.
5.1.1. `UIEvent^I ~interface
~DOM2にて導入された。 ◎ Introduced in DOM Level 2
`UIEvent^I ~interfaceは、 ~UI~eventに特有な文脈的~情報を供する。 ◎ The UIEvent interface provides specific contextual information associated with User Interface events.
`UIEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `UIEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the UIEvent interface, use the UIEvent constructor, passing an optional UIEventInit dictionary.
注記： 新たに定義される~eventは、 単に~UIに関係するだけで， `UIEvent$I ~interfaceを継承する必要はない。 `UIEventInit$I の~memberのみ継承することでも，イミを成す。 ◎ For newly defined events, you don’t have to inherit UIEvent interface just because they are related to user interface. Inherit only when members of UIEventInit make sense to those events.
5.1.1.1. `UIEvent^I
[`Exposed$=Window]
interface `UIEvent@I : `Event$I {
`UIEvent@mc(`DOMString$ %type, optional `UIEventInit$I %eventInitDict = {});
readonly attribute `Window$I? `view$m;
readonly attribute `long$ `detail$m;
};
- `view@m ◎ UIEvent . view
- この属性は、 ~eventがどの `Window$I から生成されたかを識別する。 ◎ The view attribute identifies the Window from which the event was generated.
- `未初期化~値$： ~NULL ◎ The un-initialized value of this attribute MUST be null.
- `detail@m ◎ UIEvent . detail
- この属性には、 ~eventの型に依存して， `Event$I についての一部の詳細~情報が指定される。 ◎ Specifies some detail information about the Event, depending on the type of event.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
5.1.1.2. `UIEventInit^I
dictionary `UIEventInit@I : `EventInit$I {
`Window$I? `view$m = null;
`long$ `detail$m = 0;
};
- `view@m ◎ UIEventInit . view
- この~memberは、 この~eventの配送-先の大域~環境の~windowになるベキである。 この~eventが要素に配送されるなら、 その要素の`~node文書$を包含する~windowに設定されるベキである。 ◎ Should be initialized to the Window object of the global environment in which this event will be dispatched. If this event will be dispatched to an element, the view property should be set to the Window object containing the element’s ownerDocument.
- `detail@m ◎ UIEventInit . detail
- この値は、 ~appに特有な整数を与える。 ◎ This value is initialized to a number that is application-specific.
5.1.2. 各種~UI~event型
以下に，各種~UI~event型を挙げる。 これらの~eventのうち一部のものは、［ ~UIから生成されるときは `UIEvent$I ／ 他のときは `Event$I ］~interfaceを利用する。 詳細は各~eventに。 ◎ The User Interface event types are listed below. Some of these events use the UIEvent interface if generated from a user interface, but the Event interface otherwise, as detailed in each event.
5.1.2.1. `load^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 資源を読込んだ【！common】~obj
~UAは、［ ~DOM実装が資源（文書など）, および すべての従属~資源（画像, ~stylesheet, ~scriptなど）の読込ngを完遂した ］とき，この~eventを発火するモノトスル。 従属~資源の読込nに失敗した場合でも、 それを読込んだ資源が~DOMを介して依然として~access可能である場合には， この~eventの発火は止めないモノトスル。 実装が，この~event型を発火するときには、 少なくとも `Document$I ~node上に配送することが要求される。 ◎ A user agent MUST dispatch this event when the DOM implementation finishes loading the resource (such as the document) and any dependent resources (such as images, style sheets, or scripts). Dependent resources that fail to load MUST NOT prevent this event from firing if the resource that loaded them is still accessible via the DOM. If this event type is dispatched, implementations are REQUIRED to dispatch this event at least on the Document node.
注記： 旧来の理由から、 ~HTML実装においては［ 文書の内側の資源（例えば画像）用の `load$et ~eventの`伝播~経路$ ］は，`~window$を含まない。 詳細は `HTML5$r を見よ。 ◎ For legacy reasons, load events for resources inside the document (e.g., images) do not include the Window in the propagation path in HTML implementations. See [HTML5] for more information.
5.1.2.2. `unload^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 包含されている資源が除去された共通な~obj
~UAは、［ ~DOM実装が，環境から資源（文書など）や 従属~資源（画像, ~stylesheet, ~scriptなど）を除去した ］とき，この~eventを発火するモノトスル。 文書の~unloadは，この~event型が配送された後になるモノトスル。 実装が，この~event型を配送するときには、 少なくとも `Document$I ~node上に配送することが要求される。 ◎ A user agent MUST dispatch this event when the DOM Implementation removes from the environment the resource (such as the document) or any dependent resources (such as images, style sheets, scripts). The document MUST be unloaded after the dispatch of this event type. If this event type is dispatched, implementations are REQUIRED to dispatch this event at least on the Document node.
5.1.2.3. `abort^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 資源の読込ngが~error以外により停止された要素
~UAは、［ 資源の読込ngがまだ進捗~中に，利用者が取消したなどにより中止された ］とき，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when the loading of a resource has been aborted, such as by a user canceling the load while it is still in progress.
5.1.2.4. `error^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 資源の読込ngが~errorにより停止された要素
~UAは、［ 資源の読込nに失敗した, または読込まれたが その意味論に則って解釈-できない （妥当でない画像, ~script実行~error, 整形式でない~XMLなど） ］とき，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when a resource failed to load, or has been loaded but cannot be interpreted according to its semantics, such as an invalid image, a script execution error, or non-well-formed XML.
5.1.2.5. `select^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： ~text内容が選択された要素
~UAは、［ 利用者が一部の~textを選択した ］とき，この~eventを発火するモノトスル。 この~eventは、 選択が生じた後に配送される。 ◎ A user agent MUST dispatch this event when a user selects some text. This event is dispatched after the selection has occurred.
この仕様は、 選択された~textへ~accessするための文脈的~情報を供さない。 `~host言語$は、 適用-可能な所では，次のための規則を定義するベキである：
- 利用者が内容を選択できる方法 （国際的~言語~規約も考慮して）
- `select$et ~eventがどこで発火されたか
- 内容~作者がその選択された内容に~accessできる方法
注記： 利用者により選択された内容に~accessするためには、 内容~作者は，`~host言語$に備わる能力を利用することになる — HTML Editing APIs `Editing$r の `Document.getSelection()$m ~methodなど。 ◎ In order to access to user-selected content, content authors will use native capabilities of the host languages, such as the Document.getSelection() method of the HTML Editing APIs [Editing].
注記： `select$et ~eventは、 どの言語のどの要素でも可用になるとは限らない。 例えば `HTML5$r においては、 `select$et ~eventが配送され得るのは，［ `input$e ／ `textarea$e ］要素に限られている。 実装は、［ ~form~controlの外側の~text選択, ~SVG内などの 画像や~markupの選択 ］なども含め，適切と判断される文脈にて `select$et ~eventを配送できる。 ◎ The select event might not be available for all elements in all languages. For example, in [HTML5], select events can be dispatched only on form input and textarea elements. Implementations can dispatch select events in any context deemed appropriate, including text selections outside of form controls, or image or markup selections such as in SVG.
各種~UI~eventに共通な文脈~情報
集約簡略化多くの~UI~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：
- `UIEvent!I ：
-
- `view$m
- `Window$I ~obj ◎ UIEvent.view : Window
- `detail$m
- 0 ◎ UIEvent.detail : 0
5.2. ~focus~event
注記： この節の~interface, および それに結付けられた［ ~event型, `~focus~event序列＠#events-focusevent-event-order$href ］は、［ `User Agent Accessibility Guidelines 2.0＠~UAAG20$href `UAAG20$r に定義される概念と指針 ］に則って，特に［ `~focusの仕組み＠~UAAG20#gl-focus-mechanism$href, および `~focusの用語集＠~UAAG20#def-focus$href に定義されている用語 ］に注視して設計されている。 ◎ This interface and its associated event types and § 5.2.2 Focus Event Order were designed in accordance to the concepts and guidelines defined in User Agent Accessibility Guidelines 2.0 [UAAG20], with particular attention on the focus mechanism and the terms defined in the glossary entry for focus.
5.2.1. `FocusEvent^I ~interface
この仕様にて導入された。 ◎ Introduced in this specification
`FocusEvent^I ~interfaceは、 ~focus~eventに特有な文脈的~情報を供する。 ◎ The FocusEvent interface provides specific contextual information associated with Focus events.
`FocusEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `FocusEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the FocusEvent interface, use the FocusEvent constructor, passing an optional FocusEventInit dictionary.
5.2.1.1. `FocusEvent^I
[`Exposed$=Window]
interface `FocusEvent@I : `UIEvent$I {
`FocusEvent@mc(`DOMString$ %type, optional `FocusEventInit$I %eventInitDict = {});
readonly attribute `EventTarget$I? `relatedTarget$m;
};
- `relatedTarget@m ◎ FocusEvent . relatedTarget
- ~focus~eventに関係する，副 `EventTarget$I を識別するために利用される。 ~eventの型に依存する。 ◎ Used to identify a secondary EventTarget related to a Focus event, depending on the type of event.
- ~securityの理由から、 入子な関係にある閲覧~文脈の間で~focusが切り替わったときには【！tabbing into or out 】， この属性の値【！関連な EventTarget 】は ~NULL になるベキである。 ◎ For security reasons with nested browsing contexts, when tabbing into or out of a nested context, the relevant EventTarget SHOULD be null.
- `未初期化~値$： ~NULL ◎ The un-initialized value of this attribute MUST be null.
5.2.1.2. `FocusEventInit^I
dictionary `FocusEventInit@I : `UIEventInit$I {
`EventTarget$I? `relatedTarget@m = null;
};
この辞書の各~memberは、 `FocusEventInit!I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ FocusEventInit . relatedTarget • The relatedTarget should be initialized to the element losing focus (in the case of a focus or focusin event) or the element gaining focus (in the case of a blur or focusout event).
5.2.2. ~focus~event序列
この仕様にて定義される~focus~eventは、 相互相対順序の下で生じる。 被focus要素が無い状態から要素 %A, 要素 %B の順に~focusが移転されたときの代表的な~event連列を次に示す： ◎ The focus events defined in this specification occur in a set order relative to one another. The following is the typical sequence of events when a focus is shifted between elements (this order assumes that no element is initially focused):
| ~event型 | 備考 | |
|---|---|---|
| 利用者が~focusを移転した ◎ User shifts focus | ||
| 1. | `focus$et | %A が~focusを受取った直後に送信される ◎ Sent after first target element receives focus |
| 2. | `focusin$et | `focus$et ~eventに後続する ◎ Follows the focus event |
| 利用者が~focusを移転した ◎ User shifts focus | ||
| 3. | `blur$et | %A が~focusを失った直後に送信される ◎ Sent after first target element loses focus |
| 4. | `focusout$et | `blur$et ~eventに後続する ◎ Follows the blur event |
| 5. | `focus$et | %B が~focusを受取った直後に送信される ◎ Sent after second target element receives focus |
| 6. | `focusin$et | `focus$et ~eventに後続する ◎ Follows the focus event |
注記： この仕様は、 `focus()^m や `blur()^m などの~methodに際しての~focus~eventの挙動は定義しない。 そのような挙動については、 それらの~methodを定義している，関連な仕様を見よ。 ◎ This specification does not define the behavior of focus events when interacting with methods such as focus() or blur(). See the relevant specifications where those methods are defined for such behavior.
5.2.3. 文書~focusと~focus文脈
この~event~moduleは、 文書`~focus$の変化を通知するための~event型を含む。 この論点に関連な，3 種の別個な~focus文脈がある： ◎ This event module includes event types for notification of changes in document focus. There are three distinct focus contexts that are relevant to this discussion:
- ~OS~focus文脈 ⇒ この文脈の下では、 ~computer上で現在~稼働している多数の~appのうち一つが，~focusを持ち得るとされる。 ~browserは、 その一つを成し得る。 ◎ The operating system focus context which MAY be on one of many different applications currently running on the computer. One of these applications with focus can be a browser.
- ~app~focus文脈 ⇒ ~browserが~focusを得ているときが，この文脈である。 この文脈の下では、 利用者は、 ~browserの各種~UI~field （例： ~URL~bar, 探索~field, 等々） 間で~focusを切替えることもある （~tab~UIkeyなどにより）。 ~UItab内に示されている文書も、 これらの~UI~fieldの一つを成し得る。 ◎ When the browser has focus, the user can switch (such as with the tab key) the application focus context among the different browser user interface fields (e.g., the Web site location bar, a search field, etc.). One of these user interface fields can be the document being shown in a tab.
- 文書~focus文脈 ⇒ 文書~自身が~focusを得ているときが、 この文脈である。 この文脈の下では、 文書~内で~focus可能な要素が~focusを得ることができる。 ◎ When the document itself has focus, the document focus context can be set to any of the focusable elements in the document.
この仕様にて定義される各種~event型は、 もっぱら文書~focusのみを対象にする。 ~eventの詳細~にて識別される`~target$は、 ~window内の文書またその一部に限るモノトスル — ~focus文脈が別の文脈へ切替わったときでも，決して ~browserや~OSの一部にはならない。 ◎ The event types defined in this specification deal exclusively with document focus, and the event target identified in the event details MUST only be part of the document or documents in the window, never a part of the browser or operating system, even when switching from one focus context to another.
通常は、 文書は常に被focus要素を持ち （他に無ければ，`文書~要素$が被focus要素になる）、 また，`~focus環$を持ち続ける。 ~focus文脈が切替わっても，文書における現在の被focus要素, および文書の`~focus環$は、 通常は現在の状態を保ち続ける。 例えば，文書にて~focus可能な要素が 3 個あって， 2 個目の要素が~focusされている下で、 利用者が~OS~focusを別の~appに変更してから また~browserに戻ったとき、 2 個目の要素は，文書の中で依然として被focusのままにされ、 ~tabbingなどで~focusが切り替えられたときは， 3 個目の要素に~focusが移ることになる。
`~host言語$は、 次を定義してもヨイ：
- どの要素が~focusを受取れるか
- 要素はどの条件の下で~focusを受取るか
- ~focusはどの手段で変更できるか
- ~focusはどの順序で変化するか
例えば， 要素に~pointerが接触するだけで要素が~focusを得ることもあれば、 ~mouse~clickを要する状況下もある。 要素には、 まったく~focusされ得ないものもあれば、 特別な手段（要素~上を~clickするなど）を通してなら~focusできるが，~tabbingでは~focusできないものもある。 文書は、 複数の`~focus環$を包含してもヨイ。
他の仕様は、 この仕様にて述べるものより複階的な~focus~modelを定義してもヨイ — 複数の要素が，現在の~focusを得られるようにすることも含め。
◎ Normally, a document always has a focused element (even if it is the document element itself) and a persistent focus ring. When switching between focus contexts, the document’s currently focused element and focus ring normally remain in their current state. For example, if a document has three focusable elements, with the second element focused, when a user changes operating system focus to another application and then back to the browser, the second element will still be focused within the document, and tabbing will change the focus to the third element. A host language MAY define specific elements which might receive focus, the conditions under which an element MAY receive focus, the means by which focus MAY be changed, and the order in which the focus changes. For example, in some cases an element might be given focus by moving a pointer over it, while other circumstances might require a mouse click. Some elements might not be focusable at all, and some might be focusable only by special means (clicking on the element), but not by tabbing to it. Documents MAY contain multiple focus rings. Other specifications MAY define a more complex focus model than is described in this specification, including allowing multiple elements to have the current focus.5.2.4. 各種~focus~event型
以下に，各種~focus~event型を挙げる： ◎ The Focus event types are listed below.
5.2.4.1. `blur^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： ~focusを失った`~event~target$
- `FocusEvent.relatedTarget$m： 新たに~focusを受取っている`~event~target$。
~UAは、 要素が~focusを失った直後に， 当の要素に向けて この~eventを発火するモノトスル。 この~event型は、 `focusout$et に類似するが，浮上しない。 ◎ 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 is similar to focusout, but does not bubble.
5.2.4.2. `focus^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 新たに~focusを受取った`~event~target$
- `FocusEvent.relatedTarget$m： ~focusを失っている`~event~target$（もしあれば）。
~UAは、 要素が~focusを受取った直後に， 当の要素に向けて この~eventを発火するモノトスル。 この~event型は、 `focusin$et に類似するが，浮上しない。 ◎ 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 is similar to focusin, but does not bubble.
5.2.4.3. `focusin^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： 新たに~focusを受取った`~event~target$
- `FocusEvent.relatedTarget$m： ~focusを失っている`~event~target$（もしあれば）。
~UAは、［ 要素が~focusを受取った直後 ］かつ［ 当の要素に向けて `focus$et ~eventを配送した後 ］に，当の要素に向けて この~eventを発火するモノトスル。 この~event型は、 `focus$et に類似するが，浮上する。 ◎ A user agent MUST dispatch this event when an event target receives focus. The event target MUST be the element which received focus. The focus event MUST fire before the dispatch of this event type. This event type is similar to focus, but does bubble.
5.2.4.4. `focusout^et
次を除き，`各種~UI~eventに共通な文脈~情報$にて与えられる：
- `target$m： ~focusを失った`~event~target$
- `FocusEvent.relatedTarget$m： 新たに~focusを受取っている`~event~target$。
~UAは、［ 要素が~focusを失った直後 ］かつ［ 当の要素に向けて `blur$et ~eventを配送した後 ］に， 当の要素に向けて この~eventを発火するモノトスル。 この~event型は、 `blur$et に類似するが，浮上する。 ◎ A user agent MUST dispatch this event when an event target loses focus. The event target MUST be the element which lost focus. The blur event MUST fire before the dispatch of this event type. This event type is similar to blur, but does bubble.
5.3. ~mouse~event
~mouse~event~moduleは `HTML401$r の［ `onclick^c, `ondblclick^c, `onmousedown^c, `onmouseup^c, `onmouseover^c, `onmousemove^c, `onmouseout^c ］属性に由来する。 この~event~moduleは、 特定的には，~pointing入力~装置 （~mouseや~trackballなど） で利用するために設計されている。 ◎ The mouse event module originates from the [HTML401] onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, and onmouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball.
5.3.1. `MouseEvent^I ~interface
~DOM2にて導入され、 この仕様にて改変された。 ◎ Introduced in DOM Level 2, modified in this specification
`MouseEvent^I ~interfaceは、 `~mouse~event$に特有な文脈的~情報を供する。 ◎ The MouseEvent interface provides specific contextual information associated with Mouse events.
入子な要素に対しては、 ~mouse~eventは、 通例的には【！always】，最も深い入子な要素を~targetにすることになる。 ◎ In the case of nested elements, mouse events are always targeted at the most deeply nested element.
注記： ~targetにされた要素の先祖は、 ~event浮上を利用して，子孫~要素の中で生じた~mouse~eventの通知を得することができる。 ◎ Ancestors of the targeted element can use event bubbling to obtain notifications of mouse events which occur within their descendent elements.
`MouseEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `MouseEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the MouseEvent interface, use the MouseEvent constructor, passing an optional MouseEventInit dictionary.
注記： 実装は、 ~client座標 `clientX^c, `clientY^c を利用して，［ `initMouseEvent()$m を利用して `MouseEvent^I ~objを初期化する際 ］の他の座標 （ `~DOM0$実装や他の~proprietaryな属性 — 例えば `pageX^c など — により公開される~targetの座標） を計算できる。 ◎ When initializing MouseEvent objects using initMouseEvent, implementations can use the client coordinates clientX and clientY for calculation of other coordinates (such as target coordinates exposed by DOM Level 0 implementations or other proprietary attributes, e.g., pageX).
5.3.1.1. `MouseEvent^I
[`Exposed$=Window]
interface `MouseEvent@I : `UIEvent$I {
`MouseEvent@mc(`DOMString$ %type, optional `MouseEventInit$I %eventInitDict = {});
readonly attribute `long$ `screenX$m;
readonly attribute `long$ `screenY$m;
readonly attribute `long$ `clientX$m;
readonly attribute `long$ `clientY$m;
readonly attribute `long$ `layerX$m;
readonly attribute `long$ `layerY$m;
readonly attribute `boolean$ `ctrlKey$m;
readonly attribute `boolean$ `shiftKey$m;
readonly attribute `boolean$ `altKey$m;
readonly attribute `boolean$ `metaKey$m;
readonly attribute `short$ `button$m;
readonly attribute `unsigned short$ `buttons$m;
readonly attribute `EventTarget$I? `relatedTarget$m;
`boolean$ `getModifierState$m(`DOMString$ %keyArg);
};
- `screenX@m ◎ screenX, of type long, readonly
- ~screen座標系の原点に相対的な，~eventが生じた~~地点の横方向~座標。 ◎ The horizontal coordinate at which the event occurred relative to the origin of the screen coordinate system.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `screenY@m ◎ screenY, of type long, readonly
- 横方向を縦方向に読み替える下で， `screenX$m と同じ。 ◎ The vertical coordinate at which the event occurred relative to the origin of the screen coordinate system. ◎ The un-initialized value of this attribute MUST be 0.
- `clientX@m ◎ clientX, of type long, readonly
- ~eventに結付けられた表示域に相対的な，~eventが生じた~~地点の横方向~座標。 ◎ The horizontal coordinate at which the event occurred relative to the viewport associated with the event.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `clientY@m ◎ clientY, of type long, readonly
- 横方向を縦方向に読み替える下で， `clientX$m と同じ。 ◎ The vertical coordinate at which the event occurred relative to the viewport associated with the event. ◎ The un-initialized value of this attribute MUST be 0.
- `layerX@m ◎ layerX, of type long, readonly
-
~AND↓ を満たす要素のうち【`現在の~target$】に最も近いもの【が生成する~boxの左上隅】からの【~eventが生じた~~地点の】横方向~offset：
- 【`~box~tree$において，`現在の~target$の】`先祖$である
- `積層~文脈$を生成している【！is a】
- `有位置$である
- `積層~文脈を塗る$ときに有位置 `phase^en【？】 にて塗られる
【 該当する要素が無い場合について言及されていない （ ［ `clientX$m ／ `clientY$m ］と同じになる？）。 】
◎ The horizontal offset from the nearest ancestor element which is a stacking context, is positioned, or paints in the positioned phase when painting a stacking context. - `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `layerY@m ◎ layerY, of type long, readonly
- 横方向を縦方向に読み替える下で， `layerX$m と同じ。 ◎ The vertical offset from the nearest ancestor element which is a stacking context, is positioned, or paints in the positioned phase when painting a stacking context. ◎ The un-initialized value of this attribute MUST be 0.
- `ctrlKey@m
- `shiftKey@m
- `altKey@m
- `metaKey@m
- これらについては、 `KeyboardEvent$I の同じ名前の属性を見よ。 ◎ ctrlKey, of type boolean, readonly • Refer to the KeyboardEvent's ctrlKey attribute. • The un-initialized value of this attribute MUST be false. ◎ shiftKey, of type boolean, readonly • Refer to the KeyboardEvent's shiftKey attribute. • The un-initialized value of this attribute MUST be false. ◎ altKey, of type boolean, readonly • Refer to the KeyboardEvent's altKey attribute. • The un-initialized value of this attribute MUST be false. ◎ metaKey, of type boolean, readonly • Refer to the KeyboardEvent's metaKey attribute. • The un-initialized value of this attribute MUST be false.
- `未初期化~値$： ~F ◎ ↑
- `button@m ◎ button, of type short, readonly
- ~mouse~buttonの状態~変化による~mouse~eventに対しては、 この属性を利用して，その状態を変化させた~pointing装置の~buttonを指示するモノトスル。 ◎ During mouse events caused by the depression or release of a mouse button, button MUST be used to indicate which pointer device button changed state.
-
この属性に対する整数~値 ~IN { 0 〜 4 } は、 次を指示するモノトスル： ◎ The value of the button attribute MUST be as follows:
- 0 は、 装置の首~button （一般に、 ~UI~controlや選択~textを作動化するために利用される， 左~button, または 単-~buttonな装置の唯一の~button）, または`未初期化~値$。 ◎ 0 MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text) or the un-initialized value.
- 1 は、 予備~button （一般に，中央~button — ~mouse~wheelと組合されることが多い）。 ◎ 1 MUST indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel).
- 2 は、 副~button （一般に，右~button — 文脈~menuを表示するために利用されることが多い）。 ◎ 2 MUST indicate the secondary button (in general, the right button, often used to display a context menu).
- 3 は、 X1 （ `back^en ） ~button。 ◎ 3 MUST indicate the X1 (back) button.
- 4 は、 X2 （ `forward^en ） ~button。 ◎ 4 MUST indicate the X2 (forward) button.
- ~pointing装置には，もっと他の~button状態を供する／模造するものもあり、 そのような~buttonを表現するために，上に挙げた範囲~外の整数が利用されることもある。 ◎ Some pointing devices provide or simulate more button states, and values higher than 2 or lower than 0 MAY be used to represent such buttons.
- 注記： `button$m の値は、 ~mouse~buttonの状態~変化によるものでない~eventに対しては，更新されない。 そのような局面における値 0 は、 左~buttonではなく，`未初期化~値$として解釈すること。 ◎ The value of button is not updated for events not caused by the depression/release of a mouse button. In these scenarios, take care not to interpret the value 0 as the left button, but rather as the un-initialized value.
- 注記： `mousedown$et や `mouseup$et などの~eventに関係する`既定~動作$には、 利用-中にある特定の~mouse~buttonに依存するものもある。 ◎ Some default actions related to events such as mousedown and mouseup depend on the specific mouse button in use.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `buttons@m ◎ buttons, of type unsigned short, readonly
- ~mouse~buttonが現在どの組合nで押されているかを表出する~bitmask。 どの~mouse~eventにおいても、 それを指示するときには，この属性を利用するモノトスル。 ◎ During any mouse events, buttons MUST be used to indicate which combination of mouse buttons are currently being pressed, expressed as a bitmask.
- 注記： 似た名前の `button$m 属性がとる値とは，まったく異なる。 `button^m の値を妥当と見做せるのは， `mousedown$et ／ `mouseup$et `~event~handler$の中に限られる一方、 `buttons^m 属性は，`~trusted$な どの `MouseEvent^I ~objに対しても（それが配送されている間）~mouseの各~buttonの状態を反映する — それは、 “現在どの~buttonも作動中でない” 状態（ 0 ）も表現できるので。 ◎ Though similarly named, the values for the buttons attribute and the button attribute are very different. The value of button is assumed to be valid during mousedown / mouseup event handlers, whereas the buttons attribute reflects the state of the mouse’s buttons for any trusted MouseEvent object (while it is being dispatched), because it can represent the "no button currently active" state (0).
-
`MouseEvent.buttons$m 属性の~bitmask値［ 0 ／ 1 ／ 2 ／ 4 ］は、 次を指示するモノトスル： ◎ The value of the buttons attribute MUST be as follows:
- 0 は、 どの~buttonも現在~作動中でないこと。 ◎ 0 MUST indicate no button is currently active.
- 1 は、 装置の首~button （一般に、 ~UI~controlや選択~textを作動化するために利用される，左~button, または単-~buttonな装置の唯一の~button）。 ◎ 1 MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text).
- 2 は、 副~button （一般に，右~button — 文脈~menuを表示するために利用されることが多い）。 ◎ 2 MUST indicate the secondary button (in general, the right button, often used to display a context menu), if present.
- 4 は、 予備~button （一般に，中央~button — ~mouse~wheelと組合されることが多い）。 ◎ 4 MUST indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel).
- ~pointing装置には、 上述以外の~buttonを供する／模造するものもある — そのような~buttonを表現する値は，各~buttonごとに倍々にするモノトスル （ 8, 16, 32, ... ）。 ◎ Some pointing devices provide or simulate more buttons. To represent such buttons, the value MUST be doubled for each successive button (in the binary series 8, 16, 32, ... ).
- 注記： ~buttonたち全体が成すどの状態も，各~button値の総和で一意に表現されるので、 内容~作者は，装置~上の~mouse~buttonがいくつあっても，~bitごとの演算を利用して，現在どの~buttonが押されているかを決定できる。 例えば、 値 3 は，左＆右~buttonが押された（押されている）ことを指示し、 値 5 は，左＆中央~buttonが押されたことを指示する。 ◎ Because the sum of any set of button values is a unique number, a content author can use a bitwise operation to determine how many buttons are currently being pressed and which buttons they are, for an arbitrary number of mouse buttons on a device. For example, the value 3 indicates that the left and right button are currently both pressed, while the value 5 indicates that the left and middle button are currently both pressed.
- 注記： 【！複製】 `mousedown$et や `mouseup$et などの，一部の~eventに関係する`既定~動作$には、 どの~mouse~buttonが利用中にあるかに依存するものもある。 ◎ Some default actions related to events such as mousedown and mouseup depend on the specific mouse button in use.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `relatedTarget@m ◎ relatedTarget, of type EventTarget, readonly, nullable
- ~eventの型に依存して、 ~UI~eventに関係する副 `EventTarget$I を識別するために利用される。 ◎ Used to identify a secondary EventTarget related to a UI event, depending on the type of event.
- `未初期化~値$： ~NULL ◎ The un-initialized value of this attribute MUST be null.
- `getModifierState(keyArg)@m
- `この仕様にて導入された。^em ◎ Introduced in this specification
- `KeyboardEvent.getModifierState()$m ~methodを見よ。 ◎ Queries the state of a modifier using a key value. ◎ Returns true if it is a modifier key and the modifier is activated, false otherwise. ◎ DOMString keyArg ◎ Refer to the KeyboardEvent's getModifierState() method for a description of this parameter.
5.3.1.2. `MouseEventInit^I
dictionary `MouseEventInit@I : `EventModifierInit$I {
`long$ `screenX@m = 0;
`long$ `screenY@m = 0;
`long$ `clientX@m = 0;
`long$ `clientY@m = 0;
`short$ `button@m = 0;
`unsigned short$ `buttons@m = 0;
`EventTarget$I? `relatedTarget@m = null;
};
この辞書の各~memberは、 `MouseEvent!I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ screenX, of type long, defaulting to 0 • Initializes the screenX attribute of the MouseEvent object to the desired horizontal relative position of the mouse pointer on the user’s screen. • Initializing the event object to the given mouse position must not move the user’s mouse pointer to the initialized position. ◎ screenY, of type long, defaulting to 0 • Initializes the screenY attribute of the MouseEvent object to the desired vertical relative position of the mouse pointer on the user’s screen. • Initializing the event object to the given mouse position must not move the user’s mouse pointer to the initialized position. ◎ clientX, of type long, defaulting to 0 • Initializes the clientX attribute of the MouseEvent object to the desired horizontal position of the mouse pointer relative to the client window of the user’s browser. • Initializing the event object to the given mouse position must not move the user’s mouse pointer to the initialized position. ◎ clientY, of type long, defaulting to 0 • Initializes the clientY attribute of the MouseEvent object to the desired vertical position of the mouse pointer relative to the client window of the user’s browser. • Initializing the event object to the given mouse position must not move the user’s mouse pointer to the initialized position. ◎ button, of type short, defaulting to 0 • Initializes the button attribute of the MouseEvent object to a number representing the desired state of the button(s) of the mouse. • The value 0 is used to represent the primary mouse button, 1 is used to represent the auxiliary/middle mouse button, and 2 to represent the right mouse button. Numbers greater than 2 are also possible, but are not specified in this document. ◎ buttons, of type unsigned short, defaulting to 0 • Initializes the buttons attribute of the MouseEvent object to a number representing one or more of the button(s) of the mouse that are to be considered active. • The buttons attribute is a bit-field. If a mask value of 1 is true when applied to the value of the bit field, then the primary mouse button is down. If a mask value of 2 is true when applied to the value of the bit field, then the right mouse button is down. If a mask value of 4 is true when applied to the value of the bit field, then the auxiliary/middle button is down. • In JavaScript, to initialize the buttons attribute as if the right (2) and middle button (4) were being pressed simultaneously, the buttons value can be assigned as either: { buttons: 2 | 4 } or: { buttons: 6 } ◎ relatedTarget, of type EventTarget, nullable, defaulting to null • The relatedTarget should be initialized to the element whose bounds the mouse pointer just left (in the case of a mouseover or mouseenter event) or the element whose bounds the mouse pointer is entering (in the case of a mouseout or mouseleave or focusout event). For other events, this value need not be assigned (and will default to null).
`MouseEvent$I ~objが指示する~mouse位置がどう初期化されようが，利用者の~mouse~pointerはその位置に動かされないモノトスル。 ◎ ↑
実装は、 ~mouse~eventを生成するときには， `現在の~click回数@ を保守するモノトスル。 これは、 【同じ】~pointing装置の~buttonが，特定の時間~内に連続して~clickされた数を指示する負でない整数になるモノトスル。 どの程度の遅延で回数が~resetされるかは、 環境設定0に特有になる。 ◎ Implementations MUST maintain the current click count when generating mouse events. This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time. The delay after which the count resets is specific to the environment configuration.
【 回数が増加される~~正確な時機がいつなのか記されていないが、 `click$et ~eventが配送される直前と思われる。 】【 複数の~pointing装置があるときは、 装置ごとに~click回数を保守する？ それとも，~clickした装置が切り替わったら，~click回数は~resetされる？ 】
5.3.2. ~eventの~UIkey修飾 初期化子
`MouseEvent$I ／ `KeyboardEvent$I ~interfaceは、 各種~keyboard修飾~属性を共有し，追加的な修飾~状態を検索取得するための仕組みを~supportする。 次の辞書により、 作者は，これらの~interfaceの［ 各種~keyboard修飾~属性, および［ `MouseEvent.getModifierState()$m ／ `KeyboardEvent.getModifierState()$m ］を介して~queryされる追加的な修飾~状態 ］を初期化できるようになる。 この辞書を利用して~eventを構築する手続きは、 `§ ~event構築子＠#event-constructors$hrefにて定義される。 ◎ The MouseEvent and KeyboardEvent interfaces share a set of keyboard modifier attributes and support a mechanism for retrieving additional modifier states. The following dictionary enables authors to initialize keyboard modifier attributes of the MouseEvent and KeyboardEvent interfaces, as well as the additional modifier states queried via getModifierState(). The steps for constructing events using this dictionary are defined in the event constructors section.
dictionary `EventModifierInit@I : `UIEventInit$I {
`boolean$ `ctrlKey$m = false;
`boolean$ `shiftKey$m = false;
`boolean$ `altKey$m = false;
`boolean$ `metaKey$m = false;
`boolean$ `modifierAltGraph$m = false;
`boolean$ `modifierCapsLock$m = false;
`boolean$ `modifierFn$m = false;
`boolean$ `modifierFnLock$m = false;
`boolean$ `modifierHyper$m = false;
`boolean$ `modifierNumLock$m = false;
`boolean$ `modifierScrollLock$m = false;
`boolean$ `modifierSuper$m = false;
`boolean$ `modifierSymbol$m = false;
`boolean$ `modifierSymbolLock$m = false;
};
以下において、 %~event は［ `MouseEvent$I ／ `KeyboardEvent$I ］いずれかを実装する~event~obj， `getModifierState()^m は %~event 上の同じ名前の~method （ `MouseEvent.getModifierState()$m ／ `KeyboardEvent.getModifierState()$m ） を表すとする。
- `ctrlKey@m
- `shiftKey@m
- `altKey@m
- `metaKey@m
-
これらの各~memberは、 %~event 上の同じ名前の属性を初期化する。 値の意味は、 `KeyboardEvent$I の同じ名前の属性の記述を見よ。
加えて，実装は、 %~event の`~UIkey修飾~状態$を［ 下の表tの 2 列目の値を引数に %~event 上の `getModifierState()^m が呼出されたときは，その行の 1 列目の名前の~member値が返される ］ように初期化するモノトスル。
◎ ctrlKey, of type boolean, defaulting to false • Initializes the ctrlKey attribute of the MouseEvent or KeyboardEvent objects to true if the Control key modifier is to be considered active, false otherwise. • When true, implementations must also initialize the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Control must return true. ◎ shiftKey, of type boolean, defaulting to false • Initializes the shiftKey attribute of the MouseEvent or KeyboardEvent objects to true if the Shift key modifier is to be considered active, false otherwise. • When true, implementations must also initialize the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Shift must return true. ◎ altKey, of type boolean, defaulting to false • Initializes the altKey attribute of the MouseEvent or KeyboardEvent objects to true if the Alt (alternative) (or Option) key modifier is to be considered active, false otherwise. • When true, implementations must also initialize the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Alt must return true. ◎ metaKey, of type boolean, defaulting to false • Initializes the metaKey attribute of the MouseEvent or KeyboardEvent objects to true if the Meta key modifier is to be considered active, false otherwise. • When true, implementations must also initialize the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with either the parameter Meta must return true.名前 引数 `altKey^c `Alt^l【！^cap】 `ctrlKey^c `Control^l `altKey^c `Meta^l `shiftKey^c `Shift^l - `modifierAltGraph@m
- `modifierCapsLock@m
- `modifierFn@m
- `modifierFnLock@m
- `modifierHyper@m
- `modifierNumLock@m
- `modifierScrollLock@m
- `modifierSuper@m
- `modifierSymbol@m
- `modifierSymbolLock@m
- これらの~memberは、 %~event の`~UIkey修飾~状態$を［ 対応する`~UIkey修飾~名$ — すなわち、 ~member名を `modifierXXX^c とするときの，文字列 %XXX — を引数に %~event 上の `getModifierState()^m が呼出されたときは， その~member値が返される ］ように，初期化する。 ◎ modifierAltGraph, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter AltGraph must return true. ◎ modifierCapsLock, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter CapsLock must return true. ◎ modifierFn, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Fn must return true. ◎ modifierFnLock, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter FnLock must return true. ◎ modifierHyper, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Hyper must return true. ◎ modifierNumLock, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter NumLock must return true. ◎ modifierScrollLock, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter ScrollLock must return true. ◎ modifierSuper, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Super must return true. ◎ modifierSymbol, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter Symbol must return true. ◎ modifierSymbolLock, of type boolean, defaulting to false • Initializes the event object’s key modifier state such that calls to the getModifierState() or getModifierState() when provided with the parameter SymbolLock must return true.
5.3.3. ~mouse~event序列
この仕様にて定義される一定の~mouse~eventは、 相互相対順序の下で生じるモノトスル。 `~pointing先$が，ある要素 %A に変化したときは、 次の~event連列が生じるモノトスル： ◎ Certain mouse events defined in this specification MUST occur in a set order relative to one another. The following shows the event sequence that MUST occur when a pointing device’s cursor is moved over an element:
| ~event型 | 要素 | 備考 | |
|---|---|---|---|
| 1. | `mousemove$et | ||
| `~pointing先$は %A に変化した… ◎ Pointing device is moved into element A... | |||
| 2. | `mouseover$et | %A | |
| 3. | `mouseenter$et | %A | |
| 4. | `mousemove$et | %A | 複数回 生じ得る ◎ Multiple mousemove events |
| `~pointing先$は %A でなくなった… ◎ Pointing device is moved out of element A... | |||
| 5. | `mouseout$et | %A | |
| 6. | `mouseleave$et | %A |
`~pointing先$が要素 %A に変化して，その入子な要素 %B に変化して また %A に戻ったときは、 次の~event連列が生じるモノトスル： ◎ When a pointing device is moved into an element A, and then into a nested element B and then back out again, the following sequence of events MUST occur:
| ~event型 | 要素 | 備考 | |
|---|---|---|---|
| 1. | `mousemove$et | ||
| `~pointing先$は %A に変化した… ◎ Pointing device is moved into element A... | |||
| 2. | `mouseover$et | %A | |
| 3. | `mouseenter$et | %A | |
| 4. | `mousemove$et | %A | 複数回 生じ得る ◎ Multiple mousemove events |
| `~pointing先$は %B に変化した… ◎ Pointing device is moved into nested element B... | |||
| 5. | `mouseout$et | %A | |
| 6. | `mouseover$et | %B | |
| 7. | `mouseenter$et | %B | |
| 8. | `mousemove$et | %B | 複数回 生じ得る ◎ Multiple mousemove events |
| `~pointing先$は %B から %A に変化した… ◎ Pointing device is moved from element B into A... | |||
| 9. | `mouseout$et | %B | |
| 10. | `mouseleave$et | %B | |
| 11. | `mouseover$et | %A | |
| 12. | `mousemove$et | %A | 複数回 生じ得る ◎ Multiple mousemove events |
| `~pointing先$は %A でなくなった… ◎ Pointing device is moved out of element A... | |||
| 13. | `mouseout$et | %A | |
| 14. | `mouseleave$et | %A |
~CSSの利用により，いくつかの要素が視覚的に重合することもある。 次の例では、 3 個の要素［ %A, %B, %C ］は，いずれも ~web~page上で 同じ［ 寸法, 絶対~位置 ］にされていて、 ~DOM内では， %C は %B の子, %B は %A の子 であるとする： ◎ Sometimes elements can be visually overlapped using CSS. In the following example, three elements labeled A, B, and C all have the same dimensions and absolute position on a web page. Element C is a child of B, and B is a child of A in the DOM:
~pointing装置が、 積層された要素の外側から要素 %C 内に動いて，また外へ出たときは、 次の~event連列が生じるモノトスル： ◎ When the pointing device is moved from outside the element stack to the element labeled C and then moved out again, the following series of events MUST occur:
| ~event型 | 要素 | 備考 | |
|---|---|---|---|
| 1. | `mousemove$et | ||
| `~pointing先$は［ 積層-内の最上層の要素である要素 %C ］に変化した… ◎ Pointing device is moved into element C, the topmost element in the stack | |||
| 2. | `mouseover$et | %C | |
| 3. | `mouseenter$et | %A | |
| 4. | `mouseenter$et | %B | |
| 5. | `mouseenter$et | %C | |
| 6. | `mousemove$et | %C | 複数回 生じ得る ◎ Multiple mousemove events |
| `~pointing先$は 要素 %C でなくなった… ◎ Pointing device is moved out of element C... | |||
| 7. | `mouseout$et | %C | |
| 8. | `mouseleave$et | %C | |
| 9. | `mouseleave$et | %B | |
| 10. | `mouseleave$et | %A |
注記： `mouseover$et ／ `mouseout$et ~eventが発火されるのは， 1 度だけである一方、 `mouseenter$et ／ `mouseleave$et ~eventは，（各~要素ごとに 1 度ずつ）計 3 度~発火される。 ◎ The mouseover/mouseout events are only fired once, while mouseenter/mouseleave events are fired three times (once to each element).
【 概念的には、 一連の［ `mouseenter$et ／ `mouseleave$et ］~eventは，~pointerが［ 先祖から子孫に向かって ／ 子孫から先祖に向かって ］（微小な間をおいて）要素の境界を順々にまたいでいったと解釈した下で生じるもの， と捉えられる — ただし、 この解釈は， `MouseEvent.relatedTarget$m に関して~~正確でないが （この解釈の下では、 各~子孫に配送される `mouseenter$et ~eventの `relatedTarget^m は，各自の親を指すことになる）。 これらは、 ~eventの伝播ではないので、 例えば，［ 要素 %A に登録されている `mouseenter$et 用の~event~handler ］が，［ %B ／ %C を，その表示位置はそのままに，~DOM内での位置を変えた場合 ］の挙動は，明示的に規定されていない （この節の最後の記述も~~参照）。 】
~pointing装置に結付けられた~button （例：~mouse~buttonや~trackpad） が，要素~上で押されてから, 離されたときの，代表的な~event連列： ◎ The following is the typical sequence of events when a button associated with a pointing device (e.g., a mouse button or trackpad) is pressed and released over an element:
| ~event型 | 備考 | |
|---|---|---|
| 1. | `mousedown$et | |
| 2. | `mousemove$et | 0 回 以上生じ得る（下記~注記も見よ） ◎ OPTIONAL, multiple events, some limits |
| 3. | `mouseup$et | |
| 4. | `click$et | |
| 5. | `mousemove$et | 0 回 以上生じ得る（下記~注記も見よ） ◎ OPTIONAL, multiple events, some limits |
| 6. | `mousedown$et | |
| 7. | `mousemove$et | 0 回 以上生じ得る（下記~注記も見よ） ◎ OPTIONAL, multiple events, some limits |
| 8. | `mouseup$et | |
| 9. | `click$et | |
| 10. | `dblclick$et |
注記： 上の［ `mousedown$et と `mouseup$et ~eventの間 ］に許容される `mousemove$et ~eventを生じさせる~~移動距離や~~頻度は、［ 実装／装置／~platform ］に特有になる。 この許容誤差は、 身体的不利のある利用者 — 手の~~動きが不安定であるなど — が，~pointing装置でヤリトリするときの援助にもなり得る。 ◎ The lag time, degree, distance, and number of mousemove events allowed between the mousedown and mouseup events while still firing a click or dblclick event will be implementation-, device-, and platform-specific. This tolerance can aid users that have physical disabilities like unsteady hands when these users interact with a pointing device.
各~実装は，適切な`~hysteresis$を決定することになるが、 一般に［ 結付けられた［ `mousedown$et ~event, `mouseup$et ~event ］の~targetが同じ要素であって， `mouseout$et や `mouseleave$et ~eventは介在しない ］ときには、［ `click$et ／ `dblclick$et ］~eventを発火するベキである。 また，結付けられた［ `mousedown$et ~event, `mouseup$et ~event ］の~targetが異なるときは、 最も近い共通な`広義-先祖$に対し［ `click$et ／ `dblclick$et ］~eventを発火するベキである。 ◎ Each implementation will determine the appropriate hysteresis tolerance, but in general SHOULD fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and SHOULD fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different.
`mousedown$et ~eventが~HTML文書の `~body要素$を~targetにしていて， 対応する `mouseup$et ~eventが`根~要素$を~targetにしている場合、 最も近い共通な`広義-先祖$は`根~要素$なので， `click$et ~eventは根~要素へ配送されることになる。 ◎ If a mousedown event was targeted at an HTML document’s body element, and the corresponding mouseup event was targeted at the root element, then the click event will be dispatched to the root element, since it is the nearest common inclusive ancestor.
~mouse~event連列の最中に，`~event~target$が~DOMから除去された場合、 連列の残りの部分の~eventは，その要素には発火されないモノトスル。 ◎ If the event target (e.g. the target element) is removed from the DOM during the mouse events sequence, the remaining events of the sequence MUST NOT be fired on that element.
【 ~targetが~DOMの中で移動された場合はどうなる？ その種の位置~変化が伴われるような いかなる~DOM~~操作も，［ 要素をいったん~DOM~treeから除去してから挿入し直すものである ］と解釈するならば、 それらの要素には，~eventは配送されなくなることになるが。 】
`mousedown$et ~eventの結果，【~event~listenerにより】 ~target要素が~DOMから除去された場合、 その要素に対しては［ `mouseup$et, `click$et, `dblclick$et, ］~eventは発火されず、 これらの~eventによる既定の`作動化の挙動$も誘発されなくなる。 しかしながら， `mouseup$et ~eventは、 依然として［ ~target要素が除去された後に新たに`~pointing先$になった要素 ］に対しては発火されることになる。 同様に， `mouseup$et ~eventの配送-の最中に ~target要素が~DOMから除去された場合、 `click$et, および後続な~eventは，配送されなくなる。 ◎ If the target element is removed from the DOM as the result of a mousedown event, no events for that element will be dispatched for mouseup, click, or dblclick, nor any default activation events. However, the mouseup event will still be dispatched on the element that is exposed to the mouse after the removal of the initial target element. Similarly, if the target element is removed from the DOM during the dispatch of a mouseup event, the click and subsequent events will not be dispatched.
5.3.4. 各種~mouse~event型
以下に，各種~mouse~event型を挙げる。 入子な要素に対しては、 ~mouse~event型は，常に`~pointing先$ — 入子において最も深い要素† — を~targetにする。 ~targetにされた要素の先祖は、 ~event浮上を利用して，その子孫~要素たちの中で生じた~mouse~eventの通知を得することができる。 ◎ The Mouse event types are listed below. In the case of nested elements, mouse event types are always targeted at the most deeply nested element. Ancestors of the targeted element MAY use bubbling to obtain notification of mouse events which occur within its descendent elements.
【† `mouseenter$et, `mouseleave$et に関しては、 その限りでない。 】
5.3.4.1. `auxclick^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `UIEvent.detail$m： `現在の~click回数$を指示する — 属性~値は、 利用者がこの動作を始めたときは 1 になり，その後，各~clickごとに 1 ずつ増加するモノトスル。
- `PointerEvent$I に特有な属性については、 `pointerevents3$r 仕様を見よ。
`auxclick$et ~event型は、 利用者が非~首~pointer~buttonを［ 押してから, 離した ］とき, あるいは［ そのような動作を模造する方式で~pointerが作動化された ］ときに、 `~pointing先$が要素であるならば，それに向けて発火するモノトスル。 ~mouse~buttonがどのように作動されるかは、［ ~pointing装置, 環境設定0 ］に依存する。 例えば、 ~screen上の所在や，~buttonが押されてから離されるまでの遅延に依存することもある。 ◎ The auxclick event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the non-primary pointer button, or otherwise activates the pointer in a manner that simulates such an action. The actuation method of the mouse button depends upon the pointer device and the environment configuration, e.g., it MAY depend on the screen location or the delay between the press and release of the pointing device button.
`auxclick^et ~eventは、 非~首~pointer~button用に限り，発火されるベキである （すなわち， `MouseEvent!I の `button$m 値 ~NEQ 0 ／ `buttons$m 値 ~GT 1 ）。 `auxclick^et ~eventは、 首~button（標準的な~mouseの左~buttonなど）からは，発火されないモノトスル。 対応する，首~buttonに結付けられた~eventについては `click$et を見よ。 ◎ The auxclick event should only be fired for the non-primary pointer buttons (i.e., when button value is not 0, buttons value is greater than 1). The primary button (like the left button on a standard mouse) MUST NOT fire auxclick events. See click for a corresponding event that is associated with the primary button.
`auxclick$et ~eventに先行して，同じ要素~上に［ `mousedown$et ／ `mouseup$et ］~eventが発火される場合もある — 他の~node型（例： ~text~node）への移動は無視rして【下記 例を見よ】。 環境設定0に依存して、 `auxclick$et ~eventは、 ~pointing装置の~buttonが押されてから離されるまでの間に ~event型［ `mouseover$et, `mousemove$et, `mouseout$et ］ 1 回以上 生じた場合にも発火されてヨイ。 ◎ The auxclick event MAY be preceded by the mousedown and mouseup events on the same element, disregarding changes between other node types (e.g., text nodes). Depending upon the environment configuration, the auxclick event MAY be dispatched if one or more of the event types mouseover, mousemove, and mouseout occur between the press and release of the pointing device button.
`auxclick$et ~event型の`既定~動作$は、 文脈依存であり，［ ~eventの`~target$ ］, および［ `MouseEvent!I の `button$m ／ `buttons$m 属性の値 ］に基づく。 `auxclick$et ~event型の代表的な`既定~動作$は、 次に従う： ◎ The default action of the auxclick event type varies based on the event target of the event and the value of the button or buttons attributes. Typical default actions of the auxclick event type are as follows:
- `~target$に結付けられた`作動化の挙動$があるならば、 `既定~動作$は，その`作動化の挙動$を実行するモノトスル（`作動化の誘発と挙動$を見よ）。 ◎ If the event target has associated activation behavior, the default action MUST be to execute that activation behavior (see § 3.5 Activation triggers and behavior).
中央~buttonによる `auxclick^et を受取って取扱う例： ◎ Receiving and handling auxclick for the middle button.
%myLink.addEventListener( "auxclick", function(%e) {
if (%e.button === 1) {
/*
これは既定の挙動
— 例えば ~link上で中央~clickしたときに新たな~UItabで開くなど —
を防止することになる。
◎
This would prevent the default behavior which is for example opening a new tab when middle clicking on a link.
*/
%e.preventDefault();
/*
中央~buttonの~clickを取扱うために何か他を行う
— ~appに適した仕方で新たな~UItab内に ~linkや非~link~buttonを開くことに注力する様な。
~UItab帯~内の~UItabを閉じる様な，~click動作で行われるべき他の動作もここで行える。
◎
Do something else to handle middle button click like taking care of opening link or non-link buttons in new tabs in a way that fits the app. Other actions like closing a tab in a tab-strip which should be done on the click action can be done here too.
*/
}
});
注記： 右~buttonの事例では、 `auxclick^et ~eventは， `contextmenu$et ~eventより後に配送される。 一部の~UAは、 文脈~menuが表示されている間，すべての入力~eventを吸い取ることに注意 — そのような局面では、 `auxclick$et は~appに可用にならないであろう。 より明確には、 `次の例＠#example-auxclick-right$href を見よ。 ◎ In the case of right button, the auxclick event is dispatched after any contextmenu event. Note that some user agents swallow all input events while a context menu is being displayed, so auxclick may not be available to applications in such scenarios. See this example for more clarification.
右~buttonによる `auxclick^et を受取って取扱う例： ◎ Receiving and handling auxclick for the right button
%myDiv.addEventListener("contextmenu", function(%e) {
/*
この~callは、
~pageが~eventを受取ったときに，~pageに干渉するような文脈~menuは示されないようにする。
◎
This call makes sure no context menu is shown to interfere with page receiving the events.
*/
%e.preventDefault();
});
%myDiv.addEventListener("auxclick", function(%e) {
if (%e.button === 2) {
/*
右~button~clickを取扱うために何か他を行う
— ~appの内側に~custom化した文脈~menuを開く様な。
◎
Do something else to handle right button click like opening a customized context menu inside the app.
*/
}
});
5.3.4.2. `click^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `UIEvent.detail$m： `現在の~click回数$を指示する — 属性~値は、 利用者がこの動作を始めたときは 1 になり，その後，各~clickごとに 1 ずつ増加するモノトスル。
- `PointerEvent$I に特有な属性については、 `pointerevents3$r 仕様を見よ。
`click$et ~event型は、 利用者が首~pointer~buttonを［ 押してから, 離した ］とき, あるいは［ そのような動作を模造する方式で~pointerが作動化された ］ときに、 `~pointing先$が要素であるならば，それに向けて発火するモノトスル。 ~mouse~buttonがどのように作動されるかは、［ ~pointing装置, 環境設定0 ］に依存する。 例えば、 ~screen上の所在や，~buttonが押されてから離されるまでの遅延に依存することもある。 ◎ The click event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the primary pointer button, or otherwise activates the pointer in a manner that simulates such an action. The actuation method of the mouse button depends upon the pointer device and the environment configuration, e.g., it MAY depend on the screen location or the delay between the press and release of the pointing device button.
`click^et ~eventは、 首~pointer~button用に限り，発火されるベキである （すなわち， `MouseEvent!I の `button$m 値は 0 ／ `buttons$m 値は 1 ）。 `click^et ~eventは、 副~button （標準的な~mouseの［ 中央~button／右~button ］など） からは，発火されないモノトスル。 対応する，非~首~buttonに結付けられた~eventについては `auxclick$et を見よ。 ◎ The click event should only be fired for the primary pointer button (i.e., when button value is 0, buttons value is 1). Secondary buttons (like the middle or right button on a standard mouse) MUST NOT fire click events. See auxclick for a corresponding event that is associated with the non-primary buttons.
`click$et ~eventに先行して，同じ要素~上に［ `mousedown$et ／ `mouseup$et ］~eventが発火される場合もある — 他の~node型（例： ~text~node）への移動は無視rして【下記 例を見よ】。 環境設定0に依存して、 `click$et ~eventは、 ~pointing装置の~buttonが押されてから離されるまでの間に ~event型［ `mouseover$et, `mousemove$et, `mouseout$et ］ 1 回以上 生じた場合にも発火されてヨイ。 `click$et ~eventには `dblclick$et ~eventが~~後続してもヨイ。 ◎ The click event MAY be preceded by the mousedown and mouseup events on the same element, disregarding changes between other node types (e.g., text nodes). Depending upon the environment configuration, the click event MAY be dispatched if one or more of the event types mouseover, mousemove, and mouseout occur between the press and release of the pointing device button. The click event MAY also be followed by the dblclick event.
利用者が、 （~CSS~propにより）行高が大きくとられた `p^e 要素~内の，ある子~text~node上で~mouseを~~押下げて、 ~mouseを，その~text~node上を外れる所まで少し~~動かしてから （すなわち，~pointerは同じ~text~blockの行の合間にあるが，`~pointing先$は 依然として `p^e 要素を指している）~mouseを~~離した場合でも、 まだ同じ要素の視野にあるので，依然として `click$et ~eventを誘発するであろう （ `click$et 用の通常の時間的`~hysteresis$に~~収まるならば）。 ~UAにより生成される~mouse~eventは、 ~text~nodeに対し発火されることはないことに注意。 ◎ If a user mouses down on a text node child of a <p> element which has been styled with a large line-height, shifts the mouse slightly such that it is no longer over an area containing text but is still within the containing block of that <p> element (i.e., the pointer is between lines of the same text block, but not over the text node per se), then subsequently mouses up, this will likely still trigger a click event (if it falls within the normal temporal hysteresis for a click), since the user has stayed within the scope of the same element. Note that user-agent-generated mouse events are not dispatched on text nodes.
~event型 `click$et は、 結付けられた~pointing装置に加えて、 `作動化の誘発と挙動$にて述べたとおり， 要素に対する作動化の一環としても発火するモノトスル。 ◎ In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in § 3.5 Activation triggers and behavior.
注記： ~accessibilityを最大限に得るため、 内容~作者には，~custom~control用の`作動化の挙動$を定義する際にも `click$et ~event型を利用することが奨励される — `mousedown$et ／ `mouseup$et など、 ~pointing装置に より特有な他の~event型ではなく。 `click$et ~event型は，~pointing装置（例： ~mouse）に由来するものであるが、 後続な実装において，その結付けを超えるように拡張されており、 要素を作動化するための，装置に依存しない~event型と見なせるので。 ◎ For maximum accessibility, content authors are encouraged to use the click event type when defining activation behavior for custom controls, rather than other pointing-device event types such as mousedown or mouseup, which are more device-specific. Though the click event type has its origins in pointer devices (e.g., a mouse), subsequent implementation enhancements have extended it beyond that association, and it can be considered a device-independent event type for element activation.
`click$et ~event型の`既定~動作$は、 文脈依存であり，［ ~eventの`~target$ ］, および［ `MouseEvent!I の `button$m ／ `buttons$m 属性の値 ］に基づく。 `click$et ~event型の代表的な`既定~動作$は、 次に従う： ◎ The default action of the click event type varies based on the event target of the event and the value of the button or buttons attributes. Typical default actions of the click event type are as follows:
- `~target$に結付けられた`作動化の挙動$があるならば、 `既定~動作$は，その`作動化の挙動$を実行するモノトスル（`作動化の誘発と挙動$を見よ）。 ◎ If the event target has associated activation behavior, the default action MUST be to execute that activation behavior (see § 3.5 Activation triggers and behavior).
- `~target$が~focus可能ならば、 `既定~動作$は，その要素に文書~focusを与えるモノトスル。 ◎ If the event target is focusable, the default action MUST be to give that element document focus.
5.3.4.4. `dblclick^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `UIEvent.detail$m： `現在の~click回数$ を指示する
~UAは、［ 要素~上で~pointing装置の首~buttonが 【ある時間内に】 二回~clickされた ］とき，この~eventを発火するモノトスル。 ~double-clickの定義は、 その~targetが［ `mousedown$et ／ `mouseup$et ／ `dblclick$et ］と同じになるモノトスルことを除いて，環境設定0に依存する。 この~event型は、［ ~clickと~double-clickが同時に生じた場合は `click$et ／ 他の場合は `mouseup$et ］の後に配送するモノトスル。 ◎ A user agent MUST dispatch this event when the primary button of a pointing device is clicked twice over an element. The definition of a double click depends on the environment configuration, except that the event target MUST be the same between mousedown, mouseup, and dblclick. This event type MUST be dispatched after the event type click if a click and double click occur simultaneously, and after the event type mouseup otherwise.
`click$et ~eventと同様に， `dblclick$et ~eventが発火されるのは、 首~pointer~buttonからに限られるベキであり， 副~buttonからは発火されないモノトスル。 ◎ As with the click event, the dblclick event should only be fired for the primary pointer button. Secondary buttons MUST NOT fire dblclick events.
注記： `click$et ~eventを取消しても、 `dblclick$et ~eventが発火されるかどうかには影響しない。 ◎ Canceling the click event does not affect the firing of a dblclick event.
`click$et ~event型と同様に、 `dblclick$et ~event型の`既定~動作$は，文脈依存であり、 ~eventの`~target$および［ `MouseEvent.button$m ／ `MouseEvent.buttons$m ］属性の値に基づく。 `dblclick$et ~event型の代表的な`既定~動作$は、 `click$et ~event型のそれと合致する。 ◎ As with the click event type, the default action of the dblclick event type varies based on the event target of the event and the value of the button or buttons attributes. The typical default actions of the dblclick event type match those of the click event type.
5.3.4.5. `mousedown^et
- ~drag／~drop操作oを開始する
- ~text選択を開始する
- ~scroll／~panによるヤリトリを開始する （~supportされるなら，中央~mouse~buttonとの組合nで）
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `UIEvent.detail$m： ( `現在の~click回数$ + 1 ) を指示する。 例えば、 `mousedown$et の直前に~clickが起きていない場合の `UIEvent.detail$m 値は 1 になる。
~UAは、［ ~pointing装置の~buttonが要素~上で押された ］とき，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when a pointing device button is pressed over an element.
注記： 多くの実装が、 `mousedown$et ~eventを利用して，文脈に依存する種々の`既定~動作$を開始する。 これらの既定~動作は、 この~eventを取消すことにより，防止できる。 これらの既定~動作には、 画像や~linkに対し［ ~drag／~drop ］によるヤリトリを始めたり，~text選択を開始する, 等々がある。 加えて、 ~mouse駆動な~pan~~操作 特能を供する実装もある （ `mousedown$et ~eventの配送-時に，中央~mouse~buttonが押されていた場合に作動化されるような）。 ◎ Many implementations use the mousedown event to begin a variety of contextually dependent default actions. These default actions can be prevented if this event is canceled. Some of these default actions could include: beginning a drag/drop interaction with an image or link, starting text selection, etc. Additionally, some implementations provide a mouse-driven panning feature that is activated when the middle mouse button is pressed at the time the mousedown event is dispatched.
5.3.4.6. `mouseenter^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `target$m： 注釈文を見よ。
- `MouseEvent.button$m： 0
- `MouseEvent.relatedTarget$m： 以前の`~pointing先$。
~UAは、［ `~pointing先$が`有効に変化-$して，ある要素とその子孫たちが成す境界に入った† ］とき、 その要素に向けて，この~eventを発火するモノトスル。 この~event型は， `mouseover$et に類似するが、 浮上しないこと, および［ 以前の`~pointing先$が要素の子孫である場合、 要素に向けて発火してはナラナイ ］点で相違する。 ◎ A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements. A user agent MUST also dispatch this event when the element or one of its descendants moves to be underneath the primary pointing device. This event type is similar to mouseover, but differs in that it does not bubble, and MUST NOT be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements.
【† すなわち、 ~pointing先が変化したとき， ~AND↓ を満たす`各^em 要素に向けて発火されることになる：
- 新たな~pointing先か, または その先祖である。
- 以前の~pointing先でも, その先祖でもない。
該当する要素が複数~在る場合 （例：以前の~pointing先が ~NULL ならば、 新たな~pointing先と その先祖~要素~すべてが該当する）、 最も先祖のものから順に，この~eventを発火することになろう （この順序は、 一般な記述として明文化されてはいないが，前~節に述べた `積層された例＠#figure-mouse-event-stacked-elements$href における~mouse~event序列に基づく）。
該当する要素のうち，新たな`~pointing先$ 以外のものは、 `接触判定＠#topmost-event-target$の対象から除外されているかもしれない — そのような要素には発火しない， とするのが正しい挙動かもしれない（はっきりしない）。 】
注記： この~event型と~CSS `~hover_ps 疑似類$ `CSS2$r には、 類似性がある。 `mouseleave$et ~event型も見よ。 ◎ There are similarities between this event type and the CSS :hover pseudo-class [CSS2]. See also the mouseleave event type.
5.3.4.7. `mouseleave^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `target$m： 注釈文を見よ。
- `MouseEvent.button$m： 0
- `MouseEvent.relatedTarget$m： 新たな`~pointing先$。 【原文の記述は “以前の~pointing先” を示唆しているが、更新-時の誤りであろう。】 【！issue #307】
~UAは、［ `~pointing先$が`有効に変化-$して，ある要素とその子孫たちが成す境界から出た† ］とき、 その要素に向けて，この~eventを発火するモノトスル。 この~event型は， `mouseout$et に類似するが、 浮上しないこと, および［ 新たな`~pointing先$が要素の子孫である場合、 要素に向けて発火してはナラナイ ］点で相違する。 ◎ A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element and all of its descendent elements. A user agent MUST also dispatch this event when the element or one of its descendants moves to be no longer underneath the primary pointing device. This event type is similar to mouseout, but differs in that does not bubble, and that it MUST NOT be dispatched until the pointing device has left the boundaries of the element and the boundaries of all of its children.
【† すなわち、 ~pointing先が変化したとき， ~AND↓ を満たす`各^em 要素に向けて発火されることになる：
- 以前の~pointing先か, または その先祖である。
- 新たな~pointing先でも, その先祖でもない。
該当する要素が複数~在る場合 （例：新たな~pointing先が ~NULL ならば、 以前の~pointing先と その先祖~要素~すべてが該当する）、 最も子孫のものから順に （ `mouseenter$et のときとは逆順に）， この~eventを発火することになろう。 】
注記： この~event型と~CSS `~hover_ps 疑似類$ `CSS2$r には、 類似性がある。 `mouseenter$et ~event型も見よ。 ◎ There are similarities between this event type and the CSS :hover pseudo-class [CSS2]. See also the mouseenter event type.
5.3.4.8. `mousemove^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `MouseEvent.button$m： 0
~UAは、［ `~pointing先$が要素~上で動いた ］とき，その要素に向けて，この~eventを発火するモノトスル。 ~pointing装置が動かされる間に~eventが生じる頻度0は［ 実装／装置／~platform ］に特有であるが、 ~~持続的な動きに対しては，動きが止まる度にではなく，複数の `mousemove$et ~eventが連続して発火されるベキである。 実装には、 即応性と処理能との兼ね合いをとる最適な頻度0を決定することが奨励される。 ◎ A user agent MUST dispatch this event when a pointing device is moved while it is over an element. The frequency rate of events while the pointing device is moved is implementation-, device-, and platform-specific, but multiple consecutive mousemove events SHOULD be fired for sustained pointer-device movement, rather than a single event for each instance of mouse movement. Implementations are encouraged to determine the optimal frequency rate to balance responsiveness with performance.
注記： ~browserなどの一部の実装~環境においては、 `mousemove$et~eventは，利用者が（~mouse~buttonを押すなどして）~drag操作oを始めてから ~pointing装置が~UAの境界を離れた後も，発火し続け得る。 ◎ In some implementation environments, such as a browser, mousemove events can continue to fire if the user began a drag operation (e.g., a mouse button is pressed) and the pointing device has left the boundary of the user agent.
注記： この~eventは、 以前は DOM Level 2 Events において`取消~可能$でないと指定されていたが， 既存の~UA間の相互運用能を反映するよう変更された。 ◎ This event was formerly specified to be non-cancelable in DOM Level 2 Events, but was changed to reflect existing interoperability between user agents.
5.3.4.9. `mouseout^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `target$m： 以前の`~pointing先$。
- `MouseEvent.button$m： 0
- `MouseEvent.relatedTarget$m： 新たな`~pointing先$。
~UAは、 `~pointing先$が`有効に変化-$したとき，以前の`~pointing先$が要素であるならば、 この~eventをその要素に向けて発火するモノトスル。 この~event型は， `mouseleave$et に類似するが、 浮上すること, および［ 新たな`~pointing先$が要素の子孫であっても、 要素に向けて発火するモノトスル ］点で相違する。 ◎ A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element or when the element is moved to be no longer underneath the primary pointing device. This event type is similar to mouseleave, but differs in that does bubble, and that it MUST be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements.
注記： `mouseover$et ~event型も見よ。 ◎ See also the mouseover event type.
5.3.4.10. `mouseover^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `MouseEvent.button$m： 0
- `MouseEvent.relatedTarget$m： 以前の`~pointing先$。 【原文の記述は “新たな~pointing先” を示唆しているが、更新-時の誤りであろう。】 【！issue #307】
~UAは、 `~pointing先$が`有効に変化-$したとき，新たな`~pointing先$が要素であるならば、 この~eventをその要素に向けて発火するモノトスル。 この~event型は， `mouseenter$et に類似するが、 浮上すること, および［ 以前の`~pointing先$が要素の子孫であっても、 要素に向けて発火するモノトスル ］点で相違する。 ◎ A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or when the element is moved to be underneath the primary pointing device. This event type is similar to mouseenter, but differs in that it bubbles, and that it MUST be dispatched when the pointer device moves onto the boundaries of an element whose ancestor element is the event target for the same event listener instance.
注記： `mouseout$et ~event型も見よ。 ◎ See also the mouseout event type.
5.3.4.11. `mouseup^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `UIEvent.detail$m： ( `現在の~click回数$ + 1 ) を指示する。
~UAは、［ ~pointing装置の~buttonが要素~上で離された ］とき，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when a pointing device button is released over an element.
注記： ~browserなど，実装~環境によっては、 `mouseup$et ~eventは，~pointing装置が~UAの境界から出たときにも発火され得る。 例： 利用者が~mouse~buttonを押して~drag操作oを始めたときなど。 ◎ In some implementation environments, such as a browser, a mouseup event can be dispatched even if the pointing device has left the boundary of the user agent, e.g., if the user began a drag operation with a mouse button pressed.
各種~mouse~eventに共通な文脈~情報
集約簡略化多くの~mouse~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：
- `target$m
- `~pointing先$ ◎ Event.target : topmost event target
- `UIEvent!I の各~属性：
- `各種~UI~eventに共通な文脈~情報$にて与えられる。
- `MouseEvent!I ：
-
- `screenX$m
- ~screen上の~pointer位置に基づく値 ◎ MouseEvent.screenX : value based on the pointer position on the screen
- `screenY$m
- ~screen上の~pointer位置に基づく値 ◎ MouseEvent.screenY : value based on the pointer position on the screen
- `clientX$m
- 表示域の中の~pointer位置に基づく値 ◎ MouseEvent.clientX : value based on the pointer position within the viewport
- `clientY$m
- 表示域の中の~pointer位置に基づく値 ◎ MouseEvent.clientY : value based on the pointer position within the viewport
- `layerX$m
- 包含している要素の中の~pointer位置に基づく値 ◎ MouseEvent.layerX : value based on the pointer position within the containing element
- `layerY$m
- 包含している要素の中の~pointer位置に基づく値 ◎ MouseEvent.layerY : value based on the pointer position within the containing element
- `altKey$m
- `Alt^cap 修飾が作動中であったなら ~T， ~ELSE_ ~F ◎ MouseEvent.altKey : true if Alt modifier was active, otherwise false
- `ctrlKey$m
- `Control^cap 修飾が作動中であったなら ~T， ~ELSE_ ~F ◎ MouseEvent.ctrlKey : true if Control modifier was active, otherwise false
- `shiftKey$m
- `Shift^cap 修飾が作動中であったなら ~T， ~ELSE_ ~F ◎ MouseEvent.shiftKey : true if Shift modifier was active, otherwise false
- `metaKey$m
- `Meta^cap 修飾が作動中であったなら ~T， ~ELSE_ ~F ◎ MouseEvent.metaKey : true if Meta modifier was active, otherwise false
- `button$m
- 現在 押されている~buttonに基づく値。 ◎ MouseEvent.button : value based on current button pressed
- `buttons$m
- 現在の押下げられているすべての~buttonに基づく値。 押された~buttonが無ければ 0 になる。 ◎ MouseEvent.buttons : value based on all buttons currently depressed, 0 if no buttons pressed
- `relatedTarget$m
- ~NULL ◎ MouseEvent.relatedTarget : null
5.4. ~wheel~event
~wheelは、 1 つ以上の空間的~次元にて回転できる装置であり， ~pointing装置に結付けられ得る。 座標系は環境設定0に依存する。 ◎ Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The coordinate system depends on the environment configuration.
利用者の環境は、［ 横~scroll／縦~scroll／~zoom ］を［ x-軸／y-軸／z-軸 ］に沿う回転に結付けるように環境設定され得る。 ◎ The user’s environment might be configured to associate vertical scrolling with rotation along the y-axis, horizontal scrolling with rotation along the x-axis, and zooming with rotation along the z-axis.
`WheelEvent!I ~objの［ `deltaX$m ／ `deltaY$m ／ `deltaZ$m ］属性は、 それぞれの軸に沿う，いずれかの`測定~単位$による測定を指示する。 報告される測定は、［ 環境に特有な~algoが，~wheel装置の実際の 回転や動き を適切な 値＆単位 に翻訳した後 ］に供される。 ◎ The deltaX, deltaY, and deltaZ attributes of WheelEvent objects indicate a measurement along their respective axes in units of pixels, lines, or pages. The reported measurements are provided after an environment-specific algorithm translates the actual rotation/movement of the wheel device into the appropriate values and units.
【定義追加：】 `測定~単位@ とは、 画素~数, 行~数, ~page数の総称である。
原文には、 これらが何の計量に基づくかは，定義されていない。 次の定義が考えられるが：
- 画素~数は、 ~CSS `px^css 単位 （機器~画素~単位ではなく）。
- 行数は、 `根~要素$の~CSS `line-height^p ~propに基づく。
- ~page数は、 よくある~computer~screenの下では，~CSS表示域（ `viewport^en ）の寸法に基づく。
注記： 利用者は、 ~wheel装置の実際の 回転／動き を異なる仕方で解釈させるよう環境設定1を~custom化し得る。 ［ 共通的な “dented” 【？】 ~mouse~wheelの一回の動き ］は、 何~画素か（実際の値は ~UAの現在の~screen寸法に依存する）に測定されるが、 利用者は、 自身の環境設定1を変更して この数を増大させ，~mouse~wheelを高速化することもある。 更には， ~mouse~wheel~softwareには、 加速機能 （~wheelを高速に回転させる／動かす程，各~測定の`~delta$が大きくなる） を~supportするものや， 1 画素~単位より精細に`回転$を測定するものもある。 よって作者は、［ ある~UAにおける`回転$量が，他の~UAにおいても同じ`~delta$値を生産する ］と見做すことはできない。 ◎ A user’s environment settings can be customized to interpret actual rotation/movement of a wheel device in different ways. One movement of a common "dented" mouse wheel can produce a measurement of 162 pixels (162 is just an example value, actual values can depend on the current screen dimensions of the user-agent). But a user can change their default environment settings to speed-up their mouse wheel, increasing this number. Furthermore, some mouse wheel software can support acceleration (the faster the wheel is rotated/moved, the greater the delta of each measurement) or even sub-pixel rotation measurements. Because of this, authors can not assume a given rotation amount in one user agent will produce the same delta value in all user agents.
［ `deltaX^m ／ `deltaY^m ／ `deltaZ^m ］属性~値の正負は、 実際の~wheel装置が同じ方向に［ 回転する間, 動く間 ］は， `wheel$et ~eventの複数の発火において一貫するモノトスル。 ~UAは、［ `wheel$et ~eventの既定~動作として~scrollする場合 ］の`~delta$の符号を `右手~座標系@ で — すなわち，［ X／Y／Z ］軸の正な方向が，`文書$の［ 右方／下方／奥方（利用者から遠ざかる） ］を向くように — 与えるベキである。 ◎ The sign (positive or negative) of the values of the deltaX, deltaY, and deltaZ attributes MUST be consistent between multiple dispatches of the wheel event while the motion of the actual wheel device is rotating/moving in the same direction. If a user agent scrolls as the default action of the wheel event then the sign of the delta SHOULD be given by a right-hand coordinate system where positive X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively.
注記： ~wheelの物理的な操作oに対する解釈は、 個々の~UAに応じて （あるいは~UAや~hardwareの環境設定に依存して） 異なることもある。 例えば，~trackpadの淵で上から下へ~swipeされたとき、 下への~page~scrollを意図する~wheel動作として解釈されることもあれば， その逆に解釈されることもある （すなわち， `deltaY^m 値は、 前者が正に, 後者が負に）。 ◎ Individual user agents can (depending on their environment and hardware configuration) interpret the same physical user interaction on the wheel differently. For example, a vertical swipe on the edge of a trackpad from top to bottom can be interpreted as a wheel action intended to either scroll the page down or to pan the page up (i.e., resulting in either a positive or negative deltaY value respectively).
`~wheel~event~transaction@ とは、 ある単独の利用者~gestureに結付けられる【から生じる】一連の~wheel~eventである。 `~UA$は、 それらのうち最初の~wheel~eventが発火されたとき，［ 実装に特有な時間 【言い換えれば、単独の~gestureが成し得る最大な時間】 内で生じる後続な~wheel~eventすべて ］が同じ要素を~targetにできるよう， `~wheel~event~transaction$を作成するモノトスル。 各`~wheel~event~transaction$には、 それを成す最初の~wheel~eventが生じた時点における`最上層の~event~target$が結付けられるモノトスル。 ◎ A user agent MUST create a wheel event transaction when the first wheel event is fired, so that all subsequent wheel events within a implementation-specific amount of time can be targetted at the same element. A wheel event transaction is series of wheel events that are associated with a single user gesture. The wheel event transaction MUST have an associated event target that is the topmost event target at the time the first wheel event occurs in the group.
ある~scroll可能な要素~内のどこかを~targetにする一連の~wheel~eventが， ある子~要素から開始された場合、 当の子~要素が，同じ利用者~gesture用の後続な~eventが生じ得る要素になる。 ◎ If a series of wheel events targetted in a scrollable element start above a child element, later events for the same user gesture may occur over the child element.
5.4.1. `WheelEvent^I ~interface
この仕様にて導入された。 ◎ Introduced in this specification
`WheelEvent^I ~interfaceは、 `wheel$et ~eventに特有な文脈的~情報を供する。 ◎ The WheelEvent interface provides specific contextual information associated with wheel events.
`WheelEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `WheelEventInit$I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the WheelEvent interface, use the WheelEvent constructor, passing an optional WheelEventInit dictionary.
5.4.1.1. `WheelEvent^I
[`Exposed$=Window]
interface `WheelEvent@I : `MouseEvent$I {
`WheelEvent@mc(`DOMString$ %type, optional `WheelEventInit$I %eventInitDict = {});
// `deltaMode^m 値がとり得る定数
const `unsigned long$ `DOM_DELTA_PIXEL$m = 0x00;
const `unsigned long$ `DOM_DELTA_LINE$m = 0x01;
const `unsigned long$ `DOM_DELTA_PAGE$m = 0x02;
readonly attribute `double$ `deltaX$m;
readonly attribute `double$ `deltaY$m;
readonly attribute `double$ `deltaZ$m;
readonly attribute `unsigned long$ `deltaMode$m;
};
- `DOM_DELTA_PIXEL@m
- `deltaMode$m 属性がこの値をとる場合、 `~delta$用の`測定~単位$は，画素~数になるモノトスル。 これは、 ほとんどの~OSや実装の環境設定における，最も代表的な事例である。 ◎ The units of measurement for the delta MUST be pixels. This is the most typical case in most operating system and implementation configurations.
- `DOM_DELTA_LINE@m
- `deltaMode$m 属性がこの値をとる場合、 `~delta$用の`測定~単位$は，~textの行~数になるモノトスル。 これは，多くの~form~controlに該当する。 ◎ The units of measurement for the delta MUST be individual lines of text. This is the case for many form controls.
- `DOM_DELTA_PAGE@m
- `deltaMode$m 属性がこの値をとる場合、 `~delta$用の`測定~単位$は，［ 単独の~screen, または ~page~~区分 ］に基いて定義される~page数になるモノトスル。 ◎ The units of measurement for the delta MUST be pages, either defined as a single screen or as a demarcated page.
- `deltaX@m
- `deltaY@m
- `deltaZ@m
- `wheel$et ~eventの既定~動作が~scrollである~UAでは、 ~eventが取消されなかった場合の値は，当該の軸に沿って~scrollされることになる（いずれかの`測定~単位$による）測定になるモノトスル。 他の場合、 これは［ 当該の軸~廻りの~wheel装置の動き ］の実装に特有な（いずれかの`測定~単位$による）測定。 ◎ deltaX, of type double, readonly • In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the x-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the x-axis. • The un-initialized value of this attribute MUST be 0.0. ◎ deltaY, of type double, readonly • In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the y-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the y-axis. • The un-initialized value of this attribute MUST be 0.0. ◎ deltaZ, of type double, readonly • In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the z-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the z-axis. • The un-initialized value of this attribute MUST be 0.0.
- `未初期化~値$： 0.0 ◎ ↑
- `deltaMode@m ◎ deltaMode, of type unsigned long, readonly
- `deltaMode^m 属性~値は、 `~delta$値~用の`測定~単位$を指示する。 既定~値は `DOM_DELTA_PIXEL$m （画素~数）。 ◎ The deltaMode attribute contains an indication of the units of measurement for the delta values. The default value is DOM_DELTA_PIXEL (pixels).
- この属性は、［ `~delta$値~用の`測定~単位$を指示する，いずれかの `DOM_DELTA_…^m 定数 ］に設定するモノトスル。 精確な測定は，［ 装置／~OS／~app ］の環境設定に特有になる。 ◎ This attribute MUST be set to one of the DOM_DELTA constants to indicate the units of measurement for the delta values. The precise measurement is specific to device, operating system, and application configurations.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
5.4.1.2. `WheelEventInit^I
dictionary `WheelEventInit@I : `MouseEventInit$I {
`double$ `deltaX@m = 0.0;
`double$ `deltaY@m = 0.0;
`double$ `deltaZ@m = 0.0;
`unsigned long$ `deltaMode@m = 0;
};
この辞書の各~memberは、 `WheelEvent$I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ deltaX, of type double, defaulting to 0.0 • See deltaZ attribute. ◎ deltaY, of type double, defaulting to 0.0 • See deltaZ attribute. ◎ deltaZ, of type double, defaulting to 0.0 • Initializes the deltaZ attribute of the WheelEvent object. Relative positive values for this attribute (as well as the deltaX and deltaY attributes) are given by a right-hand coordinate system where the X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively. Negative relative values are in the respective opposite directions. ◎ deltaMode, of type unsigned long, defaulting to 0 • Initializes the deltaMode attribute on the WheelEvent object to the enumerated values 0, 1, or 2, which represent the amount of pixels scrolled (DOM_DELTA_PIXEL), lines scrolled (DOM_DELTA_LINE), or pages scrolled (DOM_DELTA_PAGE) if the rotation of the wheel would have resulted in scrolling.
5.4.2. 各種~wheel~event型
5.4.2.1. `wheel^et
次を除き，`各種~mouse~eventに共通な文脈~情報$にて与えられる：
- `target$m： 現在の`~wheel~event~transaction$用の~target
-
~wheelが~pointing装置に結付けられていない場合、 `MouseEvent!I の：
- 次に挙げる属性は 0 【すなわち，`未初期化~値$】になる ⇒＃ `screenX$m, `screenY$m, `clientX$m, `clientY$m, `button$m, `buttons$m
- 【 `layerX$m, `layerY$m も，前項と同様になると思われるが、 原文には言及されていない。 】
- 【 `relatedTarget$m は， ~NULL （`未初期化~値$）になると思われるが、 原文には言及されていない。 】
- `WheelEvent!I の［ `deltaX$m ／ `deltaY$m ／ `deltaZ$m ］は、［ X ／ Y ／ Z ］軸~廻りの~wheel装置の動きを~~反映する量であって、［ ~pageが `deltaMode$m 単位に従って，その軸に沿って~scrollする量 ］であるか，または実装に特有な値。
- `WheelEvent.deltaMode$m は、［ `deltaX$m ／ `deltaY$m ／ `deltaZ$m ］属性~用の，（いずれかの`測定~単位$を表現する）単位~指示子。
~UAは、 ~mouse~wheelが いずれかの軸で回転されたとき — あるいは、 等価な入力~装置 （~mouse-ballや, 一部の~tabletや~touchpad, 等々） が そのような動作を模倣したとき — この~eventを発火するモノトスル。 同時に複数の軸が回転された場合の~wheel`~delta$は、 ~platformや入力~装置に依存して，［ 単独の `wheel$et ~eventにまとめて, あるいは 軸ごとに別々な `wheel$et ~eventとして ］送達されることもある。 ◎ A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action. Depending on the platform and input device, diagonal wheel deltas MAY be delivered either as a single wheel event with multiple non-zero axes or as separate wheel events for each non-zero axis.
`wheel$et ~event型の代表的な`既定~動作$は、 指示された量だけ文書を~scrollする （あるいは一部の事例では，~zoomする）。 この~eventが取消された場合、 実装は，文書を［ ~scroll／~zoom ］しないモノトスル （あるいは，何であれ、 この~event型に結付けられた他の実装に特有な既定~動作も）。 ◎ The typical default action of the wheel event type is to scroll (or in some cases, zoom) the document by the indicated amount. If this event is canceled, the implementation MUST NOT scroll or zoom the document (or perform whatever other implementation-specific default action is associated with this event type).
注記： ~UA や入力~装置によっては、 ~wheelが回される速度も`~delta$値に影響し得る — 高速になる程 高い`~delta$値を生産するように。 ◎ In some user agents, or with some input devices, the speed that the wheel has been turned can affect the delta values, with a faster speed producing a higher delta value.
5.4.2.2. `wheel^et ~eventの取消~可否
`wheel$et ~eventに対し `preventDefault()$m を~callした場合、 ~scrollingを［ 防止-／中断- ］し得る。 ~UAは，~scroll処理能を最大にするためとして、 ~scrollに結付けられた `wheel^et ~event連列を成す各~eventに対し，それが — 取消されたかどうか見るために — 処理されるまで待機しなくてもヨイ。 そのような事例では、 ~UAは，生成する `wheel^et ~eventの `cancelable$m を ~F にするべきである — これは、 `preventDefault()$m を利用しても，~scrollingを［ 防止-／中断- ］し得ないことを指示する。 他の場合、 `cancelable$m は ~T になる。 ◎ Calling preventDefault on a wheel event can prevent or otherwise interrupt scrolling. For maximum scroll performance, a user agent may not wait for each wheel event associated with the scroll to be processed to see if it will be canceled. In such cases the user agent should generate wheel events whose cancelable property is false, indicating that preventDefault cannot be used to prevent or interrupt scrolling. Otherwise cancelable will be true.
特に，~UAは、 ~event用の`受動的でない~listenerは無いことを観測した＠~DOM4#observing-event-listeners$ならば， 生成するどの `wheel$et ~eventも取消~不能にする【 `cancelable^m を ~F にする】ベキである。 ◎ In particular, a user agent should generate only uncancelable wheel events when it observes that there are no non-passive listeners for the event.
5.5. 入力~event型
入力~eventは、 利用者-動作の直接的な結果として （例：編集-可能な領域~内での~keyboard入力や, 整形-中にある~textを削除したとき, 等々） ~DOMが更新された（または，されつつある）とき，通知として送信される。 ◎ Input events are sent as notifications whenever the DOM is being updated (or about to be updated) as a direct result of a user action (e.g., keyboard input in an editable region, deleting or formatting text, ...).
5.5.1. `InputEvent^I ~interface
DOM3 にて導入された。 ◎ Introduced in DOM Level 3
5.5.1.1. `InputEvent^I
[`Exposed$=Window]
interface `InputEvent@I : `UIEvent$I {
`InputEvent@mc(`DOMString$ %type, optional `InputEventInit$I %eventInitDict = {});
readonly attribute `USVString$? `data$m;
readonly attribute `boolean$ `isComposing$m;
readonly attribute `DOMString$ `inputType$m;
};
- `data@m ◎ data, of type USVString, readonly, nullable
- ~IMEにより生成される~Unicode文字 `Unicode$r 並びの値を保持する — `空~文字列$にもなり得る。 一連の文字は、 `UAX15$r にて定義される~Unicode正規化~形 `NFC^em による定義に従って正規化されるベキである。 ◎ data holds the value of the characters generated by an input method. This MAY be a single Unicode character or a non-empty sequence of Unicode characters [Unicode]. Characters SHOULD be normalized as defined by the Unicode normalization form NFC, defined in [UAX15]. This attribute MAY contain the empty string.
- `未初期化~値$： ~NULL ◎ The un-initialized value of this attribute MUST be null.
- `isComposing@m ◎ isComposing, of type boolean, readonly
- 入力~eventが組成~sessionの一部として — すなわち， `compositionstart$et ~eventの後, かつ 対応する `compositionend$et ~eventの前に — 生じたならば~T。 ◎ true if the input event occurs as part of a composition session, i.e., after a compositionstart event and before the corresponding compositionend event.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `inputType@m ◎ inputType, of type DOMString, readonly
- ~eventに結付けられた［ 入力の型 ］を識別する文字列を包含する。 ◎ inputType contains a string that identifies the type of input associated with the event.
- この属性に妥当な値たちが成す~listは `Input-Events$r を見よ。 ◎ For a list of valid values for this attribute, refer to the [Input-Events] specification.
- `未初期化~値$： 空~文字列 ◎ The un-initialized value of this attribute MUST be the empty string "".
5.5.1.2. `InputEventInit^I
dictionary `InputEventInit@I : `UIEventInit$I {
`DOMString$? `data@m = null;
`boolean$ `isComposing@m = false;
`DOMString$ `inputType@m = "";
};
この辞書の各~memberは、 `InputEvent$I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ data, of type DOMString, nullable, defaulting to null • Initializes the data attribute of the InputEvent object. ◎ isComposing, of type boolean, defaulting to false • Initializes the isComposing attribute of the InputEvent object. ◎ inputType, of type DOMString, defaulting to "" • Initializes the inputType attribute of the InputEvent object.
5.5.2. 入力~event序列
この仕様にて定義される入力~eventは、 相互相対順序の下で生じるモノトスル。 ◎ The input events defined in this specification MUST occur in a set order relative to one another.
| ~event型 | 備考 | |
|---|---|---|
| 1. | `beforeinput$et | |
| DOM 要素は更新された ◎ DOM element is updated | ||
| 2. | `input$et |
5.5.3. 各種~入力~event型
◎ The Input event types are listed below.
5.5.3.1. `beforeinput^et
次を除き，`各種~入力~eventに共通な文脈~情報$にて与えられる：
- `InputEvent.data$m は、 内容が削除されることになる場合は， ~NULL にされてもヨイ。
~UAは、 ~DOMが更新されつつあるとき，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event when the DOM is about to be updated.
5.5.3.2. `input^et
次を除き，`各種~入力~eventに共通な文脈~情報$にて与えられる：
- `InputEvent.data$m は、 内容が削除された場合には，`空~文字列$にされてもヨイ。
~UAは、 ~DOMが更新された直後に，この~eventを発火するモノトスル。 ◎ A user agent MUST dispatch this event immediately after the DOM has been updated.
各種~入力~eventに共通な文脈~情報
集約簡略化各種~入力~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：
- `target$m
- 更新されつつある／された`~event~target$。 ◎ event target that [ is about to be / was just ] updated
- `UIEvent!I の各~属性：
- `各種~UI~eventに共通な文脈~情報$にて与えられる。
- `InputEvent!I ：
-
- `data$m
- 要素に追加された／されることになる~dataを包含する文字列。 内容が削除されることになる／された場合には、 ~eventの型に応じて，`空~文字列$または~NULLにされてもヨイ。 ◎ InputEvent.data : the string containing the data that [ has been | will be ] added to the element, which MAY be [ the empty string | null ] if the content [ will be | has been ] deleted
- `isComposing$m
- この~eventが`~dead-key＠#keys-dead$href連列, または `~IME$が作動中な間に配送されたものであれば ~T （`組成~event$が配送されているときなど） ／ ~ELSE_ ~F ◎ InputEvent.isComposing : true if this event is dispatched during a dead key sequence or while an input method editor is active (such that composition events are being dispatched); false otherwise.
5.6. ~keyboard~event型
~keyboard~eventは、 装置~依存である — すなわち，それは、［ 入力~装置の能力, および 【物理的な~UIkeyが】 ~OSにてどう~mapされているか ］に依拠する。 詳細は、 ~keyboard~eventと`組成~event$とを組合せる用例も含め， `§ ~keyboard~eventと~UIkey値$に。 文字~生成~装置によっては，~keyboard~eventを生成しないものもある。 ◎ Keyboard events are device dependent, i.e., they rely on the capabilities of the input devices and how they are mapped in the operating systems. Refer to Keyboard events and key values for more details, including examples on how Keyboard Events are used in combination with Composition Events. Depending on the character generation device, keyboard events might not be generated.
注記： ~keyboard~eventは、 ~textな入力を供する~~方式（ `modality^en ）の一つにすぎない。 編集~時には、 ~keyboard~eventを代替するもの（または それへの追加）として， `InputEvent$I の利用も考慮すること。 ◎ Keyboard events are only one modality of providing textual input. For editing scenarios, consider also using the InputEvent as an alternate to (or in addition to) keyboard events.
【 参考： `Keyboard Event Viewer＠https://w3c.github.io/uievents/tools/key-event-viewer.html$href にて、 各種~keyboard~eventの挙動を試すことができる。 】
5.6.1. `KeyboardEvent^I ~interface
この仕様にて導入された。 ◎ Introduced in this specification
`KeyboardEvent!I ~interfaceは、 ~keyboard装置に特有な文脈的~情報を供する。 各~keyboard~eventは、 値を利用して~UIkeyを参照する。 ~keyboard~eventは、 共通して，~focusを得ている要素へ向けられることが多い。 ◎ The KeyboardEvent interface provides specific contextual information associated with keyboard devices. Each keyboard event references a key using a value. Keyboard events are commonly directed at the element that has the focus.
`KeyboardEvent$I ~interfaceは、 一部の共通的な修飾~UIkey用の簡便な属性：［ `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m ］を供する。 これらの属性【への取得~access】は、 順に，［ `Control$kY, `Shift$kY, `Alt$kY, `Meta$kY ］を引数に `getModifierState()$m ~methodを利用するのと等価である。 ◎ The KeyboardEvent interface provides convenient attributes for some common modifiers keys: ctrlKey, shiftKey, altKey, metaKey. These attributes are equivalent to using the method getModifierState() with Control, Shift, Alt, or Meta respectively.
`KeyboardEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `KeyboardEventInit$I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the KeyboardEvent interface, use the KeyboardEvent constructor, passing an optional KeyboardEventInit dictionary.
5.6.1.1. `KeyboardEvent^I
[`Exposed$=Window]
interface `KeyboardEvent@I : `UIEvent$I {
`KeyboardEvent@mc(`DOMString$ %type, optional `KeyboardEventInit$I %eventInitDict = {});
// `location$m 属性がとり得る定数
const `unsigned long$ `DOM_KEY_LOCATION_STANDARD$m = 0x00;
const `unsigned long$ `DOM_KEY_LOCATION_LEFT$m = 0x01;
const `unsigned long$ `DOM_KEY_LOCATION_RIGHT$m = 0x02;
const `unsigned long$ `DOM_KEY_LOCATION_NUMPAD$m = 0x03;
readonly attribute `DOMString$ `key$m;
readonly attribute `DOMString$ `code$m;
readonly attribute `unsigned long$ `location$m;
readonly attribute `boolean$ `ctrlKey$m;
readonly attribute `boolean$ `shiftKey$m;
readonly attribute `boolean$ `altKey$m;
readonly attribute `boolean$ `metaKey$m;
readonly attribute `boolean$ `repeat$m;
readonly attribute `boolean$ `isComposing$m;
`boolean$ `getModifierState$m (`DOMString$ %keyArg);
};
- `DOM_KEY_LOCATION_STANDARD@m
- 作動化された~UIkeyは、 ~UIkeyの左／右 ~versionとして判別されるものではなく，かつ 十key（ `NumLock^cap ~UIkeyは除く）, または それに対応する仮想~UIkeyからも出生されていないことを指示する。 ◎ The key activation MUST NOT be distinguished as the left or right version of the key, and (other than the NumLock key) did not originate from the numeric keypad (or did not originate with a virtual key corresponding to the numeric keypad).
-
~PC101US~keyboardの `Q^cap ~UIkey。 ◎ The Q key on a PC 101 Key US keyboard.
~PC101US~keyboardの `NumLock^cap ~UIkey。 ◎ The NumLock key on a PC 101 Key US keyboard.
~PC101US~keyboardの主区画に所在する `1^cap ~UIkey。 ◎ The 1 key on a PC 101 Key US keyboard located in the main section of the keyboard.
- `DOM_KEY_LOCATION_LEFT@m
- 作動化された~UIkeyは、 左~UIkey所在から出生されていることを指示する （当の~UIkey用にアリな所在が複数ある場合に限る）。 ◎ The key activated originated from the left key location (when there is more than one possible location for this key).
- ~PC101US~keyboardの左 `Control^cap ~UIkey。 ◎ The left Control key on a PC 101 Key US keyboard.
- `DOM_KEY_LOCATION_RIGHT@m
- 作動化された~UIkeyは、 右~UIkey所在から出生されていることを指示する （当の~UIkey用にアリな所在が複数ある場合に限る）。 ◎ The key activation originated from the right key location (when there is more than one possible location for this key).
- ~PC101US~keyboardの 右 `Shift^cap ~UIkey。 ◎ The right Shift key on a PC 101 Key US keyboard.
- `DOM_KEY_LOCATION_NUMPAD@m
- 作動化された~UIkeyは、 十key, または それに 対応する仮想~UIkeyから出生されていることを指示する （当の~UIkey用にアリな所在が複数ある場合に限る）。 `NumLock^cap ~UIkeyは常に，所在 `DOM_KEY_LOCATION_STANDARD$m を伴って符号化されるベキであることに注意。 ◎ The key activation originated on the numeric keypad or with a virtual key corresponding to the numeric keypad (when there is more than one possible location for this key). Note that the NumLock key should always be encoded with a location of DOM_KEY_LOCATION_STANDARD.
- ~PC101US~keyboardの ~numpadに所在する `1^cap ~UIkey。 ◎ The 1 key on a PC 101 Key US keyboard located on the numeric pad.
- `key@m ◎ key, of type DOMString, readonly
- 押された~UIkeyに対応する`~UIkey属性~値$を保持する。 ◎ key holds a key attribute value corresponding to the key pressed.
- 注記： `key^m 属性は，旧来の `keyCode$m 属性には関係しない — とり得る値の集合も同じでない。 ◎ The key attribute is not related to the legacy keyCode attribute and does not have the same set of values.
- `未初期化~値$： `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
- `code@m ◎ code, of type DOMString, readonly
- `code^m は、 押されている物理的~UIkeyを識別する文字列を保持する。 値は，現在の~keyboard~layoutや修飾~状態からは影響されないので、 同じ~UIkeyからは常に同じ値が返されることになる。 ◎ code holds a string that identifies the physical key being pressed. The value is not affected by the current keyboard layout or modifier state, so a particular key will always return the same value.
- `未初期化~値$： `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
- `location@m ◎ location, of type unsigned long, readonly
- `location^m 属性は、 装置~上の~UIkeyの論理的な所在の指示を包含する。 ◎ The location attribute contains an indication of the logical location of the key on the device.
- この属性は、［ 装置~上の~UIkeyの所在を指示する， `DOM_KEY_LOCATION-…^m 定数 ］のうちの，いずれかに設定するモノトスル。 ◎ This attribute MUST be set to one of the DOM_KEY_LOCATION constants to indicate the location of a key on the device.
- 【環境設定により】~UIkeyを~mapし直すことを許容する~UAは、 ~mapされた~~元の~UIkey用の `location$m 値を，新たな~UIkeyに適切な値に設定するモノトスル。 例えば， `ControlLeft$kC ~UIkeyが `KeyQ$kC ~UIkeyに~mapし直されたなら、 この属性は `DOM_KEY_LOCATION_STANDARD$m に設定するモノトスル。 逆に， `KeyQ$kC ~UIkeyが左右いずれかの `Control^cap ~UIkeyに~mapし直された場合、 それに応じて，この属性も［ `DOM_KEY_LOCATION_LEFT$m, `DOM_KEY_LOCATION_RIGHT$m ］のいずれかに設定するモノトスル。 ◎ If a user agent allows keys to be remapped, then the location value for a remapped key MUST be set to a value which is appropriate for the new key. For example, if the "ControlLeft" key is mapped to the "KeyQ" key, then the location attribute MUST be set to DOM_KEY_LOCATION_STANDARD. Conversely, if the "KeyQ" key is remapped to one of the Control keys, then the location attribute MUST be set to either DOM_KEY_LOCATION_LEFT or DOM_KEY_LOCATION_RIGHT.
- `未初期化~値$： 0 ◎ The un-initialized value of this attribute MUST be 0.
- `ctrlKey@m ◎ ctrlKey, of type boolean, readonly
- `Control^cap （ control ）修飾が作動中であったならば~T ◎ true if the Control (control) key modifier was active.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `shiftKey@m ◎ shiftKey, of type boolean, readonly
- `Shift^cap （ shift ）修飾が作動中であったならば~T。 ◎ true if the shift (Shift) key modifier was active.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `altKey@m ◎ altKey, of type boolean, readonly
- `Alt^cap （ alternative, ~~別名 `Option^cap ）修飾が作動中であったならば~T。 ◎ true if the Alt (alternative) (or "Option") key modifier was active.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `metaKey@m ◎ metaKey, of type boolean, readonly
- `Meta^cap（ meta ）修飾が作動中であったならば~T。 ◎ true if the meta (Meta) key modifier was active.
- 注記： Macintosh ~system上の `Command^cap （ `⌘^cap ）~UIkey修飾は この~UIkey修飾を利用して表現される。 ◎ The "Command" ("⌘") key modifier on Macintosh systems is represented using this key modifier.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `repeat@m ◎ repeat, of type boolean, readonly
- ~UIkeyが~~持続的に押されているならば ~T 。 ~UIkeyが~~押下げ続けられている下では、［ `keydown$et, `beforeinput$et, `input$et ］~eventが、 この順序で，~system環境設定から決定される頻度で，繰返すモノトスル。 `~UIkeyの長押し^em に対する挙動を備える携帯~機器においては、 `repeat$m 属性~値に ~T を伴う最初の~UIkey~eventが，その挙動を指示する~~役割を果たすモノトスル。 繰返され始めるまで~UIkeyを押し続ける必要がある時間の長さは、 環境設定に依存する。 ◎ true if the key has been pressed in a sustained manner. Holding down a key MUST result in the repeating the events keydown, beforeinput, input in this order, at a rate determined by the system configuration. For mobile devices which have long-key-press behavior, the first key event with a repeat attribute value of true MUST serve as an indication of a long-key-press. The length of time that the key MUST be pressed in order to begin repeating is configuration-dependent.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `isComposing@m ◎ isComposing, of type boolean, readonly
- ~UIkey~eventが組成~sessionの一部として — すなわち， `compositionstart$et ~eventの後, かつ 対応する `compositionend$et ~eventの前に — 生じたならば~T。 ◎ true if the key event occurs as part of a composition session, i.e., after a compositionstart event and before the corresponding compositionend event.
- `未初期化~値$： ~F ◎ The un-initialized value of this attribute MUST be false.
- `getModifierState(keyArg)@m
- `~UIkey値$を利用して，ある修飾の状態を~queryする。 ◎ Queries the state of a modifier using a key value.
- ［ %keyArg は修飾~UIkey用の`~UIkey値$であって，その~UIkeyは作動化されているならば ~T ／ ~ELSE_ ~F ］を返す。 ◎ Returns true if it is a modifier key and the modifier is activated, false otherwise.
- 引数 %keyArg には、 修飾`~UIkey値$を与える。 妥当な`修飾~UIkey$は、 `UIEvents-Key$r の`修飾~UIkeyの表t$にて定義される。 ◎ DOMString keyArg ◎ A modifier key value. Valid modifier keys are defined in the Modifier Keys table in [UIEvents-Key].
- 注記： ~appが 右, 左の修飾を判別したいと望む場合、 この情報は， ~keyboard~event, および `KeyboardEvent.location$m を利用して演繹することもできる。 ◎ If an application wishes to distinguish between right and left modifiers, this information could be deduced using keyboard events and location.
5.6.1.2. `KeyboardEventInit^I
dictionary `KeyboardEventInit@I : `EventModifierInit$I {
`DOMString$ `key@m = "";
`DOMString$ `code@m = "";
`unsigned long$ `location@m = 0;
`boolean$ `repeat@m = false;
`boolean$ `isComposing@m = false;
};
この辞書の各~memberは、 `KeyboardEvent$I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ key, of type DOMString, defaulting to "" • Initializes the key attribute of the KeyboardEvent object to the unicode character string representing the meaning of a key after taking into account all keyboard modifiers (such as shift-state). This value is the final effective value of the key. If the key is not a printable character, then it should be one of the key values defined in [UIEvents-Key]. ◎ code, of type DOMString, defaulting to "" • Initializes the code attribute of the KeyboardEvent object to the unicode character string representing the key that was pressed, ignoring any keyboard modifications such as keyboard layout. This value should be one of the code values defined in [UIEvents-Code]. ◎ location, of type unsigned long, defaulting to 0 • Initializes the location attribute of the KeyboardEvent object to one of the following location numerical constants: • DOM_KEY_LOCATION_STANDARD (numerical value 0) • DOM_KEY_LOCATION_LEFT (numerical value 1) • DOM_KEY_LOCATION_RIGHT (numerical value 2) • DOM_KEY_LOCATION_NUMPAD (numerical value 3) ◎ repeat, of type boolean, defaulting to false • Initializes the repeat attribute of the KeyboardEvent object. This attribute should be set to true if the the current KeyboardEvent is considered part of a repeating sequence of similar events caused by the long depression of any single key, false otherwise. ◎ isComposing, of type boolean, defaulting to false • Initializes the isComposing attribute of the KeyboardEvent object. This attribute should be set to true if the event being constructed occurs as part of a composition sequence, false otherwise.
旧来の~keyboard~event実装は 3 種の追加的な属性［ `keyCode$m, `charCode$m, `which$m ］を含んでいる。 `keyCode^m 属性は［ ~computer~keyboardの特定0の~UIkeyに結付けられた数的な値 ］を指示する一方、 `charCode^m 属性は［ その~UIkeyに結付けられた文字の~ASCII値 ］を指示し（ `keyCode^m 値と同じにもなり得る）， 適用-可能なのは`文字~値$を生産する~UIkeyに限られる。 ◎ Legacy keyboard event implementations include three additional attributes, keyCode, charCode, and which. The keyCode attribute indicates a numeric value associated with a particular key on a computer keyboard, while the charCode attribute indicates the ASCII value of the character associated with that key (which might be the same as the keyCode value) and is applicable only to keys that produce a character value.
実施においては、［ `keyCode^m, `charCode^m ］は，［ ~platform間で, あるいは 同じ実装ですら 種々の~OSや地域化の間で ］一貫でない。 この仕様は［ `keyCode^m, `charCode^m ］の値も, `charCode^m の挙動も定義しない。 適合~UI~Events実装においては，内容~作者は、［ `KeyboardEvent.key$m, `KeyboardEvent.code$m ］を利用できる。 ◎ In practice, keyCode and charCode are inconsistent across platforms and even the same implementation on different operating systems or using different localizations. This specification does not define values for either keyCode or charCode, or behavior for charCode. In conforming UI Events implementations, content authors can instead use key and code.
更なる情報は、 参考な `§ 旧来の~UIkey属性＠~UIEVENTS-A#legacy-key-attributes$href を見よ。 ◎ For more information, see the informative appendix on Legacy key attributes.
注記： 既存の内容との互換性のため，仮想~keyboard — ~screenに基づく入力~装置~上の~software~keyboardなど — は、［ 物理的~UIkeyを処理しなくとも，通常の範囲の~keyboard~eventを生産する ］ものと期待されている。 ◎ For compatibility with existing content, virtual keyboards, such as software keyboards on screen-based input devices, are expected to produce the normal range of keyboard events, even though they do not possess physical keys.
注記： 一部の実装／~system環境設定においては、 一部の~UIkey~eventやその値は，利用-中な`~IME$により抑止されることがある。 ◎ In some implementations or system configurations, some key events, or their values, might be suppressed by the IME in use.
5.6.2. ~keyboard~eventに対する~UIkeyの所在
`location$m 属性は、 ~keyboard上の異なる物理的~UIkeyから同じ`~UIkey値$が生成される場合に， それらを~~区別するために利用できる。 例えば、 左右 `Shift^cap ~UIkey，あるいは 物理的~矢印~UIkeyと（ `NumLock^cap が off のときの）~numpad上の矢印~UIkey。 ◎ The location attribute can be used to disambiguate between key values that can be generated by different physical keys on the keyboard, for example, the left and right Shift key or the physical arrow keys vs. the numpad arrow keys (when NumLock is off).
~keyboard上に所在が複数あるような特別な~UIkey用の，妥当な `location$m 値は、 次の表tに定義される： ◎ The following table defines the valid location values for the special keys that have more than one location on the keyboard:
| `key$m 値 ◎ KeyboardEvent . key | 妥当な `location$m 値 ◎ Valid location values |
|---|---|
| `Shift$kY, `Control$kY, `Alt$kY, `Meta$kY | `DOM_KEY_LOCATION_LEFT$m, `DOM_KEY_LOCATION_RIGHT$m |
| `ArrowDown$kY, `ArrowLeft$kY, `ArrowRight$kY, `ArrowUp$kY | `DOM_KEY_LOCATION_STANDARD$m, `DOM_KEY_LOCATION_NUMPAD$m |
| `End$kY, `Home$kY, `PageDown$kY, `PageUp$kY | `DOM_KEY_LOCATION_STANDARD$m, `DOM_KEY_LOCATION_NUMPAD$m |
| `0^kY, `1^kY, `2^kY, `3^kY, `4^kY, `5^kY, `6^kY, `7^kY, `8^kY, `9^kY, `.^kY, `Enter$kY, `+^kY, `-^kY, `*^kY, `/^kY, | `DOM_KEY_LOCATION_STANDARD$m, `DOM_KEY_LOCATION_NUMPAD$m |
この表tに挙げられていない他のすべての~UIkey用の `location$m 属性は、 常に `DOM_KEY_LOCATION_STANDARD$m に設定するモノトスル。 ◎ For all other keys not listed in this table, the location attribute MUST always be set to DOM_KEY_LOCATION_STANDARD.
5.6.3. ~keyboard~event序列
この仕様にて定義される~keyboard~eventは、 与えられたどの~UIkeyに対しても，相互相対順序の下で生じる： ◎ The keyboard events defined in this specification occur in a set order relative to one another, for any given key:
| ~event型 | 備考 | |
|---|---|---|
| 1. | `keydown$et | |
| 2. | `beforeinput$et | （`文字~値$を生産する~UIkeyに対してのみ） ◎ (only for keys which produce a character value) |
| この~UIkeyに関係する`既定~動作$ — 文字を~DOMの中へ挿入するなど — があれば，それが行われる。 ◎ Any default actions related to this key, such as inserting a character in to the DOM. | ||
| 3. | `input$et | （~DOMを更新させた~UIkeyに対してのみ） ◎ (only for keys which have updated the DOM) |
| 一定時間，~UIkeyが押下げられたとき、 生じ得るような~event（下を見よ）。 ◎ Any events as a result of the key being held for a sustained period (see below). | ||
| 4. | `keyup$et |
一定時間，~UIkeyが押下げられた場合、 環境に依存する頻度で，次の~eventが繰返されてもヨイ： ◎ If the key is depressed for a sustained period, the following events MAY repeat at an environment-dependent rate:
| ~event型 | 備考 | |
|---|---|---|
| 1. | `keydown$et | （ `KeyboardEvent.repeat$m 属性は ~T に設定される） ◎ (with repeat attribute set to true) |
| 2. | `beforeinput$et | （`文字~値$を生産した~UIkeyに対してのみ） ◎ (only for keys which produce a character value) |
| 【！複製】 この~UIkeyに関係する`既定~動作$ — 文字を~DOMの中へ挿入するなど — があれば，それが行われる。 ◎ Any default actions related to this key, such as inserting a character in to the DOM. | ||
| 3. | `input$et | 【！複製】 （~DOMを更新させた~UIkeyに対してのみ） ◎ (only for keys which have updated the DOM) |
注記： 概して、 特定0の~UIkeyに結付けられた`既定~動作$があれば， `keyup$et ~eventが発火される前に完了する。 これは `keyup$et ~eventを少しばかり遅延し得る （おそらく，知覚される程の遅延にはならないであろうが）。 ◎ Typically, any default actions associated with any particular key are completed before the keyup event is dispatched. This might delay the keyup event slightly (though this is not likely to be a perceptible delay).
~UIkey~eventの`~target$は、 ~keyboard活動を処理している現在の被focus要素である。 これは、［ ~HTML `input^e 要素／編集-可能な~textな要素 ］になることが多いが、 `~host言語$における非~text目的の~keyboard入力 — 加速~UIkeyの作動化や 一部の他の挙動の誘発など — を受容するように定義された要素になることもある。 相応しい被focus要素が無い場合の~event~targetは、［ 可用なら ~HTML`~body要素$ ／ 他の場合は `根~要素$ ］になる。 ◎ The event target of a key event is the currently focused element which is processing the keyboard activity. This is often an HTML input element or a textual element which is editable, but MAY be an element defined by the host language to accept keyboard input for non-text purposes, such as the activation of an accelerator key or trigger of some other behavior. If no suitable element is in focus, the event target will be the HTML body element if available, otherwise the root element.
注記： `~event~target$は、 一連の~UIkey~event間で変化し得る。 例えば， `Tab^cap ~UIkey用の `keydown$et ~eventの`~target$は、 同じ~keystroke用の `keyup$et ~eventと異なるであろう。 ◎ The event target might change between different key events. For example, a keydown event for the Tab key will likely have a different event target than the keyup event on the same keystroke.
5.6.4. 各種~keyboard~event型
5.6.4.1. `keydown^et
文脈依存：
- `beforeinput$et ＆ `input$et ~event
- `~text組成~system$を立上げる
- `blur$et ＆ `focus$et ~event
- `keypress$et ~event（~support有りなら）
- `作動化の挙動$
- その他の~event
~UAは、［ ~UIkeyが押された ］とき，この~eventを発火するモノトスル。 `keydown$et ~event型は装置~依存であり， 入力~装置の能力, および それらが~OSにおいて~mapされている方法に依拠する。 この~event型は、 `~UIkey~mapping$の後に生成するモノトスル。 この~event型は、 同じ~UIkeyに結付けられた［ `beforeinput$et, `input$et, `keyup$et ］~eventの前に配送するモノトスル。 ◎ A user agent MUST dispatch this event when a key is pressed down. The keydown event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type MUST be generated after the key mapping. This event type MUST be dispatched before the beforeinput, input, and keyup events associated with the same key.
`keydown$et ~eventの既定~動作は，~UIkeyに依存する： ◎ The default action of the keydown event depends upon the key:
- ~UIkeyが文字に結付けられた場合の既定~動作は、［ `beforeinput$et ~eventと, ~~後続する `input$et ~event ］を発火するモノトスル。 ~UIkeyが複数の文字に結付けられた場合 （~macroを伴うものや ~dead-keyからなる連列など） の既定~動作は、 各~文字に対し［ `beforeinput$et, `input$et ］~event対を発火するモノトスル。 ◎ If the key is associated with a character, the default action MUST be to dispatch a beforeinput event followed by an input event. In the case where the key which is associated with multiple characters (such as with a macro or certain sequences of dead keys), the default action MUST be to dispatch one set of beforeinput / input events for each character
- ~UIkeyが`~text組成~system$に結付けられた場合の既定~動作は、 その~systemを立上げるモノトスル。 ◎ If the key is associated with a text composition system, the default action MUST be to launch that system
- ~UIkeyが `Tab^cap ~UIkeyの場合の既定~動作は、 `~focus~event$型にて述べたように，文書~focusを現在の被focus要素（もしあれば）から新たな被focus要素へ移転するモノトスル。 ◎ If the key is the Tab key, the default action MUST be to shift the document focus from the currently focused element (if any) to the new focused element, as described in Focus Event Types
- ~UIkeyが `Enter^cap ／ `~SPACEBAR^cap ~UIkeyであって, かつ 現在の~focusが状態~変化-中にある要素~上にある場合の既定~動作は、［ `click$et ~eventに加えて，~UAにより~supportされているなら `DOMActivate$et ~event ］を発火するモノトスル （詳細は、 `作動化の誘発と挙動$に） ◎ If the key is the 'Enter' or ' ' (Space) key and the current focus is on a state-changing element, the default action MUST be to dispatch a click event, and a DOMActivate event if that event type is supported by the user agent (refer to § 3.5 Activation triggers and behavior for more details)
この~eventが取消された場合、［ 結付けられた~event型は発火しないことに加え， 結付けられた動作も遂行しない ］モノトスル。 ◎ If this event is canceled, the associated event types MUST NOT be dispatched, and the associated actions MUST NOT be performed.
注記： ［ `keydown$et ／ `keyup$et ］~eventは、 伝統的に［ `文字~値$を生産する~UIkeyに限らず，他の~UIkeyの検出-法 ］にも結付けられる。 ◎ The keydown and keyup events are traditionally associated with detecting any key, not just those which produce a character value.
5.6.4.2. `keyup^et
~UAは、［ ~UIkeyが離された ］とき，この~eventを発火するモノトスル。 `keyup$et ~event型は装置~依存であり， 入力~装置の能力, および それらが~OSにおいて~mapされている方法 に依拠する。 この~event型は，`~UIkey~mapping$の後に生成するモノトスル。 この~event型は、 同じ~UIkeyに結付けられた［ `keydown$et, `beforeinput$et, `input$et ］~eventの後に発火するモノトスル。 ◎ A user agent MUST dispatch this event when a key is released. The keyup event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type MUST be generated after the key mapping. This event type MUST be dispatched after the keydown, beforeinput, and input events associated with the same key.
注記： ［ `keydown$et ／ `keyup$et ］~eventは、 伝統的に［ `文字~値$を生産する~UIkeyに限らず，他の~UIkeyの検出-法 ］にも結付けられる。 ◎ The keydown and keyup events are traditionally associated with detecting any key, not just those which produce a character value.
各種~keyboard~eventに共通な文脈~情報
集約簡略化~keyboard~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：
- `target$m
- ~UIkey~eventを処理している被focus要素。 被focus要素がない場合、 可用ならば`~body要素$ ／ 他の場合 `根~要素$ ◎ Event.target : focused element processing the key event or if no element focused, then the body element if available, otherwise the root element
- `UIEvent!I の各~属性：
- `各種~UI~eventに共通な文脈~情報$にて与えられる。
- `KeyboardEvent!I ：
-
- `key$m
- 押された~UIkeyの`~UIkey値$。 ◎ KeyboardEvent.key : the key value of the key pressed.
- `code$m
- ~UIkeyの~keyboard上での物理的~~位置に結付けられた~code値 ◎ KeyboardEvent.code : the code value associated with the key’s physical placement on the keyboard.
- `location$m
- 装置~上の~UIkeyの所在。 ◎ KeyboardEvent.location : the location of the key on the device.
- `altKey$m
- `Alt^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.altKey : true if Alt modifier was active, otherwise false
- `shiftKey$m
- `Shift^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.shiftKey : true if Shift modifier was active, otherwise false
- `ctrlKey$m
- `Control^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.ctrlKey : true if Control modifier was active, otherwise false
- `metaKey$m
- `Meta^cap 修飾が作動中であったなら ~T ／ 他の場合 ~F ◎ KeyboardEvent.metaKey : true if Meta modifier was active, otherwise false
- `repeat$m
- ~UIkeyの繰返nを誘発するに十分~長く~UIkeyが押下げられているならば ~T ／ 他の場合 ~F ◎ KeyboardEvent.repeat : true if a key has been depressed long enough to trigger key repetition, otherwise false
- `isComposing$m
- ~UIkey~eventが，組成~sessionの一部として生じたならば ~T ／ 他の場合 ~F ◎ KeyboardEvent.isComposing : true if the key event occurs as part of a composition session, otherwise false
5.7. 組成~event
組成~event（ `Composition Events^en ）は、 ~~普通の~keyboardにない文字を利用できるように，`~keyboard~event$によるものに［ 補足的な, あるいは代替する ］方式で，~textを入力する手段を供する。 組成~eventは、 例えば，次のために利用され得る：
- 文字に標準的な~US~keyboardには無い~accentを追加する。
- 多くのアジア圏の言語において，基底~成分／字種から表語文字を築上げる。
- 携帯~機器~keyboardで，押されている~UIkeyの組合nから 単語を選択する。
- 発話~認識~処理器を利用して，一連の~voice~commandを~textに変換する。
`組成~event$を~keyboard~eventと組合せる用例については、 `§ ~keyboard~eventと~UIkey値$に。
◎ Composition Events provide a means for inputing text in a supplementary or alternate manner than by Keyboard Events, in order to allow the use of characters that might not be commonly available on keyboard. For example, Composition Events might be used to add accents to characters despite their absence from standard US keyboards, to build up logograms of many Asian languages from their base components or categories, to select word choices from a combination of key presses on a mobile device keyboard, or to convert voice commands into text using a speech recognition processor. Refer to § 6 Keyboard events and key values for examples on how Composition Events are used in combination with keyboard events.概念的には、 組成~sessionは［ 1 個の `compositionstart$et ~event, 1 個【 0 個？】以上の `compositionupdate$et ~event, 1 個の `compositionend$et ~event ］からなり、 それらの~eventの `CompositionEvent.data$m 属性の値は， 各~sessionの最中のこの~event連鎖【伝播？連列？】の各 “stage” 間で持続する【？】。 ◎ Conceptually, a composition session consists of one compositionstart event, one or more compositionupdate events, and one compositionend event, with the value of the data attribute persisting between each "stage" of this event chain during each session.
注記： 組成~sessionで利用されている入力~装置が~keyboardである場合、 組成~sessionが作動中にある間の~keyboard~eventは，~DOMへ発火され得る。 関連な~eventたちの順序付けについては、 `compositionstart$et の詳細, `§ ~IME＠#keys-IME$hrefを見よ。 ◎ Note: While a composition session is active, keyboard events can be dispatched to the DOM if the keyboard is the input device used with the composition session. See the compositionstart event details and IME section for relevent event ordering.
`~IME$~system／装置は，~DOMに必要yな~dataを公開するとは限らないので、 作動中な組成~文字列 （ “変換窓（ `Reading Window^en ）” や “候補~選択~menuに示されるもの” ） は，この~interfaceを通して可用でないこともある — その場合、 選択は`空~文字列$として表現されることもある。 ◎ Not all IME systems or devices expose the necessary data to the DOM, so the active composition string (the "Reading Window" or "candidate selection menu option") might not be available through this interface, in which case the selection MAY be represented by the empty string.
5.7.1. `CompositionEvent^I ~interface
この仕様にて導入された。 ◎ Introduced in this specification
`CompositionEvent^I ~interfaceは、 `組成~event$に特有な文脈的~情報を供する。 ◎ The CompositionEvent interface provides specific contextual information associated with Composition Events.
`CompositionEvent^I ~interfaceの~instanceを作成するためには、 その構築子に `CompositionEventInit^I 辞書（省略可能）を渡して呼び出す。 ◎ To create an instance of the CompositionEvent interface, use the CompositionEvent constructor, passing an optional CompositionEventInit dictionary.
5.7.1.1. `CompositionEvent^I
[`Exposed$=Window]
interface `CompositionEvent@I : `UIEvent$I {
`CompositionEvent@mc(`DOMString$ %type, optional `CompositionEventInit$I %eventInitDict = {});
readonly attribute `USVString$ `data$m;
};
- `data@m ◎ data, of type USVString, readonly
- `data^c は~IMEにより生成された一連の`文字~値$を保持する — `空~文字列$にもなり得る。 一連の文字は、［ `UAX15$r にて定義される~Unicode正規化~形 `NFC^em ］による定義に従って正規化されるベキである。 ◎ data holds the value of the characters generated by an input method. This MAY be a single Unicode character or a non-empty sequence of Unicode characters [Unicode]. Characters SHOULD be normalized as defined by the Unicode normalization form NFC, defined in [UAX15]. This attribute MAY be the empty string.
- `未初期化~値$： `空~文字列$ ◎ The un-initialized value of this attribute MUST be "" (the empty string).
5.7.1.2. `CompositionEventInit^I
dictionary `CompositionEventInit@I : `UIEventInit$I {
`DOMString$ `data@m = "";
};
この辞書の各~memberは、 `CompositionEvent!I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、 その~interface定義の記述を見よ。 ◎ data, of type DOMString, defaulting to "" • Initializes the data attribute of the CompositionEvent object to the characters generated by the IME composition.
5.7.2. 組成~event序列
この仕様にて定義される`組成~event$は、 次による相互相対順序の下で生じるモノトスル： ◎ The Composition Events defined in this specification MUST occur in the following set order relative to one another:
| ~event型 | 備考 | |
|---|---|---|
| 1. | `compositionstart$et | |
| 2. | `compositionupdate$et | 複数回 生じ得る ◎ Multiple events |
| 3. | `compositionend$et |
5.7.3. 手書き認識~system
次の例に、［ ~pen~tabletなどの手書き認識~systemの下で，一節の~text "text" を組成する ］ときにアリな~event連列を，`組成~event$の~modelを利用して述べる。 ◎ The following example describes a possible sequence of events when composing a text passage "text" with a handwriting recognition system, such as on a pen tablet, as modeled using Composition Events.
| ~event型 | `CompositionEvent.data$m | 備考 | |
|---|---|---|---|
| 1. | `compositionstart$et | `^kGl | |
| 利用者が~tablet表面に単語を書いた ◎ User writes word on tablet surface | |||
| 2. | `compositionupdate$et | `test^kGl | |
| 利用者が~~候補として最初に挙げられた単語を却下して，異なる~~候補を選択した ◎ User rejects first word-match suggestion, selects different match | |||
| 3. | `compositionupdate$et | `text^kGl | |
| 4. | `compositionend$et | `text^kGl |
5.7.4. 組成~eventの取消~法
`keydown$et ~eventが取消された場合、 その `keydown$et の結果として発火されることになる どの`組成~event$も，発火されるベキでない： ◎ If a keydown event is canceled then any Composition Events that would have fired as a result of that keydown SHOULD not be dispatched:
| ~event型 | 備考 | |
|---|---|---|
| 1. | `keydown$et | `既定~動作$は、 例えば `preventDefault()$m の呼出ngにより，防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). |
| `組成~event$は発火されない。 ◎ No Composition Events are dispatched | ||
| 2. | `keyup$et |
初期 `compositionstart$et ~eventが取消された場合、 ~text組成~sessionは，終了されるベキである。 `compositionend$et ~eventは、 組成~sessionが終了されたかどうかに関わらず，送信するモノトスル。 ◎ If the initial compositionstart event is canceled then the text composition session SHOULD be terminated. Regardless of whether or not the composition session is terminated, the compositionend event MUST be sent.
| ~event型 | 備考 | |
|---|---|---|
| 1. | `keydown$et | |
| 2. | `compositionstart$et | 【！複製】 `既定~動作$は、 例えば `preventDefault()$m の呼出ngにより，防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). |
| 【！複製】 `組成~event$は発火されない。 ◎ No Composition Events are dispatched | ||
| 3. | `compositionend$et | |
| 4. | `keyup$et |
5.7.5. 組成~時における~UIkey~event
組成~sessionの最中でも、 依然として［ `keydown$et, `keyup$et ］~eventは送信するモノトスル — その `KeyboardEvent.isComposing$m 属性は ~T になるモノトスル。 ◎ During the composition session, keydown and keyup events MUST still be sent, and these events MUST have the isComposing attribute set to true.
| ~event型 | `KeyboardEvent.isComposing$m | 備考 | |
|---|---|---|---|
| 1. | `keydown$et | ~F | これが組成を起動した~UIkey~eventである。 ◎ This is the key event that initiates the composition. |
| 2. | `compositionstart$et | ||
| 3. | `compositionupdate$et | ||
| 4. | `keyup$et | ~T | |
| ... | 組成~sessionの最中に送信された どの~UIkey~eventも， `KeyboardEvent.isComposing$m は ~T に設定するモノトスル。 ◎ Any key events sent during the composition session MUST have isComposing set to true. | ||
| 5. | `keydown$et | ~T | これが組成を終わらせた~UIkey~eventである。 ◎ This is the key event that exits the composition. |
| 6. | `compositionend$et | ||
| 7. | `keyup$et | ~F |
5.7.6. 組成~sessionの間の入力~event
組成~sessionの間は、 その `compositionupdate$et は， `beforeinput$et が送信された後, かつ `input$et が送信される前に発火するモノトスル。 ◎ During the composition session, the compositionupdate MUST be dispatched after the beforeinput is sent, but before the input event is sent.
| ~event型 | 備考 | |
|---|---|---|
| 1. | `beforeinput$et | |
| 2. | `compositionupdate$et | |
| ~DOMの更新はこの時点で生じる。 ◎ Any DOM updates occur at this point. | ||
| 3. | `input$et |
注記： ほとんどの~IMEは、 組成~sessionの間における更新の取消~法は~supportしない。 ◎ Most IMEs do not support canceling updates during a composition session.
［ `beforeinput$et ／ `input$et ］~eventは、 組成の一部として~DOMが更新されるときに， `compositionupdate$et ~eventに伴って送信される。 `compositionend$et ~eventに対しては，~DOMの更新はないので、［ `beforeinput$et ／ `input$et ］~eventは送信されるべきではない。 ◎ The beforeinput and input events are sent along with the compositionupdate event whenever the DOM is updated as part of the composition. Since there are no DOM updates associated with the compositionend event, beforeinput and input events should not be sent at that time.
| ~event型 | 備考 | |
|---|---|---|
| 1. | `beforeinput$et | これを取消したときは ~DOM更新と `input$et ~eventを防止することになる。 ◎ Canceling this will prevent the DOM update and the input event. |
| 2. | `compositionupdate$et | |
| ~DOMの更新はこの時点で生じる。 ◎ Any DOM updates occur at this point. | ||
| 3. | `input$et | ~DOMが更新された場合に限り送信される。 ◎ Sent only if the DOM was updated. |
| 4. | `compositionend$et |
5.7.7. 各種~組成~event型
5.7.7.1. `compositionstart^et
次を除き，`各種~組成~eventに共通な文脈~情報$にて与えられる：
- `CompositionEvent.data$m： 編集-中にある【！元の】文字列, または `空~文字列$
~UAは、 `~text組成~system$が可能化されている下で，［ ~textの一節を組成する準備として，新たな組成~sessionが始まりつつある （または，`~text組成~system$に依存して始まった） ］とき，この~eventを発火するモノトスル。 この~event型は、 装置に依存し，［ ~text変換~systemの能力, ~OSに~mapされる方法 ］に依拠することもある。 この~event型は、 ~IMEへの~~入力が~keyboardから投入された場合は， `keydown$et ~eventの後に生成されるが、［ 発話／手書き ］認識~systemにおいては ~keyboard~eventを伴わずに送信されてもヨイ。 実装は、 `compositionstart$et ~eventの `CompositionEvent.data$m 属性を［ 文書にて現在（編集／置換~用に）選択されている~text ］で拡充してもヨイ — そうしない場合、 `空~文字列$にするモノトスル。 ◎ A user agent MUST dispatch this event when a text composition system is enabled and a new composition session is about to begin (or has begun, depending on the text composition system) in preparation for composing a passage of text. This event type is device-dependent, and MAY rely upon the capabilities of the text conversion system and how it is mapped into the operating system. When a keyboard is used to feed an input method editor, this event type is generated after a keydown event, but speech or handwriting recognition systems MAY send this event type without keyboard events. Some implementations MAY populate the data attribute of the compositionstart event with the text currently selected in the document (for editing and replacement). Otherwise, the value of the data attribute MUST be the empty string.
この~eventは、 `~text組成~system$が新たな組成~sessionを始める直前に, かつ 組成~処理により~DOMが改変される前に，発火するモノトスル。 この~eventの，`~text組成~system$用の既定~動作は、 新たな組成~sessionを開始させる。 この~eventが取消された場合、 `~text組成~system$は，現在の組成~sessionを破棄するベキである。 ◎ This event MUST be dispatched immediately before a text composition system begins a new composition session, and before the DOM is modified due to the composition process. The default action of this event is for the text composition system to start a new composition session. If this event is canceled, the text composition system SHOULD discard the current composition session.
注記： `compositionstart$et ~eventを取消すことと，`~text組成~system$自身を取消すこと （例： 取消~buttonを叩いたり, `~IME$ ~UIwindowを閉じるなど） とは、 別物である。 ◎ Canceling the compositionstart event type is distinct from canceling the text composition system itself (e.g., by hitting a cancel button or closing an IME window).
注記： ~IMEには、 進捗-中にある組成~sessionの取消~法を~supportしないものもある （例： GTK などは，~~現時点ではそのような~APIを備えていない）。 そのような事例では、 `preventDefault()$m を~callしても，この~eventの既定~動作は停止されないことになる。 ◎ Some IMEs do not support cancelling an in-progress composition session (e.g., such as GTK which doesn’t presently have such an API). In these cases, calling preventDefault() will not stop this event’s default action.
5.7.7.2. `compositionupdate^et
次を除き，`各種~組成~eventに共通な文脈~情報$にて与えられる：
- `CompositionEvent.data$m： 組成~sessionの現在の結果を成す文字列。 内容が削除された場合には`空~文字列$になることもある。
~UAは、［ 組成~sessionの最中に，`~text組成~system$が その作動中な~text一節を新たな文字で更新するとき ］に，この~eventを発火するベキである。 また、 配送するときは， `CompositionEvent.data$m 値にその更新を反映するモノトスル。 ◎ A user agent SHOULD dispatch this event during a composition session when a text composition system updates its active text passage with a new character, which is reflected in the string in data.
［ 進行中な組成と入力~controlとの同期cを保つ ］ような `~text組成~system$においては、 `compositionupdate$et ~eventは，その~controlが更新される前に配送するモノトスル。 ◎ In text composition systems which keep the ongoing composition in sync with the input control, the compositionupdate event MUST be dispatched before the control is updated.
`~text組成~system$には、 この情報を~DOMに公開しないものもある — その場合、 この~eventは，組成~処理nの最中には発火されないことになる。 ◎ Some text composition systems might not expose this information to the DOM, in which case this event will not fire during the composition process.
組成~sessionが取消された場合、 この~eventは， `compositionend$et ~eventの直前に — その `CompositionEvent.data$m 属性を`空~文字列$に設定した上で — 発火されることになる。 ◎ If the composition session is canceled, this event will be fired immediately before the compositionend event, and the data attribute will be set to the empty string.
5.7.7.3. `compositionend^et
次を除き，`各種~組成~eventに共通な文脈~情報$にて与えられる：
- `CompositionEvent.data$m： 組成~sessionの最終的な結果を成す文字列。 内容が削除されたり, 組成~処理nが取消された場合など、 `空~文字列$になることもある。
~UAは、［ `~text組成~system$が 現在の組成~sessionを 完了した, または取消された ］とき，この~eventを発火するモノトスル。 この~eventは、 ~controlが更新された後に配送するモノトスル。 ◎ A user agent MUST dispatch this event when a text composition system completes or cancels the current composition session, and the compositionend event MUST be dispatched after the control is updated.
この~eventは、 `~text組成~system$が組成~sessionを完了した直後に配送される （例： `~IME$が［ 閉じられた ／ 最小~化された ／ ~focusが他へ切替えられた ／ その他~退けられた ］後に，~focusが~~元の~UAに切替わったときなど）。 ◎ This event is dispatched immediately after the text composition system completes the composition session (e.g., the IME is closed, minimized, switched out of focus, or otherwise dismissed, and the focus switched back to the user agent).
各種~組成~eventに共通な文脈~情報
集約簡略化多くの組成~eventに共通な文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、 これらより優先される：
- `target$m
- 組成を処理している被focus要素。 ~access可能でないならば~NULL。 ◎ Event.target : focused element processing the composition, null if not accessible
- `UIEvent!I の各~属性：
- `各種~UI~eventに共通な文脈~情報$にて与えられる。
6. ~keyboard~eventと~UIkey値
この節では、 ~keyboard~eventに関して必要yな情報を与える： ◎ This section contains necessary information regarding keyboard events:
- ~keyboard~layout, ~mapping, `~UIkey値$ についての説明。 ◎ Explanation of keyboard layout, mapping, and key values.
- `~dead-key$や修飾~UIkeyなどの、 ~UIkeyどうしの関係。 ◎ Relations between keys, such as dead keys or modifiers keys.
- ~keyboard~eventとその既定~動作との関係。 ◎ Relations between keyboard events and their default actions.
- `key^m 値の集合, および この集合を拡張する方法についての指針。 ◎ The set of key values, and guidelines on how to extend this set.
注記： この節では、 ~Serbianと漢字を利用する。 【！which could be misrepresented or unavailable...】 ◎ This section uses Serbian and Kanji characters which could be misrepresented or unavailable in the PDF version or printed version of this specification.
6.1. ~keyboard入力
◎非規範的完全な~keyboardの各~UIkeyの関係性には，次に挙げる別々な側面があり、 いずれも — 特に，~localeに特有な理由で — ~keyboard機種や環境設定により様々になる： ◎ The relationship of each key to the complete keyboard has three separate aspects, each of which vary among different models and configurations of keyboards, particularly for locale-specific reasons:
- 物理的0な~layout： ~keyboard上での物理的な~UIkeyの 寸法, ~size, ~~配置 ◎ Mechanical layout: the dimensions, size, and placement of the physical keys on the keyboard
- 視覚的な目印： 各~UIkeyを印字する~label（または `銘^em） ◎ Visual markings: the labels (or legends) that mark each key
- 機能上の~mapping： 各~UIkey用の抽象的な ~UIkey ↔ 値の結付け。 ◎ Functional mapping: the abstract key-value association of each key.
この仕様は、 `key^m 値 および `code^m 値 を通して，機能上の~mappingのみを定義するが、 背景0として， `~UIkey銘＠#key-legends$についても概括する。 ◎ This specification only defines the functional mapping, in terms of key values and code values, but briefly describes key legends for background.
6.1.1. ~UIkey銘
◎非規範的~UIkey銘（ `key legend^en ）とは、 その `~UIkey~cap^em （~UIkeyの物理的0な~switchを覆う “~cap” ） 上に印刷されたり, 彫り込まれている，視覚的な目印である。 この種の目印は、 通常は，その~UIkeyに対する~keystrokeが生産するような 1 個~以上の文字からなる（例： `G^kGl, `8^kGl, `ш^kGl ）, あるいは その~UIkeyの機能を指示する名前や記号 （例： `Shift^cap を指示する上向き矢印 `⇧^kGl, 文字列 "Enter" など）。 ~UIkeyは、 この目印で指されることが多い （例： “ Shift ＋ F ~UIkeyを押してください。” ）。 しかしながら、 ~UIkeyの視覚的な見かけは，その~digital表現とは~~関係ないものであり、 多くの環境設定で，まったく正確aでないものにもなり得る。 `Enter^cap などの 制御~UIkey／~function~UIkey であっても，機能性が異なるものや, 文字~UIkeyに~mapされることすら あり得る。 ◎ The key legend is the visual marking that is printed or embossed on the key cap (the rectangular "cap" that covers the mechanical switch for the key). These markings normally consist of one or more characters that a keystroke on that key will produce (such as "G", "8", or "ш"), or names or symbols which indicate that key’s function (such as an upward-pointing arrow "⇧" indicating Shift, or the string "Enter"). Keys are often referred to by this marking (e.g., "Press the "Shift" and "G" keys."). Note, however, that the visual appearance of the key has no bearing on its digital representation, and in many configurations may be completely inaccurate. Even the control and function keys, such as Enter, may be mapped to different functionality, or even mapped as character keys.
注記： 多くの~keyboardは、 ~Unicode等価な記号があっても，通常は文字を生産しない~UIkeyを備えている。 例えば， `Shift^cap ~UIkeyには、 記号 `⇧^kGl （~Unicode符号位置 `21E7^U ）が付けられることもあるが， `Shift^cap ~UIkeyだけ押しても この`文字~値$を生産することはないし, `Shift^cap に対応する~Unicode符号位置もない。 ◎ Many keyboards contain keys that do not normally produce any characters, even though the symbol might have a Unicode equivalent. For example, the Shift key might bear the symbol "⇧", which has the Unicode code point U+21E7, but pressing the Shift key will not produce this character value, and there is no Unicode code point for Shift.
6.2. ~UIkey~code
~keyboard~eventに結付けられた物理的~UIkeyを識別するときは、 ~keyboard~eventの `code$m 属性で指示される~UIkey~codeを利用できる。 それは、 USB Usage ID に類似な, ~vendor中立な, 低~levelな（~scancodeに類似な）値を供する。 ◎ A key code is an attribute of a keyboard event that can be used to identify the physical key associated with the keyboard event. It is similar to USB Usage IDs in that it provides a low-level value (similar to a scancode) that is vendor-neutral.
`code$m 属性の首~目的は、 ~UIkeyを その物理的~所在に基づいて識別するための，首尾一貫する仕方を供することである。 加えて、 ~keyboardの各~UIkeyに（現在の~keyboard状態に影響されないような）安定的な名前も供して，それらを一意に識別する。 ◎ The primary purpose of the code attribute is to provide a consistent and coherent way to identify keys based on their physical location. In addition, it also provides a stable name (unaffected by the current keyboard state) that uniquely identifies each key on the keyboard.
妥当な `code^m 値たちが成す~listは、 `UIEvents-Code$r にて定義される。 ◎ The list of valid code values is defined in the [UIEvents-Code].
6.2.1. `code^m 属性の動機
標準的な~PC~keyboardが備えている一群の~UIkeyが生成する `key$m 値は、 利用者が現在~選択している（利用している書記体系に適切な）~keyboard~layoutにより異なる。 このような状況では、 ~UIkeyをその物理的~所在に基づいて検出するような~codeを書くことは困難になる — ~codeが，どの `key^m 値を検査すればよいか知るためには、 現在~有効な~layoutがどれなのかを知る必要があるので。 現実の例として、 ~player移動を制御するために［ `W^kGl, `A^kGl, `S^kGl, `D^kGl ］~UIkeyを利用する~gameがある。 `code$m 属性は、 それを検査するための，`現在の~keyboard~layoutに影響されない^em, 安定的な値を供して、 この問題を解消する。 ◎ The standard PC keyboard has a set of keys (which we refer to as writing system keys) that generate different key values based on the current keyboard layout selected by the user. This situation makes it difficult to write code that detects keys based on their physical location since the code would need to know which layout is in effect in order to know which key values to check for. A real-world example of this is a game that wants to use the "W", "A", "S" and "D" keys to control player movement. The code attribute solves this problem by providing a stable value to check that is not affected by the current keyboard layout.
加えて、 `key$m 属性がとる値は，現在の~keyboard状態にも依存する。 このため、 修飾~UIkeyと他の~UIkeyが［ 押される／離される ］順序も， `key$m 属性に格納される値に影響し得る。 `code$m 属性は、 `現在の~keyboard~layoutに影響されない^em, 安定的な値を供して、 この問題を解消する。 ◎ In addition, the values in the key attribute depend as well on the current keyboard state. Because of this, the order in which keys are pressed and released in relation to modifier keys can affect the values stored in the key attribute. The code attribute solves this problem by providing a stable value that is not affected by the current keyboard state.
6.2.2. `key^m と `code^m の関係性
- `key^m
- `key$m 属性に意図されている用途は、 押されている~UIkeyの意味に基づくふるまいを得ることである — その値には、 現在の~keyboard~layoutに加えて，~IMEも織り込まれる （`~dead-key＠#keys-dead$href には，一意な `key^m 値が与えられる）。 例えば、［ ~UIkeyが修飾~UIkeyを伴うかどうかや ~~素の修飾~UIkey ］を検出する利用事例がある （例：~keyboard~shortcutに呼応して何らかの動作を遂行するためなど）。 ◎ The key attribute is intended for users who are interested in the meaning of the key being pressed, taking into account the current keyboard layout (and IME; dead keys are given a unique key value). Example use case: Detecting modified keys or bare modifier keys (e.g., to perform an action in response to a keyboard shortcut).
- `code^m
- `code$m 属性に意図されている用途は、 利用者により押された~UIkeyそのもの — ~keyboard~layoutにより改変されないままの~UIkey — に基づくふるまいを得ることである。 例えば、 ~gameにおける移動~制御~用に［ `W^cap, `A^cap, `S^cap, `D^cap ］~UIkeyを検出したり、 すべての~UIkeyを~trapする （例： すべての~UIkeyを~remote~hostに送信する~remote~desktop~client） などの利用事例がある。 ◎ The code attribute is intended for users who are interested in the key that was pressed by the user, without any layout modifications applied. Example use case: Detecting WASD keys (e.g., for movement controls in a game) or trapping all keys (e.g., in a remote desktop client to send all keys to the remote host).
6.2.3. ~code例
左右 Alt ~UIkeyの取扱い： ◎ Handling the Left and Right Alt Keys
| Keyboard Layout | `key$m | `code$m | 備考 |
|---|---|---|---|
| US | `Alt$kY | `AltLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
| ~French | `Alt$kY | `AltLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
| US | `Alt$kY | `AltRight$kC | `DOM_KEY_LOCATION_RIGHT^m |
| ~French | `AltGraph$kY | `AltRight$kC | `DOM_KEY_LOCATION_RIGHT^m |
この例は、［ `key$m 属性を検査すれば，左右どちらの `Alt^cap ~UIkeyが押されたか気にせずに `Alt^cap と照合できる ］ことを示している。 `code$m 属性を検査すれば，現在~有効な~layoutが何かを気にすることなく 右 `Alt^cap ~UIkey（ `AltRight$kC ）と照合できるようになる。 ◎ In this example, checking the key attribute permits matching Alt without worrying about which Alt key (left or right) was pressed. Checking the code attribute permits matching the right Alt key ("AltRight") without worrying about which layout is currently in effect.
~Frenchの例では、［ `Alt^cap ／ `AltGraph^cap ］~UIkeyは どちらも 1 個しかないが，それらの［ 左／右 ］の所在は維持されることに注意。 ◎ Note that, in the French example, the Alt and AltGraph keys retain their left and right location, even though there is only one of each key.
Single Quote ~UIkeyの取扱い： ◎ Handling the Single Quote Key
| Keyboard Layout | `key$m | `code$m |
|---|---|---|
| US | `'^kY | `Quote$kC |
| 日本語 | `:^kY | `Quote$kC |
| US Intl | `Dead$kY | `Quote$kC |
この例は、 属性において，~dead-key値がどう符号化されるかを示している。 `key^m 値は，現在の~localeに基づいて様々になる一方、 `code$m 属性は，一貫した値を返す。 ◎ This example shows how dead key values are encoded in the attributes. The key values vary based on the current locale, whereas the code attribute returns a consistent value.
種々の~keyboard~layoutにおける `2^kGl ~UIkeyの取扱い （ Shift も押したとき／押さないとき）： ◎ Handling the "2" Key (with and without Shift pressed) on various keyboard layouts.
| Keyboard Layout | `key$m | `code$m | Shift の有無 |
|---|---|---|---|
| US | `2^kY | `Digit2$kC | |
| US | `~aT^kY | `Digit2$kC | `shiftKey$m |
| UK | `2^kY | `Digit2$kC | |
| UK | `"^kY | `Digit2$kC | `shiftKey$m |
| ~French | `é^kY | `Digit2$kC | |
| ~French | `2^kY | `Digit2$kC | `shiftKey$m |
現在の~localeや修飾~UIkey状態に関わらず， ~US~keyboardで~UIkey `2^kGl の~UIkeyを押したときの `code$m 属性の結果は、 常に `Digit2$kC になる。 ◎ Regardless of the current locale or the modifier key state, pressing the key labelled "2" on a US keyboard always results in "Digit2" in the code attribute.
~keyboard~event連列： `Shift^cap ＆ `2^cap ◎ Sequence of Keyboard Events : Shift and 2
次では、 2 つの~UIkey~event連列における属性~値を比較する。 それらは いずれも ~US~keyboardでは 文字 `~aT^kGl を生産するが、 ~UIkeyが離される順序により相違する。 最初の例の連列の順序は： `Shift^cap （押） → `2^cap （押） → `2^cap（離） → `Shift^cap（離）。 ◎ Compare the attribute values in the following two key event sequences. They both produce the "@" character on a US keyboard, but differ in the order in which the keys are released. In the first sequence, the order is: Shift (down), 2 (down), 2 (up), Shift (up).
| ~event型 | `key$m | `code$m | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `ShiftLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
| 2. | `keydown$et | `~aT^kY | `Digit2$kC | `shiftKey$m |
| 3. | `keypress$et | `~aT^kY | `Digit2$kC | （~support有りなら） |
| 4. | `keyup$et | `~aT^kY | `Digit2$kC | `shiftKey$m |
| 5. | `keyup$et | `Shift$kY | `ShiftLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
次の例の連列は、 2 を離すより先に Shift を離した場合： `Shift^cap（押） → `2^cap（押） → `Shift^cap（離） → `2^cap（離）。 ◎ In the second sequence, the Shift is released before the 2, resulting in the following event order: Shift (down), 2 (down), Shift (up), 2 (up).
| ~event型 | `key$m | `code$m | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `ShiftLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
| 2. | `keydown$et | `~aT^kY | `Digit2$kC | `shiftKey$m |
| 3. | `keypress$et | `~aT^kY | `Digit2$kC | （~support有りなら） |
| 4. | `keyup$et | `Shift$kY | `ShiftLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
| 5. | `keyup$et | `2^kY | `Digit2$kC |
~UIkey `2^kGl については、 `key$m 属性の値が `keydown$et ~eventと `keyup$et ~eventとの間で合致しないことに注意。 `code$m 属性は、 現在の修飾~状態に影響されず，一貫した値を供する。 ◎ Note that the values contained in the key attribute does not match between the keydown and keyup events for the "2" key. The code attribute provides a consistent value that is not affected by the current modifier state.
6.2.4. `code^m と仮想~keyboard
`code$m 属性の有用性は、 仮想~keyboardに対しては明白でない （~remote-control~keyboardや複数~UIkeyの同時押下げに対しても）。 仮想（または~remote-control）~keyboardに対しては、 標準的な~keyboardの ~layout／機能性 を真似ているものについては， `code$m 属性を適切に設定するモノトスル。 真似ていない~keyboardについては、 標準的な~keyboardになるべく近いものに設定するか, または 未定義なままにしてもヨイ。 ◎ The usefulness of the code attribute is less obvious for virtual keyboards (and also for remote controls and chording keyboards). In general, if a virtual (or remote control) keyboard is mimicking the layout and functionality of a standard keyboard, then it MUST also set the code attribute as appropriate. For keyboards which are not mimicking the layout of a standard keyboard, then the code attribute MAY be set to the closest match on a standard keyboard or it MAY be left undefined.
修飾~状態に基づいて異なる値を生産する~UIkeyを伴うような仮想~keyboardに対しては、 `code^m 値は，［ 装置がその工場出荷~状態にある下で~buttonが押された ］ときに生成される `key^m 値になるベキである。 ◎ For virtual keyboards with keys that produce different values based on some modifier state, the code value should be the key value generated when the button is pressed while the device is in its factory-reset state.
6.3. ~keyboard~eventの `key^m 値
`~UIkey値$は、 ~keyboard上の任意の~UIkeyを — その位置や状態に関わらず — それが生産する値で指示するために利用できる `DOMString^I である。 これらの~UIkey値は、 次に挙げるものに利用できる／され得る：
- 実装により生成される~keyboard~event用の返り値
- 内容~作者から欲される入力（~keyboard~shortcutなど）を指定するための入力~値
妥当な `key^m 値たちが成す~listは `UIEvents-Key$r にて定義される。 ◎ The list of valid key values is defined in [UIEvents-Key].
`~UIkey値$は、 `key$m 属性を利用して，押された~UIkeyの値を検出するときに利用される値である。 内容~作者は、［ 大文字や小文字, 数字n, 記号 ］その他，文字を生産する~UIkeyに対しては その`文字~値$を検索取得でき、［ 制御~UIkey, 修飾~UIkey, ~function~UIkey ］その他，文字を生産しない~UIkeyに対しては その`~UIkey値$を検索取得できる。 これらの値は、［ 特定0の入力~文字列を監視する ／ 他の入力（~mouseなど）との組合nで 修飾~UIkey入力を検出して動作する ／ 仮想~keyboardを作成する ］その他，いくつもの目的に利用できる。 ◎ Key values can be used to detect the value of a key which has been pressed, using the key attribute. Content authors can retrieve the character value of upper- or lower-case letters, number, symbols, or other character-producing keys, and also the key value of control keys, modifier keys, function keys, or other keys that do not generate characters. These values can be used for monitoring particular input strings, for detecting and acting on modifier key input in combination with other inputs (such as a mouse), for creating virtual keyboards, or for any number of other purposes.
内容~作者は、 `~UIkey値$を文字列~比較にも利用できる — 適合`~host言語$における~markup属性~用の値（~HTMLの `accesskey^a など）として, あるいは 他の関係する目的に。 適合`~host言語$は、 内容~作者が，`~UIkey値$用の 2 つの等価な文字列~値：［ `文字~値$ または `~UIkey値$ ］のいずれも利用できるようにするベキである。 ◎ Key values can also be used by content authors in string comparisons, as values for markup attributes (such as the HTML accesskey) in conforming host languages, or for other related purposes. A conforming host language SHOULD allow content authors to use either of the two equivalent string values for a key value: the character value, or the key value.
注記： 実装は、［ ~UIkeyに対し，~platformや~keyboard~layout~mappingから独立に，最も関連な値を利用する ］ことになる一方、 内容~作者は，それらを生成する~keyboard装置の能について前提を置けない。 内容~作者は、 ~shortcut~UIkeyの組合nとして~keyboard~eventと~UIkey値を利用するときには，普通字の代わりに 数字n~UIkey, ~function~UIkey（ `F4^cap, `F5^cap, 等々）の利用も考慮できる（ `DWW95$r ） — ほとんどの~keyboard~layoutは，それら用の~UIkeyを供するので。 ◎ While implementations will use the most relevant value for a key independently of the platform or keyboard layout mappings, content authors can not make assumptions on the ability of keyboard devices to generate them. When using keyboard events and key values for shortcut-key combinations, content authors can "consider using numbers and function keys (F4, F5, and so on) instead of letters" ([DWW95]) given that most keyboard layouts will provide keys for those.
`~UIkey値$は、 物理的~keyboard上の特定の~UIkeyを指示するものでも， ~UIkey上に印刷された文字を反映するものでもない。 ~UIkey値は、 作動中な［ ~UIkeyすべて／~UIkey入力~mode（~shift~modeを含む）の現在の状態 ］が考慮に入れられ，~OSによる~keyboard~mappingに反映され, 実装に報告されるような，~eventの現在の値を指示する。 例えば、［ `QWERTY$ ~keyboardの `O^cap ~UIkey ］の~UIkey値は，［ ~shiftなしなら `o^kY ／ ~shiftありなら `O^kY ］になる。 利用者は，自身の~keyboardを任意な~custom環境設定に~mapできるので、 内容~作者には，［ ~UIkeyの~shiftの有無と, 文字~表現の［ 大文字形, 小文字形 ］との間に関係性が存在する ］ものと見做すことなく， `key$m 属性の値を利用することが奨励される。 例えば、 `D3E-code$r にて図面化されている標準的な “102 ~keyboard” ~layoutは、 アリな~keyboard~layoutにおける，`~UIkey~mapping$の集合としてアリな一つを図示する。 他にも、 標準なもの, 独特なものが多数 存在する。 ◎ A key value does not indicate a specific key on the physical keyboard, nor does it reflect the character printed on the key. A key value indicates the current value of the event with consideration to the current state of all active keys and key input modes (including shift modes), as reflected in the operating-system mapping of the keyboard and reported to the implementation. In other words, the key value for the key labeled O on a QWERTY keyboard has the key value "o" in an unshifted state and "O" in a shifted state. Because a user can map their keyboard to an arbitrary custom configuration, the content author is encouraged not to assume that a relationship exists between the shifted and unshifted states of a key and the majuscule form (uppercase or capital letters) and minuscule form (lowercase or small letters) of a character representation, but is encouraged instead to use the value of the key attribute. For example, the Standard "102" Keyboard layout depicted in [UIEvents-Code] illustrates one possible set of key mappings on one possible keyboard layout. Many others exist, both standard and idiosyncratic.
注記： `~dead-key$用の~supportを単純~化するため、［ ~keyboardの~OS~mappingが`~dead-key$状態を取扱うときの，~dead-key連列の現在の状態 ］は、 `key$m 属性を介しては報告されず，代わりに`~UIkey値$ `Dead$kY が報告される。 実装は、 代わりに［ ~dead-key連列の中間的な状態を包含する，一連の`組成~event$ ］を生成して，それを `CompositionEvent.data$m 属性を介して報告する。 前掲の例と同様に，［ `QWERTY$ ~keyboardの `O^cap と印字された~UIkey用の`~UIkey値$には， ~dead-key操作oの最中に~umlaut発音区別符が追加される ］ので、 `CompositionEvent.data$m 値は， ~shiftなしなら `ö^kGl になり, ~shiftありなら `Ö^kGl になる。 ◎ To simplify dead key support, when the operating-system mapping of the keyboard is handling a dead key state, the current state of the dead key sequence is not reported via the key attribute. Rather, a key value of "Dead" is reported. Instead, implementations generate composition events which contain the intermediate state of the dead key sequence reported via the data attribute. As in the previous example, the key value for the key marked O on a QWERTY keyboard has a data value of "ö" in an unshifted state during a dead-key operation to add an umlaut diacritic, and "Ö" in a shifted state during a dead-key operation to add an umlaut diacritic.
また、 ~UIkey~eventの各~状態と各`~UIkey値$との間には， 一対一の関係性はないことにも特に注意。 複数の~UIkeyが特定0の~UIkey値に結付けられることもある。 例えば，多くの標準的な~keyboardは、 `Shift^cap ~UIkeyや `8^cap ~UIkeyを複数~備えている （通常は、 いずれも `location$m 値で判別される — 前者は［ `DOM_KEY_LOCATION_LEFT$m ／ `DOM_KEY_LOCATION_RIGHT$m ］で，後者は［ `DOM_KEY_LOCATION_STANDARD$m ／ `DOM_KEY_LOCATION_NUMPAD$m ］で）。 また，利用者により環境設定された~custom~keyboard~layoutは、 どの~UIkey値にも複数の~UIkey状態が対応~付けられ得る （ `location$m は、 標準的な~keyboard~layout~~用途に意図されていることに注意 — 有意義な~~区別を常に指示できるわけではない）。 ◎ It is also important to note that there is not a one-to-one relationship between key event states and key values. A particular key value might be associated with multiple keys. For example, many standard keyboards contain more than one key with the Shift key value (normally distinguished by the location values DOM_KEY_LOCATION_LEFT and DOM_KEY_LOCATION_RIGHT) or 8 key value (normally distinguished by the location values DOM_KEY_LOCATION_STANDARD and DOM_KEY_LOCATION_NUMPAD), and user-configured custom keyboard layouts MAY duplicate any key value in multiple key-state scenarios (note that location is intended for standard keyboard layouts, and cannot always indicate a meaningful distinction).
~~最後に、 与えられた文字~表現の意味は，文脈に依存する上に複階的である。 例えば，一部の文脈では、 ~asterisk~glyph（ `*^kGl ）は，脚注や強勢を表現する （~textの一節を~~括るとき）。 しかしながら，それ／その機能は、 文書や実行-可能~programによっては， 数学的な乗算に等価であったり, 乗算~記号として予約されていたり（ `×^kGl, ~Unicode `00D7^U ）, ~~英小文字 "x" （ `Latin small letter x^cn ）のこともある （多くの~keyboardが乗算~UIkeyを欠くこと，あるいは `×^kGl と `x^kGl のような~glyphの~~外見上の~~類似に因り）。 したがって、 意味論上の意味や, 文字~表現の機能は，この仕様の視野から外れる。 ◎ Finally, the meaning of any given character representation is context-dependent and complex. For example, in some contexts, the asterisk (star) glyph ("*") represents a footnote or emphasis (when bracketing a passage of text). However, in some documents or executable programs it is equivalent to the mathematical multiplication operation, while in other documents or executable programs, that function is reserved for the multiplication symbol ("×", Unicode value U+00D7) or the Latin small letter "x" (due to the lack of a multiplication key on many keyboards and the superficial resemblance of the glyphs "×" and "x"). Thus, the semantic meaning or function of character representations is outside the scope of this specification.
6.3.1. 修飾~UIkey
修飾~UIkeyを利用する~keyboard入力は、 ~UIkeyの通常の挙動を変化させる。 他の~UIkeyと同様、 修飾~UIkeyは，下の例に示すように `keydown$et ／ `keyup$et ~eventを生成する。 修飾~UIkeyには、 押されている間 作動化されるものもあれば （ `Alt^cap, `Control^cap, `Shift^cap, `AltGraph^cap, `Meta^cap など）、 状態を持ち，その状態に依存して作動化されるものもある （ `CapsLock^cap, `NumLock^cap, `ScrollLock^cap など）。 状態の変化は、 修飾~UIkeyが押されたときに起こる。 `KeyboardEvent!I ~interfaceは、 一部の共通的な修飾~UIkeyに対し，簡便な属性 — `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m — を供する。 一部の~OSは、 修飾~UIkey `AltGraph^cap を，修飾~UIkey `Alt^cap, `Control^cap の組合nで模造する。 実装には、 `AltGraph^cap 修飾~UIkeyを利用することが奨励される。 ◎ Keyboard input uses modifier keys to change the normal behavior of a key. Like other keys, modifier keys generate keydown and keyup events, as shown in the example below. Some modifiers are activated while the key is being pressed down or maintained pressed such as Alt, Control, Shift, AltGraph, or Meta. Other modifiers are activated depending on their state such as CapsLock, NumLock, or ScrollLock. Change in the state happens when the modifier key is being pressed down. The KeyboardEvent interface provides convenient attributes for some common modifiers keys: ctrlKey, shiftKey, altKey, metaKey. Some operating systems simulate the AltGraph modifier key with the combination of the Alt and Control modifier keys. Implementations are encouraged to use the AltGraph modifier key.
次の例に、 ~US~keyboardで, ~US~mappingを利用している下で， ~Unicode文字 Q（ `0051^U `Latin Capital Letter Q^cn ） が生成されるときにアリな~event連列を述べる： ◎ This example describes a possible sequence of events associated with the generation of the Unicode character Q (Latin Capital Letter Q, Unicode code point U+0051) on a US keyboard using a US mapping:
| ~event型 | `key$m | 修飾 | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `shiftKey$m | |
| 2. | `keydown$et | `Q^kY | `shiftKey$m | `Latin Capital Letter Q^cn |
| 3. | `beforeinput$et | |||
| 4. | `input$et | |||
| 5. | `keyup$et | `Q^kY | `shiftKey$m | |
| 6. | `keyup$et | `Shift$kY |
次の例に、 上の例において， `Q^cap ~UIkeyを離す前に `Shift^cap ~UIkeyを離したとき， 代わりに生じ得る~UIkey連列を述べる。 ~UIkey `Q^cap 用の`~UIkey値$は、 `keyup$et ~eventに対しては，その無shift値に復帰することになる： ◎ Th example describes an alternate sequence of keys to the example above, where the Shift key is released before the Q key. The key value for the Q key will revert to its unshifted value for the keyup event:
| ~event型 | `key$m | 修飾 | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `shiftKey$m | |
| 2. | `keydown$et | `Q^kY | `shiftKey$m | `Latin Capital Letter Q^cn |
| 3. | `beforeinput$et | |||
| 4. | `input$et | |||
| 5. | `keyup$et | `Shift$kY | ||
| 6. | `keyup$et | `q^kY | `Latin Small Letter Q^cn |
次の例に、 ~Unicode文字を生成しないときにアリな~UIkeyの連列を述べる （前の例と同じ環境設定の下で）: ◎ The following example describes a possible sequence of keys that does not generate a Unicode character (using the same configuration as the previous example):
| ~event型 | `key$m | 修飾 | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Control$kY | `ctrlKey$m | |
| 2. | `keydown$et | `v^kY | `ctrlKey$m | `Latin Small Letter V^cn |
| `beforeinput$et／`input$et ~eventは生成されない。 ◎ No beforeinput or input events are generated. | ||||
| 3. | `keyup$et | `v^kY | `ctrlKey$m | `Latin Small Letter V^cn |
| 4. | `keyup$et | `Control$kY | ||
次の例に， `Shift^cap, `Control^cap が両者とも押されたときの~event連列を示す： ◎ The following example shows the sequence of events when both Shift and Control are pressed:
| ~event型 | `key$m | 修飾 | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Control$kY | `ctrlKey$m | |
| 2. | `keydown$et | `Shift$kY | `ctrlKey$m, `shiftKey$m | |
| 3. | `keydown$et | `V^kY | `ctrlKey$m, `shiftKey$m | `Latin Capital Letter V^cn |
| 【！複製】 `beforeinput$et／`input$et ~eventは生成されない。 ◎ No beforeinput or input events are generated. | ||||
| 4. | `keyup$et | `V^kY | `ctrlKey$m, `shiftKey$m | `Latin Capital Letter V^cn |
| 5. | `keyup$et | `Shift$kY | `ctrlKey$m | |
| 6. | `keyup$et | `Control$kY | ||
非~US~keyboard~layoutに対しても，~event連列は同じになるが、 ~UIkeyの値は，現在の~keyboard~layoutに基づく。 次の例に，~Arabic~keyboard~layoutが利用されるときの~event連列を示す： ◎ For non-US keyboard layouts, the sequence of events is the same, but the value of the key is based on the current keyboard layout. This example shows a sequence of events when an Arabic keyboard layout is used:
| ~event型 | `key$m | 修飾 | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Control$kY | `ctrlKey$m | |
| 2. | `keydown$et | `ر^kY | `ctrlKey$m | `Arabic Letter Reh^cn |
| 【！複製】 `beforeinput$et／`input$et ~eventは生成されない。 ◎ No beforeinput or input events are generated. | ||||
| 3. | `keyup$et | `ر^kY | `ctrlKey$m | `Arabic Letter Reh^cn |
| 4. | `keyup$et | `Control$kY | ||
注記： ［ `keydown$et ／ `keyup$et ］~eventにおける値は、 ~UIkeyが押されたときに有効な現在の~keyboard~layoutに基づいて，様々になる。 これは、 同じ物理的~UIkeyであっても、 ~US~layout上の `v^cap ~UIkey と ~Arabic~layout上の `ر^cap ~UIkeyとでは， 異なる~eventを生成することを意味する。 これらの~eventを同じ物理的~UIkeyとして識別するためには、 `code$m 属性を利用する必要がある。 ◎ The value in the keydown and keyup events varies based on the current keyboard layout in effect when the key is pressed. This means that the v key on a US layout and the ر key on an Arabic layout will generate different events even though they are the same physical key. To identify these events as coming from the same physical key, you will need to make use of the code attribute.
修飾~UIkeyが，~UIkey~event用の`~UIkey値$を変化させる事例もある。 例えば，一部の MacOS ~keyboard上の “delete” ~UIkeyは、 未修飾~時にはWindows ~OS上の `Backspace^cap ~UIkeyと同じに機能するが、 `Fn^cap ~UIkeyで修飾されたときは `Delete^cap ~UIkeyとして動作し， ~UIkey値は 現在の修飾された状態に最も適切な~UIkeyの機能に合致することになる。 ◎ In some cases, modifier keys change the key value for a key event. For example, on some MacOS keyboards, the key labeled "delete" functions the same as the Backspace key on the Windows OS when unmodified, but when modified by the Fn key, acts as the Delete key, and the value of key will match the most appropriate function of the key in its current modified state.
6.3.2. ~dead-key
~keyboard入力では、 `~dead-key$を利用して組成-済み文字~連列を入力することもある。 手書き式に最初に基底~文字を手入力するのでなく、 そこでの~keyboard入力には，特別な状態に入ることが要求され、 `~dead-key$が押された~~直後では，限られた数の “合法な” 基底~文字が手入力されたときに限り，文字（たち）を発する。 ◎ Some keyboard input uses dead keys for the input of composed character sequences. Unlike the handwriting sequence, in which users enter the base character first, keyboard input requires to enter a special state when a dead key is pressed and emit the character(s) only when one of a limited number of "legal" base character is entered.
注記： ［ MacOS ／ Linux ~OS ］は、 `~dead-key$を処理するときに~IMEを利用する。 ◎ The MacOS and Linux operating systems use input methods to process dead keys.
（すべての~keyboard~layout, および~mappingに渡り，）`~dead-key$は、 `~UIkey値$ `Dead$kY で表現される。 ~dead-keyが押されたときは、 ~UAは それに呼応して，`組成~event$たちを発火するモノトスル。 加えて、 その `compositionupdate$et ~eventの `CompositionEvent.data$m 値は，~dead-key結合~連列の現在の状態の`文字~値$になるモノトスル。 ◎ The dead keys (across all keyboard layouts and mappings) are represented by the key value Dead. In response to any dead key press, composition events must be dispatched by the user agent and the compositionupdate event’s data value must be the character value of the current state of the dead key combining sequence.
~Unicode結合~文字は，常に［ 対応する普通字とそれに続く結合~文字による手書き連列 ］に倣う一方で、 代表的な~dead-key入力では，その結合~文字が対応する普通字の前に来るように 連列を逆順にすることもある。 例えば，単語 "naïve" は、 結合~発音区別符 "¨" を利用して，~Unicodeでは "nai¨ve" として連列的に表現されるが、 "na¨ive" と打込まれ得る。 ~keystroke連列［ `0302^U （ `Combining Circumflex Accent^cn ~UIkey）, `0065^U （ `Latin Small Letter E^cn と印字される~UIkey） ］は，［ `NFC^em （ `Unicode Normalization Form^en ）に選好される ~Unicode文字 `ê^kGl （ `Latin Small Letter E With Circumflex^cn ） ］を生産するであろう （~French~keyboardでは、 修飾~UIkeyを作動化させずに，~French~mappingを利用して）。 ◎ While Unicode combining characters always follow the handwriting sequence, with the combining character trailing the corresponding letter, typical dead key input MAY reverse the sequence, with the combining character before the corresponding letter. For example, the word naïve, using the combining diacritic ¨, would be represented sequentially in Unicode as nai¨ve, but MAY be typed na¨ive. The sequence of keystrokes U+0302 (Combining Circumflex Accent key) and U+0065 (key marked with the Latin Small Letter E) will likely produce (on a French keyboard using a french mapping and without any modifier activated) the Unicode character "ê" (Latin Small Letter E With Circumflex), as preferred by the Unicode Normalization Form NFC.
| ~event型 | `key$m | `isComposing$m | `CompositionEvent.data$m | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `Dead$kY | ~F | `Combining Circumflex Accent^cn （~dead-key） | |
| 2. | `compositionstart$et | `^kGl | |||
| 3. | `compositionupdate$et | `0302^U | |||
| 4. | `keyup$et | `Dead$kY | ~T | ||
| 5. | `keydown$et | `ê^kY | ~T | ||
| 6. | `compositionupdate$et | `ê^kGl | |||
| 7. | `compositionend$et | `ê^kGl | |||
| 8. | `keyup$et | `e^kY | ~F | `Latin Small Letter E^cn |
注記： 2 個目の `keydown^c ~event（段 5）では、 （~eventは抑止されていないとするとき，） 通常の状況下では`~UIkey値$ `e^kY （ `Latin Small Letter E^cn ~UIkey）`にはならない^em — ~UAに送達される値は、 すでに~dead-key操作oにより修飾されることになるので。 ◎ In the second keydown event (step 5), the key value (assuming the event is not suppressed) will not be "e" (Latin Small Letter E key) under normal circumstances because the value delivered to the user agent will already be modified by the dead key operation.
この処理nは、 利用者が［ `~dead-key$を押した後に， ~supportされない基底~文字 （すなわち，作動中な発音区別符号が可用でない基底~文字） を打込んだとき ］には，中止され得る： ◎ This process might be aborted when a user types an unsupported base character (that is, a base character for which the active diacritical mark is not available) after pressing a dead key:
| ~event型 | `key$m | `isComposing$m | `CompositionEvent.data$m | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `Dead$kY | ~F | `Combining Circumflex Accent^cn （~dead-key） | |
| 2. | `compositionstart$et | `^kGl | |||
| 3. | `compositionupdate$et | `0302^U | |||
| 4. | `keyup$et | `Dead$kY | ~T | ||
| 5. | `keydown$et | `q^kY | ~T | `Latin Small Letter Q^cn | |
| 6. | `compositionupdate$et | `^kGl | |||
| 7. | `compositionend$et | `^kGl | |||
| 8. | `keyup$et | `q^kY | ~F |
6.3.3. ~IME（ `Input Method Editors^en ）
この仕様は、 `CompositionEvent$I ~interface＆~event を通して，`~IME$（ `Input Method Editor^en ）用の~modelを含めている。 しかしながら、 `組成~event$と`~keyboard~event$を一対一に対応付けるとは限らない。 例として、 `~UIkey値$ `Accept^cap を伴う `keydown$et を受取ったとしても，それは、 `~IME$において現在~選択された~textが受容されたことを含意するとは限らず，~keystrokeが起きたことのみを指示する — 受容されている`~IME$の機能性からは切離されて （それは、 ほとんどの`~IME$~systemにおいては， 通常は `compositionend$et ~eventを生じさせることになるが）。 ~keyboard~eventは、 ~IMEの現在の状態を決定する用途には，利用できない — その状態は `CompositionEvent.data$m 属性を通して得することができる。 加えて、 `~IME$~systemや装置の機能性は様々であり、 その機能性を作動化するために，どの~UIkey — `Convert^cap ／ `Accept^cap ~UIkeyなど — が利用されているかは、 他の可用な~UIkeyにより表現されることもある。 ~keyboard~eventは、 ~keyboard~layout~mappingの後に，入力~装置により生成された~eventに対応する。 ◎ This specification includes a model for input method editors (IMEs), through the CompositionEvent interface and events. However, Composition Events and Keyboard Events do not necessarily map as a one-to-one relationship. As an example, receiving a keydown for the Accept key value does not necessarily imply that the text currently selected in the IME is being accepted, but indicates only that a keystroke happened, disconnected from the IME Accept functionality (which would normally result in a compositionend event in most IME systems). Keyboard events cannot be used to determine the current state of the input method editor, which can be obtained through the data attribute of the CompositionEvent interface. Additionally, IME systems and devices vary in their functionality, and in which keys are used for activating that functionality, such that the Convert and Accept keys MAY be represented by other available keys. Keyboard events correspond to the events generated by the input device after the keyboard layout mapping.
注記： 一部の実装／~system環境設定においては、 一部の~UIkey~eventやその値は，利用-中な`~IME$により抑止されることがある。 ◎ In some implementations or system configurations, some key events, or their values, might be suppressed by the IME in use.
次の例に、 日本語~IMEを利用して， ~Unicode文字 `~~市^kGl （ `CJK Unified Ideographs^en の一部である漢字 ） が生成されるときにアリな~UIkey連列を述べる。 この例では、 ~IMEは作動化されていて，日本語~Romaji入力~mode下にあるとする。 ~UIkey `Convert^cap （ “~~変換” ）／ `Accept^cap （ “~~確定” ） は、 利用-中な入力~装置や~IMEの環境設定に依存して，他に置換されることもある — 例えば `~SPACEBAR^cap （ `0020^U ）／ `Enter^cap にもなり得る。 ◎ The following example describes a possible sequence of keys to generate the Unicode character "市" (Kanji character, part of CJK Unified Ideographs) using Japanese input methods. This example assumes that the input method editor is activated and in the Japanese-Romaji input mode. The keys Convert and Accept MAY be replaced by others depending on the input device in use and the configuration of the IME, e.g., it can be respectively U+0020 (Space key) and Enter.
注記： `~~詩^kGl と `~~市^kGl は異形同音異義語であり， いずれも “し” と発音されるので、 利用者は， `Convert^cap ~UIkeyを利用して 適正な選択肢を選択する必要がある。 ◎ "詩" ("poem") and "市" ("city") are homophones, both pronounced し ("shi"/"si"), so the user needs to use the Convert key to select the proper option.
| ~event型 | `key$m | `isComposing$m | `CompositionEvent.data$m | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `s^kY | ~F | `Latin Small Letter S^cn | |
| 2. | `compositionstart$et | `^kGl | |||
| 3. | `beforeinput$et | ||||
| 4. | `compositionupdate$et | `s^kGl | |||
| ~DOMは更新された ◎ DOM is updated | |||||
| 5. | `input$et | ||||
| 6. | `keyup$et | `s^kY | ~T | ||
| 7. | `keydown$et | `i^kY | ~T | `Latin Small Letter I^cn | |
| 8. | `beforeinput$et | ||||
| 9. | `compositionupdate$et | `し^kGl | ◎ shi | ||
| ~DOMは更新された ◎ DOM is updated | |||||
| 10. | `input$et | ||||
| 11. | `keyup$et | `i^kY | ~T | ||
| 12. | `keydown$et | `Convert$kY | ~T | “~~変換” ◎ Convert | |
| 13. | `beforeinput$et | ||||
| 14. | `compositionupdate$et | `詩^kGl | ◎ "poem" | ||
| ~DOMは更新された ◎ DOM is updated | |||||
| 15. | `input$et | ||||
| 16. | `keyup$et | `Convert$kY | ~T | ||
| 17. | `keydown$et | `Convert$kY | ~T | “~~変換” ◎ Convert | |
| 18. | `beforeinput$et | ||||
| 19. | `compositionupdate$et | `市^kGl | ◎ "city" | ||
| ~DOMは更新された ◎ DOM is updated | |||||
| 20. | `input$et | ||||
| 21. | `keyup$et | `Convert$kY | ~T | ||
| 22. | `keydown$et | `Accept$kY | ~T | “~~確定” ◎ Accept | |
| 23. | `compositionend$et | `市^kGl | |||
| 24. | `keyup$et | `Accept$kY | ~F |
~IME組成は、 前掲の例と一致する条件で，次の例のように取消され得る。 ~UIkey `Cancel^cap も利用-中な入力~装置や~IMEの環境設定に依存して，他に置換され得る — 例えば `001B^U （ `Escape^cap ~UIkey ）にもなり得る。 ◎ IME composition can also be canceled as in the following example, with conditions identical to the previous example. The key 'Cancel' might also be replaced by others depending on the input device in use and the configuration of the IME, e.g., it could be U+001B (Escape key).
| ~event型 | `key$m | `isComposing$m | `CompositionEvent.data$m | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `s^kY | ~F | `Latin Small Letter S^cn | |
| 2. | `compositionstart$et | `^kGl | |||
| 3. | `compositionupdate$et | `s^kGl | |||
| 4. | `keyup$et | `s^kY | ~T | ||
| 5. | `keydown$et | `i^kY | ~T | `Latin Small Letter I^cn | |
| 6. | `compositionupdate$et | `し^kGl | |||
| 7. | `keyup$et | `i^kY | ~T | ||
| 8. | `keydown$et | `Convert$kY | ~T | “~~変換” ◎ Convert | |
| 9. | `compositionupdate$et | `詩^kGl | |||
| 10. | `keyup$et | `Convert$kY | ~T | ||
| 11. | `keydown$et | `Convert$kY | ~T | “~~変換” ◎ Convert | |
| 12. | `compositionupdate$et | `市^kGl | |||
| 13. | `keyup$et | `Convert$kY | ~T | ||
| 14. | `keydown$et | `Cancel$kY | ~T | “~~取消” ◎ Cancel | |
| 15. | `compositionupdate$et | `^kGl | |||
| 16. | `compositionend$et | `^kGl | |||
| 17. | `keyup$et | `Cancel$kY | ~F |
注記： `~IME$（ MacOS ~OS上など）によっては、 組成を取消す前に組成~data属性に`空~文字列$を設定するものもある。 ◎ Some input method editors (such as on the MacOS operating system) might set an empty string to the composition data attribute before canceling a composition.
6.3.3.1. ~IME~mode~UIkey
ある種の装置では、 一部の~UIkeyに，［ `~IME$を作動化したり, 作動中な`~IME$の~modeを変更する ］ような機能性が意図されている。 これを目的とする~UIkeyは、 装置や言語~modeごとに異なるものが定義され得る。 この仕様では、 次に挙げるものが，これを目的とする~UIkeyとして定義される ⇒＃ `Alphanumeric$kY, `CodeInput$kY, `FinalMode$kY, `HangulMode$kY, `HanjaMode$kY, `Hiragana$kY, `JunjaMode$kY, `KanaMode$kY, `KanjiMode$kY, `Katakana$kY, `Romaji$kY ◎ Some keys on certain devices are intended to activate input method editor functionality, or to change the mode of an active input method editor. Custom keys for this purpose can be defined for different devices or language modes. The keys defined in this specification for this purpose are: "Alphanumeric", "CodeInput", "FinalMode", "HangulMode", "HanjaMode", "Hiragana", "JunjaMode", "KanaMode", "KanjiMode", "Katakana", and "Romaji".＼
`~IME$が作動中でない下で，これらいずれかの~UIkeyが押されたときは、 （可用なら）適切な`~IME$が，~UIkeyにより指示される~modeで作動化されるものと期待される。 ~UIkeyが押されたとき，`~IME$がすでに作動中である場合、［ 装置／~app ］に特有なふるまいに基づいて，`~IME$が 指示された~modeへ変更されたり, 異なる`~IME$が立上げられたり, あるいは無視されることもある。 ◎ When one of these keys is pressed, and no IME is currently active, the appropriate IME is expected to be activated in the mode indicated by the key (if available). If an IME is already active when the key is pressed, the active IME might change to the indicated mode, or a different IME might be launched, or the might MAY be ignored, on a device- and application-specific basis.
この仕様は、 他の~UIkey — 特定的には、 次に挙げる`~IME$に意図される操作o用の~UIkey — も定義する ⇒＃ `Accept$kY, `AllCandidates$kY, `Cancel$kY, `Convert$kY, `Compose$kY, `Zenkaku$kY （ `FullWidth^en ）, `Hankaku$kY （ `HalfWidth^en ）, `NextCandidate$kY, `NonConvert$kY, `PreviousCandidate$kY ◎ This specification also defines other keys which are intended for operation specifically with input method editors: "Accept", "AllCandidates", "Cancel", "Convert", "Compose", "Zenkaku" (FullWidth), "Hankaku" (HalfWidth), "NextCandidate", "NonConvert", and "PreviousCandidate".＼
これらの~UIkeyの機能は、 この仕様では定義されない — `~IME$機能性についての詳細は、 他の資料を見よ。 ◎ The functions of these keys are not defined in this specification — refer to other resources for details on input method editor functionality.
注記： `~IME$機能を伴う~UIkeyは、 その目的に制約されず，他の装置や実装に特有な目的を持つこともある。 ◎ Keys with input method editor functions are not restricted to that purpose, and can have other device- or implementation-specific purposes.
6.3.4. 既定~動作と取消~可能~keyboard~event
`keydown$et ~eventの`既定~動作$が取消されたときは， それと対を成す `keyup$et ~eventには影響しないモノトスルが、 それに対応する［ `beforeinput$et ／ `input$et ／（~support有りなら） `keypress$et ］~eventは生成しないようにするモノトスル。 次の例に、 ~US~keyboardで, ~US~mappingを利用している下で， ~Unicode文字 Q（ `Latin Capital Letter Q^cn ） が生成されるときにアリな~UIkey連列を述べる： ◎ Canceling the default action of a keydown event MUST NOT affect its respective keyup event, but it MUST prevent the respective beforeinput and input (and keypress if supported) events from being generated. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a US keyboard using a US mapping:
| ~event型 | `key$m | `InputEvent.data$m | 修飾 | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `shiftKey$m | ||
| 2. | `keydown$et | `Q^kY | `shiftKey$m | 【！複製】 `既定~動作$は、 例えば `preventDefault()$m の呼出ngにより，防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). | |
| ［ `beforeinput$et／`input$et ］~event, および（~supportされるなら）`keypress$et ~eventは、 生成されない ◎ No beforeinput or input (or keypress, if supported) events are generated | |||||
| 3. | `keyup$et | `Q^kY | `shiftKey$m | ||
| 4. | `keyup$et | `Shift$kY |
~UIkeyが修飾~UIkeyであった場合、 ~keystrokeは，依然として修飾~状態に織り込むモノトスル。 次の例に、 ~US~keyboardで, ~US~mappingを利用している下で， ~Unicode文字 Q（ `Latin Capital Letter Q^cn ） が生成されるときにアリな連列を述べる： ◎ If the key is a modifier key, the keystroke MUST still be taken into account for the modifiers states. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a US keyboard using a US mapping:
| ~event型 | `key$m | `InputEvent.data$m | 修飾 | 備考 | |
|---|---|---|---|---|---|
| 1. | `keydown$et | `Shift$kY | `shiftKey$m | 【！複製】 `既定~動作$は、 例えば `preventDefault()$m の呼出ngにより，防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). | |
| 2. | `keydown$et | `Q^kY | `shiftKey$m | ||
| 3. | `beforeinput$et | `Q^kGl | |||
| 4. | `input$et | ||||
| 5. | `keyup$et | `Q^kY | `shiftKey$m | ||
| 6. | `keyup$et | `Shift$kY |
~UIkeyが何回かの~keystrokeからなる連列の一部を成す場合， それが`~dead-key$であれ, ~IME連列に寄与しているものであれ、 その~keystrokeは， `keydown$et ~event上で`既定~動作$が取消された場合に限り，無視するモノトスル （織り込まれない）。 `~dead-key$による`keyup$et ~eventを取消しても， `beforeinput$et ／ `input$et ~eventには効果がない。 次の例に、 ~French~keyboardで, ~French~mappingを利用し，どの修飾も作動化されない下で、［ ~dead-key `Dead$kY （ `0302^U `Combining Circumflex Accent^cn ~UIkey） ］, ［ `e^kY ~UIkey（ `0065^U `Latin Small Letter E^cn ~UIkey） ］を利用したときに生じる~event連列を示す： ◎ If the key is part of a sequence of several keystrokes, whether it is a dead key or it is contributing to an Input Method Editor sequence, the keystroke MUST be ignored (not taken into account) only if the default action is canceled on the keydown event. Canceling a dead key on a keyup event has no effect on beforeinput or input events. The following example uses the dead key "Dead" (U+0302 Combining Circumflex Accent key) and "e" (U+0065, Latin Small Letter E key) on a French keyboard using a French mapping and without any modifier activated:
| ~event型 | `key$m | `InputEvent.data$m | 備考 | |
|---|---|---|---|---|
| 1. | `keydown$et | `Dead$kY | 【！複製】 `既定~動作$は、 例えば `preventDefault()$m の呼出ngにより，防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). | |
| 2. | `keyup$et | `Dead$kY | ||
| 3. | `keydown$et | `e^kY | ||
| 4. | `beforeinput$et | `e^kGl | ||
| 5. | `input$et | |||
| 6. | `keyup$et | `e^kY |
7. 旧来の~event初期化子
`legacy-event-initializers^APX8. 旧来の~UIkey属性
`legacy-key-attributes^APX9. 旧来の~event型
`legacy-event-types^APX10. ~eventの拡張-法
`extending-events^APX11. ~securityの考慮点
`security-considerations^APX12. 変更点
`changes-from-earlier-versions^APX13. 謝辞
`acknowledgements-contributors^APX14. 用語集
次の用語の定義の一部は、 他の［ W3C ／標準 ］文書の類似な定義から借用されたり, 改変されている。 詳細は、 定義~内の~linkを見よ。 ◎ Some of the following term definitions have been borrowed or modified from similar definitions in other W3C or standards documents. See the links within the definitions for more information.
【 適合性に関連な用語は、 `別~pageの § 用語集＠~UIEVENTS-A#glossary$ に挙げる。 】【 ここでは、 原文の~~アルファベット順による並びに代えて， 互いの関連度に基づく並びに改めている。 】
- `~window@ （ `Window$I ~obj）
- ~windowは、 現在の`文書$が`属する閲覧~文脈$にて`作動中な~window$bcを指す。 `HTML$r【！HTML5】 ◎ The Window is the object referred to by the current document’s browsing context’s Window Proxy object as defined in HTML5 [HTML5].
- `文書@ （ `document^en ）
- `Document$I【！~TR/DOM-Level-3-Core/core.html#i-Document】 ~interface `DOM$r を~instance化した~obj — ~HTML／~XML ~text文書 全体を表現する。 概念的には、 それは 文書~treeの根であり，文書の~dataへの首な~accessを供する。 ◎ An object instantiating the Document interface [DOM-Level-3-Core], representing the entire HTML or XML text document. Conceptually, it is the root of the document tree, and provides the primary access to the document’s data.
- `要素@ （ `element^en ）
- `Element$I ~interface `DOM$r を~instance化した~obj
- `根~要素@ （ `root element^en ）
- `文書~要素$。 ［ ~HTML／ ~XHTML ］`文書$においては、 `html^e 要素が該当する。 ◎ The first element node of a document, of which all other elements are children. The document element.
- `~body要素@ （ `body element^en ）
- ［ ~HTML／ ~XHTML ］`文書$においては、 `根~要素$の子孫【子？】である `body^e 要素のうち，最初のもの。 ~body要素は，文書の内容を表現する。 【`~HTML仕様による定義＠~HTMLdom#the-body-element-2$href】 ◎ In HTML or XHTML documents, the body element represents the contents of the document. In a well-formed HTML document, the body element is a first descendant of the root element.
- `空~文字列@ （ `empty string^en ）
- 長さ 0 の，`DOMString^I 型~値。 ◎ The empty string is a value of type DOMString of length 0, i.e., a string which contains no characters (neither printing nor control characters).
- `未初期化~値@ （ `un-initialized value^en ）
- ~eventが `initEvent()$m† で初期化される前の，各種~event属性 （ `bubbles$m や `currentTarget$m など） が，既定でとるものとされる値。 ~eventの未初期化~値は、 `Document.createEvent()$m ~method††を利用して 新たな~eventが作成される時点で適用される。 ◎ The value of any event attribute (such as bubbles or currentTarget) before the event has been initialized with initEvent(). The un-initialized values of an event apply immediately after a new event has been created using the method createEvent().
- 【† または，構築子に与える `EventInit$I （または それを継承する）型の辞書~引数 】【†† または，各種~event~interfaceの構築子 】【 この種の値は、 “既定値（ `default value^en ）” 命名されることが多いが、 この名前にされている理由は，~IDL用語の “既定値” と区別するためと思われる。 】
- `~event@ （ `event^en ）
- ~eventは、 その`~target$に結付けられた何らかの~~出来事 （呈示されている要素に対する~mouse~click, 要素からの子~nodeが除去された, その他，いくらでもある） の表現である。 各~eventは、 ある特定の`~event型$の~instanceである。 ◎ An event is the representation of some occurrence (such as a mouse click on the presentation of an element, the removal of child node from an element, or any number of other possibilities) which is associated with its event target. Each event is an instantiation of one specific event type.
- `~event型@ （ `event type^en ）
- `~event型^em は、 特定0の名前を持ち, 特定0の［ 誘発~条件, ~prop, 他の~event型から判別される他の特性 ］を定義する`~event$~objである。 例えば、 ~event型 `click$et は `mouseover$et や `load$et とは異なる特性を持つ。 ~event型は、 ~event~obj上では `type$m 属性として公開される。 詳細は`~event型＠#event-types$hrefに。 ~event型が `click^et である~eventは、 “`click^et ~event” のように略記されることもある。 ◎ An event type is an event object with a particular name and which defines particular trigger conditions, properties, and other characteristics which distinguish it from other event types. For example, the click event type has different characteristics than the mouseover or load event types. The event type is exposed as the type attribute on the event object. See § 5 Event Types for more details. Also loosely referred to as "event", such as the click event.
- `~event~focus@ （ `event focus^en ）
- ~event~focusは、 `文書$の中の［ 特定0の要素その他の`~event~target$ ］において，［ ~~目立たせている／~~注視されている ］ような特別な状態である。 ~focusされたときの挙動は、 各~要素ごとに その機能性に依存して異なる — ［ （~buttonや~hyperlink用に）要素を作動化~対象の首位に据える ／ （~checkbox用の）状態の切り替え ／ （~text~form~field用の）~text入力を受取る ／ 選択された~textを複製する ］など。 詳細は `§ 文書~focusと~focus文脈＠#events-focusevent-doc-focus$hrefに。 ◎ Event focus is a special state of receptivity and concentration on an particular element or other event target within a document. Each element has different behavior when focused, depending on its functionality, such as priming the element for activation (as for a button or hyperlink) or toggling state (as for a checkbox), receiving text input (as for a text form field), or copying selected text. For more details, see § 5.2.3 Document Focus and Focus Context.
- `~event~focus環@ （ `event focus ring^en ）
- ~event~focus環とは、 `文書$内の`~event~focus$の~targetになり得るものからなる有順序~集合である。 `~host言語$は、 これらの~targetの順序を決定する複数の仕方を定義することもある — ［ 文書~順序 ／ 各~focus~targetに定義される数量的~index ／ 各~focus~targetに明示的に与えられる次の~target ／ これらの異なる~modelの~~混成 ］など。 文書は、 複数の~focus環や条件付き~focus環を包含することもある。 概して、［ 文書~順序／~index【~tab~index】 ］に基づく~focus環においては、 最後の~focus~targetの次の~focusは， “最初へ戻る” 。 ◎ An event focus ring is an ordered set of event focus targets within a document. A host language MAY define one or more ways to determine the order of targets, such as document order, a numerical index defined per focus target, explicit pointers between focus targets, or a hybrid of different models. Each document MAY contain multiple focus rings, or conditional focus rings. Typically, for document-order or indexed focus rings, focus wraps around from the last focus target to the first.
- `~event序列@ （ `event order^en ）
- 同じ［ ~event~source／処理n ］から生じた~event連列であって、 各~eventは，同じまたは関係する~event~interfaceを利用しているもの。 例えば，［ ~mouse, ~trackpad, ~keyboard ］などの各種 入力~装置を備える環境では、 それぞれが互いに別々な~event~sourceを成し， 自前の~event序列に従うことになる。 ~trackpadから `mousedown$et ~eventが生じて， ~mouseから `mouseup$et ~eventが生じても、 `click$et ~eventは生じない。 ◎ The sequence in which events from the same event source or process occur, using the same or related event interfaces. For example, in an environment with a mouse, a track pad, and a keyboard, each of those input devices would constitute a separate event source, and each would follow its own event order. A mousedown event from the trackpad followed by a mouseup event from the mouse would not result in a click event.
- 注記： 異なる~event序列~間には相互作用があり得る。 例えば， `click$et ~eventは、 同時並行な `keydown$et ~eventにより修飾され得る （例えば `Shift^cap ＋ `click^et で）。 しかしながら、 これら異なる~event~sourceによる~event序列は，別個になる。 ◎ There can be interactions between different event orders. For example, a click event might be modified by a concurrent keydown event (e.g., via Shift+click). However, the event orders of these different event sources would be distinct.
- 一部の~UIによる~event序列は、 装置に依存しない。 例えば利用者は、 `Tab^cap ~UIkeyを利用して, あるいは ~mouseで新たな被focus要素を~clickして，~focusを変更し得る。 そのような事例における~event序列は、 状態~変化を起動した装置の状態ではなく，処理nの状態に依存する。 ◎ The event order of some interfaces are device-independent. For example, a user might change focus using the Tab key, or by clicking the new focused element with the mouse. The event order in such cases depends on the state of the process, not on the state of the device that initiates the state change.
- `~event~target@ （ `event target^en, 略して “~target” ）
-
次の二つの意味で用いられる：
- `~DOM~event~flow＠#event-flow$href を利用して，`~event$の`~target＠~DOM4#event-target$にされている~obj。 ~event~targetは、 `target$m 属性で指示される。
- 何らかの~eventに対し，前項の意味で~targetになり得る~obj。
- `現在の~event~target@ （ `current event target^en ）
-
次の二つの意味で用いられる：
- ~event~flowにおいて，現在~eventが配送されている`~event~handler$に結付けられた~obj。 この~objは、 当の~event~targetか, または その先祖のいずれかになる。 現在の~targetは、 `~event$が ~event~flowの各種`~event相$を通して ~objから~objへ伝播するに伴って，変化する。 現在の~targetは、 `currentTarget$m 属性で指示される。
- 何らかの~eventに対し，前項の意味で 現在の~event~targetになり得る各~obj （すなわち，当の~eventの`伝播~経路$に属する~obj）。
- ~eventの`伝播~経路@ （ `propagation path^en ）
- `~event$~objが `~event~target$ へ向かって行く／から戻る 道を順々に通過する，`現在の~target$たちからなる有順序~集合である。 ~eventが伝播するに伴い、 `currentTarget$m には，各回ごとに経路に属する`現在の~target$が設定される。 伝播~経路は、 `~event型$にて定義されるとおり，初期~時には 1 つ以上の`~event相$からなるが、 中断されることもある。 “~event~target連鎖” とも呼ばれる。 ◎ The ordered set of current event targets though which an event object will pass sequentially on the way to and back from the event target. As the event propagates, each current event target in the propagation path is in turn set as the currentTarget. The propagation path is initially composed of one or more event phases as defined by the event type, but MAY be interrupted. Also known as an event target chain.
- ~eventの`発火-@ （ `fire^en ）
- `DOM$r にて`定義されている＠~DOM4#firing-events$href。 ~eventの型, および~eventが生じた文脈に応じて、 適切な~interfaceを実装する~eventを作成し，適切に属性を初期化した上で，`~event~target$へ向けて`配送-$することを意味する （例： “`click$et ~eventを発火する” ）。 ◎ A synonym for dispatch.
- ~eventの`配送-@ （ `dispatch^en ）
- 所与の~eventを，指定された`伝播~経路$を通して伝播させる処理nを意味する （例： “`load$et ~eventを配送する” ）。 ◎ To create an event with attributes and methods appropriate to its type and context, and propagate it through the DOM tree in the specified manner. Interchangeable with the term fire, e.g., fire a click event or dispatch a load event.
- 【 原文では、 “配送-” が上の “発火-” を意味するものとして定義されていて、 “`発火-$” は，配送-と~~互換な語であるとされているが、 この訳では、 `DOM$r その他の~web仕様の用法に合わせるため，上述のように使い分けて対訳している （この訳の “発火-” の多くは，原文における “配送-” の対訳である）。 】
- `~event相@ （ `event phase^en ）
-
`~event$の文脈においては、 相は，~DOM~tree内の［ 先祖／子孫 ］への論理的な辿りを表す：
- `捕捉-相$： `~window$ → `文書$ → `根~要素$ → … → `~event~target$の親~node
- `~target相$： `~event~target$
- `浮上-相$： 捕捉-相と同じ連鎖の逆順
- `浮上-相$ （ `bubbling phase^en ）
- `~event~target$により取扱われた`後に^em， ~targetのいずれかの先祖により取扱われ得る`~event$の処理n。 詳細は、 ~event~flowの文脈における `浮上-相$の記述に。 ◎ The process by which an event can be handled by one of the target’s ancestors after being handled by the event target. See the description of the bubble phase in the context of event flow for more details.
- `~target相$ （ `target phase^en ）
- `~event$が`~event~target$により取扱われ得る処理n。 詳細は、 ~event~flowの文脈における`~target相$の記述に。 ◎ The process by which an event can be handled by the event target. See the description of the target phase in the context of event flow for more details.
- `捕捉-相$ （ `capture phase^en ）
- `~event~target$により取扱われる`前に^em， ~targetのいずれかの先祖により取扱われ得る`~event$の処理n。 詳細は、 ~event~flowの文脈における `捕捉-相$の記述に。 ◎ The process by which an event can be handled by one of the target’s ancestors before being handled by the event target. See the description of the capture phase in the context of event flow for more details.
- `~event~listener@ （ `event listener^en ）
- `~event~handler@ （ `event handler^en ）
- `EventListener!I ~interfaceを実装する~objであって `handleEvent()$m ~callback~methodを供するもの。 ~event~handlerは、 言語に特有である。 ~event~handlerは、 特定0の~obj（`現在の~event~target$）の文脈で†，~event~obj自身を引数に伴って呼出される。 ◎ An object that implements the EventListener interface and provides an handleEvent() callback method. Event handlers are language-specific. Event handlers are invoked in the context of a particular object (the current event target) and are provided with the event object itself.
- 【† すなわち，~callback this 値がその~objにされた下で。 】【 参考： `DOM$r による、 `~event~listenerの定義＠~DOM4#concept-event-listener$href。 】
- 注記： ~JSにおいては、 利用者~定義な関数は， `EventListener$I ~interfaceを実装するものと見なされる。 したがって、 その関数が呼出されるときは，最初の引数に~event~objが供されることになる。 加えて、 ~JS~objは， `handleEvent()$m ~methodを定義して `EventListener$I ~interfaceを実装することもできる。 ◎ In JavaScript, user-defined functions are considered to implement the EventListener interface. Thus the event object will be provided as the first parameter to the user-defined function when it is invoked. Additionally, JavaScript objects can also implement the EventListener interface when they define a handleEvent() method.
- `作動化の挙動@ （ `activation behavior^en ）
- `~event$（概して、 利用者により，入力~装置を通して起動される）が、 要素に定義されている~taskを履行させるとき採られる動作。 この~taskは、 その要素に対し［ `~host言語$, 作者~定義な変数 ］あるいはこの両者により，定義されることもある。 与えられた要素~用の既定の~taskは、 汎用な動作であったり, その要素に~~固有なものになることもある。 例えば、［ ~HTML／~SVG ］の `a^e 要素の作動化の挙動は、 ~UAに `href^a 属性にて指定される~linkを辿らせる — そのための閲覧~文脈を指定する~parameter （［ 現在の~window（~UItab）／有名~window／新たな~window ］など）を更に伴なうこともある。 例えば、［ `type^a 属性~値が `submit^l にされた~HTML `input$e 要素 ］用の作動化の挙動は、 ~form要素たちの値を作者~定義な~URL【！URI】へ向けて 作者~定義な~HTTP~methodで送信する。 詳細は、 `作動化の誘発と挙動$に。 ◎ The action taken when an event, typically initiated by users through an input device, causes an element to fulfill a defined task. The task MAY be defined for that element by the host language, or by author-defined variables, or both. The default task for any given element MAY be a generic action, or MAY be unique to that element. For example, the activation behavior of an HTML or SVG <a> element is to cause the user agent to traverse the link specified in the href attribute, with the further optional parameter of specifying the browsing context for the traversal (such as the current window or tab, a named window, or a new window). The activation behavior of an HTML <input> element with the type attribute value submit is be to send the values of the form elements to an author-defined IRI by the author-defined HTTP method. See § 3.5 Activation triggers and behavior for more details.
- `作動化の誘発@ （ `activation trigger^en ）
- `作動化の挙動$を起動するように定義されている~event。 詳細は`作動化の誘発と挙動$に。 ◎ An event which is defined to initiate an activation behavior. Refer to § 3.5 Activation triggers and behavior for more details.
- `既定~動作@ （ `default action^en ）
- `既定~動作$は、 任意選択†な補足的な挙動であって，実装が~event~objの配送-と組合せて遂行しなければナラナイものである。 各種~event型~定義, および 各種 仕様は、 その~event型~用の`既定~動作$があれば，それを定義する。 `作動化の誘発$に結付けられたときなど、 一部の状況下では，~eventの各~instanceには`既定~動作$が複数ある場合もある。 `既定~動作$は、 `preventDefault()$m ~methodの呼出nを通して取消されることもある。 詳細は `既定~動作と取消~可能な~event＠#event-flow-default-cancel$href に。 ◎ A default action is an OPTIONAL supplementary behavior that an implementation MUST perform in combination with the dispatch of the event object. Each event type definition, and each specification, defines the default action for that event type, if it has one. An instance of an event MAY have more than one default action under some circumstances, such as when associated with an activation trigger. A default action MAY be cancelled through the invocation of the preventDefault() method. For more details, see § 3.2 Default actions and cancelable events.
- 【† どの主体から見て任意選択なのかはっきりしない — 実装ではなく，この仕様を参照している他の仕様？ 】
- `最上層の~event~target@ （ `topmost event target^en ）
- 最上層の~event~targetは、 `~event~target$になれるような，最も上層に描画される要素でなければナラナイ。 ~graphicな~UIにおいては、 これは，利用者の~pointing装置が~~指す所の~~直下にある要素になる。 この~targetの決定は、 ~UIの “接触判定” に基づく。 接触判定と積層~順序に関する特定の詳細は、 `~host言語$を見よ。 ◎ The topmost event target MUST be the element highest in the rendering order which is capable of being an event target. In graphical user interfaces this is the element under the user’s pointing device. A user interface’s hit testing facility is used to determine the target. For specific details regarding hit testing and stacking order, refer to the host language.
- 【 例えば `pointer-events$p ~propなどにより，明示的に接触判定の対象から除外されるものは、 最も上層に塗られていても，最上層の~event~targetにはならない。 】
- `~pointing先@
- ~pointing装置が現在 指している`最上層の~event~target$を意味する（存在しない場合は~NULL）。
- 【 この用語と次に与える用語は、 各所の記述を集約して簡潔にするために，この訳に導入している。 】
- `~pointing先$が `有効に変化-@ したとは、 その変化は，［ ~pointing装置の`首~pointer$によるものである†1 ］かつ［ （利用者により）~pointerが動かされたか，ある要素が動いた†2 ］ことにより生じたことを意味する。
- 【†1 非 `首~pointer$からは、 この定義を参照する~mouse~event（互換性~mouse~event）は生じない。 】【†2 要素が “動いた” とは、 ~scrollや~layout変化によるそれに加えて，要素を挿入するなどの~DOM変異によるそれも含まれる （と思われる — 少なくとも一部の~browserの実装は、 そうなっている）。 】【†2 動いた要素と変化-［ 前／後 ］の~pointing先が一致する必要はない。 例えば、 動いた要素は新たな~pointing先の先祖かもしれない。 】
- `回転@ （ `rotation^en ）
- `WheelEvent$I ~interfaceを利用している入力~装置~上の 増分的な変化の指示。 これには、 装置により ~wheelの回転動作, 平坦な表面をなぞる動き, 特定0の~buttonの押圧 などがあり得る。 ◎ An indication of incremental change on an input device using the WheelEvent interface. On some devices this MAY be a literal rotation of a wheel, while on others, it MAY be movement along a flat surface, or pressure on a particular button.
- `~delta@ （ `delta^en ）
- ~UAが `WheelEvent!I ~interfaceとして~supportされるような入力~装置（~mouse~wheelや~touchpadなど）の物理的な動きに呼応して，~pageを~scrollしたり~zoomするときに見積もられる~scroll量。 `~delta$の値（例： `deltaX$m, `deltaY$m, `deltaZ$m 属性）は、 `deltaMode$m ~propによる`測定~単位$として解釈される。 ~wheel（または他の装置）の物理的な動きと`~delta$の正負との関係性は、 環境や装置に依存する。 しかしながら，~UAが`既定~動作$として~scrollする場合、 `~delta$の正負は`右手~座標系$により与えられる。 ◎ The estimated scroll amount (in pixels, lines, or pages) that the user agent will scroll or zoom the page in response to the physical movement of an input device that supports the WheelEvent interface (such as a mouse wheel or touch pad). The value of a delta (e.g., the deltaX, deltaY, or deltaZ attributes) is to be interpreted in the context of the current deltaMode property. The relationship between the physical movement of a wheel (or other device) and whether the delta is positive or negative is environment and device dependent. However, if a user agent scrolls as the default action then the sign of the delta is given by a right-hand coordinate system where positive X,Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively.
- `~hysteresis@ （ `hysteresis^en ）
- 使用感を改善するために，所在や時間がずれた入力も一定限度までは受容するような、 ヒト~interface設計の特能。 例えば、 利用者が~mouse~buttonを~double-clickするときの微小な時間差の受容は，時間的~hysteresisであり、［ 利用者が子~menuへ遷移しようとして，~mouseが親~UIwindowから外れたとき，入子な~menuを直ぐに閉じないこと ］は，所在的~hysteresisである。 ◎ A feature of human interface design to accept input values within a certain range of location or time, in order to improve the user experience. For example, allowing for small deviation in the time it takes for a user to double-click a mouse button is temporal hysteresis, and not immediately closing a nested menu if the user mouses out from the parent window when transitioning to the child menu is locative hysteresis.
- `文字~値@ （ `character value^en ）
-
~UIkey値の文脈では、 文字~値は， 1 個~以上の~Unicode文字を表現する文字列である — 普通字や記号, あるいは 何個かの普通字が成す並びなど，それぞれが妥当な`~Unicode字種$が成す集合に属するような。 この仕様では、 文字~値は ~Unicode文字列（例： `0020^U ）, または 同じ符号位置の~glyph表現（例： `X^kGl ）として記され、 2 つの表現を判別し易くするよう色付けられる。 ◎ In the context of key values, a character value is a string representing one or more Unicode characters, such as a letter or symbol, or a set of letters, each belonging to the set of valid Unicode character categories. In this specification, character values are denoted as a unicode string (e.g., U+0020) or a glyph representation of the same code point (e.g., " "), and are color coded to help distinguish these two representations.
注記： ~source~codeにおいては、 非~graphic文字などの一部の~UIkey値は， 利用-中な~programming言語の文字~escape構文を利用して表現され得る。 ◎ In source code, some key values, such as non-graphic characters, can be represented using the character escape syntax of the programming language in use.
- `~UIkey値@ （ `key value^en ）
- ~UIkey値は、 特定0の状態にある~UIkeyに結付けられた，`文字~値$ または［ 複数~文字からなる文字列 （ `Enter$kY, `Tab$kY, `MediaTrackNext$kY など） ］である。 ~UIkey値は、 どの~UIkeyにも — 制御~UIkey, ~function~UIkey, `修飾~UIkey$, `~dead-key$, その他の~UIkeyも含む — `文字~値$を持つかどうかに関わらず，あてがわれる。 与えられた時点の与えられたどの~UIkeyの~UIkey値も、 `~UIkey~mapping$に依存する。 ◎ A key value is a character value or multi-character string (such as "Enter", "Tab", or "MediaTrackNext") associated with a key in a particular state. Every key has a key value, whether or not it has a character value. This includes control keys, function keys, modifier keys, dead keys, and any other key. The key value of any given key at any given time depends upon the key mapping.
- `修飾~UIkey@ （ `modifier key^en ）
- 修飾~UIkeyは、 ~UIkeyの通常の挙動を変更する — （ `Shift^cap ~UIkeyで）異なる文字caseを生産させたり, （`Fn^cap や `Alt^cap ~UIkeyなどで）~UIkeyが誘発する機能性を改めるなど。 修飾~UIkeyについての情報は、 `§ 修飾~UIkey＠#keys-modifiers$hrefに。 妥当な修飾~UIkeyたちが成す~listは、 `UIEvents-Key$r の`修飾~UIkeyの表t$内にある。 ◎ A modifier key changes the normal behavior of a key, such as to produce a character of a different case (as with the Shift key), or to alter what functionality the key triggers (as with the Fn or Alt keys). See § 6.3.1 Modifier keys for more information about modifier keys and refer to the Modifier Keys table in [UIEvents-Key] for a list of valid modifier keys.
- `~dead-key@ （ `dead key^en ）
- ~dead-keyは、 自身は文字を生産しないが，［ 別の~UIkeyとの［ 組合n／連列 ］により，修飾された文字 — 発音区別符号を伴う文字（例： `ö^kGl, `é^kGl, `â^kGl ）など — を生産する ］ような［ ~UIkeyまたは~UIkeyの組合n ］である。 ◎ A dead key is a key or combination of keys which produces no character by itself, but which in combination or sequence with another key produces a modified character, such as a character with diacritical marks (e.g., "ö", "é", "â").
- `~text組成~system@ （ `text composition system^en ）
- 何らかの形による代替-入力 （`~IME$, 発話~処理器, 手書き認識~systemなど） を解釈して，それを~textに変換する~software~component。 ◎ A software component that interprets some form of alternate input (such as a input method editor, a speech processor, or a handwriting recognition system) and converts it to text.
- `~UIkey~mapping@ （ `key mapping^en ）
- ~UIkey~mappingは、 特定0の~UIkeyに~UIkey値をあてがう処理nであり、 いくつかの要因 — ~OSや~keyboard~layout （例： `QWERTY$, Dvorak, Spanish, InScript, Chinese, 等々）， および［ `修飾~UIkey$（ `Shift^cap, `Alt^cap, 等々）／ `~dead-key$ ］の状態すべてを含む — を組合せた結果である。 ◎ Key mapping is the process of assigning a key value to a particular key, and is the result of a combination of several factors, including the operating system and the keyboard layout (e.g., QWERTY, Dvorak, Spanish, InScript, Chinese, etc.), and after taking into account all modifier key (Shift, Alt, et al.) and dead key states.
- `~IME@ （ `input method editor^en, 入力方式エディタ ）
- ~IMEは、 一連の~keystrokeから表意文字その他の文字への変換を — 通例的に，利用者により手引きされる辞書検索により — 遂行する~appであり、 東アジア圏の言語（例：中国語, 日本語, 韓国語）でよく利用される。 ~IMEは、 携帯~機器などでも単語の入力補完に利用されることもある。 この仕様における~IMEの扱いについては、 `§ ~IME＠#keys-IME$hrefに。 § `~text組成~system$も見よ。 ◎ An input method editor (IME), also known as a front end processor, is an application that performs the conversion between keystrokes and ideographs or other characters, usually by user-guided dictionary lookup, often used in East Asian languages (e.g., Chinese, Japanese, Korean). An IME MAY also be used for dictionary-based word completion, such as on mobile devices. See § 6.3.3 Input Method Editors for treatment of IMEs in this specification. See also text composition system.
- `QWERTY@
- QWERTY（ “ˈkwɜrti” と発音される）は、 共通的な~keyboard~layoutの普通字~UIkeyの上段の最初の 6 文字が Q, W, E, R, T, Y であることから命名されている。 他にも~popularな~keyboard~layoutは数多くあり（~Dvorakや~Colemak~layoutなど）、 そのほとんどは，地域化や人間工学~用に設計されている。 ◎ QWERTY (pronounced ˈkwɜrti) is a common keyboard layout, so named because the first five character keys on the top row of letter keys are Q, W, E, R, T, and Y. There are many other popular keyboard layouts (including the Dvorak and Colemak layouts), most designed for localization or ergonomics.
- `~Unicode字種@ （ `Unicode character categories^en ）
-
各~Unicode符号位置に対し定義されている
`General Category^en 値の部分集合。
この部分集合には、
次に挙げる字種に属するものすべてが包含される：
- 普通字（ `Letter^en ）： Ll, Lm, Lo, Lt, Lu
- 数字n（ `Number^en ）： Nd, Nl, NO
- 約物（ `Punctuation^en ）： Pc, Pd, Pe, Pf, Pi, Po, Ps
- 記号（ `Symbol^en ）： Sc, Sk, Sm, So
- `~DOM0@ （ DOM Level 0 ）
- 用語 “~DOM0” は，~HTML`文書$の種々の機能性の混成を指し、 正式には指定されていないことが多いが， 伝統的に事実上の標準として~supportされているものである。 元々は Netscape Navigator 3.0 や Microsoft Internet Explorer 3.0 により実装された。 属性や~methodは、 多くの事例で “~DOM0” との後方-互換性の理由から含められている。 ◎ The term DOM Level 0 refers to a mix of HTML document functionalities, often not formally specified but traditionally supported as de facto standards, implemented originally by Netscape Navigator version 3.0 or Microsoft Internet Explorer version 3.0. In many cases, attributes or methods have been included for reasons of backward compatibility with DOM Level 0.