« ナビゲーションリストについて | メイン | VMLメモ »

2004年01月05日

HTML Formの問題点とXForms [HTML]



既存のHTMLのフォームコントロール要素は、お世辞にも論理的とは呼べない。後から後から機能だけを取ってつけたというかたちで、仕様にも全く一貫性というものが無い。新しく提案されているXFromsと比較しながら、問題点を考察していく。


多機能過ぎる <input>


最もよく使われるinput要素は



  • 一行プロンプト

  • ボタン

  • チェックボックス

  • ラジオボタン

  • 隠しコントロール


という、機能も外見も全く異なる様々な形式を取る事が出来る。これらは全て type属性 の値によって決定される。実際的な問題として、例えば属性セレクタの対応していないIEでは、クラス名の助けを借りない限りはコントロールのスタイルを変更するのが困難である。機能面においても、「入力」「選択」「送信」「保持」と全く一貫性が無い。


HTML4.0においてボタン形式は button要素 に分離されたが、NN4.x等の古いブラウザが対応していないという問題もあり、あまり使用されていない。


XFormsにおいてはinput要素の役割は大幅に削減されており(多少追加もされたが)概ね文字通り"input" の機能のみを果たすようだ。


一貫性の無い選択用コントロール



  • <input type="radio" /><select>

  • <input type="checkbox" /><select multiple="multiple">


これらは機能的には全く同等のものである。単にレンダリング方法の違いだけで、大幅に仕様の異なる2つを使い分けなくてはならなくなっている。これらは統合され、スタイルシート或いは何らかの属性によってのみ、それらの表示形式を変えられるべきだ。この場合においては、一貫性の無いinput要素よりもリスト形式に近いselect要素が採択されるべきであろう。


XForms においては、 重複選択が select要素 、単一選択が select1要素に纏められており、その表示方法は appearance属性 によってラジオボタンやプルダウンメニュ等に変化する。


一貫性の無い入力フォーム



  • <input type="text" value="hoge" />

  • <textarea>hoge</textarea>


これらの入力フォームは、改行が有効かどうかが異なるだけで、あとは全く同等のものである。それだけの違いなのに、初期値の書き方やサイズ指定、取り得る属性など全く異なる仕様になっている。これらは統合され、改行できるかどうかは何らかの属性によって決定されるべきだ。


XForms でも、未だにinput要素とtextarea要素は分かれている。加えて、<input type="password" /> が secret要素 として別定義されている。まあ、全く不要だとは言わないが。


labelとquery


HTML4.0からlabel要素を用いて明示的にコントロールの説明を貼り付ける事が出来るようになった。しかし既存の仕様とも被る部分が多く、やはり一貫性が無い。

































各コントロールのクエリ値とラベル
コントロールKeyValueLabel
<input type="test"> name属性value属性(label要素)
<textarea> name属性内容テキスト(label要素)
<input type="radio"> name属性(重複可)"on" | value属性label要素
<input type="checkbox"> name属性"on" | value属性label要素
<select> + <option> select要素のname属性option要素の value属性 | 内容テキストoption要素の内容テキスト
<optgroup> --label属性
input type="submit" name属性value属性value属性
<button type="submit"> name属性内容テキスト内容テキスト


解りやすくするためには、これらに一貫性を持たせる必要がある。


XFormsにおいて、ラベルは殆どのコントロールの子要素として存在できる。また、新たなテキスト情報付加機能として hint要素 も加わった。


form要素の内容モデル


form要素 の Minimal Content Model は (%block;|SCRIPT)+ -(FORM) となっている。つまり行内要素である %formctrl; を直接子要素として含むことができない。これは確かに適切に構造化するための制約として充分なものなのだが、もともと構造的とは言えないコントロール群にそれを強制するのはいささか難がある。


例えば、隠しコントロール(<input type="hidden" />)は何によってグループ化すれば良いのだろうか。これは何かのグループというよりも、form要素の直接の初期値とでも考えたほうが妥当である。また、適切なグループ化要素であるはずのselect要素も何故か行内要素として扱われている。これらを段落(<p>)でマーク付けするのはいささか気分が悪いし、formの直下をdivで括るのも本末転倒だ。具体的な解決策としては、リストや fieldset でグループ化するという手もあるが、全てのケースに当てはまるとは言えない。


XFormsのスキーマをまだじっくり見ていないので詳しくは知らないが、現在ほどの混乱は無さそうだ。


XForms


断片的な部分しか見ていないので詳細なコメントは避けておくが、XForms1.0は概ね期待できるフォーマットと言っても良いだろう。最も、早々に多くのブラウザが対応してくれるとは考えられないので、専らXSL変換しながら使っていくしか無さそうだけれども。


投稿者 : 00:00 | コメント (0) | トラックバック (0)

トラックバック

このエントリーのトラックバックURL:
http://totora.jpn.org/mt/mt-tb.cgi/254

コメント

コメントしてください




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)