What's the status of <option label> in cross-browser age?

[saschanaz]

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=40545 Codepen: https://codepen.io/SaschaNaz/pen/JywOmd Spec: https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element

It seems Firefox hasn't support <select><option label="Hey, I'm the label :D"></option></select>. The bug in Bugzilla is now at least 18 years old so Mozilla seems to have no intent to implement it. So what's the status of this attribute? Should the behavior be deprecated?

(Currently even MDN does not warn or discourage the use of it.)

[annevk]

Did you check other browsers?

[saschanaz]

Ah, I forgot writing about other browsers. MSEdge and Chrome (+Opera) support it.

[annevk]

Chrome only seems to support it in standards mode. (data:text/html,<select><option%20label="Hey,%20I'm%20the%20label%20:D"></option></select> doesn't show it.)

[zcorpan]

Test case	EdgeHTML	Blink	Gecko	WebKit
standards mode	PASS	PASS	FAIL	PASS
quirks mode	PASS	FAIL	FAIL	FAIL

[zcorpan]

Instances from httparchive:

SELECT * FROM (
SELECT page, REGEXP_EXTRACT(LOWER(body), r'(<option(?:\s+[^>]+)?\slabel\s*=\s*[^>]+>)') AS match
FROM [httparchive:har.2017_08_15_chrome_requests_bodies]
WHERE page = url
) WHERE match != "null"

(This query only looks for top-level pages, so no framed HTML files, no external JS, etc.)

~~688 matches~~: https://gist.github.com/zcorpan/4e19e5974136e86cae852d8773e5ee16

I have not looked at any if they work better with or without label support.

[zcorpan]

http://moro-ichikara.com/

<option label="すべての商品" value="">全ての商品</option>

(No idea which one is intended here.)

---

https://www.list.co.uk/

<option value="" class="timePlaceholder" label="any time"></option>

when clicked, a script updates it to

<option value="" class="timePlaceholder" label="any time">any time</option>

---

A lot of pages have the same child content as in label; I should have excluded those in the query somehow... OK, I've now run this query instead and updated the gist:

SELECT * FROM (
  SELECT
    page,
    REGEXP_EXTRACT(match, r'<option(?:\s+[^>]+)?\slabel\s*=\s*["\']([^"\']+)') AS label,
    REGEXP_EXTRACT(match, r'>([^<]+)<') AS content
  FROM (
    SELECT page, REGEXP_EXTRACT(LOWER(body), r'(<option(?:\s+[^>]+)?\slabel\s*=\s*[^>]+>[^<]*</option\s*>)') AS match
    FROM [httparchive:har.2017_08_15_chrome_requests_bodies]
    WHERE page = url
  )
  WHERE match != "null"
)
WHERE label != content

70 matches where label is different from content

[zcorpan]

Some use a custom select widget with the actual <select> being display:none.

https://www.choctawcasinos.com/ has different text in the dropdowns between Firefox and others (click BOOK NOW). Unclear which was intended.

Overall it looks like a wash either way, web-compat wise.

[zcorpan]

<option label> can also be used with <datalist>, and there it is supported in EdgeHTML/Chromium/Gecko (WebKit doesn't support datalist):

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

I suggest we leave the spec as-is, write tests and file bugs to converge towards EdgeHTML.

[cdumez]

FYI, we intentionally made this change in WebKit: https://bugs.webkit.org/show_bug.cgi?id=169296

The reason we made this change was because a newer version of bugzilla was not working in Safari but was working in Firefox / Chrome until we made the change.

The regression in Bugzilla was caused by https://github.com/bugzilla/bugzilla/commit/7d0c10e71498f2909f466fc0ccda1890595bd3ff#diff-535e432916dc0692c5c86efd8da46662L126 which added a bunch of "X" labels to try and be HTML5 compliant :( "X" was displayed in Safari instead of nothing until we made the change to align with other browsers.

I may have submitted a patch to bugzilla, I do not remember.

[cdumez]

Looks like I merely filed a bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1345270 and it looks like it is still open so I expect the issue to still exist in bugzilla.

If so, browsers will regress if they try to align with the current spec :/

[annevk]

Can you point to a Bugzilla page that renders in quirks mode? I clicked around a bit on WebKit and Mozilla Bugzilla and they both seem to use <!DOCTYPE html> throughout...

[cdumez]

Well, we definitely had the bug when we updated our WebKit bugzilla instance. If you go to https://bugs.webkit.org/attachment.cgi?id=303712&action=review then right click > Inspect on the select "r:" element at the bottom, you'll see that this page does not have a DOCTYPE. You'll also notice that our instance does not have the labels, likely because we patched our local instance to work around the bug until the fix could ship in Safari.

[cdumez]

The exact steps to reproduce the issue were:

• Go to https://bugs.webkit.org/attachment.cgi?id=299235&action=review
• Press the "Preview button"
• Notice that the "Review" / "Commit Queue" select element show a "X" label instead of " ".

As I mentioned, it looks like we applied a local patch to our WebKit instance so the current code looks like:

<select id="flag-321209" name="flag-321209" title="Request for patch review." onchange="toggleRequesteeField(this);" class="flag_select flag_type-1">
          <option value="X" label=" "></option>
            <option value="?">?</option>
            <option value="+" selected="">+</option>
            <option value="-">-</option>
        </select>

We made the label " " instead of "X" as it currently is upstream.

Also notice that if you show the page source of that frame, the code looks like:

<style>
* { font-size: small; }
#comment { width: 100%; height: 100%; font-family: monospace; }
#form-controls { height: 40px; }
#form-controls td { width: 25%; text-align: center; }
</style>

<!DOCTYPE html>
<html lang="en">
  <head>
    <title></title>

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<link href="data/assets/c6137797464044e8a51c3a6553b0479e.css?1490902159" rel="stylesheet" type="text/css">

So they're trying to use the html DOCTYPE but it fails because they wrongly insert a style element before the DOCTYPE (another bug).

[annevk]

Thanks! I guess that means the path of least resistance is to add a quirk here. @zcorpan thoughts?

[zcorpan]

Agreed

[zcorpan]

I see the issue in bugzilla was fixed in https://github.com/bugzilla/bugzilla/pull/47 , but maybe webkit still uses an old bugzilla instance? Can it be updated?

I'm a bit reluctant to let a bug in bugzilla (which has been fixed) dictate whether a quirk should exist in the web platform. My conclusion previously was to leave the spec as-is. @cdumez what do you think?

[annevk]

Is this tested in WPT?

[saschanaz]

Per https://phabricator.services.mozilla.com/D63545 some of the tests in https://wpt.live/html/rendering/widgets/the-select-element/ are for this.

https://wpt.fyi/results/html/rendering/widgets/the-select-element?label=experimental&label=master&aligned reports some Safari failures.

[annevk]

Thanks, as far as I can tell quirks mode wasn't tested there which would presumably show the larger problem. I created https://github.com/web-platform-tests/wpt/pull/36331 for that. (It seems the WebKit issues there now are primarily around not updating the widget upon invalidation.)

Given that WebKit experienced a compatibility problem here I would not expect WebKit to take the lead in trying to make it work in quirks mode (again).

[saschanaz]

Given that WebKit experienced a compatibility problem here I would not expect WebKit to take the lead in trying to make it work in quirks mode (again).

Was there other issues not related to Bugzilla? I mean, Bugzilla is not too widespread.

[annevk]

Not sure, but once bitten twice shy.

[josepharhar]

I'm going to try to fix this in chromium by removing the check for quirks mode: https://chromium-review.googlesource.com/c/chromium/src/+/4126138

The quirks check is older than I could even figure out by going through the blame. Here is the oldest commit I could find where it was copied in from somewhere in 2006: https://chromium.googlesource.com/chromium/src/+blame/f51ca05d0e8a45a3cd746db81849207af3ed9cc6/third_party/WebKit/WebCore/khtml/html/HTMLOptionElementImpl.cpp#60

[josepharhar]

Hmm there are a variety of tests that fail given this behavior: https://chromium-layout-test-archives.storage.googleapis.com/results.html?json=linux-rel/1244626/blink_web_tests%20%28with%20patch%29/full_results_jsonp.js I suppose I could just rebaseline/remove them, but I'm a little more worried now. Anyone have thoughts?

[annevk]

Firefox seems to be getting away with not having the quirk as it fails those tests as far as I can tell. That suggests there is an opportunity. The tests suggest IE might have had this quirk, but it's been a while since that was relevant and I suspect that forms do get some maintenance at least given there typically are backend needs.

If you want to play it safe we should just standardize the quirk, but it would be nice to try and get rid of it.

[zcorpan]

Right so Gecko implemented label for both quirks mode and standards mode 3 years ago (Firefox 77), see https://bugzilla.mozilla.org/show_bug.cgi?id=40545#c79

I see one bug marked as a regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1644611 (author-provided ::before replaces the label text) but didn't find anything else. cc @emilio

[josepharhar]

I'll try implementing it with a flag to turn it off and report back here how it goes

[josepharhar]

Before I ship this in chromium, I just want to make certain I have the right behavior. The desired behavior is that these two tests should pass, which currently only firefox does, right?

1. https://wpt.fyi/results/html/rendering/widgets/the-select-element/option-add-label.html
2. https://wpt.fyi/results/html/rendering/widgets/the-select-element/option-add-label-quirks.html

[zcorpan]

@josepharhar Yes. Thanks!

[josepharhar]

My intent to ship was objected and I will have to wait for UseCounter data and hope that it is very low: https://groups.google.com/a/chromium.org/g/blink-dev/c/KJ7UI89UPpM

[josepharhar]

The I2S was approved, so I am launching the change to comply with the WPTs in Chrome 118