placeholder属性HTML5で導入された フォームフィールドに薄い灰色のテキストが表示されているものを見かけます。あのテキストや、その仕組みはプレースホルダと呼ばれています。
“placeholder”は実際のものに変わって表示されるものを意味するものです。たとえばダミーテキストなどもplaceholder textなどと呼ばれます。このノートでは、 プレースホルダのついたフォームフィールドは、こんな動作をします。
これらの挙動から、プレースホルダには「入力前にそのフィールドに関し何かしら情報を提示する」目的があると推測されます。
プレースホルダが消える挙動については、OSやソフトウェアの実装によって異なります。詳しくはプラットフォーム実装との差異をお読みください。
Webサイトがアプリケーション化しているからなのか、Webサイトでもプレースホルダを見ることも増えてきました。このプレースホルダの多くはJavaScriptによって実装されていますが、HTML5では 仕様書の説明を大雑把に訳すとこんな感じでしょうか。
長いヒントやその他の補足情報については、 UAはこのヒントを、要素の値が空文字列である場合に改行を取り除いたうえでユーザーに提示するべきだ。このとき、コントロールはフォーカスされてない状態であってもよいし、フォーカスされていてもよい。
改行文字を含んではならないとあるのに、その後UAは改行を取り除き表示すると書かれているので矛盾しているようにも読めますが、前者は製作者の要件、後者はUAの要件になります。
使い方ですが、値にプレースホルダのテキストを書くだけです。改行を含められないので、 これだけ。便利な世の中になりました。
すこし前のHTML5仕様書では、プレースホルダはフォーム要素にフォーカスが当たると消えることになっていました。しかし、この挙動はすべてのプラットフォームに共通したものではありません。
たとえば、iOSのプレースホルダはフォーカス時には消えません。フォーカス時は入力状態であることを示すIビームがプレースホルダに重なって表示されます。プレースホルダが消えるのは、テキストの入力時になります。
ところが、iOS 4までのSafariでは Mac OS X Snow Leopardにおいても、Safariのプレースホルダはフォーカス時に消える実装でした。しかし、OS X Lionでは、ネイティブのプレースホルダもSafari (5.1) のプレースホルダも、フォーカス時に消えないという挙動に変更されました。冒頭のスクリーンショットはLionのSafari 5.1ですが、アドレスバーにフォーカスが当たっているにもかかわらず“Go to this address”というプレースホルダが表示されているのがわかります。いっぽう、Snow LeopardのSafari 5.1ではフォーカス時に消えるという挙動をとっています。
こうした経緯から、OS X LionやiOS5のSafariは、仕様書の定義に意図的に反した実装になっていました。しかしこうしたUIコンポーネントの表現は、プラットフォームのもつ挙動に合わせることが正でしょう。というわけで、仕様の変更が提案され、その結果要件が緩和されました。
仕様の変更を受け、ChromiumのWebKitでも変更が反映されました。確認している範囲では、Chrome 17より、Windows, MacどちらのChromeにおいても、入力時にプレースホルダが消えるようになっています。
仕様の定義から、 まず、長いヒントは 次に、
次に、入力例です。メールアドレスのフィールドに「例: placeholder@example.com」などが書かれているケースがありますが、そういうものを想定しているのでしょう。
ほとんどの場合、入力例が有用になるケースや、そもそもヒントになるケースはまれなように感じます。しかし、入力する情報が特定のカテゴリに限定されないフィールドの場合、プレースホルダが有用なヒントとなる可能性はありそうです。
たとえば、Yahoo!ロコ地図の検索フィールドには「入力例：東京都港区赤坂9-7-1、東京ミッドタウン」「大阪駅 居酒屋」というプレースホルダがあります。どれも位置に関係する情報ですが、「東京都港区赤坂9-7-1」は住所、「東京ミッドタウン」はランドマーク、「大阪駅 居酒屋」はあるランドマーク周辺の情報検索と、性質はそれぞれ異なるのがわかります。
検索フォームが幅広いキーワードを受け付けられることを示すことで、ユーザーが目的の情報にありつきやすくなる効果が期待できるかもしれません。しかし、こういった情報も入力時に消えてしまうプレースホルダではなく、フィールドのそばに併記する方がよいかもしれません。プレースホルダの情報が助けになると判断された場合は、フォームのUIを見直すのがよいでしょう。
最後に、入力形式ですが、これは電話番号や郵便番号などを入力する際の書き方を指すものと推測されます。しかし、これをプレースホルダとして表示することは考えたほうがよいかもしれません。特定の書き方をユーザーに求めるのに、テキストを入力するとプレースホルダは消えてしまうので、どういう書き方をすればよいのかが分からなくなってしまいます。
そもそも、こういった入力する値を制限するフォームは不便なものです。住所の数字やハイフンが全角でなかったばっかりにエラー画面が出たといった経験はないでしょうか。入力された情報に表記のぶれが生じ処理に問題がでるケースは、クライアント側でははくサーバー側で処理するといった設計を考えたほうがよいでしょう。
それができない場合でも、 プレースホルダをJavaScriptで実装するものがあります。 実装方法ですが、だいたい2パターンかと思います。
さて、 そして、与えるプレースホルダは多くの場合「検索ワードを入力」や「Search」といった、ヒントにもならないテキストです。大した行数ではないでしょうが、スクリプトを実装してまでこうしたプレースホルダを プレースホルダはフィールドに入力する情報に関し何らかの「ヒント」をユーザーに伝える役割があります。ヒントはプレースホルダの使われる文脈に依存しますが、ちまたにあるプレースホルダ多くはあまり役目を果たしていないと感じます。「Search」など飾り程度でしかないものが多いからです。
プレースホルダは場合によって、良いヒントを提供してくれるかもしれません。しかし、プレースホルダの情報はあくまでヒントです。プレースホルダがなくなると目的が分からなくなるようなフォームであってはいけないわけです。ですから、まず問題なく機能するフォームを作ったうえで、必要あらばプレースホルダでヒントを与えるという設計フローがよいでしょう。
placeholder属性によって、フォームフィールドにプレースホルダを設定できるようになりました。さて、「プレースホルダ」とはそもそもなんでしょうか。また、どのようなテキストを書けばよいのでしょうか。
プレースホルダとは
inputやtextareaなどフォームフィールドに表示されるものに限定してこの「プレースホルダ」という言葉を使っています。
HTML5の
placeholder属性placeholderというそのままの名前の属性がinputおよびtextarea要素に導入されています。
placeholder属性は、ユーザーがデータを入力する際に彼らを手助けする目的で提示される短いヒント（単語や短いフレーズなど）を表す。ヒントには入力例や望まれる入力形式の説明が当てはまるだろう。この属性が指定された場合、その値にはU+000A LINE FEED (LF)やU+000D CARRIAGE RETURN (CR)が含まれてはならない。
title属性がより適切である。
placeholder属性はlabelの代わりに使うべきではない。
textareaで複数行のプレースホルダを表示することはできません。
<input placeholder="プレースホルダ">
<textarea placeholder="プレースホルダ"></textarea>
placeholderのマークアップ。プラットフォーム実装の差異
placeholder属性の実装が当時の仕様通り、フォーカス時に消えるようになっていたため、iOSネイティブ実装と一貫性がありませんでした。これを問題視したのか、AppleはSafariのエンジンであるWebKitに変更を加え、プラットフォームがフォーカス時のプレースホルダの表示状態について選択できるようにしました。この変更のためか、iOS 5のSafariはネイティブのプレースホルダと同じ挙動をとるようになりました。
何が「ヒント」となりうるか
placeholder属性やその挙動についてわかったところで、ここからはその属性の使い方について考えていきましょう。
placeholder属性は入力する内容に関し「ヒントを与える」という役割を持つことが分かりました。では、どういったテキストがその「ヒント」として適切なのでしょうか。
長い文は不適当
placeholder属性の値として想定されていないことが分かります。どれくらいが長いヒントなのかは分かりませんが、長い文でしか伝わらないようなヒントを、入力時に消えてしまうプレースホルダとして設定するのは、あまり賢いやり方ではないでしょう。
ラベル代わりの利用はダメ
label代わりに使うべきではないとあります。これが何故いけないかというと、placeholderだけではそのフィールドが何のためのものか、視覚的にしか伝わらないことが多いからです。
<input type=email placeholder="メールアドレス">labelを関連づけず、プレースホルダをラベルとして利用する例。placeholder属性の読み上げplaceholder属性のアクセシビリティについては、FirefoxとSafariで属性値の読み上げがサポートされているようです。しかし、HTML5 placeholder attribute testsによると、両者の読み上げ方には違いがあります。Firefoxではlabelが優先されますが、Safariではplaceholderが優先されてしまうようです。また、Firefoxでは、labelでラベルとコントロールを囲った場合（forで参照しない場合)、ラベルとプレースホルダがどちらも読み上げられてしまうようです。
placeholderの情報が支援技術に渡るように一部のUAで実装されていても、placeholderに対応しない環境では引き続きそのフィールドが何であるかが分かりません。placeholderをラベル代わりに使うのが問題というわけではなく、ラベルを与えないフォームフィールドがそもそも問題と考えてください。
入力内容の例示は効果的な例もある?
<input type=email placeholder="placeholder@example.com">
入力形式の表示はフォームのUI再考を
pattern属性を始めとする検証機能を利用する、JavaScriptで検証をしてそのステータスをフィールドの横に表示する、書き方をフォームの横に書くといった方法があります。プレースホルダで表示するよりももっとよい情報の提示方法があるはずです。
JavaScriptによるプレースホルダの実装は必要か
placeholder属性が導入される前から存在していたものや、古いブラウザでもプレースホルダが欲しいという要求に答えたのでしょう。
value属性の値とそのスタイルをを書き換える。
labelやtitleにプレースホルダを記述し、スタイルシートで重ねフォーカス制御を実装する。
placeholderと同じ挙動をスクリプトからで行う意義について考えてみましょう。プレースホルダはヒントを与えるもので、それがなくてもフィールドに何を入力するかは、プレースホルダなしでも理解できなければいけません。
placeholderに対応しないブラウザでも表示させる必要はあるのでしょうか。
まとめ