🎄Open UI Advent Calendar: Day 5 / Customizable Select Element Ep.3

はじめに

🎄 この記事はOpen UI Advent Calendarの5日目の記事です。

Customizable Select Element Ep.2では、ブラウザエンジンの発展と、Web標準の台頭、より柔軟なスタイリングを可能にした歴史を見ていきました。

ほとんどのForm Controlのスタイリングが可能に

OSへの技術的な依存が解消されて、標準に則ったブラウザレンダリングエンジンによる描画がおこなわれるようになったことに加え、CSS3の登場により、ほとんどのForm Controlに対してスタイリングが可能になりました。

例えば、以下の要素ではほとんどのスタイリングが可能です。

<form>
<fieldset>、<legend>
<input> （type = text, url, email） <input type="search"> 以外
<textarea>
ボタン（<input> と <button> の両方とも）
<label>
<output>

しかし、レンダリングのOSへの依存が解消されてからも、<select>などの「入力時になんらかの特殊要素を必要とするもの」に関しては、スタイリングが困難なままでした。

CustomizableでないForm Controlたち

CustomizableでないForm Controlが存在する根幹の原因は、1995年にHTML2.0に定義されたForm Controlの仕様まで遡ります。

RFC 1866 - Hypertext Markup Language - 2.0 - Forms

Ep.1でも見たように、当初の仕様では、HTMLドキュメントにデータを入力する方法、そのデータを使用してアクションを実行する方法のみが定義され、Form Controlの具体的な構築方法は各ブラウザに委ねられていました。

標準化されていなければ、クロスブラウザの互換性を保つことができないため、Form Controlをスタイリング可能にする改善を加えることも現実的ではなくなります。

例えば、<input>のtype属性に”range”を指定するとスライダーを表示させることができますが、ブラウザ・OS間で見た目が一貫しておらず、かといってスタイリングしたり内部のDOMを制御したりすることはできません。

<input type="range" id="volume" name="volume" min="0" max="11"></input>

スライダーはShadow DOMとしてレンダリングされるため、外部から変更できない スライダー内部はShadow DOMとしてレンダリングされるため、外部から変更できない

CSS property compatibility table for form controls - Learn web development | MDN

初期の仕様策定の段階で、具体的な実装方法が詰められることがなく、各ブラウザで実装が進められてきた結果、ネイティブの見た目の一貫性・スタイル可能性と拡張性が著しく欠けたままのForm Controlは多く存在しています。

かといって、ネイティブForm Controlを使用せずにイチから実装しようとすると、アクセシビリティやパフォーマンス、セキュリティなど、非常に多くの考慮事項が発生します。もし仮に、完璧なARIAロールを持ち合わせ、パフォーマンスもセキュリティも問題ないようなカスタムForm Controlを実装できたとしても、長期的にその独自Form Controlが動作するかというと、それは保証されていません。

独自Form Controlを構築する上で必要だった実装の一部が、いつの日かWebプラットフォームから廃止されてしまうリスクも考えられます。

例えば以下は、代替手段が出現したり、後方互換性の維持のために一時的に存続しているものの、いつWeb標準から削除されるかわからない技術といえます：