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/CAGsbWzQLpnH8z6%2BDhvNJjP756Ytku9Vznbs9b5a4yY-cfcpR1Q%40mail.gmail.com.
