目次
WebKitは2026年10月26日、Safari 27.2でCustomizable Selectの表示と配置を改善したと発表しました。選択済みの文字を装飾する::field-contentが加わり、選択内容のためにHTML要素を増やさず調整できる場面が広がります。フォームを作るチームは、独自のドロップダウンへ置き換える前に、標準のselectを残して見た目を改善する方法を検討できます。
本稿は2026年10月28日に確認した公式資料に基づく動向と実装の解説です。対象は一つの値を選ぶ通常のドロップダウンで、複数選択や検索付きコンボボックスを作る記事ではありません。掲載コードは段階導入を考えるための例で、Safari実機での動作確認は行っていません。採用時には利用者のブラウザーと入力方法で検証してください。
2026年10月28日追記：提供状況を公式発表で確認しました。Safari 27.2はiOS 27.2、iPadOS 27.2、visionOS 27.2、macOS 27.2 Golden Gate、macOS Tahoe、macOS Sequoiaで提供されています。前四者は「設定」の「一般」からソフトウェアアップデートでOSとともに更新します。旧版macOSでSafariのみを更新する場合は、ソフトウェアアップデートの「詳しい情報」から確認します。検証端末を選ぶ際はSafariの版に加え、OSの版も記録してください。提供対象の根拠は本文のWebKit公式解説の「Updating to Safari 27.2」です。
スポンサーリンク
Safari 27.2で何が変わったか
根拠はWebKitのSafari 27.2公式解説です。Customizable Selectそのものは27.0で導入済みで、27.2はその改善です。::field-contentで閉じた状態に表示される選択肢の文字を装飾できるほか、選択文字のtext-overflowの継承や矢印の配置など、ブラウザー既定のスタイルにも調整が入っています。
今回の変更は、すべてのブラウザーで同じ描画になることを意味しません。また、新しい擬似要素への対応と、カスタマイズ可能なselect全体への対応も分けて確認します。Safariの新版で表示が整ったからといって、旧版へ同じCSSを配れば同じ結果になると仮定しないでください。利用する機能ごとに、未対応時に残す動作を決めます。
実務では、長い選択肢が矢印へ重なる、閉じた状態で文字が切れる、開いた一覧が画面端で操作しにくい、といった既存の調整を見直すきっかけになります。既定スタイルの改善後も古い負のンや固定幅を重ねると、別のずれが起きる可能性があります。追加CSSを増やす前に、以前のを外した最小状態で比較することを勧めます。
まず通常のHTMLだけで選択と送信を成立させる
最初の実装では、label、select、optionを使ったフォームを作ります。装飾が読み込まれなくても、何を選ぶ欄か分かり、選択値を送れることを基準にします。以下は配送方法を一つ選ぶ例です。値は配送方法を識別するための説明用コードで、実際の業務定義へ置き換えます。
<form id="delivery-form">
<label for="delivery">配送方法</label>
<select id="delivery" name="delivery" required>
<option value="">選択してください</option>
<option value="standard">通常配送</option>
<option value="scheduled">日時指定配送</option>
<option value="pickup">店舗で受け取り</option>
</select>
<button type="submit">確認する</button>
</form>表示用の日本語と送信するvalueを分けると、ラベルを変えたときも処理の識別子を維持できます。placeholderに見える最初の選択肢も通常のoptionなので、空値を許すか、必須にするかを業務側で決めます。見た目の変更と同時に値や必須条件まで変えると、何が不具合を生んだかを追いにくくなります。
selectの内容とフォームの関係はWHATWGのHTML Standardで確認します。装飾を始める前に、通常の選択、初期値、送信値、無効状態を確認してください。画面で文字が見えるだけでは、サーバーへ意図する値が送られることまでは証明できません。
スポンサーリンク
対応する環境だけbase-selectを有効にする
基本的なカスタマイズ方法はMDNのCustomizable select解説でも説明されています。selectと::picker(select)へappearance: base-selectを指定して、カスタマイズ可能な表示へ参加させます。本稿では通常のselectを基礎にし、対応する環境にだけ追加スタイルを適用します。
#delivery {
font: inherit;
max-inline-size: 100%;
}
@supports (appearance: base-select) {
#delivery,
#delivery::picker(select) {
appearance: base-select;
}
#delivery {
inline-size: 18rem;
padding: 0.75rem;
border: 1px solid #58616a;
border-radius: 0.5rem;
background: #fff;
color: #17212b;
}
}
@supports selector(select::field-content) {
#delivery::field-content {
font-weight: 600;
}
}最後のブロックは、::field-contentを理解する環境で選択文字の太さを変える例です。この装飾を読み取れない環境でも、配送方法そのものを選べる構造を維持します。@supportsは構文への対応を確認する材料で、実際の見た目や支援技術の操作を保証する試験ではありません。CSSの条件が真になったことだけで検証完了にしないでください。
未対応環境のために、同じ選択内容を持つ別の疑似UIを常時重ねる必要はありません。二つの入力を同期させる構成にすると、片方の値が古い、片方だけ必須、送信名が重複するなど、管理する状態が増えます。今回の目的が色や余白の調整なら、最初は一つのselectに限定する方が原因を追いやすくなります。
selectedcontentを足す必要があるか先に決める
選択済み表示に複雑な内容を使いたい場合は、selectの先頭のbutton内へselectedcontentを置く方式もあります。これは単に文字を太くするための必須部品ではありません。今回のSafariの改善を使えるなら、普通のoptionだけを維持できる場面もあります。HTML構造を増やす前に、必要なのが文字装飾なのか、選択内容の構造そのものなのかを整理します。
構造を増やす場合は、既存JavaScriptの前提を点検します。例えばselect.firstElementChildを最初のoptionだとみなすコードは、先頭へbuttonを入れると別の要素を指します。候補一覧が必要ならselect.optionsを使うなど、目的に合うへ切り替えます。画面の見た目だけ変えたつもりでも、の順序に依存する処理には影響が出るためです。
選択肢の内容が複製される表示へ、クリック可能なリンクや独立した操作部品を安易に持ち込むことも避けます。選択欄が一つの操作として理解できることを優先し、各選択肢に別の操作を詰め込まない設計にします。単純な配送方法の選択を、説明文やボタンだらけの小さなアプリへ変える必要があるかを先に見直してください。
スポンサーリンク
長い文字列は省略の有無より識別できるかを見る
選択済み文字を省略すると欄の幅は保ちやすくなりますが、肝心の違いが見えなくなる場合があります。例えば二つの配送方法が同じ長い接頭辞を持ち、末尾だけ違うなら、末尾を隠すと選び直せません。文字の切れ方を装飾の問題だけで扱わず、候補名の付け方や説明の置き方も検討します。
テストには短い候補だけでなく、実際に最長になる候補名を入れます。日本語、英数字、括弧、追加料金の表記など、業務で使う組み合わせを確認します。狭い画面と拡大表示で、矢印が文字へ重ならないか、選択後の表示が識別できるかを見ます。固定の高さで文字が切れるなら、余白や行高の調整も候補にします。
一覧を開いたときと閉じたときで、伝わる情報が矛盾しないことも大切です。開いた一覧だけに重要な条件を入れて、閉じると単なる短い名称になる設計では、確認画面へ進む前に選択内容を誤解する可能性があります。必要な条件を補助テキストへ出す場合も、どの配送方法への説明なのかが分かる位置に置きます。
キーボードと読み上げの確認を別の工程にする
マウスで一度選べたことだけでは採用判断に足りません。キーボードだけで欄へ移動し、開閉、候補の移動、決定、次の欄への移動を確認します。期待するキー操作はOSやブラウザーの標準動作と照合し、独自のキー制御を付け足す前にネイティブの動きを観察します。フォーカスの位置が見えることも受け入れ条件です。
読み上げでは、欄の名前、現在の値、必須かどうかなど、フォームとして必要な情報が伝わるかを確認します。装飾のために同じ文字を重複させると二重に読まれる場合もあるので、見た目に表示された内容と支援技術が読む内容をそれぞれ確認します。色やアイコンだけで配送方法の差を伝えず、文字で理解できる名称を残します。
スマートフォンではタッチと文字サイズの設定も確認します。デスクトップの表示幅を狭める試験は便利ですが、実機の入力方式やOSの選択UIまで同一にはなりません。主要な利用環境を選び、ブラウザーの版とOS、入力方法、再現手順を記録します。本稿のコードを使っただけでアクセシビリティ対応が完了したとは扱わないでください。
SSRとフォーム送信を含む実アプリで検証する
静的なHTMLで問題がなくても、実アプリのフレームワークが生成するDOMやハイドレーションで結果が変わる場合があります。MDNもフレームワークとSSRの組み合わせに注意を促しています。最小サンプルの後は、本番と同じレンダリング方式で確認し、コンソールの警告、初期値のずれ、操作後の再描画を調べます。
フォーム送信は、表示名の確認とは別に実データを見ます。選択した配送方法のvalueがnameに対応して送信されるか、エラー後の再表示で値が維持されるか、リセットで意図する初期状態へ戻るかを確認します。CSSを外した比較版でも同じ業務結果になるなら、見た目の差と送信処理の差を切り分けやすくなります。
既存のフォーム部品ライブラリーがselectを包んでいるなら、その部品が何を制御しているかも確認します。JavaScriptで別のリストを描画する部品へbase-selectを足しても、標準selectのピッカーへ装飾が届くとは限りません。見た目を統一するためにCSSを増やし続ける前に、実際に操作されている要素を開発者ツールで特定してください。
小さなフォームで採用して戻せる状態を保つ
初回は配送方法など一つの欄へ絞り、既存CSSとの差分を小さくします。採用条件を、選択できる、送信値が同じ、長い候補を区別できる、主要入力方法で操作できる、に置きます。新版で直った回避策を残すか外すかも記録し、単にスクリーンショットがきれいになったことだけで完了にしないようにします。
問題が出たときに追加スタイルを外して通常のselectへ戻せるよう、拡張用のCSSをまとめて管理します。新しい要素を追加する場合は、それを前提としたスクリプトの変更も一組で扱います。Safari 27.2の改善を入口として、選択欄の標準機能を生かしながら、見た目と業務上の動作を別々に検証する導入へつなげましょう。
スポンサーリンク
関連記事
selectの先頭・末尾のoptionを取得する既存解説も参照できます。記事中のfirstElementChildを使う例は先頭がoptionの構造を前提にしています。buttonを追加する構成では同じ前提を使わず、optionsコレクションなど目的に合う取得方法を選んでください。
参考資料
WebKit：Safari 27.2の機能と改善（2026年10月26日）
MDN：Customizable select elements
WHATWG HTML Standard：selectとフォーム要素
