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/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/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/CAOMQ%2Bw-7B5jm22w69%2B00NY1yqJz%2BeeWUv3U-e6iR8dYPU%3DtRKA%40mail.gmail.com.
