Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Chris Harrelson]

LGTM3

On Wed, Aug 9, 2023 at 6:26 AM Mike Taylor  wrote:

> LGTM2, so long as we have a killswitch.
> On 8/9/23 7:08 AM, Daniel Bratell wrote:
>
> If I did the math correctly, that puts the likely breakage below 14% (95%
> confidence) of the population, or less than 0.002% of page loads. (Napkin
> math, don't quote me, but it's in that ballpark which is a good ballpark)
>
> LGTM1
>
> /Daniel
> On 2023-08-03 03:49, Joey Arhar wrote:
>
> I looked at the top 20 websites here:
> https://chromestatus.com/metrics/feature/timeline/popularity/4454
> I looked at the option elements which were triggering the UseCounter, and
> I found that all of them seemed to have a label attribute with no text
> content at some point during page load, but then when I actually looked at
> them in DevTools after page load they all had text content.
> None of those top 20 websites are affected by this change.
>
> On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:
>
>> 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
>>
>> On Wed, Apr 19, 2023 at 11:06 AM Rick Byers  wrote:
>>
>>> 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
>>>
>>> On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar  wrote:
>>>
 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 :(

 On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss 
 wrote:

> Friendly ping! :)
>
> On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:
>
>> 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
>>
>> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
>> wrote:
>>
>>> 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?
>>>
>>> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers 
>>> wrote:
>>>
 On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
 wrote:

> 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 
> 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 
>> wrote:
>>
>>> Hey Joey,
>>> Thanks for working to remove a quirk! Although we haven't
>>> written it into our compat principles
>>> 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Mike Taylor]

LGTM2, so long as we have a killswitch.

On 8/9/23 7:08 AM, Daniel Bratell wrote:


If I did the math correctly, that puts the likely breakage below 14% 
(95% confidence) of the population, or less than 0.002% of page loads. 
(Napkin math, don't quote me, but it's in that ballpark which is a 
good ballpark)


LGTM1

/Daniel

On 2023-08-03 03:49, Joey Arhar wrote:
I looked at the top 20 websites here: 
https://chromestatus.com/metrics/feature/timeline/popularity/4454
I looked at the option elements which were triggering the UseCounter, 
and I found that all of them seemed to have a label attribute with no 
text content at some point during page load, but then when I actually 
looked at them in DevTools after page load they all had text content.

None of those top 20 websites are affected by this change.

On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:

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

On Wed, Apr 19, 2023 at 11:06 AM Rick Byers 
wrote:

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

On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar
 wrote:

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 :(

On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss
 wrote:

Friendly ping! :)

On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey
Arhar wrote:

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

On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss
 wrote:

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?

On Sat, Jan 28, 2023 at 1:04 AM Rick Byers
 wrote:

On Thu, Jan 26, 2023 at 5:07 PM Simon
Pieters  wrote:

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
 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Daniel Bratell]

If I did the math correctly, that puts the likely breakage below 14% 
(95% confidence) of the population, or less than 0.002% of page loads. 
(Napkin math, don't quote me, but it's in that ballpark which is a good 
ballpark)


LGTM1

/Daniel

On 2023-08-03 03:49, Joey Arhar wrote:
I looked at the top 20 websites here: 
https://chromestatus.com/metrics/feature/timeline/popularity/4454
I looked at the option elements which were triggering the UseCounter, 
and I found that all of them seemed to have a label attribute with no 
text content at some point during page load, but then when I actually 
looked at them in DevTools after page load they all had text content.

None of those top 20 websites are affected by this change.

On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:

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

On Wed, Apr 19, 2023 at 11:06 AM Rick Byers 
wrote:

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

On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar
 wrote:

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 :(

On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss
 wrote:

Friendly ping! :)

On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey
Arhar wrote:

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

On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss
 wrote:

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?

On Sat, Jan 28, 2023 at 1:04 AM Rick Byers
 wrote:

On Thu, Jan 26, 2023 at 5:07 PM Simon
Pieters  wrote:

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  wrote:

Sounds good, 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

I looked at the top 20 websites here:
https://chromestatus.com/metrics/feature/timeline/popularity/4454
I looked at the option elements which were triggering the UseCounter, and I
found that all of them seemed to have a label attribute with no text
content at some point during page load, but then when I actually looked at
them in DevTools after page load they all had text content.
None of those top 20 websites are affected by this change.

On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:

> 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
>
> On Wed, Apr 19, 2023 at 11:06 AM Rick Byers  wrote:
>
>> 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
>>
>> On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar  wrote:
>>
>>> 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 :(
>>>
>>> On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss 
>>> wrote:
>>>
 Friendly ping! :)

 On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:

> 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
>
> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
> wrote:
>
>> 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?
>>
>> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers 
>> wrote:
>>
>>> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
>>> wrote:
>>>
 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 
 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 
> 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 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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

On Wed, Apr 19, 2023 at 11:06 AM Rick Byers  wrote:

> 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
>
> On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar  wrote:
>
>> 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 :(
>>
>> On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss 
>> wrote:
>>
>>> Friendly ping! :)
>>>
>>> On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:
>>>
 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

 On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
 wrote:

> 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?
>
> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers 
> wrote:
>
>> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
>> wrote:
>>
>>> 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 
>>> 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 
 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?
>>>
>>
>> Wow, 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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

On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar  wrote:

> 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 :(
>
> On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss  wrote:
>
>> Friendly ping! :)
>>
>> On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:
>>
>>> 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
>>>
>>> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
>>> wrote:
>>>
 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?

 On Sat, Jan 28, 2023 at 1:04 AM Rick Byers  wrote:

> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
> wrote:
>
>> 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 
>> 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 
>>> 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?
>>
>
> 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.
>
> cheers,
>> --
>> Simon Pieters
>> https://www.mozilla.com/
>>
> --
> 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 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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 :(

On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss  wrote:

> Friendly ping! :)
>
> On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:
>
>> 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
>>
>> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
>> wrote:
>>
>>> 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?
>>>
>>> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers  wrote:
>>>
 On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
 wrote:

> 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 
> 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 
>> 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?
>

 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.

 cheers,
> --
> Simon Pieters
> https://www.mozilla.com/
>
 --
 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+unsubscr...@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
 
 .

>>>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJmmn-cHNmFmktDB7gLGS4P%2BJd1sNK0ua0%3Dh%3DC3cLrgvQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Yoav Weiss]

Friendly ping! :)

On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:

> 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
>
> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss  
> wrote:
>
>> 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?
>>
>> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers  wrote:
>>
>>> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters  
>>> wrote:
>>>
 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  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  
> 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?

>>>
>>> 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.
>>>
>>> cheers,
 -- 
 Simon Pieters
 https://www.mozilla.com/

>>> -- 
>>> 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+unsubscr...@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
>>>  
>>> 
>>> .
>>>
>>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30263cfe-47e6-40ee-b1f6-6e25d1a08254n%40chromium.org.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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

On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss  wrote:

> 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?
>
> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers  wrote:
>
>> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
>> wrote:
>>
>>> 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  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  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?
>>>
>>
>> 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.
>>
>> cheers,
>>> --
>>> Simon Pieters
>>> https://www.mozilla.com/
>>>
>> --
>> 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+unsubscr...@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
>> 
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJD-xHCX7EuOP%3DO22yXuiHE-fFc%3D35V5Yg5UdsDhKV3%2BA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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?

On Sat, Jan 28, 2023 at 1:04 AM Rick Byers  wrote:

> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters  wrote:
>
>> 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  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  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?
>>
>
> 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.
>
> cheers,
>> --
>> Simon Pieters
>> https://www.mozilla.com/
>>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW6HPEiVjNBJHf5yNu6QhaXoJeNiQuhwo0MmRhr0orc4Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Rick Byers]

On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters  wrote:

> 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  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  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?
>

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.

cheers,
> --
> Simon Pieters
> https://www.mozilla.com/
>

-- 
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+unsubscr...@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.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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  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  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/

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC7mYC5b5G_Qpp60knzHYtbLmHd1WJ-mWXgcg3eyOabTxhTksw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

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  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
> , 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
>
>
> On Thu, Jan 19, 2023 at 3:54 PM Joey Arhar  wrote:
>
>> > 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
>>
>> On Thu, Jan 19, 2023 at 12:18 PM Mike Taylor 
>> wrote:
>>
>>> 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?
>>>
>>>
>>>
>>> *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 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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


On Thu, Jan 19, 2023 at 3:54 PM Joey Arhar  wrote:

> > 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
>
> On Thu, Jan 19, 2023 at 12:18 PM Mike Taylor 
> wrote:
>
>> 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?
>>
>>
>>
>> *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
>> .
>> --
>> You 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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

On Thu, Jan 19, 2023 at 12:18 PM Mike Taylor  wrote:

> 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?
>
>
>
> *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
> .
> --
> 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+unsubscr...@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
> 
> .
>
>
>

-- 
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+unsubscr...@chromium.org.
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.

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[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?



/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 
.

--
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+unsubscr...@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 
.


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7bc36e3c-39a0-6843-d41b-343f0e40d6e6%40chromium.org.

[blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

Contact emailsjar...@chromium.org

Specificationhttps://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 componentBlink>Forms>Select


TAG reviewNone

TAG review statusNot 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 bughttps://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
.

-- 
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+unsubscr...@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.