デベロッパー

デベロッパー

HTML 5のフォーム要素

Kurt Cagle
2009年11月24日 / 10:00
 
 

はじめに

 ほぼすべてのWebアプリケーションにとって、フォームはなくてはならないものになりましたが、HTMLフォームの主要な要素は13年近くも前のものです。HTML 5の最初の大きな目的の1つが、現状の潮流に合わせてこれらの要素を変更することであったのも不思議ではありません。

 W3Cが最初にXHTML仕様を策定したとき根底にあった目標の1つは、XMLコンテンツの処理に適したフォームアーキテクチャを作ることでした。そこで2002年にXFormsが開発されました。ところが、HTMLコミュニティの多くの人からは、HTML 4で進化した名前/値のペアやJavaScriptよりもXMLが重視されていて、平均的なWeb開発者には複雑で柔軟性の低い仕様だと受け止められました。

 このような反応のなか、Web Hypertext Application Technology Working Group(WHATWG)が新しいHTML仕様を作成し、それが結果的にはW3Cに採用されて次世代HTML 5の草案となりました。この過程でXHTML 2.0の計画はなくなりました。

 2009年8月現在のHTML 5の草案には、いくつかの新しいフォーム要素と既存要素の改訂が組み込まれています。これらの変更は、HTML 4.0で使用している基本データモデルを踏襲するもので、各フォームコントロールは独自の内部ステートを持ち、外部リソースに依存しません。ただし、この処理については、過去のバージョンの言語仕様ほど明確には定義されていません。

 この記事では、HTML 5の草案に導入されている、主要な新しいフォーム要素と既存要素の変更点を説明します。

output要素

 新しいフォーム要素のなかで最も重要なのは、<output>要素でしょう。<input>要素と同様に、<output>要素にも@value属性があり、現在の状態の値が反映されます。ただし、<output>要素で表示されるのは、内部コンテンツではなく値です。@value属性(または要素の対応する.valueプロパティ)が変化すると、そのコンテンツも変化します。

 例えば、以下の単純な"Hello, World!"コードでは、あいさつの相手の名前がoutputフィールドになっています。

<html xmlns="http://www.w3.org/1999/xhtml">
    <head><title>Hello!</title>
        <script type="text/javascript"><![CDATA[

function updateHello(ctrl){
    var helloOutput = document.getElementById('helloName');
    helloOutput.value = ctrl.value;
     }
        ]]></script>
    </head>
    <body>

        <div>Hello, <output id="helloName" value="World"/>!</div>
        <input type="button" value="John" onclick="updateHello(this)"/>
        <input type="button" value="Paul" onclick="updateHello(this)"/>

        <input type="button" value="George" onclick="updateHello(this)"/>
        <input type="button" value="Ringo" onclick="updateHello(this)"/>

    </body>
</html>
 outputの利点はすぐには分かりにくいかもしれません。確かに、同じid値と.innerTextプロパティを持つ<span>要素でも、これと同じことはできるでしょう。しかし、<output>要素の利点は、この要素に新しく追加されたプロパティを使うことで発揮されます。

 @mode@defaultValueという2つの属性を使うと、フィールドの初期値を作成できます。@modeを"default"に設定し、@value属性を設定しないでおくと、outputフィールドの@value@defaultValueの値と同じになります。どちらも指定しなかった場合には、空文字列("")になります。@valueが変化すると、@defaultValueも変化します。

 一方、@mode属性を"value"に設定した場合、@defaultValueは、@valueの値が変化しても変わらず、.defaultValueプロパティからしかアクセスできなくなります。

 フィールドの初期値を作成した結果は、フォームをリセットすると確認できます。各フォームには専用の.reset()メソッドがあり、これが呼び出されると、フォームの各要素はそれぞれの内部リセットルーチンを呼び出します。outputの場合、リセットの結果、@value属性は(それに伴い対象要素の表示も)@defaultValueの値に設定されます。 フォームコントロールは、対象となるフォーム要素内に記述する必要はありません。コントロールの@form=name属性を使えば、指定した名前のフォームと結び付けることができます。このことは、<output>にとって特に有用です。<output>要素は大抵テキストコンテンツに含まれ、リンク先のフォームからは離れていることが多いからです。

 以下に例を示します。

<html xmlns="http://www.w3.org/1999/xhtml">
    <head><title>Hello!</title>
        <script type="text/javascript"><![CDATA[

function updateHello(ctrl){
    var helloOutput = document.getElementById('helloName');
    helloOutput.mode="value";
    helloOutput.value = ctrl.value;
     }
        ]]></script>

    </head>
    <body>
        <div>Hello, <output id="helloName" defaultValue="World"
            form="selector"
/>!</div>
        <form name="selector">

            <input type="button" value="John" onclick="updateHello(this)"/>
            <input type="button" value="Paul" onclick="updateHello(this)"/>

            <input type="button" value="George" onclick="updateHello(this)"/>
            <input type="button" value="Ringo" onclick="updateHello(this)"/>

            <input type="reset" value="Reset"/>
        <form>
    </body>
</html>
 ここでは、<output>はフォームの外に記述されていますが、@form属性を介してフォームと結び付いています。初期値は"World"です。ユーザーがいずれかのボタンを押すと、まず@mode属性が"value"に設定され、@value属性と@defaultValue属性が分離されます。こうして、@defaultValueには常に初期値(ここでは"World")が保持されます。

 ユーザーがResetボタンを押すと、outputフィールドの@modeは自動的に"default"にリセットされ、@valueの値は@defaultValueの値に設定されます(その結果、また"Hello, World!"に戻ります)。このようにして生成するoutputにHTML要素を組み込めるかどうかは、オリジナルのHTML 5仕様には明記されていません。

 HTML 5が普及すれば、<output>要素は広く使われることになるでしょう。この要素を使うことで、JavaScriptのコーディングも(特定の新規ドキュメントでは特に)onforminputなどのフォームベースのイベントも飛躍的に簡素化できます。

input要素:HTML 5のスイスアーミーナイフ

 <input>要素はHTML 4の主戦力です。単一の値を保持する抽象エンティティである<input>は、@type属性を使って、保持するデータのタイプに基づき表現形式を決定します。HTML 5では、タイプの種類(仕様ではinputのステートと呼ばれます)が大幅に増え、よく使われるデータタイプにさまざまな視覚的インターフェースが提供されます。

 多くの場合、<input>要素はデフォルトのテキストフィールドと見た目は同じですが、入力検査ができるところが異なります。実装方法によっては(電子メール入力フィールドなど)、この機能は無効な文字の入力を防ぐこともできます。ただし、ほとんどの場合は、このフィールドは任意の値を受けつけ、それが(タイプによって)事前定義されたパターンと一致しないと、自動的に入力検査エラーを発生させます。このエラーイベントは、対応するイベントハンドラで検出できます。

テキスト、検索、電話番号、電子メール、URLのステート

 HTML 5のテキストフィールドに加えられた新しい属性の1つにpatternがあります。これは、対象フィールドと一致させるための正規表現を指定します。フィールドの値が指定の正規表現と一致しない場合、入力検査エラーが発生します。

 テキストフィールドはかなり複雑になることがあるので、HTML 5では、patternが事前定義されている特殊な形式のテキストフィールドが提供されます。emailurltel(電話番号)です。いずれも、明示的なpattern属性値を使ってそれぞれの内部実装をオーバーライドできます。

数値と範囲のステート

 数値のステートは、値として数値のみを有効とするテキストフィールドです。@min(最小値)属性と@max(最大値)属性によって、数値の範囲も追加指定できます(当然ながら、@min@maxより小さい値にする必要があります)。@step属性を特定の値(通常は1)に設定して、値が@min + n * @stepになるよう指定することもできます。このとき、nは0〜(@max - @min)/@stepです。例えば、@min="1"@max="5"@step="2"の場合、有効な値は1、3、5のみになります。

 このフィールドの実装によっては、読み取り専用テキストフィールドと矢印を使って@min@maxの値を表すスピナーにすることもできます。一方、範囲のステートの一般的な表現形式は、最小値と最大値の間をサムボタンでスライドするスライダーになります。範囲ステートのinputフィールドは、一般に、厳密な値より相対的な値を重視する場合に適しています(オーディオボリュームを消音と最大音量の間に設定するときなど)。

日付、時刻、日付時刻

 このような入力タイプの多くは、日付、時刻、日付時刻の入力検査形式と、カレンダーや時計の視覚表現を組み合わせます。HTML 5仕様では、これらのフィールドに使用する視覚表現(結果が有効なら日付や時刻や日付時刻の値をフィールドに結び付けるもの)の正式な仕様は提供されていません。

 有効な日付、時刻、日付時刻のフィールドには、標準のW3C表現が使用されます。例えば、太平洋標準時の2010年1月2日午後10:15:00は「2010-01-02T10:15:00-08:00Z」、2010年第5週は「2010-W05」、2010年1月は「2010-01」となります。

 数値の場合と同様に、これらのフィールドでも@min属性と@max属性がサポートされ、有効な値の範囲を制限できます。これはフィールドの視覚表現でもサポートされる可能性があります。その場合、例えば、@minを「2010-01」、@maxを「2010-12」とすることで、カレンダーに2010年の日付だけを表示できます。

 これらのフィールドは変換プロパティvalueAsDateもサポートします。これは、W3C XML日付表現をJavaScriptのDate()オブジェクトに変換し、またそのようなJavaScriptオブジェクトを反対に文字列表現に変換するものです。

イメージステート

 イメージステートは、とても便利になりそうな新しいフィールドタイプです。このタイプの<input>コントロールは、@src属性でイメージリソースを参照します。ロードしたイメージをユーザーがマウスでクリックすると、クリックした位置がイメージの原点からの相対座標で検出され、このコントロールの値になります。

 イメージステートにはさまざまな用途が考えられます。色の明度や彩度を表す勾配曲線などの非数値情報を視覚的範囲で示すコントロールも容易に作成できるようになります。WebゲームのUI開発やイメージコンテンツの注釈も簡素化できます。大雑把なエリアマップも作成できます。

 座標表現がどんなものになるのか、現在の仕様ではやや不明瞭ですが、おそらくはカンマで区切ったXYペアになるでしょう。既に、各種HTML DOM表現で、イメージに対するマウスの相対座標を検出できますが、必ずしも簡単ではありません。イメージステートを使えば、そうしたコードを簡素化でき、すべてのHTML 5ブラウザで統一することも可能になります。

カラーステート

 色のinputタイプは、特定の色を選択する手段を提供します。通常、これは、#rrggbb、rgb(赤、緑、青)、または単純な色名指定('green'、'yellow'など)の色表現を指定できるテキストフィールドと、カラーセレクタなどで色選択できるウィジェットを組み合わせて実装されます。このようなウィジェットの具体的な実装はブラウザに依存します。

オートコンプリート、リスト、データリスト、プレースホルダ、オートフォーカス

 これらは、inputコントロールのステートではなく属性です。inputコントロール(またはフォーム全般)のオートコンプリート属性は、入力対象に入力された値の履歴をブラウザで保存するかどうかを指定します(そのブラウザがこの機能をサポートしている場合)。@autocompleteをオフに設定するとこの機能は無効になり、機密データ(核ミサイル制御コードなど。実際に仕様に登場する例です)は毎回再入力が必要になります。ですから、HTMLで世界征服インターフェースを作成するようなことになったら、このプロパティのことを思い出しましょう(通常デフォルトはオンなので要注意です)。

 @list属性はHTML 5の新しい属性ですが、その動作は@autocompleteと似ています。@list属性には<datalist>要素の@idが含まれ、その<datalist>要素には<option>要素の集合が含まれます。@listを指定すると、デフォルトの@autocomplete動作はオーバーライドされます。オートコンプリートボックスには、過去の入力値の代わりに、指定したdatalistからのデフォルトの候補値の一覧が示されます。これを入力候補のリストと見なすことができます。

 <select>文の動作とは違って、このオートコンプリート機能は強制ではありません。ユーザーは、入力候補のドロップダウンにない値も入力できます。

 <datalist>要素とそれに結び付けられた<option>要素は非表示です。仕様では、<datalist>をどこに記述したらいいかが不明瞭です。ヘッダーか、body内のインラインか、あるいは<input>要素の子要素とするのか(これは理に適っていますが、inputは子要素を持たないnull要素であるという前提と矛盾します)、はっきりしません。

 HTML 5のもう1つの改善点が@placeholder属性の導入です。これはAJAX対応Webページでますます一般的になってきたプレースホルダ機能を実装するもので、検索フィールドでプレースホルダテキストをグレーアウトしたり、ユーザーが要素をクリックしたときはプレースホルダを消し、入力が消去されたらプレースホルダを再表示したりします。多くの場合、このようなプレースホルダには、「検索項目を入力してください」のような短い入力指示文が表示されます。フォームが送信されるとき、プレースホルダのテキストはサーバには渡されません。この機能をよく使うのは<input type="search">要素です。この機能を使わなければ、<input type="search">要素も普通のテキストフィールドと変わりません。

 最後に、@autofocus属性を紹介します。この属性は、ページがロードされて入力操作が開始したらすぐに、その要素に自動的にフォーカスを移すことを指定します。これはブール値なので、この属性を明示的に指定することで(その値に関係なく)、この動作が有効になります。

 option@selectedなど他のブール属性の難しさを考えると、@autofocusはさまざまな興味深い問題の原因になるかもしれません。

フォーム要素

 HTML 5のフォーム自体はHTML 4のときとそれほど大きく変わりませんが、それでもいくつか相違点があります。重要な変更の1つが、フォーム名の導入とフォームコントロール要素側の@form属性の追加です。この変更の結果、要素をフォーム内に記述することは、厳密な要件ではなくなりました。@form属性でフォームにバインドさえすれば、その要素に認められている任意の場所に記述できます。

 <form>要素は、@novalidate属性をサポートします。これもブール値です。この属性は入力検査イベントを発生させないときに指定します。これを指定しない場合のデフォルトの動作では、送信が行われたとき、最初に必ずHTMLで入力検査が行われてから、操作結果のロケーションに移動し、履歴が更新されます。

 <input type="submit">ボタンには、以下の5つの新しい属性があります。

  • formaction
  • formenctype
  • formmethod
  • formnovalidate
  • formtarget
 これらはそれぞれ、同じ基本名を持つフォーム属性(actionenctypeなど)と対応しており、フォーム送信ボタンからフォームの所定の属性をオーバーライドできます。このことは、豊富なHTTP動詞を駆使するのに特に便利です。

 HTML 4とは異なり、HTML 5ではPUTDELETEといったHTTP動詞を明示的に認識します。従って、HTML 5ではこれらのメソッドをサーバへ直接送信できます。現在も多くのブラウザがこの機能を暗黙的にサポートしていますが、そうではないブラウザもあります。このサポートは、RESTfulサービスの活用促進に大いに役立つでしょう。例えば、フォームのReplaceボタンとCloneボタンで、それぞれPUTPOSTのメカニズムを通して1つのRESTfulなURLを使用できるようになります。この場合、POSTでは、指定のデータにファイル識別子などが含まれていても、サーバのPOSTハンドラでそのエントリ用に新しいものが自動生成されることになります。

 <textarea>文も<select>文も、特筆すべき変更は@autofocus属性の追加だけです。<select>文については、この追加はやや奇妙に感じられますが、データリストへのバインドを考えれば自然な選択に思えます。

 現在のところ、W3CがXMLやJSONとの相互エンコーディングについて考えている気配はありませんが、これも考慮に値する分野だと筆者は考えています。HTML 5がXFormsを明示的にサポートしないにしても、コントロールのデータから単純なXMLエンコーディングを作成する潜在的利点は、複雑なXMLワークフローを抱えた企業環境において、HTML 5の役割効果を高めるのに必ず役立つはずです。

XMLはどうなるか

 この記事全体にわたる筆者のコメントからも分かるように、不明瞭な部分が多いのはHTML 5仕様全体に共通の問題と思われ、XHTML表現に限ったことではありません。各種属性やスキーマデザインに対する期待がこうしたあいまいさの原因にもなっており、実際に使える正式なスキーマやDTDの欠如もこれを助長しています。これらの要因のため、仕様の策定だけでも、安定化して実装可能になるまで最低あと1年はかかるでしょう。

 全般に、HTML 5のフォーム実装のあらゆる側面でXML表現が欠如していることが(そしてXML表現の極めてあいまいな特性も)大変気がかりです。AJAX指向の機能があること(そしてその特有の複雑さ)を考えると、要件に関するある種の合意、そして筆者の見解では、アプリケーション設計においてXMLを過小評価しようとするかなり意図的な動きがあるように思えます。W3Cは、こうした問題を踏まえ、勧告プロセスにおけるこの規格の方向性によく気を付ける必要があります。

著者紹介

Kurt Cagle(Kurt Cagle)
ライター、情報アーキテクト、XML News NetworkとMetaphorical Webのウェブマスター。カナダ、ブリティッシュコロンビア州のビクトリア在住。XMLToday.orgの編集長、O'Reilly Mediaの寄稿編集者。現在、XBRLに関する著書を執筆中。彼のTwitterはtwitter.com/kurt_cagle
【関連記事】
大幅に進化した次世代 HTML 規格「HTML5」とは?
情報を GET できる検索バナーや地図バナー
アイフリーク、テキストメールを2クリックで変換できる「デコメ変換サービス」を提供開始
HTML 5のレイアウト要素
企業メルマガ発行担当者向け必須情報

New Topics

Special Ad

ゆりかごからロケットまで、すべての乗り物をエンジョイ
ゆりかごからロケットまで、すべての乗り物をエンジョイ えん乗り」は、ゆりかごからロケットまで、すべての乗り物をエンジョイする、ニュース、コラム、動画などをお届けします! てんこ盛りをエンジョイするのは こちらから

Hot Topics

IT Job

Interviews / Specials

Popular

Access Ranking

Partner Sites