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 emailsdizha...@chromium.org >>>>>>>> >>>>>>>> ExplainerNone >>>>>>>> >>>>>>>> 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 componentBlink>CSS >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>>>>> >>>>>>>> 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 >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ?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 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.
