1498936 - display:contents on option/optgroup should behave "as normal"

Status: NEW

(Core :: Layout: Form Controls, enhancement, P4)

Description

[Mats Palmgren (inactive)]

display:contents on option/optgroup should behave "as normal" per spec:
https://drafts.csswg.org/css-display/#unbox-html

It appears Chrome implements what the spec says (with somewhat
weird rendering results).

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Well this is kind of what we do right? We don't compute to "none", we just suppress frames for stuff that are not <option> / <optgroup>...

I don't know what "as normal" would mean in this context, tbh.

Comment 2

[Mats Palmgren (inactive)]

Hmm, yeah, I guess <select><option style="display:contents">text</select>
should behave as <select>text</select> which doesn't render anything in
Chrome either, so I guess this case is a bug in Chrome and we're right
in not creating a box.

So maybe <select><optgroup style="display:contents" label="label"><option>text</select>
should behave as <select>label<option>text</select>, which should render
the same as <select><option>text</select>

It seems we have different rendering for size=1 and size>1 in Gecko,
so there's at least some bugs to fix there.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase

I think our handling of display:contents for these elements makes sense.
We have a few unrelated bugs that makes it hard to compare with other
UAs currently, but there's one case where I think might be worth
discussing:
<select size=4><optgroup style="display:contents" label="optgroup"></select>

In this case our box tree looks like:
<select>
  <optgroup::before>optgroup</optgroup::before>
</select>

(I tend to think that using ::before for this is wrong though (bug 1498358),
but let's pretend it's some other kind of box for now.)

In any case, the spec doesn't say anything about any pseudo-element
for the label:
https://html.spec.whatwg.org/multipage/form-elements.html#the-optgroup-element
and the little there is about <select> rendering, it just says
"An optgroup element is expected to be rendered by displaying the element's label attribute."
https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2
which too vague to draw any conclusions from.

It seems reasonable to me that the above counts as "a box associated
with an <optgroup>" and thus should be rendered, as Edge/Chrome/Safari does.
(Alternatively, we should treat it as <select>optgroup</select> and
thus not render it.)

Emilio, what's your thoughts on the various cases in this testcase?

(I think the text that renders red in Chrome are bugs in Chrome.)

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Mats Palmgren (:mats) from comment #3)
> In any case, the spec doesn't say anything about any pseudo-element
> for the label:
> https://html.spec.whatwg.org/multipage/form-elements.html#the-optgroup-
> element
> and the little there is about <select> rendering, it just says
> "An optgroup element is expected to be rendered by displaying the element's
> label attribute."
> https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2
> which too vague to draw any conclusions from.
> 
> It seems reasonable to me that the above counts as "a box associated
> with an <optgroup>" and thus should be rendered, as Edge/Chrome/Safari does.
> (Alternatively, we should treat it as <select>optgroup</select> and
> thus not render it.)

Edge doesn't really count here since it doesn't implement display: contents does it?

I think the reason it's rendered in WebKit / Blink is just a side-effect of they using Shadow DOM for this instead of layout tree hackery. Similarly, for us it's just a side-effect of us using ::before.

I tend to think the easiest interop-wise should be just adding <optgroup> to the set of special elements and make it compute to display: none, since that gives us more leeway in terms of how to implement the label when the optgroup has a box, specially if we want to get rid of the ::before pseudo-element for the label...

Otherwise the only way I see of getting rid of that ::before pseudo is starting to use Shadow DOM for the label attribute, which I guess it'd be fine as well, but we've objected to do the same thing for stuff like <details> / <summary> in the past... Or alternative make NAC work for display: contents elements, which looks like a pain I think we shouldn't aim for.

WDYT? I filed https://github.com/whatwg/html/issues/4093 to get this properly defined btw.