Putting it back in dev trials mode SGTM. On Wed, Oct 30, 2024 at 11:29 AM Stephen Chenney <schen...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzTe%3DLX%3DU33U5mbhNtuAV4Bw%2B%2BUKAJFLRDYsyZ-oy26a6g%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_TbP5zqJ1XLUoBPmBGTtHhzOoUJi4qd979euapJjLwTg%40mail.gmail.com.
