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.
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/14806d69-0bca-468c-abb9-39242fa3ed20n%40chromium.org.
