Continuing the discussion from Extending <select> a la chosen/select2:
I don’t have any specific familiarity with
chosen, but, after giving this a little more thought, these are a few simple changes/extensions to the existing element that would fit the way I’ve seen
<select> traditionally “extended”:
- Loosen the allowed content rules for
<option> from text content to phrasing content. (This shouldn’t break any existing web content, as phrasing content is a superset of what was allowable before.)
- Expose UI events on
<option> elements and their children.
- Add pseudo-selectors for
- Allow styling of
<option>, with a sensible standard style based around traditional text-content
- The default style for a child of
display: block when not collapsed, and
display: inline-block when collapsed.
- Allow an
<input> child inside
<select>, for implementing search boxes / “new item” input (which receives keyboard events when the
<select> is opened instead of the current UA behavior).
This could be polyfilled with a script that replaces
<select> on a page with a custom element (in the traditional mocked-UI sense, not necessarily in the Web Components sense). The one thing only UAs can do is present the
<select> elements in a frame that extends beyond the viewport (this is a significant issue for Chrome Extension popups).
Past this, it might be possible to start standardizing some more-complex-but-common behaviors (like having the
<input> filter the list of displayed
<options>), but it feels like these would be the necessary first steps.