目次
🎄はじめに
🎄 この記事はOpenUI Advent Calendarの7日目の記事です。
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!