<option> element: why is its content restricted to Text?

[verdy-p]

https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element

If the element has a label attribute but no value attribute:​ Text.
If the element has no label attribute and is not a child of a datalist element:​ Text that is not inter-element whitespace.
If the element has no label attribute and is a child of a datalist element:​ Text.

I don't understand the rationale of WHY the content of an <option> element is restricted to just Text and not a PhrasingContent. Not all human text can be represented using ONLY plain-text, we need some other inline presentational features, including for example:

• <b>, <i>, <u>, <s>, <strong>, <em>, <var>, <ins>, <del>, <code>, <kbd>, <em>, <var>, <big>, <small>, <sup>, <sub> to correctly represent notations or abbreviations (like "H₂O", "1.23×10₂₆" and not "1.23×1026", or ordinals such as "1^er" and not just "1er")
• <abbr> to insert accessibility features like "title" attributes for hints,
• <span> if we need other style or class to make some adjustments like the line-spacing, or to select some suitable fonts, or if we want to specify colors, e.g. in a drop-down list of colors,
• <br>, <nobr>, <wbr> if we allow an option to wrap on several lines and basically control line-wraps (without necessarily using CSS style= attributes),
• <img> to insert icons (e.g. in a legend-like drop-down selectors), and possibly even <video> (or even <object>).

We should not need to develop custom objects in Javascript. But even if we do that, we would use a "datalist" object, which would be rendered by this custom element instead of <select>.

I absolutely don't understand the restriction even if (for now) browsers don't break and just ignore other inline elements, preserving at least their plain text content.

Note that I'm not speaking about attributes: there's sill a problem with the "opgroup" element, that still does not allow any content for itself, only a "label" attribute, which is insufficient: attributes are not suitable for human-readable text.

Shouldn't the <option> and <optgroup> (for inclusion in <select> or <datagroup> elements) be reviewed to make them more flexible?

Also look at the Unicode standard, which ALREADY admits that NOT ALL human languages can be represented using ONLY plain-text (notable examples with Egyptian Hieroglyphs or VisibleSpeech), so it REQUIRES additional rich-text markup, notably for the layout or essential presentational attributes (e.g. in notations for maths and physics, and even in wellknown languages for correct and distinctive notation of abbreviations), otherwise the plain-text alone is ambiguous or makes no sense (e.g. "1026" instead of "10²⁶" or "CH3++OH-" instead of "CH₃⁺+OH^-").

Note that for superscripts/subscripts, the pseudo-solution consisting in replacing letters or digits by Unicode superscript/superscript variants does not work for all needed characters used in human languages: these Unicode character variants are just there for compatibility with legacy encoding standards (and are poorly supported in many fonts, except a few superscripts like the ordinal 'a' and ordinal 'o' or superscript '2', which were mapped in ISO 8859-1 and so were kept in the UCS for compatiblity; as well some other Latin superscripts used in IPA notations, but missing capitals) and are not intended to cover human languages (otherwise there would be OVER ONE MILLION variants added in the UCS for all variant types, in ALL scripts all numeral systems, including symbols and punctuation, and the support of diacritics, ligatures, contextual joining, complex shaping and special clustering controls), not even English or French for all their common abbreviations: if we are forced to use the standard base alphabets to get the correct coverage (and not these limited compatiblity variants which have limited use, e.g. for IPA, with a well-defined subset of the UCS), then we create semantic ambiguities if we cannot use rich-text markup. Even for maths, Unicode and ISO decided to stop adding variants: today this is no longer needed for new development (given the advances made by today's renderers, and the fact that there's no demonstrated need to offer compatibility with older standards).

[Jamesernator]

Shouldn't the "option" and "optgroup" (for inclusion in "select" or "datagroup" elements) be reviewed to make them more flexible?

There is a (early draft) proposal from the open UI group for changed behaviour here: https://open-ui.org/components/select#content-not-allowed-within-the-anatomy

[smaug----]

Note, in the past (I think ~15 years ago) <option> with an <img> inside it was used to trick the popup of the <select> to look like the desktop of the operating system. It was very convincing looking and by using right kind of event listeners it was possible to get at least some sensitive data from the user.

[verdy-p]

I'm not requesting for posible inclusion of <img>, but more basically admitting <abbr>, <sup>, <sub>, <em>, <var>, <i>, <strong>, <b>, <big>, <small>, <ins>, <del>, <u>, <s>, <code>, <kbd>, may be also elements of the "ruby" notation, and <span> (for other attributes like lang=, dir=, title=, possibly class= and style=), as needed for the intended semantics which cannot carried only with the plain-text content...

And may be also <br> and <wbr>, possibly with additional restrictions on styles, notably each option should be rendered with a display:relative and overflow:hidden CSS attribute in its container, to limit where its content can be safely rendered in a constrained box (but with the difficulty on how to properly size that box). In that case it would be possible as well to include <img> (possibly even an imagemap, for example to select regions visually on a cartographic map, instead of just a textual list: the imagemap would be allowed as an option group, not as an individual option, but selectable items in the map would become individual options); In that case, for accessibility, we could allow "duplicate" options, one visual on the map, another for text; but "duplicates" would be fine and even desirable as well between different option groups (e.g. when selecting languages grouped by area where it is spoken, or by language family, or in an additional group for user-prefered languages).

When admitting the inline elements listed above, as soon as we allow CSS styling, we already get the possibility to render some images: a webbrowser should inspect those styles and attributes and see which ones can be safely used; the webbrowser may then add extra decoration to the popup or its content, to prevent misuses caused by malicious tricks. This could as well be done by browser extensions, such as those coming with secury tools, antimalwares, or accessibility tools.

All this indented section is of course "very advanced" usage of custom option selectors (not needed for now, most sites use their own Javascript-generated selectors for that, such as example the "Universal Language Selector" in MediaWiki, which allows more advanced control of the layout and can remember user preferences and offer a search tool, including with an entry box and autocompletion).

However, form input elements like <input>, <submit> , or another <input> element should probably not allowed in <option> or <datagroup> elements (how to manage these elements inside options of a selector, itself used as a form input element, without creating a local input form inside the selector, and a validation scheme for such complex input, and avoid possible recursion loops??)

Note that the contents of the selector popup could have several alternative layouts, not necessarily stacked vertically (or horizontally when the selector is used with East-Asian vertical text), they could be using flexible, grid, or multicolumn layouts, by styling the <select> object itself (may be also <datagroup>?), and possibly <optgroup>.

That possibility of the listbox for the selector being stacking items horizontally, when these items are vertical (e.g. with Traditional Han/Hanja/Kanji or Mongol they would stack to the right or to the left, in the same direction as successive text rows), is not addressed in the Open UI proposal, even if it does not study other layouts than just a scrollable stacked list box.

---

Anyway, popups of combo-selectors can still be made distinct from the the desktop/OS presentation, using borders, and OS/desktop environment use other ways to make their security dialog popups distinct (e.g. shadowing the whole desktop over which these secure popups are displayed). We had the same issue with windows for Javascript alert(), now made distinctive by the windows decoration adding a title bar indicating that this comes from a web page and not the OS.

Even outside of selectors and javascript popups for alert(), you can always mimic an OS presentation using just <div>and <span> and CSS styles in any web page; the tricks is to not allow a browser to retrieve exact color/font/decoration styles used by the OS/desktop: web pages would have to "guess" and should be wrong if the user have made any customization of their OS. All what web pages can do is to retrieve basic properties (if permitted by browser options), such as light/dark mode; as well the prefered language for a web page may not necessarily follow the language of the OS UI or of the browser UI (webbrowsers already have options for that and can enforce them in their privacy settings, so websites have to "guess" and may be wrong, unable to exactly mimic an OS behavior): this is a concern in all webbrowsers, in their current fight against "phishing attacks".

[zcorpan]

The main dealbreaker here for option in select is that the HTML parser will throw away almost all tags in select.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/10666

However, for the proposed selectmenu element this is not a problem. https://open-ui.org/prototypes/selectmenu

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/10667

So I think if/when selectmenu is added to the HTML spec, we'll update option's content model (when there's no select ancestor).