1. 序論
1.1. 概観
UI Events は、~~主に二つの目標を念頭に設計されている。 第一の目標は、`~event$~systemを,`~event~listener$を登録できるように, および ~event~flowを木~構造を通して述べ得るように設計することである。 加えて,この仕様は、~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 については,`非推奨に$されており、 `DOM$r にて再定義されている。 】
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上の規約
この仕様では、次の表記が用いられる: ◎ This specification follows the Proposed W3C Specification Conventions, with the following supplemental additions:
表記~例 | 意味 |
---|---|
`↓^cap, `=^cap, `Q^cap | ~key上に印字される ~key~cap。 この表記は、生成される `KeyboardEvent!I の `key$m, `code$m 値には関わらない,利用者~視点の~keyを指すときに利用される。 |
`ア^kGl, `漢字^kGl | 文字/文字~並びを表現している~glyph並び |
`003D^U | ~Unicode文字 |
`ArrowDown$kY, `=^kY, `q^kY, `Q^kY | ~keyを押して生成される~key値の名前(すなわち, `KeyboardEvent^I の `key$m 値)。 |
`ArrowDown$kC, `Equal$kC, `KeyQ$kC | 物理的な~keyに結付けられている~key~code(すなわち、 `KeyboardEvent^I の `code$m 値)の名前 |
加えて,この仕様における一定の用語は、特定0の意味で利用される。 語 “実装”は、~browser, 内容~著作tool, その他,この仕様を実装する`~UA$を~~指す。 語 内容~作者は、~ifc, ~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木を通してどのように伝播するかについて述べる。 ~appは, `dispatchEvent()$m ~methodを利用して~event~objを配送し、~event~objは,~DOM~event~flowにより決定されるように~DOM木を通して伝播する。 ◎ 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標的$に向けて配送されるが、その前に~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標的$たちからなる有順序~listであり、~eventはそれらを通過する。 この伝播~経路は、文書の階層的~木~構造を反映する。 ~list内の最後の~itemが`~event標的$になり、~list内で先行する~itemは 標的の先祖とされ, 直前の~itemが 標的の親とされる。 ◎ 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相には、次の 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 )
- この相の下では、~event~objは,`伝播~経路$を順方向に辿って, 標的の手前まで伝播する。 すなわち、`~Window$から標的の親まで,標的の各~先祖を辿ることになる。 ◎ The capture phase: 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.
- `標的~相@( at-target phase )
- ~event~objは、その`標的$に到着する。 `~event型$にて,~eventは浮上しないものと指示されている場合、~eventの伝播は,この相の完了を以って終える。 ◎ The target phase: 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 )
- この相の下では、~event~objは,`捕獲-相$のときと同じ`伝播~経路$を,その逆順に辿ることになる。 すなわち、標的の親から `~Window$まで,標的の各~先祖を辿って伝播することになる。 ◎ The bubble phase: 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配送が完了した後に遂行される~SHOULDであるが、例外的~事例では,~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が配送される前に】 切り替える。 `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のうち,同期的とされているもの( “同期~event” )は、同じ時機に生じた[ 他の~event / ~DOMにおける変更 / 利用者操作 ]による~eventの 連列( sequence )の中で互いに順序付けられた,[ FIFO( first-in-first-out )~modelにおける,仮想の~queue ]内にあるかのように扱われる。 この~queue内の各~eventは、前の~eventにおける伝播の挙動が[ 完了するか, 取消される ]まで遅延される。 一部の同期~eventは、~mouse~button~eventなど,特定の[ 装置/処理- ]により駆動される。 この種の~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.
【 同期/非同期 の定義は,他の~eventとの関係に基づく — 現在は非同期とされている~eventであっても,新たな~event型が導入されたときは、それと同期的な関係になり得ることになる。 】
非同期的な~event( “非同期~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要素は、文書の読込-中に構文解析されて実行される。 `load$et ~eventは、その~script要素にて,非同期的に発火されるように~queueされる。 しかしながら,それは非同期~eventなので、文書の読込-中に発火される他の同期的~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木$から除去された場合、その背後にある要素に向けて `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標的$(~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 ~keyである `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 ~keyを押す / その要素が~focusを得ているかどうかに関わらず,何らかの方法で その要素に~linkされている~key( “~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 ~ifc またはそれを継承する~ifcの構築子が呼出されたときは, `DOM$r に述べられる手続きに従うべきであるが、それに加え,[ `KeyboardEvent$I / `MouseEvent$I ]~ifcは、[ `Event$I ~objにおける~key修飾の内部~状態を初期化する ]ための追加の辞書~memberも供する。 この内部~状態は、特定的には[ `KeyboardEvent.getModifierState()$m / `MouseEvent.getModifierState()$m ]~methodを用いて照会できる。 この節では、 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, または これらから派性する~ifc ]を実装する~objも,各種 `~key修飾~名$ に対応する, `内部~key修飾~状態@ を持つ。 それは:
- 下の~algoを利用して,~objを構築する際に設定できる。
- `UIEvents-Key$r の`修飾~key一覧$に述べられる `~key修飾~名@ を用いて検索取得できる。
次の手続きが, DOM4 による~eventの構築-法に定義される~algoに追補される: ◎ The following steps supplement the algorithm defined for constructing events in DOM4:
-
~event~obj %~event を構築する際に,構築子に `EventModifierInit$I 引数 %dict が供された場合、次の下位手続きを実行する:
-
各 `~key修飾~名$ %名前 に対し:
-
%dict 内に[[ 文字列 "`modifier^c" と %名前 を順に連結した文字列 ]を名前とする辞書~member %member ]があるならば:
- [ %名前 に対応する, %~event の `内部~key修飾~状態$ ]を %member の値に設定する。
-
-
4. ~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.
~eventの定義表
【 この節は、この訳による追加である。 】
この仕様に現れる,各種`~event型$の定義は、次のような表形式で与えられる:
◎イ型 この欄には、当の~event型の名前が記される(例: `click^et )。 この名前が、~eventの `type$m 属性の値になる。 ◎界面 この欄には、この型の~event~objが実装する~ifcが示される(例: `MouseEvent^I )。 ◎同期 この欄には、この型の~eventが他の~eventと`同期$して生じ得るならば “あり”/ 他の場合は “なし” と記される。 ◎浮上 この欄には、この型の~eventが `浮上-$するならば “する” / 他の場合は “しない” と記される。 後者の場合、この~eventに対する`~event~listener$が`浮上-相$に対し登録されても,誘発されないことになる。 ◎標的 この欄には、この型の~eventの`標的$になり得る~objが挙げられる(例: `Element$I )。 そうでない~objに,この~eventに対する`~event~listener$が登録されても,`~trusted$~eventは誘発されないことになる。 ◎取消 この欄には、この型の~eventが`取消~可能$ならば “可” / 他の場合は “不可” と記される。 ◎構 `composed$m 属性に関係する — 単に, “Yes” 記されているならその属性~値は ~T をとる — と見られるが、実際の定義は不明。 “Yes” 以外にどのような値または記述があり得るのかも不明。 この欄が無い~event型もあり、その不在が何を意味するのかも不明。 ◎既定動作 この欄には、この型の~eventに結付けられ得る`既定~動作$が挙げられる(例:頁を~scrollする)。 ◎文脈 この欄には、この型の~eventが実装する(~ifc欄に挙げられている)~ifcの各種~memberが,どのような値に初期化されるかが述べられる。 ◎表終注意: この表の大部分は、`~trusted$~eventに対してのみ意味を持つ。 `~trusted$でない~event(~scriptが作成したものなど)は、この表に従うとは限らない。 例えば、`既定~動作$があっても,行われないであろう。
4.1. ~UI~event
~UI~event~moduleは、~UIや文書の操作1に結付けられている,基本的な~event型について述べる。 ◎ The User Interface event module contains basic event types associated with user interfaces and document manipulation.
4.1.1. ~ifc `UIEvent^I
~DOM2にて導入された。 ◎ Introduced in DOM Level 2
`UIEvent^I ~ifcは、~UI~eventに特有の文脈的~情報を供する。 ◎ The UIEvent interface provides specific contextual information associated with User Interface events.
`UIEvent^I ~ifcの~instanceを作成するためには、その構築子に `UIEventInit^I 辞書(省略可)を渡して呼び出す。 ◎ To create an instance of the UIEvent interface, use the UIEvent constructor, passing an optional UIEventInit dictionary.
4.1.1.1. `UIEvent^I
[Constructor(~DS %type, optional `UIEventInit$I %eventInitDict), `Exposed$=Window] interface `UIEvent@I : `Event$I { ~RA `Window$I? `view$m; ~RA long `detail$m; };
- `view@m
- この属性は、~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
- この属性には、~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.
4.1.1.2. `UIEventInit^I
dictionary `UIEventInit@I : `EventInit$I { `Window$I? `view$m = null; long `detail$m = 0; };
- `view@m
- この~memberは、この~eventの配送~先の大域~環境の~Windowにされる~SHOULDである。 この~eventが要素に配送されるなら、その要素の`~node文書$を包含する~Windowに設定される~SHOULDである。 ◎ 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
- この値は、個々の~appに特有の整数を与える。 ◎ This value is initialized to a number that is application-specific.
4.1.2. 各種~UI~event型
以下に,各種~UI~event型を挙げる。 これらの~eventのうち一部のものは、[ ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ]~ifcを利用する。 詳細は各~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.
4.1.2.1. `load^et
◎イ型 `load@et ◎界面 ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ◎ UIEvent if generated from a user interface, Event otherwise. ◎同期 なし ◎浮上 しない ◎標的 `Window$I, `Document$I, `Element$I ◎取消 不可 ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 資源を読込んだ~obj
~UAは、[ ~DOM実装が資源(文書など), および すべての従属~資源(画像, ~stylesheet, ~scriptなど)の読込みを終えた ]とき,この~eventを発火し~MUST。 従属~資源の読込-に失敗した場合でも、それを読込んだ資源が~DOMを介して依然として~access可能である場合には,この~eventの発火を止めては~MUST_NOT。 実装が,この~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.
4.1.2.2. `unload^et
◎イ型 `unload@et ◎界面 ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ◎ UIEvent if generated from a user interface, Event otherwise. ◎同期 あり ◎浮上 しない ◎標的 `Window$I, `Document$I, `Element$I ◎取消 不可 ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 包含されている資源が除去された共通の~obj
~UAは、[ ~DOM実装が,環境から資源(文書など)や 従属~資源(画像, ~stylesheet, ~scriptなど)を除去した ]とき,この~eventを発火し~MUST。 文書の~unloadは,この~event型が配送された後で~MUST。 実装が,この~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.
4.1.2.3. `abort^et
◎イ型 `abort@et ◎界面 ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ◎ UIEvent if generated from a user interface, Event otherwise. ◎同期 あり ◎浮上 しない ◎標的 `Window$I, `Element$I ◎取消 不可 ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 資源の読込みが~error以外により停止された要素
~UAは、[ 資源の読込みがまだ進捗~中に,利用者が取消したなどにより中止された ]とき,この~eventを発火し~MUST。 ◎ 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.
4.1.2.4. `error^et
◎イ型 `error@et ◎界面 ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ◎ UIEvent if generated from a user interface, Event otherwise. ◎同期 なし ◎浮上 しない ◎標的 `Window$I, `Element$I ◎取消 不可 ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 資源の読込みが~errorにより停止された要素
~UAは、[ 資源の読込-に失敗した, または読込まれたが その意味論に則って解釈-できない(無効な画像, ~script実行~error, 整形式でない~XMLなど) ]とき,この~eventを発火し~MUST。 ◎ 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.
4.1.2.5. `select^et
◎イ型 `select@et ◎界面 ~UIから生成されるときは `UIEvent$I / 他のときは `Event$I ◎ UIEvent if generated from a user interface, Event otherwise. ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 不可 ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: ~text内容が選択された要素
~UAは、[ 利用者が一部の~textを選択した ]とき,この~eventを発火し~MUST。 この~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言語$は、適用-可能な所では,次のための規則を定義する~SHOULDである:
- 利用者が内容を選択できる方法(国際的~言語~規約も考慮して)
- `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
4.2. ~focus~event
注記: この節の~ifc, および それに結付けられている[ ~event型, ~focus~event序列 ]は、[ User Agent Accessibility Guidelines 2.0 `UAAG20$r に定義される概念と指針 ]に則って,特に[ ~focusの仕組み, および ~focusの用語集 に定義されている用語 ]に注視して設計されている。 ◎ This interface and its associated event types and §4.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.
4.2.1. ~ifc `FocusEvent^I
この仕様にて導入された。 ◎ Introduced in this specification
`FocusEvent^I ~ifcは、~focus~eventに特有の文脈的~情報を供する。 ◎ The FocusEvent interface provides specific contextual information associated with Focus events.
`FocusEvent^I ~ifcの~instanceを作成するためには、その構築子に `FocusEventInit^I 辞書(省略可)を渡して呼び出す。 ◎ To create an instance of the FocusEvent interface, use the FocusEvent constructor, passing an optional FocusEventInit dictionary.
4.2.1.1. `FocusEvent^I
[Constructor(~DS %type, optional `FocusEventInit$I %eventInitDict), `Exposed$=Window] interface `FocusEvent@I : `UIEvent$I { ~RA `EventTarget$I? `relatedTarget$m; };
- `relatedTarget@m
- ~focus~eventに関係する,副 `EventTarget$I を識別するために利用される。 ~eventの型に依存する。 ◎ Used to identify a secondary EventTarget related to a Focus event, depending on the type of event.
- 保安上の理由から、入子の関係にある閲覧文脈の間で~focusが切り替わったときには,この属性の値は、~NULL にされる~SHOULDである。 ◎ 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.
4.2.1.2. `FocusEventInit^I
dictionary `FocusEventInit@I : `UIEventInit$I { `EventTarget$I? `relatedTarget@m = null; };
この辞書の各~memberは、 `FocusEventInit!I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ 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).
4.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. | `focusin$et | %A が~focusを受取る直前に送信される ◎ Sent before first target element receives focus |
2. | `focus$et | %A が~focusを受取った直後に送信される ◎ Sent after first target element receives focus |
利用者が~focusを移転させた ◎ User shifts focus | ||
3. | `focusout$et | %A が~focusを失う直前に送信される ◎ Sent before first target element loses focus |
4. | `focusin$et | %B が~focusを受取る直前に送信される ◎ Sent before second target element receives focus |
5. | `blur$et | %A が~focusを失った直後に送信される ◎ Sent after first target element loses focus |
6. | `focus$et | %B が~focusを受取った直後に送信される ◎ Sent after second target element receives focus |
注記: この仕様は、 `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.
4.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(例: 所在bar, 検索~field, 等々 )間で~focusを切替し得る(~tab~keyなどにより)。 ~tab内に示されている文書も、これらの~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の詳細にて識別される`標的$は、~window内の文書またその一部に限られ~MUST — ~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言語$は、次を定義して~MAY:
- どの要素が~focusを受取れるか
- 要素はどの条件の下で~focusを受取るか
- ~focusはどの手段で変更できるか
- ~focusはどの順序で変化するか
例えば,要素に~pointerが接触するだけで,要素が~focusを得ることもあれば、~mouse~clickを要する状況もある。 要素には、全く~focusされ得ないないものもあれば、特別な手段(要素~上を~clickするなど)を通してなら~focusできるが,~tabbingでは~focusできないものもある。 文書は、複数の`~focus環$を包含して~MAY。
他の仕様は、この仕様にて述べるものより複雑な~focus~modelを定義して~MAY — 複数の要素が,現在の~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.4.2.4. 各種~focus~event型
以下に,各種~focus~event型を挙げる: ◎ The Focus event types are listed below.
4.2.4.1. `blur^et
◎イ型 `blur@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Window$I, `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: ~focusを失った`~event標的$
- `FocusEvent.relatedTarget$m: 新たに~focusを受取った`~event標的$。
~UAは、要素が~focusを失った直後に,その要素を標的に,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when an event target loses focus. The focus MUST be taken from the element before the dispatch of this event type. This event type is similar to focusout, but is dispatched after focus is shifted, and does not bubble.
4.2.4.2. `focus^et
◎イ型 `focus@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Window$I, `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 新たに~focusを受取った`~event標的$
- `FocusEvent.relatedTarget$m: ~focusを失った`~event標的$(もしあれば)。
~UAは、要素が~focusを受取った直後に,その要素を標的に,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when an event target receives focus. The focus MUST be given to the element before the dispatch of this event type. This event type is similar to focusin, but is dispatched after focus is shifted, and does not bubble.
4.2.4.3. `focusin^et
◎イ型 `focusin@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 する ◎標的 `Window$I, `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: 新たに~focusを受取ることになる`~event標的$
- `FocusEvent.relatedTarget$m: ~focusを失うことになる`~event標的$(もしあれば)。
~UAは、要素が~focusを受取る直前に,その要素を標的に,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when an event target is about to receive focus. This event type MUST be dispatched before the element is given focus. The event target MUST be the element which is about to receive focus. This event type is similar to focus, but is dispatched before focus is shifted, and does bubble.
注記: この~event型を利用すれば、内容~作者は,~focusが次の~focus`~event標的$へ移転する前に ~eventの `FocusEvent.relatedTarget$m 属性(または~host言語に特有の~methodや手段)を利用して,現在の被focus要素を得ることができる。 ◎ When using this event type, the content author can use the event’s relatedTarget attribute (or a host-language-specific method or means) to get the currently focused element before the focus shifts to the next focus event target, thus having access to both the element losing focus and the element gaining focus without the use of the blur or focusout event types.
4.2.4.4. `focusout^et
◎イ型 `focusout@et ◎界面 `FocusEvent$I ◎同期 あり ◎浮上 する ◎標的 `Window$I, `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~UI~eventに共通する文脈~情報$にて与えられる:
- `target$m: ~focusを失うことになる`~event標的$
- `FocusEvent.relatedTarget$m: 新たに~focusを受取ることになる`~event標的$。
~UAは、要素が~focusを失う直前に,その要素を標的に,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when an event target is about to lose focus. This event type MUST be dispatched before the element loses focus. The event target MUST be the element which is about to lose focus. This event type is similar to blur, but is dispatched before focus is shifted, and does bubble.
4.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.
4.3.1. ~ifc `MouseEvent^I
~DOM2にて導入され、この仕様にて改変された。 ◎ Introduced in DOM Level 2, modified in this specification
`MouseEvent^I ~ifcは、`~mouse~event$に特有の文脈的~情報を供する。 ◎ The MouseEvent interface provides specific contextual information associated with Mouse events.
入子にされている要素に対しては、~mouse~eventは, 通例的には,最も深い入子の要素を標的にすることになる。 ◎ In the case of nested elements, mouse events are always targeted at the most deeply nested element.
注記: 標的にされた要素の先祖は、~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 ~ifcの~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 など)を計算できる。 ◎ 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).
4.3.1.1. `MouseEvent^I
[Constructor(~DS %type, optional `MouseEventInit$I %eventInitDict), `Exposed$=Window] interface `MouseEvent@I : `UIEvent$I { ~RA long `screenX$m; ~RA long `screenY$m; ~RA long `clientX$m; ~RA long `clientY$m; ~RA boolean `ctrlKey$m; ~RA boolean `shiftKey$m; ~RA boolean `altKey$m; ~RA boolean `metaKey$m; ~RA short `button$m; ~RA unsigned short `buttons$m; ~RA `EventTarget$I? `relatedTarget$m; boolean `getModifierState$m(~DS %keyArg); };
- `screenX@m
- `screenY@m
- 順に、[ ~screen座標系の原点 ]に相対的な,~eventが生じた~~地点の[ 横方向, 縦方向 ]座標。 ◎ screenX, of type long, readonly ◎ The horizontal 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. ◎ screenY, of type long, readonly ◎ 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.
- `未初期化~値$: 0 ◎ ↑
- `clientX@m
- `clientY@m
- 順に、[ ~eventに結付けられている表示域 ]に相対的な,~eventが生じた~~地点の[ 横方向, 縦方向 ]座標。 ◎ clientX, of type long, readonly ◎ The horizontal coordinate at which the event occurred relative to the viewport associated with the event. ◎ The un-initialized value of this attribute MUST be 0. ◎ clientY, of type long, readonly ◎ 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.
- `未初期化~値$: 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
- ~mouse~buttonの状態~変化による~mouse~eventに対しては、この属性を利用して,その状態を変化させた~pointing装置の~buttonを指示し~MUST。 ◎ button, of type short, readonly ◎ 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 } は、次を指示し~MUST: ◎ 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
- ~mouse~buttonが現在どの組合せで押されているかを指示する~bitmask。 どの~mouse~eventにおいても、それを指示するときには,この属性が利用され~MUST。 ◎ buttons, of type unsigned short, readonly ◎ 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 ]は、次を指示し~MUST: ◎ 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ごとに倍々にされ~MUST( 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がいくつあっても,~bitwise演算を利用して,現在どの~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
- ~eventの型に依存して、 ~UI~eventに関係する副 `EventTarget$I を識別するために利用される。 ◎ relatedTarget, of type EventTarget, readonly, nullable ◎ 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
- この仕様にて導入された。 ◎ 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.
4.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上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ 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がその位置に動かされては~MUST_NOT。 ◎ ↑
実装は、~mouse~eventを生成するときには, `現在の~click回数@ を保守し~MUST。 これは、【同じ】~pointing装置の~buttonが,特定の時間~内に連続して~clickされた数を指示する非~負の整数で~MUST。 どの程度の遅延で回数が~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される? 】
4.3.2. ~eventの~key修飾 初期化子
`MouseEvent$I / `KeyboardEvent$I ~ifcは、各種~keyboard修飾~属性を共有し,追加の修飾~状態を検索取得するための仕組みを~supportする。 次の辞書により、作者は,これらの~ifcの[ 各種~keyboard修飾~属性, および[ `MouseEvent.getModifierState()$m / `KeyboardEvent.getModifierState()$m ]を介して照会される追加の修飾~状態 ]を初期化できるようになる。 この辞書を利用して~eventを構築する手続きは、 ~event構築子 節 にて定義される。 ◎ 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 の`~key修飾~状態$を,[ 下の表の 2 列目の値を引数に %~event 上の `getModifierState()^m が呼出されたときは,その行の 1 列目の名前の~member値が返される ]ように初期化し~MUST。
名前 引数 `altKey^c `Alt^l `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 の`~key修飾~状態$を,[ 対応する`~key修飾~名$ — すなわち、~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.
4.3.3. ~mouse~event序列
この仕様にて定義される一定の~mouse~eventは、相互相対順序の下で生じ~MUST。 `~pointing先$が,ある要素 %A に変化したときは、次の~event連列が生じ~MUST: ◎ 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連列が生じ~MUST: ◎ 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頁~上で 同じ[ 寸法, 絶対~位置 ]にされていて、~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連列が生じ~MUST: ◎ 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 と `mouseup$et ~event ]の標的が同じ要素であって, `mouseout$et や `mouseleave$et ~eventが介在しない ]ときには、 `click$et/`dblclick$et ~eventを発火する~SHOULDである。 また、[ 結付けられている `mousedown$et と `mouseup$et とで標的が異なる ]ときは、最も近い共通の`広義先祖$ 上に `click$et/`dblclick$et ~eventを発火する~SHOULDである。 ◎ 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要素$を標的にしていて,対応する `mouseup$et ~eventが`根~要素$を標的にしている場合、最も近い共通の`広義先祖$は`根~要素$なので, `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標的$が~DOMから除去された場合、連列の残りの部分の~eventが,その要素~上に発火されては~MUST_NOT。 ◎ 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.
【 標的が~DOMの中で移動された場合はどうなる? その種の位置~変化が伴われるような いかなる~DOM~~操作も,[ 要素をいったん~DOM木から除去してから挿入し直すものである ]と解釈するならば、それらの要素には,~eventは配送されなくなることになるが。 】
`mousedown$et ~eventの結果,【~event~listenerにより】 標的~要素が~DOMから除去された場合、その要素に対し[ `mouseup$et, `click$et, `dblclick$et, ]~eventは発火されず、これらの~eventによる既定の`作動化の挙動$も誘発されなくなる。 しかしながら, `mouseup$et ~eventは、依然として[ 標的~要素が除去された後に新たに`~pointing先$になった要素 ]に対しては発火されることになる。 同様に, `mouseup$et ~eventの配送の最中に 標的~要素が~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.
4.3.4. 各種~mouse~event型
以下に,各種~mouse~event型を挙げる。 入子にされている要素に対しては、~mouse~event型は,常に`~pointing先$ — 入子において最も深い要素† — を標的にする。 標的にされた要素の先祖は、~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 に関しては、その限りでない。 】
4.3.4.1. `auxclick^et
◎イ型 `auxclick@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 文脈依存 ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `UIEvent.detail$m: `現在の~click回数$を指示する — 属性~値は、利用者がこの動作を始めたときは 1 になり,その後,各~clickごとに 1 ずつ増加され~MUST。
`auxclick$et ~event型は、利用者が非~首~pointer~buttonを[ 押してから, 離した ]とき, あるいは[ そのような動作を模造する方式で~pointerが作動化された ]ときに、`~pointing先$が要素であるならば,それに向けて発火され~MUST。 ~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に対してのみ発火される~SHOULDである (すなわち, `MouseEvent!I の `button$m 値 ~NEQ 0 / `buttons$m 値 ~GT 1 )。 `auxclick^et ~eventは、首~button(標準的な~mouseの左~buttonなど)に対しては,発火されては~MUST_NOT。 首~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の`標的$ ], および[ `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:
- `標的$に結付けられている`作動化の挙動$があるならば、`既定~動作$は,その`作動化の挙動$を実行するもので~MUST(`作動化の誘発と挙動$を見よ)。 ◎ 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による `auxlick^et を受取って取扱う例: ◎ Receiving and handling auxclick for the middle button.
%myLink.addEventListener( "auxclick", function(%e) { if (%e.button === 1) { /* これは既定の挙動 — 例えば ~link上で中央~clickしたときに新たな~tabで開くなど — を防止することになる。 ◎ 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に適した仕方で新たな~tab内に ~linkや非~link~buttonを開くことに注力する様な。 ~tab帯~内の~tabを閉じる様な,~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に可用にならないであろう。 より明確には、 次の例 を見よ。 ◎ 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による `auxlick^et を受取って取扱う例: ◎ Receiving and handling auxlick for the right button
%myDiv.addEventListener("contextmenu", function(%e) { /* この~callは、頁が~eventを受取ったときに,頁に干渉するような文脈~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. */ } });
4.3.4.2. `click^et
◎イ型 `click@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 文脈依存 ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `UIEvent.detail$m: `現在の~click回数$を指示する — 属性~値は、利用者がこの動作を始めたときは 1 になり,その後,各~clickごとに 1 ずつ増加され~MUST。
`click$et ~event型は、利用者が首~pointer~buttonを[ 押してから, 離した ]とき, あるいは[ そのような動作を模造する方式で~pointerが作動化された ]ときに、`~pointing先$が要素であるならば,それに向けて発火され~MUST。 ~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に対してのみ発火される~SHOULDである (すなわち, `MouseEvent!I の `button$m 値は 0 / `buttons$m 値は 1 )。 `click^et ~eventは、副~button(標準的な~mouseの 中央~button/右~button など)に対しては,発火されては~MUST_NOT。 非~首~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装置に加えて、`作動化の誘発と挙動$にて述べたように,要素に対する作動化の一環としても発火され~MUST。 ◎ 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の`標的$ ], および[ `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:
- `標的$に結付けられている`作動化の挙動$があるならば、`既定~動作$は,その`作動化の挙動$を実行するもので~MUST(`作動化の誘発と挙動$を見よ)。 ◎ 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).
- `標的$が~focus可能ならば、`既定~動作$は,その要素に文書~focusを与え~MUST。 ◎ If the event target is focusable, the default action MUST be to give that element document focus.
4.3.4.3. `dblclick^et
◎イ型 `dblclick@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `UIEvent.detail$m: `現在の~click回数$ を指示する
~UAは、[ 要素~上で~pointing装置の首~buttonが 【ある時間内に】 二回~clickされた ]とき,この~eventを発火し~MUST。 ~double-clickの定義は、[ その標的が `mousedown$et / `mouseup$et / `dblclick$et と同じで~MUST ]ことを除いて,環境設定0に依存する。 この~event型は、[ ~clickと~double-clickが同時に生じた場合は `click$et / 他の場合は `mouseup$et ]の後に配送され~MUST。 ◎ 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に対してのみ発火される~SHOULDであり、副~buttonに対して発火されては~MUST_NOT。 ◎ 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の`標的$, および `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. Normally, the typical default actions of the dblclick event type match those of the click event type, with the following additional behavior:
- `標的$が選択-可能ならば、`既定~動作$は,その選択-可能な内容の一部またはすべてを選択するもので~MUST。 後続の各~clickは、その内容の選択-可能な部位を追加で選択して~MAY。 【代表的な例: 初回は単語を選択し, 次回は行全体を選択するなど。】 ◎ If the event target is selectable, the default action MUST be to select part or all of the selectable content. Subsequent clicks MAY select additional selectable portions of that content.
4.3.4.4. `mousedown^et
◎イ型 `mousedown@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作- ~drag/~drop操作を開始する
- ~text選択を開始する
- ~scroll/~panによる対話を開始する(~supportされるなら,中央~mouse~buttonとの組合せで)
次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `UIEvent.detail$m: ( `現在の~click回数$ + 1 ) を指示する。 例えば、 `mousedown$et の直前に~clickが起きていない場合の `UIEvent.detail$m 値は 1 になる。
~UAは、[ ~pointing装置の~buttonが要素~上で押された ]とき,この~eventを発火し~MUST。 ◎ 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.
4.3.4.5. `mouseenter^et
◎イ型 `mouseenter@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `target$m: 注釈文を見よ。
- `MouseEvent.button$m: 0
- `MouseEvent.relatedTarget$m: 変化-前の`~pointing先$。
~UAは、[ `~pointing先$が`有効に変化-$して,ある要素とその子孫たちが成す境界に入った† ]とき、その要素に向けて,この~eventを発火し~MUST。 この~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先か, または その先祖である。
- 要素は、変化-前の~pointing先でも, その子孫でもない。
そのような要素は、同時に複数~存在し得る(変化-前の~pointing先が ~NULL ならば、変化-後の~pointing先と その先祖~要素すべてが該当することになる)。 その場合、該当する各~要素に向けて,最も先祖のものから順に,この~eventを発火することになる(この順序は規範的に明文化されていないが、前~節に述べた 積層された例 における~mouse~event序列を見よ)。
条件を満たす各~要素のうち,変化-後の`~pointing先$ 以外のものは,~eventが生じた時点で`接触判定$の対象から除外されている可能性も考えられる。 その場合、[ そのような要素へは,~eventは発火されない ]とするのが正しい挙動かもしれない。 】
注記: この~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.
4.3.4.6. `mouseleave^et
◎イ型 `mouseleave@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 しない ◎標的 `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `target$m: 注釈文を見よ。
- `MouseEvent.button$m: 0
- `MouseEvent.relatedTarget$m: 変化-後の`~pointing先$。 【原文の記述は “変化-前” を示唆しているが、更新-時の誤りであろう。】
~UAは、[ `~pointing先$が`有効に変化-$して,ある要素とその子孫たちが成す境界から出た† ]とき、その要素に向けて,この~eventを発火し~MUST。 この~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先か, または その先祖である。
- 要素は、変化-後の~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.
4.3.4.7. `mousemove^et
◎イ型 `mousemove@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `MouseEvent.button$m: 0
~UAは、[ `~pointing先$が要素~上で動いた ]とき,その要素に向けて,この~eventを発火し~MUST。 ~pointing装置が動かされる間に~eventが生じる頻度0は[ 実装/装置/~platform ]に特有であるが、持続的な動きに対しては,動きが止まる度にではなく,複数の `mousemove$et ~eventが連続して発火される~SHOULDである。 実装には、即応性と処理能との兼ね合いをとる最適な頻度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操作を始めてから ~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.
注記: 以前は、 `DOM-Level-2-Events$r において,この~eventは`取消~可能$でないと指定されていたが、既存の~UA間の相互運用性を反映するため,変更された。 ◎ This event was formerly specified to be non-cancelable in DOM Level 2 Events [DOM-Level-2-Events], but was changed to reflect existing interoperability between user agents.
4.3.4.8. `mouseout^et
◎イ型 `mouseout@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `target$m: 変化-前の`~pointing先$。
- `MouseEvent.button$m: 0
- `MouseEvent.relatedTarget$m: 変化-後の`~pointing先$。
~UAは、`~pointing先$が`有効に変化-$したとき,前の`~pointing先$が要素であるならば、この~eventをその要素に向けて発火し~MUST。 この~event型は, `mouseleave$et に似るが、浮上すること, および 新たな`~pointing先$が要素の子孫であっても 要素に発火され~MUST点で相違する。 ◎ 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.
4.3.4.9. `mouseover^et
◎イ型 `mouseover@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `MouseEvent.button$m: 0
- `MouseEvent.relatedTarget$m: 変化-前の`~pointing先$。 【原文の記述は “変化-後” を示唆しているが、更新-時の誤りであろう。】
~UAは、`~pointing先$が`有効に変化-$したとき,新たな`~pointing先$が要素であるならば、この~eventをその要素に向けて発火し~MUST。 この~event型は, `mouseenter$et に似るが、浮上すること, および 前の`~pointing先$が要素の子孫であっても 要素に発火され~MUST点で相違する。 ◎ 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.
4.3.4.10. `mouseup^et
◎イ型 `mouseup@et ◎界面 `MouseEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 文脈~menuを呼出す(~supportされるなら,右~mouse~buttonとの組合せで) ◎ Invoke a context menu (in combination with the right mouse button, if supported) ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- `UIEvent.detail$m: ( `現在の~click回数$ + 1 ) を指示する。
~UAは、[ ~pointing装置の~buttonが要素~上で離された ]とき,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when a pointing device button is released over an element.
注記: 多くの実装は、右~mouse~buttonが離されるとき†には、この~eventの既定~動作として,文脈~menuを呼出す。 【†押したときに呼出す実装もある(そのほうが多い?)。】 ◎ Many implementations will invoke a context menu as the default action of this event if the right mouse button is being released.
注記: ~browserなど,実装~環境によっては、 `mouseup$et ~eventは,~pointing装置が~UAの境界から出たときにも発火され得る。 例: 利用者が~mouse~buttonを押して~drag操作を始めたときなど。 ◎ 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
- `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
4.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.
【定義追加:】 `計測~単位@ とは、画素~数, 行~数, 頁~数の総称である。
原文には、これらが何の計量に基づくかは,定義されていない。 次の定義が考えられるが:
- 画素~数は、 CSS pixel 単位(機器~画素~単位ではなく)。
- 行数は、`根~要素$の CSS `line-height^c ~propに基づく。
- 頁~数は、よくある~computer~screenの下では, CSS 表示域( viewport )の寸法に基づく。
注記: 利用者は、~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の複数の発火において一貫して~MUST。 ~UAは、 `wheel$et ~eventの既定~動作として~scrollする場合の`~delta$の符号を, `右手~座標系@ で — すなわち,[ X/Y/Z ]軸の正~方向が,文書の[ 右方/下方/奥方(利用者から遠ざかる) ]を向くように — 与える~SHOULDである。 ◎ 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の物理的な操作に対する解釈は、個々の~UAによって(あるいは~UAや~hardwareの環境設定に依存して)異なることもある。 例えば,~trackpadの淵で上から下へ~swipeされたとき、下への頁~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).
4.4.1. ~ifc `WheelEvent^I
この仕様にて導入された。 ◎ Introduced in this specification
`WheelEvent^I ~ifcは、 `wheel$et ~eventに特有の文脈的~情報を供する。 ◎ The WheelEvent interface provides specific contextual information associated with wheel events.
`WheelEvent^I ~ifcの~instanceを作成するためには、その構築子に `WheelEventInit^I 辞書(省略可)を渡して呼び出す。 ◎ To create an instance of the WheelEvent interface, use the WheelEvent constructor, passing an optional WheelEventInit dictionary.
4.4.1.1. `WheelEvent^I
[Constructor(~DS %type, optional `WheelEventInit$I %eventInitDict),
`Exposed$=Window]
interface `WheelEvent@I : `MouseEvent$I {
// `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;
~RA double `deltaX$m;
~RA double `deltaY$m;
~RA double `deltaZ$m;
~RA unsigned long `deltaMode$m;
};
- `DOM_DELTA_PIXEL@m
- `deltaMode$m 属性がこの値をとる場合、`~delta$に対する`計測~単位$は,画素~数で~MUST。 これは、ほとんどの~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の行~数で~MUST。 これは,多くの~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, または 頁区分 ]に基いて定義される頁~数で~MUST。 ◎ 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されることになる(いずれかの`計測~単位$による)計測で~MUST。 他の場合、これは[ 当該の軸~~廻りの~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.
- `未初期化~値$: 0.0 ◎ The un-initialized value of this attribute MUST be 0.0.
- `deltaMode@m
- `deltaMode^m 属性~値は、`~delta$値に対する`計測~単位$を指示する。 既定~値は `DOM_DELTA_PIXEL$m (画素~数)。 ◎ deltaMode, of type unsigned long, readonly • 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 定数 ]に設定され~MUST。 精確な計測は,[ 装置/~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.
4.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上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ 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 • double deltaZ = 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.
4.4.2. 各種~wheel~event型
4.4.2.1. `wheel^et
◎イ型 `wheel@et ◎界面 `WheelEvent$I ◎同期 なし ◎浮上 する ◎標的 `Element$I ◎取消 文脈依存 ◎構 Yes ◎既定動作 文書を~scroll(または~zoom)する ◎ Scroll (or zoom) the document ◎文脈次を除き,`各種~mouse~eventに共通する文脈~情報$にて与えられる:
- ~wheelが~pointing装置に結付けられていない場合、 `MouseEvent!I の[ `screenX$m, `screenY$m, `clientX$m, `clientY$m, `button$m, `buttons$m ]は、 0 にされる。 また、 `relatedTarget$m は 【明示的に記されていないが,おそらく】 ~NULL (`未初期化~値$)。
- `WheelEvent!I の[ `deltaX$m / `deltaY$m / `deltaZ$m ]は、[ X / Y / Z ]軸~~廻りの~wheel装置の動きを~~反映する量であって、[ 頁が `deltaMode$m 単位に従って,その軸に沿って~scrollする量 ]であるか,または実装に特有の値。
- `WheelEvent.deltaMode$m は、[ `deltaX$m / `deltaY$m / `deltaZ$m ]属性に対する,(いずれかの`計測~単位$を表現する)単位~指示子。
~UAは、[ ~mouse~wheelが,いずれかの軸で回転された, または 等価な入力~装置(~mouse-ballや, 一部の~tabletや~touchpad, 等々)が そのような動作を模倣した ]とき,この~eventを発火し~MUST。 同時に複数の軸が回転された場合の~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 しては~MUST_NOT(あるいは,何であれ、この~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.
4.4.2.2. `wheel^et ~eventの取消~可否
`wheel$et ~eventに対し `preventDefault()$m を~callした場合、~scrollするのを防止したり, 中断し得る。 ~scroll処理能を最大にするため,~UAは、~scrollに結付けられた `wheel^et ~event連列に対し,各~eventごとに処理されるまで — 取消されたかどうか見るために — 待機しなくとも~MAY。 そのような事例では、~UAは,最初の `wheel^et ~eventだけ取消~可能にすることも可能である — その場合、残りの各 `wheel^et ~eventに対しては, `cancelable$m ~propを ~F に設定する~SHOULDである。 ◎ 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 it is possible that only the first wheel event of a scrolling sequence is cancelable. For the rest of the wheel events the user agent should set their cancelable property to false.
4.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, ...).
4.5.1. ~ifc `InputEvent^I
DOM3 にて導入された。 ◎ Introduced in DOM Level 3
4.5.1.1. `InputEvent^I
[Constructor(~DS %type, optional `InputEventInit$I %eventInitDict), `Exposed$=Window] interface `InputEvent@I : `UIEvent$I { readonly attribute ~DS? `data$m; readonly attribute boolean `isComposing$m; };
- `data@m
- ~IMEにより生成される~Unicode文字 `Unicode$r 並びの値を保持する(`空~文字列$にもなり得る)。 一連の文字は、 `UAX15$r にて定義される~Unicode正規化形 NFC による定義に従って正規化される~SHOULDである。 ◎ data, of type DOMString, readonly, nullable • 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
- 入力~eventが組成~sessionの一部として — すなわち, `compositionstart$et ~eventの後, かつ 対応する `compositionend$et ~eventの前に — 生じたならば~T。 ◎ isComposing, of type boolean, readonly • 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.
4.5.1.2. `InputEventInit^I
dictionary `InputEventInit@I : `UIEventInit$I { ~DS? `data@m = ""; boolean `isComposing@m = false; };
この辞書の各~memberは、 `InputEvent$I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ data, of type DOMString, nullable, defaulting to "" • Initializes the data attribute of the InputEvent object. isComposing of type boolean, defaulting to false ◎ isComposing, of type boolean, defaulting to false • Initializes the isComposing attribute of the InputEvent object.
4.5.2. 入力~event序列
この仕様にて定義される入力~eventは、相互相対順序の下で生じ~MUST。 ◎ 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 |
4.5.3. 各種~入力~event型
◎ The Input event types are listed below.
4.5.3.1. `beforeinput^et
◎イ型 `beforeinput@et ◎界面 `InputEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I — 特定的には, `HTMLInputElement$I 等の~control, または `contenteditable^a 属性が可能化されている任意の `Element$I 。 ◎ Element (specifically: control types such as HTMLInputElement, etc.) or any Element with contenteditable attribute enabled ◎取消 可 ◎構 Yes ◎既定動作 ~DOM要素を更新する ◎ Update the DOM element ◎文脈次を除き,`各種~入力~eventに共通する文脈~情報$にて与えられる:
- `InputEvent.data$m は、内容が削除されることになる場合は,~NULLにされてよい。
~UAは、~DOMが更新されつつあるとき,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event when the DOM is about to be updated.
4.5.3.2. `input^et
◎イ型 `input@et ◎界面 `InputEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I — 特定的には, `HTMLInputElement$I 等の~control, または `contenteditable^a 属性が可能化されている任意の `Element$I 。 ◎ Element (specifically: control types such as HTMLInputElement, etc.) or any Element with contenteditable attribute enabled ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~入力~eventに共通する文脈~情報$にて与えられる:
- `InputEvent.data$m は、内容が削除された場合には,`空~文字列$にされてよい。
~UAは、~DOMが更新された直後に,この~eventを発火し~MUST。 ◎ A user agent MUST dispatch this event immediately after the DOM has been updated.
各種~入力~eventに共通する文脈~情報
集約簡略化各種~入力~eventに共通する文脈~情報を以下に挙げる。 個々の~event型にて定義されるものは、これらより優先される:
- `target$m
- 更新されつつある/された`~event標的$。 ◎ 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連列, または `~IME$が作動中の間に配送されたものであれば(`組成~event$が配送されているときなど) ~T / ~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.
4.6. ~keyboard~event型
~keyboard~eventは、装置~依存である — すなわち,それは、[ 入力~装置の能力, および 【物理的な~keyが】 ~OSにてどう~mapされているか ]に依拠する。 詳細は、~keyboard~eventと`組成~event$とを組合せる用例も含め,`~keyboard~eventと~key値$ 節に。 文字~生成~装置によっては,~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用の入力を供する唯一の方式0である。 編集~時には、~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.
4.6.1. ~ifc `KeyboardEvent^I
この仕様にて導入された。 ◎ Introduced in this specification
`KeyboardEvent!I ~ifcは、~keyboard装置に特有の文脈的~情報を供する。 各~keyboard~eventは、値を利用して~keyを参照する。 ~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 ~ifcは、一部の共通的な修飾~key用の簡便な属性:[ `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m ]を供する。 これらの属性【への取得~access】は、順に,[ `Control^cap, `Shift^cap, `Alt^cap, `Meta^cap ]を引数に `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 ~ifcの~instanceを作成するためには、その構築子に `KeyboardEventInit$I 辞書(省略可)を渡して呼び出す。 ◎ To create an instance of the KeyboardEvent interface, use the KeyboardEvent constructor, passing an optional KeyboardEventInit dictionary.
4.6.1.1. `KeyboardEvent^I
[Constructor(~DS %type, optional `KeyboardEventInit$I %eventInitDict),
`Exposed$=Window]
interface `KeyboardEvent@I : `UIEvent$I {
// `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;
~RA ~DS `key$m;
~RA ~DS `code$m;
~RA unsigned long `location$m;
~RA boolean `ctrlKey$m;
~RA boolean `shiftKey$m;
~RA boolean `altKey$m;
~RA boolean `metaKey$m;
~RA boolean `repeat$m;
~RA boolean `isComposing$m;
boolean `getModifierState$m (~DS %keyArg);
};
- `DOM_KEY_LOCATION_STANDARD@m
- 作動化された~keyは、~keyの左/右 ~versionとして判別されるものではなく,かつ 十key( `NumLock^cap ~keyは除く), または それに対応する仮想~keyからも出生されていないことを指示する。 ◎ 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 ~key。 ◎ The Q key on a PC 101 Key US keyboard.
~PC101US~keyboardの `NumLock^cap ~key。 ◎ The NumLock key on a PC 101 Key US keyboard.
~PC101US~keyboardの主区画に所在する `1^cap ~key。 ◎ The 1 key on a PC 101 Key US keyboard located in the main section of the keyboard.
- `DOM_KEY_LOCATION_LEFT@m
- 作動化された~keyは、左~key所在から出生されていることを指示する(当の~keyに対し複数の所在がある場合に限る)。 ◎ The key activated originated from the left key location (when there is more than one possible location for this key).
- ~PC101US~keyboardの左 `Control^cap ~key。 ◎ The left Control key on a PC 101 Key US keyboard.
- `DOM_KEY_LOCATION_RIGHT@m
- 作動化された~keyは、右~key所在から出生されていることを指示する(当の~keyに対し複数の所在がある場合に限る)。 ◎ The key activation originated from the right key location (when there is more than one possible location for this key).
- ~PC101US~keyboardの 右 `Shift^cap ~key。 ◎ The right Shift key on a PC 101 Key US keyboard.
- `DOM_KEY_LOCATION_NUMPAD@m
- 作動化された~keyは、十key, または それに 対応する仮想~keyから出生されていることを指示する(当の~keyに対し複数の所在がある場合に限る)。 `NumLock^cap ~keyは常に,所在 `DOM_KEY_LOCATION_STANDARD$m を伴って符号化される~SHOULDであることに注意。 ◎ 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 ~key。 ◎ The 1 key on a PC 101 Key US keyboard located on the numeric pad.
- `key@m
- `key^m は押された~keyに対応する`~key値$を保持する。 ◎ key, of type DOMString, readonly • 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^m は、押されている物理的~keyを識別する文字列を保持する。 値は,現在の~keyboard~layoutや修飾~状態からは影響されないので、同じ~keyからは常に同じ値が返されることになる。 ◎ code, of type DOMString, readonly ◎ 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^m 属性は、装置~上の~keyの論理的な所在の指示を包含する。 ◎ location, of type unsigned long, readonly ◎ The location attribute contains an indication of the logical location of the key on the device.
- この属性は、[ 装置~上の~keyの所在を指示する, `DOM_KEY_LOCATION-…^m 定数 ]のうちの,いずれかに設定され~MUST。 ◎ This attribute MUST be set to one of the DOM_KEY_LOCATION constants to indicate the location of a key on the device.
- ~keyの再mapを許容する~UAは、再mapされた~keyに対する `location$m 値を,新たな~keyに適切な値に設定し~MUST。 例えば、 `ControlLeft$kC ~keyが `KeyQ$kC ~keyに再mapされたなら、この属性は `DOM_KEY_LOCATION_STANDARD$m に設定され~MUST。 逆に, `KeyQ$kC ~keyが左右いずれかの `Control^cap ~keyに再mapされた場合、それに応じて,この属性も[ `DOM_KEY_LOCATION_LEFT$m, `DOM_KEY_LOCATION_RIGHT$m ]のいずれかに設定され~MUST。 ◎ 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
- `Control^cap ( control )修飾が作動中であったならば~T ◎ ctrlKey, of type boolean, readonly ◎ true if the Control (control) key modifier was active.
- `未初期化~値$: ~F ◎ The un-initialized value of this attribute MUST be false.
- `shiftKey@m
- `Shift^cap ( shift )修飾が作動中であったならば~T。 ◎ shiftKey, of type boolean, readonly ◎ true if the shift (Shift) key modifier was active.
- `未初期化~値$: ~F ◎ The un-initialized value of this attribute MUST be false.
- `altKey@m
- `Alt^cap ( alternative, 別名 `Option^cap )修飾が作動中であったならば~T。 ◎ altKey, of type boolean, readonly ◎ true if the Alt (alternative) (or "Option") key modifier was active.
- `未初期化~値$: ~F ◎ The un-initialized value of this attribute MUST be false.
- `metaKey@m
- `Meta^cap( meta )修飾が作動中であったならば~T。 ◎ metaKey, of type boolean, readonly ◎ true if the meta (Meta) key modifier was active.
- 注記: Macintosh ~system上の `Command^cap ( `⌘^cap )~key修飾は この~key修飾を利用して表現される。 ◎ 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
- ~keyが持続的に押されているならば~T。 ~keyが~~押下げ続けられている下では、[ `keydown$et, `beforeinput$et, `input$et ]~eventが、この順序で,~system環境設定から決定される頻度で,繰り返され~MUST。 ~keyの長押し に対する挙動を備える携帯機器においては、 `repeat$m 属性~値に ~T を伴う最初の~key~eventが,その挙動を指示する~~役割を果たさ~MUST。 繰り返しが始まるために~keyが押され続ける必要がある時間の長さは、環境設定に依存する。 ◎ repeat, of type boolean, readonly ◎ 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
- ~key~eventが組成~sessionの一部として — すなわち, `compositionstart$et ~eventの後, かつ 対応する `compositionend$et ~eventの前に — 生じたならば~T。 ◎ isComposing, of type boolean, readonly ◎ 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
- `~key値$を利用して,ある修飾の状態を照会する。 ◎ Queries the state of a modifier using a key value.
- 引数 %keyArg には、修飾`~key値$を与える。 妥当な`修飾~key$は、 `UIEvents-Key$r の`修飾~key一覧$にて定義される。 ◎ 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.
4.6.1.2. `KeyboardEventInit^I
dictionary `KeyboardEventInit@I : `EventModifierInit$I { ~DS `key@m = ""; ~DS `code@m = ""; unsigned long `location@m = 0; boolean `repeat@m = false; boolean `isComposing@m = false; };
この辞書の各~memberは、 `KeyboardEvent$I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ 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の~keyに結付けられている数的~値 ]を指示する一方、 `charCode^m 属性は[ その~keyに結付けられている文字の~ASCII値 ]を指示し( `keyCode^m 値と同じにもなり得る),適用-可能なのは`文字~値$を生産する~keyに限られる。 ◎ 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.
更なる情報は、参考~付録 旧来の~key属性 を見よ。 ◎ For more information, see the informative appendix on Legacy key attributes.
注記: 既存の内容との互換性のため,仮想~keyboard — ~screenに基づく入力~装置~上の~software~keyboardなど — は、物理的~keyを処理しなくとも,通常の範囲の~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環境設定においては、一部の~key~eventやその値は,利用中の`~IME$により抑止されることがある。 ◎ In some implementations or system configurations, some key events, or their values, might be suppressed by the IME in use.
4.6.2. ~keyboard~eventに対する~keyの所在
`location$m 属性は、~keyboard上の異なる物理的~keyから同じ`~key値$が生成される場合に、それらを~~区別するために利用できる。 例えば、左右 `Shift^cap ~key,あるいは 物理的~矢印~keyと( `NumLock^cap が off のときの)~numpad上の矢印~key。 ◎ 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上に所在が複数あるような特別な~keyに対する,妥当な `location$m 値は、次の表に定義される: ◎ 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 |
この表に挙げられていない他のすべての~keyに対する `location$m 属性は、常に `DOM_KEY_LOCATION_STANDARD$m に設定され~MUST。 ◎ For all other keys not listed in this table, the location attribute MUST always be set to DOM_KEY_LOCATION_STANDARD.
4.6.3. ~keyboard~event序列
この仕様にて定義される~keyboard~eventは、与えられたどの~keyに対しても,相互相対順序の下で生じる: ◎ 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 | (`文字~値$を生産する~keyに対してのみ) ◎ (only for keys which produce a character value) |
この~keyに関係する`既定~動作$ — 文字を~DOMの中へ挿入するなど — があれば,それが行われる。 ◎ Any default actions related to this key, such as inserting a character in to the DOM. | ||
3. | `input$et | (~DOMを更新させた~keyに対してのみ) ◎ (only for keys which have updated the DOM) |
一定時間,~keyが押下げられたとき、生じ得るような~event(下を見よ)。 ◎ Any events as a result of the key being held for a sustained period (see below). | ||
4. | `keyup$et |
一定時間,~keyが押下げられた場合、環境に依存する頻度で,次の~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 | (`文字~値$を生産した~keyに対してのみ) ◎ (only for keys which produce a character value) |
この~keyに関係する`既定~動作$ — 文字を~DOMの中へ挿入するなど — があれば,それが行われる。 ◎ Any default actions related to this key, such as inserting a character in to the DOM. | ||
3. | `input$et | (~DOMを更新させた~keyに対してのみ) ◎ (only for keys which have updated the DOM) |
注記: 概して、特定0の~keyに結付けられている`既定~動作$があれば, `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).
~key~eventの`標的$は、~keyboard活動を処理している現在の被focus要素である。 これは、~HTML `input^e 要素か,編集-可能な~text用の要素になることが多いが、`~host言語$における非~text目的の~keyboard入力 — 加速~keyの作動化や 一部の他の挙動の誘発など — を受容するように定義された要素になることもある。 相応しい被focus要素が無い場合の~event標的は、[ 可用なら ~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標的$は、一連の~key~event間で変化し得る。 例えば, `Tab^cap ~key用の `keydown$et ~eventの`標的$は、同じ~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.
4.6.4. 各種~keyboard~event型
4.6.4.1. `keydown^et
◎イ型 `keydown@et ◎界面 `KeyboardEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作文脈依存:
- `beforeinput$et & `input$et ~event
- `~text組成~system$を起動0させる
- `blur$et & `focus$et ~event
- `keypress$et ~event(~support有りなら)
- `作動化の挙動$
- その他の~event
~UAは、[ ~keyが押された ]とき,この~eventを発火し~MUST。 `keydown$et ~event型は装置~依存であり, 入力~装置の能力, および それらが~OSにおいて~mapされている方法に依拠する。 この~event型は,`~key~mapping$の後に生成され~MUST。 この~event型は、同じ~keyに結付けられている[ `beforeinput$et, `input$et, `keyup$et ]~eventの前に配送され~MUST。 ◎ 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の既定~動作は,~keyに依存する: ◎ The default action of the keydown event depends upon the key:
- ~keyが文字に結付けられている場合の既定~動作は、[ `beforeinput$et ~eventと, ~~後続する `input$et ~event ]を発火するもので~MUST。 ~keyが複数の文字に結付けられている場合(~macroを伴うものや ~dead-keyからなる連列など)の既定~動作は、各~文字に対し[ `beforeinput$et, `input$et ]~event対を発火するもので~MUST。 ◎ 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
- ~keyが`~text組成~system$に結付けられている場合の既定~動作は、その~systemを起動0させるもので~MUST。 ◎ If the key is associated with a text composition system, the default action MUST be to launch that system
- ~keyが `Tab^cap ~keyの場合の既定~動作は、`~focus~event$型にて述べた様に、文書~focusを現在の被focus要素(もしあれば)から新たな被focus要素へ移転させるもので~MUST。 ◎ 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
- ~keyが `Enter^cap / `~SPACEBAR^cap ~keyであって, かつ 現在の~focusが状態~変化-中の要素~上にある場合の既定~動作は、[ `click$et ~eventに加えて,~UAにより~supportされているなら `DOMActivate$et ~event ]を発火するもので~MUST (詳細は、`作動化の誘発と挙動$に) ◎ If the key is the 'Enter' or ' ' 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型は,発火されては~MUST_NOT。 また、結付けられている動作も,遂行されては~MUST_NOT。 ◎ 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は、伝統的に,`文字~値$を生産するものだけでなく,何か~keyが~~押されたかどうかの検出-法にも結付けられている。 ◎ The keydown and keyup events are traditionally associated with detecting any key, not just those which produce a character value.
4.6.4.2. `keyup^et
◎イ型 `keyup@et ◎界面 `KeyboardEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 なし ◎文脈 `各種~keyboard~eventに共通する文脈~情報$にて与えられる。 ◎ • Event.target : focused element processing the key event or if no element focused, then the body element if available, otherwise the root element • UIEvent.view : Window • UIEvent.detail : 0 • KeyboardEvent.key : the key value of the key pressed. • KeyboardEvent.code : the code value associated with the key’s physical placement on the keyboard. • KeyboardEvent.location : the location of the key on the device. • KeyboardEvent.altKey : true if Alt modifier was active, otherwise false • KeyboardEvent.shiftKey : true if Shift modifier was active, otherwise false • KeyboardEvent.ctrlKey : true if Control modifier was active, otherwise false • KeyboardEvent.metaKey : true if Meta modifier was active, otherwise false • KeyboardEvent.repeat : true if a key has been depressed long enough to trigger key repetition, otherwise false • KeyboardEvent.isComposing : true if the key event occurs as part of a composition session, otherwise false ◎表終~UAは、[ ~keyが離された ]とき,この~eventを発火し~MUST。 `keyup$et ~event型は装置~依存であり, 入力~装置の能力, および それらが~OSにおいて~mapされている方法 に依拠する。 この~event型は,`~key~mapping$の後に生成され~MUST。 この~event型は、 同じ~keyに結付けられている[ `keydown$et, `beforeinput$et, `input$et ]~eventの後に発火され~MUST。 ◎ 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は、伝統的に,`文字~値$を生産するものだけでなく,何か~keyが~~押されたかどうかの検出-法にも結付けられている。 ◎ 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
- ~key~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
- 押された~keyの`~key値$。 ◎ KeyboardEvent.key : the key value of the key pressed.
- `code$m
- ~keyの~keyboard上での物理的~~位置に結付けられている~code値 ◎ KeyboardEvent.code : the code value associated with the key’s physical placement on the keyboard.
- `location$m
- 装置~上の~keyの所在。 ◎ 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
- ~keyの繰返しを誘発するに十分~長く~keyが押下げられているならば ~T / 他の場合 ~F ◎ KeyboardEvent.repeat : true if a key has been depressed long enough to trigger key repetition, otherwise false
- `isComposing$m
- ~key~eventが,組成~sessionの一部として生じたならば ~T / 他の場合 ~F ◎ KeyboardEvent.isComposing : true if the key event occurs as part of a composition session, otherwise false
4.7. 組成~event
組成~event( Composition Events )は、~~普通の~keyboardにない文字を利用できるように,`~keyboard~event$によるものに[ 追補的な, あるいは代替する ]方式で,~textを入力する手段を供する。 組成~eventは、例えば,次のために利用され得る:
- 文字に標準的な~US~keyboardには無い~accentを追加する。
- 多くのアジア圏の言語において,基底~成分/字種から表語文字を築き上げる。
- 携帯機器~keyboardで,押されている~keyの組合せから 単語を選択する。
- 発話~認識~処理器を利用して,一連の~voice~commandを~textに変換する。
`組成~event$を~keyboard~eventと組合せる用例については、`~keyboard~eventと~key値$ 節に。
◎ 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 §5 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” 間で persisting【?】。 ◎ 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節 を見よ。 ◎ 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に必要とされる~dataを公開するとは限らないので、 作動中の組成~文字列( “変換窓( Reading Window )” や “候補~選択~menuに示されるもの” )は,この~ifcを通して可用でないこともある — その場合、選択は`空~文字列$として表現されることもある。 ◎ 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.
4.7.1. ~ifc `CompositionEvent^I
この仕様にて導入された。 ◎ Introduced in this specification
`CompositionEvent^I ~ifcは、`組成~event$に特有の文脈的~情報を供する。 ◎ The CompositionEvent interface provides specific contextual information associated with Composition Events.
`CompositionEvent^I ~ifcの~instanceを作成するためには、その構築子に `CompositionEventInit^I 辞書(省略可)を渡して呼び出す。 ◎ To create an instance of the CompositionEvent interface, use the CompositionEvent constructor, passing an optional CompositionEventInit dictionary.
4.7.1.1. `CompositionEvent^I
[Constructor(~DS %type, optional `CompositionEventInit$I %eventInitDict), `Exposed$=Window] interface `CompositionEvent@I : `UIEvent$I { ~RA ~DS `data$m; };
- `data@m
- `data^c は~IMEにより生成された一連の`文字~値$を保持する。 これは、長さ 1 以上の~Unicode文字~連列をとることもある。 一連の文字は、 `UAX15$r にて定義される~Unicode正規化形 NFC による定義に従って正規化される~SHOULDである。 この属性は、`空~文字列$になることもある。 ◎ data, of type DOMString, readonly ◎ 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).
4.7.1.2. `CompositionEventInit^I
dictionary `CompositionEventInit@I : `UIEventInit$I { ~DS `data@m = ""; };
この辞書の各~memberは、 `CompositionEvent!I ~obj上の同じ名前の属性を初期化する。 それぞれがとり得る値とその意味については、その~ifc定義の記述を見よ。 ◎ data, of type DOMString, defaulting to "" • Initializes the data attribute of the CompositionEvent object to the characters generated by the IME composition.
4.7.2. 組成~event序列
この仕様にて定義される`組成~event$は、次による相互相対順序の下で生じ~MUST: ◎ 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 |
4.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 |
4.7.4. 組成~eventの取消~法
`keydown$et ~eventが取消された場合、その `keydown$et の結果として発火されることになる どの`組成~event$も,発火される~SHOULDでない: ◎ 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 の呼出しにより,防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). |
`組成~event$は発火されない。 ◎ No Composition Events are dispatched | ||
2. | `keyup$et |
初期 `compositionstart$et ~eventが取消された場合、~text組成~sessionは,終了される~SHOULDである。 `compositionend$et ~eventは、 組成~sessionが終了されたかどうかに関わらず, 送信され~MUST。 ◎ 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 の呼出しにより,防止された。 ◎ The default action is prevented, e.g., by invoking preventDefault(). |
`組成~event$は発火されない。 ◎ No Composition Events are dispatched | ||
3. | `compositionend$et | |
4. | `keyup$et |
4.7.5. 組成~時における~key~event
組成~sessionの最中でも、依然として[ `keydown$et, `keyup$et ]~eventは送信され~MUST — その `KeyboardEvent.isComposing$m 属性は ~T にされ~MUST。 ◎ 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 | これが組成を起動させた~key~eventである。 ◎ This is the key event that initiates the composition. |
2. | `compositionstart$et | ||
3. | `compositionupdate$et | ||
4. | `keyup$et | ~T | |
... | 組成~sessionの最中に送信された どの~key~eventも, `KeyboardEvent.isComposing$m は ~T に設定され~MUST。 ◎ Any key events sent during the composition session MUST have isComposing set to true. | ||
5. | `keydown$et | ~T | これが組成を終わらせた~key~eventである。 ◎ This is the key event that exits the composition. |
6. | `compositionend$et | ||
7. | `keyup$et | ~F |
4.7.6. 組成~sessionの間の入力~event
組成~sessionの間は、その `compositionupdate$et は, `beforeinput$et が送信された後, かつ `input$et が送信される前に発火され~MUST。 ◎ 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 |
4.7.7. 各種~組成~event型
4.7.7.1. `compositionstart^et
◎イ型 `compositionstart@et ◎界面 `CompositionEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 可 ◎構 Yes ◎既定動作 `~text組成~system$が可能化されているならば,新たな組成~sessionを開始する。 ◎ Start a new composition session when a text composition system is enabled ◎文脈次を除き,`各種~組成~eventに共通する文脈~情報$にて与えられる:
- `CompositionEvent.data$m: 編集-中の文字列, または `空~文字列$
~UAは、`~text組成~system$が可能化されている下で,[ ~textの一節を組成する準備として,新たな組成~sessionが始まりつつある(または,`~text組成~system$に依存して始まった) ]とき,この~eventを発火し~MUST。 この~event型は、装置に依存し,[ ~text変換~systemの能力, ~OSに~mapされる方法 ]に依拠することもある。 この~event型は、~IMEへの~~入力が~keyboardから給される場合は, `keydown$et ~eventの後に生成されるが、[ 発話/手書き ]認識~systemにおいては ~keyboard~eventを伴わずに送信されて~MAY。 実装は、 `compositionstart$et ~eventの `CompositionEvent.data$m 属性を,文書にて現在(編集/置換~用に)選択されている~textで拡充しても~MAY — そうしない場合、`空~文字列$にし~MUST。 ◎ 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が改変される前に,発火され~MUST。 この~eventの,`~text組成~system$用の既定~動作は、新たな組成~sessionを開始させる。 この~eventが取消された場合、`~text組成~system$は,現在の組成~sessionを破棄する~SHOULDである。 ◎ 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$~windowを閉じるなど)とは、別物である。 ◎ 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.
4.7.7.2. `compositionupdate^et
◎イ型 `compositionupdate@et ◎界面 `CompositionEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~組成~eventに共通する文脈~情報$にて与えられる:
- `CompositionEvent.data$m: 組成~sessionの現在の結果を成す文字列。 内容が削除された場合には`空~文字列$になることもある。
~UAは、[ 組成~sessionの最中に,`~text組成~system$が その作動中の~text一節を新たな文字で更新するとき ]に,この~eventを発火する~SHOULDである。 また、配送するときは, `CompositionEvent.data$m 値にその更新を反映させ~MUST。 ◎ 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との同期を保つ ]ような `~text組成~system$においては、 `compositionupdate$et ~eventは,その~controlが更新される前に配送され~MUST。 ◎ 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は,組成~処理-の最中には発火されないことになる。 ◎ 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.
4.7.7.3. `compositionend^et
◎イ型 `compositionend@et ◎界面 `CompositionEvent$I ◎同期 あり ◎浮上 する ◎標的 `Element$I ◎取消 不可 ◎構 Yes ◎既定動作 なし ◎文脈次を除き,`各種~組成~eventに共通する文脈~情報$にて与えられる:
- `CompositionEvent.data$m: 組成~sessionの最終的な結果を成す文字列。 内容が削除されたり, 組成~処理-が取消された場合など、`空~文字列$になることもある。
~UAは、[ `~text組成~system$が 現在の組成~sessionを 完了した, または取消された ]とき,この~eventを発火し~MUST。 この~eventは、~controlが更新された後に配送され~MUST。 ◎ 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に共通する文脈~情報$にて与えられる。
5. ~keyboard~eventと~key値
この節では、~keyboard~eventに関して必要とされる情報を包含する: ◎ This section contains necessary information regarding keyboard events:
- ~keyboard~layout, ~mapping, `~key値$ についての説明。 ◎ Explanation of keyboard layout, mapping, and key values.
- `~dead-key$や修飾~keyなどの、~key間の関係。 ◎ 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と漢字を利用する。 ◎ This section uses Serbian and Kanji characters which could be misrepresented or unavailable in the PDF version or printed version of this specification.
5.1. ~keyboard入力
~INFORMATIVE完全な~keyboardの各~keyの関係性には,三つの別々の側面があり、いずれも,特に ~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上での物理的~keyの 寸法, ~size, ~~配置 ◎ Mechanical layout: the dimensions, size, and placement of the physical keys on the keyboard
- 視覚的~目印: 各~keyを印字する~label(または 銘( legend )) ◎ Visual markings: the labels (or legends) that mark each key
- 機能上の~mapping: 各~keyに対する 抽象的な ~key ↔ 値の結付け。 ◎ Functional mapping: the abstract key-value association of each key.
この仕様は、 `key^m 値 および `code^m 値 を通して,機能上の~mappingのみを定義するが、背景として, ~key銘 についても概括する。 ◎ This specification only defines the functional mapping, in terms of key values and code values, but briefly describes key legends for background.
5.1.1. ~key銘
~INFORMATIVE~key銘とは、その ~key~cap(~keyの物理的0~switchを覆う “~cap” )上に印刷されたり, 彫り込まれている,視覚的~目印である。 この種の目印は、通常は,その~keyに対する~keystrokeが生産するような, 1 つ以上の文字からなる(例: `G^kGl, `8^kGl, `ш^kGl ), あるいは その~keyの機能を指示する名前や記号(例: `Shift^cap を指示する上向き矢印 `⇧^kGl, 文字列 "Enter" など)。 ~keyは、この目印で指されることが多い(例: “ Shift + F ~keyを押してください。” )。 しかしながら、~keyの視覚的な見かけは,その~digital表現とは~~関係ないものであり、多くの環境設定で,全く~~正確でないものにもなり得る。 `Enter^cap などの 制御~key/~function~key であっても,機能性が異なるものや, 文字~keyに~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等価な記号があっても,通常は文字を生産しない~keyを備えている。 例えば, `Shift^cap ~keyには、記号 `⇧^kGl (~Unicode符号位置 `21E7^U )が付けられることもあるが, `Shift^cap ~keyだけ押しても この`文字~値$を生産することはないし, `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.
5.2. ~key~code
~keyboard~eventに結付けられている物理的~keyを識別するときは、~keyboard~eventの `code$m 属性で指示される~key~codeを利用できる。 それは、 USB Usage ID に似た,~vendor中立の(~scancodeに似た)低~level値を供する。 ◎ 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 属性の首~目的は、~keyを その物理的~所在に基づいて識別するための,首尾一貫する仕方を供することである。 加えて、~keyboardの各~keyに(現在の~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].
5.2.1. `code^m 属性の動機
標準的な~PC~keyboardが備えている一連の~keyが生成する `key$m 値は、利用者が現在~選択している(利用している書記体系に適切な)~keyboard~layoutにより異なる。 このような~~状況下では、~keyをその物理的~所在に基づいて検出するような~codeを書くことは困難になる — ~codeが,どの `key^m 値を検査すればよいか知るためには、現在~有効な~layoutがどれなのかを知る必要があるので。 現実の例として、~player移動を制御するために[ `W^kGl, `A^kGl, `S^kGl, `D^kGl ]~keyを利用する~gameがある。 `code$m 属性は、それを検査するための,現在の~keyboard~layoutに影響されない, 安定的な値を供して、この問題を解消する。 ◎ 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状態にも依存する。 このため、修飾~keyと他の~keyが[ 押される/離される ]順序も, `key$m 属性に格納される値に影響し得る。 `code$m 属性は、 現在の~keyboard~layoutに影響されない, 安定的な値を供して、この問題を解消する。 ◎ 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.
5.2.2. `key^m と `code^m の関係性
- `key^m
- `key$m 属性に意図されている用途は、押されている~keyの意味に基づくふるまいを得ることである — その値には、現在の~keyboard~layoutに加えて,~IMEも織り込まれる( ~dead-key には,一意な `key^m 値が与えられる)。 例えば、[ ~keyが修飾~keyを伴うかどうかや ~~素の修飾~key ]を検出する利用~事例がある(例: ~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 属性に意図されている用途は、利用者により押された~keyそのもの — ~keyboard~layoutにより改変されないままの~key — に基づくふるまいを得ることである。 例えば、~gameにおける移動~制御~用に[ `W^kGl, `A^kGl, `S^kGl, `D^kGl ]~keyを検出したり、すべての~keyを~trapする(例: すべての~keyを遠隔~hostに送信する遠隔~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).
5.2.3. ~code例
左右 Alt ~keyの取扱い: ◎ 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 | `AltGr$kY | `AltRight$kC | `DOM_KEY_LOCATION_RIGHT^m |
この例は、 `key$m 属性を検査すれば,左右どちらの `Alt^cap ~keyが押されたか気にせずに `Alt^cap と照合できることを示している。 `code$m 属性を検査すれば,現在~有効な~layoutが何かを気にすることなく 右~Alt~key( `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 / `AltGr^cap ~keyは,それぞれ 1 個しかないが, 左/右 の所在は維持されることに注意。 ◎ Note that, in the French example, the Alt and AltGr keys retain their left and right location, even though there is only one of each key.
Single Quote ~keyの取扱い: ◎ Handling the Single Quote Key
Keyboard Layout | `key$m | `code$m |
---|---|---|
US | `'^kY | `Quote$kC |
Japanese | `:^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 ~keyの取扱い( 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や修飾~key状態に関わらず,~US~keyboardで~key `2^kGl の~keyを押したときの `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 つの~key~event連列における属性~値を比較する。 それらは いずれも ~US~keyboardでは 文字 `~aT^kGl を生産するが、~keyが離される順序により相違する。 最初の例の連列の順序は: `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 | 空~文字列 | (~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 | 空~文字列 | (~support有りなら) |
4. | `keyup$et | `Shift$kY | `ShiftLeft$kC | `DOM_KEY_LOCATION_LEFT^m |
5. | `keyup$et | `2^kY | `Digit2$kC |
~key `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.
5.2.4. `code^m と仮想~keyboard
`code$m 属性の有用性は、仮想~keyboardに対しては明白でない(遠隔~制御~keyboardや複数~keyの同時押下げに対しても)。 仮想(または遠隔~制御)~keyboardに対しては、 標準的な~keyboardの ~layout/機能性 を真似ているものについては, `code$m 属性を適切に設定し~MUST。 真似ていない~keyboardについては、標準的な~keyboardになるべく近いものに設定するか, または 未定義のままにして~MAY。 ◎ 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.
修飾~状態に基づいて異なる値を生産する~keyを伴うような仮想~keyboardに対しては、 `code^m 値は,[ 装置がその工場出荷~状態にある下で~buttonが押された ]ときに生成される `key^m 値にされる~SHOULDである。 ◎ 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.
5.3. ~keyboard~eventの `key^m 値
`~key値$は、~keyboard上の任意の~keyを,その位置や状態に関わらず, それが生産する値で指示するために利用し得る `DOMString^I である。 これらの~key値は、次のものに利用できる/され得る:
- 実装により生成される~keyboard~eventに対する返値
- 内容~作者から欲される入力(~keyboard~shortcutなど)を指定するための入力~値
妥当な `key^m 値の~listは `UIEvents-Key$r にて定義される。 ◎ The list of valid key values is defined in [UIEvents-Key].
`~key値$は、 `key$m 属性を利用して,押された~keyの値を検出するときに利用される値である。 内容~作者は、[ 大文字や小文字, 数字, 記号 ]その他,文字を生産する~keyに対しては その`文字~値$を検索取得でき、[ 制御~key, 修飾~key, ~function~key ]その他,文字を生産しない~keyに対しては その`~key値$を検索取得できる。 これらの値は、[ 特定0の入力~文字列を監視する / 他の入力(~mouseなど)との組合せで 修飾~key入力を検出して動作する / 仮想~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.
内容~作者は、`~key値$を文字列~比較にも利用できる — 適合`~host言語$における~markup属性~用の値(~HTMLの `accesskey^a など)として, あるいは 他の関係する目的に。 適合`~host言語$は、内容~作者が,`~key値$用の 2 つの等価な文字列~値:[ `文字~値$ または `~key値$ ]のいずれも利用できるようにする~SHOULDである。 ◎ 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.
注記: 実装は、~keyに対し,~platformや~keyboard~layout~mappingから独立に,最も関連する値を利用することになる一方、内容~作者は,それらを生成する~keyboard装置の能について前提を置けない。 内容~作者は、~shortcut~keyの組合せとして~keyboard~eventと~key値を利用するときには,普通字の代わりに 数字~key, ~function~key( `F4^cap, `F5^cap, 等々)の利用も考慮できる( `DWW95$r ) — ほとんどの~keyboard~layoutは,それら用の~keyを供するので。 ◎ 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.
`~key値$は、物理的~keyboard上の特定の~keyを指示するものでも,~key上に印刷された文字を反映するものでもない。 ~key値は、作動中の[ ~keyすべて/~key入力~mode(~shift~modeを含む)の現在の状態 ]が考慮に入れられ,~OSによる~keyboard~mappingに反映され, 実装に報告されるような,~eventの現在の値を指示する。 例えば、[ `QWERTY$ ~keyboardの `O^cap~key ]の~key値は,[ 未shiftの下では `o^kY / 有shiftの下では `O^kY ]になる。 利用者は,自身の~keyboardを任意の~custom環境設定に~mapできるので、内容~作者には,[ ~keyの~shiftの有無や,文字~表現の[ 大文字形, 小文字形 ]の間に,関係性が存在する ]ものと見做すことなく, `key$m 属性の値を利用することが奨励される。 例えば、 `D3E-code$r にて図面化されている標準的な “102 ~keyboard” ~layoutは、ある~keyboard~layoutにおける,`~key~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 属性を介しては報告されず,代わりに`~key値$ `Dead$kY が報告される。 実装は、代わりに[ ~dead-key連列の中間的な状態を包含する,一連の`組成~event$ ]を生成して,それを `CompositionEvent.data$m 属性を介して報告する。 前掲の例と同様に, `QWERTY$ ~keyboardの `O^cap と印字された~key用の`~key値$には,~dead-key操作の最中に~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.
また、~key~eventの各~状態と各`~key値$との間には,一対一の関係性はないことにも特に注意。 複数の~keyが特定0の~key値に結付けられることもある。 例えば,多くの標準的な~keyboardは、 `Shift^cap ~keyや `8^cap ~keyを複数~備えている(通常は[ いずれも `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は、どの~key値にも複数の~key状態が対応付けられ得る( `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" のこともある(多くの~keyboardが乗算~keyを欠くこと,あるいは `×^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.
5.3.1. 修飾~key
修飾~keyを利用する~keyboard入力は、~keyの通常の挙動を変化させる。 他の~keyと同様、修飾~keyは,下の例に示すように `keydown$et / `keyup$et ~eventを生成する。 修飾~keyには、押されている間 作動化されるものもあれば( `Alt^cap, `Control^cap, `Shift^cap, `AltGraph^cap, `Meta^cap など)、状態を持ち,その状態に依存して作動化されるものもある( `CapsLock^cap, `NumLock^cap, `ScrollLock^cap など)。 状態の変化は、修飾~keyが押されたときに起こる。 `KeyboardEvent!I ~ifcは、一部の共通的な修飾~keyに対し,簡便な属性 — `ctrlKey$m, `shiftKey$m, `altKey$m, `metaKey$m — を供する。 一部の~OSは、修飾~key `AltGraph^cap を,修飾~key `Alt^cap, `Control^cap の組合せで模造する。 実装には、 `AltGraph^cap 修飾~keyを利用することが奨励される。 ◎ 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( Latin Capital Letter Q, ~Unicode符号位置 `0051^U )が生成されるときに生じ得る~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 |
3. | `beforeinput$et | |||
4. | `input$et | |||
5. | `keyup$et | `Q^kY | `shiftKey$m | |
6. | `keyup$et | `Shift$kY |
次の例に、上の例において, `Q^cap ~keyを離す前に `Shift^cap ~keyを離したときに,代わって生じ得る~key連列を述べる。 ~key `Q^cap 用の`~key値$は、 `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 |
3. | `beforeinput$et | |||
4. | `input$et | |||
5. | `keyup$et | `Shift$kY | ||
6. | `keyup$et | `q^kY | Latin Small Letter Q |
次の例に、~Unicode文字を生成しないときに生じ得る~keyの連列を述べる(前の例と同じ環境設定の下で): ◎ 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 |
`beforeinput$et/`input$et ~eventは生成されない。 ◎ No beforeinput or input events are generated. | ||||
3. | `keyup$et | `v^kY | `ctrlKey$m | Latin Small Letter V |
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 |
`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 |
5. | `keyup$et | `Shift$kY | `ctrlKey$m | |
6. | `keyup$et | `Control$kY |
非~US~keyboard~layoutに対しても,~event連列は同じになるが、~keyの値は,現在の~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 |
`beforeinput$et/`input$et ~eventは生成されない。 ◎ No beforeinput or input events are generated. | ||||
3. | `keyup$et | `ر^kY | `ctrlKey$m | Arabic Letter Reh |
4. | `keyup$et | `Control$kY |
注記: `keydown$et / `keyup$et ~eventにおける値は、~keyが押されたときに有効な現在の~keyboard~layoutに基づいて,様々になる。 これは、同じ物理的~keyであっても, ~US~layout上の `v^cap ~key と ~Arabic~layout上の `ر^cap ~keyとでは,異なる~eventを生成することを意味する。 これらの~eventを同じ物理的~keyとして識別するためには、 `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.
修飾~keyが,~key~event用の`~key値$を変化させる事例もある。 例えば,一部の MacOS ~keyboard上の “delete” ~keyは、未修飾~時にはWindows ~OS上の `Backspace^cap ~keyと同じに機能するが、 `Fn^cap ~keyで修飾されたときは `Delete^cap ~keyとして動作し,~key値は 現在の修飾された状態に最も適切な~keyの機能に合致することになる。 ◎ 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.
5.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$は、`~key値$ `Dead$kY で表現される。 ~dead-keyが押されたときは、~UAは それに呼応して,`組成~event$たちを発火し~MUST。 加えて、その `compositionupdate$et ~eventの `CompositionEvent.data$m 値は,~dead-key結合~連列の現在の状態の`文字~値$にされ~MUST。 ◎ 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 ~key), `0065^U ( Latin Small Letter E と印字される~key) ]は,[ NFC ( Unicode Normalization Form )に選好される ~Unicode文字 `ê^kGl ( Latin Small Letter E With Circumflex ) ]を生産するであろう(~French~keyboardでは、修飾~keyを作動化させずに,~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 (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 |
注記: 2 個目の `keydown^c ~event(段 5)では、(~eventは抑止されていないとするとき,)通常の状況~下では`~key値$ `e^kY ( Latin Small Letter E ~key)にはならない — ~UAに送達される値は、すでに~dead-key操作により修飾されることになるので。 ◎ 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.
この処理-は、利用者が`~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 (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 | |
6. | `compositionupdate$et | `^kGl | |||
7. | `compositionend$et | `^kGl | |||
8. | `keyup$et | `q^kY | ~F |
5.3.3. ~IME( Input Method Editors )
この仕様は、 `CompositionEvent$I ~ifc&~event を通して,`~IME$( Input Method Editor )用の~modelを含めている。 しかしながら、`組成~event$と`~keyboard~event$を一対一に~mapすることは,必要とされていない。 例として、`~key値$ `Accept^cap を伴う `keydown$et を受取ったとしても、それは, `~IME$において現在~選択-中の~textが受容されたことを含意するわけではなく、~keystrokeが起きたことのみを指示する — 受容されている`~IME$の機能性からは切離されて(通常それは、ほとんどの`~IME$~systemにおいて, `compositionend$et ~eventを生じさせることになるが)。 ~keyboard~eventは、~IMEの現在の状態を決定する用途には,利用できない — その状態は `CompositionEvent.data$m 属性を通して得ることができる。 加えて、`~IME$~systemや装置の機能性は様々であり,その機能性を作動化するために,どの~key — `Convert^cap / `Accept^cap ~keyなど — が利用されているかは、他の可用な~keyにより表現されることもある。 ~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環境設定においては、一部の~key~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 の一部である漢字 )が生成されるときに生じ得る~key連列を述べる。 この例では、~IMEは作動化されていて,日本語~Romaji入力~mode下にあるとする。 ~key `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 ~keyを利用して 適正な選択肢を選択する必要がある。 ◎ "詩" ("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 | |
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 | |
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組成は、前掲の例と同一の条件で,次の例のように取消され得る。 ~key `Cancel^cap も利用中の入力~装置や~IMEの環境設定に依存して,他に置換され得る — 例えば `001B^U ( `Escape^cap ~key )にもなり得る。 ◎ 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 | |
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 | |
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.
5.3.3.1. ~IME~mode~key
ある種の装置では、一部の~keyに,[ `~IME$を作動化したり, 作動中の`~IME$の~modeを変更する ]ような機能性が意図されている。 これを目的とする~keyは、装置や言語~modeごとに異なるものが定義され得る。 この仕様では、次のものが,これを目的とする~keyとして定義される: `Alphanumeric$kY, `CodeInput$kY, `FinalMode$kY, `HangulMode$kY, `HanjaMode$kY, `Hiragana$kY, `JunjaMode$kY, `KanaMode$kY, `KanjiMode$kY, `Katakana$kY, `RomanCharacters$kY 。 `~IME$が作動中でない下で,これらのいずれかの~keyが押されたときは、(可用なら)適切な`~IME$が,~keyにより指示される~modeで作動化されることが予期される。 ~keyが押されたとき,`~IME$がすでに作動中である場合、[ 装置/~app ]に特有のふるまいに基づいて,`~IME$が 指示された~modeへ変更されたり, 異なる`~IME$が起動0されたり, あるいは無視されることもある。 ◎ 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 "RomanCharacters". 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.
この仕様は、他の~key — 特定的には、次に挙げる`~IME$に意図される操作~用の~key — も定義する: `Accept$kY, `AllCandidates$kY, `Cancel$kY, `Convert$kY, `Compose$kY, `FullWidth$kY, `HalfWidth$kY, `NextCandidate$kY, `Nonconvert$kY, `PreviousCandidate$kY 。 これらの~keyの機能は、この仕様では定義されない — `~IME$機能性についての詳細は、他の資料を参照のこと。 ◎ This specification also defines other keys which are intended for operation specifically with input method editors: "Accept", "AllCandidates", "Cancel", "Convert", "Compose", "FullWidth", "HalfWidth", "NextCandidate", "Nonconvert", and "PreviousCandidate". The functions of these keys are not defined in this specification — refer to other resources for details on input method editor functionality.
注記: `~IME$機能を伴う~keyは、その目的に制約されず,他の装置や実装に特有の目的を持つこともある。 ◎ Keys with input method editor functions are not restricted to that purpose, and can have other device- or implementation-specific purposes.
5.3.4. 既定~動作と取消~可能~keyboard~event
`keydown$et ~eventの`既定~動作$が取消されたときは,それと対を成す `keyup$et ~eventには影響しては~MUST_NOTが、それに呼応する[ `beforeinput$et / `input$et /(~support有りなら) `keypress$et ]~eventは 生成されないようにし~MUST。 次の例に、~US~keyboardで, ~US~mappingを利用している下で,~Unicode文字 Q( Latin Capital Letter Q )が生成されるときに生じ得る~key連列を述べる: ◎ 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 の呼出しにより,防止された。 ◎ 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 |
~keyが修飾~keyであった場合、~keystrokeは,依然として修飾~状態には織り込まれ~MUST。 次の例に、~US~keyboardで, ~US~mappingを利用している下で,~Unicode文字 Q( Latin Capital Letter Q )が生成されるときに生じ得る連列を述べる: ◎ 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 の呼出しにより,防止された。 ◎ 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 |
~keyが何回かの~keystrokeからなる連列の一部である場合、それが `~dead-key$であれ, ~IME連列に関与しているものであれ、その~keystrokeは, `keydown$et ~event上で`既定~動作$が取消された場合にのみ,無視され~MUST(織り込まれない)。 `~dead-key$による`keyup$et ~eventを取消しても, `beforeinput$et / `input$et ~eventには効果がない。 次の例に、~French~keyboardで, ~French~mappingを利用し,どの修飾も作動化されない下で、[ ~dead-key `Dead$kY ( `0302^U Combining Circumflex Accent ~key) ], [ `e^kY ~key( `0065^U, Latin Small Letter E ~key) ]を利用したときに生じる~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 の呼出しにより,防止された。 ◎ 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 |
6. 旧来の~event初期化子
`legacy-event-initializers^APX7. 旧来の~key属性
`legacy-key-attributes^APX8. 旧来の~event型
`legacy-event-types^APX9. ~eventの拡張-法
`extending-events^APX10. 保安上の考慮点
`security-considerations^APX11. 変更点
`changes-from-earlier-versions^APX12. 謝辞
`acknowledgements-contributors^APX13. 用語集
次の用語の定義の一部は、他の 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.
【 この訳では、利用されていない(本文の改訂により参照されなくなった)用語, 適合性~関連の用語については、省略する。 また、原文の~~アルファベット順による並びを,互いの関連度に基づく並びに変えている。 】
- `~Window@ ( `Window^I ~obj)
- ~Windowは、 `HTML5$r にて定義されるように,[ 現在の文書の閲覧文脈の `WindowProxy$I ~obj ]から~~参照される,~objである。 ◎ The Window is the object referred to by the current document’s browsing context’s Window Proxy object as defined in HTML5 [HTML5].
- `文書@ ( `Document^I ~obj )
- `Document^I ~ifc `DOM-Level-3-Core$r / `Document^I ~ifc `DOM$r を~instance化する~obj — ~HTML/~XML ~text文書 全体を表現する。 概念的には、それは 文書~木の根であり,文書の~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^I ~obj )
- `Element^I ~ifc `DOM$r を~instance化する~obj
- `木@ ( tree )
- 【この項の内容は、DOM4 仕様の~node木 節に委譲。】 ◎ A data structure that represents a document as a hierarchical set of nodes with child-parent-sibling relationships, i.e., each node having one or more possible ancestors (nodes higher in the hierarchy in a direct lineage), one or more possible descendants (nodes lower in the hierarchy in a direct lineage), and one or more possible peers (nodes of the same level in the hierarchy, with the same immediate ancestor).
- `根~要素@ ( root element )
- `文書~要素$。 ~HTML/ ~XHTML 文書においては、 `html^e 要素が該当する。 ◎ The first element node of a document, of which all other elements are children. The document element.
- `~body要素@ ( body element )
- ~HTML/ ~XHTML 文書においては、`根~要素$の子孫【子?】である `body^e 要素のうち,最初のもの。 ~body要素は,文書の内容を表現する。 【~HTML仕様による定義】 ◎ 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 )
- 長さ 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 )
- ~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~ifcの構築子 】【 この種の値は、 “既定値( default value )” 命名されることが多いが、この名前にされている理由は,~IDL用語の “既定値” と区別するためと思われる。 】
- `~event@ ( event )
- ~eventは、その`標的$に結付けられている何らかの~~出来事(呈示されている要素に対する~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 )
- ~event型 は、特定0の名前を持ち, 特定0の[ 誘発~条件, ~prop, 他の~event型から判別される他の特性 ]を定義する`~event$~objである。 例えば、 ~event型 `click$et は, `mouseover$et や `load$et とは異なる特性を持つ。 ~event型は、~event~obj上では `type$m 属性として公開される。 詳細は~event型に。 ~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 §4 Event Types for more details. Also loosely referred to as "event", such as the click event.
- `~event~focus@ ( event focus )
- ~event~focusは、文書の中の 特定0の要素その他の`~event標的$ において,~~目立たせている/~~注視されているような特別な状態である。 ~focusされたときの挙動は、各~要素ごとに その機能性に依存して異なる — [ (~buttonや~hyperlink用に)要素を作動化~対象の首位に据える / (~checkbox用の)状態の切り替え / (~text~form~field用の)~text入力を受取る / 選択された~textを複製する ]など。 詳細は 文書~focusと~focus文脈 節に。 ◎ 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 §4.2.3 Document Focus and Focus Context.
- `~event~focus環@ ( event focus ring )
- ~event~focus環とは、文書~内の`~event~focus$の標的になり得るものからなる順序集合である。 `~host言語$は、これらの標的の順序を決定する複数の仕方を定義することもある — [ 文書~順序 / 各~focus標的に定義される数的~index / 各~focus標的に明示的に与えられる次の標的 / これらの異なる~modelの~~混成 ]など。 文書は、複数の~focus環や条件付き~focus環を包含することもある。 概して、 文書順/~index に基づく~focus環においては、最後の~focus標的の次の~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 )
- 同じ[ ~event源/処理- ]から生じた~event連列であって、各~eventは,同じまたは関係する~event~ifcを利用しているもの。 例えば,[ ~mouse, ~trackpad, ~keyboard, ]などの各種 入力~装置を備える環境では、それぞれが互いに別々の~event源を成し, 自前の~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源による~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 ~keyを利用して, あるいは ~mouseで新たな被focus要素を~clickして,~focusを変更し得る。 そのような事例における~event序列は、状態~変化を起動させた装置の状態ではなく,処理-の状態に依存する。 ◎ 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標的@(または単に “標的”)( event target )
-
次の二つの意味で用いられる:
- ~DOM~event~flow を利用して,`~event$の標的にされている~obj。 ~event標的は、 `target$m 属性で指示される。
- 何らかの~eventに対し,前項の意味で 標的になり得る~obj。
- `現在の~event標的@ ( current event target )
-
次の二つの意味で用いられる:
- ~event~flowにおいて,現在~eventが配送されている`~event~handler$に結付けられている,~obj。 この~objは、当の~event標的か, または その先祖のいずれかになる。 現在の標的は、`~event$が ~event~flowの各種`~event相$を通して ~objから~objへ伝播するに伴って,変化する。 現在の標的は、 `currentTarget$m 属性で指示される。
- 何らかの~eventに対し,前項の意味で 現在の~event標的になり得る各~obj(すなわち,当の~eventの`伝播~経路$に属する~obj)。
- ~eventの`伝播~経路@( propagation path )
- `~event$~objが `~event標的$ へ向かって行く/から戻る 道を順々に通過する,`現在の標的$たちからなる順序集合である。 ~eventが伝播するに伴い、 `currentTarget$m には,各回ごとに経路に属する`現在の標的$が設定される。 伝播~経路は、`~event型$にて定義されるように,初期~時には一つ以上の`~event相$からなるが、中断されることもある。 “~event標的~連鎖” とも呼ばれる。 ◎ 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 )
- `DOM$r にて定義されている。 ~eventの型, および~eventが生じた文脈に応じて、適切な~ifcを実装する~eventを作成し,適切に属性を初期化した上で,`~event標的$へ向けて`配送$することを意味する(例: “`click$et ~eventを発火する” )。 ◎ A synonym for dispatch.
- ~eventの`配送@ ( dispatch )
- 所与の~eventを,指定された`伝播~経路$を通して伝播させる処理-を意味する(例: “`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 )
-
`~event$の文脈においては、相は,~DOM木の 先祖への/子孫への 論理的な辿りを表す:
- `捕獲-相$: `~Window$ → `文書$ → `根~要素$ → … → `~event標的$の親~node
- `標的~相$: `~event標的$
- `浮上-相$: 捕獲-相と同じ連鎖の逆順
- `浮上-相$ ( bubbling phase )
- `~event標的$により取扱われた後に, 標的のいずれかの先祖により取扱われ得る`~event$の処理-。 詳細は、~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 phase )
- `~event$が`~event標的$により取扱われ得る処理-。 詳細は、~event~flowの文脈における`標的~相$の記述に。 ◎ 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 )
- `~event標的$により取扱われる前に, 標的のいずれかの先祖により取扱われ得る`~event$の処理-。 詳細は、~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 )
- `~event~handler@ ( event handler )
- `EventListener!I ~ifcを実装する`利用元~obj$であって `handleEvent()$m ~callback~methodを供するもの。 ~event~handlerは、言語に特有である。 ~event~handlerは、特定0の~obj(`現在の~event標的$)の文脈で†, ~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の定義。 】
- 注記: JavaScript においては、利用者定義の関数は, `EventListener$I ~ifcを実装するものと見なされる。 したがって、その関数の呼出時には,その最初の引数に~event~objが渡されることになる。 加えて、 JavaScript ~objは, `handleEvent()$m ~methodを定義して `EventListener$I ~ifcを実装することもできる。 ◎ 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 )
- `~event$(概して、利用者により,入力~装置を通して起動される)が、要素に定義されている~taskを履行させるとき採られる動作。 この~taskは、その要素に対し[ `~host言語$, 作者により定義された変数 ]あるいはこの両者により,定義されることもある。 与えられた要素~用の既定の~taskは、汎用の動作であったり, その要素に~~固有のものになることもある。 例えば、 ~HTML/~SVG の `a^e 要素の作動化の挙動は、~UAに `href^a 属性にて指定される~linkを辿らせる — そのための閲覧文脈を指定するような~parameter( 現在の~window/ある~tab/有名~window/新たな~window など)を更に伴なうこともある。 例えば、[ `type^a 属性~値が `submit^l にされた~HTML `input$e 要素 ]用の作動化の挙動は、 `form^e 要素の一連の値を,作者が与える 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 )
- `作動化の挙動$を起動するように定義されている~event。 詳細は`作動化の誘発と挙動$に。 ◎ An event which is defined to initiate an activation behavior. Refer to §3.5 Activation triggers and behavior for more details.
- `既定~動作@ ( default action )
- `既定~動作$は、任意選択†の追補的な挙動であって,実装が~event~objの配送と組合せて遂行し~MUSTものである。 各種~event型~定義, および 各種 仕様は、その~event型~用の`既定~動作$があれば,それを定義する。 `作動化の誘発$に結付けられているときなど、状況に応じて,~eventの各~instanceには`既定~動作$が複数ある場合もある。 `既定~動作$は、 `preventDefault()$m ~methodの呼出を通して取消されることもある。 詳細は 既定~動作と取消~可能な~event に。 ◎ 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標的@ ( topmost event target )
- 最上層の~event標的は、`~event標的$になれるような,最も上層に描画される要素で~MUST。 ~graphical~UIにおいては、これは,利用者の~pointing装置が~~指す所の~~直下にある要素になる。 この標的の決定は、~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 ~prop( ~SVG )などにより,明示的に接触判定の対象から除外されるものは、最も上層に塗られていても,最上層の~event標的にはならない。 】
- `~pointing先@
- ~pointing装置が現在 指している`最上層の~event標的$を意味する(存在しない場合は~NULL)。
- 【 この用語と次に与える用語は、各所の記述を集約して簡潔にするために,この訳に導入している。 】
- `~pointing先$が `有効に変化-@ したとは、その変化は~pointing装置の`首~pointer$におけるものであって†1,[ (利用者により)~pointerが動かされたことにより生じた ]か, または[ ある要素が動いた†2ことにより,~pointerに生じた†3 ]ことを意味する。
- 【†1 非 `首~pointer$からは、この定義を参照する~mouse~event(互換性~mouse~event)は生じない。 】【†2 要素が “動いた” とは、~scrollや~layout変化によるそれに加えて,要素を挿入するなどの~DOM変異によるそれも含まれる(と思われる — 少なくとも一部の~browserの実装は、そうなっている)。 】【†3 動いた要素と変化-[ 前/後 ]の~pointing先が一致する必要はない。 例えば、動いた要素は変化-後の~pointing先の先祖かもしれない。 】
- `回転@ ( rotation )
- `WheelEvent$I ~ifcを利用している入力~装置~上の 増分的な変化の指示。 これには、装置により ~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 )
- ~UAが `WheelEvent!I ~ifcとして~supportされるような入力~装置(~mouse~wheelや~touchpadなど)の物理的な動きに呼応して,頁を~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 )
- 使用感を改善するために,所在や時間がずれた入力も一定限度までは受容するような、人~ifc設計の特色機能。 例えば、利用者が~mouse~buttonを~double-clickするときの微小な時間差の受容は,時間的~hysteresisであり、利用者が子~menuへ遷移しようとして,~mouseが親~windowから外れたときに,入子の~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 )
-
~key値の文脈では、文字~値は, 一つ以上の~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. 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文字などの一部の~key値は,利用中の~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.
- `~key値@ ( key value )
- ~key値は、特定0の状態にある~keyに結付けられている,`文字~値$ または[ 複数~文字からなる文字列( `Enter$kY, `Tab$kY, `MediaTrackNext$kY など) ]である。 ~key値は、[ 制御~key, ~function~key, `修飾~key$, `~dead-key$, その他の~key ]も含め,どの~keyにも、`文字~値$を持つかどうかに関わらず,あてがわれる。 与えられた時点の与えられたどの~keyの~key値も、`~key~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.
- `修飾~key@ ( modifier key )
- 修飾~keyは、~keyの通常の挙動を変更する — ( `Shift^cap ~keyで)異なる文字caseを生産させたり, (`Fn^cap や `Alt^cap ~keyなどで)~keyが誘発する機能性を改めるなど。 修飾~keyについての情報は 修飾~key節 に。 妥当な修飾~keyの~listは、 `UIEvents-Key$r の`修飾~key一覧$にある。 ◎ 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 §5.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 )
- ~dead-keyは、自身は文字を生産しないが,[ 別の~keyとの 組合せ/連列 により,修飾された文字 — 発音区別符号を伴う文字(例: `ö^kGl, `é^kGl, `â^kGl )など — を生産する ]ような,~keyまたは~keyの組合せである。 ◎ 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 )
- 何らかの形による代替-入力(`~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.
- `~key~mapping@ ( key mapping )
- ~key~mappingは、特定0の~keyに~key値をあてがう処理-であり、いくつかの因子 — ~OSや~keyboard~layout(例: `QWERTY$, Dvorak, Spanish, InScript, Chinese, 等々),および[ `修飾~key$( `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, 入力方式エディタ )
- ~IMEは、一連の~keystrokeから表意文字その他の文字への変換を — 通例的に,利用者により手引きされる辞書検索により — 遂行する~appであり、東アジア圏の言語(例:中国語, 日本語, 韓国語)でよく利用される。 ~IMEは、携帯機器などでも単語の入力補完に利用されることもある。 この仕様における~IMEの扱いについては、 ~IME節に。 `~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 §5.3.3 Input Method Editors for treatment of IMEs in this specification. See also text composition system.
- `QWERTY@
- QWERTY( “ˈkwɜrti” と発音される)は、 共通的な~keyboard~layoutの普通字~keyの上段の最初の 6 文字が Q, W, E, R, T, Y であることから命名されている。 他にも普及している~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 )
-
各~Unicode符号位置に対し定義されている
General Category 値の部分集合。
この部分集合には、次の字種に属するものすべてが包含される:
- 普通字( Letter ): Ll, Lm, Lo, Lt, Lu
- 数字( Number ): Nd, Nl, NO
- 約物( Punctuation ): Pc, Pd, Pe, Pf, Pi, Po, Ps
- 記号( Symbol ): 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.