🎄Open UI Advent Calendar: Day7 / Customizable Select Element Ep.5
Published on December 7, 2024
Open UIでCSEのResearchが行われる。同時期にMSで`<selectmenu>`Explainerの作成。Explainerに基づいて、`<selectmenu>`がIntent to Prototypeに
Table of Contents
Table of Contents
🎄はじめに
Customizable Select Element Ep.4では、Greg と Mason による調査結果を受けた、Domenic による Open UI 内での初期提案について見ていきました。
今回から、これまでにどのような提案が議論され、実装されてきたのか、または議論中なのかを見ていきます。
CSE は、現状の形になる前に命名の変遷を辿ってきました。
初めは<selectmenu>だったものが、<selectlist>になり、今となっては<select>です。
最初に、この変遷の経緯を確認していきます。
<selectmenu>としての初期提案
Open UI Propsalのステージ
まず、Open UI での Proposal の進み方を確認しておきます。 Open UI では、Proposal の策定段階が 5 つの Stage に分けられており、次のように区分されます。
| Stage | 目的 | 入る基準 | 出る基準 |
|---|---|---|---|
| 0: Research | 調査内容を共有し、アイデアを統合できる状態にする | Proposalが出され、Issueが開かれている | Champion(そのテーマの責任者)が決まり、歴史的経緯の研究調査とProposalが2人のOpen UI EditorまたはChairによってApproveされる |
| 1: Editor’s Draft | Open UI内でコンポーネントのExplainerに合意し、確定させる | Usecase、Structure、Property、Behaviorなどをカバーする初期Draftが作成されている | 仕様がOpen UI EditorまたはChairによってレビューおよびApproveされる |
| 2: Community Draft | ステークホルダー（WHATWG, ARIA, CSSWG, 他開発者など諸関係者）からのレビューを受け、フィードバックを取り入れる | Open UIがEditor’s Draftを外部グループや個人からの追加レビューのためにApproveしている | ARIA、I18n、プライバシー、WHATWG、CSSWG、ブラウザ実装者、他Web開発者、Library Authorなどのステークホルダーからの承認 |
| 3: Recommendation | Proposalを最終状態に導く | Championがステークホルダーと合意を形成している | Web Platformに追加するかどうかの決定。Webコンポーネントが実装されたり、仕様が標準化団体に渡ったりする。適合度テストが行われ、Specが作成される。実装されるがまだExperimentalな状態。 |
| 4: Finished | コンポーネントが実装されたことを示す | コンポーネントが安定した実装または仕様を持っている | N/A |
よって、CSE の PR では Stage 0: Research 段階のものが最も古く、それが以下に当たります。
この PR が Research として十分な内容を含むと認められたとき、Stage 1: Editor’s Draft、つまり Explainer の作成が始まります。
<selectmenu>Explainerの作成
CSE の Explainer は、Dan ClarkによってMSEdgeExplainersの中で考案が始まりました。
当時 MS 内で Explainer を作成過程で議論されていたのが、<select>をカスタマイズ可能とする際のオプトイン方法でした。オプトインを、属性によって制御するのか、はたまた新しい要素を作成するのか。それぞれのメリット・デメリットが MS・WHATWG で検討されました。
最初の問題提起をした Dan の主張を簡単にまとめると、
<select>をカスタマイズ可能にするには、互換性を保つためにオプトインさせる必要があり、２通りの方法がある
custom属性を付与する方法
- 例えば、
<input type="range">をカスタマイズ可能にしたいとなった場合、<input>は HTML パーサによって子に DOM の追加が制限されているため、<range>などの新しい要素を実装する必要がある - しかし、
<select>は HTML パーサが子に DOM の追加を特に制限していないため、カスタマイズ可能にするために新しい要素を作成する必要はない - よって、
<select custom="">のような属性を用いてオプトインすると良いと考えているが、以下に挙げる問題もあるcustom属性の有無によって<select>のパースの仕方を変えることになるので、パース中にcustom属性を動的に追加/削除された場合の正しい挙動を再現する実装が難しそう
- （おそらく、もし今後の話：）
<input>をカスタマイズ可能にするとなった時、新しい要素を作成することになるので、<select>に対してだけcustom属性を導入するのは一貫性がない
<selectmenu>のような新しい要素を導入する方法
custom属性を使うのではなく、新しい要素を導入する方法もあるが、次のような問題がある- 命名はどうするのか。
<selectmenu>はどうか？ - 既存の
<select>とほぼ同等の機能を持つ新要素に対する抵抗感を招く可能性がある
- 命名はどうするのか。
これは最初 MS 内で議論された内容でしたが、WHATWG にも提案が持ち込まれ、より多くの関係者を交えた議論となります。
ここでの議論の結論としては、以下です。
<input>+<datalist>によって実現される Combobox のような形式にも適応できるようにする<option>に任意の HTML を指定できるようにする<select>の各部品はカスタマイズ可能にする- ポップアップ（ドロップダウン部分）は window の範囲を超えないようにする
- 以上の機能を持った
<select>を、新しい要素として実装する
この「新しい要素」が<selectmenu>となって、MS の Explainer を元に実装着手が意思表示されます。
こうして、一旦は仕様が固まった<selectmenu>でしたが、どうして<selectlist>に改名され、最終的に<select>になったのか、次回以降で見ていきます。
それでは、また明日⛄
See you tomorrow!
