The Mozilla folks have some good points that I believe should go back to the CSS WG, particularly the a11y concerns. I'll put some thought into concrete proposals and open up spec issues.
I think shipping is blocked until there is broader browser agreement. Is it OK if I shift the status back to "Dev Trials and Iterate" and enable it with Experimental Web Platform features? Can I cancel the need for API owners to review for now? Cheers, Stephen. On Wed, Oct 30, 2024 at 11:12 AM Chris Harrelson <chris...@chromium.org> wrote: > 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/CAGsbWzTe%3DLX%3DU33U5mbhNtuAV4Bw%2B%2BUKAJFLRDYsyZ-oy26a6g%40mail.gmail.com.
