[blink-dev] Intent to Prototype: SoftNavigation performance entry

[Yoav Weiss]

Contact emailsyoavwe...@chromium.org

Explainerhttps://bit.ly/soft-navigation
https://docs.google.com/document/d/1eUyQg3YLEmYjrTMC3p-F1MilECwCynhM6WIbIo05SPU/edit

Specification

Not yet!

Summary

Exposes (experimental) soft navigation heuristics
 to web developers, using both
PerformanceObserver and the performance timeline.

Blink componentBlink>PerformanceAPIs


Motivation

Web developers have been asking
 for a way to take
"soft navigations" - JS-driven navigations in Single Page Apps (SPA) - into
account when exposing performance metrics. This exposes a browser heuristic
to that effect. Doing that would enable developers to initially validate
the heuristic compared to their own application- and framework-specific
heuristics. Once validated, they can start relying on it when calculating
the performance impact of various routes in their SPAs.


Initial public proposal

TAG review

Not yet. Once we validate that the heuristic makes sense and move on to
specify it (and the underlying Task Attribution
 concept, which will be a heavier lift),
it would make sense for the TAG to review this. I'll file one as early as
possible, but once they actually have something to review :)


TAG review statusNot yet!

Risks


Interoperability and Compatibility



*Gecko*: No signal for now. Will file later.

*WebKit*: No signal for now. Will file later.

*Web developers*: Some excitement
!

*Other signals*:

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?



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1338390

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144837209194496

This intent message was generated by Chrome Platform Status
.

-- 
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/CAL5BFfV3qRFx0i-eGJFSzqE8bnbX8XYJCvXAj0LfvO0icPo_jA%40mail.gmail.com.

[blink-dev] Re: Intent to Prototype: FileSystemHandle::remove() method

[Austin Sullivan]

On Fri, Sep 9, 2022 at 4:15 PM Austin Sullivan  wrote:

> Contact emails
>
> asu...@chromium.org
>
> Explainer
>
> https://github.com/whatwg/fs/pull/9
>
> Summary
>
> Currently, it is not possible to remove a file or directory given its
> handle. You must obtain the handle of the parent directory and call
> FileSystemDirectoryHandle::removeEntry().
>
> Introducing a new method, FileSystemHandle::remove(),  enables the common
> use case where you obtain a file handle from showSaveFilePicker(), but then
> decide you don't want to save after all, and delete the file.
>
> NOTE: The code for this already landed behind a flag; we're filing this
> I2P retroactively.
>
>
> Blink component
>
> Blink>Storage>FileSystem
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/773
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive (
> https://github.com/WICG/file-system-access/pull/283#issuecomment-1036085470
> )
>
> WebKit: No signal
>
> Web developers: Positive (
> https://github.com/WICG/file-system-access/issues/214). Also
> https://crbug.com/1114923
>
> Other signals:
>
> Ergonomics
>
> This will improve the ergonomics of the API.
>
> Currently, if a file handle is obtained via the showSaveFilePicker() API,
> the site has no way to remove the file if the user changes their mind and
> wants the file deleted, leaving the file system in an awkward state. The
> remove() method fills this gap.
>
>
> Security
>
> Files and directories will only be removable if the user has explicitly
> granted read/write access to the handle.
>
> This method will take an exclusive read/write lock to the file. It's
> possible that the file is locked by another site (e.g. if the site has an
> open FileSystemWritableFileStream to the file). In this case, the remove()
> operation will fail with a locking error. The site is aware that the file
> is locked, but it does not know how or by whom. This is not a concern.
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No. The File System Access API is not yet supported on Android (tracking
> bug )
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes (link
> 
> )
>
> Flag name
>
> FileSystemAccessAPIExperimental
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1114923
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6318478849998848
>
> This intent message was generated by Chrome Platform Status
> .
>
>

-- 
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/CAGnvaEVjDmRuhtZsetaR069oNYr4ae6VQtK6MUb3wfiOuN0D8A%40mail.gmail.com.

[blink-dev] Intent to Prototype: FileSystemHandle::remove() method

[Austin Sullivan]

Contact emails

asu...@chromium.org

Explainer

https://github.com/whatwg/fs/pull/9

Summary

Currently, it is not possible to remove a file or directory given its
handle. You must obtain the handle of the parent directory and call
FileSystemDirectoryHandle::removeEntry().

Introducing a new method, FileSystemHandle::remove(),  enables the common
use case where you obtain a file handle from showSaveFilePicker(), but then
decide you don't want to save after all, and delete the file.

NOTE: The code for this already landed behind a flag; we're filing this I2P
retroactively.


Blink component

Blink>Storage>FileSystem


TAG review

https://github.com/w3ctag/design-reviews/issues/773

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: Positive (
https://github.com/WICG/file-system-access/pull/283#issuecomment-1036085470)

WebKit: No signal

Web developers: Positive (
https://github.com/WICG/file-system-access/issues/214). Also
https://crbug.com/1114923

Other signals:

Ergonomics

This will improve the ergonomics of the API.

Currently, if a file handle is obtained via the showSaveFilePicker() API,
the site has no way to remove the file if the user changes their mind and
wants the file deleted, leaving the file system in an awkward state. The
remove() method fills this gap.


Security

Files and directories will only be removable if the user has explicitly
granted read/write access to the handle.

This method will take an exclusive read/write lock to the file. It's
possible that the file is locked by another site (e.g. if the site has an
open FileSystemWritableFileStream to the file). In this case, the remove()
operation will fail with a locking error. The site is aware that the file
is locked, but it does not know how or by whom. This is not a concern.


Debuggability

N/A


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

No. The File System Access API is not yet supported on Android (tracking bug
)

Is this feature fully tested by web-platform-tests

?

Yes (link

)

Flag name

FileSystemAccessAPIExperimental

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1114923


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6318478849998848

This intent message was generated by Chrome Platform Status
.

-- 
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/CAGnvaEXfqHczZgmn6MjPFWzxsFTqWnzeWTikhrQWXk5ZTpxs2g%40mail.gmail.com.

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[Josh Karlin]

Topics, Fenced Frames, and Attribution Reporting are now ramping up to 1%
on Android stable.

Josh

On Thu, Sep 1, 2022 at 2:01 PM Josh Karlin  wrote:

> Hi folks. I wanted to bring your attention to a post from FLEDGE API
> Announce
> 
> list today that impacts experimenters:
>
> "We've discovered a bug in FLEDGE, so we are ramping down FLEDGE for
> Chrome Stable in the Privacy Sandbox Relevance and Measurement origin
> trial
> .
> Other APIs in the trial are unaffected.
>
> We've identified a fix for the bug and are working to validate it and
> re-enable the origin trial for FLEDGE with the fix soon (roughly two weeks
> from now if all goes well)."
>
> Best,
>
> Josh
>
> On Wed, Aug 24, 2022 at 8:29 AM Josh Karlin  wrote:
>
>> Hey folks. Shared Storage's
>>  
>> selectURL()
>> operation will begin to ramp up on canary/dev/beta in the next 24 hours at
>> 50%. Aggregate reporting is forthcoming.
>>
>> Best,
>>
>> Josh
>>
>> On Thu, Aug 11, 2022 at 11:39 AM Josh Karlin 
>> wrote:
>>
>>> We've been asked if canary/dev/beta will continue to hold at 50% while
>>> stable is at 1%. Yes, the pre-stable channels will continue at 50%.
>>>
>>> On Wed, Aug 10, 2022 at 5:45 PM Josh Karlin 
>>> wrote:
>>>
 I should clarify that this stable push to m104 is for desktop only.
 Mobile is coming later.

 On Wed, Aug 10, 2022, 1:35 PM Josh Karlin  wrote:

> The unified origin trial will start ramping up to 1% of M104 Stable
> traffic tomorrow, August 11th.
>
> On Fri, Jun 3, 2022 at 1:22 PM Josh Karlin 
> wrote:
>
>> The unified origin trial is also now at 50% of Chrome Beta for the
>> Topics API as of May 27th.
>>
>>
>> On Mon, May 23, 2022 at 6:23 PM John Delaney 
>> wrote:
>>
>>> The unified origin trial for the Privacy Sandbox Ads APIs is now at
>>> 50% of Chrome Beta population for FLEDGE and Attribution Reporting.  A
>>> stability issue was identified and fixed in Topics code, and we expect 
>>> the
>>> API to be available to 50% of Chrome Canary and Chrome Dev by the end of
>>> today, and 50% of Beta users within a few days.  Reports from early 
>>> testers
>>> help us identify and address such technical issues. This is to be 
>>> expected
>>> in the early days of origin trials and the reason we proceed gradually.
>>>
>>> We expect the origin trial to remain in Beta for at least a few more
>>> weeks to help us identify and address any additional issues.  Once we’re
>>> confident we’ve fixed any major open issues, we will provide an update 
>>> with
>>> a timeline for moving the origin trial to Chrome Stable for expanded
>>> testing with a larger volume of traffic.  To get support, report 
>>> issues, or
>>> provide feedback please see the resources for Topics
>>> 
>>> , FLEDGE
>>> 
>>>  and Attribution Reporting
>>> 
>>> .
>>> On Thursday, April 28, 2022 at 4:18:05 PM UTC-4 John Delaney wrote:
>>>
 The unified origin trial for the Privacy Sandbox relevance and
 measurement APIs (Topics, FLEDGE and Attribution Reporting) is 
 available in
 Chrome Beta.  We plan to ramp up to approximately 50% of the Chrome 
 Beta
 population within the next two weeks.  We will continue to run the 
 origin
 trial in Chrome Beta to evaluate the functionality of the APIs and the
 accompanying user controls.   Technical testing is an important first 
 step
 in the origin trial process;  developers are encouraged to provide 
 feedback
 on API functionality, documentation and ease of integration.  To get
 support, report issues, or provide feedback please see these resources 
 for
 Topics
 ,
 FLEDGE
 
 and Attribution Reporting
 .


 We will provide updates soon on when we expect to advance the
 origin trial to Chrome Stable, with increased traffic volume to support
 additional testing.

 On Friday, April 8, 2022 at 4:17:12 PM UTC-4 John Delaney wrote:

> Hi blink-dev,
>

[blink-dev] Intent to Prototype: Intl.DurationFormat

[Frank Tang]

Contact emailsft...@google.com

Explainerhttps://github.com/tc39/proposal-intl-duration-format

Specificationhttps://tc39.es/proposal-intl-duration-format

Summary

Intl.DurationFormat API is a TC39 ECMA402 proposal See
https://github.com/tc39/proposal-intl-duration-format for the proposal The
proposal advanced to Stage 3 on 2021-10 Spec:
https://tc39.es/proposal-intl-duration-format/


Blink componentBlink>JavaScript>Internationalization


Motivation

This TC39/ECMA402 proposal advanced to Stage 3 in Oct 2021. Users need all
types of duration formatting depending on the requirements of their
application. For example, to show how long a flight takes, the duration
should be in Short or Narrow format "1 hr 40 min 60 sec" → Short "1h 40m
60s" → Narrow And such format are different in different locale. This API
enacpsulate the details of such formatting and provide an unified API
supporting multiple locales.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: In development (
https://bugzilla.mozilla.org/show_bug.cgi?id=1648139)

*WebKit*: In development (https://bugs.webkit.org/show_bug.cgi?id=214794)

*Web developers*: Positive (https://github.com/tc39/ecma402-mdn/issues/22)

*Other signals*:

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?



Debuggability

tbw


Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=11660

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5193021205774336

This intent message was generated by Chrome Platform Status
.

-- 
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/CAOcELL-vykLL8UDTG1QcKptGfyRPw8T6StP2%2BqMPFv09aUHPbg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Khushal Sagar]

On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss  wrote:

> Thanks for meticulously gathering that data!!
>
> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
> is noticeable breakage but not necessarily an insurmountable one.
> The numbers are a bit higher than I'd like, but at the same time, this
> enables new capabilities and we're not walking this path alone
> 
> .
>
> Given the above, *LGTM1* for a careful and monitored rollout, accompanied
> with DevRel folks supporting y'all in communicating this change to
> developers.
> What are the timelines you have in mind? Is there some way to use
> Deprecation Reporting to help us here?
>

I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a
week before each progression in M107. The release will go to stable
~October 25th (schedule ).

In terms of outreach a console warning

and a deprecation warning

was
added in M105 for cases where the element's computed style can cause this
behaviour change. I've also reached out to the dev rel folks for a targeted
email to affected sites that came up through our CT analysis.


>
> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar 
> wrote:
>
>> We have UseCounter data from M105 stable to quantify the large breakage
>> for this feature. Large is a page load where any image, video or canvas
>> drawn on the page paints over 5k CSS pixels outside its content-box. The
>> precise numbers (with page load count) are here
>> 
>>  (sorry
>> can't share the details externally).
>>
>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
>> large breakage category and Android had ~0.007%.
>>
>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss 
>>> wrote:
>>>


 On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <
 khushalsa...@chromium.org> wrote:

>
>
> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
> wrote:
>
>> Thanks Khushal! :)
>>
>> The breakage seems potentially significant (at worst, makes the site
>> visually broken and unusable), and the percentage of breakage seems above
>> the threshold we typically consider safe.
>> At the same time this seems like a positive change, and our friends
>> at Mozilla consider it "worth prototyping".
>>
>> Would it be possible to consider this as a deprecation of the old
>> behavior, and run the console issue (+deprecation warnings and outreach 
>> to
>> affected sites) for a few milestones, to try and drive the usage down
>> before flipping this change to be on by default? Maybe also get some
>> documentation out there and work with devrel folks to make sure folks are
>> aware of this coming change?
>>
>> Does that sound reasonable?
>>
>
> Thanks for the suggestion Yoav. This sounds reasonable. I've reached
> out to the devrel folks to do more outreach about this change. I'll update
> this thread with the plan for it. The console issue and deprecation
> warnings have been added in M105.
>
> I looked into adding a use counter for sites which have real breakage,
> since the current metric tracks whether the computed style *could* permit
> allow but not whether there is actual overflow at paint time. And
> unfortunately computing potential overflow is not easy to add. The CT
> analysis I ran earlier did this by turning the feature on and tracking
> actual overflow generated by the element. So a couple of questions for
> moving forward:
>
> - Would it be okay to turn the feature on in beta and 1% stable (in
> M105) to collect metrics for the sites with real breakage and the extent 
> of
> this breakage (how many pixels of overflow do we see). This should be 
> lower
> than the counter of 0.017%.
>

 That sounds like a great way to gather data! (assuming the relevant
 Chrome processes are followed)
 Would be good to gather a histogram of overflowed pixels, to get a
 sense of "small breakage" vs. "large breakage".


>
> - What's the number (in terms of page loads affected) we should be
> targeting before this would be safe?
>

 From my perspective, I'd be comfortable shipping this if we're seeing
 less than 0.003% of page loads in the "large breakage" bucket (say more
 than ~5000 overflowing pixels, assuming that number makes sense).

 +Andre Bandarra  - for devrel opinions on this.

>>>
>>> Currently we're recording a UseCounter when any breakage would happen,
>>

[blink-dev] Query regarding CSS opacity attribute value coming 0,1(zero comma 1)

[uzair jaleel]

Hello,

We are currently working on linux based chromium version 94.0.4606.31.

When *we set Google chrome language as "English"* below is opacity value of 
an div element in webste  https://www.samsung.com/de




When *we set Google chrome language as "deutsch"* below is opacity value of 
an div element in webste  https://www.samsung.com/de



Any input as to why CSS opacity attribute value is coming as 0,1(zero comma 
1) in style in content side on language change ( English to deutsch)  ?

Also what is expected behaviour on blink side(source code side) when it 
encounters value 0,1 for opacity ?

Any input would be helpfull

Thanks

-- 
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/bec8d287-bc01-438c-95eb-c59306c93698n%40chromium.org.

Re: [blink-dev] Intent to ship: Sec-CH-Prefers-Reduced-Motion client hint header

[Yoav Weiss]

On Fri, Sep 9, 2022 at 4:21 PM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> fbeauf...@chromium.org, to...@chromium.org
>
> Explainer
>
>
> https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md
>
> Specification
>
>
> https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-motion
>

It seems worthwhile to properly specify that the hints in question are
high-entropy hints that are not sent without an opt-in.
Based on https://github.com/WebKit/standards-positions/issues/15, it
doesn't seem like that is clear.


>
> API spec
>
> Yes
>
> Summary
>
> The Sec-CH-Prefers-Reduced-Motion client hint is modeled after the
> prefers-reduced-motion user preference media feature as defined in Media
> Queries Level 5. This headers follows Sec-CH-Prefers-Color-Scheme, which
> was described in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms.
>
> Blink component
>
> Blink>CSS
>
> Motivation
>
> CSS media queries, and specifically user preference media features like
> prefers-reduced-motion, have a potentially significant impact on the
> amount of CSS that needs to be delivered by a page, and on the experience
> the user is going to have when the page loads.
>
> It is a best practice to not load CSS responsible for animations in the
> critical rendering path if the user prefers reduced motion, but to instead
> only load said CSS if the user doesn't mind motion. One way of doing so is
> via . However, high-traffic sites like Google Search that
> wish to honor user preference media features like prefers-reduced-motion
> and that inline CSS for performance reasons, need to know about the motion
> preferences (or other user preference media features respectively) ideally
> at request time, so that the initial HTML payload already has the right CSS
> inlined.
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/632
>
> TAG review status
>
> Unsatisfied
>
> Demo link
>
> https://sec-ch-prefers-reduced-motion.glitch.me/
>
> Debuggability
>
> Developers can change the Sec-CH-Prefers-Reduced-Motion client hint
> header value by emulating motion preferences via DevTools in the Rendering
> panel like they can do with the Sec-CH-Prefers-Color-Scheme client hint
> header today.
>
> Measurement
>
> The kClientHintsPrefersReducedMotion WebFeature tracks
> Sec-CH-Prefers-Reduced-Motion client hint usage.
>
> Risks
>
>
> Interoperability and Compatibility
> There are no particular compatibility risks.
>
> Interoperability is still pending on other browser vendors replying.
> Support for Client Hints in general is not enthusiastic though.
>
>
> Signals from other implementations (Gecko, WebKit):
>
> Gecko: Pending (https://github.com/mozilla/standards-positions/issues/526)
>
> WebKit: Pending (
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html, now
> migrated to https://github.com/WebKit/standards-positions/issues/15)
>
> Web / Framework developers: Positive (WICG proposal Issue:
> https://github.com/WICG/proposals/issues/30 with feedback from developers
> working for Facebook
>  and
> Magento
> .
> Twitter: https://twitter.com/kilianvalkhof/status/1392404416335056896.
> The proposal was initially discussed in
> https://github.com/w3c/csswg-drafts/issues/4162 and received positive
> feedback via 16 Likes and 3 supportive comments:
> https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-621047333,
> https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-631400330,
> and https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-645742958).
> Google Search is interested in this header, too.
>
> Ergonomics:
>
> N/A
>
> Activation:
>
> Developers will include Sec-CH-Prefers-Reduced-Motion in the response
> headers Accept-CH and Critical-CH to let the browser know that they’re
> interested in the motion preferences. If supported, the request header
> Sec-CH-Prefers-Reduced-Motion will be populated with the appropriate
> value.
>
> Is this feature fully tested by web-platform-tests?
>
> Yes. https://wpt.fyi/results/client-hints.
>
> Tracking bug
>
> https://crbug.com/1361871
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5141804190531584
>
> --
> 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/CALgRrL%3DgTkCO%3DmZErYjf1BCyQAPFNNMv3KJFPpFEFV3Ev6%3DrtA%40mail.gmail.com
> 
> .
>

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Yoav Weiss]

Thanks for meticulously gathering that data!!

Just to give a rough idea - 5K pixels would be 50x100 pixels, which
is noticeable breakage but not necessarily an insurmountable one.
The numbers are a bit higher than I'd like, but at the same time, this
enables new capabilities and we're not walking this path alone

.

Given the above, *LGTM1* for a careful and monitored rollout, accompanied
with DevRel folks supporting y'all in communicating this change to
developers.
What are the timelines you have in mind? Is there some way to use
Deprecation Reporting to help us here?

On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar 
wrote:

> We have UseCounter data from M105 stable to quantify the large breakage
> for this feature. Large is a page load where any image, video or canvas
> drawn on the page paints over 5k CSS pixels outside its content-box. The
> precise numbers (with page load count) are here
> 
>  (sorry
> can't share the details externally).
>
> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
> large breakage category and Android had ~0.007%.
>
> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
> wrote:
>
>>
>>
>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar 
>>> wrote:
>>>


 On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
 wrote:

> Thanks Khushal! :)
>
> The breakage seems potentially significant (at worst, makes the site
> visually broken and unusable), and the percentage of breakage seems above
> the threshold we typically consider safe.
> At the same time this seems like a positive change, and our friends at
> Mozilla consider it "worth prototyping".
>
> Would it be possible to consider this as a deprecation of the old
> behavior, and run the console issue (+deprecation warnings and outreach to
> affected sites) for a few milestones, to try and drive the usage down
> before flipping this change to be on by default? Maybe also get some
> documentation out there and work with devrel folks to make sure folks are
> aware of this coming change?
>
> Does that sound reasonable?
>

 Thanks for the suggestion Yoav. This sounds reasonable. I've reached
 out to the devrel folks to do more outreach about this change. I'll update
 this thread with the plan for it. The console issue and deprecation
 warnings have been added in M105.

 I looked into adding a use counter for sites which have real breakage,
 since the current metric tracks whether the computed style *could* permit
 allow but not whether there is actual overflow at paint time. And
 unfortunately computing potential overflow is not easy to add. The CT
 analysis I ran earlier did this by turning the feature on and tracking
 actual overflow generated by the element. So a couple of questions for
 moving forward:

 - Would it be okay to turn the feature on in beta and 1% stable (in
 M105) to collect metrics for the sites with real breakage and the extent of
 this breakage (how many pixels of overflow do we see). This should be lower
 than the counter of 0.017%.

>>>
>>> That sounds like a great way to gather data! (assuming the relevant
>>> Chrome processes are followed)
>>> Would be good to gather a histogram of overflowed pixels, to get a sense
>>> of "small breakage" vs. "large breakage".
>>>
>>>

 - What's the number (in terms of page loads affected) we should be
 targeting before this would be safe?

>>>
>>> From my perspective, I'd be comfortable shipping this if we're seeing
>>> less than 0.003% of page loads in the "large breakage" bucket (say more
>>> than ~5000 overflowing pixels, assuming that number makes sense).
>>>
>>> +Andre Bandarra  - for devrel opinions on this.
>>>
>>
>> Currently we're recording a UseCounter when any breakage would happen,
>> i.e, there is any pixel overflow. If it helps to have a UseCounter for
>> overflow above a threshold, I'm happy to add that too.
>>
>> We do have an UMA metric which measures the number of overflowing pixels
>> when there is overflow but it's for all images rendered. I can tie it to
>> the UseCounter so we can also know the number of affected page loads with
>> large breakage. I'll wait till the end of the week for more feedback,
>> otherwise assume 5k is a good threshold for large breakage.
>>
>>
>>>
>>>


>
> Cheers,
> Yoav
>
> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>
>> Hey folks,
>>
>> I'm summarizing the steps to mitigate the compat risk with this
>> feature based on the feedback:
>>
>>- Add a warning to the console when a developer style would
>>permit replaced elements

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Khushal Sagar]

We have UseCounter data from M105 stable to quantify the large breakage for
this feature. Large is a page load where any image, video or canvas drawn
on the page paints over 5k CSS pixels outside its content-box. The precise
numbers (with page load count) are here

(sorry
can't share the details externally).

In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
large breakage category and Android had ~0.007%.

On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
wrote:

>
>
> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss  wrote:
>
>>
>>
>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
>>> wrote:
>>>
 Thanks Khushal! :)

 The breakage seems potentially significant (at worst, makes the site
 visually broken and unusable), and the percentage of breakage seems above
 the threshold we typically consider safe.
 At the same time this seems like a positive change, and our friends at
 Mozilla consider it "worth prototyping".

 Would it be possible to consider this as a deprecation of the old
 behavior, and run the console issue (+deprecation warnings and outreach to
 affected sites) for a few milestones, to try and drive the usage down
 before flipping this change to be on by default? Maybe also get some
 documentation out there and work with devrel folks to make sure folks are
 aware of this coming change?

 Does that sound reasonable?

>>>
>>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached out
>>> to the devrel folks to do more outreach about this change. I'll update this
>>> thread with the plan for it. The console issue and deprecation warnings
>>> have been added in M105.
>>>
>>> I looked into adding a use counter for sites which have real breakage,
>>> since the current metric tracks whether the computed style *could* permit
>>> allow but not whether there is actual overflow at paint time. And
>>> unfortunately computing potential overflow is not easy to add. The CT
>>> analysis I ran earlier did this by turning the feature on and tracking
>>> actual overflow generated by the element. So a couple of questions for
>>> moving forward:
>>>
>>> - Would it be okay to turn the feature on in beta and 1% stable (in
>>> M105) to collect metrics for the sites with real breakage and the extent of
>>> this breakage (how many pixels of overflow do we see). This should be lower
>>> than the counter of 0.017%.
>>>
>>
>> That sounds like a great way to gather data! (assuming the relevant
>> Chrome processes are followed)
>> Would be good to gather a histogram of overflowed pixels, to get a sense
>> of "small breakage" vs. "large breakage".
>>
>>
>>>
>>> - What's the number (in terms of page loads affected) we should be
>>> targeting before this would be safe?
>>>
>>
>> From my perspective, I'd be comfortable shipping this if we're seeing
>> less than 0.003% of page loads in the "large breakage" bucket (say more
>> than ~5000 overflowing pixels, assuming that number makes sense).
>>
>> +Andre Bandarra  - for devrel opinions on this.
>>
>
> Currently we're recording a UseCounter when any breakage would happen,
> i.e, there is any pixel overflow. If it helps to have a UseCounter for
> overflow above a threshold, I'm happy to add that too.
>
> We do have an UMA metric which measures the number of overflowing pixels
> when there is overflow but it's for all images rendered. I can tie it to
> the UseCounter so we can also know the number of affected page loads with
> large breakage. I'll wait till the end of the week for more feedback,
> otherwise assume 5k is a good threshold for large breakage.
>
>
>>
>>
>>>
>>>

 Cheers,
 Yoav

 On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:

> Hey folks,
>
> I'm summarizing the steps to mitigate the compat risk with this
> feature based on the feedback:
>
>- Add a warning to the console when a developer style would permit
>replaced elements to overflow. The patch to add that is here
> and
>documentation to help developers debug, which is referenced in the 
> console
>warning, is here
>.
>We can pre-emptively add this warning to M105 and ship the feature in 
> M106
>to have a one release window before the behaviour changes.
>
>- Send an email to the webmaster of sites surfaced in the CT
>analysis which already have the styles that trigger the warning above.
>
> In addition to the above, the feature can be turned off with a
> server-side config using finch if there is any severe breakage.
>
> Please let me know if the above suffices.
>
>

[blink-dev] Intent to ship: Sec-CH-Prefers-Reduced-Motion client hint header

['Thomas Steiner' via blink-dev]

Contact emails

fbeauf...@chromium.org, to...@chromium.org

Explainer

https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md

Specification

https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-motion

API spec

Yes

Summary

The Sec-CH-Prefers-Reduced-Motion client hint is modeled after the
prefers-reduced-motion user preference media feature as defined in Media
Queries Level 5. This headers follows Sec-CH-Prefers-Color-Scheme, which
was described in
https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms.

Blink component

Blink>CSS

Motivation

CSS media queries, and specifically user preference media features like
prefers-reduced-motion, have a potentially significant impact on the amount
of CSS that needs to be delivered by a page, and on the experience the user
is going to have when the page loads.

It is a best practice to not load CSS responsible for animations in the
critical rendering path if the user prefers reduced motion, but to instead
only load said CSS if the user doesn't mind motion. One way of doing so is
via . However, high-traffic sites like Google Search that wish
to honor user preference media features like prefers-reduced-motion and
that inline CSS for performance reasons, need to know about the motion
preferences (or other user preference media features respectively) ideally
at request time, so that the initial HTML payload already has the right CSS
inlined.

TAG review

https://github.com/w3ctag/design-reviews/issues/632

TAG review status

Unsatisfied

Demo link

https://sec-ch-prefers-reduced-motion.glitch.me/

Debuggability

Developers can change the Sec-CH-Prefers-Reduced-Motion client hint header
value by emulating motion preferences via DevTools in the Rendering panel
like they can do with the Sec-CH-Prefers-Color-Scheme client hint header
today.

Measurement

The kClientHintsPrefersReducedMotion WebFeature tracks
Sec-CH-Prefers-Reduced-Motion client hint usage.

Risks


Interoperability and Compatibility
There are no particular compatibility risks.

Interoperability is still pending on other browser vendors replying.
Support for Client Hints in general is not enthusiastic though.


Signals from other implementations (Gecko, WebKit):

Gecko: Pending (https://github.com/mozilla/standards-positions/issues/526)

WebKit: Pending (
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html, now
migrated to https://github.com/WebKit/standards-positions/issues/15)

Web / Framework developers: Positive (WICG proposal Issue:
https://github.com/WICG/proposals/issues/30 with feedback from developers
working for Facebook
 and
Magento .
Twitter: https://twitter.com/kilianvalkhof/status/1392404416335056896. The
proposal was initially discussed in
https://github.com/w3c/csswg-drafts/issues/4162 and received positive
feedback via 16 Likes and 3 supportive comments:
https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-621047333,
https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-631400330, and
https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-645742958).
Google Search is interested in this header, too.

Ergonomics:

N/A

Activation:

Developers will include Sec-CH-Prefers-Reduced-Motion in the response
headers Accept-CH and Critical-CH to let the browser know that they’re
interested in the motion preferences. If supported, the request header
Sec-CH-Prefers-Reduced-Motion will be populated with the appropriate value.

Is this feature fully tested by web-platform-tests?

Yes. https://wpt.fyi/results/client-hints.

Tracking bug

https://crbug.com/1361871

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5141804190531584

-- 
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/CALgRrL%3DgTkCO%3DmZErYjf1BCyQAPFNNMv3KJFPpFEFV3Ev6%3DrtA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Variable COLRv1

[Mike Taylor]

LGTM2

On Thursday, September 8, 2022 at 9:42:54 AM UTC-4 dr...@google.com wrote:

> Hi Yoav,
>
> On Thursday, September 8, 2022 at 4:35:58 PM UTC+3 yoav...@chromium.org 
> wrote:
>
>> OK, so sounds like there's urgency here, or at least we need to 
>> coordinate shipping.
>>
>> LGTM1 to ship in the same release as `tech()`.
>>
>
> Thanks! 
>  
>
>> Does that mean that if we'd want to ship a future enhancement to colrv1, 
>> we'd need to give it its own tech() signifier? e.g. "colrv1-foobar"?
>>
>
> Yes, either that or call an update to the format COLRv2 for example. We 
> have some requests for functionality as additoins to COLRv1, such as mesh 
> gradients,  blur filters (for shadows) and such, but none of that is 
> spec'ed as of today.
>
> Dominik
>
>  
>
>>
>>>
>>> On Monday, September 5, 2022 at 4:36:01 PM UTC+2 Dominik Röttsches wrote:

>>> Contact emailsdr...@chromium.org
>

>
> Explainer
> https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md#changes-to-off-5711---color-table
>
> Specification
> https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr
>
> Summary
>
> COLRv1 color vector fonts have been previously released in Chrome 98 
> https://developer.chrome.com/blog/colrv1-fonts/ but this release 
> supported only static functionality of the COLRv1 table. (Previous I2S 
> 
> ).
>
>
> The COLRv1 specification defined integration with OpenType Variations 
> 
>  
> from the beginning. This allows modifying the color elements of a font, 
> parameters of gradients and transforms by means of changing font variable 
> axis parameters. This I2S here is for bringing implementation support and 
> adding variations to COLRv1 in Blink (see demo video 
> , or demo links below)
>
> Blink componentBlink>Fonts 
> 
>
> Search tagscolrv1 , 
> variations , variable 
> fonts , color 
> , emoji 
> , gradients 
> 
>
> TAG reviewThe COLRv1 specification is developed outside of W3C, 
> slated for inclusion in OpenType and ISO/MPEG Open Font Format. Before 
> the previous 
> I2S 
> ,
>  
> I started a thread on blink-api-owners-discuss asking whether TAG review 
> for such a font format would be needed. This discussion concluded that a 
> TAG review is not required (thread 
> 
> ).
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> I see an interoperability risk mainly by not shipping variable COLRv1 
> support. Here's why:
>
>
> Firefox is already in the process of shipping COLRv1 support 
> (#1740530) , 
> and their initial release will immediately include COLRv1 variations 
> support. 
>
>
> In the past few weeks, I've worked closely with Jonathan Kew from the 
> Mozilla side to ensure interoperability of the resulting variable COLRv1 
> glyph renderings. To that end, I developed an extensive variable COLRv1 
> test font, for which we have compared results. 
> https://github.com/googlefonts/color-fonts/blob/main/fonts/test_glyphs-glyf_colr_1_variable.ttf
>  
> Additional interoperability efforts are underways: I would like to get to 
> a 
> point where we can have at least pixel comparisons of text stack 
> rendering 
> results for COLRv1. This is below the level of testing that WPT covers 
> and 
> likely needs separate infrastructure. For now, rendering results based on 
> the test font have been manually compared. 
>
> *Gecko*: In development (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1740530) The standards 
> position was already "worth implementing" and no a fast-paced effort to 
> deliver COLRv1 including variations support to users is driven by 
> Jonathan 
> Kew. The high quality implementation can already be tested in FF Nightly.
>
> *WebKit*: Neutral (

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Mike Taylor]

That's great to hear, thanks for the update.

On Friday, September 9, 2022 at 9:51:19 AM UTC-4 Rune Lillesveen wrote:

> We resolved to be bug compatible with Safari as the jquery breakage was 
> too risky to keep. This change has landed on the branches for 105, 106, and 
> on main (107)
>
> The discussion around forgiving selectors will continue in 
> https://github.com/w3c/csswg-drafts/issues/7676
>
> On Fri, Sep 2, 2022 at 4:41 PM Byungwoo Lee  wrote:
>
>> Thank you for checking the issue and sorry for not being able to prevent 
>> it in advance.
>>
>> I missed the risk of conflicting with JQuery's :has() implementation. I 
>> apologize for not checking enough.
>>
>> I made a CL to avoid current JQuery conflict by following the WebKit 
>> behavior:
>>  - https://chromium-review.googlesource.com/c/chromium/src/+/3868781
>>
>> After the CL merged, these web-platform-tests results will be same with 
>> WebKit:
>> - https://wpt.fyi/results/css/selectors/has-error-recovery.html
>> - 
>> https://wpt.fyi/results/css/selectors/parsing/parse-has-disallow-nesting-has-inside-has.html
>> - https://wpt.fyi/results/css/selectors/parsing/parse-has.html
>>
>> If it looks OK, I'll try to merge it asap.
>>
>> 2022년 9월 2일 금요일 오후 9시 52분 35초 UTC+9에 Rune Lillesveen님이 작성:
>>
>>> On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss  wrote:
>>>


 On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen  
 wrote:

> On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss  
> wrote:
>
>> Thanks for the update! Given that this is something that web 
>> developers have been using (as a polyfill, but still) for a lng 
>> while, 
>> I'm somewhat skeptical that we can get away with the spec as currently 
>> written.
>> As we can't have use-counters for things passed as jquery selectors, 
>> I wonder if an HTTPArchive and a GitHub search can reveal how widespread 
>> this is.
>>
>> But I suspect this is a "revert first and ask questions later" kind 
>> of situation. Unfortunately, it seems like this would require a code 
>> update, as the flag is not propagated to a Chromium feature flag 
>> 
>>  AFAICT.
>>
>
> That is correct.
>
> It could be that the best way short term is to change the 
> implementation to not allow forgiving selectors lists. Authors should be 
> able to get the same forgiving effect for :has() sprinkling :is() at 
> appropriate places.
>

 Given that a code change is required anyways, that sounds reasonable..

>>>
>>> New update about the WebKit implementation:
>>>
>>> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235450787
>>>
>>> They _do_ support a forgiving selector list, with a small twist that if 
>>> all selectors are invalid and end up with an empty :has(), the selector is 
>>> dropped.
>>>
>>>  

>
> Slightly longer term, the spec issue for possibly changing it is here: 
> https://github.com/w3c/csswg-drafts/issues/7676
>
> On Fri, Sep 2, 2022 at 1:11 PM Rune Lillesveen  
>> wrote:
>>
>>> On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen  
>>> wrote:
>>>
 On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen <
 fut...@chromium.org> wrote:

> Hi all,
>
> We have an incoming issue for jQuery that seems pretty serious for 
> them:
>

 An update on the impact for jQuery:

 https://github.com/jquery/jquery/issues/5098#issuecomment-1235351545

>>>
>>> There was an issue filed for the CSSWG 
>>> https://github.com/w3c/csswg-drafts/issues/7676
>>>
>>> https://crbug.com/1358953
>
> The problem is that jQuery uses the native implementation of 
> :has() when present, but the feature detection detects support for 
> other custom jQuery selectors inside :has() because of :has() 
> accepting 
> forgiving selectors.
>
> It should be possible to fix this for jQuery, but the problem is 
> for existing content which relies on this feature detection.
>
> The reason why this was not detected when Safari shipped :has(), 
> is that Safari does not accept  
> like the 
> spec says. I have filed 
> https://bugs.webkit.org/show_bug.cgi?id=244708 against WebKit.
>
> On Thu, Jun 2, 2022 at 5:57 PM Chris Harrelson <
> chri...@chromium.org> wrote:
>
>> LGTM3, once the implementation aligns with the WG decisions, 
>> there are tests, and the corresponding spec PRs have landed.
>>
>> Congratulations to all who worked on this feature! I think it's a 
>> great addition to the platform that developers will really like.
>>
>> On Thu, Jun 2, 2022 at 1:25 AM Daniel Bratel

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Rune Lillesveen]

We resolved to be bug compatible with Safari as the jquery breakage was too
risky to keep. This change has landed on the branches for 105, 106, and on
main (107)

The discussion around forgiving selectors will continue in
https://github.com/w3c/csswg-drafts/issues/7676

On Fri, Sep 2, 2022 at 4:41 PM Byungwoo Lee  wrote:

> Thank you for checking the issue and sorry for not being able to prevent
> it in advance.
>
> I missed the risk of conflicting with JQuery's :has() implementation. I
> apologize for not checking enough.
>
> I made a CL to avoid current JQuery conflict by following the WebKit
> behavior:
>  - https://chromium-review.googlesource.com/c/chromium/src/+/3868781
>
> After the CL merged, these web-platform-tests results will be same with
> WebKit:
> - https://wpt.fyi/results/css/selectors/has-error-recovery.html
> -
> https://wpt.fyi/results/css/selectors/parsing/parse-has-disallow-nesting-has-inside-has.html
> - https://wpt.fyi/results/css/selectors/parsing/parse-has.html
>
> If it looks OK, I'll try to merge it asap.
>
> 2022년 9월 2일 금요일 오후 9시 52분 35초 UTC+9에 Rune Lillesveen님이 작성:
>
>> On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen 
>>> wrote:
>>>
 On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss  wrote:

> Thanks for the update! Given that this is something that web
> developers have been using (as a polyfill, but still) for a lng while,
> I'm somewhat skeptical that we can get away with the spec as currently
> written.
> As we can't have use-counters for things passed as jquery selectors, I
> wonder if an HTTPArchive and a GitHub search can reveal how widespread 
> this
> is.
>
> But I suspect this is a "revert first and ask questions later" kind of
> situation. Unfortunately, it seems like this would require a code update,
> as the flag is not propagated to a Chromium feature flag
> 
>  AFAICT.
>

 That is correct.

 It could be that the best way short term is to change the
 implementation to not allow forgiving selectors lists. Authors should be
 able to get the same forgiving effect for :has() sprinkling :is() at
 appropriate places.

>>>
>>> Given that a code change is required anyways, that sounds reasonable..
>>>
>>
>> New update about the WebKit implementation:
>>
>> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235450787
>>
>> They _do_ support a forgiving selector list, with a small twist that if
>> all selectors are invalid and end up with an empty :has(), the selector is
>> dropped.
>>
>>
>>>

 Slightly longer term, the spec issue for possibly changing it is here:
 https://github.com/w3c/csswg-drafts/issues/7676

 On Fri, Sep 2, 2022 at 1:11 PM Rune Lillesveen 
> wrote:
>
>> On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen 
>> wrote:
>>
>>> On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen 
>>> wrote:
>>>
 Hi all,

 We have an incoming issue for jQuery that seems pretty serious for
 them:

>>>
>>> An update on the impact for jQuery:
>>>
>>> https://github.com/jquery/jquery/issues/5098#issuecomment-1235351545
>>>
>>
>> There was an issue filed for the CSSWG
>> https://github.com/w3c/csswg-drafts/issues/7676
>>
>> https://crbug.com/1358953

 The problem is that jQuery uses the native implementation of :has()
 when present, but the feature detection detects support for other 
 custom
 jQuery selectors inside :has() because of :has() accepting forgiving
 selectors.

 It should be possible to fix this for jQuery, but the problem is
 for existing content which relies on this feature detection.

 The reason why this was not detected when Safari shipped :has(), is
 that Safari does not accept  like the
 spec says. I have filed
 https://bugs.webkit.org/show_bug.cgi?id=244708 against WebKit.

 On Thu, Jun 2, 2022 at 5:57 PM Chris Harrelson <
 chri...@chromium.org> wrote:

> LGTM3, once the implementation aligns with the WG decisions, there
> are tests, and the corresponding spec PRs have landed.
>
> Congratulations to all who worked on this feature! I think it's a
> great addition to the platform that developers will really like.
>
> On Thu, Jun 2, 2022 at 1:25 AM Daniel Bratell 
> wrote:
>
>> LGTM2
>>
>> /Daniel
>>
>>
>> On 2022-06-02 10:05, Yoav Weiss wrote:
>>
>> Thanks for the update!
>>
>> LGTM1 to ship, once we're aligned with the spec and WG decisions.
>>
>> On Thu, Jun 2, 2022 at 9:25