Define customizable <select>

[josepharhar]

This defines several concepts related to customizable <select>:

• Relaxing the HTML parser to allow more tags inside <select>
• Updating the content model to allow more elements inside <select> and related elements.
• Defines rendering and some interactions for base appearance for <select>
• Adds the <selectedcontent> HTML element
• Adds a UA stylesheet for <select> with base appearance

Closes #9799
Closes #10557
Closes #10310
Closes #10586
Closes #10317
Closes #10629
Closes #10633
Closes #10520
Closes #10670
Closes #10520
Closes #10762

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko
  • Standards positions:
    • Relax <select> parser WebKit/standards-positions#414
    • Customizable select element WebKit/standards-positions#386
    • Relax <select> parser mozilla/standards-positions#1086
    • Customizable select element mozilla/standards-positions#1060
• Tests are written and can be reviewed and commented upon at:
  • Update tests for relaxed <select> parser html5lib/html5lib-tests#178
  • https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select
• Implementation bugs are filed:
  • Chromium: Already implemented
  • Gecko:
    • https://bugzilla.mozilla.org/show_bug.cgi?id=1933591
    • https://bugzilla.mozilla.org/show_bug.cgi?id=1944403
  • WebKit:
    • https://bugs.webkit.org/show_bug.cgi?id=283732
    • https://bugs.webkit.org/show_bug.cgi?id=286642
• MDN issue is filed: Customizable select element mdn/content#37857
• The top of this comment includes a clear commit message to use.

---

/dom.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/grouping-content.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/text-level-semantics.html ( diff )

[josepharhar]

FYI: I am likely going to remove the author-provided datalist and fallback UA button in this PR soon based on recent discussions, which will likely reduce the number of changes and complexity.

[mfreed7]

Should this PR be closed, to avoid confusion? I believe it's been completely superseded by the list at the top of #9799, right?

[josepharhar]

Yes I'm not keeping this up to date anymore since I decided to split out the PRs and have slight redundancies

[annevk]

I found two more small issues, but overall this looks good. In the future I'd prefer the occasional rebase and force push over merge commits. It feels very uncertain whether these 179 commits once squashed will have unintended consequences. Hopefully there are none.

@josepharhar I suggest you prepare this PR for landing, superseding the others. The commit message should explain the change and cause the other PRs to get closed.

@smaug---- any more comments from your side?

@domenic @domfarolino are you both happy with the state of this?

[annevk]

I think this is ambiguous with respect to whether this is allowed as child or descendant and how this relates to phrasing content. Maybe @zcorpan has ideas on how to best phrase this?

[josepharhar]

I added "descendant" to try making it less ambiguous.

[mtrootyy]

Similar to the area element, the following is more preferable.

4.10.17 The selectedcontent element
Categories:
    Phrasing content.

Contexts in which this element can be used:
    Where phrasing content is expected, but only if there is, in ancestor, button element which is a child of a select element.

[josepharhar]

So you're saying that we should add the selectedcontent element to the phrasing content category? How come?

[mtrootyy]

<select>
<button><span><selectedcontent></selectedcontent></span></button>
<option>option1</option>
</select>

The above is non-conformance.
Because, currently, span element cannot have selectedcontent element.
Then,it is meaningless that button element can contain selectedcontent element as a descendant(not child).

[josepharhar]

Ok, I added the selectedcontent element to phrasing content

[josepharhar]

I suggest you prepare this PR for landing, superseding the others. The commit message should explain the change and cause the other PRs to get closed.

Done, thanks!

[mtrootyy]

The following is conformance?

<label> Animal:<input name=animal list=animals></label>
<datalist id=animals>
 <label>or select from the list:
  <select name=animal>
   <option><img src="cat.jpg" alt="cat"></option>
   <option><div>dog<br><small>(but except child dog)</small></div></option>
  </select>
 </label>
</datalist>

[josepharhar]

The option element is not a child of a datalist element, so it falls into the "zero or more option element inner content elements" case, so it's allowed to have the child img and div in your example. Does that answer your question?

[mtrootyy]

When such option element is displayed as suggestion by datalist element, how is it rendered?

[josepharhar]

The input element's datalist does not support rendering things other than text right now, so it just renders the text content of the option.

The spec does not say anything in the rendering section about inputs with datalist.

I also find it very odd that the spec says that datalists can have phrasing content which technically allows for having a select inside of a datalist. In my opinion this should be changed.

[annevk]

That's intentional I think. As that's the graceful degradation story for user agents that do not support datalist (you would get two controls instead of one).

[mtrootyy]

The browser which support customizable select element and dosen't support datalist element will be probably extremely rare.
Therefore, the content model of option element(which has no label attribute) as "descendant" of a datalist element should be text only.

[josepharhar]

Ok we could change the "child of a datalist" cases to "descendant of a datalist", but it seems kinda of contradictory since right above that it says that options are allowed as children of a datalist element as opposed to allowing them as descendants of a datalist element. Should we change that too to say that options are allowed as descendants of datalist elements?

Or we could just keep it as-is and say that your example is conformance. I anticipate that similar changes to option elements will happen in the future for the datalist element so that we can do base appearance for <input type=text> with <datalist>.

[mtrootyy]

Ok we could change the "child of a datalist" cases to "descendant of a datalist", but it seems kinda of contradictory since right above that it says that options are allowed as children of a datalist element as opposed to allowing them as descendants of a datalist element. Should we change that too to say that options are allowed as descendants of datalist elements?

Yes, we should change that too to say that options are allowed as descendants of datalist elements.

Only when "customizable datalist" is supported in the future, we will be able to remove the conditioning by presence or absence of ancestor datalist element.

[annevk]

I think it's more difficult.

You want either phrasing content or option elements. But then the option elements (that could also be part of the phrasing content through a <select> element) need to be constrained to just text.

[josepharhar]

I still think it would be more ideal to call the example conformance, or to say that datalist elements aren't allowed to have interactive descendants like the select element.

You want either phrasing content or option elements. But then the option elements (that could also be part of the phrasing content through a <select> element) need to be constrained to just text.

So I guess we need a way of saying that when an option element is both a descendant of a select element and a descendant of a datalist element at the same time, that the datalist rule takes precedence and the options must have text? I could add a case for it being a descendant of a datalist and a select at the same time.