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.
