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 <bratel...@gmail.com> 
> 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.000014
>>>
>>> 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 
>>>>> <http://wpt.live/css/css-ui/appearance-cssom-001.html?include=Invalid>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 <input type=range> 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 <tk...@chromium.org> 
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> <p>
>>>>>>>>> <span style="border:2px solid red; height:3em; background:yellow; 
>>>>>>>>> appearance:media-slider;">Valid</span>
>>>>>>>>> <span style="border:2px solid red; height:3em; background:yellow; 
>>>>>>>>> appearance:foobar;">Invalid</span>
>>>>>>>>> </p>
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2023 at 5:00 PM Yoav Weiss <yoavwe...@chromium.org> 
>>>>>>>>> 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 <tk...@chromium.org> 
>>>>>>>>>> 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 <dizha...@chromium.org> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Contact emails dizha...@chromium.org
>>>>>>>>>>>>
>>>>>>>>>>>> Explainer None
>>>>>>>>>>>>
>>>>>>>>>>>> Specification 
>>>>>>>>>>>> https://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 <input 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 component Blink>CSS 
>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>>>>
>>>>>>>>>>>> TAG review None
>>>>>>>>>>>>
>>>>>>>>>>>> TAG review status Not 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 
>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>>>> ? Yes
>>>>>>>>>>>>
>>>>>>>>>>>> Flag name on chrome://flags RemoveNonStandardAppearanceValue
>>>>>>>>>>>>
>>>>>>>>>>>> Finch feature name 
>>>>>>>>>>>>
>>>>>>>>>>>> Non-finch justification None
>>>>>>>>>>>>
>>>>>>>>>>>> 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 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 
>>>>>>>>>>>> <https://chromestatus.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/CA%2BSS7eAE3At9QiJ-XymVFxUc7Z2%2B06xGTBOk%2B%3D7sGGNHvt5HSg%40mail.gmail.com
>>>>>>>>>>>>  
>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eAE3At9QiJ-XymVFxUc7Z2%2B06xGTBOk%2B%3D7sGGNHvt5HSg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> TAMURA Kent 
>>>>>>>>>>> Software Engineer, Google 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> 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/CAGH7WqGmooLg362nFsWDC7JaYt3RaztUfccdtT5%2BA4_QFNJWJA%40mail.gmail.com
>>>>>>>>>>>  
>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGmooLg362nFsWDC7JaYt3RaztUfccdtT5%2BA4_QFNJWJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> TAMURA Kent 
>>>>>>>>> Software Engineer, Google 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>> 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/08b21853-52aa-4eaf-8224-a69aa747b665n%40chromium.org
>>>>  
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/08b21853-52aa-4eaf-8224-a69aa747b665n%40chromium.org?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>>
>
> -- 
> TAMURA Kent 
> Software Engineer, Google 
>
>
>

-- 
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/8a9261dd-eab1-4b59-acf9-e43930aab48en%40chromium.org.

Reply via email to