innerText should be supported for the <option> elements in a <select>

[jfkthame]

I think the <option> descendants of a <select> should be able to return their text, just like <button> can. (See note about replaced elements in the section on Getting innerText.)

According to bug 1290937 this is required for web compatibility, and both Chrome and Edge apparently support it. (I didn't test Edge personally.)

In addition, once the <option> elements support innerText, the only reasonable behavior (IMO) for the parent <select> is to return the concatenated list of innerTexts of its children.

In bug 1290937, we're fixing Gecko to implement these changes (and updating the web-platform tests accordingly).

(Blink currently returns empty for the <select>'s innerText, even when it returns the actual text for an <option> within it, but I've filed a Chromium issue about that.)

[rocallahan]

I think we need to modify the spec to say that for the purposes of this algorithm, <option> nodes and their text node children are treated as generating CSS boxes even if the engine implementation does not implement <select> that way.

[rocallahan]

@zcorpan is upstreaming this spec in whatwg/html#1678 so I think those changes should probably be applied there and this version retired.

[jfkthame]

The proposed change sounds good to me - thanks.

[zcorpan]

Tests:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4393
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4394
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4395

I believe the behavior of Chromium is non-sensical and inconsistent, I think we shouldn't spec it. It appears the Gecko people reached the same conclusion and didn't want to copy it.

It looks like IE and Edge almost match the new behavior of Gecko.

IE/Edge (edit: up to and including 14.14300 but not 14.14393; see comment below) behave like select and option are like non-replaced inline CSS boxes (no line breaks before/after). The difference in Gecko is that option is like a non-replaced block-level (with line breaks before/after). Which of these two should I specify?

cc @gregwhitworth

[jfkthame]

When considering a select that has multiple option children, I think returning an innerText that has line breaks separating the options will better match user expectations. The options of a select normally appear to the user on individual lines, whether presented as a popup menu or in a list box; running them together as if they were inline boxes will make the select's innerText appear very confusing.

[zcorpan]

That is fine reasoning but I believe we also need to consider if Edge is able to change this. Edge/IE has had this API and the same behavior since like forever, as far as I can tell. Gecko implemented the new behavior a few days ago. :-)

[jfkthame]

Sure, that's a fair question. Though considering the wide variation in behavior we currently see among browsers, it seems unlikely that much of the web is dependent on this.

[zcorpan]

Yeah.

(I'm trying to test some more to help inform what to do here.) It appears that option (outside a select) is display:block by default in Gecko and Chromium. In IE it is inline. In WebKit it is not rendered (seemingly like display:none but no such declaration per devtools).

I suggest we specify Gecko's behavior for this issue (at least until new information suggests we need to do something else). Separately we should figure out what the default styles for option should be; I'll file a new issue on HTML for that.

[zcorpan]

Hmmm, @domenic tested Edge 14 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393) and got a different result; it instead matches Chrome.
https://www.irccloud.com/pastebin/wp99E4RY/

If this was a recent change in Edge, would be interesting to know what caused the change

[domenic]

It doesn't completely match Chrome; the second opt.innerText line is different. (Chrome is https://www.irccloud.com/pastebin/cOoVRWdw/)

[zcorpan]

Ah yes, sorry. It does match WebKit Technology Preview though.

[zcorpan]

The WebKit/Edge 14.14393 behavior can be explained (in the spec) by select being a replaced element and option being "not rendered" (at least when it's in a select).

[gregwhitworth]

We rewrote our select control for Edge 14 primarily for accessibility reasons but we also wanted to open it up a bit more for styling as it is a common request from webdevs. Any API changes are probably a result of that work, specific changes I would need to look through all of the changelists to track down what changed and why. Here's a testcase, try it in Edge 13/IE in comparison to Edge 14: http://jsbin.com/yugonaduva/edit?html,output

[zcorpan]

Thanks for the info @gregwhitworth! So maybe it was accidental that it changed innerText then? Would you be OK with changing it again to match Gecko?

Also cc-ing @tkent-google, @cdumez

[zcorpan]

Please see PR at whatwg/html#1717

[zcorpan]

This issue can be closed now