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/CAGsbWzQr5tYkCtfQZAOTE8xsroUWXQiGvjEQgRtF9yhJLxUO8w%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/ad92d62c-c021-405a-9533-16d9b882e23cn%40chromium.org.
