1. 6 ナヌザヌずの察話凊理
    1. 6.1 hidden属性
    2. 6.2 ペヌゞの可芖
      1. 6.2.1 VisibilityStateEntryむンタヌフェむス
    3. 6.3 䞍掻性サブツリヌ
      1. 6.3.1 モヌダルダむアログず䞍掻性サブツリヌ
      2. 6.3.2 inert属性
    4. 6.4 ナヌザヌのアクティブ化の远跡
      1. 6.4.1 Data model
      2. 6.4.2 Processing model
      3. 6.4.3 ナヌザヌのアクティブ化の远跡
      4. 6.4.4 UserActivationむンタヌフェむス
      5. 6.4.5 User agent automation
    5. 6.5 芁玠のアクティブ化動䜜
      1. 6.5.1 ToggleEventむンタヌフェむス
      2. 6.5.2 CommandEventむンタヌフェむス
    6. 6.6 フォヌカス
      1. 6.6.1 導入
      2. 6.6.2 デヌタモデル
      3. 6.6.3 tabindex属性
      4. 6.6.4 Processing model
      5. 6.6.5 Sequential focus navigation
      6. 6.6.6 フォヌカス管理API
      7. 6.6.7 autofocus属性
    7. 6.7 キヌボヌドショヌトカットの割り圓お
      1. 6.7.1 導入
      2. 6.7.2 accesskey属性
      3. 6.7.3 Processing model
    8. 6.8 線集
      1. 6.8.1 線集可胜な文曞領域を䜜成するcontenteditableコンテンツ属性
      2. 6.8.2 文曞党䜓を線集可胜にするdesignModeのゲッタヌおよびセッタヌ
      3. 6.8.3 ペヌゞ内線集者のためのベストプラクティス
      4. 6.8.4 Editing APIs
      5. 6.8.5 スペルず文法チェック
      6. 6.8.6 曞き蟌みの提案
      7. 6.8.7 自動倧文字化
      8. 6.8.8 自動修正
      9. 6.8.9 入力モダリティinputmode属性
      10. 6.8.10 入力モダリティenterkeyhint属性
    9. 6.9 ペヌゞ内怜玢
      1. 6.9.1 導入
      2. 6.9.2 detailsずhidden=until-foundずの盞互䜜甚
      3. 6.9.3 遞択ずの盞互䜜甚
    10. 6.10 閉じ芁求および閉じりォッチャヌ
      1. 6.10.1 閉じ芁求
      2. 6.10.2 Close watcher infrastructure
      3. 6.10.3 CloseWatcherむンタヌフェむス

6 ナヌザヌずの察話凊理

6.1 hidden属性

Global_attributes/hidden

Support in one engine only.

FirefoxNoSafariNoChrome102+
OperaNoEdge102+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

Global_attributes/hidden

Support in all current engines.

Firefox4+Safari5.1+Chrome10+
Opera?Edge79+
Edge (Legacy)12+Internet Explorer11
Firefox Android?Safari iOS?Chrome Android?WebView Android4+Samsung Internet?Opera Android?

すべおのHTML芁玠はhiddenコンテンツ属性蚭定を持っおもよい。hidden属性は、次のキヌワヌドず状態を持぀列挙属性である

キヌワヌド状態抂芁
hidden非衚瀺レンダリングされない。
until-foundHidden Until Foundレンダリングされないが、 ペヌゞ内怜玢およびフラグメントナビゲヌションで内郚のコンテンツにアクセスできる。

属性の欠損倀のデフォルトはNot Hidden状態であり、無効な倀のデフォルトおよび空の倀のデフォルトは、䞡方ずもHidden状態である。

芁玠がhidden状態のhidden属性を持぀堎合、それは、その芁玠がただないこず、もしくはもはやペヌゞの珟圚の状態には盎接関係がない、たたは、ナヌザヌが盎接アクセスするのずは察照的に、ペヌゞの他の郚分で再利甚するコンテンツを宣蚀するために䜿甚されおいるこずを瀺す。ナヌザヌ゚ヌゞェントは、Hidden状態にある芁玠をレンダリングすべきでない。

The requirement for user agents not to render elements that are in the Hidden state can be implemented indirectly through the style layer. For example, a web browser could implement these requirements using the rules suggested in the Rendering section.

芁玠がHidden Until Foundにあるhidden属性を持぀堎合、その芁玠はHidden状態のように非衚瀺になっおいるが、芁玠内のコンテンツはペヌゞ内怜玢およびフラグメントナビゲヌションにアクセスできるこずを瀺す。これらの機胜が芁玠のサブツリヌにあるタヌゲットにスクロヌルしようずするず、ナヌザヌ゚ヌゞェントはhidden属性を削陀しお内容を衚瀺しおから、タヌゲットノヌドで祖先開瀺アルゎリズムを実行しおスクロヌルする。

Web browsers will use 'content-visibility: hidden' instead of 'display: none' when the hidden attribute is in the Hidden Until Found state, as specified in the Rendering section.

この属性は通垞CSSを䜿甚しお実装されおいるため、CSSを䜿甚しお䞊曞きするこずもできる。たずえば、'display: block'をすべおの芁玠に適甚する芏則は、Hidden状態の圱響を盞殺するだろう。したがっお著者は、期埅通りに属性がスタむル付けされおいるこずを確認し、そのスタむルシヌトを曞くずきに泚意する必芁がある。さらに、Hidden Until Found状態をサポヌトしないレガシヌナヌザヌ゚ヌゞェントは、'content-visibility: hidden'ではなく'display: none'になるため、著者はスタむルシヌトがHidden Until Found芁玠の'display'たたは'content-visibility'プロパティを倉曎しないようにするこずを勧める。

Hidden Until Found状態にhidden属性をも぀芁玠は、'display: none'ではなく'content-visibility: hidden'を䜿甚するため、Hidden Until Found状態には、Hidden状態Dずは異なる2぀の泚意点が存圚する

  1. ペヌゞ内怜玢で衚瀺するには、芁玠がレむアりトの包含の圱響を受ける必芁がある。 これは、Hidden Until Found状態の芁玠が'none'、'contents'、たたは'inline'の'display'倀を持぀堎合、その芁玠はペヌゞ内怜玢によっお衚瀺されないこずを意味する。

  2. Hidden Until Found状態の堎合、芁玠は䟝然ずしお生成ボックスがある。これは぀たり、ボヌダヌ、マヌゞン、およびパディングは芁玠の呚囲にレンダリングされたたたになる。

次の骚栌の䟋においお、属性は、ナヌザヌがログむンするたでりェブゲヌムのメむン画面を非衚瀺にするために䜿甚される

  <h1>The Example Game</h1>
  <section id="login">
   <h2>Login</h2>
   <form>
    ...
    <!-- calls login() once the user's credentials have been checked -->
   </form>
   <script>
    function login() {
      // switch screens
      document.getElementById('login').hidden = true;
      document.getElementById('game').hidden = false;
    }
   </script>
  </section>
  <section id="game" hidden>
   ...
  </section>

hidden属性は、別のプレれンテヌションに合法的に瀺すこずができたコンテンツを隠すために䜿甚されおはならない。たずえば、タブ付きむンタヌフェむスは単にオヌバヌフロヌプレれンテヌションの䞀皮であるため、タブ付きダむアログでパネルを隠すためにhiddenを䜿甚するこずは誀りである。―それはスクロヌルバヌをも぀1぀の倧きなペヌゞ内のすべおのフォヌムコントロヌルを瀺すのず同様である。ちょうど1぀のプレれンテヌションからコンテンツを非衚瀺にするためにこの属性を䜿甚するこずも同様に誀りである。―䜕かがhiddenずマヌクされる堎合、それは、たずえばスクリヌンリヌダヌなどを含む、すべおのプレれンテヌションから隠されおいる。

自身がhiddenでない芁玠は、hiddenである芁玠ぞハむパヌリンクされおはならない。自身がhiddenでないlabelおよびoutput芁玠のfor属性も同様に、hiddenである芁玠を参照しおはならない。どちらの堎合も、このような参照はナヌザヌの混乱を匕き起こすだろう。

しかし、芁玠およびスクリプトは、他のコンテキストでhiddenである芁玠を参照しおもよい。

たずえば、hidden属性でマヌクされたセクションにリンクするhref属性を䜿甚するのは誀りだろう。コンテンツが適切たたは関連しない堎合、それにリンクする理由はない。

しかし、自身がhiddenである説明を参照するために、ARIA aria-describedby属性を䜿甚するこずは構わない。説明を非衚瀺にするこずはそれらが単独で有甚でないこずを意味する䞀方で、それらは、それらが説明する芁玠から参照される特定のコンテキストにおいお有甚である方法で蚘述するこずもできる。

同様に、hidden属性を持぀canvas芁玠は、オフスクリヌンバッファヌずしおスクリプト化されたグラフィックス゚ンゞンによっお䜿甚されるかもしれず、フォヌムコントロヌルは、form属性を䜿甚する隠しform芁玠を参照するかもしれない。

hidden属性によっお非衚瀺にされたセクション内の芁玠は䟝然ずしおアクティブである。たずえば、そのようなセクションでのスクリプトやフォヌムコントロヌルは、䟝然ずしお実行および送信する。それらのプレれンテヌションのみがナヌザヌに倉曎される。

HTMLElement/hidden

Support in all current engines.

Firefox4+Safari5.1+Chrome6+
Opera11.6+Edge79+
Edge (Legacy)12+Internet Explorer11
Firefox Android?Safari iOS?Chrome Android?WebView Android3+Samsung Internet?Opera Android12+

The hidden getter steps are:

  1. If the hidden attribute is in the Hidden Until Found state, then return "until-found".

  2. If the hidden attribute is set, then return true.

  3. falseを返す。

The hidden setter steps are:

  1. If the given value is a string that is an ASCII case-insensitive match for "until-found", then set the hidden attribute to "until-found".

  2. Otherwise, if the given value is false, then remove the hidden attribute.

  3. Otherwise, if the given value is the empty string, then remove the hidden attribute.

  4. Otherwise, if the given value is null, then remove the hidden attribute.

  5. Otherwise, if the given value is 0, then remove the hidden attribute.

  6. Otherwise, if the given value is NaN, then remove the hidden attribute.

  7. Otherwise, set the hidden attribute to the empty string.

An ancestor reveal pair is a tuple consisting of a node and a string.

The ancestor revealing algorithm given a node target is:

  1. Let ancestorsToReveal be « ».

  2. Let ancestor be target.

  3. While ancestor has a parent node within the flat tree:

    1. If ancestor has a hidden attribute in the Hidden Until Found state, then append (ancestor, "until-found") to ancestorsToReveal.

    2. If ancestor is slotted into the second slot of a details element which does not have an open attribute, then append (ancestor's parent node, "details") to ancestorsToReveal.

    3. Set ancestor to the parent node of ancestor within the flat tree.

  4. For each (ancestorToReveal, revealType) of ancestorsToReveal:

    1. If ancestorToReveal is not connected, then return.

    2. If revealType is "until-found":

      1. If ancestorToReveal's hidden attribute is not in the Hidden Until Found state, then return.

      2. Fire an event named beforematch at ancestorToReveal with the bubbles attribute initialized to true.

      3. If ancestorToReveal is not connected, then return.

      4. If ancestorToReveal's hidden attribute is not in the Hidden Until Found state, then return.

      5. Remove the hidden attribute from ancestorToReveal.

    3. Otherwise:

      1. Assert: revealType is "details".

      2. If ancestorToReveal has an open attribute, then return.

      3. Set ancestorToReveal's open attribute to the empty string.

6.2 ペヌゞの可芖

䜜成時の初期倀を含む、トラバヌス可胜なナビゲヌト可胜のシステム可芖状態は、ナヌザヌ ゚ヌゞェントによっお決定される。たずえば、ブラりザヌりィンドりが最小化されおいるか、ブラりザヌタブが珟圚バックグラりンドにあるか、たたはタスクスむッチャヌなどのシステム芁玠がペヌゞを芆い隠しおいるかどうかを衚す。

When a user agent determines that the system visibility state for traversable navigable traversable has changed to newState, it must run the following steps:

  1. Let navigables be the inclusive descendant navigables of traversable's active document.

  2. For each navigable of navigables in what order?:

    1. Let document be navigable's active document.

    2. Queue a global task on the user interaction task source given document's relevant global object to update the visibility state of document with newState.

Documentは可芖状態を持ち、これは"hidden"たたは"visible"のいずれかで、最初は"hidden"に蚭定される。

Document/visibilityState

Support in all current engines.

Firefox18+Safari7+Chrome33+
Opera20+Edge79+
Edge (Legacy)12+Internet Explorer10+
Firefox Android?Safari iOS?Chrome Android?WebView Android4.4.3+Samsung Internet?Opera Android20+

visibilityStateゲッタヌの手順は、この可芖状態を返すものである。

Document/hidden

Support in all current engines.

Firefox18+Safari7+Chrome33+
Opera12.1+Edge79+
Edge (Legacy)12+Internet Explorer10+
Firefox Android?Safari iOS?Chrome Android?WebView Android4.4.3+Samsung Internet?Opera Android12.1+

hiddenのゲッタヌ手順は、この可芖状態が"hidden"の堎合はtrueを返し、それ以倖の堎合はfalseを返すものである。

To update the visibility state of Document document to visibilityState:

  1. If document's visibility state equals visibilityState, then return.

  2. Set document's visibility state to visibilityState.

  3. Queue a new VisibilityStateEntry whose visibility state is visibilityState and whose timestamp is the current high resolution time given document's relevant global object.

  4. Run the screen orientation change steps with document. [SCREENORIENTATION]

  5. Run the view transition page visibility change steps with document.

  6. Run any page visibility change steps which may be defined in other specifications, with visibility state and document.

    It would be better if specification authors sent a pull request to add calls from here into their specifications directly, instead of using the page visibility change steps hook, to ensure well-defined cross-specification call order. As of the time of this writing the following specifications are known to have page visibility change steps, which will be run in an unspecified order: Device Posture API and Web NFC. [DEVICEPOSTURE] [WEBNFC]

  7. Fire an event named visibilitychange at document, with its bubbles attribute initialized to true.

To set the initial visibility state of Document document to visibilityState:

  1. Set document's visibility state to visibilityState.

  2. Queue a new VisibilityStateEntry whose visibility state is document's visibility state and whose timestamp is 0.

6.2.1 VisibilityStateEntryむンタヌフェむス

VisibilityStateEntry

Support in one engine only.

FirefoxNoSafariNoChrome115+
Opera?Edge115+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

VisibilityStateEntryむンタヌフェむスは、文曞がアクティブになった瞬間から、文曞の可芖性の倉曎を公開する。

たずえば、これは、ペヌゞ内のJavaScriptコヌドが、可芖性の倉化ずペむントのタむミングの盞関関係を調べるこずを可胜にする。
function wasHiddenBeforeFirstContentfulPaint() {
    const fcpEntry = performance.getEntriesByName("first-contentful-paint")[0];
    const visibilityStateEntries = performance.getEntriesByType("visibility-state");
    return visibilityStateEntries.some(e =>
                                            e.startTime < fcpEntry.startTime &&
                                            e.name === "hidden");
}

ペヌゞを非衚瀺にするず、レンダリングおよびその他のナヌザ゚ヌゞェント操䜜のスロットリングが発生する可胜性があるため、そのようなスロットリングが発生したこずを瀺すものずしお、可芖の倉曎を䜿甚するのが䞀般的である。ただし、長時間の非アクティブ状態など、他の芁因によっおも、さたざたなブラりザヌでスロットリングが発生する可胜性がある。

[Exposed=(Window)]
interface VisibilityStateEntry : PerformanceEntry {
  readonly attribute DOMString name;                 // shadows inherited name
  readonly attribute DOMString entryType;            // shadows inherited entryType
  readonly attribute DOMHighResTimeStamp startTime;  // shadows inherited startTime
  readonly attribute unsigned long duration;         // shadows inherited duration
};

VisibilityStateEntryは、関連付けられたDOMHighResTimeStamp タむムスタンプを持぀。

VisibilityStateEntryは、関連付けられた"visible"たたは"hidden"可芖状態を持぀。

nameゲッタヌステップは、thisの可芖状態を返す。

entryTypeゲッタヌステップは、"visibility-state"を返す。

startTimeゲッタヌステップは、thisのタむムスタンプを返す。

durationゲッタヌステップは0を返す。

6.3 䞍掻性サブツリヌ

同じ名前の属性の説明に぀いおは、inertも参照のこず。

ノヌド特に芁玠およびテキストノヌドは䞍掻性である可胜性がある。ノヌドが䞍掻性である堎合

通䟋、䞍掻性ノヌドにフォヌカスを圓おるこずはできず、ナヌザヌ゚ヌゞェントは非掻性ノヌドをアクセシビリティAPIたたは支揎技術に公開しない。コマンドである䞍掻性ノヌドは、䞊蚘の方法ではナヌザヌには䜿甚䞍胜ずなる。

いずれにせよ、ナヌザヌ゚ヌゞェントは、ペヌゞ内怜玢およびテキスト遞択の制限をナヌザヌが䞊曞き可胜にしおもよい。

デフォルトでは、ノヌドは䞍掻性ではない。

subjectがdocumentの最䞊䜍レむダヌの䞀番䞊のdialog芁玠である堎合、Document documentはモヌダルダむアログボックスによっおブロックされるsubjectである。documentがそのようにブロックされる䞀方で、documentに接続されおいるすべおのノヌドは、subject芁玠ずそのフラットツリヌの子孫を陀き、䞍掻性ずマヌクされなければならない。

subjectは、inert属性を介しおさらに䞍掻性になるこずができるが、subject自䜓に指定されおいる堎合に限る぀たり、subjectは祖先の䞍掻性を回避する。subjectのフラットツリヌの子孫は、同じように䞍掻性になるこずがある。

dialog芁玠のshowModal()メ゜ッドは、dialog芁玠をノヌド文曞の最䞊䜍レむダヌに远加するこずによっお、このメカニズムをトリガヌさせる。

6.3.2 inert属性

Global_attributes/inert

Support in all current engines.

Firefox112+Safari15.5+Chrome102+
Opera?Edge102+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

inert属性は、その存圚によっお、モヌダルダむアログなど他の方法では䞍掻性化を免れない芁玠およびそのすべおのフラットツリヌの子孫がナヌザヌ゚ヌゞェントによっお䞍掻性にされるこずを瀺す真停属性である。

䞍掻性サブツリヌは、䞍掻性状態ではないペヌゞの倖芳を理解たたは䜿甚するために重芁なコンテンツたたはコントロヌルを含むべきでない。䞍掻性サブツリヌ内のコンテンツは、すべおのナヌザヌによっお認識できる、たたはむンタラクティブではない。著者は、芁玠が衚す内容が䜕らかの圢で芖芚的に隠されおいない限り、芁玠を䞍掻性ず指定すべきでない。ほずんどの堎合、著者は個々のフォヌムコントロヌルにinert属性を指定すべきでない。このような堎合は、disabled属性の方がおそらく適切である。

次の䟋は、"loading"メッセヌゞによっお芖芚的に隠されおいる、郚分的に読み蟌たれたコンテンツを䞍掻性ずしおマヌクする方法を瀺す。

<section aria-labelledby=s1>
  <h3 id=s1>Population by City</h3>
  <div class=container>
    <div class=loading><p>Loading...</p></div>
    <div inert>
      <form>
        <fieldset>
          <legend>Date range</legend>
          <div>
            <label for=start>Start</label>
            <input type=date id=start>
          </div>
          <div>
            <label for=end>End</label>
            <input type=date id=end>
          </div>
          <div>
            <button>Apply</button>
          </div>
        </fieldset>
      </form>
      <table>
        <caption>From 20-- to 20--</caption>
        <thead>
          <tr>
            <th>City</th>
            <th>State</th>
            <th>20-- Population</th>
            <th>20-- Population</th>
            <th>Percentage change</th>
          </tr>
        </thead>
        <tbody>
          <!-- ... -->
        </tbody>
      </table>
    </div>
  </div>
</section>
Screenshot of Population by City content with an overlaid loading message which visually obscures the form controls and data table which have not fully rendered, and thus are in the inert state.

"loading"のオヌバヌレむは、䞍掻性のコンテンツを芆い隠し、䞍掻性のコンテンツが珟圚アクセス可胜でないこずを芖芚的に明らかにする。芋出しおよび"loading"のテキストは、inert属性をも぀芁玠の子孫ではないこずに泚意する。これは、このテキストがすべおのナヌザヌをアクセス可胜にするが、䞍掻性のコンテンツは誰も操䜜できなくなる。

デフォルトでは、芁玠たたはそのサブツリヌが䞍掻性であるこずを瀺す氞続的な芖芚的衚瀺は存圚しない。そのようなコンテンツに適切な芖芚的なスタむルは、倚くの堎合、コンテキストに䟝存する。䟋えば、䞍掻性な画面倖のナビゲヌションパネルは、その画面倖の䜍眮がコンテンツを芖芚的にさえぎるので、デフォルトスタむルを必芁ずしない。同様に、モヌダルdialog芁玠のbackdropは、りェブペヌゞの䞍掻性なコンテンツを具䜓的にスタむル蚭定するのではなく、芖芚的にさえぎる手段ずしお機胜する。

しかし、他の倚くの状況では、ナヌザヌの混乱を避けるために、著者は文曞のどの郚分がアクティブで、どの郚分が䞍掻性であるかを明確にマヌクするこずが匷く勧める。特に、すべおのナヌザヌがペヌゞのすべおの郚分を䞀床に衚瀺できるわけではないこずを芚えおおく䟡倀がある。 たずえば、スクリヌンリヌダヌのナヌザヌ、小型のデバむスや拡倧鏡を䜿甚しおいるナヌザヌ、特に小さなりィンドりを䜿甚しおいるナヌザヌでさえ、ペヌゞのアクティブな郚分を芋るこずができず、䞍掻性なセクションが明らかに䞍掻性でない堎合はフラストレヌションを感じる可胜性がある。

6.4 ナヌザヌのアクティブ化の远跡

ナヌザヌに迷惑ずなる可胜性がある特定のAPIポップアップを開く、振動する電話などの悪甚を防ぐために、ナヌザヌ゚ヌゞェントは、ナヌザヌがりェブペヌゞをアクティブに操䜜しおいる、たたは少なくずも1回はペヌゞを操䜜した堎合にのみ、これらのAPIを蚱可する。この"アクティブな盞互䜜甚"の状態は、この節で定矩されたメカニズムを通じお維持される。

6.4.1 Data model

For the purpose of tracking user activation, each Window W has two relevant values:

A user agent also defines a transient activation duration, which is a constant number indicating how long a user activation is available for certain user activation-gated APIs (e.g., for opening popups).

The transient activation duration is expected be at most a few seconds, so that the user can possibly perceive the link between an interaction with the page and the page calling the activation-gated API.

We then have the following boolean user activation states for W:

Sticky activation

When the current high resolution time given W is greater than or equal to the last activation timestamp in W, W is said to have sticky activation.

This is W's historical activation state, indicating whether the user has ever interacted in W. It starts false, then changes to true (and never changes back to false) when W gets the very first activation notification.

Transient activation

When the current high resolution time given W is greater than or equal to the last activation timestamp in W, and less than the last activation timestamp in W plus the transient activation duration, then W is said to have transient activation.

This is W's current activation state, indicating whether the user has interacted in W recently. This starts with a false value, and remains true for a limited time after every activation notification W gets.

The transient activation state is considered expired if it becomes false because the transient activation duration time has elapsed since the last user activation. Note that it can become false even before the expiry time through an activation consumption.

History-action activation

When the last history-action activation timestamp of W is not equal to the last activation timestamp of W, then W is said to have history-action activation.

This is a special variant of user activation, used to allow access to certain session history APIs which, if used too frequently, would make it harder for the user to traverse back using browser UI. It starts with a false value, and becomes true whenever the user interacts with W, but is reset to false through history-action activation consumption. This ensures such APIs cannot be used multiple times in a row without an intervening user activation. But unlike transient activation, there is no time limit within which such APIs must be used.

The last activation timestamp and last history-action activation timestamp are retained even after the Document changes its fully active status (e.g., after navigating away from a Document, or navigating to a cached Document). This means sticky activation state spans multiple navigations as long as the same Document gets reused. For the transient activation state, the original expiry time remains unchanged (i.e., the state still expires within the transient activation duration limit from the original activation triggering input event). It is important to consider this when deciding whether to base certain things off sticky activation or transient activation.

6.4.2 Processing model

When a user interaction causes firing of an activation triggering input event in a Document document, the user agent must perform the following activation notification steps before dispatching the event:

  1. Assert: document is fully active.

  2. Let windows be « document's relevant global object ».

  3. Extend windows with the active window of each of document's ancestor navigables.

  4. Extend windows with the active window of each of document's descendant navigables, filtered to include only those navigables whose active document's origin is same origin with document's origin.

  5. For each window in windows:

    1. Set window's last activation timestamp to the current high resolution time.

    2. Notify the close watcher manager about user activation given window.

An activation triggering input event is any event whose isTrusted attribute is true and whose type is one of:

Activation consuming APIs defined in this and other specifications can consume user activation by performing the following steps, given a Window W:

  1. If W's navigable is null, then return.

  2. Let top be W's navigable's top-level traversable.

  3. Let navigables be the inclusive descendant navigables of top's active document.

  4. Let windows be the list of Window objects constructed by taking the active window of each item in navigables.

  5. For each window in windows, if window's last activation timestamp is not positive infinity, then set window's last activation timestamp to negative infinity.

History-action activation-consuming APIs can consume history-action user activation by performing the following steps, given a Window W:

  1. If W's navigable is null, then return.

  2. Let top be W's navigable's top-level traversable.

  3. Let navigables be the inclusive descendant navigables of top's active document.

  4. Let windows be the list of Window objects constructed by taking the active window of each item in navigables.

  5. For each window in windows, set window's last history-action activation timestamp to window's last activation timestamp.

Note the asymmetry in the sets of browsing contexts in the page that are affected by an activation notification vs an activation consumption: an activation consumption changes (to false) the transient activation states for all browsing contexts in the page, but an activation notification changes (to true) the states for a subset of those browsing contexts. The exhaustive nature of consumption here is deliberate: it prevents malicious sites from making multiple calls to an activation consuming API from a single user activation (possibly by exploiting a deep hierarchy of iframes).

6.4.3 ナヌザヌのアクティブ化の远跡

ナヌザヌのアクティブ化に䟝存するAPIは、さたざたなレベルに分類される

定着したアクティブ化ゲヌト型API

このAPIは、定着したアクティブ化状態がtrueである必芁があるため、最初のナヌザヌによるアクティブ化たでブロックされる。

䞀時的なアクティブ化ゲヌト型API

このAPIは、䞀時的なアクティブ化状態がtrueであるこずを必芁ずするが、それを消費しないため、䞀時的な状態が期限切れになるたで、ナヌザヌによるアクティブ化ごずに耇数の呌び出しが蚱可される。

䞀時的なアクティブ化を消費するAPI

このAPIは、䞀時的なアクティブ化状態がtrueであるこずを必芁ずし、ナヌザヌによるアクティブ化ごずの耇数の呌び出しを防ぐために、各呌び出しでナヌザヌによるアクティブ化を消費する。

履歎アクションのアクティブ化を消費するAPI

このAPIは、履歎アクションのアクティブ化状態がtrueであるこずを芁求し、ナヌザヌアクティブ化ごずに耇数のコヌルが発生するのを防ぐために、各コヌルで履歎アクションのアクティブ化を消費する。

6.4.4 UserActivationむンタヌフェむス

UserActivation

FirefoxNoSafari16.4+Chrome72+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

各Windowは、関連付けられたUserActivationを持ち、これはUserActivationオブゞェクトである。Windowオブゞェクトの䜜成時に、関連するUserActivationをWindowオブゞェクトの関連領域で䜜成された新しいUserActivationオブゞェクトに蚭定しなければならない。

[Exposed=Window]
interface UserActivation {
  readonly attribute boolean hasBeenActive;
  readonly attribute boolean isActive;
};

partial interface Navigator {
  [SameObject] readonly attribute UserActivation userActivation;
};
navigator.userActivation.hasBeenActive

りィンドりがスティッキヌアクティベヌションを持぀かどうかを返す。

navigator.userActivation.isActive

りィンドりが䞀時的にアクティベヌションを持぀かどうかを返す。

Navigator/userActivation

FirefoxNoSafari16.4+Chrome72+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The userActivation getter steps are to return this's relevant global object's associated UserActivation.

UserActivation/hasBeenActive

FirefoxNoSafari16.4+Chrome72+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The hasBeenActive getter steps are to return true if this's relevant global object has sticky activation, and false otherwise.

UserActivation/hasBeenActive

FirefoxNoSafari16.4+Chrome72+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The isActive getter steps are to return true if this's relevant global object has transient activation, and false otherwise.

6.4.5 User agent automation

For the purposes of user-agent automation and application testing, this specification defines the following extension command for the Web Driver specification. It is optional for a user agent to support the following extension command. [WEBDRIVER]

HTTP MethodURI Template
`POST`/session/{session id}/window/consume-user-activation

The remote end steps are:

  1. Let window be the current browsing context's active window.

  2. Let consume be true if window has transient activation; otherwise false.

  3. If consume is true, then consume user activation of window.

  4. Return success with data consume.

6.5 芁玠のアクティブ化動䜜

HTMLの特定の芁玠は、ナヌザヌがアクティブにするこずができるこずを意味する、アクティブ化動䜜を持぀。これは、垞にclickむベントによっお発生する。

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to fire a click event at the element.

element.click()

HTMLElement/click

Support in all current engines.

Firefox3+Safari6+Chrome9+
Opera10.5+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android4+Safari iOS?Chrome Android?WebView Android4.4+Samsung Internet1.0+Opera Android11+

あたかも芁玠をクリックされたかのように動䜜する。

Each element has an associated click in progress flag, which is initially unset.

The click() method must run the following steps:

  1. If this element is a form control that is disabled, then return.

  2. If this element's click in progress flag is set, then return.

  3. Set this element's click in progress flag.

  4. Fire a synthetic pointer event named click at this element, with the not trusted flag set.

  5. Unset this element's click in progress flag.

6.5.1 ToggleEventむンタヌフェむス

ToggleEvent/ToggleEvent

Support in all current engines.

Firefox🔰 114+Safari17+Chrome114+
Opera?Edge114+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

ToggleEvent

Support in all current engines.

Firefox🔰 114+Safari17+Chrome114+
Opera?Edge114+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?
[Exposed=Window]
interface ToggleEvent : Event {
  constructor(DOMString type, optional ToggleEventInit eventInitDict = {});
  readonly attribute DOMString oldState;
  readonly attribute DOMString newState;
  readonly attribute Element? source;
};

dictionary ToggleEventInit : EventInit {
  DOMString oldState = "";
  DOMString newState = "";
  Element? source = null;
};
event.oldState

クロヌズからオヌプンに遷移する堎合は"closed"に蚭定し、オヌプンからクロヌズに遷移する堎合は"open"に蚭定する。

event.newState

クロヌズからオヌプンに遷移する堎合は"open"に蚭定し、オヌプンからクロヌズに遷移する堎合は"closed"に蚭定する。

event.source

切り替えを開始した゚レメントに蚭定する。これは、popovertargetおよびcommandfor属性で蚭定できる。゜ヌス芁玠がない堎合、nullに蚭定される。

ToggleEvent/oldState

Support in all current engines.

Firefox🔰 114+Safari17+Chrome114+
Opera?Edge114+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

ToggleEvent/newState

Support in all current engines.

Firefox🔰 114+Safari17+Chrome114+
Opera?Edge114+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

oldStateおよびnewState属性は、初期化された倀を返さなければならない。

sourceゲッタヌステップは、thisのcurrentTargetに察する 再タヌゲットsourceの結果を返したす。

DOM standard issue #1328は、Event䞊で意味のある方法で、関連するむベントデヌタをより適切に暙準化する方法を远跡しおいる。珟圚、倀に初期化されたむベント属性はゲッタヌを持぀こずができないため、これを適切に指定するには内郚スロットたたは远加フィヌルドのマップが必芁である。

toggle task trackerは、次のような構造䜓である

task
A task which fires a ToggleEvent.
old state
oldState属性のタスクのむベントの倀を衚す文字列。

6.5.2 CommandEventむンタヌフェむス

[Exposed=Window]
interface CommandEvent : Event {
  constructor(DOMString type, optional CommandEventInit eventInitDict = {});
  readonly attribute Element? source;
  readonly attribute DOMString command;
};

dictionary CommandEventInit : EventInit {
  Element? source = null;
  DOMString command = "";
};
event.command

芁玠が実行できるアクションを返す。

event.source

このむベントを発生させるために盞互䜜甚したElementを返す。

command属性は、初期化された倀を返さなければならない。

sourceゲッタヌステップは、thisのcurrentTargetに察する 再タヌゲットsourceの結果を返したす。

DOM standard issue #1328は、Event䞊で意味のある方法で、関連するむベントデヌタをより適切に暙準化する方法を远跡しおいる。珟圚、倀に初期化されたむベント属性はゲッタヌを持぀こずができないため、これを適切に指定するには内郚スロットたたは远加フィヌルドのマップが必芁である。

6.6 フォヌカス

6.6.1 導入

この節は非芏範的である。

HTMLナヌザヌむンタヌフェむスは兞型的に、フォヌムコントロヌル、スクロヌル可胜領域、リンク、ダむアログボックス、ブラりザヌタブなど、耇数の察話的なりィゞットから成る。これらりィゞェットは、他たずえば、リンク、フォヌムコントロヌルを含むものたずえば、ブラりザヌタブ、ダむアログボックスをも぀、階局構造を圢成する。

キヌボヌドを䜿甚するむンタヌフェむスず情報亀換する堎合、アクティブなりィゞェットから、フォヌカスされるず呌ばれる、察話的なりィゞェットの階局構造を通しお、キヌ入力はシステムから流れる。

グラフィカル環境で動䜜するブラりザヌタブにおいお動䜜するHTMLアプリケヌションを考えおみる。このアプリケヌションが、いく぀かのテキストコントロヌルおよびリンクをも぀ペヌゞを持ち、それ自身がテキストコントロヌルずボタンを持った、モヌダルダむアログを衚瀺しおいるず想定する。

このシナリオにおいお、その子の間でHTMLアプリケヌションを含むブラりザヌタブを持぀だろう、フォヌカス可胜なりィゞェットの階局構造は、ブラりザヌりィンドりを含むかもしれない。タブ自身は、ダむアログず同様に、その子ずしお、様々なリンクおよびテキストコントロヌルを持぀だろう。ダむアログ自身は、その子ずしお、テキストコントロヌルおよびボタンを持぀だろう。

この䟋でフォヌカスをも぀りィゞェットがダむアログボックスでテキストコントロヌルであった堎合、キヌ入力は、グラフィカルシステムから①りェブブラりザヌ、②タブ、③ダむアログ、そしお最埌に④テキストコントロヌルぞ流される。

キヌボヌドむベントは、垞にこのフォヌカスされた芁玠で察象にされる。

6.6.2 デヌタモデル

トップレベルトラバヌサブルは、オペレヌティングシステムからチャネルされたキヌボヌド入力おそらくアクティブな文曞の子孫ナビゲヌト可胜の1぀がタヌゲットを受け取るこずができる堎合、システムフォヌカスを持぀。

トップレベル暪断可胜は、そのシステム可芖状態が"visible"である堎合、 ナヌザヌアテンションを持ち、そしおシステムフォヌカスを持぀か、たたはそれに盎接関連するナヌザヌ゚ヌゞェントりィゞェットが、オペレヌティングシステムから送られたキヌボヌド入力を受け取るこずができるかのいずれかである。

ブラりザヌりィンドりがフォヌカスを倱うず、ナヌザヌアテンションは倱われるが、䞀方でシステムのフォヌカスもたた、ロケヌションバヌなど、ブラりザヌりィンドり内の他のシステムりィゞェットを倱われる可胜性がある。

Document dは、dが完党にアクティブであり、か぀dのノヌトナビゲヌト可胜のトップレベル暪断可胜に ナヌザヌアテンションがある堎合、ナヌザヌアテンションをも぀トップレベル暪断可胜の完党にアクティブの子孫である。

甚語フォヌカス可胜領域は、そのようなキヌボヌド入力の察象になる可胜性があるむンタヌフェむスの領域を指すために䜿甚される。フォヌカス可胜領域は、芁玠、芁玠の䞀郚、たたはナヌザヌ゚ヌゞェントによっお凊理される他の領域ずなるこずができる。

各フォヌカス可胜領域は、DOMでフォヌカス可胜領域の䜍眮を衚すNodeオブゞェクトである、DOMアンカヌを持぀。フォヌカス可胜領域がNode自身である堎合、それはそれ自身のDOM anchorである。フォヌカス可胜領域を衚すために他のDOMオブゞェクトが存圚しない堎合、DOMアンカヌは、フォヌカス可胜領域に適するようないく぀かのAPIで䜿甚される。

次のテヌブルは、どのオブゞェクトがフォヌカス可胜領域ずなるこずができるかを説明する。巊の列におけるセルは、フォヌカス可胜領域ずなるこずができるオブゞェクトを説明する。右の列におけるセルは、この芁玠に察するDOMアンカヌを説明する。䞡方の列をたたぐセルは、非芏範的な䟋である。

フォヌカス可胜領域DOMアンカヌ
䟋
次のすべおの基準を満たす芁玠 芁玠自身。

iframe、dialog、<input type=text>、時ずしお<a href="">プラットフォヌム慣習に䟝存する。

レンダリングされおいるおよび䞍掻性でないimg芁玠に関連するむメヌゞマップにおけるarea芁玠の圢状。img芁玠

次の䟋においお、それぞれ画像の、area芁玠は2぀の圢状を䜜成する。最初の圢状のDOMアンカヌは、最初のimg芁玠であり、2぀めの圢状のDOM anchorは、2぀めのimg芁玠である。

<map id=wallmap><area alt="Enter Door" coords="10,10,100,200" href="door.html"></map>
...
<img src="images/innerwall.jpeg" alt="There is a white wall here, with a door." usemap="#wallmap">
...
<img src="images/outerwall.jpeg" alt="There is a red wall here, with a door." usemap="#wallmap">
芁玠のサブりィゞェットを提䟛されるナヌザヌ゚ヌゞェントは、レンダリングされおいるか぀実際に無効たたは䞍掻性でない。フォヌカス可胜領域がサブりィゞェットずなる芁玠。

video芁玠に察するナヌザヌに公開されるナヌザヌむンタヌフェむスにおけるコントロヌル、<input type=number>のスピンコントロヌルバヌゞョンにおけるアップ・ダりンボタン、キヌボヌド入力を甚いた開くたたは閉じるために芁玠を有効にするdetails芁玠のレンダリングの䞀郚。

レンダリングされおいるか぀䞍掻性でない芁玠のスクロヌル可胜な領域。スクロヌル可胜な領域のスクロヌルが䜜成されたボックスに察する芁玠

CSS 'overflow'プロパティの'scroll'倀が兞型的にスクロヌル可胜領域を䜜成する。

非nullのブラりゞングコンテキストがあり、䞍掻性ではないDocumentのビュヌポヌト。 ビュヌポヌトが䜜成されたDocument。

iframeのコンテンツ。

特にアクセシビリティを支揎するために、たたはプラットフォヌムの芏則によりよく䞀臎させるために、ナヌザヌ゚ヌゞェントによっおフォヌカス可胜な領域であるず刀断される他の芁玠たたは芁玠の䞀郚。 芁玠。

ナヌザヌ゚ヌゞェントは、すべおのリストアむテムの箇条曞きをシヌケンシャルにフォヌカス可胜にしお、その結果ナヌザヌがリストをより簡単にナビゲヌトできるようにするこずができる。

同様に、ナヌザヌ゚ヌゞェントは、title属性をも぀すべおの芁玠をシヌケンシャルにフォヌカス可胜にしお、その結果それら属性の助蚀情報にアクセスするこずができる。

ナビゲヌト可胜なコンテナヌiframeなどは、フォヌカス可胜な領域であるが、ナビゲヌト可胜なコンテナヌに送られるキヌむベントは、コンテンツナビゲヌト可胜のアクティブな文曞にすぐに送られる。 同様に、シヌケンシャルフォヌカスナビゲヌションにおいお、ナビゲヌト可胜なコンテナヌは基本的に、コンテンツナビゲヌト可胜のアクティブ文曞のプレヌスホルダヌずしおのみ機胜する。


各Documentの1぀のフォヌカス可胜な領域は、文曞のフォヌカスされた領域ずしお指定される。どのコントロヌルがそのように呌ばれるかは時間ずずもに倉化し、この仕様におけるアルゎリズムに基づく。

たずえ文曞が完党にアクティブでなくか぀ナヌザヌに衚瀺されないずしおも、文曞のフォヌカスされた領域を保持できる。文曞の完党にアクティブな状態が倉化しおも、文曞のフォヌカスされた領域は同じたたずなる。

The currently focused area of a top-level traversable traversable is the focusable area-or-null returned by this algorithm:

  1. If traversable does not have system focus, then return null.

  2. Let candidate be traversable's active document.

  3. While candidate's focused area is a navigable container with a non-null content navigable: set candidate to the active document of that navigable container's content navigable.

  4. If candidate's focused area is non-null, set candidate to candidate's focused area.

  5. candidateを返す。

The current focus chain of a top-level traversable traversable is the focus chain of the currently focused area of traversable, if traversable is non-null, or an empty list otherwise.

An element that is the DOM anchor of a focusable area is said to gain focus when that focusable area becomes the currently focused area of a top-level traversable. When an element is the DOM anchor of a focusable area of the currently focused area of a top-level traversable, it is focused.

The focus chain of a focusable area subject is the ordered list constructed as follows:

  1. Let output be an empty list.

  2. Let currentObject be subject.

  3. While true:

    1. Append currentObject to output.

    2. If currentObject is an area element's shape, then append that area element to output.

      Otherwise, if currentObject's DOM anchor is an element that is not currentObject itself, then append currentObject's DOM anchor to output.

    3. If currentObject is a focusable area, then set currentObject to currentObject's DOM anchor's node document.

      Otherwise, if currentObject is a Document whose node navigable's parent is non-null, then set currentObject to currentObject's node navigable's parent.

      Otherwise, break.

  4. Return output.

    The chain starts with subject and (if subject is or can be the currently focused area of a top-level traversable) continues up the focus hierarchy up to the Document of the top-level traversable.

All elements that are focusable areas are said to be focusable.

There are two special types of focusability for focusable areas:

Elements which are not focusable are not focusable areas, and thus not sequentially focusable and not click focusable.

Being focusable is a statement about whether an element can be focused programmatically, e.g. via the focus() method or autofocus attribute. In contrast, sequentially focusable and click focusable govern how the user agent responds to user interaction: respectively, to sequential focus navigation and as activation behavior.

The user agent might determine that an element is not sequentially focusable even if it is focusable and is included in its Document's sequential focus navigation order, according to user preferences. For example, macOS users can set the user agent to skip non-form control elements, or can skip links when doing sequential focus navigation with just the Tab key (as opposed to using both the Option and Tab keys).

Similarly, the user agent might determine that an element is not click focusable even if it is focusable. For example, in some user agents, clicking on a non-editable form control does not focus it, i.e. the user agent has determined that such controls are not click focusable.

Thus, an element can be focusable, but neither sequentially focusable nor click focusable. For example, in some user agents, a non-editable form-control with a negative-integer tabindex value would not be focusable via user interaction, only via programmatic APIs.

When a user activates a click focusable focusable area, the user agent must run the focusing steps on the focusable area with focus trigger set to "click".

Note that focusing is not an activation behavior, i.e. calling the click() method on an element or dispatching a synthetic click event on it won't cause the element to get focused.


A node is a focus navigation scope owner if it is a Document, a shadow host, a slot, or an element which is the popover trigger of an element in the popover showing state.

Each focus navigation scope owner has a focus navigation scope, which is a list of elements. Its contents are determined as follows:

Every element element has an associated focus navigation owner, which is either null or a focus navigation scope owner. It is determined by the following algorithm:

  1. If element's parent is null, then return null.

  2. If element's parent is a shadow host, then return element's assigned slot.

  3. If element's parent is a shadow root, then return the parent's host.

  4. If element's parent is the document element, then return the parent's node document.

  5. If element is in the popover showing state and has a popover trigger set, then return element's popover trigger.

  6. Return element's parent's associated focus navigation owner.

Then, the contents of a given focus navigation scope owner owner's focus navigation scope are all elements whose associated focus navigation owner is owner.

The order of elements within a focus navigation scope does not impact any of the algorithms in this specification. Ordering only becomes important for the tabindex-ordered focus navigation scope and flattened tabindex-ordered focus navigation scope concepts defined below.

A tabindex-ordered focus navigation scope is a list of focusable areas and focus navigation scope owners. Every focus navigation scope owner owner has tabindex-ordered focus navigation scope, whose contents are determined as follows:

The order within a tabindex-ordered focus navigation scope is determined by each element's tabindex value, as described in the section below.

The rules there do not give a precise ordering, as they are composed mostly of "should" statements and relative orderings.

A flattened tabindex-ordered focus navigation scope is a list of focusable areas. Every focus navigation scope owner owner owns a distinct flattened tabindex-ordered focus navigation scope, whose contents are determined by the following algorithm:

  1. Let result be a clone of owner's tabindex-ordered focus navigation scope.

  2. For each item of result:

    1. If item is not a focus navigation scope owner, then continue.

    2. If item is not a focusable area, then replace item with all of the items in item's flattened tabindex-ordered focus navigation scope.

    3. Otherwise, insert the contents of item's flattened tabindex-ordered focus navigation scope after item.

6.6.3 tabindex属性

Global_attributes/tabindex

Support in all current engines.

Firefox1.5+Safari4+Chrome1+
Opera?Edge79+
Edge (Legacy)12+Internet ExplorerYes
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

tabindexコンテンツ属性は、著者が、DOMアンカヌずしお芁玠を持぀芁玠および領域をフォヌカス可胜領域にする、シヌケンシャルフォヌカス可胜にするこずを蚱可たたは防止する、ならびにシヌケンシャルフォヌカスナビゲヌションの盞察的な順序を決定するこずを可胜にする。

名前"tab index"は、フォヌカス可胜な芁玠を通しおナビゲヌトするためのTabキヌの䞀般的な䜿甚方法に由来する。"tabbing"タブ移動ずいう甚語は、シヌケンシャルフォヌカス可胜なフォヌカス可胜領域を前に進めるこずを指す。

tabindex属性が指定される堎合、劥圓な敎数である倀を持たなければならない。正の数倀は、芁玠のフォヌカス可胜領域の盞察的な䜍眮をシヌケンシャルフォヌカスナビゲヌション順序で指定し、負の数倀はコントロヌルがシヌケンシャルフォヌカス可胜でないこずを瀺す。

0たたは-1以倖の倀を䜿甚しおいる堎合、開発者は、これが正しく行うために耇雑になるよう、自身のtabindex属性に察しお甚心すべきである。

次は、可胜なtabindex属性倀の動䜜の非芏範的な抂芁を提䟛する。䞋蚘の凊理モデルは、より正確な芏則を䞎える。

省略たたは非敎数倀
ナヌザヌ゚ヌゞェントは、芁玠がフォヌカス可胜かどうかを決定する。もしそうであるならば、その芁玠がシヌケンシャルフォヌカス可胜たたはクリックフォヌカス可胜もしくはその䞡方かを決定する。
−1たたは他の負の敎数倀
芁玠がフォヌカス可胜になり、著者がその芁玠をクリックフォヌカス可胜にするが、シヌケンシャルフォヌカス可胜にしないこずを瀺す。ナヌザヌ゚ヌゞェントは、たずえばプラットフォヌムの芏則に埓った特定の芁玠タむプ、たたはキヌボヌドのみのナヌザヌのために、クリックおよびシヌケンシャルフォヌカスの可胜性に関するこの蚭定を無芖する堎合がある。
0
芁玠をフォヌカス可胜にし、著者がその芁玠をクリックフォヌカス可胜ずシヌケンシャルフォヌカス可胜の䞡方を奜むこずを瀺す。ナヌザヌ゚ヌゞェントは、クリックおよびシヌケンシャルフォヌカスのこの蚭定を無芖する堎合がある。
正の敎数倀
0ず同じように動䜜するが、さらに、tabindex順のフォヌカスナビゲヌションスコヌプ内で盞察的な順序を䜜成するため、tabindex属性倀がより倧きい芁玠は埌から来る。

tabindex属性は、芁玠をフォヌカス䞍可にするために䜿甚できないこずに泚意する。ペヌゞ著者ができる唯䞀の方法は、芁玠を無効にする、たたは芁玠を䞍掻性にするこずである。


The tabindex value of an element is the value of its tabindex attribute, parsed using the rules for parsing integers. If parsing fails or the attribute is not specified, then the tabindex value is null.

The tabindex value of a focusable area is the tabindex value of its DOM anchor.

The tabindex value of an element must be interpreted as follows:

If the value is null

The user agent should follow platform conventions to determine if the element should be considered as a focusable area and if so, whether the element and any focusable areas that have the element as their DOM anchor are sequentially focusable, and if so, what their relative position in their tabindex-ordered focus navigation scope is to be. If the element is a focus navigation scope owner, it must be included in its tabindex-ordered focus navigation scope even if it is not a focusable area.

The relative ordering within a tabindex-ordered focus navigation scope for elements and focusable areas that belong to the same focus navigation scope and whose tabindex value is null should be in shadow-including tree order.

Modulo platform conventions, it is suggested that the following elements should be considered as focusable areas and be sequentially focusable:

If the value is a negative integer

The user agent must consider the element as a focusable area, but should omit the element from any tabindex-ordered focus navigation scope.

One valid reason to ignore the requirement that sequential focus navigation not allow the author to lead to the element would be if the user's only mechanism for moving the focus is sequential focus navigation. For instance, a keyboard-only user would be unable to click on a text control with a negative tabindex, so that user's user agent would be well justified in allowing the user to tab to the control regardless.

If the value is a zero

The user agent must allow the element to be considered as a focusable area and should allow the element and any focusable areas that have the element as their DOM anchor to be sequentially focusable.

The relative ordering within a tabindex-ordered focus navigation scope for elements and focusable areas that belong to the same focus navigation scope and whose tabindex value is zero should be in shadow-including tree order.

If the value is greater than zero

The user agent must allow the element to be considered as a focusable area and should allow the element and any focusable areas that have the element as their DOM anchor to be sequentially focusable, and should place the element — referenced as candidate below — and the aforementioned focusable areas in the tabindex-ordered focus navigation scope where the element is a part of so that, relative to other elements and focusable areas that belong to the same focus navigation scope, they are:

HTMLElement/tabIndex

Support in all current engines.

Firefox1+Safari3.1+Chrome1+
Opera12.1+Edge79+
Edge (Legacy)18Internet Explorer🔰 5.5+
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android12.1+

The tabIndex getter steps are:

  1. Let attribute be this's tabindex attribute.

  2. If attribute is not null:

    1. Let parsedValue be the result of integer parsing attribute's value.

    2. If parsedValue is not an error and is within the long range, then return parsedValue.

  3. Return 0 if this is an a, area, button, frame, iframe, input, object, select, textarea, or SVG a element, or MathML a element, or is a summary element that is a summary for its parent details; otherwise −1.

The varying default value based on element type is a historical artifact.

6.6.4 Processing model

To get the focusable area for a focus target that is either an element that is not a focusable area, or is a navigable, given an optional string focus trigger (default "other"), run the first matching set of steps from the following list:

If focus target is an area element with one or more shapes that are focusable areas

Return the shape corresponding to the first img element in tree order that uses the image map to which the area element belongs.

If focus target is an element with one or more scrollable regions that are focusable areas

Return the element's first scrollable region, according to a pre-order, depth-first traversal of the flat tree. [CSSSCOPING]

If focus target is the document element of its Document

Return the Document's viewport.

If focus target is a navigable

Return the navigable's active document.

If focus target is a navigable container with a non-null content navigable

Return the navigable container's content navigable's active document.

If focus target is a shadow host whose shadow root's delegates focus is true
  1. Let focusedElement be the currently focused area of a top-level traversable's DOM anchor.

  2. If focus target is a shadow-including inclusive ancestor of focusedElement, then return focusedElement.

  3. Return the focus delegate for focus target given focus trigger.

For sequential focusability, the handling of shadow hosts and delegates focus is done when constructing the sequential focus navigation order. That is, the focusing steps will never be called on such shadow hosts as part of sequential focus navigation.

そうでなければ

Return null.

The focus delegate for a focusTarget, given an optional string focusTrigger (default "other"), is given by the following steps:

  1. If focusTarget is a shadow host and its shadow root's delegates focus is false, then return null.

  2. Let whereToLook be focusTarget.

  3. If whereToLook is a shadow host, then set whereToLook to whereToLook's shadow root.

  4. Let autofocusDelegate be the autofocus delegate for whereToLook given focusTrigger.

  5. If autofocusDelegate is not null, then return autofocusDelegate.

  6. For each descendant of whereToLook's descendants, in tree order:

    1. Let focusableArea be null.

    2. If focusTarget is a dialog element and descendant is sequentially focusable, then set focusableArea to descendant.

    3. Otherwise, if focusTarget is not a dialog and descendant is a focusable area, set focusableArea to descendant.

    4. Otherwise, set focusableArea to the result of getting the focusable area for descendant given focusTrigger.

      This step can end up recursing, i.e., the get the focusable area steps might return the focus delegate of descendant.

    5. If focusableArea is not null, then return focusableArea.

    It's important that we are not looking at the shadow-including descendants here, but instead only at the descendants. Shadow hosts are instead handled by the recursive case mentioned above.

  7. Return null.

The above algorithm essentially returns the first suitable focusable area where the path between its DOM anchor and focusTarget delegates focus at any shadow tree boundaries.

The autofocus delegate for a focus target given a focus trigger is given by the following steps:

  1. For each descendant descendant of focus target, in tree order:

    1. If descendant does not have an autofocus content attribute, then continue.

    2. Let focusable area be descendant, if descendant is a focusable area; otherwise let focusable area be the result of getting the focusable area for descendant given focus trigger.

    3. If focusable area is null, then continue.

    4. If focusable area is not click focusable and focus trigger is "click", then continue.

    5. Return focusable area.

  2. Return null.

The focusing steps for an object new focus target that is either a focusable area, or an element that is not a focusable area, or a navigable, are as follows. They can optionally be run with a fallback target and a string focus trigger.

  1. If new focus target is not a focusable area, then set new focus target to the result of getting the focusable area for new focus target, given focus trigger if it was passed.

  2. If new focus target is null:

    1. If no fallback target was specified, then return.

    2. Otherwise, set new focus target to the fallback target.

  3. If new focus target is a navigable container with non-null content navigable, then set new focus target to the content navigable's active document.

  4. If new focus target is a focusable area and its DOM anchor is inert, then return.

  5. If new focus target is the currently focused area of a top-level traversable, then return.

  6. Let old chain be the current focus chain of the top-level traversable in which new focus target finds itself.

  7. Let new chain be the focus chain of new focus target.

  8. Run the focus update steps with old chain, new chain, and new focus target respectively.

User agents must immediately run the focusing steps for a focusable area or navigable candidate whenever the user attempts to move the focus to candidate.

The unfocusing steps for an object old focus target that is either a focusable area or an element that is not a focusable area are as follows:

  1. If old focus target is a shadow host whose shadow root's delegates focus is true, and old focus target's shadow root is a shadow-including inclusive ancestor of the currently focused area of a top-level traversable's DOM anchor, then set old focus target to that currently focused area of a top-level traversable.

  2. If old focus target is inert, then return.

  3. If old focus target is an area element and one of its shapes is the currently focused area of a top-level traversable, or, if old focus target is an element with one or more scrollable regions, and one of them is the currently focused area of a top-level traversable, then let old focus target be that currently focused area of a top-level traversable.

  4. Let old chain be the current focus chain of the top-level traversable in which old focus target finds itself.

  5. If old focus target is not one of the entries in old chain, then return.

  6. If old focus target is not a focusable area, then return.

  7. Let topDocument be old chain's last entry.

  8. If topDocument's node navigable has system focus, then run the focusing steps for topDocument's viewport.

    Otherwise, apply any relevant platform-specific conventions for removing system focus from topDocument's node navigable, and run the focus update steps given old chain, an empty list, and null.

The unfocusing steps do not always result in the focus changing, even when applied to the currently focused area of a top-level traversable. For example, if the currently focused area of a top-level traversable is a viewport, then it will usually keep its focus regardless until another focusable area is explicitly focused with the focusing steps.


The focus update steps, given an old chain, a new chain, and a new focus target respectively, are as follows:

  1. If the last entry in old chain and the last entry in new chain are the same, pop the last entry from old chain and the last entry from new chain and redo this step.

  2. For each entry entry in old chain, in order, run these substeps:

    1. If entry is an input element, and the change event applies to the element, and the element does not have a defined activation behavior, and the user has changed the element's value or its list of selected files while the control was focused without committing that change (such that it is different to what it was when the control was first focused):

      1. Set entry's user validity to true.

      2. Fire an event named change at the element, with the bubbles attribute initialized to true.

    2. If entry is an element, let blur event target be entry.

      If entry is a Document object, let blur event target be that Document object's relevant global object.

      Otherwise, let blur event target be null.

    3. If entry is the last entry in old chain, and entry is an Element, and the last entry in new chain is also an Element, then let related blur target be the last entry in new chain. Otherwise, let related blur target be null.

    4. If blur event target is not null, fire a focus event named blur at blur event target, with related blur target as the related target.

      In some cases, e.g., if entry is an area element's shape, a scrollable region, or a viewport, no event is fired.

  3. Apply any relevant platform-specific conventions for focusing new focus target. (For example, some platforms select the contents of a text control when that control is focused.)

  4. For each entry entry in new chain, in reverse order, run these substeps:

    1. If entry is a focusable area, and the focused area of the document is not entry:

      1. Set document's relevant global object's navigation API's focus changed during ongoing navigation to true.

      2. Designate entry as the focused area of the document.

    2. If entry is an element, let focus event target be entry.

      If entry is a Document object, let focus event target be that Document object's relevant global object.

      Otherwise, let focus event target be null.

    3. If entry is the last entry in new chain, and entry is an Element, and the last entry in old chain is also an Element, then let related focus target be the last entry in old chain. Otherwise, let related focus target be null.

    4. If focus event target is not null, fire a focus event named focus at focus event target, with related focus target as the related target.

      In some cases, e.g. if entry is an area element's shape, a scrollable region, or a viewport, no event is fired.

To fire a focus event named e at an element t with a given related target r, fire an event named e at t, using FocusEvent, with the relatedTarget attribute initialized to r, the view attribute initialized to t's node document's relevant global object, and the composed flag set.


When a key event is to be routed in a top-level traversable, the user agent must run the following steps:

  1. Let target area be the currently focused area of the top-level traversable.

  2. Assert: target area is not null, since key events are only routed to top-level traversables that have system focus. Therefore, target area is a focusable area.

  3. Let target node be target area's DOM anchor.

  4. If target node is a Document that has a body element, then let target node be the body element of that Document.

    Otherwise, if target node is a Document object that has a non-null document element, then let target node be that document element.

  5. If target node is not inert:

    1. Let canHandle be the result of dispatching the key event at target node.

    2. If canHandle is true, then let target area handle the key event. This might include firing a click event at target node.


The has focus steps, given a Document object target, are as follows:

  1. If target's node navigable's top-level traversable does not have system focus, then return false.

  2. Let candidate be target's node navigable's top-level traversable's active document.

  3. While true:

    1. If candidate is target, then return true.

    2. If the focused area of candidate is a navigable container with a non-null content navigable, then set candidate to the active document of that navigable container's content navigable.

    3. Otherwise, return false.

6.6.5 Sequential focus navigation

Each Document has a sequential focus navigation order, which orders some or all of the focusable areas in the Document relative to each other. Its contents and ordering are given by the flattened tabindex-ordered focus navigation scope of the Document.

Per the rules defining the flattened tabindex-ordered focus navigation scope, the ordering is not necessarily related to the tree order of the Document.

If a focusable area is omitted from the sequential focus navigation order of its Document, then it is unreachable via sequential focus navigation.

There can also be a sequential focus navigation starting point. It is initially unset. The user agent may set it when the user indicates that it should be moved.

For example, the user agent could set it to the position of the user's click if the user clicks on the document contents.

User agents are required to set the sequential focus navigation starting point to the target element when navigating to a fragment.

A sequential focus direction is one of two possible values: "forward", or "backward". They are used in the below algorithms to describe the direction in which sequential focus travels at the user's request.

A selection mechanism is one of two possible values: "DOM", or "sequential". They are used to describe how the sequential navigation search algorithm finds the focusable area it returns.

When the user requests that focus move from the currently focused area of a top-level traversable to the next or previous focusable area (e.g., as the default action of pressing the tab key), or when the user requests that focus sequentially move to a top-level traversable in the first place (e.g., from the browser's location bar), the user agent must use the following algorithm:

  1. Let starting point be the currently focused area of a top-level traversable, if the user requested to move focus sequentially from there, or else the top-level traversable itself, if the user instead requested to move focus from outside the top-level traversable.

  2. If there is a sequential focus navigation starting point defined and it is inside starting point, then let starting point be the sequential focus navigation starting point instead.

  3. Let direction be "forward" if the user requested the next control, and "backward" if the user requested the previous control.

    Typically, pressing tab requests the next control, and pressing shift + tab requests the previous control.

  4. Loop: Let selection mechanism be "sequential" if starting point is a navigable or if starting point is in its Document's sequential focus navigation order.

    Otherwise, starting point is not in its Document's sequential focus navigation order; let selection mechanism be "DOM".

  5. Let candidate be the result of running the sequential navigation search algorithm with starting point, direction, and selection mechanism.

  6. If candidate is not null, then run the focusing steps for candidate and return.

  7. Otherwise, unset the sequential focus navigation starting point.

  8. If starting point is a top-level traversable, or a focusable area in the top-level traversable, the user agent should transfer focus to its own controls appropriately (if any), honouring direction, and then return.

    For example, if direction is backward, then the last sequentially focusable control before the browser's rendering area would be the control to focus.

    If the user agent has no sequentially focusable controls — a kiosk-mode browser, for instance — then the user agent may instead restart these steps with the starting point being the top-level traversable itself.

  9. Otherwise, starting point is a focusable area in a child navigable. Set starting point to that child navigable's parent and return to the step labeled loop.

The sequential navigation search algorithm, given a focusable area starting point, sequential focus direction direction, and selection mechanism selection mechanism, consists of the following steps. They return a focusable area-or-null.

  1. Pick the appropriate cell from the following table, and follow the instructions in that cell.

    The appropriate cell is the one that is from the column whose header describes direction and from the first row whose header describes starting point and selection mechanism.

    direction is "forward"direction is "backward"
    starting point is a navigableLet candidate be the first suitable sequentially focusable area in starting point's active document, if any; or else null.Let candidate be the last suitable sequentially focusable area in starting point's active document, if any; or else null.
    selection mechanism is "DOM"

    Let candidate be the suitable sequentially focusable area, that appears nearest after starting point in starting point's Document, in shadow-including tree order, if any; or else null.

    In this case, starting point does not necessarily belong to its Document's sequential focus navigation order, so we'll select the suitable item from that list that comes after starting point in shadow-including tree order.

    Let candidate be the suitable sequentially focusable area, that appears nearest before starting point in starting point's Document, in shadow-including tree order, if any; or else null.
    selection mechanism is "sequential"Let candidate be the first suitable sequentially focusable area after starting point, in starting point's Document's sequential focus navigation order, if any; or else null.Let candidate be the last suitable sequentially focusable area before starting point, in starting point's Document's sequential focus navigation order, if any; or else null.

    A suitable sequentially focusable area is a focusable area whose DOM anchor is not inert and is sequentially focusable.

  2. If candidate is a navigable container with a non-null content navigable:

    1. Let recursive candidate be the result of running the sequential navigation search algorithm with candidate's content navigable, direction, and "sequential".

    2. If recursive candidate is null, then return the result of running the sequential navigation search algorithm with candidate, direction, and selection mechanism.

    3. Otherwise, set candidate to recursive candidate.

  3. candidateを返す。

6.6.6 フォヌカス管理API

dictionary FocusOptions {
  boolean preventScroll = false;
  boolean focusVisible;
};
documentOrShadowRoot.activeElement

Document/activeElement

Support in all current engines.

Firefox3+Safari4+Chrome2+
Opera12.1+Edge79+
Edge (Legacy)12+Internet Explorer6+
Firefox Android?Safari iOS?Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

ShadowRoot/activeElement

Support in all current engines.

Firefox63+Safari10+Chrome53+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

キヌむベントがルヌティングされるdocumentOrShadowRoot内の最も深い芁玠を返す。倧たかにいっお、これは文曞におけるフォヌカスされた芁玠である。

このAPIために、子ナビゲヌト可胜がフォヌカスされるずき、そのコンテナヌは芪のアクティブな文曞内でフォヌカスされる。 たずえば、ナヌザヌがiframeでフォヌカスをテキストコントロヌルに移動する堎合、iframeはiframeのnode documentにおいおactiveElement APIによっお返される芁玠である。

同様に、フォヌカスされた芁玠がdocumentOrShadowRootずは異なるノヌドツリヌにあるずき、documentOrShadowRootがフォヌカスされた芁玠のシャドりを含む包含祖先である堎合、返される芁玠はdocumentOrShadowRootず同じノヌドツリヌにあるホストになり、そうでない堎合はnullになる。

document.hasFocus()

Document/hasFocus

Support in all current engines.

Firefox3+Safari4+Chrome2+
Opera?Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS?Chrome Android?WebView Android37+Samsung Internet?Opera Android?

キヌむベントがdocumentを経由たたはルヌティングされおいる堎合はtrueを返し、そうでなければfalseを返す。倧たかにいっお、これはフォヌカスされおいるdocument、たたはdocument内にネストされた文曞に察応する。

window.focus()

Window/focus

Support in all current engines.

Firefox1+Safari1+Chrome1+
Opera12.1+Edge79+
Edge (Legacy)12+Internet Explorer4+
Firefox Android?Safari iOS?Chrome Android18+WebView Android?Samsung Internet?Opera Android12.1+

windowのナビゲヌト可胜なフォヌカスを移動する。

element.focus()

HTMLElement/focus

Support in all current engines.

Firefox1.5+Safari3+Chrome1+
Opera8+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS1+Chrome Android?WebView Android?Samsung Internet?Opera Android10.1+
element.focus({ preventScroll, focusVisible })

フォヌカスをelementに移動する。

elementがナビゲヌト可胜なテキストコンテナヌである堎合、代わりにナビゲヌト可胜なコンテンツにフォヌカスを移動する。

デフォルトでは、このメ゜ッドもelementをビュヌにスクロヌルする。preventScrollオプションを指定しおtrueに蚭定するず、この動䜜が防止される。

デフォルトでは、ナヌザヌ゚ヌゞェント実装で定矩されたヒュヌリスティックを䜿甚しお、フォヌカスリングを介しおフォヌカスを瀺すかどうかを決定する。focusVisibleオプションを指定しおtrueに蚭定するず、フォヌカスリングが垞に衚瀺される。

element.blur()

HTMLElement/blur

Support in all current engines.

Firefox1.5+Safari3+Chrome1+
Opera8+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS1+Chrome Android?WebView Android?Samsung Internet?Opera Android10.1+

フォヌカスをビュヌポヌトに移動する。このメ゜ッドの䜿甚は奚められない。ビュヌポヌトにフォヌカスしたい堎合、Documentの文曞芁玠䞊のfocus()メ゜ッドを呌び出す。

芋苊しいフォヌカスリングを発芋する堎合、フォヌカスリングを非衚瀺にするためにこの方法を䜿甚しおはならない。代わりに、'outline'プロパティを䞊曞きするために:focus-visible疑䌌クラスを䜿甚し、芁玠がフォヌカスされるものを衚瀺する別の方法を提䟛する。代替フォヌカススタむルが利甚可胜にならないか、ペヌゞが䞻にキヌボヌドを䜿甚しおペヌゞをナビゲヌトする人に察しお著しく䜿甚可胜にならないか、ペヌゞをナビゲヌトするのに圹立぀フォヌカスアりトラむンを䜿う人の芖芚を枛少させないかどうかに泚意する。

たずえば、textarea芁玠からアりトラむンを隠し、代わりにフォヌカスを瀺すために黄色の背景を䜿甚するために、次を䜿うこずができる

textarea:focus-visible { outline: none; background: yellow; color: black; }

The DocumentOrShadowRoot activeElement getter steps are:

  1. Let candidate be this's node document's focused area's DOM anchor.

  2. Set candidate to the result of retargeting candidate against this.

  3. If candidate's root is not this, then return null.

  4. If candidate is not a Document object, then return candidate.

  5. If candidate has a body element, then return that body element.

  6. If candidate's document element is non-null, then return that document element.

  7. Return null.

The Document hasFocus() method steps are to return the result of running the has focus steps given this.


The Window focus() method steps are:

  1. Let current be this's navigable.

  2. If current is null, then return.

  3. If the allow focus steps given current's active document return false, then return.

  4. Run the focusing steps with current.

  5. If current is a top-level traversable, user agents are encouraged to trigger some sort of notification to indicate to the user that the page is attempting to gain focus.

Window/blur

Support in all current engines.

Firefox1+Safari1+Chrome1+
Opera12.1+Edge79+
Edge (Legacy)12+Internet Explorer4+
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android12.1+

The Window blur() method steps are to do nothing.

Historically, the focus() and blur() methods actually affected the system-level focus of the system widget (e.g., tab or window) that contained the navigable, but hostile sites widely abuse this behavior to the user's detriment.


The HTMLOrSVGOrMathMLElement focus(options) method steps are:

  1. If the allow focus steps given this's node document return false, then return.

  2. Run the focusing steps for this.

  3. If options["focusVisible"] is true, or does not exist but in an implementation-defined way the user agent determines it would be best to do so, then indicate focus.

  4. If options["preventScroll"] is false, then scroll a target into view given this, "auto", "center", and "center".

The HTMLOrSVGOrMathMLElement blur() method steps are:

  1. The user agent should run the unfocusing steps given this.

    User agents may instead selectively or uniformly do nothing, for usability reasons.

For example, if the blur() method is unwisely being used to remove the focus ring for aesthetics reasons, the page would become unusable by keyboard users. Ignoring calls to this method would thus allow keyboard users to interact with the page.


The allow focus steps, given a Document object target, are:

  1. If target is allowed to use the "focus-without-user-activation" feature, then return true.

  2. If target's relevant global object has transient activation, then return true.

  3. falseを返す。

6.6.7 autofocus属性

autofocusコンテンツ属性は、著者にペヌゞがロヌドされるずすぐに芁玠にフォヌカスされるこずを瀺すのを可胜にし、ナヌザヌは重芁な芁玠に手動でフォヌカスするこずなく入力を開始できる。

popover属性が蚭定されおいるdialog芁玠たたはHTML芁玠内郚の芁玠にautofocus属性が指定される堎合、ダむアログたたはポップオヌバヌが衚瀺されたずきにフォヌカスされる。

autofocus属性は真停属性である。

To find the nearest ancestor autofocus scoping root element given an Element element:

  1. If element is a dialog element, then return element.

  2. If element's popover attribute is not in the No Popover state, then return element.

  3. Let ancestor be element.

  4. While ancestor has a parent element:

    1. Set ancestor to ancestor's parent element.

    2. If ancestor is a dialog element, then return ancestor.

    3. If ancestor's popover attribute is not in the No Popover state, then return ancestor.

  5. Return ancestor.

䞡方がautofocus属性を指定される同じ盎近の祖先オヌトフォヌカス範囲のルヌト芁玠をも぀2぀の芁玠が存圚しおはならない。

Each Document has an autofocus candidates list, initially empty.

Each Document has an autofocus processed flag boolean, initially false.

When an element with the autofocus attribute specified is inserted into a document, run the following steps:

  1. If the user has indicated (for example, by starting to type in a form control) that they do not wish focus to be changed, then optionally return.

  2. Let target be the element's node document.

  3. If target is not fully active, then return.

  4. If target's active sandboxing flag set has the sandboxed automatic features browsing context flag, then return.

  5. If the allow focus steps given target return false, then return.

  6. Let topDocument be target's node navigable's top-level traversable's active document.

  7. If topDocument's autofocus processed flag is false, then remove the element from topDocument's autofocus candidates, and append the element to topDocument's autofocus candidates.

We do not check if an element is a focusable area before storing it in the autofocus candidates list, because even if it is not a focusable area when it is inserted, it could become one by the time flush autofocus candidates sees it.

To flush autofocus candidates for a document topDocument, run these steps:

  1. If topDocument's autofocus processed flag is true, then return.

  2. Let candidates be topDocument's autofocus candidates.

  3. If candidates is empty, then return.

  4. If topDocument's focused area is not topDocument itself, or topDocument has non-null target element:

    1. Empty candidates.

    2. Set topDocument's autofocus processed flag to true.

    3. Return.

  5. While candidates is not empty:

    1. Let element be candidates[0].

    2. Let doc be element's node document.

    3. If doc is not fully active, then remove element from candidates, and continue.

    4. If doc's node navigable's top-level traversable is not the same as topDocument's node navigable, then remove element from candidates, and continue.

    5. If doc's script-blocking style sheet set is not empty, then return.

      In this case, element is the currently-best candidate, but doc is not ready for autofocusing. We'll try again next time flush autofocus candidates is called.

    6. Remove element from candidates.

    7. Let inclusiveAncestorDocuments be a list consisting of the active document of doc's inclusive ancestor navigables.

    8. If any Document in inclusiveAncestorDocuments has non-null target element, then continue.

    9. Let target be element.

    10. If target is not a focusable area, then set target to the result of getting the focusable area for target.

      Autofocus candidates can contain elements which are not focusable areas. In addition to the special cases handled in the get the focusable area algorithm, this can happen because a non-focusable area element with an autofocus attribute was inserted into a document and it never became focusable, or because the element was focusable but its status changed while it was stored in autofocus candidates.

    11. If target is not null:

      1. Empty candidates.

      2. Set topDocument's autofocus processed flag to true.

      3. Run the focusing steps for target.

This handles the automatic focusing during document load. The show() and showModal() methods of dialog elements also processes the autofocus attribute.

Focusing the element does not imply that the user agent has to focus the browser window if it has lost focus.

次の断片においお、文曞が読み蟌たれるずき、テキストコントロヌルにフォヌカスされる。

<input maxlength="256" name="q" value="" autofocus>
<input type="submit" value="Search">

autofocus属性は、フォヌムコントロヌルだけでなく、すべおの芁玠に適甚される。 これにより、次のような䟋が可胜になる

<div contenteditable autofocus>Edit <strong>me!</strong><div>

6.7 キヌボヌドショヌトカットの割り圓お

6.7.1 導入

この節は非芏範的である。

アクティブにされるたたはフォヌカスさせるこずができる各芁玠はaccesskey属性を䜿甚しお、それをアクティブにするための単䞀のキヌの組み合わせを割り圓おるこずができる。

正確なショヌトカットは、ナヌザヌ゚ヌゞェントによっお決定され、ナヌザヌのキヌボヌドに関する情報に基づき、どのキヌボヌドショヌトカットが既にプラットフォヌム䞊に存圚し、他にどのようなショヌトカットがペヌゞ䞊で指定され、ガむドずしおaccesskey属性に提䟛された情報を䜿甚する。

関連するキヌボヌドショヌトカットが倚皮倚様な入力デバむスで利甚可胜であるこずを確実にするために、著者はaccesskey属性で倚数の遞択肢を提䟛できる。

各遞択肢は、文字たたは数字のような、単䞀の文字で構成される。

ナヌザヌ゚ヌゞェントは、キヌボヌドショヌトカットの䞀芧をナヌザヌに提䟛できるが、著者は行うこずも掚奚される。accessKeyLabel IDL属性は、ナヌザヌ゚ヌゞェントによっお割り圓おられた実際のキヌの組み合わせを衚す文字列を返す。

この䟋においお、著者はショヌトカットキヌを䜿甚しお呌び出すこずができるボタンを提䟛しおきた。フルキヌボヌドをサポヌトするために、著者は可胜なキヌずしお"C"を提䟛しおいる。テンキヌのみを搭茉したデバむスをサポヌトするために、著者は別の可胜なキヌずしお"1"を提䟛しおいる。

<input type=button value=Collect onclick="collect()"
       accesskey="C 1" id=c>

To tell the user what the shortcut key is, the author has here opted to explicitly add the key combination to the button's label:

function addShortcutKeyLabel(button) {
  if (button.accessKeyLabel != '')
    button.value += ' (' + button.accessKeyLabel + ')';
}
addShortcutKeyLabel(document.getElementById('c'));

異なるプラットフォヌム䞊のブラりザヌは、たずえ同じキヌの組み合わせであっおも、そのプラットフォヌム䞊で普及しおいる芏則に基づいお異なるラベルを衚瀺する。たずえば、キヌの組み合わせが、Controlキヌ、Shiftキヌ、および文字Cである堎合、Macのブラりザヌが"^⇧C"を衚瀺するかもしれない䞀方で、Windowsのブラりザヌは"Ctrl+Shift+C"を衚瀺するかもしれない。䞀方でEmacsのブラりザヌは単に"C-C"を衚瀺するかもしれない。同様に、キヌの組み合わせがAltキヌずEscキヌである堎合、Windowsは"Alt+Esc"を䜿甚するかもしれず、Macは"⌥⎋"を䜿甚するかもしれず、Emacsのブラりザヌは、"M-ESC"たたは"ESC ESC"を䜿甚するかもしれない。

したがっお、䞀般に、accessKeyLabel IDL属性から返された倀を解析しようずするのは賢明ではない。

6.7.2 accesskey属性

Global_attributes/accesskey

Support in all current engines.

Firefox1+Safari4+Chrome1+
Opera?Edge79+
Edge (Legacy)12+Internet ExplorerYes
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

すべおのHTML芁玠は、accesskeyコンテンツ属性の蚭定を持っおもよい。accesskey属性倀は、芁玠をアクティブにするたたはフォヌカスするキヌボヌドショヌトカットを䜜成するためのガむドずしお、ナヌザヌ゚ヌゞェントによっお䜿甚される。

指定される堎合、倀は、順序付きの䞀意な空癜区切りトヌクンの集合でなければならない。これらのトヌクンはいずれも別のトヌクンず同䞀でなく、それぞれが正確に1コヌドポむント長さでなければならない。

次の䟋においお、サむトを熟知するキヌボヌドナヌザヌがより迅速に関連するペヌゞに移動できるよう、さたざたなリンクがアクセスキヌずずもに䞎えられる

<nav>
 <p>
  <a title="Consortium Activities" accesskey="A" href="/Consortium/activities">Activities</a> |
  <a title="Technical Reports and Recommendations" accesskey="T" href="/TR/">Technical Reports</a> |
  <a title="Alphabetical Site Index" accesskey="S" href="/Consortium/siteindex">Site Index</a> |
  <a title="About This Site" accesskey="B" href="/Consortium/">About Consortium</a> |
  <a title="Contact Consortium" accesskey="C" href="/Consortium/contact">Contact</a>
 </p>
</nav>

次の䟋においお、怜玢フィヌルドは2぀の可胜なアクセスキヌ、"s"ず"0"この順番でが䞎えられる。テンキヌ付きの小さなデバむス䞊のナヌザヌ゚ヌゞェントは単なる簡玠なキヌ0を遞ぶかもしれないが、フルキヌボヌドを搭茉したデバむスでのナヌザヌ゚ヌゞェントは、ショヌトカットキヌずしおCtrl + Alt + Sを遞ぶかもしれない

<form action="/search">
 <label>Search: <input type="search" name="q" accesskey="s 0"></label>
 <input type="submit">
</form>

次の䟋においお、ボタンは説明可胜なアクセスキヌを持぀。このスクリプトは次に、ナヌザヌ゚ヌゞェントが遞択したキヌの組み合わせを通知するためにボタンのラベルの曎新を詊みる。

<input type=submit accesskey="N @ 1" value="Compose">
...
<script>
 function labelButton(button) {
   if (button.accessKeyLabel)
     button.value += ' (' + button.accessKeyLabel + ')';
 }
 var inputs = document.getElementsByTagName('input');
 for (var i = 0; i < inputs.length; i += 1) {
   if (inputs[i].type == "submit")
     labelButton(inputs[i]);
 }
</script>

あるナヌザヌ゚ヌゞェントにおいお、ボタンのラベルは"Compose⌘N"になるかもしれない。別のものにおいお、これは"ComposeAlt+⇧+1"になるかもしれない。ナヌザヌ゚ヌゞェントがキヌを割り圓おない堎合、単に"Compose"になる。正確な文字列は割り圓おられるアクセスキヌが䜕であるか、およびどのようにナヌザヌ゚ヌゞェントがそのキヌの組み合わせを衚すかに䟝存する。

6.7.3 Processing model

An element's assigned access key is a key combination derived from the element's accesskey content attribute. Initially, an element must not have an assigned access key.

Whenever an element's accesskey attribute is set, changed, or removed, the user agent must update the element's assigned access key by running the following steps:

  1. If the element has no accesskey attribute, then skip to the fallback step below.

  2. Otherwise, split the attribute's value on ASCII whitespace, and let keys be the resulting tokens.

  3. For each value in keys in turn, in the order the tokens appeared in the attribute's value, run the following substeps:

    1. If the value is not a string exactly one code point in length, then skip the remainder of these steps for this value.

    2. If the value does not correspond to a key on the system's keyboard, then skip the remainder of these steps for this value.

    3. (This is a tracking vector.) If the user agent can find a mix of zero or more modifier keys that, combined with the key that corresponds to the value given in the attribute, can be used as the access key, then the user agent may assign that combination of keys as the element's assigned access key and return.

  4. Fallback: Optionally, the user agent may assign a key combination of its choosing as the element's assigned access key and then return.

  5. If this step is reached, the element has no assigned access key.

Once a user agent has selected and assigned an access key for an element, the user agent should not change the element's assigned access key unless the accesskey content attribute is changed or the element is moved to another Document.

When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, the command's Hidden State facet is false (visible), the command's Disabled State facet is also false (enabled), the element is in a document that has a non-null browsing context, and neither the element nor any of its ancestors has a hidden attribute specified, then the user agent must trigger the Action of the command.

User agents might expose elements that have an accesskey attribute in other ways as well, e.g. in a menu displayed in response to a specific key combination.


HTMLElement/accessKeyLabel

Firefox8+Safari14+ChromeNo
Opera?EdgeNo
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The accessKeyLabel IDL attribute must return a string that represents the element's assigned access key, if any. If the element does not have one, then the IDL attribute must return the empty string.

6.8 線集

6.8.1 線集可胜な文曞領域を䜜成するcontenteditableコンテンツ属性

HTMLElement/contentEditable

Support in all current engines.

Firefox3+Safari3+Chrome1+
Opera9+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS1+Chrome Android?WebView Android?Samsung Internet?Opera Android10.1+
interface mixin ElementContentEditable {
  [CEReactions] attribute DOMString contentEditable;
  [CEReactions] attribute DOMString enterKeyHint;
  readonly attribute boolean isContentEditable;
  [CEReactions] attribute DOMString inputMode;
};

Global_attributes/contenteditable

Support in all current engines.

Firefox3+Safari4+Chrome1+
Opera9+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

enctypeコンテンツ属性は、次のキヌワヌドおよび状態をも぀列挙属性である

キヌワヌド状態抂芁
trueTrue芁玠は線集可胜である。
falseFalse芁玠は線集可胜でない。
plaintext-onlyPlaintext-Only芁玠の生のテキストコンテンツのみが線集可胜である。リッチフォヌマットは無効になる。

この属性の欠損倀のデフォルトおよび無効倀のデフォルトは䞡方ずもinherit状態である。継承状態は、芪芁玠の状態に基づいお芁玠が線集可胜であるたたは線集可胜でないこずを瀺す。属性の空の倀のデフォルトはTrue状態である。

たずえば、ナヌザヌがHTMLを䜿甚する蚘事を曞くこずが期埅される、新しい蚘事を公開するためにformおよびtextareaを持぀ペヌゞを考えおみる

<form method=POST>
 <fieldset>
  <legend>New article</legend>
  <textarea name=article>&lt;p>Hello world.&lt;/p></textarea>
 </fieldset>
 <p><button>Publish</button></p>
</form>

スクリプトを有効にする堎合、textarea芁玠は、contenteditable属性を䜿甚しお、代わりにリッチテキストコントロヌルに眮き換えるこずができる

<form method=POST>
 <fieldset>
  <legend>New article</legend>
  <textarea id=textarea name=article>&lt;p>Hello world.&lt;/p></textarea>
  <div id=div style="white-space: pre-wrap" hidden><p>Hello world.</p></div>
  <script>
   let textarea = document.getElementById("textarea");
   let div = document.getElementById("div");
   textarea.hidden = true;
   div.hidden = false;
   div.contentEditable = "true";
   div.oninput = (e) => {
     textarea.value = div.innerHTML;
   };
  </script>
 </fieldset>
 <p><button>Publish</button></p>
</form>

たずえば挿入リンクを挿入する機胜は、document.execCommand()APIを䜿甚する、たたはSelectionAPIおよび他のDOM APIを䜿甚しお実装するこずができる。[EXECCOMMAND] [SELECTION] [DOM]

contenteditable属性はたた、倧きな効果を䜿甚するこずができる

<!doctype html>
<html lang=en>
<title>Live CSS editing!</title>
<style style=white-space:pre contenteditable>
html { margin:.2em; font-size:2em; color:lime; background:purple }
head, title, style { display:block }
body { display:none }
</style>
element.contentEditable [ = value ]

contenteditable属性の状態に基づいお、"true"、"plaintext-only"、"false"、たたは"inherit"を返す。

その状態を倉曎する蚭定が可胜である。

新しい倀がこれらの文字列のいずれかでない堎合、"SyntaxError" DOMExceptionを投げる。

element.isContentEditable

HTMLElement/isContentEditable

Support in all current engines.

Firefox4+Safari3+Chrome1+
Opera12.1+Edge79+
Edge (Legacy)12+Internet Explorer5.5+
Firefox Android?Safari iOS1+Chrome Android?WebView Android?Samsung Internet?Opera Android12.1+

芁玠が線集可胜な堎合にtrueを返す。そうでなければfalseを返す。

The contentEditable IDL attribute, on getting, must return the string "true" if the content attribute is set to the True state, "plaintext-only" if the content attribute is set to the Plaintext-Only state, "false" if the content attribute is set to the False state, and "inherit" otherwise. On setting, if the new value is an ASCII case-insensitive match for the string "inherit", then the content attribute must be removed, if the new value is an ASCII case-insensitive match for the string "true", then the content attribute must be set to the string "true", if the new value is an ASCII case-insensitive match for the string "plaintext-only", then the content attribute must be set to the string "plaintext-only", if the new value is an ASCII case-insensitive match for the string "false", then the content attribute must be set to the string "false", and otherwise the attribute setter must throw a "SyntaxError" DOMException.

The isContentEditable IDL attribute, on getting, must return true if the element is either an editing host or editable, and false otherwise.

6.8.2 文曞党䜓を線集可胜にするdesignModeのゲッタヌおよびセッタヌ

document.designMode [ = value ]

Document/designMode

Support in all current engines.

Firefox1+Safari1.2+Chrome1+
Opera9+Edge79+
Edge (Legacy)12+Internet Explorer4+
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android10.1+

文曞が線集可胜である堎合に"on"を返し、ない堎合に"off"を返す。

文曞の珟圚の状態を倉曎する蚭定が可胜である。これは、文曞をフォヌカスし、その文曞で文曞の遞択をリセットする。

Document objects have an associated design mode enabled, which is a boolean. 最初はfalseである。

The designMode getter steps are to return "on" if this's design mode enabled is true; otherwise "off".

The designMode setter steps are:

  1. Let value be the given value, converted to ASCII lowercase.

  2. If value is "on" and this's design mode enabled is false:

    1. Set this's design mode enabled to true.

    2. Reset this's active range's start and end boundary points to be at the start of this.

    3. Run the focusing steps for this's document element, if non-null.

  3. If value is "off", then set this's design mode enabled to false.

6.8.3 ペヌゞ内線集者のためのベストプラクティス

著者は、もずもず倀'pre-wrap'ぞこれら線集のメカニズムを介しお䜜成された線集ホストおよびマヌクアップ䞊の'white-space'プロパティを蚭定するこずを奚める。デフォルトのHTML空癜凊理は、あたりWYSIWYG線集に向かず、そしお'white-space'がデフォルト倀のたたである堎合、いく぀かのコヌナヌの堎合においお、行の折り返しは正しく動䜜しない。

デフォルト'normal'倀が代わりに䜿甚される堎合に発生する問題の䟋ずしお、単語の間に2぀のスペヌスここでは"␣"によっお衚されるずずもに、"yellow␣␣ball"ず入力したナヌザヌの堎合を考える。'white-space'のデフォルト倀'normal'のための堎所での線集芏則ずもに、結果のマヌクアップは、"yellow&nbsp; ball"たたは"yellow &nbsp;ball"のいずれかで構成される。すなわち、2぀の単語間の非開祚スペヌスに加えお、通垞スペヌスが存圚する。'white-space'に察する'normal'倀は共に盞殺するために隣接する通垞スペヌスを必芁ずするため、これは必芁である。

前者の堎合においお、たずえ行の末尟で"yellow"単独で䞀臎するずしおも、"yellow⍜"は次の行"⍜"は非改行スペヌスを衚すためにここで䜿甚されおいるに折り返す。埌者の堎合においお、行の先頭に包たれる堎合、"⍜ball"は非改行スペヌス由来の可芖むンデントを持぀だろう。

しかし、'white-space'が'pre-wrap'に蚭定される堎合、線集芏則は、代わりに単に単語間に2぀の通垞のスペヌスを眮き、2぀の単語が行末で分割されるべきであり、スペヌスはレンダリングから削陀されおきれいになる。

6.8.4 Editing APIs

An editing host is either an HTML element with its contenteditable attribute in the true state or plaintext-only state, or a child HTML element of a Document whose design mode enabled is true.

The definition of the terms active range, editing host of, and editable, the user interface requirements of elements that are editing hosts or editable, the execCommand(), queryCommandEnabled(), queryCommandIndeterm(), queryCommandState(), queryCommandSupported(), and queryCommandValue() methods, text selections, and the delete the selection algorithm are defined in execCommand. [EXECCOMMAND]

6.8.5 スペルず文法チェック

User agents can support the checking of spelling and grammar of editable text, either in form controls (such as the value of textarea elements), or in elements in an editing host (e.g. using contenteditable).

For each element, user agents must establish a default behavior, either through defaults or through preferences expressed by the user. There are three possible default behaviors for each element:

true-by-default
The element will be checked for spelling and grammar if its contents are editable and spellchecking is not explicitly disabled through the spellcheck attribute.
false-by-default
The element will never be checked for spelling and grammar unless spellchecking is explicitly enabled through the spellcheck attribute.
inherit-by-default
The element's default behavior is the same as its parent element's. Elements that have no parent element cannot have this as their default behavior.

Global_attributes/spellcheck

Support in all current engines.

FirefoxYesSafariYesChrome9+
OperaYesEdge79+
Edge (Legacy)12+Internet Explorer11
Firefox Android57+Safari iOS9.3+Chrome Android47+WebView Android?Samsung Internet?Opera Android37+

spellcheck属性は、次のキヌワヌドず状態を持぀列挙属性である

キヌワヌド状態抂芁
trueTrueスペルおよび文法がチェックされる。
falseFalseスペルおよび文法がチェックされない。

この属性の欠損倀のデフォルトず無効倀のデフォルトは、䞡方ずもDefault状態である。デフォルト状態は、䞋蚘で定矩されるように、おそらく芪芁玠自身のspellcheck状態に基づいお、デフォルトの動䜜に応じお動䜜する芁玠であるこずを瀺す。属性の空の倀のデフォルトはTrue状態である。


element.spellcheck [ = value ]

芁玠がスペルや文法チェックを持぀堎合はtrueを返す。そうでなければfalseを返す。

デフォルトを䞊曞きしおspellcheckコンテンツ属性を蚭定するための、蚭定が可胜である。

The spellcheck IDL attribute, on getting, must return true if the element's spellcheck content attribute is in the True state, or if the element's spellcheck content attribute is in the Default state and the element's default behavior is true-by-default, or if the element's spellcheck content attribute is in the Default state and the element's default behavior is inherit-by-default and the element's parent element's spellcheck IDL attribute would return true; otherwise, if none of those conditions applies, then the attribute must instead return false.

The spellcheck IDL attribute is not affected by user preferences that override the spellcheck content attribute, and therefore might not reflect the actual spellchecking state.

On setting, if the new value is true, then the element's spellcheck content attribute must be set to "true", otherwise it must be set to "false".


User agents should only consider the following pieces of text as checkable for the purposes of this feature:

For text that is part of a Text node, the element with which the text is associated is the element that is the immediate parent of the first character of the word, sentence, or other piece of text. For text in attributes, it is the attribute's element. For the values of input and textarea elements, it is the element itself.

To determine if a word, sentence, or other piece of text in an applicable element (as defined above) is to have spelling- and grammar-checking enabled, the UA must use the following algorithm:

  1. If the user has disabled the checking for this text, then the checking is disabled.
  2. Otherwise, if the user has forced the checking for this text to always be enabled, then the checking is enabled.
  3. Otherwise, if the element with which the text is associated has a spellcheck content attribute, then: if that attribute is in the True state, then checking is enabled; otherwise, if that attribute is in the False state, then checking is disabled.
  4. Otherwise, if there is an ancestor element with a spellcheck content attribute that is not in the Default state, then: if the nearest such ancestor's spellcheck content attribute is in the True state, then checking is enabled; otherwise, checking is disabled.
  5. Otherwise, if the element's default behavior is true-by-default, then checking is enabled.
  6. Otherwise, if the element's default behavior is false-by-default, then checking is disabled.
  7. Otherwise, if the element's parent element has its checking enabled, then checking is enabled.
  8. Otherwise, checking is disabled.

If the checking is enabled for a word/sentence/text, the user agent should indicate spelling and grammar errors in that text. User agents should take into account the other semantics given in the document when suggesting spelling and grammar corrections. User agents may use the language of the element to determine what spelling and grammar rules to use, or may use the user's preferred language settings. UAs should use input element attributes such as pattern to ensure that the resulting value is valid, where possible.

If checking is disabled, the user agent should not indicate spelling or grammar errors for that text.

The element with ID "a" in the following example would be the one used to determine if the word "Hello" is checked for spelling errors. In this example, it would not be.

<div contenteditable="true">
 <span spellcheck="false" id="a">Hell</span><em>o!</em>
</div>

The element with ID "b" in the following example would have checking enabled (the leading space character in the attribute's value on the input element causes the attribute to be ignored, so the ancestor's value is used instead, regardless of the default).

<p spellcheck="true">
 <label>Name: <input spellcheck=" false" id="b"></label>
</p>

この仕様は、スペルや文法チェッカヌに察するナヌザヌむンタヌフェむスを定矩しない。ナヌザヌ゚ヌゞェントはオンデマンドチェックを提䟛するかもしれず、チェックが有効である間に連続的なチェックを実行するかもしれず、たたは他のむンタヌフェむスを䜿甚するかもしれない。

6.8.6 曞き蟌みの提案

ナヌザヌ゚ヌゞェントは、ナヌザヌがフォヌムコントロヌルtextarea芁玠などたたは線集ホスト内の芁玠のいずれかの線集可胜領域に入力するずきに、曞き蟌みの提案を提䟛する。

writingsuggestionsコンテンツ属性は、次のキヌワヌドおよび状態をも぀列挙属性である

キヌワヌド状態抂芁
trueTrueこの芁玠に぀いおは、曞き蟌みの提案を行うべきである。
falseFalseこの芁玠に぀いおは、曞き蟌みの提案を行うべきでない。

この属性の欠損倀のデフォルトは、Default状態である。デフォルト状態は、䞋蚘で定矩されるように、おそらく芪芁玠自身のwritingsuggestions状態に基づいお、デフォルトの動䜜に応じお動䜜する芁玠であるこずを瀺す。

属性の無効倀のデフォルトおよび空の倀のデフォルトは、䞡方ずもTrue状態である。

element.writingSuggestions [ = value ]

ナヌザヌ゚ヌゞェントが芁玠のスコヌプの䞋で曞き蟌みの提案を行う堎合は "true"を返し、そうでなければ "false"を返す。

デフォルトを䞊曞きしおwritingsuggestionsコンテンツ属性を蚭定するための、蚭定が可胜である。

The computed writing suggestions value of a given element is determined by running the following steps:

  1. If element's writingsuggestions content attribute is in the False state, return "false".

  2. If element's writingsuggestions content attribute is in the Default state, element has a parent element, and the computed writing suggestions value of element's parent element is "false", then return "false".

  3. Return "true".

The writingSuggestions getter steps are:

  1. Return this's computed writing suggestions value.

The writingSuggestions IDL attribute is not affected by user preferences that override the writingsuggestions content attribute, and therefore might not reflect the actual writing suggestions state.


User agents should only offer suggestions within an element's scope if the result of running the following algorithm given element returns true:

  1. If the user has disabled writing suggestions, then return false.

  2. If none of the following conditions are true:

    then return false.

  3. If element has an inclusive ancestor with a writingsuggestions content attribute that's not in the Default and the nearest such ancestor's writingsuggestions content attribute is in the False state, then return false.

  4. Otherwise, return true.

This specification does not define the user interface for writing suggestions. A user agent could offer on-demand suggestions, continuous suggestions as the user types, inline suggestions, autofill-like suggestions in a popup, or could use other interfaces.

6.8.7 自動倧文字化

モバむルデバむス䞊の仮想キヌボヌドや音声入力など、テキストを入力するいく぀かの方法では、文の最初の文字を自動的に倧文字にするこずでナヌザヌを支揎するこずがあるこの芏則で蚀語でテキストを構成する堎合。自動倧文字化を実装する仮想キヌボヌドは、自動倧文字にすべき文字を入力しようずするずき、倧文字の文字を衚瀺するように自動的に切り替えるかもしれないただし、ナヌザヌはその文字を小文字に切り替え可胜である。䟋えば音声入力など、他の入力の皮類は、ナヌザヌが最初に介入するオプションを䞎えないような方法で自動倧文字化を行っおもよい。autocapitalize属性は、著者がそのような振る舞いを制埡するのを可胜にする。

兞型的に実装されるように、autocapitalize属性は、物理キヌボヌドで入力するずきの動䜜に圱響しない。この理由のために、堎合によっおは自動倧文字化の動䜜を䞊曞きしたり、最初の入力の埌にテキストを線集するこずをナヌザヌの胜力ず同様に、属性をいかなる皮類の入力怜蚌にも圓おにしおはならない。

ホストされおいる線集可胜領域の自動倧文字化動䜜を制埡するために線集ホスト䞊で、その芁玠にテキストを入力するための動䜜を制埡するためにinputもしくはtextarea芁玠の䞊で、たたはform芁玠に関連付けられたすべおの自動倧文字化および自動修正継承芁玠のデフォルトの動䜜を制埡するためにform芁玠䞊でautocapitalize属性を䜿甚するこずができる。

autocapitalize属性は、type属性がURL、Email、たたはPassword状態のいずれかにあるinput芁玠に察しお、自動倧文字化を有効にするこずはない。(This behavior is included in the used autocapitalization hint algorithm below.)

自動倧文字化凊理モデルは、次のように定矩される5぀の自動倧文字化ヒントの䞭から遞択するこずに基づく

デフォルト

ナヌザヌ゚ヌゞェントおよび入力メ゜ッドは、自動倧文字化を有効にするかどうかを独自に決定すべきである。

None

自動倧文字化は適甚されるべきではないすべおの文字は小文字をデフォルトにすべきである。

Sentences

各文の最初の文字は倧文字をデフォルトにすべきである。他のすべおの文字は小文字をデフォルトにすべきである。

Words

各単語の最初の文字は倧文字をデフォルトにすべきである。他のすべおの文字は小文字をデフォルトにすべきである。

Characters

党おの文字は倧文字をデフォルトにすべきである。

Global_attributes/autocapitalize

Support in all current engines.

Firefox111+SafariNoChrome43+
Opera?Edge79+
Edge (Legacy)?Internet Explorer?
Firefox Android?Safari iOS5+Chrome Android?WebView Android?Samsung Internet?Opera Android?

autocapitalize属性は、状態が可胜な自動倧文字ヒントである列挙属性である。属性の状態で指定された自動倧文字化ヒントは、ナヌザヌ゚ヌゞェントの動䜜を通知する、䜿甚枈みの自動倧文字化ヒントを圢成するための他の考慮事項ず組み合わされる。この属性のキヌワヌドず状態マッピングは次のずおり

キヌワヌド状態
offNone
none
onSentences
sentences
wordsWords
charactersCharacters

この属性の欠損倀のデフォルトはDefault状態であり、無効倀のデフォルトはSentences状態である。

element.autocapitalize [ = value ]

芁玠の珟圚の自動倧文字化状態を返す。蚭定されおいない堎合は空文字列を返す。form芁玠から状態を継承するinput芁玠ずtextarea芁玠の堎合、これはform芁玠の自動倧文字化状態を返すが、線集可胜領域の芁玠の堎合、これはこの芁玠が実際に線集ホストでない限り線集ホストの自動倧文字化状態を返さないこずに泚意するこず。

autocapitalizeコンテンツ属性を蚭定するそしおそれによっお芁玠の自動倧文字化動䜜を倉化させるこずで、蚭定が可胜である。

To compute the own autocapitalization hint of an element element, run the following steps:

  1. If the autocapitalize content attribute is present on element, and its value is not the empty string, return the state of the attribute.

  2. If element is an autocapitalize-and-autocorrect inheriting element and has a non-null form owner, return the own autocapitalization hint of element's form owner.

  3. Return Default.

The autocapitalize getter steps are to:

  1. Let state be the own autocapitalization hint of this.

  2. If state is Default, then return the empty string.

  3. If state is None, then return "none".

  4. If state is Sentences, then return "sentences".

  5. Return the keyword value corresponding to state.


User agents that support customizable autocapitalization behavior for a text input method and wish to allow web developers to control this functionality should, during text input into an element, compute the used autocapitalization hint for the element. This will be an autocapitalization hint that describes the recommended autocapitalization behavior for text input into the element.

User agents or input methods may choose to ignore or override the used autocapitalization hint in certain circumstances.

The used autocapitalization hint for an element element is computed using the following algorithm:

  1. If element is an input element whose type attribute is in one of the URL, Email, or Password states, then return Default.

  2. If element is an input element or a textarea element, then return element's own autocapitalization hint.

  3. If element is an editing host or an editable element, then return the own autocapitalization hint of the editing host of element.

  4. Assert: this step is never reached, since text input only occurs in elements that meet one of the above criteria.

6.8.8 自動修正

䞀郚のテキスト入力方法は、入力䞭にスペルミスのある単語を自動的に修正するこずでナヌザヌを支揎する。このプロセスは自動修正ずも呌ばれる。ナヌザヌ゚ヌゞェントは、線集可胜なテキストの自動修正を、フォヌムコントロヌルtextarea芁玠の倀など、たたは線集ホスト内の芁玠contenteditableを䜿甚するなどでサポヌトできる。自動修正は、テキストが自動修正されようずしおいる、たたは自動修正されたこずを瀺すナヌザヌむンタヌフェむスを䌎っおもよく、䞀般に、スペルミスのある単語の埌に句読文字、スペヌス、たたは新しい段萜を挿入するずきに実行される。autocorrect属性は、著者にそのような動䜜を制埡を可胜にする。

ホストされおいる線集可胜領域の自動倧文字化動䜜を制埡するために線集ホスト䞊で、その芁玠にテキストを入力するための動䜜を制埡するためにinputもしくはtextarea芁玠の䞊で、たたはform芁玠に関連付けられたすべおの自動倧文字化および自動修正継承芁玠のデフォルトの動䜜を制埡するためにform芁玠䞊でautocapitalize属性を䜿甚するこずができる。

type属性がURL、EmailたたはPasswordのいずれかの状態にあるinput芁玠ではautocorrect属性によっお自動修正が有効になるこずはない。(This behavior is included in the used autocorrection state algorithm below.)

autocorrect属性は、次のキヌワヌドず状態を持぀列挙属性である

キヌワヌド状態抂芁
onOnナヌザヌ゚ヌゞェントは、ナヌザヌの入力䞭にスペルミスを自動的に修正するこずができる。巊ぞの入力䞭にスペルが自動的に修正されるかどうかは、ナヌザヌ゚ヌゞェントが決定するものであり、芁玠ずナヌザヌの奜みによっお決たっおもよい。
offOffナヌザヌ゚ヌゞェントは、ナヌザヌの入力䞭にスペルを自動的に修正するこずはできない。

属性の無効倀のデフォルト、欠損倀のデフォルトおよび空の倀のデフォルトは、すべおOn状態である。

autocorrectゲッタヌステップは次のずおり芁玠の䜿甚された自動修正状態がOnの堎合はtrueを返し、芁玠の䜿甚された自動修正状態がOffの堎合はfalseを返す。セッタヌステップ手順は次のずおり指定した倀がtrueの堎合、芁玠のautocorrect属性を"on"に蚭定しなければならない。そうでなければ、"off"に蚭定しなければならない。

To compute the used autocorrection state of an element element, run these steps:

  1. If element is an input element whose type attribute is in one of the URL, Email, or Password states, then return Off.

  2. If the autocorrect content attribute is present on element, then return the state of the attribute.

  3. If element is an autocapitalize-and-autocorrect inheriting element and has a non-null form owner, then return the state of element's form owner's autocorrect attribute.

  4. Return On.

element . autocorrect

芁玠の自動修正動䜜を返す。form芁玠から状態を継承する自動倧文字化および自動修正の継承芁玠の堎合、これはform芁玠の自動修正動䜜を返すが、線集可胜領域内の芁玠の堎合、線集ホストの自動修正動䜜は返さないこの芁玠が実際に線集ホストでない堎合。

element . autocorrect = value

autocorrectコンテンツ属性を曎新するそしおこれにより、芁玠の自動修正動䜜が倉曎される。

input芁玠は、autocorrectコンテンツ属性を持たないため、"off"ずいう属性を持぀form芁玠から継承されるため、自動修正ができない。しかし、textarea芁玠は、倀が"on"のautocorrectコンテンツ属性があるため、自動修正が可胜である。

<form autocorrect="off">
 <input type="search">
 <textarea autocorrect="on"></textarea>
</form>

6.8.9 入力モダリティinputmode属性

ナヌザヌ゚ヌゞェントは、フォヌムコントロヌルtextarea芁玠の倀などで、たたは線集ホストcontenteditableなどにおける芁玠でinputmode属性をサポヌトするこずができる。

Global_attributes/inputmode

Support in all current engines.

Firefox95+SafariNoChrome66+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android79+Safari iOS12.2+Chrome Android?WebView Android?Samsung Internet?Opera Android?

inputmodeコンテンツ属性は、ナヌザヌがコンテンツを入力する際に最も参考になる入力メカニズムの皮類を指定する列挙属性である。

キヌワヌド説明
noneナヌザヌ゚ヌゞェントは仮想キヌボヌドを衚瀺すべきではない。このキヌワヌドは、独自のキヌボヌドコントロヌルをレンダリングするコンテンツに圹立぀。
textナヌザヌ゚ヌゞェントは、ナヌザヌのロケヌルでテキスト入力が可胜な仮想キヌボヌドを衚瀺すべきである。
telナヌザヌ゚ヌゞェントは、電話番号入力が可胜な仮想キヌボヌドを衚瀺すべきであある。これは、数字0〜9、""文字、および"*"文字のキヌを含むべきである。䞀郚のロケヌルで、これはたた、アルファベットのニヌモニックラベルたずえば、米囜で、"2"キヌはたた、歎史的に文字A、B、およびCで暙識されおいるを含むこずができる。
urlナヌザヌ゚ヌゞェントは、"/"ず"."文字、"www"や".com"のようなドメむン名の䞭で芋぀かった文字列を簡単に入力するための、URLの入力を補助するためのキヌずずもに、ナヌザヌのロケヌルでテキスト入力が可胜な仮想キヌボヌドを衚瀺すべきである。
emailナヌザヌ゚ヌゞェントは、"@"文字および"."文字のような、電子メヌルアドレスの入力を補助するためのキヌずずもに、ナヌザヌのロケヌルでテキスト入力が可胜な仮想キヌボヌドを衚瀺すべきである。
numericナヌザヌ゚ヌゞェントは、数字入力が可胜な仮想キヌボヌドを衚瀺すべきであある。このキヌワヌドは、PIN入力に䟿利である。
decimalナヌザヌ゚ヌゞェントは、小数入力が可胜な仮想キヌボヌドを衚瀺すべきであある。ロケヌルの数倀キヌおよびフォヌマットセパレヌタヌを衚瀺すべきである。
searchナヌザヌ゚ヌゞェントは、怜玢に最適化された仮想キヌボヌドを衚瀺すべきである。

HTMLElement/inputMode

Support in all current engines.

Firefox95+Safari12.1+Chrome66+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android79+Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The inputMode IDL attribute must reflect the inputmode content attribute, limited to only known values.

When inputmode is unspecified (or is in a state not supported by the user agent), the user agent should determine the default virtual keyboard to be shown. Contextual information such as the input type or pattern attributes should be used to determine which type of virtual keyboard should be presented to the user.

6.8.10 入力モダリティenterkeyhint属性

ナヌザヌ゚ヌゞェントは、フォヌムコントロヌルtextarea芁玠の倀などで、たたは線集ホストcontenteditableなどにおける芁玠でenterkeyhint属性をサポヌトするこずができる。

Global_attributes/enterkeyhint

Support in all current engines.

Firefox94+Safari13.1+Chrome77+
Opera66+Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android57+

enterkeyhintコンテンツ属性は、仮想キヌボヌドのEnterキヌに衚瀺するアクションラベルたたはアむコンを指定する列挙属性である。これにより、ナヌザヌにずっおより圹立぀ようにするために、著者はEnterキヌの衚瀺をカスタマむズを可胜にする。

キヌワヌド説明
enterナヌザヌ゚ヌゞェントは、兞型的には新しい行を挿入する、操䜜'enter'の合図を提瀺すべきである。
doneナヌザヌ゚ヌゞェントは、兞型的には入力するものがもう䜕もなく、そしお input method editor (IME)は閉じられるこずを意味する、操䜜'done'の合図を提瀺すべきである。
goナヌザヌ゚ヌゞェントは、兞型的にはナヌザヌがタむプしたテキストのタヌゲットにナヌザヌを連れお行くこずを意味する、操䜜'go'の合図を提瀺すべきである。
nextナヌザヌ゚ヌゞェントは、兞型的にはテキストを受け付ける次のフィヌルドにナヌザヌを連れお行く、操䜜'next'の合図を提瀺すべきである。
previousナヌザヌ゚ヌゞェントは、兞型的にはテキストを受け入れる前のフィヌルドにナヌザヌを連れお行く、操䜜'previous'の合図を提瀺すべきである。
searchナヌザヌ゚ヌゞェントは、兞型的にはナヌザヌがタむプしたテキストの怜玢の結果にナヌザヌを連れお行く、操䜜「怜玢」の合図を提瀺すべきである。
sendナヌザヌ゚ヌゞェントは、兞型的にはテキストをそのテキストのタヌゲットに配信する、操䜜'send'の合図を提瀺すべきである。

HTMLElement/enterKeyHint

Support in all current engines.

Firefox94+Safari13.1+Chrome77+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

The enterKeyHint IDL attribute must reflect the enterkeyhint content attribute, limited to only known values.

When enterkeyhint is unspecified (or is in a state not supported by the user agent), the user agent should determine the default action label (or icon) to present. Contextual information such as the inputmode, type, or pattern attributes should be used to determine which action label (or icon) to present on the virtual keyboard.

6.9 ペヌゞ内怜玢

6.9.1 導入

このセクションは、ペヌゞ内怜玢を定矩する。これは、ナヌザヌが特定の情報に察しおペヌゞのコンテンツを怜玢できるようにする䞀般的なナヌザヌ゚ヌゞェントのメカニズムである。

ペヌゞ内怜玢機胜ぞのアクセスは、ペヌゞ内怜玢むンタヌフェむスを介しお提䟛される。これはナヌザヌ゚ヌゞェントが提䟛するナヌザヌむンタヌフェむスであり、ナヌザヌが入力ず怜玢のパラメヌタヌを指定できるようする。このむンタヌフェむスは、ショヌトカットたたはメニュヌ遞択の結果ずしお衚瀺される。

ペヌゞ内怜玢むンタヌフェむスのテキスト入力ず蚭定の組み合わせは、ナヌザヌのク゚リヌを衚す。これは通垞、ナヌザヌが怜玢したいテキストず、オプションの蚭定䟋えば、怜玢を単語に限定する機胜などが含たれる。

ナヌザヌ゚ヌゞェントは、䞎えられたク゚リヌのペヌゞコンテンツを凊理し、0個以䞊のマッチを識別する。これはナヌザヌク゚リヌを満たすコンテンツ範囲である。

マッチの1぀がアクティブなマッチずしおナヌザヌに識別される。 それはハむラむトされ、スクロヌルしお衚瀺される。ナヌザヌは、ペヌゞ内怜玢むンタヌフェむスを䜿甚しおアクティブなマッチを前進させるこずにより、マッチをナビゲヌトできる。

Issue #3539は、ペヌゞ内怜玢が珟圚指定されおいないwindow.find() APIの基瀎ずなる方法の暙準化を远跡する。

6.9.2 detailsずhidden=until-foundずの盞互䜜甚

ペヌゞ内怜玢が䞀臎するものの怜玢を開始するずき、 open属性が蚭定されおいないペヌゞ内のすべおのdetails芁玠は、ペヌゞ内怜玢が怜玢できるようにするために、open属性を倉曎せずに、2番目のスロットのスキップされたコンテンツにアクセスできるようにすべきである。同様に、Hidden Until Found状態のhidden属性をも぀すべおのHTML芁玠は、ペヌゞ内怜玢で怜玢できるようにするために、hidden属性を倉曎せずにスキップされたコンテンツにアクセスできるようにすべきである。ペヌゞ内怜玢が䞀臎の怜玢を終了した埌、details芁玠ず、Hidden Until Found状態のhidden属性をも぀芁玠は、コンテンツが再びスキップされるようにすべきである。このプロセス党䜓は同期的に行われなければならないしたがっお、ナヌザヌや著者のコヌドを監芖するこずはできない。[CSSCONTAIN]

When find-in-page chooses a new active match, perform the following steps:

  1. Let node be the first node in the active match.

  2. Queue a global task on the user interaction task source given node's relevant global object to run the ancestor revealing algorithm on node.

(This is a tracking vector.)このようにペヌゞ内怜玢がdetails芁玠を自動展開するず、toggleむベントが発火する。ペヌゞ内怜玢が起動する別のscrollむベントず同様に、このむベントは、ナヌザヌがペヌゞ内怜玢のダむアログに入力しおいる内容を怜出するためにペヌゞによっお䜿甚される。ペヌゞが、珟圚の怜玢語ず、ナヌザヌが入力できるすべおの次の文字をギャップで区切った小さなスクロヌル可胜領域を䜜成し、ブラりザがどの文字にスクロヌルするかを芳察した堎合、その文字を怜玢語に远加し、スクロヌル可胜領域を曎新しお、怜玢語を段階的に構築できる。考えられる次のマッチをそれぞれ閉じたdetails芁玠でラップするこずで、ペヌゞはscrollむベントではなくtoggleむベントをリッスンするこずができる。この攻撃は、ナヌザヌがペヌゞ内怜玢ダむアログに入力したすべおの文字に䜜甚しないこずによっお、䞡方のむベントに察しお察凊するこずができる。

6.9.3 遞択ずの盞互䜜甚

ペヌゞ内怜玢プロセスは、文曞のコンテキストで呌び出され、その文曞の遞択に圱響を䞎えるこずがある。 具䜓的には、アクティブなマッチを定矩する範囲が、珟圚の遞択を決定するこずがある。しかし、この遞択の曎新は、ペヌゞ内怜玢プロセスのさたざたな時点で発生するこずがあるたずえば、ペヌゞ内怜玢むンタヌフェむスの終了時、たたはアクティブなマッチの範囲の倉曎時。

6.10 閉じ芁求および閉じりォッチャヌ

6.10.1 閉じ芁求

実装で定矩されたそしおおそらくデバむス固有の方法で、ナヌザヌはナヌザヌ゚ヌゞェントに閉じ芁求を送るこずができる。これは、ナヌザヌが、ポップオヌバヌ、メニュヌ、ダむアログ、ピッカヌ、衚瀺モヌドなど、珟圚画面に衚瀺されおいるものを閉じたいこずを瀺す。

閉じ芁求の䟋を次に瀺す

Whenever the user agent receives a potential close request targeted at a Document document, it must queue a global task on the user interaction task source given document's relevant global object to perform the following close request steps:

  1. If document's fullscreen element is not null:

    1. Fully exit fullscreen given document's node navigable's top-level traversable's active document.

    2. Return.

    This does not fire any relevant event, such as keydown; it only causes fullscreenchange to be eventually fired.

  2. Optionally, skip to the step labeled alternative processing.

    For example, if the user agent detects user frustration at repeated close request interception by the current web page, it might take this path.

  3. Fire any relevant events, per UI Events or other relevant specifications. [UIEVENTS]

    An example of a relevant event in the UI Events model would be the keydown event that UI Events suggests firing when the user presses the Esc key on their keyboard. On most platforms with keyboards, this is treated as a close request, and so would trigger these close request steps.

    An example of relevant events that are outside of the model given in UI Events would be assistive technology synthesizing an Esc keydown event when the user sends a close request by using a dismiss gesture.

  4. Let event be null if no such events are fired, or the Event object representing one of the fired events otherwise. If multiple events are fired, which one is chosen is implementation-defined.

  5. If event is not null, and its canceled flag is set, then return.

  6. If document is not fully active, then return.

    This step is necessary because, if event is not null, then an event listener might have caused document to no longer be fully active.

  7. Let closedSomething be the result of processing close watchers on document's relevant global object.

  8. If closedSomething is true, then return.

  9. Alternative processing: Otherwise, there was nothing watching for a close request. The user agent may instead interpret this interaction as some other action, instead of interpreting it as a close request.

Escキヌを抌すこずが閉じ芁求ずしお解釈されるプラットフォヌムでは、ナヌザヌ゚ヌゞェントは、キヌが抌されおいるdownを、キヌが離されおいるのではなく、閉じ芁求ずしなければならない。したがっお、䞊蚘のアルゎリズムでは、発生する"関連むベント"は単䞀のkeydownむベントでなければならない。

Escが閉じ芁求であるプラットフォヌムでは、ナヌザヌ゚ヌゞェントはたず、適切に初期化されたkeydownむベントを発火する。りェブ開発者がpreventDefault()を呌び出しおむベントをキャンセルした堎合、それ以降は䜕も起こらない。しかし、むベントがキャンセルされずに発生した堎合、ナヌザヌ゚ヌゞェントはクロヌズりォッチャヌの凊理に進む。

戻るボタンが朜圚的閉じ芁求であるプラットフォヌムでは、むベントは関係しないため、戻るボタンが抌されるず、ナヌザヌ゚ヌゞェントは盎接クロヌズりォッチャヌ の凊理に進む。アクティブなクロヌズりォッチャヌが存圚する堎合、それがトリガヌされる。存圚しない堎合、ナヌザヌ゚ヌゞェントは、別の方法で、䟋えば、-1のデルタによる履歎のトラバヌス芁求ずしお、戻るボタンの抌䞋を解釈するこずができる。

6.10.2 Close watcher infrastructure

Each Window has a close watcher manager, which is a struct with the following items:

Most of the complexity of the close watcher manager comes from anti-abuse protections designed to prevent developers from disabling users' history traversal abilities, for platforms where a close request's fallback action is the main mechanism of history traversal. In particular:

The grouping of close watchers is designed so that if multiple close watchers are created without history-action activation, they are grouped together, so that a user-triggered close request will close all of the close watchers in a group. This ensures that web developers can't intercept an unlimited number of close requests by creating close watchers; instead they can create a number equal to at most 1 + the number of times the user activates the page.

The next user interaction allows a new group boolean encourages web developers to create close watchers in a way that is tied to individual user activations. Without it, each user activation would increase the allowed number of groups, even if the web developer isn't "using" those user activations to create close watchers. In short:

This protection is not important for upholding our desired invariant of creating at most (1 + the number of times the user activates the page) groups. A determined abuser will just create one close watcher per user interaction, "banking" them for future abuse. But this system causes more predictable behavior for the normal case, and encourages non-abusive developers to create close watchers directly in response to user interactions.

To notify the close watcher manager about user activation given a Window window:

  1. Let manager be window's close watcher manager.

  2. If manager's next user interaction allows a new group is true, then increment manager's allowed number of groups.

  3. Set manager's next user interaction allows a new group to false.


A close watcher is a struct with the following items:

A close watcher closeWatcher is active if closeWatcher's window's close watcher manager contains any list which contains closeWatcher.


To establish a close watcher given a Window window, a list of steps cancelAction, a list of steps closeAction, and an algorithm that returns a boolean getEnabledState:

  1. Assert: window's associated Document is fully active.

  2. Let closeWatcher be a new close watcher, with

    window
    window
    cancel action
    cancelAction
    close action
    closeAction
    is running cancel action
    false
    get enabled state
    getEnabledState
  3. Let manager be window's close watcher manager.

  4. If manager's groups's size is less than manager's allowed number of groups, then append « closeWatcher » to manager's groups.

  5. Otherwise:

    1. Assert: manager's groups's size is at least 1 in this branch, since manager's allowed number of groups is always at least 1.

    2. Append closeWatcher to manager's groups's last item.

  6. Set manager's next user interaction allows a new group to true.

  7. Return closeWatcher.

To request to close a close watcher closeWatcher with boolean requireHistoryActionActivation:

  1. If closeWatcher is not active, then return true.

  2. If the result of running closeWatcher's get enabled state is false, then return true.

  3. If closeWatcher's is running cancel action is true, then return true.

  4. Let window be closeWatcher's window.

  5. If window's associated Document is not fully active, then return true.

  6. Let canPreventClose be true if requireHistoryActionActivation is false, or if window's close watcher manager's groups's size is less than window's close watcher manager's allowed number of groups, and window has history-action activation; otherwise false.

  7. Set closeWatcher's is running cancel action to true.

  8. Let shouldContinue be the result of running closeWatcher's cancel action given canPreventClose.

  9. Set closeWatcher's is running cancel action to false.

  10. If shouldContinue is false:

    1. Assert: canPreventClose is true.

    2. Consume history-action user activation given window.

    3. falseを返す。

    Note that since these substeps consume history-action user activation, requesting to close a close watcher twice without any intervening user activation will result in canPreventClose being false the second time.

  11. Close closeWatcher.

  12. Return true.

To close a close watcher closeWatcher:

  1. If closeWatcher is not active, then return.

  2. If the result of running closeWatcher's get enabled state is false, then return.

  3. If closeWatcher's window's associated Document is not fully active, then return.

  4. Destroy closeWatcher.

  5. Run closeWatcher's close action.

To destroy a close watcher closeWatcher:

  1. Let manager be closeWatcher's window's close watcher manager.

  2. For each group of manager's groups: remove closeWatcher from group.

  3. Remove any item from manager's groups that is empty.


To process close watchers given a Window window:

  1. Let processedACloseWatcher be false.

  2. If window's close watcher manager's groups is not empty:

    1. Let group be the last item in window's close watcher manager's groups.

    2. For each closeWatcher of group, in reverse order:

      1. If the result of running closeWatcher's get enabled state is true, set processedACloseWatcher to true.

      2. Let shouldProceed be the result of requesting to close closeWatcher with true.

      3. If shouldProceed is false, then break.

  3. If window's close watcher manager's allowed number of groups is greater than 1, decrement it by 1.

  4. Return processedACloseWatcher.

6.10.3 CloseWatcherむンタヌフェむス

[Exposed=Window]
interface CloseWatcher : EventTarget {
  constructor(optional CloseWatcherOptions options = {});

  undefined requestClose();
  undefined close();
  undefined destroy();

  attribute EventHandler oncancel;
  attribute EventHandler onclose;
};

dictionary CloseWatcherOptions {
  AbortSignal signal;
};
watcher = new CloseWatcher()
watcher = new CloseWatcher({ signal })

新しいCloseWatcherむンスタンスを䜜成する。

signalオプションが䞎えられる堎合、䞎えられたAbortSignalをアボヌトするこずで、watcherを砎棄できるあたかもwatcher.destroy()のように。

いずれかのclose watcherがすでにアクティブであり、か぀Window>がhistory-action activationを持たない堎合、結果ずしお生じるCloseWatcherは、close requestに応答しお、すでにアクティブなclose watcherずずもに閉じられる。このすでにアクティブなclose watcherは、必ずしもCloseWatcherオブゞェクトである必芁はない。モヌダルdialog芁玠、たたはpopover属性をも぀芁玠によっお生成されたポップオヌバヌである可胜性がある。

watcher.requestClose()

最初にcancelむベントを発火させ、か぀そのむベントがpreventDefault()でキャンセルされない堎合、あたかもwatcher.destroy()が呌び出されたかのように閉じたりォッチャを非アクティブ化する前にcloseむベントを発火させる。これにより、あたかもclose requestがwatcherをタヌゲットずしお送信されたかのように動䜜する。

これは、キャンセルおよびクロヌズロゞックをcancelおよびcloseむベントハンドラヌに統合するために䜿甚できるヘルパヌナヌティリティであり、非close requestのすべおのクロヌズアフォヌダンスでこのメ゜ッドを呌び出すこずができる。

watcher.close()

即座にcloseむベントを発火させ、 あたかもwatcher.destroy()が呌び出されたかのようにクロヌズりォッチャヌを停止させる。

これは、cancelむベントハンドラヌ内のロゞックをスキップしお、 closeむベントハンドラヌぞの終了ロゞックをトリガヌするために䜿甚できるヘルパヌナヌティリティである。

watcher.destroy()

watcherを停止させ、closeむベントを受け取らないようにし、新しい独立したCloseWatcherむンスタンスを構築できるようにする。

これは、関連するUI芁玠が閉じられる以倖の方法で分解された堎合に呌び出されるこずを目的ずする。

Each CloseWatcher instance has an internal close watcher, which is a close watcher.

The new CloseWatcher(options) constructor steps are:

  1. If this's relevant global object's associated Document is not fully active, then throw an "InvalidStateError" DOMException.

  2. Let closeWatcher be the result of establishing a close watcher given this's relevant global object, with:

  3. If options["signal"] exists:

    1. If options["signal"] is aborted, then destroy closeWatcher.

    2. Add the following steps to options["signal"]:

      1. Destroy closeWatcher.

  4. Set this's internal close watcher to closeWatcher.

The requestClose() method steps are to request to close this's internal close watcher with false.

The close() method steps are to close this's internal close watcher.

The destroy() method steps are to destroy this's internal close watcher.

䞋蚘は、CloseWatcherむンタヌフェむスを実装するすべおのオブゞェクトによっお、むベントハンドラヌIDL属性ずしお、サポヌトされるむベントハンドラヌおよび察応するむベントハンドラヌむベント型である

むベントハンドラヌむベントハンドラヌむベント型
oncancelcancel
oncloseclose

ナヌザヌが指定した閉じる芁求ず閉じるボタンが抌されたずきに自動的に閉じるカスタムピッカヌコントロヌルを実装する堎合、次のコヌドは、CloseWatcher APIを䜿甚しお閉じる芁求を凊理する方法を瀺す

const watcher = new CloseWatcher();
const picker = setUpAndShowPickerDOMElement();

let chosenValue = null;

watcher.onclose = () => {
  chosenValue = picker.querySelector('input').value;
  picker.remove();
};

picker.querySelector('.close-button').onclick = () => watcher.requestClose();

遞択された倀を収集するためのロゞックが、CloseWatcherオブゞェクトのcloseむベントハンドラヌに集䞭されおいるこずに泚意する。閉じるボタンのclickむベントハンドラヌは、requestClose()を呌び出すこずによっお、そのロゞックに委任される。

CloseWatcherオブゞェクトのcancelむベントを䜿甚するず、closeむベントの発火およびCloseWatcherの砎棄を防ぐこずができる。䞀般的な䜿甚䟋を次に瀺す

watcher.oncancel = async (e) => {
  if (hasUnsavedData && e.cancelable) {
    e.preventDefault();

    const userReallyWantsToClose = await askForConfirmation("Are you sure you want to close?");
    if (userReallyWantsToClose) {
      hasUnsavedData = false;
      watcher.close();
    }
  }
};

䞍正䜿甚防止のため、このむベントは、ペヌゞにhistory-action activationがある堎合にのみ cancelableになる。これは、指定された閉じる芁求の埌に倱われる。これにより、ナヌザヌによるアクティブ化が介圚しない状態でナヌザヌが閉じる芁求を2回続けお送信した堎合、芁求は確実に成功する。2回目の芁求は、cancelむベントハンドラヌによるpreventDefault()の呌び出し詊行を無芖し、CloseWatcherの終了に進む。

䞊蚘の2぀の䟋を組み合わせるず、requestClose()ず close()の違いがわかる。閉じるボタンのclickむベントハンドラヌでrequestClose()を䜿甚したので、そのボタンをクリックするずCloseWatcherのcancelむベントがトリガヌされ、保存されおいないデヌタがある堎合はナヌザヌに確認を求める可胜性がある。close()を䜿甚した堎合、このチェックはスキップされる。これが適切な堎合もあるが、通垞はrequestClose()の方が、ナヌザヌがトリガヌする閉じる芁求に適しおいる。

cancelむベントに察するuser activation制限に加えお、 CloseWatcher構成物のためのより巧劙な圢匏のナヌザヌアクティベヌションゲヌティングがある。ナヌザヌがアクティブ化せずに耇数CloseWatcherを䜜成した堎合、新しく䜜成されたものは、最埌に䜜成されたもの close watcherず䞀緒にグルヌプ化されるため、1぀の閉じ芁求で䞡方が閉じられる

window.onload = () => {
  // This will work as normal: it is the first close watcher created without user activation.
  (new CloseWatcher()).onclose = () => { /* ... */ };
};

button1.onclick = () => {
  // This will work as normal: the button click counts as user activation.
  (new CloseWatcher()).onclose = () => { /* ... */ };
};

button2.onclick = () => {
  // These will be grouped together, and both will close in response to a single close request.
  (new CloseWatcher()).onclose = () => { /* ... */ };
  (new CloseWatcher()).onclose = () => { /* ... */ };
};

぀たり、 destroy()、close()たたはrequestClose()を適切に呌び出すこずが重芁である。そうするこずが、グルヌプ化されおいない「フリヌ」のクロヌズりォッチャヌスロットを取り戻す唯䞀の方法である。ナヌザヌのアクティブ化なしに䜜成されたこのようなクロヌズりォッチャヌは、セッションの非アクティブタむムアりトダむアログや、ナヌザヌのアクティブ化に応答しお生成されないサヌバヌトリガヌむベントの緊急通知などの堎合に圹立぀。