結論
<input list="..."> と <datalist> は、候補が数十件程度で見た目のカスタマイズが要らない社内フォームなら、まずこちらから検討してください。JavaScriptを1行も書かずに入力補完が動き、キーボード操作も含めてブラウザが面倒を見てくれます。
一方で、候補の絞り込み方（部分一致か前方一致か）やドロップダウンの見た目はブラウザに委ねるしかなく、実質的にスタイリングできません。候補にハイライト表示や画像・補足情報を添えたい、候補の絞り込みロジックを自分で制御したい、スマートフォンでも同じ見た目を保証したい、というときは自作サジェストに寄せます。
見た目を問わない社内向け入力補完はdatalist、顧客向け画面やデザインを合わせたい場面は自作。分岐点は「スタイリングが要るかどうか」の一点。
両方の動くデモ
左の<datalist>は都道府県名の文字列そのものと比較するため、「とう」とひらがなで打っただけでは候補が出ず、「東京」のように漢字に確定してはじめてヒットします。右の自作版は読み仮名も検索対象に加えているので、ひらがなを打っている途中から候補が絞り込まれます。同じ「とう」で試して、この違いを比べてみてください。
- 追加のJavaScriptなし
- 絞り込み方はブラウザ依存
- 見た目はスタイリング不可
- keyupのたびに候補を再描画
- 絞り込みロジックを自分で書く
- ハイライト・見た目は自由
左のdatalist版は、Chromeでは入力文字を含む候補が部分一致で残ります。一方でSafari（macOS/iOS）は前方一致寄りの絞り込みになりやすく、同じ入力でも表示される候補の数が変わります。ドロップダウンの背景色やフォント、候補1件の高さといった見た目は、どのブラウザでもCSSから直接触れません。右の自作版は絞り込みロジック（この例では部分一致＋マッチ部分のハイライト）も見た目も自分で決めているため、どのブラウザでも同じ挙動になります。
比較表
実装で差が出る項目を並べます。「スタイリング」と「絞り込みロジック」の2行が、この記事の判断軸に直結します。
| 項目 | datalist（標準機能） | 自作サジェスト（JS + ul） |
|---|---|---|
| 基本の実装 | <input list="..."> と <datalist> を紐づけるだけ。JS不要 |
入力イベントの監視、候補の絞り込み、リストの描画をすべて自分で書く |
| 絞り込みロジック | ブラウザ任せ。部分一致寄りか前方一致寄りかがブラウザによって変わる | 部分一致・前方一致・あいまい検索など、要件に合わせて自由に実装できる |
| スタイリングの自由度 | ドロップダウンの背景・フォント・候補の高さは実質的に触れない | ハイライト・アイコン・補足テキストの追加まで完全に自由 |
| ブラウザ・OS間の見た目差 | Chrome・Firefox・Safariでドロップダウンの見た目と挙動が異なる（後述） | 普通のDOM要素なのでどのブラウザでも同じ見た目になる |
| スマートフォンでの挙動 | iOS Safariはキーボード上部のツールバー的な表示になるなど、PCと見た目が大きく変わる | PCと同じUIをそのまま出せる（タップ操作の考慮は別途必要） |
| キーボード操作 | 上下キーでの候補選択・Enterでの確定がブラウザ標準で動く | 上下キー・Enter・Escの挙動をイベントハンドラで自分で実装する |
| 候補が多いときの挙動 | 件数上限や表示速度はブラウザの実装依存。制御できない | 件数の絞り込み（例: 上位8件のみ表示）やAPI経由の非同期取得も自由に組める |
| ブラウザ対応 | Chrome・Edge・Firefox・Safariの現行版すべてで基本機能は対応済み | 普通のDOM操作なので対応の心配は基本的にない |
| 実装量の目安 | マークアップのみ。JS 0行 | 絞り込み・描画・キーボード操作・外側クリックでの閉じるまで含めると数十行 |
datalistがJavaScriptなしで持っている挙動
<input> の list 属性に <datalist> の id を指定するだけで、入力中に候補がドロップダウン表示されます。
<input type="text" list="pref-list"> <datalist id="pref-list"> <option value="東京都"> <option value="大阪府"> <option value="福岡県"> </datalist>
候補の絞り込み・上下キーでの選択・Enterでの確定は、すべてブラウザが内部で処理します。input 要素自体は普通のテキスト入力のままなので、選んだ値は他のテキスト入力と同じように value から取得できます。候補にない自由入力もそのまま許可される点も、<select>との違いです。
ただし絞り込みの挙動はブラウザの実装依存です。Chromeは入力文字列を含む候補を部分一致で拾いますが、Safariでは前方一致に近い絞られ方になることがあり、同じ入力でも表示される候補の数や順序がブラウザによって変わります。この挙動は仕様で厳密に定義されておらず、CSSはもちろんJavaScriptからも調整できません。
スタイリングの制約はさらに大きく、ドロップダウンの背景色・文字サイズ・候補1件あたりの高さ・スクロールバーの見た目は、どのブラウザでも通常のCSSセレクターで触れません。<option> に装飾を足すことも、候補に画像やアイコンを添えることもできません。
スマートフォンでの見え方の差はもっと露骨です。iOS Safariでは候補がキーボード上部のツールバー的な領域に一覧表示されることがあり、Androidの主要ブラウザでの表示ともPCの見た目とも違います。「どの端末でも同じ体験にしたい」という要件がある時点で、datalistは選択肢から外れます。
自作サジェストで作り込めること
上のデモの自作版は、input のinputイベントごとに候補配列をフィルタし、結果を <ul> に描画し直す実装です。マッチした部分文字列を <mark> でハイライトする処理も自前で書いており、これはdatalistでは不可能な表現です。
input.addEventListener('input', function () {
var query = input.value.trim();
var matches = list.filter(function (item) {
return item.indexOf(query) !== -1; // 絞り込みロジックを自分で決められる
});
renderList(matches);
});
上下キーでの候補移動とEnterでの確定も、keydown イベントで自分でハンドリングしています。role="combobox" と aria-expanded、候補側の role="option" の付与も、標準機能なら不要な作業です。「見た目とロジックを自由にできる代わりに、標準で付いてくる挙動を全部自分で書き直す」という構図は、このテーマで扱ってきたdialogやdetails/summaryの比較記事と同じです。
候補が数百件以上になる場合や、サーバーから非同期で候補を取得したい場合も、自作サジェストなら実装できます。datalistは静的な<option>の集合を前提にした仕組みで、動的な絞り込みAPIとの相性は良くありません。
業務アプリでの選び方
ここまでを踏まえて、実際の判断軸を挙げます。
社内向けの軽い入力補完はdatalist
候補が数十件程度で、見た目の統一よりも実装コストの低さを優先したい社内フォームなら、まずdatalistを検討してください。マークアップだけで済み、保守の手間もほぼありません。
顧客向け画面やデザイン統一が必要なら自作
候補にハイライトや補足情報を出したい、スマートフォンでも同じ見た目にしたい、候補件数が多く非同期取得が必要、といった要件が1つでもあれば自作サジェストに寄せます。キーボード操作とARIA属性の実装まで含めて見積もってください。
なお、両者は同じフォーム内で使い分けても問題ありません。社内管理画面の検索条件はdatalist、顧客向けの申込フォームは自作、という切り分けは十分成立します。
まとめ
datalistは、追加のJavaScriptなしで入力補完・キーボード操作まで手に入る標準機能です。候補が少なく見た目を問わない場面では、この手軽さに勝る実装コストの選択肢はありません。
ただし絞り込みの挙動とドロップダウンの見た目はブラウザ・OSごとに差があり、スタイリングもほぼ制御できません。顧客向けの画面でデザインを揃えたい、候補にハイライトや補足情報を出したい、という要件があるなら、最初から自作サジェストを選ぶ方が結果的に手戻りが少なくなります。自作でどこまで作り込むかの実装は、上の動くデモのコードをそのままコピペして確認できます。