LGTM3 On Fri, Jun 20, 2025 at 9:00 PM Stephen Chenney <schen...@chromium.org> wrote:
> On Wed, Jun 18, 2025 at 6:36 PM Stephen Chenney <schen...@chromium.org> > wrote: > >> I would like to re-start this review. The spec PR is still waiting due a >> third party dependency. I'm in contact with that party to move it along. > > > The spec PR has been merged. > > Mozilla's position is addressed apart from the concerns about >> accessibility, and a request to clarify some caret-color behavior which is >> unrelated to the animation (https://issues.chromium.org/issues/425735683). >> Specifically, for a11y this feature may lead web sites to make the cursor >> less obvious, while for other users is can reduce motion effects, >> particularly the irregular flashing you get with animated caret colors and >> caret blinking. And sites can already set the caret-color to transparent, >> so we're not enabling new bad behavior in my view. >> >> Thanks, >> Stephen. >> >> On Tuesday, January 28, 2025 at 2:29:17 PM UTC-5 Stephen Chenney wrote: >> >> Yes Domenic, the PR to clarify when caret- properties apply would address >> my questions and at least one of Mozilla's concerns. The CSS F2F this week >> is set to discuss the PR and get agreement that it conveys the expectations >> of developers. So by Friday we should have enough to know if this can move >> forward. >> >> Mozilla's other concern was related to this being an a11y foot gun, but >> then control of caret color is already an a11y foot gun (because you can >> make it transparent) and blinking carets can impact motion-sensitive users. >> I followed up on the Mozilla issue but haven't heard back. I'll bring it to >> their attention at the F2F. >> >> Cheers, >> Stephen. >> >> On Mon, Jan 27, 2025 at 10:59 PM Domenic Denicola <dome...@chromium.org> >> wrote: >> >> 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/CAGsbWzQr5tYkCtfQZAOTE8xsroUWX >> QiGvjEQgRtF9yhJLxUO8w%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/CAM0wra9F3tsWn55D%3DyPGW5BkR0WB-zWWrXxNg0hJt-iSxPFA4g%40mail.gmail.com.
