HTML5 Formsとは何だったのか? input要素の実装をマニアックに調べてみた

2016/11/01

Tim Severien

0

Articles in this issue reproduced from SitePoint
Copyright © 2016, All rights reserved. SitePoint Pty Ltd. www.sitepoint.com. Translation copyright © 2016, KADOKAWA CorporationJapanese syndication rights arranged with SitePoint Pty Ltd, Collingwood, Victoria,Australia through Tuttle-Mori Agency, Inc., Tokyo

HTML5の登場で注目されたのが、当時Operaが提案したフォーム関連機能の強化(Web Forms 2.0)でした。あれから数年経ち、ブラウザー実装はどうなったのでしょうか? input要素限定ですが、仕様のあいまいな点を含めて、マニアックに検証しました。

最近、日付フィールドと数値フィールドを必要とするプロジェクトに参加しました。私はある種の肥大化したフォーム用JavaScriptライブラリーよりも、ネイティブのフォーム要素を優先的に使っており、これからもずっとそうするつもりです。「ポリフィルで古いブラウザーをカバーできる」「そのほうが最新のブラウザーで最良のエクスペリエンスを保てる」と考えています。

プロジェクトはヨーロッパの数か国向けのものでした。ほとんどの国には日付や数値用の独自のフォーマットがあり、次のような疑問を持ちました。

  • HTML5のinputフィールドはロケール( 国や地域、言語の設定のこと)の影響を受ける場合があるか?
  • フィールドで期待される値のフォーマットは明確にされているか?
  • ブラウザーの解釈の誤りを防ぐ方法はあるか?

仕様で定義されていること・いないこと

W3ではHTML5のinput要素のローカライゼーション用にいくつかの項目を設け、次のように説明しています。

「ワイヤーフォーマットでページに与えられる時刻・日付・数値は、ユーザーに表示される前に(ユーザーの好みかページ自体のロケールに基づいて)ユーザー好みの表現に変換される。同様に、ユーザーが好みのフォーマットで時刻・日付・数値を入力すると、(入力内容は)DOMに取り込まれ、表示される前にユーザーエージェントによって元のワイヤーフォーマットに変換される」:4.10.1.5 Date, time, and number formats(日付・時刻・数値のフォーマット)

「ブラウザーは、input要素の言語またはユーザー好みのロケールのいずれかによって暗黙的に定義された慣習に従って日付・時刻・数値を表示するユーザーインターフェイスの使用が推奨される。ページのロケールを使えば、ページ提供のデータとの一貫性が確実に保たれる」:4.10.5.2 Implemention notes regarding localization of form controls(フォームコントロールのローカライゼーションに関する注記)

仕様では、input(要素)はページかユーザー設定からロケールを継承すると宣言されています。さらにページのロケールがユーザー設定よりも優先される理由も示されています。残念ながら、期待されるフォーマットがブラウザーでどのように表示されるかについて、これ以上の情報は提供されていません。

直面した課題

仕様では、ユーザーかページのロケールで要素をレンダリングすることが明らかに推奨されています。ところがブラウザーによってはユーザーのロケールのみを使用し、ページ(のロケール)には対応しない場合があります。このために混乱が生じたり、入力が無効になるおそれがあります。

次の例を考えてください。

Example where number formatting results in odd input

英語圏ではこのフォーマットはまったく問題なく見えます。しかし、あるオフィスでは「おや? オランダ人がBMIを2万5000と入力しているぞ。この人は1人で全国民分の体重があるにちがいない!」という話になるかもしれません。ブラウザーでは数値フィールドでオランダ語のロケールが選択されているのに、ユーザーのほうは「とにかく英語のページなのだから英語用のフォーマットが求められている」と考えている状況では、ブラウザーで値が誤って解釈され表示されてしまうことがあるのです。

解決策

明らかに、素のinputフィールドでは混乱やエラーを防ぐのに不十分です。次に示す解決策は目新しいものではありません。

  • 期待されるフォーマットを表示する
  • ユーザー入力を制限する

ブラウザーがいつもページのロケールを継承する場合、アプリケーション内にヒントを組み込めます。たいしたことではありません。

ブラウザーがなにを継承するか確定できない場合、ヒントはブラウザーによって変わります。1つの可能性としてプレースホルダーによるヒントがありますが、フィールドが事前入力されているとプレースホルダーは表示されません。ツールチップなども、アプリケーションのツールチップやほかのコンテンツと重なり合う場合があります。

別の選択肢は入力の制限です。これは(数字以外の)文字を無視する、pattern属性を使ってフォーマットを指定するなどとてもシンプルです。もっと複雑な値については、ユーザーに所定の値の選択だけを許可するカレンダーやセレクトボックスなどのポップアップを使えます。

Datepicker on iOS

ブラウザーごとの反応

仕様では、ブラウザーがどのようにロケールの検知を実装するか、input(要素)がどのように動作するかが明示されていないため、現在の実装状況は実にさまざまです。先ほどの3つの疑問点について、ブラウザーごとに次の3点をテストして答えを得ました。

  • ブラウザーはどのようにフィールドのロケールを決定するか?
  • フィールドで期待される値のフォーマットはどのように明確にされるか?
  • 解釈に関係なく、フィールドをエラーなく安全に使えるか?

注:inputタイプの欄にハイフン(-)が入っている場合、ブラウザーがそのinputタイプに対応していないことを示す。

Google Chrome(52)

■ロケールの決定

設定 結果
HTMLの言語( lang)属性 無効
Content-Languageヘッダ― 無効
ユーザーの言語設定 有効

Chromeはブラウザーの言語かOSの言語を使ってロケールを決定します。それ以外はすべて無視されます。

■エラー対策

Inputタイプ 期待されるフォーマットの表現 入力制限 安全性
date プレースホルダー 3つの部分にのみ区切られた数字とdatepicker(日付選択ボックス)を使用 事前入力されたフィールドでは安全でない
month プレースホルダー(ただしあまり明確ではない) 「月」は単一(アルファベット)文字のキー入力、「年」は数字入力のみ 複雑であるが安全
week プレースホルダー 2つの部分に分かれた数字 安全
time 要素の区切り 2つの部分に分かれた数字 安全
date-time プレースホルダーと要素の区切り 日付と時刻のフィールドを合わせたもの 事前入力フィールドでは安全でない
number なし 数字、記号、また指数表現では「E」の文字 安全でない

Firefox(48)

MDNでは次のように述べられています。

Firefoxでは(少なくともtype=”number”に関して)次の方法でロケールを決定し、ユーザー入力を検証します。

  • xml:lang属性で指定された言語を要素やその親要素に適用する
  • HTTPのContent-Languageヘッダ―がある場合、指定された言語を適用する
  • なにも指定されていない場合、ブラウザーのロケールを使用する

うまくいきそうに聞こえますね。

■ロケールの決定

設定 結果
HTMLの言語(lang)属性 有効
Content-Languagヘッダ― 有効
ユーザーの言語設定 有効

■エラー対策

Inputタイプ 期待されるフォーマットの表現 入力制限 安全性
date 安全でない
month 安全でない
week 安全でない
time 安全でない
date-time 安全でない
number なし なし 安全でない

おそらくFirefoxでは、ローカライゼーション方法をいまも探しているところなのでしょう。

Safari(9.1)

■ロケールの決定

設定 結果
HTMLの言語( lang)属性 無効
Content-Languageヘッダ― 無効
ユーザーの言語設定 有効

■エラー対策

Inputタイプ 期待されるフォーマットの表現 入力制限 安全性
date 安全でない
month 安全でない
week 安全でない

time

安全でない

date-time

安全でない

number

なし

なし

安全でない

Safari(iOS 8.4)

■ロケールの決定

設定

結果

HTMLの言語(lang)属性

無効

Content-Languageヘッダ―

無効

ユーザーの言語設定

有効

おそらくSafariはOS X上でも同様に動作するでしょう。iOSとOS Xでは状況が同じか、少なくとも類似していると考えられます。

■エラー対策

Inputタイプ

期待されるフォーマットの表現

入力制限 安全性
date なし あり。複数選択のポップアップ 安全
month なし あり。複数選択のポップアップ 安全
week 安全でない
time なし あり。複数選択のポップアップ 安全
date-time なし あり。複数選択のポップアップ 安全
number なし 安全でない

興味深いことに、iOSはHTML5のいろいろなinputタイプに対応しています。複数選択のポップアップで入力を制限しているので、(入力)可能な値はすべて有効になります。

Edge

■ロケールの決定

最近、マイクロソフトは、Edgeについて「HTML5に完全対応した最初のブラウザー」であると宣言しました。これにローカライゼーションも含まれるでしょうか。

設定 結果
HTMLの言語(lang)属性 無効
Content-Languageヘッダ― 無効
ユーザーの言語設定 OSから継承

Edgeでは、アメリカ英語以外のロケールではinputフィールドをまったく表示できませんでした。EdgeはWindowsの言語設定を継承しているようです。

■エラー対策

Inputタイプ 期待されるフォーマットの表現 入力制限 安全性
date プレースホルダー あり。複数選択のポップアップ 安全
month プレースホルダー あり。複数選択のポップアップ 安全
week プレースホルダーと要素の区切り あり。複数選択のポップアップ 安全
time プレースホルダーと要素の区切り あり。複数選択のポップアップ 安全
date-time プレースホルダーと要素の区切り あり。複数選択のポップアップ 安全
number なし なし 安全でない

上のテストに使用されたテストページはGitHubにあります。

最後に

inputフィールドのローカライゼーションが実装されていても、開発者はFirefox以外のブラウザーではローカライゼーションをコントロールできません。ユーザーがフィールドのフォーマットでページとユーザーのコンピューターのどちらと同じロケールを使うことを期待しているかを把握するために調査しても、うまくいかないでしょう。

残念なことに、ブラウザーでは期待される値のフォーマットがどのようなものかもあまり明確にされていません。ブラウザーによってはいくつかの要素についてかなりはっきりしている場合もありますが、ヒントの多くはあいまいでいつも利用できるわけでもなく、エラーフリーにはできません。

幸い、いくつかのブラウザーはこれらの課題が考慮され、実際とても使い勝手が良く、無効な入力を完全になくせるポップアップが実装されました。この場合、フォーマットの設定は無意味です。こうしたブラウザーの中にはフォーマット依存のブラウザーに比べて使いにくいものもあるため、ユーザー体験への影響がとても気がかりです。

HTML5のinputフィールドでポリフィルを使うべきか、それともブラウザーでの実装の改善を待つべきか、という大きな疑問がなお残っています。HTML5のinput要素をポリフィルとともに使うのが標準的な選択でしょう。製品が複数の国で利用可能になる場合、どんなフィールドが必要で、そこにどんな「危険」があるかを調べておいてください。なんらかの理由で入力が無効になるおそれがあるなら、pattern属性を持つテキストのinput要素やJavaScriptなど、別のinput要素の使用を検討できます。

(原文:The State of HTML5 Input Elements

[翻訳:新岡祐佳子/編集:Livit

Copyright © 2016, Tim Severien All Rights Reserved.

Tim Severien

Tim Severien

オランダ出身で最先端のものに情熱を燃やす開発者です。JavaScriptとSassが大好きで、コードを書いていないときはSitePointまたはTim’s blogの記事を執筆しています。

Loading...