古いブラウザでの HTML フォーム

すべての Web 開発者が、Web はとてもつらい場所であることをいち早く (時には痛いほど) 知ります。もっともいまいましいのは、古いブラウザです。まあそれは受け入れて、"古いブラウザ" というときは古いバージョンの Internet Explorer を念頭に置きます... しかし、それだけではありません。ESR バージョンのような、1 年経過した Firefox も古いブラウザです。また、モバイルでは? ブラウザも OS も更新できないのではないでしょうか? そうです、最新ではないブラウザを備えている、多くの古い Android フォンや iPhone があります。これらもまた、古いブラウザです。

残念ながら、そのような困難に対処するのも仕事の一部です。幸い、古いブラウザによって起きる問題の 80% 程度を解決する助けになることがわかっている秘訣がいくつかあります。

問題について学ぶ

実のところもっとも重要なことは、一般的なパターンを理解するためにそれらのブラウザに関するドキュメントを読むことです。例えば、多くの場合 CSS のサポート状況が HTML フォームにおける最大の問題です。あなたはスタートとして適切な場所にいます。使用したい要素 (または DOM インターフェイス) のサポート状況を確認しましょう。MDN では Web ページで使用できる多くの要素、プロパティあるいは API について、実装状況の一覧表を入手できます。しかし、驚くほど役に立つであろうリソースが他にもあります:

ブラウザベンダーのドキュメント

Mozilla: あなたは適切な場所にいます。MDN をご覧ください。
Microsoft: Internet Explorer Standards Support Documentation
Opera: Web specification support in Opera
WebKit: このエンジンはいくつかの異なるエディションが存在するため、やや複雑です。
- The WebKit blog や Planet WebKit は、WebKit のコア開発者による最良の記事を集約しています。
- The chromium web site も重要です。
- Apple の Web サイトも同様です。

独自のドキュメント

Can I Use に、先端技術のサポート状況に関する情報があります。
Quirks Mode は、ブラウザの互換性に関するすばらしい資料です。モバイルの部は現時点で入手できる最高の情報源です。
Position Is Everything は、古いブラウザのレンダリングの不具合や (もしあれば) その回避策を入手できる最高の情報源です。
Mobile HTML5 は、"top 5" に限らず (Nokia、Amazon、Blackberry も含む) さまざまなモバイルブラウザの互換性情報を掲載しています。

物事をシンプルに

HTML フォームは複雑なやりとりを伴うことから、一つの経験則があります: 可能な限りシンプルにしてください (日本語版)。フォームを "より立派に" あるいは "高機能に" したいケースはたくさんありますが、効率的なフォームの作成はデザインや技術の問題ではありません。それを忘れないように、UX For The Masses にあるフォームのユーザビリティに関する記事を読む時間をとってください。

Graceful Degradation は Web 開発者の最高の味方

Graceful Degradation と Progressive Enhancement は、一度に幅広いブラウザをサポートすることにより、すばらしいものを構築可能にする開発パターンです。新しいブラウザで何かを構築するときにそれが動作すると確信したい場合は、あれやこれやで古いブラウザにおいて Graceful Degradation を行っています。

HTML フォームに関する例をいくつか見ていきましょう。

HTML input のタイプ

HTML5 でもたらされた新たな input のタイプは、退行手段がとてもわかりやすいことから、すばらしいものです。ブラウザが <input> 要素の type 属性の値を知らない場合は、値が text であるかのようにフォールバックします。

<label for="myColor">
  Pick a color
  <input type="color" id="myColor" name="color">
</label>

Chrome 24	Firefox 18

CSS 属性セレクタ

CSS の属性セレクタは HTML フォームでとても有用ですが、一部の古いブラウザはサポートしていません。その場合、慣例では type と同等の class で二重化します:

<input type="number" class="number">

input[type=number] {
  /* こちらは一部のブラウザで機能しません */
}

input.number {
  /* こちらはどのブラウザでも動作するでしょう */
}

以下の記述では役に立たず (冗長であるため)、一部のブラウザで機能しない可能性があります:

input[type=number],
input.number {
  /* セレクタのひとつが理解できない場合は規則全体が無視されるため、
     これは一部のブラウザで動作しません */
}

フォームボタン

HTML フォームでボタンを定義する方法は 2 つあります:

type 属性の値を button、submit、reset あるいは image に設定した <input> 要素
<button> 要素

<input> は、要素セレクタを使用して CSS を適用したい場合に若干難しいことになります:

<input type="button" class="button" value="click me">

input {
  /* この規則は、input 要素で定義するボタンのデフォルトのレンダリングを無効にします */
  border: 1px solid #CCC;
}

input.button {
  /* これはデフォルトのレンダリングを復元しません */
  border: none;
}

input.button {
  /* こちらも同様です! 実際は、あらゆるブラウザでこれを行う標準的な方法はありません */
  border: auto;
}

<button> 要素は、起こりうる 2 つの問題に悩まされます:

古いバージョンの Internet Explorer に存在する不具合です。ユーザがボタンをクリックしたときに送信されるものは value 属性の内容物ではなく、<button> 要素の開始タグと終了タグの間にある HTML コンテンツです。これはそのような値を送信する場合のみの問題であり、例えばユーザがクリックしたボタンに応じてデータを処理する場合です。
一部のとても古いブラウザは type 属性のデフォルト値として submit を使用しないため、<button> 要素では常に type 属性を設定することを推奨します。

<!-- ボタンをクリックすると "A" ではなく "<em>Do A</em>" を送信する場合があります -->
<button type="submit" name="IWantTo" value="A">
  <em>Do A</em>
</button>

プロジェクトの制約に基づいて、どちらの解決策を選択するかはあなた次第です。

CSS を手放そう

HTML フォームと古いブラウザにおける最大の問題は CSS のサポートです。Property compatibility table for form widgets の記事の複雑さからおわかりいただけるとおり、これはとても難しい問題です。テキスト系の要素でいくらか調整が (サイズや文字色など) 可能であるとしても、それらには必ず副作用があります。残された最善の方法は、HTML フォームのウィジェットに一切スタイルを設定しないことです。ただし、それでも周囲のアイテムにはスタイルを設定してもかまいません。もしあなたがプロフェッショナルで、顧客が要求するようなことがあれば、JavaScript によるウィジェットの再構築といった難易度が高い技術について調査してみるとよいでしょう。しかしそのような場合でも、顧客の愚かさを変えることをためらってはいけません。

機能検出とポリフィル

JavaScript は新しいブラウザにおいてすばらしい技術ですが、古いブラウザでは多くの問題を抱えています。

控えめな JavaScript

最大の問題のひとつは、API を利用できるかです。そのため、"控えめな (unobtrusive)" JavaScript によって取り組むことベストプラクティスであると考えられています。これは、2 つの要件によって定義される開発パターンです:

構造と振る舞いの厳密な分割。
コードが動作しない場合でも、コンテンツや基本的な機能性には依然としてアクセス可能かつ利用可能でなければならない。

The principles of unobtrusive JavaScript (原文は Peter-Paul Koch 氏によって Dev.Opera.com 向けに記述され、現在は Docs.WebPlatform.org に移動しました) で、これらのアイデアを明快に説明しています。

Modernizr ライブラリ

欠けている API を提供することで、すばらしい "ポリフィル" が大きな助けになるケースが多数あります。ポリフィルは、古いブラウザにおける機能性の "穴を埋める" 小さな JavaScript コードです。ポリフィルは任意の機能のサポート状況を改善するために使用できますが、JavaScript 向けに使用するのは CSS や HTML 向けより低リスクです。JavaScript が動作しない可能性は多数あります(ネットワークの問題、スクリプトの競合など)。しかし JavaScript については、控えめな JavaScript を念頭に置いて取り組む場合はポリフィルが欠けたとしても、重大な問題にはなりません。

欠けている API に対してポリフィルを適用する最善の方法は、Modernizr ライブラリおよびそこからスピンオフしたプロジェクトである YepNope を使用することです。Modernizr は、機能が利用できるかを確認して適宜対応を行えるようにするためのライブラリです。YepNope は、条件付きで読み込みを行うライブラリです。

サンプルは以下のとおりです:

Modernizr.load({
  // ブラウザが HTML5 の form validation API をサポートしているかを確認します
  test : Modernizr.formvalidation,
 
  // ブラウザがサポートしない場合は、指定したポリフィルを読み込みます
  nope : form-validation-API-polyfill.js,
 
  // どの場合でも、API に依存するコアアプリのファイルを読み込みます
  both : app.js,
 
  // 両方のファイルを読み込んだら、アプリを初期化するためにこの関数を呼び出します
  complete : function () {
    app.init();
  }
});

好都合なことに、Modernizr チームはすばらしいポリフィルのリストを管理しています。必要なポリフィルを選びましょう。

注記: Modernizr は、控えめな JavaScript や Graceful Degradation のテクニックに取り組むことを支援するためのすばらしい機能を搭載しています。Modernizr のドキュメントをご覧ください。

パフォーマンスに注意を払う

Modernizr のようなスクリプトがパフォーマンスについて強く配慮しているとしても、200 キロバイトのポリフィルを読み込むとアプリケーションのパフォーマンスに影響を与えます。これは特に古いブラウザで重要です。それらの多くはすべてのポリフィルを実行することがユーザの苦痛になるかもしれない、とても遅い JavaScript エンジンを搭載しています。パフォーマンスはそれ自身の問題ですが、古いブラウザはその問題に対してとても影響を受けやすいものです: 要するに、それらは遅い一方で多くのポリフィルが必要であり、処理すべき JavaScript が多くなります。よって、新しいブラウザに比べて二重の負担がかかります。実際どのように動作するかを確認するため、古いブラウザでコードのテストを行ってください。時には、すべてのブラウザで完全に同じ機能を持つのではなく、よりよいユーザ体験をもたらすために一部の機能を削除しましょう。最後に念のため、常にエンドユーザのことを考えるようにしてください。

おわりに

ご覧いただいたように、古いブラウザへの対処はフォームだけに関するものではありません。それはテクニックの集合体です。しかし、それらのすべてを習得することは本記事で扱う範囲を超えます。

この HTML フォームガイドの全記事を読んだのでしたら、フォームを気楽に使用できるでしょう。もしあなたが新たなテクニックやヒントをご存じでしたら、ガイドの改善にご協力願います。