innerText getter impact of customizable select

[zcorpan]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/#dom-innertext says

3. If node is not being rendered, then return items. For the purpose of this step, the following elements must act as described if the computed value of the 'display' property is not 'none':

   1. select elements have an associated non-replaced inline CSS box whose child boxes include only those of optgroup and option element child nodes;

   2. optgroup elements have an associated non-replaced block-level CSS box whose child boxes include only those of option element child nodes; and

   3. option element have an associated non-replaced block-level CSS box whose child boxes are as normal for non-replaced block-level CSS boxes.

Given <select><div><option>foo</option></div></select>, select.innerText would be the empty string (because there is no option child node), which is different from old select parsing (where the div is dropped).

Relevant tests: https://wpt.fyi/results/html/dom/elements/the-innertext-and-outertext-properties/getter.html?label=master&label=experimental&aligned&q=innertext

Also currently innerText per spec would drop text outside of optgroup/option in select. (e.g. <select>foo</select> per the current spec gives the empty string.)

I suppose the options are:

1. tweak it to include descendant optgroup/options, not just children
2. remove the special casing
3. keep the innerText spec as-is

I think (1) seems safest in terms of web compat, but I don't know if there are strong web compat constraints here.

Also see:

• The spec does not deal with replaced elements like <select> which have textContent but no innerText rocallahan/innerText-spec#1
• innerText should be supported for the <option> elements in a <select> rocallahan/innerText-spec#5

cc @josepharhar

[myakura]

I think (1) seems safest in terms of web compat, but I don't know if there are strong web compat constraints here.

There was a report on twitter around Chrome introduced the select parser change that broke option.innerText being blank:

I should do this we had some old code could be bad… we used innerText to get the text content of option elements within a select tag. It was working well and then it started giving us back blank text values… it’s unclear to me if we broke this or it was the result of something changing in chrome… we fixed our side by using innerHTML instead…

https://x.com/taf2/status/1859935811330060576

[josepharhar]

I implemented option 1 in chrome already: https://chromium-review.googlesource.com/c/chromium/src/+/6173103

I included the changes in the spec PR for the content model here: #10586

Specifically this: 1117978

I can move the commit to another PR if you'd like.

[zcorpan]

@josepharhar ah, I had missed that. I'm ok with it being in the same PR, it can be marked as also fixing this bug when merging.