Content model and 'what' to render for stylable `<select>` elements

[scottaohara]

This is a follow on to #10310 to move discussion on what to do about the potential content models for styleable selects, and its current/proposed directly supported children/descendants (option, optgroup, hr, button, datalist). Additionally, I'd expect this discussion could also cover what may be rendered in a select or not, regardless of whether the elements are parsed out or not. (as was noted in the other issue, one can get around the parser and inject elements into a select - but they don't actually render. that's clearly not the intent for what changing the parser would do, continue to not have elements render - but maybe some still shouldnt?)

One reason to start this discussion is to also determine potential use cases / author intent for content that extends beyond the current content model. For instance, someone wanted to provide a description to an option element - they might think to intervene options with divs or paragraph elements to do this:

...
<option>Orange</option>
<p>A type of fruit, or color... context matters</p>
<option>...

but that isn't really enough to just allow the paragraph in there - there needs to be an association between the paragraph and the option so that the paragraph's content can be relayed via the a11y api as the options description. And putting the paragraph within the option means it'd contribute to its accessible name (undesired).

So, is it enough to just allow any content in and have authors hook it up themselves. Or have HTML determine new definitions for how elements work together in this context? Or is it really a new supporting element that is needed, and allowing main, article, video, iframe into the mix is just noise and potential for author error that didn't exist since the parser didn't allow these things before?

I hope this serves as enough to get this ball rolling.

[annevk]

To be clear, #10310 was to discuss a specific subset of #9799. What ends up getting rendered is really a function of the appearance property and is already tracked by its own issue over in the CSS WG: https://github.com/w3c/csswg-drafts/issues/10028 & https://github.com/w3c/csswg-drafts/issues/5998.

I think an accessible select will always need to have text-based options, essentially. Not just for accessibility, but also for platforms that opt not to support the custom rendering. When you create a tree that one cannot derive text-based options from (and thus doesn't render anything with appearance:auto instead of appearance:base-select) that should essentially be a non-conforming.

[josepharhar]

My draft spec has a proposed updated content model here: https://github.com/whatwg/html/pull/10548

The gist of the changes:

<select>

• Either one of the following:
  • Zero or more <option>s, <optgroup>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.
  • One <datalist>
• Zero or one <button>

<datalist>

• Either: phrasing content if not the child of a select element.
• Or: zero or more <option>s, <optgroup>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.

<optgroup>

• Zero or more <option>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.
• Zero or one <legend>.

<option>

• If the element has a label attribute and a value attribute: Nothing
• If the element has a label attribute but no value attribute: Text
• If the element has no label attribute: Text, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.

Decorative images:

• <img> with alt=””
• <svg> with aria-hidden

[annevk]

Why would we only allow decorative images? I think we should make alt="something" work. People will want to be able to replace option text with images.

[scottaohara]

we had discussed images with alternative text being allowed. i think that might just be a miss. We had talked about how it could be problematic if people used images without alternative text or visible text in the option - and how that'd be an issue.

but i know there was also discussion about needing to potentially address your previous comment.

I think an accessible select will always need to have text-based options, essentially. Not just for accessibility, but also for platforms that opt not to support the custom rendering.

with your latest comment, are you implying it might be ok if image has alternative text, then such platforms could render the alt text instead of the image? if so that'd be great. i was worried that if a platform decided not to render the image, that the whole image, including alt text, would be dropped.

[domenic]

Relatedly, I think having authoring conformance requirements depend on ARIA seems a bit sketchy? ARIA is supposed to be used as a means of interfacing with AT, and not affect semantics or document conformance.

[annevk]

@scottaohara right, it's called "replacement text" for a reason. I don't see why we couldn't use that.

[scottaohara]

@annevk excellent, seems we're on the same page then. again, i think that's a mistake in relaying what had been discussed. an option should absolutely be able to contain non-decorative images. The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

the mention of decorative images was supposed to be in regard to if the graphic was a direct child of a select element (used outside of an option), not if it was a child of an option. cc @josepharhar

@domenic that's fair, and if not for the fact that aria-hidden=true is the primary author guidance for how to mark svgs as decorative, then the use of aria would have been avoided. but maybe it makes sense to reverse the way this is being talked about. lean more into where there would be author requirements to provide alternative text for graphics, rather than requirements about marking graphics as decorative/presentational.

[josepharhar]

Thanks for the discussion!

So it sounds like I should keep the content model the way it is but also remove the requirement of having alt='' or aria-hidden=true, and then add another requirement for this:

The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

Anything I'm missing? If not then I can go update the content model in the draft spec.

[domenic]

The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

I don't think we need a specific requirement for this. There are many elements in the spec which don't make very much sense if they're empty (e.g., only whitespace, or only a non-alt image, or only <audio>). For example <p> or <em>. I don't believe we call out such restrictions on their contents.

[annevk]

For the title element we do call out non-whitespace text as content model, but for the option element without label attribute we only say text. But then we define text as potentially being nothing. We might not be as good about this as we should be?

[zcorpan]

We have "palpable content", but it might not be correct for option (for example an img with empty alt counts as palpable content).

Right now https://html.spec.whatwg.org/#the-option-element has

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

I think the intent is to catch the mistake where the contents of option is used as its value.

Should alt text be included in the submitted value? That would be a normative change, but maybe it's not a web compat problem (since you can't easily use images in option and they are ignored today). If so, https://html.spec.whatwg.org/#dom-option-text needs to be changed, and maybe the content model can just say that https://html.spec.whatwg.org/#concept-option-value must be non-empty (when in a select and no label attribute)

[josepharhar]

Should alt text be included in the submitted value? That would be a normative change, but maybe it's not a web compat problem (since you can't easily use images in option and they are ignored today).

I feel like the only case where making alt text the submitted value make sense is if there is no other text in the option element and the option element also doesn't have the value attribute. Wouldn't it make more sense to put a value attribute on the option as well?

For the title element we do call out non-whitespace text as content model, but for the option element without label attribute we only say text. But then we define text as potentially being nothing. We might not be as good about this as we should be?

This sounds in favor of including the "if they are the only content of an option, they must have alternative text" requirement. Do you think we should have that requirement?

[scottaohara]

i don't see the downside of calling this out. Even if just briefly and cross linking over to https://html.spec.whatwg.org/multipage/images.html#alt for the more detailed requirements for when an alt is necessary.

[annevk]

Wouldn't it make more sense to put a value attribute on the option as well?

It seems cumbersome if you would otherwise not have to do that. Since we already have a custom iterator to determine the text content we might as well handle img elements explicitly going forward.

Additionally, we have environments where we need to display the pure text version and that pure text version should be roughly the same as what AT sees I think and not necessarily reflect the submitted value (which can be nonsensical as far as an end user is concerned).

[josepharhar]

It seems cumbersome if you would otherwise not have to do that

that pure text version should be roughly the same as what AT sees I think and not necessarily reflect the submitted value (which can be nonsensical as far as an end user is concerned).

It sounds like you're in favor of including alt text in the submitted value. Is that correct?

the mention of decorative images was supposed to be in regard to if the graphic was a direct child of a select element (used outside of an option), not if it was a child of an option.

This sounds in favor of including the "if they are the only content of an option, they must have alternative text" requirement. Do you think we should have that requirement?

i don't see the downside of calling this out.

So it sounds like if the image it outside of the option it must not have alt text, and if its inside the image it must have alt text. I'm going to add this to the spec.

Relatedly, I think having authoring conformance requirements depend on ARIA seems a bit sketchy? ARIA is supposed to be used as a means of interfacing with AT, and not affect semantics or document conformance.

if not for the fact that aria-hidden=true is the primary author guidance for how to mark svgs as decorative, then the use of aria would have been avoided

For svgs, can we just make aria-hidden get applied automatically as part of the accessibility mappings when needed? Also, how is alt text supposed to be put on svgs in order to follow the requirement that it must have alt text when used inside an option element?

[scottaohara]

just talked with @josepharhar about this, and per the feedback in this thread we are instead thinking to drop the explicit mention of decorative images from the content model entirely.

Rather, author guidance can be provided in examples and notes, referencing back to existing spec content about the alt attribute, and explaining why it is important to mark graphics as either decorative or informative. Per Domenic's point, there is no special author requirements for other elements, like hyperlinks or the button element, that if you use only an <img src=... alt=""> as their contents then that would make non-conforming HTML. But a11y-specific checkers and WCAG success criteria exist and can catch these sorts of problems.

The only way I could still see graphics being mentioned in the content model, is in regard to needing a value to submit - so that an option like <option><img src=# alt></option> would return something. but again, very happy to just make that into an example if people think this scenario would be covered by the existing content model allowances?

[josepharhar]

Thanks scott!! I created a spec PR here: https://github.com/whatwg/html/pull/10586

[yisibl]

Are form elements like <input> currently supported?

There is a use case in Ant design. https://ant-design.antgroup.com/~demos/select-demo-custom-dropdown-menu

[annevk]

It sounds like you're in favor of including alt text in the submitted value. Is that correct?

I think I would expect it to influence the text getter and therefore both the "label" and "value". (Although we should probably not define the latter two by directly invoking the text getter as we do today as that's kinda bogus.)

[scottaohara]

Thanks scott!! I created a spec PR here: #10586

thanks Joey. That looks like it's going in the right direction to me. And so long as it's good with everyone else, then when the rest of the spec updates are in a good place, we can maybe co-author some examples/notes as needed.

[josepharhar]

Some feedback from @fantasai

• Only <div> should be allowed instead of <span> outside of <option> because the elements wrapping <option> should be block level
• Elements like <em> and <bdo> should be allowed inside <option>s

I'll remove explicit references to <span> so that only <div> remains.

As for em, bdo, ruby, and other tags for doing things to text, I'm not sure there is an existing category that represents this, so I'll say "palpable content except for interactive content" inside options. If anyone has a better idea, I'm all ears!

[josepharhar]

Here is an updated overview of the new content model (to replace https://github.com/whatwg/html/issues/10317#issuecomment-2286699243):

Within <select> these nodes are allowed:

• <option>, <optgroup>, and <hr>
• <div>
• <noscript> and script-supporting elements

Within <optgroup> these nodes are allowed:

• <option>
• <legend>
• <div>
• <noscript> and script-supporting elements

Within <option> these nodes are allowed:

• Text
• Palpable content except for interactive content
  • This is intended to be elements which support rendering text, like <ruby> and <bdo>
• <svg> and <img>
• <span>
• <noscript> and script-supporting elements

[scottaohara]

understand the feedback about no span outside of options - but not sure why it wouldn't be allowed within options? Or is that a miss that it's not listed along with div within option?

any other feedback needed to remove img/svg from being direct allowances of select (e.g., are they really necessary between options?), vs just allowed within options?

[josepharhar]

understand the feedback about no span outside of options - but not sure why it wouldn't be allowed within options? Or is that a miss that it's not listed along with div within option?

any other feedback needed to remove img/svg from being direct allowances of select (e.g., are they really necessary between options?), vs just allowed within options?

After looking through una's demos:

• I agree about span inside option, that is what is present in the demos. I'll update the PR and my comment to replace div with span when inside options.
• Unas demos don't use images outside of options, so yeah I think it is reasonable to remove that. I'll do so until we find a reason to re-add them.

[josepharhar]

In my last comment I said that I didn't have any evidence that authors use divs inside options, but @brechtdr was just showing me a demo which uses div inside options: https://codepen.io/utilitybend/pen/PoMbYRg/f7ceec6bf1b0153e77928e014ef210ba

Maybe we should allow divs and spans inside options?

[brechtDR]

In my last comment I said that I didn't have any evidence that authors use divs inside options, but @brechtDR was just showing me a demo which uses div inside options:

To elaborate a bit. One of the reasons i'd like to use at least <div> elements inside an option is the "lazy developer syndrome". Because I want to set 2 items inside my option block without having to specify the following in my css:

option span {display: block;}

I just want to quickly add 2 items below each other.

If it's possible, why not allow it as it is just one little task that is less tedious and speeds up development a bit? Another quick draft of why: https://codepen.io/utilitybend/pen/VwobyNw

Yes, i know, you could just add two spans and set them to display block... question as a developer is: Why? Do I really have to? Why is this restricted? This feels like an unnecessary rule (especially since div is generic, in contrast to video or paragraphs).

[scottaohara]

i don't see any reason not to allow either of those elements within options. there are plenty of examples of developers doing this if you look at custom listboxes containing role=option elements. if you look for them using this within the actual option element, you likely won't find much if any, since those elements would be ignored right now.

[sorvell]

The proposed content model seems overly strict.

I have a strong bias towards being more expressive and less restrictive overall. The focus here seems to be mostly on styling/display and not considering the potential for extended functionality or future innovation. Disallowing custom elements inside <select> is a limiting case in point.

I definitely acknowledge the large trade off between providing a more expressive API and maintaining base functional guarantees and accessibility. In general, I favor trusting the developer and giving them more power.

[josepharhar]

Disallowing custom elements inside <select> is a limiting case in point.

Custom elements seems fine to me as long as their content doesn't go against the content model. I'm not sure if there is any prior art to be able to do this in the HTML spec's content model though.

[josepharhar]

It sounds like you're in favor of including alt text in the submitted value. Is that correct?

I think I would expect it to influence the text getter and therefore both the "label" and "value". (Although we should probably not define the latter two by directly invoking the text getter as we do today as that's kinda bogus.)

I'd prefer not to calculate alt text and incorporate that into these getters/attributes. Would it just be for the alt attribute on img elements? Didn't scott recommend that imgs used in select shouldn't even have any alt text in the first place?

[scottaohara]

i was/am not keen on the idea of informative images being used outside of options.

but an img element inside of an option, that could be decorative to sibling text. Or it could be the only content of the option, and so long as it has alt text, then that's the text fallback / value of the option.

With an svg, it looks like if actual text is defined in the SVG (title, desc or text elements, for example) then that could serve as the fallback text. https://codepen.io/scottohara/pen/rNXXJVd

so alt and text from within an svg seem like maybe they'd be in scope?

I'm not sure about ARIA attributes though - even though people will absolutely want/expect to use these, since they can with custom ARIA versions of selects (combobox / popup listboxes with options)

but anything that fully relied on ARIA or CSS to be accessible / render... maybe to Anne's earlier comment

When you create a tree that one cannot derive text-based options from (and thus doesn't render anything with appearance:auto instead of appearance:base-select) that should essentially be a non-conforming.

such things shouldn't be considered conforming - at least not without a fallback that would be able to render in browsers that didn't support customizable select?