Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Di Zhang]

2024 Q1 update:
The new deprecation warnings has been in stable for multiple milestones: 
118 (October 2023) to 121 (January 2024).
The high usage appearance values are still getting used at similar rate.
*NonStandardAppearanceValuesHighUsage*: (September 2023 -> January 2024 
numbers)
* inner-spin-button at 0.0256 -> 0.024
* searchfield-cancel-button at 0.058 -> 0.050
* slider-horizontal at 0.008 -> 0.010
* push-button at 0.217 -> 0.202
* square-button at 0.0027 -> 0.0032

However, looking at the highest usage URLs, they seem to be using a generic 
website building template. For example, many sites are using the same CSS 
file where the `-webkit-appearance: push-button` is set on a reset submit 
button. But that button isn't found in the rendered site. Maybe we need a 
few more UX clicks to get to that button, but even then, I estimate the 
appearance change wouldn't be breaking.

Another data point: We have had a mismatched enum to appearance value id 
bug that reached stable (crbug.com/1495418). This caused many high usage 
values to be mapped wrongly for a month. Only one bug with one star was 
filled. This could be an indication that deprecating these >= 0.001 % of 
page loads CSS appearance values will not break websites.

My plan is to start a Finch experiment slowly in M122 and monitor reported 
bugs. If all goes well, we can officially disable/deprecate these higher 
usage values in M124.
Please let me know if you have reservations about this approach. Thanks.

On Wednesday, August 30, 2023 at 10:35:11 PM UTC-7 Kent Tamura wrote:

> LGTM3.
>
>
> On Thu, Aug 31, 2023 at 1:22 AM Daniel Bratell  
> wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2023-08-30 17:46, Alex Russell wrote:
>>
>> Thanks for being flexible here!
>>
>> LGTM1 to deprecate the first set of keywords (below < 0.001% use). Thanks 
>> for coming back to us about the second set. 
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, August 29, 2023 at 4:18:11 PM UTC-7 Di Zhang wrote:
>>
>>> Thanks to the advice above, I have done some improvements to the 
>>> deprecation warning and how/when it will get shown to the user.
>>>
>>> After discussing with the DOM team, we have decided to split the feature 
>>> into two parts. We will divide *NonStandardAppearanceValues* into two 
>>> features:
>>> *NonStandardAppearanceValuesLowUsage*: All keywords currently at usage 
>>> < 0.001.
>>> * media-slider at 0.000361
>>> * media-sliderthumb at 0.000187
>>> * media-volume-slider at 0.000143
>>> * media-volume-sliderthumb at 0.000109
>>> * sliderthumb-horizontal at 0.000182
>>> * sliderthumb-vertical at 0.14
>>>
>>> These will get removed as part of 118 and go through a slow rollout 
>>> release through Finch (before enabling in stable)
>>>
>>> *NonStandardAppearanceValuesHighUsage*: All keywords currently at usage 
>>> >= 0.001.
>>> * inner-spin-button at 0.0256
>>> * searchfield-cancel-button at 0.058
>>> * slider-horizontal at 0.008
>>> * push-button at 0.217
>>> * square-button at 0.0027
>>>
>>> These will need a few milestones to show deprecation issue and should be 
>>> re-evaluated (maybe around M120). We might find ways to reduce the numbers 
>>> by targeting some CSS import or popular sites.
>>> Please let me know if this plan sounds good and I will update the 
>>> chromestatus description accordingly.
>>> On Wednesday, August 9, 2023 at 2:34:39 AM UTC-7 Daniel Bratell wrote:
>>>
 That sounds good! Considering that the number in the use counter is 
 already so low, it should be enough to show that a majority of the users 
 only use the value that will not be removed and I'd be happy to see this 
 ship.

 /Daniel
 On 2023-07-27 22:01, Di Zhang wrote:

 Hi, 
 I had a talk with Chris and Mason, who helped me better understand the 
 steps for 2-3. I will aggregate more metrics data and share them in a 
 google doc here soon.
 * What are the websites that uses these values most
 * What elements are they using the CSS property on, are there rendering 
 differences once disabled?
 * Why are some of these value's counter higher than the aggregated 
 WebFeature::kCSSValueAppearanceNonStandard
 Thanks,
 Di

 On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:

> Hi Alex, 
> It's great to have support on this deprecation. Since we feel a 
> deprecation period of 117 to 120 is too short, I just removed the target 
> milestone. It can be updated once we have better metric pulses.
>
> For suggestion 1, the wpt test appearance-cssom-001.html 
> actually
>  
> list all of them.
> For Chrome, we are failing the 11 listed on this feature as well as 1 
> slider-vertical (for both appearance and -webkit-appearance).
> For Firefox, everything is passing: it only supports standard 
> appearance values.
> For Safari, it is failing for the newly added 3 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[TAMURA, Kent]

LGTM3.


On Thu, Aug 31, 2023 at 1:22 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-08-30 17:46, Alex Russell wrote:
>
> Thanks for being flexible here!
>
> LGTM1 to deprecate the first set of keywords (below < 0.001% use). Thanks
> for coming back to us about the second set.
>
> Best,
>
> Alex
>
> On Tuesday, August 29, 2023 at 4:18:11 PM UTC-7 Di Zhang wrote:
>
>> Thanks to the advice above, I have done some improvements to the
>> deprecation warning and how/when it will get shown to the user.
>>
>> After discussing with the DOM team, we have decided to split the feature
>> into two parts. We will divide *NonStandardAppearanceValues* into two
>> features:
>> *NonStandardAppearanceValuesLowUsage*: All keywords currently at usage <
>> 0.001.
>> * media-slider at 0.000361
>> * media-sliderthumb at 0.000187
>> * media-volume-slider at 0.000143
>> * media-volume-sliderthumb at 0.000109
>> * sliderthumb-horizontal at 0.000182
>> * sliderthumb-vertical at 0.14
>>
>> These will get removed as part of 118 and go through a slow rollout
>> release through Finch (before enabling in stable)
>>
>> *NonStandardAppearanceValuesHighUsage*: All keywords currently at usage
>> >= 0.001.
>> * inner-spin-button at 0.0256
>> * searchfield-cancel-button at 0.058
>> * slider-horizontal at 0.008
>> * push-button at 0.217
>> * square-button at 0.0027
>>
>> These will need a few milestones to show deprecation issue and should be
>> re-evaluated (maybe around M120). We might find ways to reduce the numbers
>> by targeting some CSS import or popular sites.
>> Please let me know if this plan sounds good and I will update the
>> chromestatus description accordingly.
>> On Wednesday, August 9, 2023 at 2:34:39 AM UTC-7 Daniel Bratell wrote:
>>
>>> That sounds good! Considering that the number in the use counter is
>>> already so low, it should be enough to show that a majority of the users
>>> only use the value that will not be removed and I'd be happy to see this
>>> ship.
>>>
>>> /Daniel
>>> On 2023-07-27 22:01, Di Zhang wrote:
>>>
>>> Hi,
>>> I had a talk with Chris and Mason, who helped me better understand the
>>> steps for 2-3. I will aggregate more metrics data and share them in a
>>> google doc here soon.
>>> * What are the websites that uses these values most
>>> * What elements are they using the CSS property on, are there rendering
>>> differences once disabled?
>>> * Why are some of these value's counter higher than the aggregated
>>> WebFeature::kCSSValueAppearanceNonStandard
>>> Thanks,
>>> Di
>>>
>>> On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:
>>>
 Hi Alex,
 It's great to have support on this deprecation. Since we feel a
 deprecation period of 117 to 120 is too short, I just removed the target
 milestone. It can be updated once we have better metric pulses.

 For suggestion 1, the wpt test appearance-cssom-001.html
 actually
 list all of them.
 For Chrome, we are failing the 11 listed on this feature as well as 1
 slider-vertical (for both appearance and -webkit-appearance).
 For Firefox, everything is passing: it only supports standard
 appearance values.
 For Safari, it is failing for the newly added 3 push-button,
 slider-horizontal, square-button [1], 1 internal apple-pay-button, and the
 same 1 slider-vertical.

 WebFeature::kCSSValueAppearanceNonStandard is currently tracking for
 all non-standard values, including slider-vertical. I could make them into
 2 different WebFeatures as I suspect slider-vertical is high usage value
 (as it affects how  gets rendered). Splitting it might
 decrease the usage percentage.

 Suggestions 2 and 3 are great, I don't know how to best start on them.

 [1]
 https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 was
 resolved April 2023

 Thanks,
 Di


 On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:

> Hey Di,
>
> Thanks for taking compat seriously.
>
> We chatted about this at API OWNERS this morning, and there'd broad
> support for the deprecation. There's also concern about the relatively
> short deprecation window, but maybe there are some ways we can build
> confidence? Some ideas that were contributed by Mike, Yoav, and Chris:
>
>
>- Perhaps we can look to see which keywords in this proposal are
>unsupported in other engines? E.g., if it's not compatible to use it 
> across
>Gecko, WebKit, and Blink today, perhaps it's easier to remove.
>- A spot check of the big users of these values to understand if
>there are patterns. Perhaps there's a single library, or embedded 
> script,
>that represents the bulk of use, which might lead us to some quick 
> wins for
>driving down use (e.g., targeted 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Daniel Bratell]

LGTM2

/Daniel

On 2023-08-30 17:46, Alex Russell wrote:

Thanks for being flexible here!

LGTM1 to deprecate the first set of keywords (below < 0.001% use). 
Thanks for coming back to us about the second set.


Best,

Alex

On Tuesday, August 29, 2023 at 4:18:11 PM UTC-7 Di Zhang wrote:

Thanks to the advice above, I have done some improvements to the
deprecation warning and how/when it will get shown to the user.

After discussing with the DOM team, we have decided to split the
feature into two parts. We will divide
_NonStandardAppearanceValues_ into two features:
_NonStandardAppearanceValuesLowUsage_: All keywords currently at
usage < 0.001.
* media-slider at 0.000361
* media-sliderthumb at 0.000187
* media-volume-slider at 0.000143
* media-volume-sliderthumb at 0.000109
* sliderthumb-horizontal at 0.000182
* sliderthumb-vertical at 0.14

These will get removed as part of 118 and go through a slow
rollout release through Finch (before enabling in stable)

_NonStandardAppearanceValuesHighUsage_: All keywords currently at
usage >= 0.001.
* inner-spin-button at 0.0256
* searchfield-cancel-button at 0.058
* slider-horizontal at 0.008
* push-button at 0.217
* square-button at 0.0027

These will need a few milestones to show deprecation issue and
should be re-evaluated (maybe around M120). We might find ways to
reduce the numbers by targeting some CSS import or popular sites.
Please let me know if this plan sounds good and I will update the
chromestatus description accordingly.
On Wednesday, August 9, 2023 at 2:34:39 AM UTC-7 Daniel Bratell wrote:

That sounds good! Considering that the number in the use
counter is already so low, it should be enough to show that a
majority of the users only use the value that will not be
removed and I'd be happy to see this ship.

/Daniel

On 2023-07-27 22:01, Di Zhang wrote:

Hi,
I had a talk with Chris and Mason, who helped me better
understand the steps for 2-3. I will aggregate more metrics
data and share them in a google doc here soon.
* What are the websites that uses these values most
* What elements are they using the CSS property on, are there
rendering differences once disabled?
* Why are some of these value's counter higher than the
aggregated WebFeature::kCSSValueAppearanceNonStandard
Thanks,
Di

On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:

Hi Alex,
It's great to have support on this deprecation. Since we
feel a deprecation period of 117 to 120 is too short, I
just removed the target milestone. It can be updated once
we have better metric pulses.

For suggestion 1, the wpt test appearance-cssom-001.html

actually
list all of them.
For Chrome, we are failing the 11 listed on this feature
as well as 1 slider-vertical (for both appearance and
-webkit-appearance).
For Firefox, everything is passing: it only supports
standard appearance values.
For Safari, it is failing for the newly added 3
push-button, slider-horizontal, square-button [1], 1
internal apple-pay-button, and the same 1 slider-vertical.

WebFeature::kCSSValueAppearanceNonStandard is currently
tracking for all non-standard values, including
slider-vertical. I could make them into 2 different
WebFeatures as I suspect slider-vertical is high usage
value (as it affects how  gets
rendered). Splitting it might decrease the usage percentage.

Suggestions 2 and 3 are great, I don't know how to best
start on them.

[1]

https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326

 was
resolved April 2023

Thanks,
Di


On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex
Russell wrote:

Hey Di,

Thanks for taking compat seriously.

We chatted about this at API OWNERS this morning, and
there'd broad support for the deprecation. There's
also concern about the relatively short deprecation
window, but maybe there are some ways we can build
confidence? Some ideas that were contributed by Mike,
Yoav, and Chris:

  * Perhaps we can look to see which keywords in this
proposal are unsupported in other engines? E.g.,
if it's not 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Alex Russell]

Thanks for being flexible here!

LGTM1 to deprecate the first set of keywords (below < 0.001% use). Thanks 
for coming back to us about the second set.

Best,

Alex

On Tuesday, August 29, 2023 at 4:18:11 PM UTC-7 Di Zhang wrote:

> Thanks to the advice above, I have done some improvements to the 
> deprecation warning and how/when it will get shown to the user.
>
> After discussing with the DOM team, we have decided to split the feature 
> into two parts. We will divide *NonStandardAppearanceValues* into two 
> features:
> *NonStandardAppearanceValuesLowUsage*: All keywords currently at usage < 
> 0.001.
> * media-slider at 0.000361
> * media-sliderthumb at 0.000187
> * media-volume-slider at 0.000143
> * media-volume-sliderthumb at 0.000109
> * sliderthumb-horizontal at 0.000182
> * sliderthumb-vertical at 0.14
>
> These will get removed as part of 118 and go through a slow rollout 
> release through Finch (before enabling in stable)
>
> *NonStandardAppearanceValuesHighUsage*: All keywords currently at usage 
> >= 0.001.
> * inner-spin-button at 0.0256
> * searchfield-cancel-button at 0.058
> * slider-horizontal at 0.008
> * push-button at 0.217
> * square-button at 0.0027
>
> These will need a few milestones to show deprecation issue and should be 
> re-evaluated (maybe around M120). We might find ways to reduce the numbers 
> by targeting some CSS import or popular sites.
> Please let me know if this plan sounds good and I will update the 
> chromestatus description accordingly.
> On Wednesday, August 9, 2023 at 2:34:39 AM UTC-7 Daniel Bratell wrote:
>
>> That sounds good! Considering that the number in the use counter is 
>> already so low, it should be enough to show that a majority of the users 
>> only use the value that will not be removed and I'd be happy to see this 
>> ship.
>>
>> /Daniel
>> On 2023-07-27 22:01, Di Zhang wrote:
>>
>> Hi, 
>> I had a talk with Chris and Mason, who helped me better understand the 
>> steps for 2-3. I will aggregate more metrics data and share them in a 
>> google doc here soon.
>> * What are the websites that uses these values most
>> * What elements are they using the CSS property on, are there rendering 
>> differences once disabled?
>> * Why are some of these value's counter higher than the aggregated 
>> WebFeature::kCSSValueAppearanceNonStandard
>> Thanks,
>> Di
>>
>> On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:
>>
>>> Hi Alex, 
>>> It's great to have support on this deprecation. Since we feel a 
>>> deprecation period of 117 to 120 is too short, I just removed the target 
>>> milestone. It can be updated once we have better metric pulses.
>>>
>>> For suggestion 1, the wpt test appearance-cssom-001.html 
>>> actually
>>>  
>>> list all of them.
>>> For Chrome, we are failing the 11 listed on this feature as well as 1 
>>> slider-vertical (for both appearance and -webkit-appearance).
>>> For Firefox, everything is passing: it only supports standard appearance 
>>> values.
>>> For Safari, it is failing for the newly added 3 push-button, 
>>> slider-horizontal, square-button [1], 1 internal apple-pay-button, and the 
>>> same 1 slider-vertical.
>>>
>>> WebFeature::kCSSValueAppearanceNonStandard is currently tracking for all 
>>> non-standard values, including slider-vertical. I could make them into 2 
>>> different WebFeatures as I suspect slider-vertical is high usage value (as 
>>> it affects how  gets rendered). Splitting it might 
>>> decrease the usage percentage.
>>>
>>> Suggestions 2 and 3 are great, I don't know how to best start on them.
>>>
>>> [1] 
>>> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 was 
>>> resolved April 2023
>>>
>>> Thanks,
>>> Di
>>>
>>>
>>> On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:
>>>
 Hey Di, 

 Thanks for taking compat seriously.

 We chatted about this at API OWNERS this morning, and there'd broad 
 support for the deprecation. There's also concern about the relatively 
 short deprecation window, but maybe there are some ways we can build 
 confidence? Some ideas that were contributed by Mike, Yoav, and Chris:


- Perhaps we can look to see which keywords in this proposal are 
unsupported in other engines? E.g., if it's not compatible to use it 
 across 
Gecko, WebKit, and Blink today, perhaps it's easier to remove. 
- A spot check of the big users of these values to understand if 
there are patterns. Perhaps there's a single library, or embedded 
 script, 
that represents the bulk of use, which might lead us to some quick wins 
 for 
driving down use (e.g., targeted outreach). 
- DevRel might be able to help spread the word about deprecation. 

 In general, I think there's support for marking this as deprecated 
 quickly, but it might be better if we agree 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Di Zhang]

Thanks to the advice above, I have done some improvements to the 
deprecation warning and how/when it will get shown to the user.

After discussing with the DOM team, we have decided to split the feature 
into two parts. We will divide *NonStandardAppearanceValues* into two 
features:
*NonStandardAppearanceValuesLowUsage*: All keywords currently at usage < 
0.001.
* media-slider at 0.000361
* media-sliderthumb at 0.000187
* media-volume-slider at 0.000143
* media-volume-sliderthumb at 0.000109
* sliderthumb-horizontal at 0.000182
* sliderthumb-vertical at 0.14

These will get removed as part of 118 and go through a slow rollout release 
through Finch (before enabling in stable)

*NonStandardAppearanceValuesHighUsage*: All keywords currently at usage >= 
0.001.
* inner-spin-button at 0.0256
* searchfield-cancel-button at 0.058
* slider-horizontal at 0.008
* push-button at 0.217
* square-button at 0.0027

These will need a few milestones to show deprecation issue and should be 
re-evaluated (maybe around M120). We might find ways to reduce the numbers 
by targeting some CSS import or popular sites.
Please let me know if this plan sounds good and I will update the 
chromestatus description accordingly.
On Wednesday, August 9, 2023 at 2:34:39 AM UTC-7 Daniel Bratell wrote:

> That sounds good! Considering that the number in the use counter is 
> already so low, it should be enough to show that a majority of the users 
> only use the value that will not be removed and I'd be happy to see this 
> ship.
>
> /Daniel
> On 2023-07-27 22:01, Di Zhang wrote:
>
> Hi, 
> I had a talk with Chris and Mason, who helped me better understand the 
> steps for 2-3. I will aggregate more metrics data and share them in a 
> google doc here soon.
> * What are the websites that uses these values most
> * What elements are they using the CSS property on, are there rendering 
> differences once disabled?
> * Why are some of these value's counter higher than the aggregated 
> WebFeature::kCSSValueAppearanceNonStandard
> Thanks,
> Di
>
> On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:
>
>> Hi Alex, 
>> It's great to have support on this deprecation. Since we feel a 
>> deprecation period of 117 to 120 is too short, I just removed the target 
>> milestone. It can be updated once we have better metric pulses.
>>
>> For suggestion 1, the wpt test appearance-cssom-001.html 
>> actually
>>  
>> list all of them.
>> For Chrome, we are failing the 11 listed on this feature as well as 1 
>> slider-vertical (for both appearance and -webkit-appearance).
>> For Firefox, everything is passing: it only supports standard appearance 
>> values.
>> For Safari, it is failing for the newly added 3 push-button, 
>> slider-horizontal, square-button [1], 1 internal apple-pay-button, and the 
>> same 1 slider-vertical.
>>
>> WebFeature::kCSSValueAppearanceNonStandard is currently tracking for all 
>> non-standard values, including slider-vertical. I could make them into 2 
>> different WebFeatures as I suspect slider-vertical is high usage value (as 
>> it affects how  gets rendered). Splitting it might 
>> decrease the usage percentage.
>>
>> Suggestions 2 and 3 are great, I don't know how to best start on them.
>>
>> [1] 
>> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 was 
>> resolved April 2023
>>
>> Thanks,
>> Di
>>
>>
>> On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:
>>
>>> Hey Di, 
>>>
>>> Thanks for taking compat seriously.
>>>
>>> We chatted about this at API OWNERS this morning, and there'd broad 
>>> support for the deprecation. There's also concern about the relatively 
>>> short deprecation window, but maybe there are some ways we can build 
>>> confidence? Some ideas that were contributed by Mike, Yoav, and Chris:
>>>
>>>
>>>- Perhaps we can look to see which keywords in this proposal are 
>>>unsupported in other engines? E.g., if it's not compatible to use it 
>>> across 
>>>Gecko, WebKit, and Blink today, perhaps it's easier to remove. 
>>>- A spot check of the big users of these values to understand if 
>>>there are patterns. Perhaps there's a single library, or embedded 
>>> script, 
>>>that represents the bulk of use, which might lead us to some quick wins 
>>> for 
>>>driving down use (e.g., targeted outreach). 
>>>- DevRel might be able to help spread the word about deprecation. 
>>>
>>> In general, I think there's support for marking this as deprecated 
>>> quickly, but it might be better if we agree to revisit the removal date 
>>> based on evidence in the future. WDYT?
>>>
>>> Best,
>>>
>>> Alex
>>>
>>>
>>>
>>> On Tuesday, July 25, 2023 at 4:03:15 PM UTC-7 Di Zhang wrote:
>>>
 Thanks for the feedback. The counter does feel high, I will follow the 
 Deprecation steps [1] and extend the milestones (likely DevTrial 117 and 
 Shipping 3 milestones later at 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Daniel Bratell]

That sounds good! Considering that the number in the use counter is 
already so low, it should be enough to show that a majority of the users 
only use the value that will not be removed and I'd be happy to see this 
ship.


/Daniel

On 2023-07-27 22:01, Di Zhang wrote:

Hi,
I had a talk with Chris and Mason, who helped me better understand the 
steps for 2-3. I will aggregate more metrics data and share them in a 
google doc here soon.

* What are the websites that uses these values most
* What elements are they using the CSS property on, are there 
rendering differences once disabled?
* Why are some of these value's counter higher than the aggregated 
WebFeature::kCSSValueAppearanceNonStandard

Thanks,
Di

On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:

Hi Alex,
It's great to have support on this deprecation. Since we feel a
deprecation period of 117 to 120 is too short, I just removed the
target milestone. It can be updated once we have better metric pulses.

For suggestion 1, the wpt test appearance-cssom-001.html

actually
list all of them.
For Chrome, we are failing the 11 listed on this feature as well
as 1 slider-vertical (for both appearance and -webkit-appearance).
For Firefox, everything is passing: it only supports standard
appearance values.
For Safari, it is failing for the newly added 3 push-button,
slider-horizontal, square-button [1], 1 internal apple-pay-button,
and the same 1 slider-vertical.

WebFeature::kCSSValueAppearanceNonStandard is currently tracking
for all non-standard values, including slider-vertical. I could
make them into 2 different WebFeatures as I suspect
slider-vertical is high usage value (as it affects how  gets rendered). Splitting it might decrease the usage
percentage.

Suggestions 2 and 3 are great, I don't know how to best start on them.

[1]
https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326
 
was
resolved April 2023

Thanks,
Di


On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:

Hey Di,

Thanks for taking compat seriously.

We chatted about this at API OWNERS this morning, and there'd
broad support for the deprecation. There's also concern about
the relatively short deprecation window, but maybe there are
some ways we can build confidence? Some ideas that were
contributed by Mike, Yoav, and Chris:

  * Perhaps we can look to see which keywords in this proposal
are unsupported in other engines? E.g., if it's not
compatible to use it across Gecko, WebKit, and Blink
today, perhaps it's easier to remove.
  * A spot check of the big users of these values to
understand if there are patterns. Perhaps there's a single
library, or embedded script, that represents the bulk of
use, which might lead us to some quick wins for driving
down use (e.g., targeted outreach).
  * DevRel might be able to help spread the word about
deprecation.

In general, I think there's support for marking this as
deprecated quickly, but it might be better if we agree to
revisit the removal date based on evidence in the future. WDYT?

Best,

Alex



On Tuesday, July 25, 2023 at 4:03:15 PM UTC-7 Di Zhang wrote:

Thanks for the feedback. The counter does feel high, I
will follow the Deprecation steps [1] and extend the
milestones (likely DevTrial 117 and Shipping 3 milestones
later at 120).

[1]

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md



On Monday, July 24, 2023 at 11:29:06 PM UTC-7 Yoav Weiss
wrote:

Thanks!! So IIUC, any usage will result in rendering
changes? If that's indeed the case, I think it makes
sense to try and drive usage down before changing
behavior..

On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent
 wrote:

Valid appearance keywords have some side-effects
even though they have no special painting.
 * Skip border painting
 * 'display' property value is changed to
'inline-block' or 'block'.  So some properties
such as 'width' 'height' are not ignored.


Valid
Invalid


 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Di Zhang]

Hi,
I had a talk with Chris and Mason, who helped me better understand the 
steps for 2-3. I will aggregate more metrics data and share them in a 
google doc here soon.
* What are the websites that uses these values most
* What elements are they using the CSS property on, are there rendering 
differences once disabled?
* Why are some of these value's counter higher than the aggregated 
WebFeature::kCSSValueAppearanceNonStandard
Thanks,
Di

On Wednesday, July 26, 2023 at 5:04:17 PM UTC-7 Di Zhang wrote:

> Hi Alex,
> It's great to have support on this deprecation. Since we feel a 
> deprecation period of 117 to 120 is too short, I just removed the target 
> milestone. It can be updated once we have better metric pulses.
>
> For suggestion 1, the wpt test appearance-cssom-001.html 
> actually
>  
> list all of them.
> For Chrome, we are failing the 11 listed on this feature as well as 1 
> slider-vertical (for both appearance and -webkit-appearance).
> For Firefox, everything is passing: it only supports standard appearance 
> values.
> For Safari, it is failing for the newly added 3 push-button, 
> slider-horizontal, square-button [1], 1 internal apple-pay-button, and the 
> same 1 slider-vertical.
>
> WebFeature::kCSSValueAppearanceNonStandard is currently tracking for all 
> non-standard values, including slider-vertical. I could make them into 2 
> different WebFeatures as I suspect slider-vertical is high usage value (as 
> it affects how  gets rendered). Splitting it might 
> decrease the usage percentage.
>
> Suggestions 2 and 3 are great, I don't know how to best start on them.
>
> [1] 
> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 was 
> resolved April 2023
>
> Thanks,
> Di
>
>
> On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:
>
>> Hey Di,
>>
>> Thanks for taking compat seriously.
>>
>> We chatted about this at API OWNERS this morning, and there'd broad 
>> support for the deprecation. There's also concern about the relatively 
>> short deprecation window, but maybe there are some ways we can build 
>> confidence? Some ideas that were contributed by Mike, Yoav, and Chris:
>>
>>
>>- Perhaps we can look to see which keywords in this proposal are 
>>unsupported in other engines? E.g., if it's not compatible to use it 
>> across 
>>Gecko, WebKit, and Blink today, perhaps it's easier to remove.
>>- A spot check of the big users of these values to understand if 
>>there are patterns. Perhaps there's a single library, or embedded script, 
>>that represents the bulk of use, which might lead us to some quick wins 
>> for 
>>driving down use (e.g., targeted outreach).
>>- DevRel might be able to help spread the word about deprecation.
>>
>> In general, I think there's support for marking this as deprecated 
>> quickly, but it might be better if we agree to revisit the removal date 
>> based on evidence in the future. WDYT?
>>
>> Best,
>>
>> Alex
>>
>>
>>
>> On Tuesday, July 25, 2023 at 4:03:15 PM UTC-7 Di Zhang wrote:
>>
>>> Thanks for the feedback. The counter does feel high, I will follow the 
>>> Deprecation steps [1] and extend the milestones (likely DevTrial 117 and 
>>> Shipping 3 milestones later at 120).
>>>
>>> [1] 
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md
>>>
>>> On Monday, July 24, 2023 at 11:29:06 PM UTC-7 Yoav Weiss wrote:
>>>
 Thanks!! So IIUC, any usage will result in rendering changes? If that's 
 indeed the case, I think it makes sense to try and drive usage down before 
 changing behavior.. 

 On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent  
 wrote:

> Valid appearance keywords have some side-effects even though they have 
> no special painting.
>  * Skip border painting
>  * 'display' property value is changed to 'inline-block' or 'block'.  
> So some properties such as 'width' 'height' are not ignored.
>
> 
> Valid
> Invalid
> 
>
> On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  
> wrote:
>
>> tkent@ - can you expand on the compat risk? It's not immediately 
>> obvious to me what these apps were doing that resulted in a rendering 
>> difference.
>>
>> On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:
>>
>>> Removing appearance keywords which have no painting code might have 
>>> compatibility issues. We removed the keyword "caret" in the past, and 
>>> it 
>>> caused issues like crbug.com/944023.
>>>
>>> The counter for this is 
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4416. 
>>> The value is 0.005 - 0.02.
>>>
>>> I recommend having a deprecation period before removal.
>>>
>>> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  
>>> wrote:
>>>
 Contact emailsdizha...@chromium.org

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Di Zhang]

Hi Alex,
It's great to have support on this deprecation. Since we feel a deprecation 
period of 117 to 120 is too short, I just removed the target milestone. It 
can be updated once we have better metric pulses.

For suggestion 1, the wpt test appearance-cssom-001.html 
actually 
list all of them.
For Chrome, we are failing the 11 listed on this feature as well as 1 
slider-vertical (for both appearance and -webkit-appearance).
For Firefox, everything is passing: it only supports standard appearance 
values.
For Safari, it is failing for the newly added 3 push-button, 
slider-horizontal, square-button [1], 1 internal apple-pay-button, and the 
same 1 slider-vertical.

WebFeature::kCSSValueAppearanceNonStandard is currently tracking for all 
non-standard values, including slider-vertical. I could make them into 2 
different WebFeatures as I suspect slider-vertical is high usage value (as 
it affects how  gets rendered). Splitting it might 
decrease the usage percentage.

Suggestions 2 and 3 are great, I don't know how to best start on them.

[1] https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 was 
resolved April 2023

Thanks,
Di


On Wednesday, July 26, 2023 at 3:48:55 PM UTC-7 Alex Russell wrote:

> Hey Di,
>
> Thanks for taking compat seriously.
>
> We chatted about this at API OWNERS this morning, and there'd broad 
> support for the deprecation. There's also concern about the relatively 
> short deprecation window, but maybe there are some ways we can build 
> confidence? Some ideas that were contributed by Mike, Yoav, and Chris:
>
>
>- Perhaps we can look to see which keywords in this proposal are 
>unsupported in other engines? E.g., if it's not compatible to use it 
> across 
>Gecko, WebKit, and Blink today, perhaps it's easier to remove.
>- A spot check of the big users of these values to understand if there 
>are patterns. Perhaps there's a single library, or embedded script, that 
>represents the bulk of use, which might lead us to some quick wins for 
>driving down use (e.g., targeted outreach).
>- DevRel might be able to help spread the word about deprecation.
>
> In general, I think there's support for marking this as deprecated 
> quickly, but it might be better if we agree to revisit the removal date 
> based on evidence in the future. WDYT?
>
> Best,
>
> Alex
>
>
>
> On Tuesday, July 25, 2023 at 4:03:15 PM UTC-7 Di Zhang wrote:
>
>> Thanks for the feedback. The counter does feel high, I will follow the 
>> Deprecation steps [1] and extend the milestones (likely DevTrial 117 and 
>> Shipping 3 milestones later at 120).
>>
>> [1] 
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md
>>
>> On Monday, July 24, 2023 at 11:29:06 PM UTC-7 Yoav Weiss wrote:
>>
>>> Thanks!! So IIUC, any usage will result in rendering changes? If that's 
>>> indeed the case, I think it makes sense to try and drive usage down before 
>>> changing behavior.. 
>>>
>>> On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent  
>>> wrote:
>>>
 Valid appearance keywords have some side-effects even though they have 
 no special painting.
  * Skip border painting
  * 'display' property value is changed to 'inline-block' or 'block'.  
 So some properties such as 'width' 'height' are not ignored.

 
 Valid
 Invalid
 

 On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  
 wrote:

> tkent@ - can you expand on the compat risk? It's not immediately 
> obvious to me what these apps were doing that resulted in a rendering 
> difference.
>
> On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:
>
>> Removing appearance keywords which have no painting code might have 
>> compatibility issues. We removed the keyword "caret" in the past, and it 
>> caused issues like crbug.com/944023.
>>
>> The counter for this is 
>> https://chromestatus.com/metrics/feature/timeline/popularity/4416. 
>> The value is 0.005 - 0.02.
>>
>> I recommend having a deprecation period before removal.
>>
>> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  
>> wrote:
>>
>>> Contact emailsdizha...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>>>
>>> Summary
>>>
>>> Since only standard appearance keywords should be supported, we are 
>>> removing the appearance (and -webkit-appearance) keywords that 
>>> shouldn't be 
>>> supported anymore: * inner-spin-button * media-slider * 
>>> media-sliderthumb * 
>>> media-volume-slider * media-volume-sliderthumb * push-button * 
>>> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal 
>>> * 
>>> sliderthumb-vertical * square-button Note that value "slider-vertical" 
>>> will 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Alex Russell]

Hey Di,

Thanks for taking compat seriously.

We chatted about this at API OWNERS this morning, and there'd broad support 
for the deprecation. There's also concern about the relatively short 
deprecation window, but maybe there are some ways we can build confidence? 
Some ideas that were contributed by Mike, Yoav, and Chris:


   - Perhaps we can look to see which keywords in this proposal are 
   unsupported in other engines? E.g., if it's not compatible to use it across 
   Gecko, WebKit, and Blink today, perhaps it's easier to remove.
   - A spot check of the big users of these values to understand if there 
   are patterns. Perhaps there's a single library, or embedded script, that 
   represents the bulk of use, which might lead us to some quick wins for 
   driving down use (e.g., targeted outreach).
   - DevRel might be able to help spread the word about deprecation.

In general, I think there's support for marking this as deprecated quickly, 
but it might be better if we agree to revisit the removal date based on 
evidence in the future. WDYT?

Best,

Alex



On Tuesday, July 25, 2023 at 4:03:15 PM UTC-7 Di Zhang wrote:

> Thanks for the feedback. The counter does feel high, I will follow the 
> Deprecation steps [1] and extend the milestones (likely DevTrial 117 and 
> Shipping 3 milestones later at 120).
>
> [1] 
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md
>
> On Monday, July 24, 2023 at 11:29:06 PM UTC-7 Yoav Weiss wrote:
>
>> Thanks!! So IIUC, any usage will result in rendering changes? If that's 
>> indeed the case, I think it makes sense to try and drive usage down before 
>> changing behavior.. 
>>
>> On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent  wrote:
>>
>>> Valid appearance keywords have some side-effects even though they have 
>>> no special painting.
>>>  * Skip border painting
>>>  * 'display' property value is changed to 'inline-block' or 'block'.  So 
>>> some properties such as 'width' 'height' are not ignored.
>>>
>>> 
>>> Valid
>>> Invalid
>>> 
>>>
>>> On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  
>>> wrote:
>>>
 tkent@ - can you expand on the compat risk? It's not immediately 
 obvious to me what these apps were doing that resulted in a rendering 
 difference.

 On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:

> Removing appearance keywords which have no painting code might have 
> compatibility issues. We removed the keyword "caret" in the past, and it 
> caused issues like crbug.com/944023.
>
> The counter for this is 
> https://chromestatus.com/metrics/feature/timeline/popularity/4416. 
> The value is 0.005 - 0.02.
>
> I recommend having a deprecation period before removal.
>
> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  
> wrote:
>
>> Contact emailsdizha...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>>
>> Summary
>>
>> Since only standard appearance keywords should be supported, we are 
>> removing the appearance (and -webkit-appearance) keywords that shouldn't 
>> be 
>> supported anymore: * inner-spin-button * media-slider * 
>> media-sliderthumb * 
>> media-volume-slider * media-volume-sliderthumb * push-button * 
>> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal * 
>> sliderthumb-vertical * square-button Note that value "slider-vertical" 
>> will 
>> not be removed as part of this patch it is used for allowing > type=range> vertical. It will be removed once feature 
>> FormControlsVerticalWritingModeSupport is enabled in stable. Previously, 
>> if 
>> using any of the above keywords, a console warning will be shown, but 
>> the 
>> keyword will be recognized as a valid value. With the feature enabled, 
>> there will be no console warning. The appearance property will be 
>> ignored 
>> and set to the empty string. The use count (under 
>> WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 
>> 2023 
>> [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2] 
>> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 
>> [3] 
>> https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub
>>
>>
>> Blink componentBlink>CSS 
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature only affects the reflection in computed style. 
>> Currently, while it is possible to set an appearance value with one of 
>> these non-standard values, it will not affect the appearance of that 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Di Zhang]

Thanks for the feedback. The counter does feel high, I will follow the 
Deprecation steps [1] and extend the milestones (likely DevTrial 117 and 
Shipping 3 milestones later at 120).

[1] 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md

On Monday, July 24, 2023 at 11:29:06 PM UTC-7 Yoav Weiss wrote:

> Thanks!! So IIUC, any usage will result in rendering changes? If that's 
> indeed the case, I think it makes sense to try and drive usage down before 
> changing behavior.. 
>
> On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent  wrote:
>
>> Valid appearance keywords have some side-effects even though they have no 
>> special painting.
>>  * Skip border painting
>>  * 'display' property value is changed to 'inline-block' or 'block'.  So 
>> some properties such as 'width' 'height' are not ignored.
>>
>> 
>> Valid
>> Invalid
>> 
>>
>> On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  
>> wrote:
>>
>>> tkent@ - can you expand on the compat risk? It's not immediately obvious 
>>> to me what these apps were doing that resulted in a rendering difference.
>>>
>>> On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:
>>>
 Removing appearance keywords which have no painting code might have 
 compatibility issues. We removed the keyword "caret" in the past, and it 
 caused issues like crbug.com/944023.

 The counter for this is 
 https://chromestatus.com/metrics/feature/timeline/popularity/4416. The 
 value is 0.005 - 0.02.

 I recommend having a deprecation period before removal.

 On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  wrote:

> Contact emailsdizha...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Summary
>
> Since only standard appearance keywords should be supported, we are 
> removing the appearance (and -webkit-appearance) keywords that shouldn't 
> be 
> supported anymore: * inner-spin-button * media-slider * media-sliderthumb 
> * 
> media-volume-slider * media-volume-sliderthumb * push-button * 
> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal * 
> sliderthumb-vertical * square-button Note that value "slider-vertical" 
> will 
> not be removed as part of this patch it is used for allowing  type=range> vertical. It will be removed once feature 
> FormControlsVerticalWritingModeSupport is enabled in stable. Previously, 
> if 
> using any of the above keywords, a console warning will be shown, but the 
> keyword will be recognized as a valid value. With the feature enabled, 
> there will be no console warning. The appearance property will be ignored 
> and set to the empty string. The use count (under 
> WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 
> 2023 
> [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2] 
> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326 
> [3] 
> https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub
>
>
> Blink componentBlink>CSS 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature only affects the reflection in computed style. Currently, 
> while it is possible to set an appearance value with one of these 
> non-standard values, it will not affect the appearance of that element. 
> Now, if appearance is set to one of these non-standard values, the 
> returned 
> computed appearance value will be auto. It is unlikely websites depend on 
> this information: this deprecation should be web compatible.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> There are no other platform APIS this will be used in tandem with and 
> this will not make it hard for chrome to maintain good performance.
>
>
> Activation
>
> There should be no challenge for developers to take advantage of this 
> feature immediately.
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such 
> that it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> The non-standard appearance values we are removing are already not 
> listed in the autocomplete in DevTools.
>
>
> Will this feature be supported on all six Blink platforms (Windows, 
> Mac, Linux, Chrome OS, Android, and Android 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Yoav Weiss]

Thanks!! So IIUC, any usage will result in rendering changes? If that's
indeed the case, I think it makes sense to try and drive usage down before
changing behavior..

On Tue, Jul 25, 2023 at 12:08 AM TAMURA, Kent  wrote:

> Valid appearance keywords have some side-effects even though they have no
> special painting.
>  * Skip border painting
>  * 'display' property value is changed to 'inline-block' or 'block'.  So
> some properties such as 'width' 'height' are not ignored.
>
> 
> Valid
> Invalid
> 
>
> On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  wrote:
>
>> tkent@ - can you expand on the compat risk? It's not immediately obvious
>> to me what these apps were doing that resulted in a rendering difference.
>>
>> On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:
>>
>>> Removing appearance keywords which have no painting code might have
>>> compatibility issues. We removed the keyword "caret" in the past, and it
>>> caused issues like crbug.com/944023.
>>>
>>> The counter for this is
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4416. The
>>> value is 0.005 - 0.02.
>>>
>>> I recommend having a deprecation period before removal.
>>>
>>> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  wrote:
>>>
 Contact emailsdizha...@chromium.org

 ExplainerNone

 Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching

 Summary

 Since only standard appearance keywords should be supported, we are
 removing the appearance (and -webkit-appearance) keywords that shouldn't be
 supported anymore: * inner-spin-button * media-slider * media-sliderthumb *
 media-volume-slider * media-volume-sliderthumb * push-button *
 searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal *
 sliderthumb-vertical * square-button Note that value "slider-vertical" will
 not be removed as part of this patch it is used for allowing >>> type=range> vertical. It will be removed once feature
 FormControlsVerticalWritingModeSupport is enabled in stable. Previously, if
 using any of the above keywords, a console warning will be shown, but the
 keyword will be recognized as a valid value. With the feature enabled,
 there will be no console warning. The appearance property will be ignored
 and set to the empty string. The use count (under
 WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 2023
 [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2]
 https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326
 [3]
 https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub


 Blink componentBlink>CSS
 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 This feature only affects the reflection in computed style. Currently,
 while it is possible to set an appearance value with one of these
 non-standard values, it will not affect the appearance of that element.
 Now, if appearance is set to one of these non-standard values, the returned
 computed appearance value will be auto. It is unlikely websites depend on
 this information: this deprecation should be web compatible.


 *Gecko*: Shipped/Shipping

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 There are no other platform APIS this will be used in tandem with and
 this will not make it hard for chrome to maintain good performance.


 Activation

 There should be no challenge for developers to take advantage of this
 feature immediately.


 Security

 N/A


 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?

 None


 Debuggability

 The non-standard appearance values we are removing are already not
 listed in the autocomplete in DevTools.


 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 on chrome://flagsRemoveNonStandardAppearanceValue

 Finch feature name

 Non-finch justificationNone

 Requires code in //chrome?False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=924486

 Estimated milestones
 Shipping on desktop 117
 DevTrial on desktop 115
 Shipping on Android 117
 DevTrial on Android 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[TAMURA, Kent]

Valid appearance keywords have some side-effects even though they have no
special painting.
 * Skip border painting
 * 'display' property value is changed to 'inline-block' or 'block'.  So
some properties such as 'width' 'height' are not ignored.


Valid
Invalid


On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss  wrote:

> tkent@ - can you expand on the compat risk? It's not immediately obvious
> to me what these apps were doing that resulted in a rendering difference.
>
> On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:
>
>> Removing appearance keywords which have no painting code might have
>> compatibility issues. We removed the keyword "caret" in the past, and it
>> caused issues like crbug.com/944023.
>>
>> The counter for this is
>> https://chromestatus.com/metrics/feature/timeline/popularity/4416. The
>> value is 0.005 - 0.02.
>>
>> I recommend having a deprecation period before removal.
>>
>> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  wrote:
>>
>>> Contact emailsdizha...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>>>
>>> Summary
>>>
>>> Since only standard appearance keywords should be supported, we are
>>> removing the appearance (and -webkit-appearance) keywords that shouldn't be
>>> supported anymore: * inner-spin-button * media-slider * media-sliderthumb *
>>> media-volume-slider * media-volume-sliderthumb * push-button *
>>> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal *
>>> sliderthumb-vertical * square-button Note that value "slider-vertical" will
>>> not be removed as part of this patch it is used for allowing >> type=range> vertical. It will be removed once feature
>>> FormControlsVerticalWritingModeSupport is enabled in stable. Previously, if
>>> using any of the above keywords, a console warning will be shown, but the
>>> keyword will be recognized as a valid value. With the feature enabled,
>>> there will be no console warning. The appearance property will be ignored
>>> and set to the empty string. The use count (under
>>> WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 2023
>>> [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2]
>>> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326
>>> [3]
>>> https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature only affects the reflection in computed style. Currently,
>>> while it is possible to set an appearance value with one of these
>>> non-standard values, it will not affect the appearance of that element.
>>> Now, if appearance is set to one of these non-standard values, the returned
>>> computed appearance value will be auto. It is unlikely websites depend on
>>> this information: this deprecation should be web compatible.
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> There are no other platform APIS this will be used in tandem with and
>>> this will not make it hard for chrome to maintain good performance.
>>>
>>>
>>> Activation
>>>
>>> There should be no challenge for developers to take advantage of this
>>> feature immediately.
>>>
>>>
>>> Security
>>>
>>> N/A
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> The non-standard appearance values we are removing are already not
>>> listed in the autocomplete in DevTools.
>>>
>>>
>>> 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 on chrome://flagsRemoveNonStandardAppearanceValue
>>>
>>> Finch feature name
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=924486
>>>
>>> Estimated milestones
>>> Shipping on desktop 117
>>> DevTrial on desktop 115
>>> Shipping on Android 117
>>> DevTrial on Android 115
>>> Shipping on WebView 117
>>>
>>> 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
>>> 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[Yoav Weiss]

tkent@ - can you expand on the compat risk? It's not immediately obvious to
me what these apps were doing that resulted in a rendering difference.

On Mon, Jul 24, 2023, 03:45 TAMURA, Kent  wrote:

> Removing appearance keywords which have no painting code might have
> compatibility issues. We removed the keyword "caret" in the past, and it
> caused issues like crbug.com/944023.
>
> The counter for this is
> https://chromestatus.com/metrics/feature/timeline/popularity/4416. The
> value is 0.005 - 0.02.
>
> I recommend having a deprecation period before removal.
>
> On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  wrote:
>
>> Contact emailsdizha...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>>
>> Summary
>>
>> Since only standard appearance keywords should be supported, we are
>> removing the appearance (and -webkit-appearance) keywords that shouldn't be
>> supported anymore: * inner-spin-button * media-slider * media-sliderthumb *
>> media-volume-slider * media-volume-sliderthumb * push-button *
>> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal *
>> sliderthumb-vertical * square-button Note that value "slider-vertical" will
>> not be removed as part of this patch it is used for allowing > type=range> vertical. It will be removed once feature
>> FormControlsVerticalWritingModeSupport is enabled in stable. Previously, if
>> using any of the above keywords, a console warning will be shown, but the
>> keyword will be recognized as a valid value. With the feature enabled,
>> there will be no console warning. The appearance property will be ignored
>> and set to the empty string. The use count (under
>> WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 2023
>> [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2]
>> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326
>> [3]
>> https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature only affects the reflection in computed style. Currently,
>> while it is possible to set an appearance value with one of these
>> non-standard values, it will not affect the appearance of that element.
>> Now, if appearance is set to one of these non-standard values, the returned
>> computed appearance value will be auto. It is unlikely websites depend on
>> this information: this deprecation should be web compatible.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> There are no other platform APIS this will be used in tandem with and
>> this will not make it hard for chrome to maintain good performance.
>>
>>
>> Activation
>>
>> There should be no challenge for developers to take advantage of this
>> feature immediately.
>>
>>
>> Security
>>
>> N/A
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> The non-standard appearance values we are removing are already not listed
>> in the autocomplete in DevTools.
>>
>>
>> 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 on chrome://flagsRemoveNonStandardAppearanceValue
>>
>> Finch feature name
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=924486
>>
>> Estimated milestones
>> Shipping on desktop 117
>> DevTrial on desktop 115
>> Shipping on Android 117
>> DevTrial on Android 115
>> Shipping on WebView 117
>>
>> 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).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5066630972833792
>>
>> Links to previous Intent discussions
>>
>> 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 

Re: [blink-dev] Intent to Ship: Remove non-standard appearance keywords

[TAMURA, Kent]

Removing appearance keywords which have no painting code might have
compatibility issues. We removed the keyword "caret" in the past, and it
caused issues like crbug.com/944023.

The counter for this is
https://chromestatus.com/metrics/feature/timeline/popularity/4416. The
value is 0.005 - 0.02.

I recommend having a deprecation period before removal.

On Thu, Jul 20, 2023 at 3:54 AM Di Zhang  wrote:

> Contact emailsdizha...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Summary
>
> Since only standard appearance keywords should be supported, we are
> removing the appearance (and -webkit-appearance) keywords that shouldn't be
> supported anymore: * inner-spin-button * media-slider * media-sliderthumb *
> media-volume-slider * media-volume-sliderthumb * push-button *
> searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal *
> sliderthumb-vertical * square-button Note that value "slider-vertical" will
> not be removed as part of this patch it is used for allowing  type=range> vertical. It will be removed once feature
> FormControlsVerticalWritingModeSupport is enabled in stable. Previously, if
> using any of the above keywords, a console warning will be shown, but the
> keyword will be recognized as a valid value. With the feature enabled,
> there will be no console warning. The appearance property will be ignored
> and set to the empty string. The use count (under
> WebFeature::kCSSValueAppearanceNonStandard) is at 0.005985% as of July 2023
> [3]. [1] https://drafts.csswg.org/css-ui-4/#appearance-switching [2]
> https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326
> [3]
> https://docs.google.com/document/d/e/2PACX-1vTP-wXiSV9_dSbbs4OEH-XqP0hakmoTwmEBkEJ-EAI3vDmlXxWMdHvCYl01QqUHm7q6iw8ubK0d3xk1/pub
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature only affects the reflection in computed style. Currently,
> while it is possible to set an appearance value with one of these
> non-standard values, it will not affect the appearance of that element.
> Now, if appearance is set to one of these non-standard values, the returned
> computed appearance value will be auto. It is unlikely websites depend on
> this information: this deprecation should be web compatible.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> There are no other platform APIS this will be used in tandem with and this
> will not make it hard for chrome to maintain good performance.
>
>
> Activation
>
> There should be no challenge for developers to take advantage of this
> feature immediately.
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> The non-standard appearance values we are removing are already not listed
> in the autocomplete in DevTools.
>
>
> 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 on chrome://flagsRemoveNonStandardAppearanceValue
>
> Finch feature name
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=924486
>
> Estimated milestones
> Shipping on desktop 117
> DevTrial on desktop 115
> Shipping on Android 117
> DevTrial on Android 115
> Shipping on WebView 117
>
> 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).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5066630972833792
>
> Links to previous Intent discussions
>
> 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/CA%2BSS7eAE3At9QiJ-XymVFxUc7Z2%2B06xGTBOk%2B%3D7sGGNHvt5HSg%40mail.gmail.com
>