目次
HTMLのフォームは、文書の一部分を成し、通常の内容とマーク付け、そしてコントロールと呼ばれる特別な要素、更にこれらコントロールのラベルを含む。コントロールにはチェックボックス、ラジオボタン、メニューなどがある。 ユーザは一般に、テキストを追加する、メニュー項目を選ぶ、等してこれらコントロールを変更してフォームを「完成」させ、その後フォーム処理のためにWebサーバやメールサーバ等のエージェントへとフォームを提出する。
次に、ラベル、ラジオボタン、押しボタンを備えた簡単なフォームの例を示す。押しボタンは【記入内容を】リセットするか提出するかに用いるものである。
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="firstname">名: </LABEL> <INPUT type="text" id="firstname"><BR> <LABEL for="lastname">姓: </LABEL> <INPUT type="text" id="lastname"><BR> <LABEL for="email">email: </LABEL> <INPUT type="text" id="email"><BR> <INPUT type="radio" name="sex" value="Male"> 男性<BR> <INPUT type="radio" name="sex" value="Female"> 女性<BR> <INPUT type="submit" value="送る"> <INPUT type="reset"> </P> </FORM>
注意。 本仕様書は、フォームの表示に関する小節に、詳細情報を含む。
コントロールの“コントロール名”は、 name属性で名づける。 あるFORM要素にあるコントロールのname属性の有効範囲は、そのFORM要素に限られる。
各コントロールは、初期値と現在値とを1つずつ持ち、この値は文字列である。初期値の詳細と、コントロールの値に適用可能な制約については、各コントロールの定義を参照されたい。 一般的には、コントロールの “初期値”は当該コントロール要素の value属性で指定され得る。 しかし、 TEXTAREA要素の初期値は、その内容によって与えられ、フォームのOBJECT要素の初期値は当該オブジェクト実装によって決まる。すなわち、本仕様の範囲外である。
コントロールの“現在値”は、まず初期値に設定される。この後、ユーザの操作やスクリプトによって変更され得る。
コントロールの初期値は不変である。 従って、フォームがリセットされた場合、各コントロールの現在値は初期値へと設定し直される。初期値が設定されていないコントロールにおけるリセットの効力については、定義しない。
フォームが処理のために提出される際に現在値と組になる名をもつコントロールがあり、この組合せが当該フォームで提出される。 この名前/値組で提出されるコントロールを、 満足なコントロールと呼ぶ。
HTMLでは次のコントロール形式を定義する。
HTML著者は、押しボタンのスクリプトに用いるスクリプト言語を、META要素によるデフォルトスクリプト宣言で指定する必要がある。
著者は、BUTTON要素かINPUT要素のどちらかでボタンを作成する。 各種ボタン形式の指定について、詳細は各要素の定義を参照のこと。
1つのフォームで複数のチェックボックスが同じコントロール名を共有してよい。こうしたチェックボックスは、例えば、ユーザが1つのプロパティについて複数の値を選ぶことを許容する。 チェックボックスコントロールの作成には、 INPUT要素を用いる。
複数のラジオボタンの中で、常に1つがチェックされた状態となる。ラジオボタンコントロール群の<INPUT>要素に`CHECKED'と設定されたものが存在しない場合、ユーザエージェントは初期値として群の最初のラジオボタンを“on”の状態にしなければならない。
ユーザエージェントの動作が現実にはこうならないため、著者は各ラジオボタン群につき1つの初期値を確実に“on”にしておく必要がある。
コントロールを作成する要素は、一般的には FORM要素内に出現するが、ユーザインターフェイス構築目的の場合には、 FORM要素宣言の外部にも出現し得る。 これについては 組込みイベントの項で述べる。フォームの外部にあるコントロールは 満足なコントロールになり得ない点に注意されたい。
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form --> <!ATTLIST FORM %attrs; -- %coreattrs, %i18n, %events -- action %URI; #REQUIRED -- server-side form handler -- method (GET|POST) GET -- HTTP method used to submit the form-- enctype %ContentType; "application/x-www-form-urlencoded" accept %ContentTypes; #IMPLIED -- list of MIME types for file upload -- name CDATA #IMPLIED -- name of form for scripting -- onsubmit %Script; #IMPLIED -- the form was submitted -- onreset %Script; #IMPLIED -- the form was reset -- accept-charset %Charsets; #IMPLIED -- list of supported charsets -- >
開始タグ: 必須、終了タグ: 必須
属性定義
この属性のデフォルト値は予約文字列「UNKNOWN」(不明)である。ユーザエージェントは、この値を、当該FORM要素を含む文書の伝送に使われた文字符号化方法であるものとしてインタープリトしてよい。
別途定義がある属性
FORM要素は、コントロールの入れ物として働き、次の情報を指定する。
フォームはフォームのコントロールに加えて、テキストやマーク付け(段落、リスト等)を含むことができる。
次の例は、提出後「adduser」プログラムが処理することになるフォームを示す。このフォームはプログラムに対し、HTTPの「POST」メソッドで送られる。
<FORM action="http://somesite.com/prog/adduser" method="post"> ...フォームの内容... </FORM>
ユーザエージェントがサーバに向けてどのようにフォームのデータを準備する必要があるかという点と、起こり得る反応をどのように処理すべきかという点については、フォームの提出に関する項を参照されたい。
注意。 フォームデータを受けるサーバの挙動に関する詳細は、本仕様の範囲外である。
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE | BUTTON)" > <!-- attribute name required for all but submit and reset --> <!ELEMENT INPUT - O EMPTY -- form control --> <!ATTLIST INPUT %attrs; -- %coreattrs, %i18n, %events -- type %InputType; TEXT -- what kind of widget is needed -- name CDATA #IMPLIED -- submit as part of form -- value CDATA #IMPLIED -- Specify for radio buttons and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- for text and passwd -- size CDATA #IMPLIED -- specific to each type of field -- maxlength NUMBER #IMPLIED -- max chars for text fields -- src %URI; #IMPLIED -- for fields with images -- alt CDATA #IMPLIED -- short description -- usemap %URI; #IMPLIED -- use client-side image map -- ismap (ismap) #IMPLIED -- use server-side image map -- tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onselect %Script; #IMPLIED -- some text was selected -- onchange %Script; #IMPLIED -- the element value was changed -- accept %ContentTypes; #IMPLIED -- list of MIME types for file upload -- >
開始タグ: 必須、終了タグ: なし
属性定義
他に定義のある属性
INPUT要素で定義するコントロールの形式は、type 属性の値に左右される。
注意。 アプリケーション設計者は、この機構が軽いセキュリティ保護しか提供しないことに注意する必要がある。ユーザエージェントは、普通に眺めているだけの人からはパスワードを隠すが、サーバへは通常のテキストとして伝送されるので、ネットワークへの低レベルアクセスで誰もが読み取り可能である。
画像をクリックするためにポインティングデバイスが使われた場合、 フォームが提出されると共にクリック地点の座標がサーバに渡される。x座標値は画像の左側からピクセル単位で計られ、y座標値は画像の上側からピクセル単位で計られる。 提出されるデータには「name.x=x-value」と「name.y=y-value」が含まれ、 この"name"はname属性の値、x-valueとy-valueは各々x・y座標の値である。
仮にクリック地点に応じてサーバの挙動が異なる場合、非グラフィック系ブラウザのユーザが不利益を被る。このため、著者は代替方法を考慮する必要がある。
次のHTML断片では、ユーザによって、姓・名、電子メールアドレス、性別を入力させる簡単なフォームが定義されている。提出ボタンがアクティブにされると、 action属性が指定するプログラムへとフォームが送られる。
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> 名: <INPUT type="text" name="firstname"><BR> 姓: <INPUT type="text" name="lastname"><BR> email: <INPUT type="text" name="email"><BR> <INPUT type="radio" name="sex" value="Male"> 男性<BR> <INPUT type="radio" name="sex" value="Female"> 女性<BR> <INPUT type="submit" value="送る"> <INPUT type="reset"> </P> </FORM>
このフォームは次のようにレンダリングされ得るだろう。
LABEL要素の項で、「姓」などのラベルのマーク付けについて述べる。
今度の例では、onclickイベントの発生によってJavaScriptの「verify」関数が呼び出されるようになっている。
<HEAD> <META http-equiv="Content-Script-Type" content="text/javascript"> </HEAD> <BODY> <FORM action="..." method="post"> <P> <INPUT type="button" value="クリックしてね" onclick="verify()"> </FORM> </BODY>
スクリプトとイベントの詳細は、組込みイベントの項を参照のこと。
次の例では、ユーザ指定ファイルの内容がどのようにフォームで提出され得るかを示す。ユーザは、自分の名前と、当該フォームで内容を送りたいファイルの名前とを入力する。 enctype属性値が"multipart/form-data"に指定されていることにより、各ファイル内容は提出用マルチパート文書の各々独立したセクションへとパッケージ化される。
<FORM action="http://server.dom/cgi/handle" enctype="multipart/form-data" method="post"> <P> あなたのお名前は? <INPUT type="text" name="name_of_sender"> 送りたいファイルは? <INPUT type="file" name="name_of_files"> </P> </FORM>
<!ELEMENT BUTTON - - (%flow;)* -(A|%formctrl;|FORM|FIELDSET) -- push button --> <!ATTLIST BUTTON %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED value CDATA #IMPLIED -- sent to server when submitted -- type (button|submit|reset) submit -- for use as form button -- disabled (disabled) #IMPLIED -- unavailable in this context -- tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- >
開始タグ: 必須、終了タグ: 必須
属性定義
別途定義がある属性
BUTTON要素が生成するボタンとINPUT要素が生成するボタンは、機能的には同等だが、 BUTTON要素の方がレンダリング能力が高い。 BUTTON要素は内容を持てる。例えば、画像を内容に持つBUTTON要素の機能は、type属性が"image"のINPUT要素とそっくり同じだが、BUTTON要素型は内容を持てるのだ。
視覚系ユーザエージェントの場合、BUTTON要素のボタンを、立体的にし、クリック時に上下動するようレンダリングさせるようなものがあるであろう。 これはINPUT要素のボタンを「平面」画像としてレンダリングするであろうこととは対照的である。
次の例は前の例の拡張版で、提出ボタンとリセットボタンを INPUT要素ではなく BUTTON要素で作成している。このボタンは IMG要素による画像を含んでいる。
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> 名: <INPUT type="text" name="firstname"><BR> 姓: <INPUT type="text" name="lastname"><BR> email: <INPUT type="text" name="email"><BR> <INPUT type="radio" name="sex" value="Male"> 男性<BR> <INPUT type="radio" name="sex" value="Female"> 女性<BR> <BUTTON name="submit" value="送る" type="submit"> 送る<IMG src="/icons/wow.gif" alt="ナイス"></BUTTON> <BUTTON name="reset" type="reset"> リセットする<IMG src="/icons/oops.gif" alt="イヤーン"></BUTTON> </P> </FORM>
著者には IMG要素に代替テキストを提供する必要があるということを思い起こされたい。
BUTTONボタン要素の内容であるIMG要素をイメージマップと連携させるのは、 本仕様上不正である。
不正な例:
これは正当なHTMLではない。
<BUTTON> <IMG src="foo.gif" usemap="..."> </BUTTON>
<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> <!ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED -- field name -- size NUMBER #IMPLIED -- rows visible -- multiple (multiple) #IMPLIED -- default is single selection -- disabled (disabled) #IMPLIED -- unavailable in this context -- tabindex NUMBER #IMPLIED -- position in tabbing order -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onchange %Script; #IMPLIED -- the element value was changed -- >
開始タグ: 必須、終了タグ: 必須
SELECT要素の属性定義
他に定義がある属性
SELECT要素はメニューを生成する。 メニュー中の各選択肢はOPTION要素によって提示される。 1つのSELECT要素には最低1つのOPTION要素が含まれている必要がある。
OPTGROUP要素によって、著者は選択項目を論理的にグループ化することができる。グループ化は、ユーザが長大な選択リストから選び出さねばならないような場合に特に有用である。関連項目がグループ化されている方が、単調で長いリストよりも、全体像の把握が容易でかつ覚えやすくなる。HTML 4では、どの OPTGROUP要素もSELECT要素の直接の子である必要がある(すなわち、グループは入れ子にできない。)
ユーザの便宜を計るため、選択肢を事前選択しておいてもよい。ユーザエージェントは、どの選択肢が選択済みかを次のように決定する必要がある。
どの<OPTION>要素にもSELECTED属性が存在しない場合、第一番目の選択肢が選択済み初期値となる。
ユーザエージェントの挙動がこれとは異なるため、著者は各メニューがデフォルトで選択済みのOPTION要素を1つ含むようにする必要がある。
<!ELEMENT OPTGROUP - - (OPTION)+ -- option group --> <!ATTLIST OPTGROUP %attrs; -- %coreattrs, %i18n, %events -- disabled (disabled) #IMPLIED -- unavailable in this context -- label %Text; #REQUIRED -- for use in hierarchical menus -- >
開始タグ: 必須、終了タグ: 必須
別途定義がある属性
注意。 実装者に対する助言。HTMLの将来の版では、入れ子のグループを許容するようなグループ化機構の拡張があり得る。(すなわち、 OPTGROUP要素が入れ子になり得る。) これによって著者が選択肢をより強力に階層化して表現できるようになる。
<!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> <!ATTLIST OPTION %attrs; -- %coreattrs, %i18n, %events -- selected (selected) #IMPLIED disabled (disabled) #IMPLIED -- unavailable in this context -- label %Text; #IMPLIED -- for use in hierarchical menus -- value CDATA #IMPLIED -- defaults to element content -- >
開始タグ: 必須、終了タグ: オプション
OPTION要素の属性定義
別途定義がある属性
メニュー選択をレンダリングする場合、ユーザエージェントは選択項目としてOPTION要素のlabel属性値を、用いる必要がある。この属性が指定されていない場合、ユーザエージェントはOPTION要素の内容を選択項目として用いねばならない。
OPTGROUP要素のlabel属性は、選択グループのラベルを指定する。
次の例では、7つのソフトウエアコンポーネントからどれをインストールするかをユーザに選択させられるメニューが用意されている。第1・第2項目が選択済みになっているが、これはユーザによって選び直され得る。残りの5項目は選択済みではない。 size属性は、7項目から選択するにも関わらず同時に4行しかメニュー表示されないことを示している。 他の3項目はスクロール機構によって利用できるようにされる必要がある。
SELECT要素に続いて、提出ボタンとリセットボタンがある。
<FORM action="http://somesite.com/prog/component-select" method="post"> <P> <SELECT multiple size="4" name="component-select"> <OPTION selected value="Component_1_a">Component_1</OPTION> <OPTION selected value="Component_1_b">Component_2</OPTION> <OPTION>Component_3</OPTION> <OPTION>Component_4</OPTION> <OPTION>Component_5</OPTION> <OPTION>Component_6</OPTION> <OPTION>Component_7</OPTION> </SELECT> <INPUT type="submit" value="送る"><INPUT type="reset"> </P> </FORM>
選択された項目だけが、(コントロール名 "component-select" との組合せにより)満足となる。どの項目も選ばれなかった場合、当該コントロールは満足とならず、またフォーム提出の際にコントロールの名前も値もサーバへ送られない。 value属性がどこかに設定されていればそれが当該コントロールの初期値となり、設定されていなければ当該要素の内容が初期値であるということに、注意されたい。
次の例ではOPTGROUP要素を用いてグループ選択を実現している。
<FORM action="http://somesite.com/prog/someprog" method="post"> <P> <SELECT name="ComOS"> <OPTION selected label="none" value="none">None</OPTION> <OPTGROUP label="PortMaster 3"> <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1</OPTION> <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7</OPTION> <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="PortMaster 2"> <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7</OPTION> <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="IRX"> <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R</OPTION> <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R</OPTION> </OPTGROUP> </SELECT> </FORM>
上記のマーク付けは、次のグループ化を表現している。
None PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 IRX 3.7R 3.5R
視覚系ユーザエージェントの場合、ユーザは、階層化メニューか、グループ選択の構造を反映する他の機構によって、グループ選択を行えるようになるだろう。
グラフィック系ユーザエージェントは、次のようにレンダリングするであろう。
この画像は、SELECT要素が段階的メニューとしてレンダリングされている状態を示している。最上位のメニューは現在選択されている値(PortMaster 3, 3.7.1)を表示している。 ユーザは2つの段階メニューを開いているが、まだ新しい値(PortMaster 2, 3.7)を選んではいない。どの段階メニューも OPTGROUP要素かOPTION要素のラベルを表示していることに注意されたい。
<!ELEMENT TEXTAREA - - (#PCDATA) -- multi-line text field --> <!ATTLIST TEXTAREA %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED rows NUMBER #REQUIRED cols NUMBER #REQUIRED disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onselect %Script; #IMPLIED -- some text was selected -- onchange %Script; #IMPLIED -- the element value was changed -- >
開始タグ: 必須、終了タグ: 必須
属性定義
別途定義がある属性
TEXTAREA要素は、複数行のテキスト入力コントロールを生成する。 ユーザエージェントは要素の内容を当該コントロールの初期値とする必要があり、最初にこれをレンダリングしなければならない。
次の例では、大きさが20行80列で、2行の初期テキストを含む TEXTAREA要素が用いられている。 TEXTAREA要素に続けて提出ボタンとリセットボタンがある。
<FORM action="http://somesite.com/prog/text-read" method="post"> <P> <TEXTAREA name="thetext" rows="20" cols="80"> 初期テキストの第一行。 初期テキストの第二行。 </TEXTAREA> <INPUT type="submit" value="送る"><INPUT type="reset"> </P> </FORM>
readonly属性を設定することで、著者は書き換えられないテキストをTEXTAREA要素に記すことができる。 文書中の通常のマーク付けテキストとの違いは、TEXTAREAの値は他のフォームデータと共に提出されるという点である。
ISINDEX要素は推奨されない。 1行だけのテキスト入力コントロールを生成する要素である。 テキスト入力コントロールを生成する場合、著者はINPUT要素を用いる必要がある。
正式な定義は移行型DTDを参照のこと。
ISINDEX要素は、1行だけのテキスト入力コントロールを作成し、この行には何文字あっても構わない。ユーザエージェントはprompt属性の値をプロンプトの表題として利用できる。
推奨しない例:
このようなISINDEX宣言は、
<ISINDEX prompt="検索語を入力してください: ">
INPUT要素で次のように書き換えられる。
<FORM action="..." method="post"> <P>検索語を入力してください: <INPUT type="text"></P> </FORM>
ISINDEXのセマンティクス。 現在のところ、 ISINDEXのセマンティクスは、当該文書の基準URIがHTTPスキームのURIである場合に関してのみ明確化されている。 実用上、URIはLatin-1以外の文字集合を指定できないので、入力文字列はLatin-1に限られる。
コントロールには、押しボタンのように自動的にラベル付けられるものもあるが、テキスト入力やチェックボックス、ラジオボタン、メニューなど殆どのコントロールはそうではない。
暗示的ラベルを持つコントロールについては、ユーザエージェントはvalue属性値をラベル文字列として用いる必要がある。
暗示的ラベルを持たないコントロールのラベルを指定するのには、 LABEL要素を用いる。
<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- form field label text --> <!ATTLIST LABEL %attrs; -- %coreattrs, %i18n, %events -- for IDREF #IMPLIED -- matches field ID value -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- >
開始タグ: 必須、終了タグ: 必要
属性定義
別途定義がある属性
LABEL要素は、コントロールに追加情報を与えるために利用できる。どの LABEL要素も、他のただ1つのコントロールと結びつく。
for属性はラベルを他のコントロールと明示的に結びつける。 for属性の値は結びつくコントロールの要素の id属性値と同値でなければならない。 このfor属性を用いることで、ある特定のコントロールに対し複数の LABEL要素を結びつけることができる。
次の例は、2つのテキスト入力コントロールと、その各々に結びつくラベルとを配置する表を作るものだ。各ラベルは、各々1つのテキスト入力と明示的に結びつけられている。
<FORM action="..." method="post"> <TABLE> <TR> <TD><LABEL for="fname">名</LABEL> <TD><INPUT type="text" name="firstname" id="fname"> <TR> <TD><LABEL for="lname">姓</LABEL> <TD><INPUT type="text" name="lastname" id="lname"> </TABLE> </FORM>
次の例は、LABEL要素を含むように上の例を拡張したものである。
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="firstname">名: </LABEL> <INPUT type="text" id="firstname"><BR> <LABEL for="lastname">姓: </LABEL> <INPUT type="text" id="lastname"><BR> <LABEL for="email">email: </LABEL> <INPUT type="text" id="email"><BR> <INPUT type="radio" name="sex" value="Male"> 男性<BR> <INPUT type="radio" name="sex" value="Female"> 女性<BR> <INPUT type="submit" value="送る"> <INPUT type="reset"> </P> </FORM>
ラベルを他のコントロールと暗示的に結びつけるには、結びつくコントロールをLABEL要素の子とする必要がある。 この場合、LABEL要素は1つのコントロールしか子にできない。ラベルそれ自体【であるLABEL要素の内容】は、結びつくコントロールの前後どちらにあってもよい。
次の例では、2つのテキスト入力コントロールに対し、2つのラベルが暗示的に結びつけられている。
<FORM action="..." method="post"> <P> <LABEL> 名 <INPUT type="text" name="firstname"> </LABEL> <LABEL> <INPUT type="text" name="lastname"> 姓 </LABEL> </P> </FORM>
暗示的ラベルづけのテクニックは、レイアウト目的で表を使いラベルとコントロールとを別々のセルに配置した場合には使えないということに注意されたい。
LABEL要素がフォーカスを受けた場合、結びついているコントロールにフォーカスが渡される。後述するアクセスキーの例示を参照のこと。
ラベルはユーザエージェントによって様々な方法でレンダリングされる。例えば、視覚的な表示や、音声合成装置による読み上げ、等々。
<!-- #PCDATA is to solve the mixed content problem, per specification only whitespace is allowed there! --> <!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group --> <!ATTLIST FIELDSET %attrs; -- %coreattrs, %i18n, %events -- > <!ELEMENT LEGEND - - (%inline;)* -- fieldset legend --> <!ATTLIST LEGEND %attrs; -- %coreattrs, %i18n, %events -- accesskey %Character; #IMPLIED -- accessibility key character -- >
開始タグ: 必須、終了タグ: 必須
LEGEND要素の属性定義
別途定義がある属性
FIELDSET要素を使うと、著者はテーマ的に関連しあっているコントロールとラベルとをグループ化することができる。 グループ化されたコントロールは、視覚系ユーザエージェントならタブキーでの移動、音声出力環境なら音声入力による項目移動の機能と連動していると、よりその意図が利用者から理解されやすくなる。この要素を適切に用いると、文書のアクセス性は高まる。
LEGEND要素を使うと、著者は FIELDSETに説明書をつけることができる。 説明書きがあると、 FIELDSET要素が非視覚的にレンダリングされる際により分かりやすくなる。
次の例では、医者にかかる際に記入するようなフォームを用意した。このフォームは、個人情報、病歴、服用中の薬の3つのパートに別れている。どのパートにも、各パートに対して適切な情報を入力するコントロールが含まれている。
<FORM action="..." method="post"> <P> <FIELDSET> <LEGEND>個人情報</LEGEND> 姓: <INPUT name="personal_lastname" type="text" tabindex="1"> 名: <INPUT name="personal_firstname" type="text" tabindex="2"> 住所: <INPUT name="personal_address" type="text" tabindex="3"> …個人情報欄続く… </FIELDSET> <FIELDSET> <LEGEND>病歴</LEGEND> <INPUT name="history_illness" type="checkbox" value="Smallpox" tabindex="20"> 天然痘 <INPUT name="history_illness" type="checkbox" value="Mumps" tabindex="21"> おたふく風邪 <INPUT name="history_illness" type="checkbox" value="Dizziness" tabindex="22"> 目眩 <INPUT name="history_illness" type="checkbox" value="Sneezing" tabindex="23"> せき・くしゃみ …病歴欄続く… </FIELDSET> <FIELDSET> <LEGEND>服用中の薬</LEGEND> Are you currently taking any medication? <INPUT name="medication_now" type="radio" value="Yes" tabindex="35">はい <INPUT name="medication_now" type="radio" value="No" tabindex="35">いいえ 現在服用中の薬がある方は、下の空欄に薬の名前をご記入下さい <TEXTAREA name="current_medication" rows="20" cols="50" tabindex="40"> </TEXTAREA> </FIELDSET> </FORM>
上の例にスタイルシートを適用して各FIELDSET要素の子要素の位置合わせや色・フォントの情報を追加したり、スクリプトを加えてユーザが服用中の薬に注目している時点では服用中の薬のテキスト記入領域のみ見せるといった、視覚的表現を強化できるという点に注意されたい。
HTML文書において、ある要素がアクティブになってその機能を果たすためには、まずユーザからフォーカスを受け取る必要がある。例えば、ユーザはA要素のリンクを辿るために、当該要素をアクティブにする必要がある。同様に、TEXTAREAにテキストを入力するには、ユーザはここにフォーカスを合わせる必要がある。
要素にフォーカスを合わせる方法は、様々である。
属性定義
タブ移動順序とは、キーボード操作でユーザが読み進む際に要素がフォーカスを受け取る順番を定義するものである。タブ移動順は、他の要素の子である要素をも含み得る。
ユーザエージェントは、フォーカスを受け得る要素の間を、次の基準に沿って移動する必要がある。
tabindex属性をサポートする要素は、A、 AREA、BUTTON、INPUT、OBJECT、SELECT、 and TEXTAREAである。
次の例では、BUTTON要素、 the INPUT要素の順でタブ移動する。 "field1"のINPUTとBUTTONとが同じtabindex属性値を持っていて、"field1"のINPUTの方が文字列中で後ろになっていることに注意されたい。タブ移動順は、最後に A要素のリンクに移る。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>FORMを伴う文書の例</TITLE> </HEAD> <BODY> …とある文章… <P> <A tabindex="10" href="http://www.w3.org/">W3CのWebサイト</A>に進む …とある文章… <BUTTON type="button" name="get-database" tabindex="1" onclick="get-database"> 現在のデータベースを呼び出す。 </BUTTON> …とある文章… <FORM action="..." method="post"> <P> <INPUT tabindex="1" type="text" name="field1"> <INPUT tabindex="2" type="text" name="field2"> <INPUT tabindex="3" type="submit" name="submit"> </P> </FORM> </BODY> </HTML>
タブ移動に使うキー。 実際にタブ移動や要素のアクティブ化に使われるキー入力は、ユーザエージェントの設定に依存する。例えば「tab」キーで移動し「enter」キーでアクティブにする要素を選ぶ、など。
ユーザエージェントは、タブ移動順を逆に辿るキー入力をも定義し得る。タブ移動で末尾(か冒頭)に達した場合、ユーザエージェントは円環的に冒頭(末尾)に戻るとよいだろう。
属性定義
ある要素に設定されているアクセスキーを押すことで、その要素はフォーカスを受け取る。 フォーカスを受けたことで何が起きるかは、要素が何であるかに依存する。例えば、ユーザが A要素のリンクをアクティブにすると、ユーザエージェントは一般にリンクを辿る。ユーザがラジオボタンをアクティブにすると、ユーザエージェントはラジオボタンの値を変更する。ユーザがテキスト入力欄をアクティブにすると、入力待ちになる、等。
accesskey属性をサポートする要素は、A、 AREA、BUTTON、INPUT、 LABEL、LEGEND、 TEXTAREAである。
次の例では、 INPUTコントロールへのアクセスキーが、結びついているラベルの「U」で示されている。アクセスキーを打鍵すると、いったんラベルがフォーカスを受け取るが、結びついているコントロールへとフォーカスが渡される。これによって、ユーザは INPUT要素の記入欄に入力可能になる。
<FORM action="..." method="post"> <P> <LABEL for="fuser" accesskey="U"> ユーザ名 </LABEL> <INPUT type="text" name="user" id="fuser"> </P> </FORM>
次の例では、A要素にアクセスキーが割り当ててある。このアクセスキーを打鍵すると、ユーザは他の文書、この例では目次へと移動する。
<P><A accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> 目次</A>
アクセスキーの呼び出し方法は、システムに依存する。例えば、MS Windowsのマシンでは一般に、アクセスキーの他に「alt」キーを押す必要がある。Apple【のMacOS】の場合は、一般に「cmd」キーが併用される。
アクセスキーのレンダリング方法はユーザエージェントに依存する。著者は、ラベル文や他のあらゆるアクセスキー適用先に、当該アクセスキーの文字を含めるよう勧められる。ユーザエージェントはアクセスキーの値を、それがアクセスキーであると判るよう他の文字と区別して(下線をつけるなど)レンダリングする必要がある。
ユーザによる入力が望ましくなかったり不適切だったりする場合、コントロールを選択不能にすることや読み出し専用にしておくことが重要である。例えば、ユーザが必要なデータを入力し終えるまでは提出ボタンを押せないようにしたいといったことがあるだろう。同様に、ユーザに読ませたい文章で、かつ他のフォームデータと共に返信されることを望むようなものもあろう。以下の各項では、このような選択不能指定と読み出し専用指定について説明する。
このdisabled属性が設定されると、その要素には次のような効果がある。
disabled属性をサポートする要素は、BUTTON、 INPUT、OPTGROUP、OPTION、SELECT、 and TEXTAREAである。
disabled属性は継承されるが、個々の要素における宣言は継承値を上書きする。
選択不能の要素がどのようにレンダリングされるかは、ユーザエージェントに依存する。例えば、選択不能のメニュー項目やボタンラベルを「ぼかす」ユーザエージェントもあろう。
次の例では、INPUT要素が選択不能とされている。従って、ユーザの入力を受け付けることもなく、またこの値がフォームデータと共に提出されることもない。
<INPUT disabled name="fred" value="stone">
readonly属性は、ユーザによるコントロールの変更を許すかどうかを指定する。
このreadonly属性が設定されると、当該コントロールには次の効果がある。
readonly属性をサポートする要素は、INPUTと TEXTAREAである。
読み出し専用要素がどのようにレンダリングされるかは、ユーザエージェントに依存する。
以下の各項では、ユーザエージェントがどのように処理側エージェントへとフォームデータを提出するのかを説明する。
FORM要素の method属性は、処理エージェントへフォームを送る際のHTTPメソッドを指定する。取り得る値は次の2つ。
getメソッドは、フォームが等羃である場合、すなわち副次作用がない場合にのみ用いるようにしなければならない。データベース検索の多くは目に見える副次作用がなく、getメソッドの理想的応用例となる。
フォーム処理に関連するサービスが、例えばフォームがデータベース更新を伴うなど、副次作用を引き起こすものである場合、postメソッドを利用する必要がある。
注意。 getメソッドの場合、フォームデータ集合の値はASCII文字に限られる。 postメソッドでenctype="multipart/form-data"の場合のみが、[ISO10646]文字集合全体を含み得る指定となる。
満足なコントロールは、提出に「適格」である。満足なコントロールは、どれも、当該コントロール名と現在値との組で、提出されるフォームデータ集合の一部分を成す。 満足なコントロールは FORM要素中で定義されている必要があり、かつコントロール名を持たねばならない。
具体例を述べる。
フォーム提出の際、現在値を持たないコントロールがあれば、ユーザエージェントはこれを満足なコントロールとして扱う必要はない。
更に、ユーザエージェントは、次のようなコントロールを満足であるとしてはいけない。
隠れコントロールやスタイルシートの設定で非表示になっているコントロールは、満足になれる。
<FORM action="..." method="post"> <P> <INPUT type="password" style="display:none" name="invisible-password" value="mypassword"> </FORM>
上に例示したコントロールの値は、コントロール名「invisible-password」と共に組となり、フォームで提出される。
提出ボタンをアクティブにするなどしてユーザがフォームを提出する際、ユーザエージェントは次のようにフォームを処理する。
A フォームデータ集合は、満足なコントロールから構築される、コントロール名/現在値組の成す1つの文字列である。
この段階で、フォームデータ集合は、FORM要素のenctype属性に従って符号化される。
符号化されたデータは、最後の段階で、 action属性が示す処理エージェントへ、method属性が示すプロトコルを通じて送られる。
本仕様は、適格な提出メソッドやフォームで用いるMIMEタイプについて、全てを定義するものではない。しかしながら、HTML 4 ユーザエージェントは、慣習的に確立した下記のすべてをサポートする必要があるものとする。
actionあるいはmethodが他の値だった場合の挙動は定義しない。
ユーザエージェントは、HTTPのgetトランザクションやpostトランザクションの結果をもレンダリングする必要がある。
FORM要素の enctype属性は、フォームデータ集合をサーバへ提出する際に用いるMIMEタイプを指定する。ユーザエージェントは次に示すMIMEタイプをサポートしなければならない。他のMIMEタイプに関する挙動は定義しない。
URI属性値におけるアンパサンドのエスケープの項も参照されたい。
デフォルトのMIMEタイプである。このMIMEタイプで提出するフォームは、次の通り符号化しなければならない。
注意。 ファイルのアップロードについて、後方互換性、multipart/form-data及び他のMIMEタイプの関係、パフォーマンス等に関する追加的情報は [RFC2388]を参照されたい。
フォームのセキュリティ問題については本書の附属書を参照されたい。
MIMEタイプapplication/x-www-form-urlencodedは、巨大なバイナリデータや非ASCII文字を含むテキストの送信には適さない。ファイルや非ASCIIデータ、バイナリデータを含むフォームの提出には、MIMEタイプmultipart/form-dataを用いる必要がある。
MIMEタイプmultipart/form-dataは、[RFC2045]のマルチパートMIME伝送のすべての規則に従う。このmultipart/form-dataの定義は、[IANA]レジストリで得られる【訳注:RFC2388として登録された】。
1つのmultipart/form-dataメッセージには、1つ1つが満足なコントロールから成る、一連のパーツが含まれる。各パーツは、関連コントロールが文書に出現した順に処理エージェントに送られる。どのデータにもパートバウンダリが発生してはならないが、この発生ついては本仕様の範囲外である。
すべてのマルチパートMIMEタイプ同様、各パートにはデフォルトがtext/plainであるオプションのContent-Typeヘッダを持つ。ユーザエージェントはContent-Typeヘッダにcharsetパラメータをつける必要がある。
各パートには次が含まれている必要がある。
従って、例えば「mycontrol」というコントロール名は、対応パートで次のように指定される。
Content-Disposition: form-data; name="mycontrol"
すべてのMIME伝送同様、「CR LF」すなわち「%0D%0A」はデータの各行を分離するものとして用いる。
あるパートがデフォルトの7ビット符号化( [RFC2045]の6参照)に適合しない値である場合、そのパートも符号化され、Content-Transfer-Encodingヘッダが付加される。
ファイルの内容がフォームで提出される場合、ファイル入力はapplication/octet-streamなど適切なMIMEタイプで識別しなければならない。 1つのフォームの結果として複数のファイルが返される場合は、multipart/form-dataに埋め込んだmultipart/mixedとして返される必要がある。
ユーザエージェントは、各提出ファイルにファイル名をつけようと試みる必要がある。ファイル名は、Content-Disposition: form-dataヘッダのfilenameパラメータか、複数ファイルの場合サブパートのContent-Disposition: fileヘッダで指定できる。 クライアントのOS側でファイル名に非US-ASCIIが使われていた場合、ファイル名は[RFC2045]の手法で近似されるかまたは符号化される。これは、例えばTeXファイルとその「.sty」補助スタイル宣言などのように、アップロードするファイルが互いへの参照を含む場合に便利である。
次の例では、multipart/form-dataの符号化を示す。以下のようなフォームを仮定する。
<FORM action="http://server.com/cgi/handle" enctype="multipart/form-data" method="post"> <P> あなたのお名前は? <INPUT type="text" name="submit-name"><BR> 送りたいファイルの名前は? <INPUT type="file" name="files"><BR> <INPUT type="submit" value="送る"> <INPUT type="reset"> </FORM>
ユーザが名前「Larry」を入力し、テキストファイル「file1.txt」を選んだとしよう。ユーザエージェントは次のようなデータを送り返してよこすであろう。
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files"; filename="file1.txt" Content-Type: text/plain … file1.txt の内容 … --AaB03x--
ユーザが2番目のファイル、file2.gif 画像をも選んだ場合、ユーザエージェントは次のようなパートを構築する。
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y --BbC04y Content-Disposition: file; filename="file1.txt" Content-Type: text/plain … file1.txt の内容 … --BbC04y Content-Disposition: file; filename="file2.gif" Content-Type: image/gif Content-Transfer-Encoding: binary … file2.gif の内容 … --BbC04y-- --AaB03x--