Making <option> a first-class citizen (and other <select> tweaks)

Continuing the discussion from Extending <select> a la chosen/select2:

I don’t have any specific familiarity with select2 or 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 :selected and :collapsed.
• Allow styling of <option>, with a sensible standard style based around traditional text-content <option>s.
  • The default style for a child of <select> includes 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.