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.
