Need to define how <optgroup>'s label should be rendered.

[emilio]

This is loosely related to #4086. Right now Gecko renders the <optgroup>s label with:

optgroup::before {
  display: block;
  content: attr(label);
}

I think that's not a great way to do it, but we need to come up with another way of rendering it. Blink / WebKit use Shadow DOM, which means that as a side effect, this works:

<optgroup label="The label" style="display: contents"></optgroup>

But it's not clear to me why it should, and if we want to make that work our only feasible alternative to our current ::before implementation is Shadow DOM.

In any case, it has to be defined how UAs should render the label, or maybe at least be added to the set of special elements in css-display where display: contents computes to none:

https://drafts.csswg.org/css-display/#unbox-html

[annevk]

cc @zcorpan

[zcorpan]

Right now the spec says

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

A quick test case

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

In Firefox the label on the multiline select is "adsfasdfaf", but in the dropdown it is "xxx" (but the width of the single-line select is affected by the author-CSS generated content).

Safari ignores the generated content in both cases.

Chrome and Edge show the generated content and the label in the multiline select, and ignores it in the dropdown.

@MatsPalmgren @tkent-google @FremyCompany any opinions?

[tkent-google]

I'd like to assume <option> and <optgroup> just provide the owner <select> with data, they don't create CSS boxes, and they don't support almost all CSS styling including generated contents.