Default UA stylesheet for <select> as a listbox + optgroup + option

[zcorpan]

This is part of #7050

I created a tentative test against the current spec here: web-platform-tests/wpt#35801

Test results: https://wpt.fyi/results/html/rendering/widgets/the-select-element/select-as-listbox-default-styles.tentative.html?label=pr_head&max-count=1&pr=35801

Here are the failing tests:

• on the select
  • WebKit has margin: 2px
  • Gecko has padding-block-start: 1px; padding-block-end: 1px
  • All 3 have borders but with different widths, styles, and colors.
  • WebKit and Chromium have align-items: flex-start
  • Chromium and Gecko have white-space: nowrap
  • All 3 have a white background-color (might be subject to dark mode?)
  • All 3 have cursor: default on select
  • All 3 have a set font-family and size (but different between browsers).
  • Chromium and WebKit force writing-mode: horizontal-tb (Gecko supports vertical for form controls).
  • Chromium sets overflow: hidden, Gecko overflow: auto.
  • Chromium and Gecko set vertical-align: bottom
  • Gecko sets user-select: none
  • Gecko sets page-break-inside: avoid
• on the option (not in optgroup)
  • Gecko sets padding-block: 2px; padding-inline: 4px
  • Chromium sets padding: 0 2px 1px 2px
  • Chromium and Gecko sets white-space: nowrap
  • (cursor, font styles, writing-mode are inherited)
  • Gecko sets user-select: none
• on the optgroup
  • Chromium and Gecko set white-space: nowrap
  • (cursor, writing-mode are inherited)
  • font styles are different: Gecko uses bold+italic, Chromium and WebKit only bold.
  • Gecko sets user-select: none
• on the option in optgroup
  • Chromium sets padding: 0 2px 1px 2px, Gecko padding-inline-start: 20px; padding-block: 2px. Chromium instead indents the options with

    select:-internal-list-box optgroup option:before {
      content: "\00a0\00a0\00a0\00a0";;
    }
    

  • Chromium and Gecko set white-space: nowrap
  • (cursor, font styles, writing-mode are inherited)
  • Gecko sets user-select: none

These results are for desktop only, the styles on mobile/tablet may be different: #8189

I think it seems reasonable to try to get interop on margins, paddings, borders (which can look different than the CSS-specified borders when appearance: auto), align-items, cursor, overflow, vertical-align, user-select, page-break-inside, and how to indent option in optgroup.

I'm not sure about background-color/color, need to test dark mode. Font might also be tricky, maybe the spec can allow implementation-defined font and color properties?

Should writing-mode be supported for form controls (like in Gecko) or not (like WebKit/Chromium)?

For optgroup, I think it's reasonable to align on either bold or bold+italic.

cc @whatwg/forms @mfreed7 @pxlcoder

[zcorpan]

@mfreed7 do you have opinions here?

[mfreed7]

@mfreed7 do you have opinions here?

Sorry for the delay. So is the plan to add some CSS to the Rendering section with values for these properties? If so, would you mind pointing me to that proposed CSS? (I looked at the test, and while it is cool, I can't tell where e.g. the expected value for align-items comes from.)

Generally, I'm very supportive of trying to standardize as much of this as possible. But there are definitely web compat issues, depending on the changes, so I'd need time to test those out.

[zcorpan]

Sorry for the delay. So is the plan to add some CSS to the Rendering section with values for these properties?

Yes.

If so, would you mind pointing me to that proposed CSS?

There's only the OP above, so no proposed CSS yet.

(I looked at the test, and while it is cool, I can't tell where e.g. the expected value for align-items comes from.)

The test compares styles for HTML elements with only the UA stylesheet against non-HTML elements (with the same names) with the expected CSS as author-origin styles. So for any property that is not in the test's CSS the expectation is that it's the property's initial value.

Generally, I'm very supportive of trying to standardize as much of this as possible. But there are definitely web compat issues, depending on the changes, so I'd need time to test those out.

OK, great. Is there a preference or rationale for current behavior for any of these?

[mfreed7]

The test compares styles for HTML elements with only the UA stylesheet against non-HTML elements (with the same names) with the expected CSS as author-origin styles. So for any property that is not in the test's CSS the expectation is that it's the property's initial value.

Got it, ok.

OK, great. Is there a preference or rationale for current behavior for any of these?

In terms of rationale, I'd have to go line by line and see what the history is.

One question generally: for <option> and <optgroup> styling, we are only thinking about standardizing styles in the <select multiple> case, correct? Are we also thinking about standardizing the non-multiple case for <select>? And should it be the same set of styles?

[zcorpan]

Only "as a listbox" case, so <select multiple> or <select size=5>.

[vinhill]

All browsers prevent line-height from applying to optgroup and option within select.

Chromium sets line-height: inital !important for option and optgroup in select multiple here.

Gecko sets line-height: normal !important for option and optgroup here, though is discussing to also limit this rule to select multiple.

For select dropdown and in WebKit, line-height has no apparent effect.

[zcorpan]

The initial value for line-height is normal so Chromium and Gecko declarations are equivalent.

I can't get line-height have an effect on either dropdown or listbox select in Firefox/Chrome/Safari on macOS. Is there an effect in Linux or Windows?

[gsnedders]

• Chromium and Gecko sets white-space: nowrap

https://bugs.webkit.org/show_bug.cgi?id=257477 changed this in WebKit to match the other two.