フォームコントロールに共通な属性

4.10.19 フォームコントロールに共通な属性

4.10.19.1 フォームコントロールの名前付け: name 属性

name コンテント属性は、フォームコントロールの名前を与えます。これは、フォームサブミットform 要素の elements オブジェクトで使われます。この属性が指定される場合、その値は空文字列であってはいけません。

name には、空でない値なら何でも許されます。しかし、"_charset_" と "isindex" という名前は特別に扱われます:

isindex

この値を使うと、application/x-www-form-urlencoded メカニズムを使ってサブミットされるフォームの中で最初のコントロールとなる Text コントロールの名前として使われるなら、このコントロールの値のみを入れてサブミットすることになります。名前は使われません。

_charset_

この値は、value 属性を持たない Hidden コントロールの名前として使われるなら、サブミット中に、サブミットの文字エンコーディングから構成される値が自動的に与えられます。

name IDL 属性は、name コンテント属性を反映しなければいけません。

4.10.19.2 要素の方向性のサブミット: dirname 属性

フォームコントロール要素の dirname 属性によって、その要素の方向性をサブミットできるようにし、 フォームサブミットの際にこの値を入れるフィールドの名前を与えます。この属性が指定されたら、その値は空文字列であってはいけません。

この例では、フォームにテキストフィールドとサブミットボタンがあります:

<form action="addcomment.cgi" method=post>
 <p><label>コメント: <input type=text name="comment" dirname="comment.dir" required></label></p>
 <p><button name="mode" type=submit value="add">コメントを投稿</button></p>
</form>

ユーザーがこのフォームをサブミットするとき、ユーザーエージェントは 3 つのフィールドを入れます。"comment" と呼ばれるもの、"comment.dir" と呼ばれるもの、そして、"mode" と呼ばれるものです。そのため、ユーザーが "Hello" と入力したら、そのサブミットの本体は、次のようなものになるでしょう:

comment=Hello&comment.dir=ltr&mode=add

ユーザーが右から左への書式方向に手動で変更し、"مرحبا" と入力したら、このサブミットの本体は次のようになるでしょう:

comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl&mode=add
4.10.19.3 ユーザー入力長の制限: maxlength 属性

フォームコントロールの maxlength 属性、これは dirty value flag によって制御されるものですが、ユーザーが入力できる文字数の制限を宣言します。

要素にフォームコントロール maxlength 属性を指定するなら、その属性の値は、妥当な非負整数でなければいけません。この属性が指定され、非負整数パース手順をその値に適用した結果が数値なら、その数値が、その要素の最大許容データ長となります。この属性が省略されたり、値をパースしたらエラーになる場合は、最大許容データ長はないということになります。

制約バリデーション: 要素が最大許容データ長を持ち、その dirty value flag が true で、そのがユーザー編集(スクリプトによる変更ではありません)によって最後に変更され、その要素のコードユニット長がその要素の最大許容データ長より大きければ、その要素は、データ長超過状態に陥っていることになります。

ユーザーエージェントは、ユーザーに対して、コードユニット長がその要素の最大許容データ長より大きい値を、その要素のにセットできないようにすることができます。

4.10.19.4 最小入力長要件の設定: minlength 属性

フォームコントロールの minlength 属性は、dirty value flag によって制御されますが、ユーザーが入力することができる文字の数の下限を宣言します。

minlength 属性は required 属性の意味合いを持ちません。フォームコントロールが minlength 属性を持っていなかったとしても、その値は省略することができます。minlength 属性は、ユーザーが値を入力したときだけに機能します。もし空文字列が許されないのであれば、required 属性もセットする必要があります。

要素にフォームコントロールの minlength 属性を指定するなら、その属性の値は妥当な非負整数でなければいけません。この属性が指定され、非負整数パース手順をその値に適用した結果が数値なら、その数値が、その要素の最小許容データ長になります。この属性が省略されたり、値をパースしたらエラーになる場合は、最小許容データ長はないということになります。

要素が最大許容データ長最小許容データ長の両方を持つ場合、最小許容データ長最大許容データ長より小さいか同じでなければいけません。

制約バリデーション: 要素が最小許容データ長を持ち、そのが空文字列ではなく、その要素の値のコードユニット長最小許容データ長より小さいなら、その要素は、データ長不足状態に陥っていることになります。

この例では、4 つのテキストフィールドがあります。1 つ目は必須で、少なくとも 5 文字でなければいけません。残りの 3 つは任意ですが、ユーザーは入力するなら、少なくとも 10 文字を入力しなければいけません。

<form action="/events/menu.cgi" method="post">
 <p><label>イベントの名前: <input required minlength=5 maxlength=50 name=event></label></p>
 <p><label>朝食に何かご希望があれば記入してください:
    <textarea name="breakfast" minlength="10"></textarea></label></p>
 <p><label>昼食に何かご希望があれば記入してください:
    <textarea name="lunch" minlength="10"></textarea></label></p>
 <p><label>夕食に何かご希望があれば記入してください:
    <textarea name="dinner" minlength="10"></textarea></label></p>
 <p><input type=submit value="リクエストを送信"></p>
</form>
4.10.19.5 フォームコントロールの有効化と無効化: disabled 属性

disabled コンテント属性は、論理属性です。

フォームコントロールに disabled 属性がセットされている、または、そのフォームコントロールは disabled 属性がセットされた fieldset 要素の子孫で、その fieldset 要素の子となる最初の legend 要素の子孫でないなら、そのフォームコントロールは無効です。

無効となったフォームコントロールは、ユーザーインタラクション・タスクソースキューイングされる click イベントがその要素上で送出されないようにしなければいけません。

制約バリデーション: 要素が無効なら、制約バリデーションから除外されます。

The disabled IDL 属性は、disabled コンテント属性を反映しなければいけません。

4.10.19.6 フォームのサブミット

フォームのサブミット用の属性は、form 要素とサブミットボタン(フォームをサブミットするボタンを表す要素で、例えば、type 属性が submit buttons 状態にある input 要素など)のどちらにも指定することができます。

form 要素で指定できるフォームのサブミット用の属性は、action, enctype, method, novalidate, target です。

サブミットボタンに指定できるフォームのサブミット用の属性は、formaction, formenctype, formmethod, formnovalidate, formtarget です。省略されたら、それぞれに対応する form 要素の属性に指定された値がデフォルトとなります。


actionformaction コンテント属性が指定されたら、その値は潜在的にスペースで囲まれた空でない妥当なURL でなければいけません。

要素の アクション とは、もし、その要素がサブミットボタンformaction 属性を持つなら、その属性の値となり、フォームオーナーaction 属性を持つなら、その値となり、そして、いずれでもなければ、空文字列となります。


methodformmethod コンテント属性は、次のキーワードと状態を伴った列挙属性です:

  • キーワード get は、状態 GET にマッピングされ、HTTP GET メソッドのことを指します。
  • キーワード post は、状態 POST にマッピングされ、HTTP POST メソッドのことを指します。

これらの属性の値が妥当でない場合のデフォルトは、GET 状態です。method 属性に対する値が指定されなかった場合のデフォルトGET 状態です。(formmethod 属性に対する値が指定されなかった場合のデフォルトはありません。)

要素の メソッド とは、これらの状態のうちのひとつになります。要素がサブミットボタンで、formmethod 属性を持つなら、その要素のメソッドは、その属性の状態となります。なければ、それは、フォームオーナーmethod 属性の状態となります。

ここでは、method 属性を使って、明示的にデフォルトの値 "get" を指定しています。これによって、検索クエリが URL に入れられてサブミットされます:

<form method="get" action="/search.cgi">
 <p><label>検索語: <input type=search name=q></label></p>
 <p><input type=submit></p>
</form>

一方こちらでは、method 属性を使って、値 "post" を指定することで、ユーザーのメッセージが HTTP リクエストの本体に入れられてサブミットされます:

<form method="post" action="/post-message.cgi">
 <p><label>メッセージ: <input type=text name=m></label></p>
 <p><input type=submit value="メッセージを送信"></p>
</form>

enctypeformenctype コンテント属性は、次のキーワードと状態を伴った列挙属性です:

  • "application/x-www-form-urlencoded" キーワードと、それに対応する状態
  • "multipart/form-data" キーワードと、それに対応する状態
  • "text/plain" キーワードと、それに対応する状態

これらの属性の値が妥当でない場合のデフォルトは、application/x-www-form-urlencoded 状態です。enctype 属性に対する値が指定されなかった場合のデフォルトapplication/x-www-form-urlencoded 状態です。(formenctype 属性に対する値が指定されなかった場合のデフォルトはありません。)

要素の enctype とは、これら 3 つの状態のいずれかです。要素がサブミットボタンformenctype 属性を持つなら、その要素の enctype は、その属性の状態となります。なければ、それは、フォームオーナーenctype 属性の状態となります。


targetformtarget コンテント属性が指定されたら、その値は、妥当なブラウジングコンテキスト名またはキーワードでなければいけません。

要素の ターゲット は、その要素がサブミットボタンformtarget 属性を持つなら、その属性の値となり、フォームオーナーtarget 属性を持っていれば、その値となり、Documenttarget 属性を持った base 要素があれば、そのうち最初の base 要素の target 属性の値となり、そのような要素がなければ、空文字列となります。


novalidateformnovalidate コンテント属性は、 論理属性です。もしこの属性が存在すれば、そのフォームはサブミット中にバリデートされないことを表します。

要素の非バリデート状態は、その要素がサブミットボタンformnovalidate 属性が存在する、または、その要素のフォームオーナーnovalidate 属性が存在したら、true となります。そうでなければ、false となります。

この属性は、バリデーション制約を持つフォーム上に "保存" ボタンを入れるのに役立ちます。ユーザーは、そのフォームのすべてに入力し終わっていなくても、その途中段階の状態を保存しておくことができます。次の例は、2 つの必須フィールドがある簡単なフォームを示しています。ボタンが 3 つあります。1 つはフォームをサブミットするボタンで、両方のフィールドの入力を必須にします。もう 1 つはフォームを保存するボタンです。これは、ユーザーが後に戻ってきても入力した状態が再現できるようにします。最後はフォームをまとめてキャンセルするボタンです。

<form action="editor.cgi" method="post">
 <p><label>名前: <input required name=fn></label></p>
 <p><label>エッセー: <textarea required name=essay></textarea></label></p>
 <p><input type=submit name=submit value="エッセーを送信"></p>
 <p><input type=submit formnovalidate name=save value="エッセーを保存"></p>
 <p><input type=submit formnovalidate name=cancel value="キャンセル"></p>
</form>

action IDL 属性は、同じ名前のコンテント属性を反映しなければいけません。ただし、取得時において、このコンテント属性がない、または、その値が空文字列だった場合は除きます。その場合は、ドキュメントのアドレスが代わりに返されなければいけません。target IDL 属性は、同じ名前のコンテント属性を反映しなければいけません。methodenctype IDL 属性は、それぞれ同じ名前のコンテント属性を反映しなければいけません。ただし、既知の値のみに限定されます。encoding IDL 属性は、enctype コンテント属性を反映しなければいけません。ただし、既知の値のみに限定されます。noValidate IDL 属性は、novalidate コンテント属性を反映しなければいけません。formAction IDL 属性は、formaction コンテント属性を反映しなければいけません。ただし、取得時において、このコンテント属性がない、または、その値が空文字列だった場合は除きます。その場合は、ドキュメントのアドレスが代わりに返されなければいけません。formEnctype IDL 属性は、formenctype コンテント属性を反映しなければいけません。ただし、既知の値のみに限定されます。formMethod IDL 属性は、formmethod コンテント属性を反映しなければいけません。ただし、既知の値のみに限定されます。formNoValidate IDL 属性は、formnovalidate コンテント属性を反映しなければいけません。formTarget IDL 属性は、formtarget コンテント属性を反映しなければいけません。

4.10.19.7 フォームコントロールのオートフォーカス: autofocus 属性

autofocus コンテント属性を使うと、ウェブ制作者は、ページがロードされたらできる限り早く、そのコントロールにフォーカスするよう指示することができます。ユーザーは、手動でメインのコントロールにフォーカスしなくても、入力を開始することができるようになります。

autofocus 属性は論理属性です。

要素の直近祖先のオートフォーカス・スコピーピング・ルート要素とは、その要素のルート要素のことです。

同じ直近祖先のオートフォーカス・スコーピング・ルート要素を持つ autofocus 属性が指定された要素は 2 つあってはなりません。

autofocus 属性が指定された要素がドキュメントに挿入されたら、ユーザーエージェントは、次の手順を実行するべきです:

  1. target を該当の要素の Document とします。

  2. targetブラウジングコンテキストを持たなければ、これらの手順を中止します。

  3. targetブラウジングコンテキストトップレベル・ブラウジングコンテキストがなければ(例えば、それが親ブラウジングコンテキストを持たないネストされたブラウジングコンテキストだった場合)、これらの手順を中止します。

  4. targetアクティブサンドボックス・フラグセットサンドボックス化自動機能ブラウジングコンテキスト・フラグを持つなら、これらの手順を中止します。

  5. targetオリジンが、targetトップレベル・ブラウジングコンテキストの中で、その時点でフォーカスがあたっている要素の Documentオリジンと同じでないなら、これらの手順を中止します。

  6. targetオリジンが、targetトップレベル・ブラウジングコンテキストアクティブドキュメントオリジンと同じでないなら、これらの手順を中止します。

  7. 要素が、トップレベル・ブラウジングコンテキストアクティブドキュメントtargetトップレベル・ブラウジングコンテキストアクティブドキュメントと同じとなる Document挿入される際に、ユーザーエージェントがすでにこの手順リストの最後に到達したなら、これらの手順を中止します。

  8. ユーザーが、フォーカスを変更したくないことを示したなら(例えば、フォームコントロールに入力し始めるなど)、随意にこれらの手順を中止します。

  9. 要素がフォーカス可能かどうかをチェックするタスクをキューイングします。もしそうなら、その要素に対してフォーカス手順を実行します。ユーザーエージェントは、ドキュメントのスクロール位置を変更することもできます。または、その要素にユーザーの注意を引くための何かしらのアクションを実行することができます。このタスクのタスクソースは、ユーザーインタラクション・タスクソースです。

これは、ドキュメントのロードの間に、自動的なフォーカスを処理します。

コントロールにフォーカスするといっても、フォーカスを失ったら、ユーザーエージェントはブラウザーウィンドウにフォーカスしなければならない、ということを意味しているわけではありません。

autofocus IDL 属性は、同じ名前のコンテント属性を反映しなければいけません。

次のコードでは、ドキュメントがロードされたとき、テキストコントロールにフォーカスが当たるでしょう。

<input maxlength="256" name="q" value="" autofocus>
<input type="submit" value="検索">
4.10.19.8 フォームコントロールの自動入力: autocomplete 属性

ユーザーエージェントは、たとえば、以前の入力に基づいて、ユーザーのアドレスを事前に入力された状態にするなど、ユーザーのフォーム入力を助ける機能を持つことがあります。autocomplete コンテント属性は、ユーザーエージェントに、そういった機能をどのように提供するのか、または、実際に提供するのかしないのかについて示唆するために使うことができます。

この属性は、存在するなら、文字列 "off" に大文字と小文字を区別せずに一致する値、または、文字列 "on" に大文字と小文字を区別せずに一致するひとつのトークンを持たなければいけません。

"off" キーワードは、そのコントロールの入力データはとりわけセンシティブである(たとえば、核兵器の起動コード)、または、それは決して再利用されることはない値(たとえば、銀行のログインに使うワンタイムキー)であり、それゆえにユーザーは、UA がその値を事前に入力した状態にしてくれることに頼らずに、毎度その値を明示的に入力しなければいけない、または、そのドキュメント自体が自動入力メカニズムを提供するため、ユーザーエージェントには自動補完された値を提供してほしくない、のいずれかを指し示します。

"on" キーワードは、ユーザーエージェントはユーザーに自動補完値を提供することが許されているが、ユーザーが入力すると期待されるデータがどんなものなのかに関する追加の情報を提供しないことを指し示します。ユーザーエージェントは、どんな自動補完値を提示するべきかを決定するために、経験則を使わなければならないでしょう。

autocomplete 属性が省略されたら、その要素のフォームオーナーautocomplete 属性の状態に相当するデフォルト値が使われます("on" または "off")。フォームオーナーがなければ、値 "on" が使われます。

要素の自動入力フィールド名が "off" のとき、ユーザーエージェントは、そのコントロールのを記憶するべきではありません。そして、ユーザーに過去の値を提示するべきではありません。

さらに、要素の自動入力フィールド名が "off" なら、履歴をたどる際に、値はリセットされます。

銀行はしばしば UA にログイン情報を事前入力してほしくないと考えます:

<p><label>口座: <input type="text" name="ac" autocomplete="off"></label></p>
<p><label>PIN: <input type="password" name="pin" autocomplete="off"></label></p>

要素の自動入力フィールド名が "off" でないとき、ユーザーエージェントは、そのコントロールのを保存して、ユーザーに保存した値を事前に提供することができます。

自動入力フィールド名が "on" のとき、ユーザーエージェントは、ユーザーに提供するべき最も適した値を決定するために経験則を使うべきです。たとえば、その要素の name の値や、ドキュメントの DOM の中における該当要素の位置や、そのフォームには他にどんなフィールドが存在するのか、などを基準にします。

自動補完メカニズムは、あたかもユーザーがその要素のを変更したかのように振る舞うよう、ユーザーエージェントによって実装されなければいけません。そして、その要素がミュータブルであるときに実行されなければいけません(たとえば、その要素がドキュメントに挿入された直後や、ユーザーエージェントがパース処理を停止しているとき)。ユーザーエージェントは、ユーザーが入力したであろう値を使ってコントロールを事前入力するだけにとどめなければいけません。

フォームコントロールのを事前入力するユーザーエージェントは、そのコントロールが、タイプ不一致に陥るパターン不一致に陥るデータ長超過に陥るデータ長不足に陥るアンダーフローに陥るオーバーフローに陥るステップ不一致に陥る、ことがないようにしなければいけません。コントロールの制約が与えられる可能性があるところでは、ユーザーエージェントは、前述の表で基準として示された形式を使わなければいけません。その基準形式の仕様が不可能なところでは、ユーザーエージェントは、経験則を使って値の変換を試みて、それらを使えるようにするべきです。

ユーザーエージェントは、ユーザーが要素の自動入力フィールド名を無視できるようにすることができます。たとえば、それを "off" から "on" に変更して、値を記憶できるようにして、そのページ製作者の意に反しながらも事前入力できるようにしたり、常に "off" にして、値を絶対に記憶させないようにすることができます。しかし、ユーザーエージェントは、ユーザーが自動入力フィールド名を "off" から "on" や他の値に手軽に変更できるようにするべきではありません。なぜなら、もしサイトの意向を無視して、すべての値が常に記憶されるとしたら、ユーザーにとって重大なセキュリティの影響がでてくるからです。

autocomplete IDL 属性は、取得の際には、該当の要素の IDL-exposed 自動入力値を返さなければいけません。セットの際には、同じ名前のコンテント属性を反映しなければいけません。


※ 原文:http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#attributes-common-to-form-controls