For <option> elements it should be allowed to place other elements inside them. Especially <img> and <picture> elements are useful, but also other phrasing content elements like <b>, <em>, <ruby>, <time>, etc. should be supported.
Sebastian
[1] I’ve initially asked for that at https://github.com/w3c/html/issues/996, but got asked to discuss it here first.
Agreed, but IIRC <option> is rendered by the OS, not the browser, which is also why styling it is next to impossible in most cases.
At least Edge displays the dropdown differently than other browsers, so I assume they are not necessarily rendered by the OS, but I don’t know whether the browsers or other UAs currently use the OS rendering. Also, the <select>s themselves can be styled. Furthermore, <option>s can be styled when they’re within a <select multiple> element. See https://jsfiddle.net/53rb5bLt/ and the related Firefox bug I’ve filed.
At least a related CSS 2.2 spec. note explicitly doesn’t restrict the styling saying
CSS 2 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.
But coming back to the HTML aspect, allowing other elements to be placed within <option> elements would allow to provide some semantical meaning for the options.
Sebastian
Given the number of custom built “select” style plugins and react components, it seems like this is something that would be used by thousands of websites.
I’ve seen so many that have such poor accessibility as well, so I’d hope that a default browser built implementation could improve upon this.
I’d like to see cases in which the UX is substantially improved with images in a select node. Every example I’ve seen are nonsense uses at the end of the day.
Adding images into option elements brings in the concept of the box modal and layout to them. This is something that currently doesn’t exist. It’s a lot of extra complexity for a ux pattern that is actively discouraged in most use cases for already being difficult to use.
Do we really need to encourage browser vendors to revisit these already well understood elements? Or should we focus on evangelizing better ux patterns that actually help more end users to begin with?
From my perspective, this is just an extension of selecting from a group more complex data. This could also be selecting one image from a list of many.
Yes, this isn’t strictly necessary, since we can build the components with more basic components and JS, but it’s a common enough problem where something a little more standard seems useful
https://github.com/w3c/html/issues/995 shows the Facebook search box, which was linked to the original GitHub issue as a possible use case for this.
How would mobile browsers like iOS handle rendering this in their views? It’s a big ask to ask for more to be shoved into their full-screen view. Which is currently fairly solid on accessibility.
Some of the rendering on different platforms is done by the host OS itself. It can vary yes, but none-the-less it exists for the best accessibility since it follows the existing paradigms for user son those platforms. It also brings the options outside of the stacking context in various areas to make sure the options are highly visible.
Why should browser vendors revisit this time-tested element and make changes to it? Even with the Facebook example, I don’t see where introducing layout into options as a justifiable ask. In some cases we are asking for browser to entirely engineer a new rendering method instead of passing it off to the host machine. Simply to achieve one semi-useful use-case. That isn’t a justified return-on-investment to move the web forward for the majority of users.
The same as on desktop browsers. That means, the default rendering would still be the same, though you can influence it e.g. via ruby annotations or emphasize the contents via <strong>.
Sure, this opens up rendering and allows authors to break the rendering. (Note that styling [and possible visual breakage] is actually already possible for <option> elements within <select multiple> elements.)
Though I believe the advantages mentioned earlier outweight this disadvantage.
For what it’s worth, styling <option> elements seems to be requested in CSSWG issue 1685). For Gecko I filed a similar request.
The same as on desktop browsers.
There are so many ways developers could want it styled though. Using the few examples of existing native options doesn’t account for how many will end up using it. In fact, one prime use-case is to select an image itself, I haven’t seen one example ever of a select node being used to select an image without text being the primary piece of content in the node.
Once you introduce nesting an image in an option, you’re opening the gateway to having web-level layout constructs in it so developers can use it however they please. This is an extreme measure which would require revisiting an old component for a major overhaul
Though I believe the advantages mentioned earlier outweight this disadvantage.
I disagree with the “advantages” entirely (of which, I currently only see one case where it helps.) Modifying an element this old internally could lead to buggy behavior and/or existing sites breaking since they aren’t expecting the new functionality. We shouldn’t justify that kind of breakage without multiple clear cases where a UX is extremely convoluted and difficult to build without the changes.
Hey folks, there is a desire to light this up as a larger effort to make it so that form controls in general can be exposed and styled. In order to do this however we need to standardize on the parts that currently haven’t yet been exposed. We’ve spun up a community group to begin tackling this called Open UI. It has coordination of webdevs/designers and browser engineers. Would love to have any additional help with feedback on open issues or help drive specs. http://open-ui.org/
I’ve written a few blog posts about this here as well:
Should have probably linked to the WICG thread as well: