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/CAGH7WqHVK4zeF2i_PGu814wi1EwG2FS%2BhNf9Y9J9NpCC8BY-ZQ%40mail.gmail.com.
