オートコンプリート、リスト、データリスト、プレースホルダ、オートフォーカス
これらは、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
これらはそれぞれ、同じ基本名を持つフォーム属性（action、enctypeなど）と対応しており、フォーム送信ボタンからフォームの所定の属性をオーバーライドできます。このことは、豊富なHTTP動詞を駆使するのに特に便利です。
HTML 4とは異なり、HTML 5ではPUTやDELETEといったHTTP動詞を明示的に認識します。従って、HTML 5ではこれらのメソッドをサーバへ直接送信できます。現在も多くのブラウザがこの機能を暗黙的にサポートしていますが、そうではないブラウザもあります。このサポートは、RESTfulサービスの活用促進に大いに役立つでしょう。例えば、フォームのReplaceボタンとCloneボタンで、それぞれPUTとPOSTのメカニズムを通して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は、こうした問題を踏まえ、勧告プロセスにおけるこの規格の方向性によく気を付ける必要があります。
