Support in all current engines.
すべてのはhiddenコンテンツ属性設定を持ってもよい。属性はである。要素で指定される場合、それは、要素がまだないこと、またはもはやページの現在の状態には直接関係がない、または、ユーザーが直接アクセスするのとは対照的に、ページの他の部分で再利用するコンテンツを宣言するために使用されていることを示す。
この属性は通常CSSを使用して実装されているため、CSSを使用して上書きすることもできる。たとえば、'display: block'をすべての要素に適用する規則は、属性の影響を相殺するだろう。したがって著者は、期待通りに属性がスタイル付けされていることを確認し、そのスタイルシートを書くときに注意する必要がある。
以下の骨格の例において、属性は、ユーザーがログインするまでウェブゲームのメイン画面を非表示にするために使用される：
< 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 > 属性は、別のプレゼンテーションに合法的に示すことができたコンテンツを隠すために使用されてはならない。たとえば、タブ付きインターフェイスは単にオーバーフロープレゼンテーションの一種であるため、タブ付きダイアログでパネルを隠すためにを使用することは誤りである。―それはスクロールバーをもつ1つの大きなページ内のすべてのフォームコントロールを示すのと同様である。ちょうど1つのプレゼンテーションからコンテンツを非表示にするためにこの属性を使用することも同様に誤りである。―何かがとマークされる場合、それは、たとえばスクリーンリーダーなどを含む、すべてのプレゼンテーションから隠されている。
自身がでない要素は、である要素へされてはならない。自身がでないおよび要素のfor属性も同様に、である要素を参照してはならない。どちらの場合も、このような参照はユーザーの混乱を引き起こすだろう。
しかし、要素およびスクリプトは、他のコンテキストでである要素を参照してもよい。
たとえば、属性でマークされたセクションにリンクする属性を使用するのは誤りだろう。コンテンツが適切または関連しない場合、それにリンクする理由はない。
しかし、自身がである説明を参照するために、ARIA 属性を使用することは構わない。説明を非表示にすることはそれらが単独で有用でないことを意味する一方で、それらは、それらが説明する要素から参照される特定のコンテキストにおいて有用である方法で記述することもできる。
同様に、属性を持つ要素は、オフスクリーンバッファーとしてスクリプト化されたグラフィックスエンジンによって使用されるかもしれず、フォームコントロールは、属性を使用する隠し要素を参照するかもしれない。
属性によって非表示にされたセクション内の要素は依然としてアクティブである。たとえば、そのようなセクションでのスクリプトやフォームコントロールは、依然として実行および送信する。それらのプレゼンテーションのみがユーザーに変更される。
この節は、"inert"という名前のいかなるコンテンツ属性を定義または作成しない。この節は、単に不活性の抽象的な概念を定義する。
（特に要素やテキストノード）あるノードは不活性としてマークすることができる。ノードが不活性であるとき、あたかもノードがユーザーインタラクションイベントを対象する目的のために不在であるかのように、ユーザーエージェントは動作しなければならず、ページ内検索の目的に対してノードを無視してもよく、そのノード内のテキストの選択からユーザーを防いでもよい。しかし、ユーザーエージェントは、ユーザーが検索とテキスト選択に制限を上書きできるようにすべきである。
たとえば、bodyの中央に位置する単一の不活性段落からなるページを考えてみる。ユーザーがbody上から不活性段落へポインティングデバイスを移動させ、段落上をクリックする場合、mouseoverイベントは発火せず、mousemoveおよびclickイベントは段落よりむしろbody要素で発火するだろう。
ノードが不活性である場合、ノードは一般にフォーカスできない。コマンドである不活性ノードはまた、無効であるだろう。
ブラウジングコンテキストコンテナが不活性としてマークされる間に、そのネストされたブラウジングコンテキストのアクティブ文書、およびそのDocumentにおけるすべてのノードは、不活性としてマークされなければならない。
要素がinertであり、そのノード文書がinertでない場合、要素は明示的にinertである。
subjectがdocumentの最上位レイヤーの一番上のdialog要素である場合、Document documentはモーダルダイアログボックスによってブロックされるsubjectである。documentがそのようにブロックされる一方で、documentに接続されているすべてのノードは、subject要素とそのシャドウを含む子孫を除き、不活性とマークされなければならない。（この段落で除外される要素は、さらに他の手段を介して不活性にマークすることができる。モーダルダイアログの一部であることは不活性とマークされることからノードを"守る"ことはない。）
dialog要素のshowModal()メソッドは、dialog要素をノード文書の最上位レイヤーに追加することによって、このメカニズムをトリガーさせる。
ユーザーに迷惑となる可能性がある特定のAPI（ポップアップを開く、振動する電話など）の悪用を防ぐために、ユーザーエージェントは、ユーザーがウェブページをアクティブに操作している、または少なくとも1回はページを操作した場合にのみ、これらのAPIを許可する。この"アクティブな相互作用"の状態は、この節で定義されたメカニズムを通じて維持される。
ユーザーのアクティブ化に依存するAPIは、3つの異なるレベルに分類される。レベルは以下のとおりで、ユーザーのアクティブ化に対する"依存度の強さ"でソートされている（最も弱いものから最も強いものへ）。
このAPIは、定着したアクティブ化状態がtrueである必要があるため、最初のユーザーによるアクティブ化までブロックされる。
このAPIは、一時的なアクティブ化状態がtrueであることを必要とするが、それを消費しないため、一時的な状態が期限切れになるまで、ユーザーによるアクティブ化ごとに複数の呼び出しが許可される。
このAPIは、一時的なアクティブ化状態がtrueであることを必要とし、ユーザーによるアクティブ化ごとの複数の呼び出しを防ぐために、各呼び出しでユーザーによるアクティブ化を消費する。
HTMLの特定の要素は、ユーザーがアクティブにすることができることを意味する、アクティブ化動作を持つ。これは、常にclickイベントによって発生する。
click()Support in all current engines.
あたかも要素をクリックされたかのように動作する。
HTMLユーザーインターフェイスは典型的に、フォームコントロール、スクロール可能領域、リンク、ダイアログボックス、ブラウザータブなど、複数の対話的なウィジットから成る。これらウィジェットは、他（たとえば、リンク、フォームコントロール）を含むもの（たとえば、ブラウザータブ、ダイアログボックス）をもつ、階層構造を形成する。
キーボードを使用するインターフェイスと情報交換する場合、アクティブなウィジェットから、フォーカスされると呼ばれる、対話的なウィジェットの階層構造を通して、キー入力はシステムから流れる。
グラフィカル環境で動作するブラウザータブにおいて動作するHTMLアプリケーションを考えてみる。このアプリケーションが、いくつかのテキストコントロールおよびリンクをもつページを持ち、それ自身がテキストコントロールとボタンを持った、モーダルダイアログを表示していると想定する。
このシナリオにおいて、その子の間でHTMLアプリケーションを含むブラウザータブを持つだろう、フォーカス可能なウィジェットの階層構造は、ブラウザーウィンドウを含むかもしれない。タブ自身は、ダイアログと同様に、その子として、様々なリンクおよびテキストコントロールを持つだろう。ダイアログ自身は、その子として、テキストコントロールおよびボタンを持つだろう。
この例でフォーカスをもつウィジェットがダイアログボックスでテキストコントロールであった場合、キー入力は、グラフィカルシステムから①ウェブブラウザー、②タブ、③ダイアログ、そして最後に④テキストコントロールへ流される。
キーボードイベントは、常にこのフォーカスされた要素で対象にされる。
A top-level browsing context has system focus when it can receive keyboard input channeled from the operating system.
System focus is lost when a browser window loses focus, but might also be lost to other system widgets in the browser window such as a URL bar.
The term focusable area is used to refer to regions of the interface that can further become the target of such keyboard input. フォーカス可能領域は、要素、要素の一部、またはユーザーエージェントによって処理される他の領域となることができる。
各フォーカス可能領域は、DOMでフォーカス可能領域の位置を表すNodeオブジェクトである、DOMアンカーを持つ。（フォーカス可能領域がNode自身である場合、それはそれ自身のDOM anchorである。）フォーカス可能領域を表すために他のDOMオブジェクトが存在しない場合、DOMアンカーは、フォーカス可能領域に適するようないくつかのAPIで使用される。
以下のテーブルは、どのオブジェクトがフォーカス可能領域となることができるかを説明する。左の列におけるセルは、フォーカス可能領域となることができるオブジェクトを説明する。右の列におけるセルは、この要素に対するDOMアンカーを説明する。（両方の列をまたぐセルは、非規範的な例である。）
| フォーカス可能領域 | DOMアンカー |
|---|---|
| 例 | |
Elements that meet all the following criteria:
| 要素自身。 |
| |
レンダリングされているおよび明示的に不活性でないimg要素に関連するイメージマップにおけるarea要素の形状。 | img要素 |
次の例において、それぞれ画像の、 | |
| 要素のサブウィジェットを提供されるユーザーエージェントは、レンダリングされているかつ実際に無効または明確に不活性でない。 | フォーカス可能領域がサブウィジェットとなる要素。 |
The controls in the user interface for a | |
| レンダリングされているかつ明確に不活性でない要素のスクロール可能な領域。 | スクロール可能な領域のスクロールが作成されたボックスに対する要素 |
CSS 'overflow'プロパティの'scroll'値が典型的にスクロール可能領域を作成する。 | |
The viewport of a Document that has a non-null browsing context and is not inert. | ビューポートが作成されたDocument。 |
| |
| Any other element or part of an element determined by the user agent to be a focusable area, especially to aid with accessibility or to better match platform conventions. | 要素。 |
A user agent could make all list item bullets sequentially focusable, so that a user can more easily navigate lists. Similarly, a user agent could make all elements with | |
ブラウジングコンテキストコンテナ（たとえばiframe）は、フォーカス可能領域であるが、ブラウジングコンテキストコンテナに送られるキーイベントは、そのネストされたブラウジングコンテキストのアクティブ文書に送られる。同様に、逐次的フォーカスナビゲーションにおいてブラウジングコンテキストコンテナは本質的にそのネストされるブラウジングコンテキストのアクティブ文書に対するプレースホルダーとして単に動作する。
One focusable area in each Document is designated the focused area of the document. どのコントロールがそのように呼ばれるかは時間とともに変化し、この仕様におけるアルゴリズムに基づく。
The currently focused area of a top-level browsing context topLevelBC at any particular time is the focusable area-or-null returned by this algorithm:
If topLevelBC does not have system focus, then return null.
Let candidate be topLevelBC's active document.
While candidate's focused area is a browsing context container with a non-null nested browsing context: set candidate to the active document of that browsing context container's nested browsing context.
If candidate's focused area is non-null, set candidate to candidate's focused area.
candidateを返す。
The current focus chain of a top-level browsing context topLevelBC at any particular time is the focus chain of the currently focused area of topLevelBC, if topLevelBC is non-null, or an empty list otherwise.
フォーカス可能領域のDOMアンカーである要素は、フォーカス可能領域がトップレベルブラウジングコンテキストの被フォーカス領域になる場合に利得フォーカスと呼ばれる。要素がトップレベルブラウジングコンテキストの現在の被フォーカス領域に属するフォーカス可能領域のDOMアンカーである場合、要素は被フォーカスである。
tabindex属性Support in all current engines.
tabindexコンテンツ属性は、著者が、DOMアンカーとして要素を持つ要素および領域をフォーカス可能領域にする、逐次フォーカス可能にすることを許可または防止する、ならびに逐次フォーカスナビゲーションの相対的な順序を決定することを可能にする。
名前"tab index"は、フォーカス可能な要素を通してナビゲートするためのTabキーの一般的な使用方法に由来する。"tabbing"（タブ移動）という用語は、逐次フォーカス可能なフォーカス可能領域を前に進めることを指す。
tabindex属性が指定される場合、妥当な整数である値を持たなければならない。正の数値は、要素のフォーカス可能領域の相対的な位置を順次フォーカスナビゲーション順序で指定し、負の数値はコントロールが順次フォーカス可能でないことを示す。
0または-1以外の値を使用している場合、開発者は、これが正しく行うために複雑になるよう、自身のtabindex属性に対して用心すべきである。
以下に、可能なtabindex属性値の動作の概要を提供する。
tabindex属性値がより大きい要素は後から来る。tabindex属性は、要素をフォーカス不可にするために使用できないことに注意する。ページ著者ができる唯一の方法は、要素を無効にする、または要素を不活性にすることである。
activeElementキーイベントが送られるまたは送る文書における最も深い要素を返す。大まかに言って、これは文書における被フォーカス要素である。
このAPIのために、子ブラウジングコンテキストが被フォーカスである場合、そのコンテナは親ブラウジングコンテキストで被フォーカスである。たとえば、ユーザーがiframeでフォーカスをテキストコントロールに移動する場合、iframeはiframeのnode documentにおいてactiveElement APIによって返される要素である。
同様に、フォーカスされた要素がdocumentOrShadowRootとは異なるノードツリーにあるとき、documentOrShadowRootがフォーカスされた要素のシャドウを含む包含祖先である場合、返される要素はdocumentOrShadowRootと同じノードツリーにあるホストになり、そうでない場合はnullになる。
hasFocus()Support in all current engines.
キーイベントが文書を通してまたは文書に向かって送られる場合にtrueを返し、そうでなければfalseを返す。大まかに言って、これは文書、この内側でネストされた文書、被フォーカスに対応する。
focus()Support in all current engines.
可能であれば、フォーカスをウィンドウのブラウジングコンテキストに移動する。
focus([ { preventScroll: true } ])Support in all current engines.
フォーカスを要素に移動する。
If the element is a browsing context container, moves the focus to its nested browsing context instead.
デフォルトでは、このメソッドはまた要素をビューにスクロールする。preventScrollオプションを指定してtrueに設定すると、この動作が防止される。
blur()Support in all current engines.
フォーカスをビューポートに移動する。このメソッドの使用は奨められない。ビューポートにフォーカスしたい場合、Documentの文書要素上のfocus()メソッドを呼び出す。
見苦しいフォーカスリングを発見する場合、フォーカスリングを非表示にするためにこの方法を使用してはならない。代わりに、'outline'プロパティを上書きするためにCSS規則を使用し、要素がフォーカスされるものを表示する別の方法を提供する。代替フォーカススタイルが利用可能にならないか、ページが主にキーボードを使用してページをナビゲートする人に対して著しく使用可能にならないか、ページをナビゲートするのに役立つフォーカスアウトラインを使う人の視覚を減少させないかどうかに注意する。
たとえば、リンクからアウトラインを隠し、代わりにフォーカスを示すために黄色の背景を使用するために、次を使うことができる：
:link:focus, :visited:focus { outline : none; background : yellow; color : black; } autofocus属性Support in all current engines.
autofocusコンテンツ属性は、ページが読み込まれるとすぐに、または自身を見つけてその中でdialogを表示されるとすぐに、要素をフォーカスすることを著者に許可し、ユーザーが手動で主な要素にフォーカスすることなしに入力をすぐに開始できるようにする。
要素の直近の祖先オートフォーカス範囲のルート要素は、その要素がdialog要素である場合、要素そのものであり、そうでなければ、もしあれば要素の直近の祖先dialog要素であり、そうでなければ要素の最後の包括祖先要素である。
両方がautofocus属性を指定される同じ直近の祖先オートフォーカス範囲のルート要素をもつ2つの要素が存在してはならない。
次の断片において、文書が読み込まれるとき、テキストコントロールにフォーカスされる。
< input maxlength = "256" name = "q" value = "" autofocus >
< input type = "submit" value = "Search" > autofocus属性は、フォームコントロールだけでなく、すべての要素に適用される。 これにより、次のような例が可能になる：
< div contenteditable autofocus > Edit < strong > me!</ strong >< div > アクティブにされるまたはフォーカスさせることができる各要素はaccesskey属性を使用して、それをアクティブにするための単一のキーの組み合わせを割り当てることができる。
正確なショートカットは、ユーザーエージェントによって決定され、ユーザーのキーボードに関する情報に基づき、どのキーボードショートカットが既にプラットフォーム上に存在し、他にどのようなショートカットがページ上で指定され、ガイドとしてaccesskey属性に提供された情報を使用する。
関連するキーボードショートカットが多種多様な入力デバイスで利用可能であることを確実にするために、著者はaccesskey属性で多数の選択肢を提供できる。
各選択肢は、文字または数字のような、単一の文字で構成される。
ユーザーエージェントは、キーボードショートカットの一覧をユーザーに提供できるが、著者は行うことも推奨される。accessKeyLabel IDL属性は、ユーザーエージェントによって割り当てられた実際のキーの組み合わせを表す文字列を返す。
この例において、著者はショートカットキーを使用して呼び出すことができるボタンを提供してきた。フルキーボードをサポートするために、著者は可能なキーとして"C"を提供している。テンキーのみを搭載したデバイスをサポートするために、著者は別の可能なキーとして"1"を提供している。
< input type = button value = Collect onclick = "collect()"
accesskey = "C 1" id = c > ショートカットキーが何であるかをユーザーに伝えるために、著者は明示的にボタンのラベルにキーの組み合わせを追加するために選択しているここでのこのスクリプトを持つ。
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属性から返された値を解析しようとするのは賢明ではない。
accesskey属性Support in all current engines.
すべての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"になる。正確な文字列は割り当てられるアクセスキーが何であるか、およびどのようにユーザーエージェントがそのキーの組み合わせを表すかに依存する。
contenteditableコンテンツ属性Support in all current engines.
Global_attributes/contenteditable
Support in all current engines.
contenteditableコンテンツ属性は、キーワードが空文字列、true、おとびfalseとなる列挙属性である。空の文字列およびtrueキーワードは、true状態に対応する。falseキーワードは、false状態に対応する。さらに、inherit状態という第3の状態が存在する。これは欠損値のデフォルトおよび不正値のデフォルトである。
true状態は、要素が編集可能であることを示す。inherit状態は、その親が存在する場合、要素が編集可能であることを示す。false状態は、要素が編集可能でないことを示す。
たとえば、ユーザーがHTMLを使用する記事を書くことが期待される、新しい記事を公開するためにformおよびtextareaを持つページを考えてみる：
< form method = POST >
< fieldset >
< legend > New article</ legend >
< textarea name = article > < p>Hello world.< /p></ textarea >
</ fieldset >
< p >< button > Publish</ button ></ p >
</ form > スクリプトを有効にする場合、textarea要素は、contenteditable属性を使用して、代わりにリッチテキストコントロールに置き換えることができる：
< form method = POST >
< fieldset >
< legend > New article</ legend >
< textarea id = textarea name = article > < p>Hello world.< /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 : .2 em ; font-size : 2 em ; color : lime ; background : purple }
head , title , style { display : block }
body { display : none }
</ style > contentEditable [ = value ]contenteditable属性の状態に基づいて、"true"、"false"、または"inherit"を返す。
その状態を変更する設定が可能である。
新しい値がこれらの文字列のいずれかでない場合、"SyntaxError" DOMExceptionを投げる。
isContentEditableSupport in all current engines.
要素が編集可能な場合にtrueを返す。そうでなければfalseを返す。
6.7.2 文書全体を編集可能にする：designModeのゲッターおよびセッターSupport in all current engines.
designMode [ = value ]文書が編集可能である場合に"on"を返し、ない場合に"off"を返す。
文書の現在の状態を変更する設定が可能である。これは、文書をフォーカスし、その文書で文書の選択をリセットする。
著者は、もともと値'pre-wrap'へこれら編集のメカニズムを介して作成された編集ホストおよびマークアップ上の'white-space'プロパティを設定することを奨める。デフォルトのHTML空白処理は、あまりWYSIWYG編集に向かず、そして'white-space'がデフォルト値のままである場合、いくつかのコーナーの場合において、行の折り返しは正しく動作しない。
デフォルト'normal'値が代わりに使用される場合に発生する問題の例として、単語の間に2つのスペース（ここでは"␣"によって表される）とともに、"yellow␣␣ball"と入力したユーザーの場合を考える。'white-space'のデフォルト値（'normal'）のための場所での編集規則ともに、結果のマークアップは、"yellow ball"または"yellow ball"のいずれかで構成される。すなわち、2つの単語間の非開票スペースに加えて、通常スペースが存在する。'white-space'に対する'normal'値は共に相殺するために隣接する通常スペースを必要とするため、これは必要である。
前者の場合において、たとえ行の末尾で"yellow"単独で一致するとしても、"yellow⍽"は次の行（"⍽"は非改行スペースを表すためにここで使用されている）に折り返す。後者の場合において、行の先頭に包まれる場合、"⍽ball"は非改行スペース由来の可視インデントを持つだろう。
しかし、'white-space'が'pre-wrap'に設定される場合、編集規則は、代わりに単に単語間に2つの通常のスペースを置き、2つの単語が行末で分割されるべきであり、スペースはレンダリングから削除されてきれいになる。
Support in all current engines.
spellcheck属性は、キーワードが空文字列、trueおよびfalseとなる列挙属性である。空の文字列およびtrueキーワードは、true状態に対応する。falseキーワードは、false状態に対応する。さらに、default状態という第3の状態が存在する。これは欠損値のデフォルトおよび不正値のデフォルトである。
true状態は、要素がそのスペルおよび文法チェックを持つことを示す。default状態は、以下で定義されるように、親要素の独自のspellcheck状態におそらく基づいて、デフォルトの動作に応じて動作する要素であることを示す。false状態は、要素がチェックされないことを示す。
spellcheck [ = value ]要素がスペルや文法チェックを持つ場合はtrueを返す。そうでなければfalseを返す。
デフォルトを上書きしてspellcheckコンテンツ属性を設定するための、設定が可能である。
この仕様は、スペルや文法チェッカーに対するユーザーインターフェイスを定義しない。ユーザーエージェントはオンデマンドチェックを提供するかもしれず、チェックが有効である間に連続的なチェックを実行するかもしれず、または他のインターフェイスを使用するかもしれない。
Global_attributes/autocapitalize
Support in all current engines.
モバイルデバイス上の仮想キーボードや音声入力など、テキストを入力するいくつかの方法では、文の最初の文字を自動的に大文字にすることでユーザーを支援することがある（この規則で言語でテキストを構成する場合）。自動大文字化を実装する仮想キーボードは、自動大文字にすべき文字を入力しようとするとき、大文字の文字を表示するように自動的に切り替えるかもしれない（ただし、ユーザーはその文字を小文字に切り替え可能である）。例えば音声入力など、他の入力の種類は、ユーザーが最初に介入するオプションを与えないような方法で自動大文字化を行ってもよい。autocapitalize属性は、著者がそのような振る舞いを制御するのを可能にする。
典型的に実装されるように、autocapitalize属性は、物理キーボードで入力するときの動作に影響しない。（この理由のために、場合によっては自動大文字化の動作を上書きしたり、最初の入力の後にテキストを編集することをユーザーの能力と同様に、属性をいかなる種類の入力検証にも当てにしてはならない。
ホストされている編集可能領域の自動大文字化動作を制御するために編集ホスト上で、その要素にテキストを入力するための動作を制御するためにinputもしくはtextarea要素の上で、またはform要素に関連付けられたすべての自動大文字継承要素のデフォルトの動作を制御するためにform要素上でautocapitalize属性を使用することができる。
autocapitalize属性は、type属性がURL、Email、またはPassword状態のいずれかにあるinput要素に対して、自動大文字化を有効にすることはない。
自動大文字化処理モデルは、以下のように定義される5つの自動大文字化ヒントの中から選択することに基づく：
ユーザーエージェントおよびインプットメソッドは、自動大文字化を有効にするかどうかを独自に決定すべきである。
自動大文字化は適用されるべきではない（すべての文字は小文字をデフォルトにすべきである）。
各文の最初の文字は大文字をデフォルトにすべきである。他のすべての文字は小文字をデフォルトにすべきである。
各単語の最初の文字は大文字をデフォルトにすべきである。他のすべての文字は小文字をデフォルトにすべきである。
全ての文字は大文字をデフォルトにすべきである。
autocapitalize属性は、状態が可能な自動大文字ヒントである列挙属性である。属性の状態で指定された自動大文字化ヒントは、ユーザーエージェントの動作を通知する、使用済みの自動大文字化ヒントを形成するための他の考慮事項と組み合わされる。この属性のキーワードと状態マッピングは次のとおり：
| キーワード | 状態 |
|---|---|
off | none |
none | |
on | sentences |
sentences | |
words | words |
characters | characters |
不正値のデフォルトはsentences状態である。欠損値のデフォルトはdefault状態である。
autocapitalize [ = value ]要素の現在の自動大文字化状態を返す。設定されていない場合は空文字列を返す。form要素から状態を継承するinput要素とtextarea要素の場合、これはform要素の自動大文字化状態を返すが、編集可能領域の要素の場合、これは（この要素が実際に編集ホストでない限り）編集ホストの自動大文字化状態を返さないことに注意すること。
autocapitalizeコンテンツ属性を設定する（そしてそれによって要素の自動大文字化動作を変化させる）ことで、設定が可能である。
inputmode属性Support in all current engines.
ユーザーエージェントは、フォームコントロール（textarea要素の値など）で、または編集ホスト（contenteditableなど）における要素でinputmode属性をサポートすることができる。
inputmodeコンテンツ属性は、ユーザーがコンテンツを入力する際に最も参考になる入力メカニズムの種類を指定する列挙属性である。
| キーワード | 説明 |
|---|---|
none | ユーザーエージェントは仮想キーボードを表示すべきではない。このキーワードは、独自のキーボードコントロールをレンダリングするコンテンツに役立つ。 |
text | ユーザーエージェントは、ユーザーのロケールでテキスト入力が可能な仮想キーボードを表示すべきである。 |
tel | ユーザーエージェントは、電話番号入力が可能な仮想キーボードを表示すべきであある。これは、数字0〜9、"＃"文字、および"*"文字のキーを含むべきである。一部のロケールで、これはまた、アルファベットのニーモニックラベル（たとえば、米国で、"2"キーはまた、歴史的に文字A、B、およびCで標識されている）を含むことができる。 |
url | ユーザーエージェントは、"/"と"."文字、"www"や".com"のようなドメイン名の中で見つかった文字列を簡単に入力するための、URLの入力を補助するためのキーとともに、ユーザーのロケールでテキスト入力が可能な仮想キーボードを表示すべきである。 |
email | ユーザーエージェントは、"@"文字および"."文字のような、電子メールアドレスの入力を補助するためのキーとともに、ユーザーのロケールでテキスト入力が可能な仮想キーボードを表示すべきである。 |
numeric | ユーザーエージェントは、数字入力が可能な仮想キーボードを表示すべきであある。このキーワードは、PIN入力に便利である。 |
decimal | ユーザーエージェントは、小数入力が可能な仮想キーボードを表示すべきであある。ロケールの数値キーおよびフォーマットセパレーターを表示すべきである。 |
search | ユーザーエージェントは、検索に最適化された仮想キーボードを表示すべきである。 |
enterkeyhint属性ユーザーエージェントは、フォームコントロール（textarea要素の値など）で、または編集ホスト（contenteditableなど）における要素でenterkeyhint属性をサポートすることができる。
enterkeyhintコンテンツ属性は、仮想キーボードのEnterキーに表示するアクションラベル（またはアイコン）を指定する列挙属性である。これにより、ユーザーにとってより役立つようにするために、著者はEnterキーの表示をカスタマイズを可能にする。
| キーワード | 説明 |
|---|---|
enter | ユーザーエージェントは、典型的には新しい行を挿入する、操作'enter'の合図を提示すべきである。 |
done | ユーザーエージェントは、典型的には入力するものがもう何もなく、そして input method editor (IME)は閉じられることを意味する、操作'done'の合図を提示すべきである。 |
go | ユーザーエージェントは、典型的にはユーザーがタイプしたテキストのターゲットにユーザーを連れて行くことを意味する、操作'go'の合図を提示すべきである。 |
next | ユーザーエージェントは、典型的にはテキストを受け付ける次のフィールドにユーザーを連れて行く、操作'next'の合図を提示すべきである。 |
previous | ユーザーエージェントは、典型的にはテキストを受け入れる前のフィールドにユーザーを連れて行く、操作'previous'の合図を提示すべきである。 |
search | ユーザーエージェントは、典型的にはユーザーがタイプしたテキストの検索の結果にユーザーを連れて行く、操作「検索」の合図を提示すべきである。 |
send | ユーザーエージェントは、典型的にはテキストをそのテキストのターゲットに配信する、操作'send'の合図を提示すべきである。 |
このセクションは、ページ内検索を定義する。これは、ユーザーが特定の情報に対してページのコンテンツを検索できるようにする一般的なユーザーエージェントのメカニズムである。
ページ内検索機能へのアクセスは、ページ内検索インターフェイスを介して提供される。これはユーザーエージェントが提供するユーザーインターフェイスであり、ユーザーが入力と検索のパラメーターを指定できるようする。このインターフェイスは、ショートカットまたはメニュー選択の結果として表示される。
ページ内検索インターフェイスのテキスト入力と設定の組み合わせは、ユーザーのクエリーを表す。これは通常、ユーザーが検索したいテキストと、オプションの設定（例えば、検索を単語に限定する機能など）が含まれる。
ユーザーエージェントは、与えられたクエリーのページコンテンツを処理し、0個以上のマッチを識別する。これはユーザークエリーを満たすコンテンツ範囲である。
マッチの1つがアクティブなマッチとしてユーザーに識別される。 それはハイライトされ、スクロールして表示される。ユーザーは、ページ内検索インターフェイスを使用してアクティブなマッチを前進させることにより、マッチをナビゲートできる。
Issue #3539は、ページ内検索が現在指定されていないwindow.find() APIの基礎となる方法の標準化を追跡する。
ページ内検索プロセスは、文書のコンテキストで呼び出され、その文書の選択に影響を与えることがある。 具体的には、アクティブなマッチを定義する範囲が、現在の選択を決定することがある。しかし、この選択の更新は、ページ内検索プロセスのさまざまな時点で発生することがある（たとえば、ページ内検索インターフェイスの終了時、またはアクティブなマッチの範囲の変更時）。