option and optgroup rendering requirements

[annevk]

What is the issue with the HTML Standard?

The only requirement I see for optgroup is

An optgroup element is expected to be rendered by displaying the element's label attribute.

which seems insufficient for what the tests expect.

The option element also has a rather curious sentence that I don't quite understand:

indented under its optgroup element if it has one

Shouldn't that be defined through CSS, if there's any indentation to be done at all? Also, if you render option like suggested in the surrounding sentence, you might well end up with a rendering that doesn't support pseudo-elements, so something is missing there as well.

cc @mfreed7 @josepharhar @nt1m

[josepharhar]

The only requirement I see for optgroup is

An optgroup element is expected to be rendered by displaying the element's label attribute.

which seems insufficient for what the tests expect.

Agreed, I will fix this.

The option element also has a rather curious sentence that I don't quite understand:

indented under its optgroup element if it has one

That part of the paragraph is from the old text before I defined base appearance. I left it there as a way to describe the appearance:auto behavior. I guess we could remove it since native rendering might want to render options in an optgroup with other things besides indentation.

Shouldn't that be defined through CSS, if there's any indentation to be done at all?

Yeah, we didn't add intentation for base appearance since options already have a bunch of padding on the left for the checkmark. I'll remove the text about indentation.

Also, if you render option like suggested in the surrounding sentence, you might well end up with a rendering that doesn't support pseudo-elements, so something is missing there as well.

I'm not sure I understand, is this still an issue if I made the changes in the PR?

Here is a PR: #12201

[annevk]

I wanted to briefly reflect on our options (harhar) here. For the option element we need to either display the label attribute or its contents. The conditions for what to show are:

• Does it have a label attribute whose value is not empty? (This is what the label getter uses as condition.)
• Does it have a select element owner? It would seem somewhat natural to me if outside of a select element the element behaves like a span element as neither base nor auto appearance of the select element would be applicable.

We could do this either as a div element (contains label attribute value) and a slot element as siblings which are conditionally shown based on those conditions. Or we could have a single slot element (contains label attribute value) that we force to show its fallback based on the conditions (you make no nothing match if the conditions match, essentially). I think these are identical, but I prefer the latter as it makes best use of the shadow tree primitives. If we ever give more access through pseudo-elements, these would no longer be identical and the distinctions would become more relevant.

---

For the optgroup element we need to either display the label attribute or a legend element child, followed by the contents. The conditions are roughly the same, but now also depend on whether there is a legend element child as well.

This could again be done as a div element (contains label attribute value) and a slot element as siblings which are conditionally shown. This is fairly clean in a way and can be made to not have an impact when there is no select element owner. (In contrast to the option element the div element would also have some padding applied to it.)

More in line with shadow roots would probably be two slot elements with the first slot element having a div element containing the label attribute value as fallback. (This div element would also have some light padding applied to it.) A first element child if it is a legend element would be slotted into it, if any. (This is different from the initial prototype/proposal which allows for any legend element child to suppress the label attribute. But it would match more closely with how we only slot the first element child if it is a button element in a select element.)

I suppose we could still make it so that outside of select elements the first slot element would not be shown and not match any element, but it would feel a bit less natural (to me, anyway).

cc @lukewarlow @keithamus @emilio @josepharhar @mfreed7

[lukewarlow]

I agree that a single slot with it's fallback content set as the label attribute value, and assigned the first legend element makes the most sense for optgroup (along with obviously a second slot for the rest of the contents). Likewise a single slot for option also feels best, the more we can explain in terms of exposed APIs the better imo.

[lukewarlow]

I've just come across a behaviour for which I've raised a WebKit bug but I figure I should check what is actually expected here.

data:text/html,<select size="4"><optgroup label="Animals"><legend>Foobar</legend><option>Lion</option></optgroup></select>

In Chromium this will render with the legend content NOT the label, in WebKit (using latest main where it will work in base appearance with size=1) this renders with the label.

Given we're in auto appearance mode perhaps WebKit is correct, BUT this is for listbox select where the security issues of allowing rich content don't apply. So essential, should the legend only be rendered when in base appearance mode?

Worth noting Chromium won't use rich content from the options only the optgroup which seems odd but perhaps thats for compat reasons.

[annevk]

That's a WebKit bug, it should use HTML's "get an optgroup element's label", but that's not implemented at the moment. I also don't think it's tested which is why I overlooked it. (The same issue applies to the picker version.)

[josepharhar]

It would seem somewhat natural to me if outside of a select element the element behaves like a span element as neither base nor auto appearance of the select element would be applicable.

This is what firefox does. Chromium only shows the text content or label attribute, and webkit was rendering nothing when I tested it. I think that this suggestion of doing what firefox does sounds great, if I am able to change the behavior in chromium without breaking any websites.

We could do this either as a div element (contains label attribute value) and a slot element as siblings which are conditionally shown based on those conditions. Or we could have a single slot element (contains label attribute value) that we force to show its fallback based on the conditions (you make no nothing match if the conditions match, essentially). I think these are identical, but I prefer the latter as it makes best use of the shadow tree primitives. If we ever give more access through pseudo-elements, these would no longer be identical and the distinctions would become more relevant.

I did the siblings thing because that way I could change which one gets shown from the UA stylesheet instead of from slot assignment, which makes it possible to also consider whether appearance is base or auto to decide which one gets shown. This allowed me to make the appearance:auto listbox rendering of the option element only have text content, which I guess might not be completely necessary but seemed like a good idea at the time to avoid changing behavior in websites. The div element in this case doesn't just hold the label attribute - if there is no label attribute, then it holds the text content of the option.

Since as you mentioned they should be identical for base appearance, I think its fine to do either.

This could again be done as a div element (contains label attribute value) and a slot element as siblings which are conditionally shown. This is fairly clean in a way and can be made to not have an impact when there is no select element owner. (In contrast to the option element the div element would also have some padding applied to it.)

This is what we're currently doing in chromium, I think.

More in line with shadow roots would probably be two slot elements with the first slot element having a div element containing the label attribute value as fallback. (This div element would also have some light padding applied to it.) A first element child if it is a legend element would be slotted into it, if any. (This is different from the initial prototype/proposal which allows for any legend element child to suppress the label attribute. But it would match more closely with how we only slot the first element child if it is a button element in a select element.)

I am trying to implement this here: https://chromium-review.googlesource.com/c/chromium/src/+/7629416