Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

Contact emails

jar...@chromium.org

Specification

https://github.com/whatwg/html/issues/2988

Summary

Option elements support a "label" attribute which will cause the option to render with the text inside the attribute rather than the child text of the option element itself. This functionality is disabled in quirks mode, where the label attribute is ignored and the child text is always rendered. This change will always use the label attribute in both standards mode and quirks mode.

Blink component

Blink>Forms>Select

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If websites rely on this quirks mode behavior despite firefox already shipping this behavior for years, then select elements won't render with the expected text. If too many websites are broken, I will disable this change via finch and try to change the HTML spec to align with chrome.

Gecko: Shipped/Shipping (https://wpt.fyi/results/html/rendering/widgets/the-select-element/option-add-label-quirks.html)

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

There are no other platform APIs that this change will be used in tandem with.

Activation

This will not be challenging for developers to take advantage of.

Security

There are no security risks/considerations for this feature.

WebView application risks

This change does not have particularly high risk to WebView.

Debuggability

No DevTools changes are needed for this change.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

--enable-features=OptionElementAlwaysUseLabel

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1403735

Estimated milestones

111

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6084027289698304

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 1/19/23 12:54 PM, Joey Arhar wrote:

Contact emails

jar...@chromium.org

Specification

https://github.com/whatwg/html/issues/2988

Summary

Option elements support a "label" attribute which will cause the option to render with the text inside the attribute rather than the child text of the option element itself. This functionality is disabled in quirks mode, where the label attribute is ignored and the child text is always rendered. This change will always use the label attribute in both standards mode and quirks mode.

Blink component

Blink>Forms>Select

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If websites rely on this quirks mode behavior despite firefox already shipping this behavior for years, then select elements won't render with the expected text. If too many websites are broken, I will disable this change via finch and try to change the HTML spec to align with chrome.

It's reassuring that this ships in Gecko, but do we have any sense of how common it is to encounter an option w/ a label in quirks mode?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLed%2BEECiebAa0bgXfLGVXNMMucLG%2B4667VnpJzeXXa8A%40mail.gmail.com.

[Joey Arhar]

> It's reassuring that this ships in Gecko, but do we have any sense of how common it is to encounter an option w/ a label in quirks mode?

I could add a use counter but I'm not sure what results would be considered acceptable.

Apparently firefox only had one regression bug when they shipped this behavior: https://github.com/whatwg/html/issues/2988#issuecomment-1378794167

[Rick Byers]

Hey Joey,

Thanks for working to remove a quirk! Although we haven't written it into our compat principles, I'm personally willing to accept greater compat risk for removing quirks as they're by-definition legacy behavior of the web which create an ongoing complexity burden for the platform which we should seek to eventually eliminate.

Reading through the history of WebKit not being able to make this change due to severe breakage in bugzilla and seeing that we still load 12% of pages in quirks mode, I don't think I can support proceeding without UseCounter data. Personally I would be happy to approve if we had a UseCounter with less than our small but non-trivial risk threshold of 0.001% of page loads. Based on Simon's previous HTTP Archive analysis you'll want to exclude the case where the strings match in your calculation. I think ignoring cases where the child text is empty is also fine as it'll avoid false positives with script updated DOM that Simon described and because replacing empty with non-empty string is almost certainly an improvement. WDYT?

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BNO8ShF8nV1s1GDaryEpGGG%2B3M%2Bgw6qT%2Bxsfq%3DTwiG_w%40mail.gmail.com.

[Joey Arhar]

Sounds good, I'm adding a UseCounter here: https://chromium-review.googlesource.com/c/chromium/src/+/4193560

[Simon Pieters]

Hi folks!

Thanks for working on this, Joey. Removing quirks where possible is always nice!

On Wed, Jan 25, 2023 at 7:18 PM Joey Arhar <jar...@chromium.org> wrote:

Sounds good, I'm adding a UseCounter here: https://chromium-review.googlesource.com/c/chromium/src/+/4193560

On Tue, Jan 24, 2023 at 8:05 AM Rick Byers <rby...@chromium.org> wrote:

Hey Joey,

Thanks for working to remove a quirk! Although we haven't written it into our compat principles, I'm personally willing to accept greater compat risk for removing quirks as they're by-definition legacy behavior of the web which create an ongoing complexity burden for the platform which we should seek to eventually eliminate.

Reading through the history of WebKit not being able to make this change due to severe breakage in bugzilla and seeing that we still load 12% of pages in quirks mode,

In https://almanac.httparchive.org/en/2020/markup#conclusion the number was 3.97% of *pages* in httparchive are in quirks mode, and if I remember correctly, this has further declined slightly in 2021 and 2022. I'm not sure why there's a 3x discrepancy between the use counter page view number and the httparchive pages number, though. Does an about:blank iframe trigger the use counter?

cheers,

--

Simon Pieters

https://www.mozilla.com/

[Rick Byers]

Wow, that is surprising to me! Typically the biggest discrepancy comes from the fact that usage is head-heavy with 1/3rd of page loads being from the top 100 origins, and I would absolutely expect the head to not be using quirks mode. Perhaps there's one or two popular sites using quirks mode? No, only http/https schemes contribute to UseCounters IIRC so about:blank shouldn't be the problem.  Or maybe there's some discrepancy in how we're identifying quirky pages.

[Yoav Weiss]

Looked at this following the API owners meeting and given that the usecounters landed in 112, I think we can expect stable data early April but not before.

Joey - does that match your understanding?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8ZizCwMOX_r8dKbJ44xNkih7J4Tx7z31DNnPOrmLRH%2Bw%40mail.gmail.com.

[Joey Arhar]

Yes, that matches my understanding. I can see on omahaproxy that the usecounter was merged in 112 and I can see on chromiumdash that 112 goes to stable on april 4

[Yoav Weiss]

Friendly ping! :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Joey Arhar]

Here is the UseCounter: https://chromestatus.com/metrics/feature/timeline/popularity/4454

It looks like it is at 0.0103%

What do yall think?

> Personally I would be happy to approve if we had a UseCounter with less than our small but non-trivial risk threshold of 0.001% of page loads

Looks like its higher than this threshold :(

Friendly ping! :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

Hey Joey, sorry for the delay. Yeah 0.01% puts this into the high risk range unfortunately. If you want to proceed, the next step would probably be to get a random sample of impacted URLs and evaluate the severity of breakage and ease of adaptation. Maybe we'd find they are almost all pages with very subtle layout changes which already look OK or just slightly off in Firefox. The real risk likely comes from sites / apps designed for blink/webkit only (enterprise, android webview, etc.). But if you could show evidence that < 1 in 20 impacted page loads have any meaningful breakage (i.e. <0.005% page views impacted), then we might still be able to proceed with appropriate webview and enterprise guards. But that obviously has a cost, so up to you if it's better to just specify the current quirky behavior. Maybe our efforts are better spent trying to actively drive down quirks mode usage somehow?

Thanks for trying to clean this sort of thing up! 

  Rick

[Rick Byers]

Hey Joey,

We discussed this in the API owners meeting today. Given that Firefox has succeeded in removing this quirk, we do think it's valuable for us to attempt to follow. Thank you again for pushing on it. Could you take a look at either 20 hits from HA, or 10 high-ranking hits* and see if you see any actual breakage? API owners agreed today that if you didn't (or if you saw just 1 in 20), we'd be OK proceeding with a killswitch we can pull if necessary.

*Note chrishtr@ is looking into making ranking-based HA analysis easier than getting BigQuery setup. 

Thanks,

   Rick