HTML5のinput typeはemail、url、telを入力目的で使い分ける
公開日: 執筆:佐藤
メールアドレスの入力欄にはtype="email"、絶対URLの入力欄にはtype="url"、電話番号の入力欄にはtype="tel"を使います。見た目が一行の入力欄だからtype="text"でそろえるのではなく、受け取りたい値の目的で選びます。
emailとurlは、空でない値が定められた形式に合わなければ、ブラウザーの制約検証で形式エラーになります。telには固有の電話番号書式がありません。三つとも、ブラウザーの表示や検証だけに頼らず、送信された値をサーバー側でも検査します。
email、url、telは受け取る値の意味で選ぶ
input要素のtype属性は、入力するデータの種類と、それに関連するコントロールを示します。三つの入力形式は、次の目的に分かれます。
| type | 入力の目的 | type固有の形式検証 |
|---|---|---|
email |
メールアドレス | 空でない値がメールアドレスの形式か調べる |
url |
一つの絶対URL | 空でない値が絶対URLの形式か調べる |
tel |
電話番号 | 固有の書式を強制しない |
問い合わせフォームなら、次のように項目名と入力目的をそろえます。
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email">
<label for="website">ウェブサイトのURL</label>
<input type="url" id="website" name="website">
<label for="phone">電話番号</label>
<input type="tel" id="phone" name="phone">
typeは入力の意味を示します。項目名を伝えるlabelや、空欄を認めるかを決めるrequiredとは役割が違います。
emailとurlは空欄と形式エラーを分けて考える
type="email"では、空でない値が一つのメールアドレスの形式に合わない場合、type mismatchという制約違反になります(E-mail state)。たとえば、info.example.comは@を含まないため、メールアドレス欄の形式に合いません。
type="url"が受け取るのは絶対URLです。https://example.com/のように、どの方法でどの場所へ接続するかを含む値を入れます。空でない値が絶対URLの形式に合わなければ、同じくtype mismatchになります(URL state)。
どちらも、空欄であること自体はtype固有の形式エラーではありません。空欄を認めない項目には、別にrequiredを指定します。
<input type="email" name="email" required>
<input type="url" name="website">
この例では、メールアドレスは入力必須であり、URLは空欄を認めます。入力の有無を調べるrequiredと、空でない値の種類を示すtypeを一つの機能として扱わないことが重要です。
telには一つの電話番号書式が定められていない
type="tel"は電話番号を入力する欄ですが、値へ固有の構文を強制しません。電話番号には、国番号、括弧、空白、ハイフンなどを含む多様な書き方があるためです(Telephone state)。
受け付ける書式を限定する必要がある場合は、pattern属性で条件を加えられます。ただし、条件は「電話番号とはこう書くものだ」という思い込みではなく、サーバーが受け付け、担当者が利用できる書式から決めます。
<label for="phone">電話番号 数字とハイフン</label>
<input type="tel" id="phone" name="phone" pattern="[0-9-]+">
この例は、数字とハイフンだけを受け付ける説明用の条件です。+81のような先頭のプラス記号、括弧、空白を使う番号は一致しません。それらを受け付ける運用なら、このpatternをそのまま使えません。
ブラウザーの入力UIとエラー表示は実機で確かめる
type属性によって、ブラウザーは入力目的に合うコントロールを選べます。ただし、画面に出る入力欄、候補、キーボード、エラーメッセージが、すべてのブラウザーと端末で同じになるとは限りません。
メールアドレス欄で@を入力しやすいか、URL欄で入力候補が出るか、電話番号欄で数字を入力しやすいかは、実際に対象端末で確認します。デスクトップの一つのブラウザーで一行入力欄に見えたことだけを理由に、三つをtextへ戻す必要はありません。反対に、typeを書いたことだけで操作しやすくなったと判断することもできません。
制約検証も、少なくとも次の値を入れて送信を試します。
| 入力欄 | 確認する値 | 確認すること |
|---|---|---|
email |
info@example.comとinfo.example.com |
形式に合う値と合わない値を区別するか |
url |
https://example.com/とexample.com |
絶対URLとそれ以外を区別するか |
tel |
03-1234-5678と+81 3 1234 5678 |
type自体では固有書式を強制せず、追加したpatternが書式条件になるか |
| 三つすべて | 空欄 | requiredの有無どおりに扱うか |
この表は説明用の入力例です。実際に受け付ける値は、フォームの用途と連絡方法に合わせて決めます。
サーバー側では受け付ける条件をもう一度検査する
ブラウザーの制約検証は、サーバー側の検査を置き換えません。検証を実装しない利用環境や自動処理から値が送られる場合があり、クライアント側の検証は意図して回避することもできるためです(フォームのSecurity)。
サーバー側では、各項目について次の条件を独立して確認します。
- 値が必要なら空でないか
- メールアドレスとURLは、受け付ける形式に合うか
- 電話番号は、連絡に使える文字と長さの範囲か
- 保存、メール送信、画面表示へ渡す前に必要な処理を行ったか
type="email"の形式に合うことは、そのメールボックスが存在することを保証しません。type="url"の形式に合うことも、接続先が存在し、安全に利用できることを保証しません。ブラウザーが調べる形式と、フォームの目的に必要な確認を分けます。
最初の一手は、既存フォームのメールアドレス、URL、電話番号の三項目を探すことです。それぞれのtypeとサーバー側の受け付け条件を一行ずつ書き出し、目的と指定が一致しているかを確認してください。
関連記事

