It looks like on ChromeStatus there was a request to reactivate this review.
Can you clarify what is preventing https://github.com/w3c/csswg-drafts/pull/11373 from landing? Do you believe it addresses all of Mozilla's concerns? (And your concerns?) On Thursday, October 31, 2024 at 12:30:37 AM UTC+9 Chris Harrelson wrote: > Putting it back in dev trials mode SGTM. > > On Wed, Oct 30, 2024 at 11:29 AM Stephen Chenney <schen...@chromium.org> > wrote: > >> The Mozilla folks have some good points that I believe should go back to >> the CSS WG, particularly the a11y concerns. I'll put some thought into >> concrete proposals and open up spec issues. >> >> I think shipping is blocked until there is broader browser agreement. Is >> it OK if I shift the status back to "Dev Trials and Iterate" and enable it >> with Experimental Web Platform features? Can I cancel the need for API >> owners to review for now? >> >> Cheers, >> Stephen. >> >> On Wed, Oct 30, 2024 at 11:12 AM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> Hi, >>> >>> I see there was some discussion on the Mozilla standards position with >>> some possible open questions about a11y aspects. Would you consider any of >>> them blocking or needing further work? >>> >>> On Wed, Oct 30, 2024 at 9:18 AM Stephen Chenney <schen...@chromium.org> >>> wrote: >>> >>>> Thanks. WPT issue at >>>> https://github.com/web-platform-tests/wpt/issues/48882 >>>> >>>> On Wed, Oct 30, 2024 at 6:12 AM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> LGTM2 >>>>> >>>>> It's unfortunate that we can't reliably WPT test this, but I don't >>>>> think it should be a blocker. Can you file an issue against WPT to let >>>>> folks know that this is not WPT testable today (without flakiness)? >>>>> >>>>> On Thursday, October 17, 2024 at 2:39:34 AM UTC+2 Stephen Chenney >>>>> wrote: >>>>> >>>>>> I've linked the WPT test for the style code into the status entry and >>>>>> updated the test situation. While I could write a rendering test that >>>>>> worked locally it relies on the caret blinking in web_tests, which is >>>>>> disabled as a flakiness mitigation. I think it's unwise to try to change >>>>>> that given the variable blink rates across browsers and the likely >>>>>> flakiness of any test. I used unit testing for the implementation so we >>>>>> have test coverage and I also manually tested for things like caret >>>>>> browsing (which works fine with the feature and does respect caret-color. >>>>>> >>>>>> I also added the vendor signals into the status entry. >>>>>> >>>>>> Stephen. >>>>>> >>>>>> On Wed, Oct 16, 2024 at 7:02 PM Chris Harrelson < >>>>>> chris...@chromium.org> wrote: >>>>>> >>>>>>> Great. Could you link to the WPT tests also? >>>>>>> >>>>>>> Also, FTR: I think this is small enough that an independent TAG >>>>>>> review is not necessary. >>>>>>> >>>>>>> On Wed, Oct 16, 2024 at 9:13 AM Stephen Chenney < >>>>>>> schen...@chromium.org> wrote: >>>>>>> >>>>>>>> Thanks for the review. >>>>>>>> >>>>>>>> On Wed, Oct 16, 2024 at 11:24 AM Chris Harrelson < >>>>>>>> chris...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Could you please file formal positions requests for Mozilal and >>>>>>>>> Apple? >>>>>>>>> >>>>>>>> >>>>>>>> Filed https://github.com/WebKit/standards-positions/issues/417 and >>>>>>>> https://github.com/mozilla/standards-positions/issues/1100 >>>>>>>> >>>>>>>> >>>>>>>>> Also, CSSWG issue 9707 is still open, why is that? >>>>>>>>> >>>>>>>> >>>>>>>> I didn't close the issue when I added WPT tests. Closed now as >>>>>>>> there are no action items. >>>>>>>> >>>>>>>> Stephen. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Oct 16, 2024 at 8:21 AM Alex Russell < >>>>>>>>> slightly...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Thanks for the detail! LGTM1 >>>>>>>>>> >>>>>>>>>> On Saturday, October 12, 2024 at 7:19:06 PM UTC+5:30 Stephen >>>>>>>>>> Chenney wrote: >>>>>>>>>> >>>>>>>>>>> On Fri, Oct 11, 2024 at 2:23 PM Alex Russell < >>>>>>>>>>> slightly...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Is Apple is pushing back on caret animation for battery life >>>>>>>>>>>> reasons? Do we share that concern? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fortunately not. The issue for Safari is that they render the >>>>>>>>>>> caret in a way that defies customization. In the CSS WG discussion >>>>>>>>>>> the >>>>>>>>>>> Apple folks were not opposed, they just wanted it to be a "browsers >>>>>>>>>>> may >>>>>>>>>>> support this" rather than "must", with @supports to detect the >>>>>>>>>>> situation. >>>>>>>>>>> >>>>>>>>>>> From a battery perspective using this feature should be a >>>>>>>>>>> win, or at worst neutral. There will be no invalidation and >>>>>>>>>>> repainting of >>>>>>>>>>> the caret due to blinking which would typically save battery. >>>>>>>>>>> However, the >>>>>>>>>>> feature is likely to be used with caret-color animation, which does >>>>>>>>>>> a lot >>>>>>>>>>> of repainting but the blinking would not add to the cost. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Stephen. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Alex >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, October 10, 2024 at 6:17:12 AM UTC-7 Chromestatus >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Contact emails schen...@chromium.org >>>>>>>>>>>>> >>>>>>>>>>>>> Explainer https://drafts.csswg.org/css-ui/#caret-animation >>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/9707 >>>>>>>>>>>>> >>>>>>>>>>>>> Specification https://drafts.csswg.org/css-ui/#caret-animation >>>>>>>>>>>>> >>>>>>>>>>>>> Summary >>>>>>>>>>>>> >>>>>>>>>>>>> Chromium supports animation of the caret-color property, but >>>>>>>>>>>>> when animated the default blinking behavior of the caret >>>>>>>>>>>>> interferes with >>>>>>>>>>>>> the animation. For instance, see the example at >>>>>>>>>>>>> https://drafts.csswg.org/css-ui/#caret-animation where an >>>>>>>>>>>>> animation from blue to red and back is rendered as a blinking >>>>>>>>>>>>> cursor that >>>>>>>>>>>>> is randomly blue or red. The CSS caret-animation property has two >>>>>>>>>>>>> possible >>>>>>>>>>>>> values: auto and manual, where auto means browser default >>>>>>>>>>>>> (blinking) and >>>>>>>>>>>>> manual means the page author is controlling the caret animation. >>>>>>>>>>>>> In >>>>>>>>>>>>> addition, via a user stylesheet, it allows users who are >>>>>>>>>>>>> disturbed by or >>>>>>>>>>>>> have adverse reactions to blinking or flashing visuals to disable >>>>>>>>>>>>> the >>>>>>>>>>>>> blinking. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Blink component Blink>CSS >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Search tags caret-color <http:///features#tags:caret-color>, >>>>>>>>>>>>> caret-animation <http:///features#tags:caret-animation> >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review None >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>>>> >>>>>>>>>>>>> Risks >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>> >>>>>>>>>>>>> None >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Gecko*: Positive Supported the spec change. >>>>>>>>>>>>> >>>>>>>>>>>>> *WebKit*: Neutral In spec discussions, Safari indicated that >>>>>>>>>>>>> their caret does not support color animation and cannot be >>>>>>>>>>>>> customized, so >>>>>>>>>>>>> they are unlikely to implement this spec feature. >>>>>>>>>>>>> >>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>> >>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>> >>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>> >>>>>>>>>>>>> Likely to be used with existing support for caret-color >>>>>>>>>>>>> animation to improve the behavior of that feature. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Activation >>>>>>>>>>>>> >>>>>>>>>>>>> No risks. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Security >>>>>>>>>>>>> >>>>>>>>>>>>> None. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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? >>>>>>>>>>>>> >>>>>>>>>>>>> No specific Webview risk. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Debuggability >>>>>>>>>>>>> >>>>>>>>>>>>> Support in DevTools. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, 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 >>>>>>>>>>>>> >>>>>>>>>>>>> Tests will land with the feature. I have confirmed that WPT >>>>>>>>>>>>> can be created to test the feature. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Flag name on chrome://flags Experimental web platform >>>>>>>>>>>>> features >>>>>>>>>>>>> >>>>>>>>>>>>> Finch feature name CSSCaretAnimation >>>>>>>>>>>>> >>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking bug https://issues.chromium.org/issues/329301988 >>>>>>>>>>>>> >>>>>>>>>>>>> Measurement Through usual CSS feature counters. >>>>>>>>>>>>> >>>>>>>>>>>>> Availability expectation It's in the spec and relatively easy >>>>>>>>>>>>> to implement, so I would expect at least Firefox to implement. >>>>>>>>>>>>> WebKit maybe >>>>>>>>>>>>> not due to more complex caret painting. >>>>>>>>>>>>> >>>>>>>>>>>>> Adoption expectation I would expect almost anyone animating >>>>>>>>>>>>> the caret color to use this feature. caret-color itself has over >>>>>>>>>>>>> 12% usage >>>>>>>>>>>>> per page load. It is rarely animated (maybe 0.016% of loads) but >>>>>>>>>>>>> that may >>>>>>>>>>>>> well be due to the issues addressed by this change. So I would >>>>>>>>>>>>> expect >>>>>>>>>>>>> animated caret-color to maybe hit 1% over time. >>>>>>>>>>>>> >>>>>>>>>>>>> Adoption plan I would rely on organic adoption once the >>>>>>>>>>>>> feature is out and publicized. I will publicize it. >>>>>>>>>>>>> >>>>>>>>>>>>> Non-OSS dependencies >>>>>>>>>>>>> >>>>>>>>>>>>> Does the feature depend on any code or APIs outside the >>>>>>>>>>>>> Chromium open source repository and its open-source dependencies >>>>>>>>>>>>> to >>>>>>>>>>>>> function? >>>>>>>>>>>>> None. >>>>>>>>>>>>> >>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>> Shipping on desktop 133 >>>>>>>>>>>>> Shipping on Android 133 >>>>>>>>>>>>> Shipping on WebView 133 >>>>>>>>>>>>> >>>>>>>>>>>>> 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). >>>>>>>>>>>>> The feature is in the spec draft and was recently discussed >>>>>>>>>>>>> and resolved in the working group. >>>>>>>>>>>>> >>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>> https://chromestatus.com/feature/5082469066604544?gate=5119320993300480 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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/fddf09e9-6bc7-468b-83cd-cf243ac3a50fn%40chromium.org >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fddf09e9-6bc7-468b-83cd-cf243ac3a50fn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>> 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/CAGsbWzQr5tYkCtfQZAOTE8xsroUWXQiGvjEQgRtF9yhJLxUO8w%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQr5tYkCtfQZAOTE8xsroUWXQiGvjEQgRtF9yhJLxUO8w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>> 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 visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQx2dr93vTsHhANFOuF_zqs%3DexpnzfL2cihAgaRHmxKEw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQx2dr93vTsHhANFOuF_zqs%3DexpnzfL2cihAgaRHmxKEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzTe%3DLX%3DU33U5mbhNtuAV4Bw%2B%2BUKAJFLRDYsyZ-oy26a6g%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzTe%3DLX%3DU33U5mbhNtuAV4Bw%2B%2BUKAJFLRDYsyZ-oy26a6g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/536f4fc5-a80a-4903-b711-df8c873a96f0n%40chromium.org.
