logo

🎄Open UI Advent Calendar: Day 9 / Customizable Select Element Ep.7

Published on December 9, 2024

`<selectmenu>`のその後：`<selectlist>`から`<select>`に至るまで

Table of Contents

Table of Contents

はじめに

Customizable Select Element Ep.6では、<selectmenu>が改名され、<selectlist>に至るまでの経緯をお話ししました。

しかし、現在の CSE は<selectlist>ではなく、<select>としてRFCが発表されています。今回は、<selectlist>から、<select>に変遷するまでの経緯をお話しします。

<selectmenu>のその後：<selectlist>から<select>に至るまで

主に既存の UI パターンとの混乱を避けるための様々な考慮がなされ、<selectmenu>は<selectlist>にリネームされました。

本格的に<selectlist>の運用が始まる中で、whatwg/html に、<select>の HTML/CSS に関する Issue と PR をまとめた Issue が開かれました。

そして、この Issue を皮切りに、<selectlist>から<select>への移行が検討されていくことになります。

まずその口火を切ったのが、Apple で WHATWG のAnne van Kesterenでした。その後の会話からすると、次の提案は Anne と Joey Arhar を含む colleagues の間で話し合われ、それを Anne が代表してここにまとめていることがわかります。

提案の内容は以下です。

Thank you for bringing this proposal to the WHATWG Joey! I thought this would be a good opportunity to outline how colleagues and I feel about extending HTML in this area. In particular, we feel that new and existing form controls:

  • Should look the same as the operating system controls by default.
  • Should be fully styleable by web developers.
  • Should generally attempt to follow existing HTML element patterns.
  • Should not be redundant with existing HTML form controls.
  • Should work on a wide variety of platforms, including those with very small screens, no mouse or touch, etc.
  • Should be fully accessible.
  • Should not have any l10n or i18n shortcomings.

We understand that the select element can’t address a variety of scenarios due to parser limitations, but the select element could address them in combination with the datalist element. One of our big worries with complete duplication is that we end up not solving the problems with the existing controls and that the duplicated controls will have a variety of shortcomings the older controls did not have. https://github.com/whatwg/html/issues/9799#issuecomment-1770254871

このコメントの内容を理解する前に、まず、CSE が別要素として仕様策定されるべきだと判断された根拠を振り返ってみましょう。

CSE の Explainer は、当初 MS 内で検討が始まりましたが、その過程の中で次のような議論が交されていました。

@mfreed7 pointed out that we’d need to deal with the fact that the custom attribute could be added/removed dynamically, which adds complexity. Parsing is particularly concerning here, since the attribute would change the parsing rules for the subtree of the <select>. Is there any scenario where a <select> could have script change it to custom when we’re in the middle of parsing its subtree?

つまり、Opt-inするための属性の有無によって<select>のパースのされ方が変わることになるので、パース中にOpt-inするための属性を動的に追加/削除された場合、正しい挙動を再現する実装が難しいということでした。

const combobox = document.createElement('select');
document.body.appendChild(combobox);
combobox.addAttribute('newbehavior','true'); // Opt in!
combobox.innerHTML = '<option><img src="cat.jpg">Cat</option><option><img src="dog.jpg">Dog</option>';
// Here, we have a fancy, new <select> with images of cats and dogs
// https://github.com/whatwg/html/issues/5791#issuecomment-671477100
const combobox = document.createElement('select');
document.body.appendChild(combobox);
combobox.innerHTML = '<option><img src="cat.jpg">Cat</option><option><img src="dog.jpg">Dog</option>';
combobox.addAttribute('newbehavior','true'); // Opt in, but a little late
// Boo! No images here, because we opted in after innerHTML, and the parser removed the <img> tags.
// https://github.com/whatwg/html/issues/5791#issuecomment-671477100

これによって、CSE は別要素として実装される方向に舵が切られました。

対して、先ほどのAnneのコメントからは、別要素で実装することで考えられる別の問題点が挙げれられています。

the select element can’t address a variety of scenarios due to parser limitations, but the select element could address them in combination with the datalist element. One of our big worries with complete duplication is that we end up not solving the problems with the existing controls and that the duplicated controls will have a variety of shortcomings the older controls did not have.

select要素はパーサーの制限によりさまざまなシナリオに対応できないが、datalist要素と組み合わせることで対応できる。 最大の問題は、既存のControl（つまり<select>）の問題はそのままになり、複製されたControl（つまり<selectlist>）には、<select>にはなかったさまざまな欠点が生じる可能性があることです。

CSE は<select>を”完全に”カスタマイズ可能にすることを目指しているので、<select>の中に入れる要素やその構造も制限されないようにしなければなりません。

しかし、当初考えられていた「<select>に Opt-in 属性を追加する方法」では、パースタイミングの問題により、<select>の中に入れる要素が制限されてしまう可能性がありました。

そのため、<select>とは別要素として実装する必要があるという結論に至ったのですが、「<selectlist>の中に入れるポップアップ内の任意要素は<listbox>でラップする」というのが当時の<selectlist>の仕様でした。

<selectlist>
  <button type="selectlist">
    <selectedoption></selectedoption>
    <span>Felids</span>
  </button>
  <listbox>
    <input type="search">
    <div tabindex="-1">
      <option value="Asian golden cat">Asian golden cat</option>
      <option value="Bay cat">Bay cat</option>
      <option value="Marbled cat">Marbled cat</option>
    </div>
  </listbox>
</selectlist>

しかし、これは既存の<select>と<datalist>との組み合わせで実現可能であると Anne は主張します。

加えて、<selectlist>という別要素として実装した場合、既存の<select>と<datalist>の問題は解消されません。Progressive Enhancement の観点からも、<select>を採用を検討したいとのことでした。

さまざまな意見が交換された結果、Anne の提案通り、2023/12 の段階で次のようにまとまることになります。

  1. Reusing the <select> element will work: <select>は CSE の実現に利用できる
  2. We can change the parser for <select> to allow particular new child tags like <button> and <datalist>: <select>のパーサーを変更して（緩めて）、<button>や<datalist>などの新しい子要素を許可できる
  3. We can work incrementally, first by making these parser changes in the spec etc.: まずは仕様などでパーサーの変更を行い、段階的に進めることができる
  4. Using <datalist> as a child of <select> will work to replace the listbox with custom content: <select>の子要素として<datalist>を使用することで、listbox をカスタムコンテンツで置き換えることができる

この WHATWG での議論の結果を以て、Open UI でも正式に<selectlist>/<listbox>から<select>/<datalist>を使用することに決定され、Open UIのselectlistのExplainerも<select>に変更されました。

I updated the explainer to be <select> instead of <selectlist>: https://open-ui.org/components/selectlist/ https://github.com/whatwg/html/issues/9799#issuecomment-1885356884

<selectlist>から<select>への変更理由は、最近 developer.chrome.com から発表された RFC でも触れられています。

Allow