Stylish Select

WHATWG has been working on improvements to HTML’s select element to allow much greater control over style. The proposal is quickly approaching release status. Google Chrome (Canary 130) currently has preliminary support and is seeking feedback. You can read all about that here. Be sure to also read about the recent updates to the proposal here (or you will be confused)!

It’s great WHATWG is tackling this long outstanding need, and I think they are clearly on the right track, but it is also clear to me that the proposal still has a bit more room for improvement.

Simple Container of Options

Probably the most significant need for customizing the style of a select element is a way to style the container of options the user sees when the select button is clicked — the so called “dropdown” or “popover”. And honestly, nothing could be simpler than just adding exactly that: a container of options.

<select>
  <options>
    <option value="1">A</option>
    <option value="2">B</option>
    <option value="3">C</option>
  <options>
</select>

By simply adding this plural options tag to contain the list of options, we don’t need the pseudo-selector::picker(select) in CSS, we need only use options { }. Using an actual container element is much better then depending on pseudo-selector — a pseudo-selector should really only be used if there is no other reasonable means to selecting the target element(s). Using the options element clearly delineates the select as a button from the portion that is the dropdown/popover. It also helps make it clearer that we can add extra content before, after, or even in between option tags. This new options tag would be assumed when not present, ensuring backward compatibility, much like tbody is for tables.

Detached Options

With this plural options tag in place, we can easily envision another good design adjustment: it should be possible to detach the options container from the select button. When options is inside select, it is naturally anchored to it. But that might not be what we want! For instance, perhaps we want the options box to be a modal. We can accommodate this with a for attribute.

<select for=“myopts” />
<options id=“myopts”>
 …
</options>

This also gives us a much better conception of what select itself actually is: It is the button. We don’t really need a redundant button tag inside of it. [This button has been removed from the proposal. Yeah!]

Making a Selection

The original proposal put forth the use of selectedoption to specify where the selected option’s content will be duplicated into the select button when selected (what a mouth full). This has been recently changed to selectedcontent — a clear improvement. But, it occurs to me there is a single word that conveys the needed meaning quite precisely and more concisely, that is simply, selection. I don’t think the longer two-word smush, “selectedcontent”, conveys any significant additional meaning where just “selection” would do just as well if not better.

In addition, I was wondering what if we put content in this element? Would it just be ignored? Seems to me it makes an excellent place for placeholder text — no need for that odd blank value option that is sometimes used for this purpose.

So, putting it all together in a simple example, we might have something like this:

<select>
  <selection>Please Vote</selection>
  <options>
    <option value="1">Yea</option>>
    <option value="0">Nay</option>
  </options>
</select>

Some Added Value

My last two idea’s are a bit outside the scope of styling, but nonetheless play an important role in the web designers handling of the select element.

The first idea, which I have longed to see become a standard feature of the select element ever since I first started web development, is to not need to use the selected attribute to select an option, but instead have the option with a value matching the select element’s value attribute be automatically selected.

<select value="blue">  <!-- Since value is blue... -->
  <selection></selection>
  <options>
    <option value="red">Red Pill</option>
    <option value="blue">Blue Pill</option>  <!-- this option is selected -->
  </options>
</select>

Should the selection change then the value of the select element would likewise change —just as the content of the new selection element changes. This would provide a significant ergonomic improvement to web templates since they would no longer require a loop with an if-condition to decide when to insert the selected attribution. (Note, I also think multi-selections should not be allowed and instead should be a completely different element.)

Finally, I will quickly add that the select element also needs a readonly attribute. How it has gotten along without it for so long is pretty sad — after all, select is ultimately an input element, just one with a predetermined list of choices, and like input one should be able to set it to read-only.

And with that, I think I have covered everything I feel the need to address on this subject. With these improvements, styling HTML’s select element would be enhanced in a very clear and obvious manner and provide increased flexibility for the web designer.