Re: [blink-dev] Intent to Ship: Modulepreload Referrer Header Fix

Back to the original intent, the only outstanding question I see is the status of the WPTs. I see the CL has added 4 WPTs

Re: [blink-dev] Intent to Prototype: Prerendering cross-origin iframes

Makes sense to me as an opt-in, thanks for working on this Yoichi! Rick On Tue, Sep 2, 2025 at 12:21 AM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails yoic...@chromium.org > > Explainer > https://github.com/WICG/nav-speculation/blob/main/prerendering-cross-origin-iframes

Re: [blink-dev] Intent to Ship: Probabilistic Reveal Tokens

terest in > testing PRTs! > > Thanks all, > > > Eric > > > On Mon, Aug 18, 2025 at 4:09 PM Rick Byers wrote: > >> Thank you Scott (and David), understanding the developer adoption >> interest is really helpful in weighing the tradeoffs around enabling this

Re: [blink-dev] Intent to Ship: Probabilistic Reveal Tokens

to determine > the impact obfuscated IPs within Incognito sessions may have on ad fraud. > > Cheers, > Scott Pierce, Head of Fraud > Integral Ad Science > > On Monday, August 18, 2025 at 11:02:24 AM UTC-7 Rick Byers wrote: > >> On Fri, Aug 8, 2025 at 2:39 PM '

Re: [blink-dev] Intent to Ship: Probabilistic Reveal Tokens

On Fri, Aug 8, 2025 at 2:39 PM 'David Turner' via blink-dev < blink-dev@chromium.org> wrote: > As a member of Google's Ad Traffic Quality team, we're excited to see the > development of PRTs and to better understand ad fraud in IP protected > traffic. > > On Wed, Aug 6, 2025 at 8:31 AM Yoav Weiss

Re: [blink-dev] Web-Facing Change PSA: Faster background freezing on Android

Thanks Michael. I'm personally always surprised at how long a web page gets to run in the background on Android, so this SGTM. There's some web compat risk here so we'll have to keep an eye on feedback, but I agree this is really an OS-level heuristic and not something subject to our web-facing bre

[blink-dev] Re: Intent to Ship: Digital Credentials API I (presentation support)

[API owner hat off since I work on this API] On Mon, Aug 11, 2025 at 2:26 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails rby...@chromium.org, g...@chromium.org, ma...@chromium.org, > ashimaar...@google.com > > Explainer > https://github.com/w3c-fedid/digital-credential

Re: [blink-dev] [Intent to Prototype] Layout Instability Attribution in CSS Pixels

s was more of an oversight than a specific decision, and >>> feedback from developers seems to align with Ane Diaz: most are having to >>> work around this. >>> >>> However, there are clients out there who now depend on this and we are >>> reaching out

Re: [blink-dev] Intent to Prototype: Selective Permissions Intervention

Thanks for sharing Josh! While the only real security boundary on the page can be the frame boundary, I'm personally a fan of this work to provide some defense-in-depth and help reinforce that powerful permissions are for use or delegation by the 1P shown in the address bar, not 3P scripts which ar

Re: [blink-dev] [Intent to Prototype] Layout Instability Attribution in CSS Pixels

Sounds like a valuable improvement, thank you! I see you're talking with @mmocny on the CL , that's great. I wonder if this was just an oversight in our initial design? Seems like a bug to me. Think we can just switch it (and put t

Re: [blink-dev] Intent to Prototype: Document Local Dictionary API

and we do both. > > I'll try to get some idea on the size of typical dictionaries in this > space. It is important to know, > > Cheers, > Stephen. > > On Tue, Jul 22, 2025 at 12:03 PM Rick Byers wrote: > >> Spelling server seems a lot harder to get right to

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

LGTM On Tue, Jul 22, 2025 at 11:33 AM Nan Lin wrote: > Contact emails > > lin...@chromium.org, jkar...@chromium.org > > Explainer > > > https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md > > https://developer.chrome.com/en/docs/privacy-sandbox/chro

Re: [blink-dev] Intent to Prototype: Document Local Dictionary API

t; that approach we would be interested. > > Cheers, > Stephen. > > On Tue, Jul 22, 2025 at 10:54 AM Rick Byers wrote: > >> FWIW I was also a little confused reading the explainer, but I think I >> understand the overall design and I think it's a good one: these

Re: [blink-dev] Intent to Prototype: Document Local Dictionary API

FWIW I was also a little confused reading the explainer, but I think I understand the overall design and I think it's a good one: these dictionaries are transient and document-local, simply a mechanism to let pages selectively suppress spell check violations on their own page. Presumably discussio

Re: [blink-dev] Intent to Extend Experiment: Digital Credential API

[API owner hat off since I'm personally working on this API] Yeah Alex we had the same debate on the team. We feel ready to ship but we understand there's a lot of concern around this API and that the spec is far from finished in terms of convincingly mitigating the privacy risks of this powerful

Re: [blink-dev] Re: Intent to Ship: Secure Payment Confirmation: UX Refresh

LGTM3 On Wed, Jul 16, 2025 at 11:13 AM Vladimir Levin wrote: > Thanks Stephen, that makes sense. > > LGTM2 > > On Tuesday, July 15, 2025 at 3:20:00 PM UTC-4 Slobodan Pejic wrote: > >> Thanks Domenic, I have filed an issue to address this problem with the >> secure-payment-confirmation specifica

Re: [blink-dev] Intent to Ship: Deprecate special font size rules for H1 within some elements

Perfect, thanks Mason. LGTM1 then. On Thu, Jul 10, 2025 at 8:42 PM Mason Freed wrote: > > On Thu, Jul 10, 2025 at 3:08 PM Rick Byers wrote: > >> Interoperability and Compatibility >>> >>> Use counters are relatively high: >>> https://chromestatus.co

Re: [blink-dev] Intent to Ship: Deprecate special font size rules for H1 within some elements

On Thu, Jul 10, 2025 at 5:50 PM Mason Freed wrote: > {Note: to make sure it's clear, this is the request to actually remove > ("ship") the special rules, in M140.} > Contact emailsmas...@chromium.org > > ExplainerNone > > Specificationhttps://github.com/whatwg/html/pull/11102 > > Design docs > ht

Re: [EXTERNAL] Re: [blink-dev] Intent to Experiment: Local Network Access

you will have the reverse OT infrastructure set up before > proceeding to a stable channel experiment, correct? > > > > *From:* Rick Byers > *Sent:* Tuesday, June 24, 2025 1:40 PM > *To:* Hubert Chao > *Cc:* blink-dev ; Chris Thompson < > cth...@chromium.org>;

Re: [blink-dev] Intent to Experiment: Local Network Access

LGTM to experiment via Finch in pre-stable channels. I love the strategy of automatically popping a permission prompt. I'm optimistic we can get this tuned to minimize breakage while maximizing developer predictability and user understandability, but I can totally imagine that it'll take some tuni

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Randomizing TCP Port Allocation on Windows

LGTM3. Compat risk seems minimal (and yes likely below the bar needed for API owner approval, but more transparency doesn't hurt). On Fri, Jun 20, 2025 at 12:25 AM 'Erik Anderson' via blink-dev < blink-dev@chromium.org> wrote: > There was no new API here and thus no API detection mechanism. It’s

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation: Browser Bound Keys

a nice-to-have to me, happy to leave up to your judgement. > > On Wed, Jun 18, 2025 at 1:27 PM Reilly Grant wrote: > >> Note the approach I took in WebUSB hasn't proven popular. I wouldn't >> replicate it. WebAuthn defines WebDriver commands and that's the app

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation: Browser Bound Keys

This is exciting Slobo, thank you! I think this is really important to ship in order to bring back the promise of device-binding to SPC (which was broken when WebAuthn keys became synced a few years ago). It's unfortunate that no other engines are currently interested in SPC but I remain confident

Re: [blink-dev] Intent to Ship: CSS Corner shaping (corner-shape, superellipse, squircle)

LGTM1, sounds nice and uncontroversial. Thanks for the spec issues list and analysis! On Wed, Jun 11, 2025 at 1:01 PM Noam Rosenthal wrote: > Contact emailsnrosent...@chromium.org > > Explainer > https://github.com/noamr/explainers/blob/main/corner-shape-explainer.md > > Specificationhttps://dra

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

t; wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks Evan and Jeff. >>>>>>>>>>>> >>>>>>>>>>>> Evan: if we can get to API symmetry, I think that will help >>>

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

;>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>> On Wednesday, May 7, 2025 at 12:12:29 AM UTC-7 Jeffrey Yas

Re: [blink-dev] Intent to Experiment: IP Protection in Incognito using published Masked Domain list

LGTM to experiment. I had lots of questions on the details but they were all very well covered by the explainer. Thank you, I'm excited to see this progress towards shipping! Thank you also for being so careful in minimizing the risk of unintended consequences while also being committed to prevent

Re: [blink-dev] Re: Intent to Implement and Ship: isSecurePaymentConfirmationAvailable API

LGTM3 Sorry this fell off our radar (was due to re-using the existing chromestatus entry so looked fully approved in tooling already). On Wed, Apr 30, 2025 at 7:09 AM Mike Taylor wrote: > LGTM2 > On 4/28/25 5:43 PM, Chris Harrelson wrote: > > LGTM1. Please make sure to ping the standards positi

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

On Tue, Apr 15, 2025 at 8:14 PM Evan Liu wrote: > Thanks for the detailed feedback, Jeffrey! We'll discuss this at the Audio > Working Group meeting this week and I'll update this thread afterwards. > > Thanks, > Evan > > On Mon, Apr 14, 2025 at 9:08 PM Jeffrey Yasskin > wrote: > >> FYI, the TAG

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

dows aside from the CLI flag, and the >>> fallback is not triggerable by an attacker on systems with a "normal" GPU, >>> we'll be in much better shape from a security standpoint. >>> >>> We will update this thread with the progress and results of

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

outside your control, including lack of review). >>> >>> One more question, it looks like the latest spec has not been published >>>>> to the gh-pages branch yet. Can you please make sure that your changes are >>>>> visible here <https://webaudio.gi

Re: [blink-dev] Intent to Ship: FedCM multi IDP in single get(), and remove add another account, in passive mode

LGTM1 FWIW I've always considered it a bug that FedCM only supported a single IDP at a time. I know there are complex UX design issues to address and a couple small tweaks in the API. The promise of FedCM always was that it could be a single UI surface that intersected the list of IDPs a site supp

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

Great, thank you Matt! Rick On Mon, Mar 24, 2025 at 2:25 PM Matt George wrote: > Hi Rick, AFAIK it's only Windows, but currently reaching out to see if > it's different for our distributors in Europe. > > Matt > On Monday, March 24, 2025 at 10:38:19 AM UTC-7 Rick Bye

Re: [blink-dev] Intent to Ship: ::scroll-marker and ::scroll-marker-group for Carousel, ::column pseudo element for Carousel and ::scroll-button() pseudo elements

s resolve them. > > Thank you! > > Regards, > Xiaocheng > > On Thursday, February 27, 2025 at 5:10:34 AM UTC+8 dan...@microsoft.com > wrote: > >> LGTM3 >> >> On Wednesday, February 26, 2025 at 8:12:24 AM UTC-8 mike...@chromium.org >> wrote: &

Re: [blink-dev] Intent to Ship: CSS interactivity

added, but is there also a >>>>> solution to click-grab dragging? This is notably missing from native >>>>> carousel support on the web and I would have expected it to be proposed >>>>> along with this; e.g. an extension that mirrors `touch-action: pan-x`

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

tied to the removal of the policy (since they’d > now be aware of what broke and why). > > > > Thanks, > > Erik > > > > *From:* Ken Russell > *Sent:* Monday, March 3, 2025 10:39 AM > *To:* Ashley Gullen > *Cc:* Geoff Lang ; Erik Anderson < > erik.ande

Re: [blink-dev] Re: Intent to Ship: Explicit Compile Hints with Magic Comments

osals/issues/174> for this! I think there's >> now enough evidence of industry interest in this. That should enable y'all >> to move this to the WICG as a venue, which would resolve the IPR concerns. >> >> On Friday, October 4, 2024 at 4:34:16 PM UTC+2 Rick Bye

Re: [blink-dev] Intent to Remove: SwiftShader Fallback

Sorry for the delay from API owners, as discussed on chat the chromestatus entry wasn't set up properly to request API owner review (now fixed). This is a tricky one indeed (thanks for your input Ashley!). It looks like WebGL is u

Re: [blink-dev] Intent to Ship: ::scroll-marker and ::scroll-marker-group for Carousel, ::column pseudo element for Carousel and ::scroll-button() pseudo elements

On Tue, Feb 25, 2025 at 1:00 PM Robert Flack wrote: > > On Fri, Feb 21, 2025 at 5:19 PM Rick Byers wrote: > >> I'm excited to see this ship! >> > > Thanks, me too! > > On Fri, Feb 14, 2025 at 1:57 PM 'Ajay Rahatekar' via blink-dev < >

Re: [blink-dev] Intent to Ship: ::scroll-marker and ::scroll-marker-group for Carousel, ::column pseudo element for Carousel and ::scroll-button() pseudo elements

I'm excited to see this ship! On Fri, Feb 14, 2025 at 1:57 PM 'Ajay Rahatekar' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > fla...@chromium.org, sakha...@chromium.org > > Summary > > This is a combined Intent to ship for the following features: > > ::scroll-marker and ::scr

Re: [blink-dev] Intent to Extend Deprecation Trial: Deprecate unload event

LGTM to extend through Chrome 146 Responsibly deprecating unload is going to be a long process, we should expect this deprecation trial to be useful for an extended period... On Thu, Feb 13, 2025 at 5:54 AM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails fer...@chromium.o

Re: [blink-dev] Intent to Ship: Dispatching click events to captured pointer

moment. However, this makes > your setPointerCapture question difficult to answer! In fact we > were surprised to see setPointerCapture being used in at least 0.1% page > loads ("at least" because our UseCounter has other conditions to meet)!! > > > On Wed, Feb 12, 202

Re: [blink-dev] Intent to remove: navigator.xr.supportsSession

A barely used WebXR-specific method that's been deprecated for 5+ years seems very low risk to me. LGTM1 to remove. Rick On Wed, Feb 12, 2025 at 1:52 PM Brandon Jones wrote: > Primary eng (and PM) emails > > bajo...@chromium.org > > Summary > > navigator.xr.supportsSession was replaced in the W

Re: [blink-dev] Intent to Ship: Remove clamping of setInterval(...) to >= 1ms

LGTM3 On Wed, Feb 12, 2025 at 11:04 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > LGTM2 > > On Wednesday, February 12, 2025 at 2:59:43 AM UTC+1 Domenic Denicola wrote: > >> LGTM1. I'm still curious on the web developer signals, if you have >> anything to share there :) >> >> >> *Web

Re: [blink-dev] Intent to Ship: Dispatching click events to captured pointer

LGTM3 I was surprised the UseCounter was so high, is that because this includes the implicit capture case for touch input? Or is setPointerCapture really that common? If it includes the touch implicit capture case, does that mean the click generated from a GestureTap can also have it's target chan

Re: [blink-dev] Intent to Ship: CSS interactivity

LGTM1 On Fri, Feb 7, 2025 at 5:28 PM 'Ajay Rahatekar' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > fla...@chromium.org, futh...@chromium.org > > Explainer > > https://github.com/flackr/carousel/tree/main/inert > > Specification > > https://drafts.csswg.org/css-ui-4/#inertne

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

github.com/WebAudio/web-speech-api/pull/129 > Thanks! > > Thanks for the feedback and please let me know if anyone has any > additional comments or concerns! > > On Wed, Jan 15, 2025 at 10:55 AM Stmh wrote: > >> It would be nice to speak with someone privately, as I may be

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

fore approving - The group agrees that discussions of modernizing the API are non-blocking for this intent Thanks, Rick On Wed, Jan 15, 2025 at 10:58 AM Rick Byers wrote: > Thank you Evan. Given the samples and github hits you've shared, I agree > that web compat will constr

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

Thank you Evan. Given the samples and github hits you've shared, I agree that web compat will constrain us from making breaking changes to the APi when we unprefix. That's a shame, but is a known reason why we long ago gave up on prefixes as a safe way to do experimental API development. So are you

Re: [blink-dev] Intent to Extend Experiment: Digital Credential API

Whoops, I'm very embarrassed to admit that I told Mohamed that he could request a renewal for 6 milestones. Sorry, my bad! I expect we'll likely need one more renewal before shipping, but we've got a bunch of progress we anticipate on the specification so hopefully it won't be controversial when w

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

LGTM3 Discussed a bit in API owners meeting today. There are some risks here, but IMHO it's all stuff we should be able to measure, detect and respond to (eg. if sites actually get slower due to incorrect use of this API). So those concerns don't seem worth blocking on to me. On Wed, Dec 25, 2024

Re: [blink-dev] Intent to Ship: Storage Access Headers

LGTM3 On Wed, Jan 8, 2025 at 9:29 AM Mike Taylor wrote: > Thanks for the updates Chris. LGTM2. > On 1/7/25 10:35 PM, Yoav Weiss (@Shopify) wrote: > > > > On Tue, Jan 7, 2025 at 10:31 PM Chris Fredrickson > wrote: > >> Minor updates: >> >> Mike Taylor previously noted >>

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: On-device Web Speech API

This is great to see! IMHO there are a bunch of great use-cases for on-device speech recognition which are likely not suitable for server-based approaches. This is still only exposed

[blink-dev] Re: Web-Facing Change PSA: Expose CSSFontFeaturesValueRule

On Tue, Jan 7, 2025 at 12:11 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails rby...@chromium.org, tannal2...@gmail.com > > Specification https://drafts.csswg.org/css-fonts/#cssfontfeaturevaluesrule > > Design docs > https://developer.mozilla.org/en-US/docs/Web/API/CSSFon

Re: [blink-dev] Intent to Prototype & Ship: scroll-start-target

LGTM3. On Wed, Dec 18, 2024 at 4:08 PM Mike Taylor wrote: > LGTM2 > On 12/18/24 3:11 PM, Chris Harrelson wrote: > > LGTM1 > > On Mon, Dec 16, 2024 at 2:10 PM David Awogbemila > wrote: > >> The CSS working group resolved >>

Re: [blink-dev] Intent to Ship: CSS advanced attr() function

nd/or a cluster >>> telemetry run perhaps) to try to put an upper bound on the breaking change >>> risk? I think we all expect that the risk is low, but is it extremely low >>> and so something we should just launch with a finch killswitch ready to use >>> a

Re: [blink-dev] Intent to Deprecate and Remove: Protected Audience Subresource bundle directFromSellerSignals

I double-checked internal metrics and usage is indeed effectively zero, so compat risk should be effectively non-existent. LGTM2 to remove directly with just the usual kill switch in case of emergency somehow. On Wed, Dec 11, 2024 at 11:13 AM Alex Russell wrote: > LGTM1 w/ finch control for rol

Re: [blink-dev] Intent to Ship: X25519 algorithm of the Web Cryptography API

Perfect, thanks for the update Javier! On Thu, Dec 5, 2024 at 11:32 AM Javier Fernandez wrote: > Hi, > > Thank you all for reviewing the request. > > I just wanted to inform that the PR to add the X25519 and Ed25519 into the > WebCrytpo specification has been merged already. > > https://github.c

Re: [blink-dev] Intent to Ship: CSS advanced attr() function

Discussed in API owners meeting today that we don't really understand the compat risk here. Vlad makes a compelling argument that the risk in example #2 may be non-trivial (especially when considering inheritance scenarios beyond just custom properties). Also you'll need to request enterprise revie

Re: [blink-dev] Intent to Ship: Expose attributionsrc attribute on

Thanks for cleaning this little wart up. LGTM2 On Wed, Dec 4, 2024 at 10:24 AM Stephen Chenney wrote: > I don't get to give LGTMs but after investigation and offline discussion > there seems to be essentially zero breakage risk, so I see no problems at > all with shipping this. > > On Wed, Dec 4

Re: [blink-dev] Intent to Ship: X25519 algorithm of the Web Cryptography API

LGTM2 On Sun, Dec 1, 2024 at 9:11 PM Domenic Denicola wrote: > Thanks for taking the time to answer all my questions. LGTM1. > > Please continue working on getting the spec PR merged, although I > understand that's waiting on reviewers so is largely out of your control. > > On Tue, Nov 26, 2024

Re: [blink-dev] Intent to Ship: Freezing on Energy Saver

LGTM1 to ship including a deprecation trial On Fri, Nov 29, 2024, 5:00 p.m. François Doray wrote: > > > On Friday, November 29, 2024 at 3:13:39 PM UTC-5 Rick Byers wrote: > > tl;dr: Just one remaining question about providing a developer opt-out > (like a deprecation trial).

Re: [blink-dev] Intent to Ship: Freezing on Energy Saver

for in customer reports and perhaps inform our future guidance, so please let me know (here or privately) if it ends up showing up as an issue in customer reports or not. > Will the blog post you mentioned be published prior to 133 beta (Jan 15)? > That's the goal, though DevRel hasn&#x

Re: [blink-dev] Re: Intent to Ship: CSS Scroll State Container Queries

On Fri, Nov 29, 2024 at 5:02 AM Rune Lillesveen wrote: > > On Wed, Nov 27, 2024 at 4:49 PM Rick Byers wrote: > >> LGTM3 >> >> Is anyone looking into why the tests >> <https://wpt.fyi/results/css/css-conditional/container-queries/scroll-state> >> hav

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: Clipboardchange event

dback from those platforms. > > -Rohan > -- > *From:* Rick Byers > *Sent:* Wednesday, November 27, 2024 9:25 PM > *To:* Chromestatus > *Cc:* blink-dev@chromium.org ; > lukekli...@google.com ; Rakesh Goulikar < > rakesh.gouli...@microsoft.com>; Rohan Raja ; Sanket >

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

On Thu, Nov 28, 2024 at 7:59 AM Noam Rosenthal wrote: > > On Wed, Nov 27, 2024 at 4:16 PM Alex Russell > wrote: > > > > Thanks for all of this. > > > > Would be good if we had a doc that explored the potential extension > paths for the existing APIs (arguments object as additional param?) vs. th

Re: [blink-dev] Intent to Ship: Explicit resource management (sync)

FWIW, it looks like this is also covered by the same explainer as the as the async version (I2S

Re: [blink-dev] Intent to Ship: Explicit resource management (async)

LGTM3 Love seeing more of the best parts of C# make it into ECMAScript :-) Rick On Wed, Nov 27, 2024 at 10:56 AM Chris Harrelson wrote: > LGTM2 > > On Thu, Nov 21, 2024 at 4:12 PM Mike Taylor > wrote: > >> LGTM1 >> On 11/21/24 6:44 PM, Rezvan Mahdavi Hezaveh wrote: >> >> Contact emails rez...

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

LGTM2 once the PR lands On Wed, Nov 27, 2024 at 11:16 AM Alex Russell wrote: > Thanks for all of this. > > Would be good if we had a doc that explored the potential extension paths > for the existing APIs (arguments object as additional param?) vs. the > "larger bundle" path. I'm happy for this

Re: [blink-dev] Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

LGTM3 On Wed, Nov 27, 2024 at 11:13 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > LGTM2 > > On Friday, November 22, 2024 at 12:47:46 PM UTC+1 Noam Rosenthal wrote: > >> On Fri, Nov 22, 2024 at 6:21 AM Domenic Denicola >> wrote: >> >>> >>> >>> On Thu, Nov 21, 2024 at 6:07 PM Noam Ro

Re: [blink-dev] Intent to Prototype: Clipboardchange event

Looks great, a clear improvement over polling. Thanks! Hopefully you can find APIs on non-Windows platforms to enable this. The explainer mentions polling the clipboard on MacOS but I'm not sure we'd want to do that in Chromium, would we? Perhaps it would be better to not expose the API on platfor

Re: [blink-dev] Re: Intent to Ship: CSS Scroll State Container Queries

LGTM3 Is anyone looking into why the tests have harness errors on non-chromium browsers? Is that a bug in the test failing to fail properly? Rick On Wed, Nov 27, 2024 at 10:48 AM Chris Harrelson wrote: > LGTM2 > > On

Re: [blink-dev] Re: Intent to Ship: Animation.overallProgress

LGTM1 to ship in M133. It's nice to see the explainer and design improved based on TAG feedback, thank you for that! Rick On Tue, Nov 26, 2024 at 10:41 AM David Awogbemila wrote: > > > On Tue, Nov 26, 2024 at 10:35 AM David Awogbemila > wrote: > >> Contact emailsawogbem...@google.com >> >> Ex

Re: [blink-dev] Intent to Extend Deprecation Trial (Again): Partitioning Storage, Service Workers, and Communication APIs

LGTM to extend this DT for another 6 milestones. On Tue, Nov 26, 2024 at 12:00 PM Ari Chivukula wrote: > Contact emails > > aric...@chromium.org, miketa...@chromium.org > > Explainer > > > https://github.com/wanderview/quota-

Re: [blink-dev] Intent to Ship: FedCM authorization features (fka Bundle 6: Continuation API, Parameters API, Fields API, Multiple configURLs, Custom account labels)

LGTM2 On Wed, Nov 27, 2024 at 9:40 AM Vladimir Levin wrote: > Thank you for the explanation! > > LGTM1 > > On Mon, Nov 25, 2024, 1:53 p.m. Christian Biesinger < > cbiesin...@chromium.org> wrote: > >> >> >> On Mon, Nov 25, 2024 at 12:47 PM Vladimir Levin >> wrote: >> >>> Hey Christian, >>> >>> T

Re: [blink-dev] Intent to Ship: Freezing on Energy Saver

I evaluated this intent relative to our compat principles and overall think you've done an excellent job mitigating the compat risks. In particular the user controls, developer-influencable heuristics and enterprise opt-out seem likely to be significant mitigations. I'

Re: [blink-dev] Intent to Ship: WebAssembly Memory64

LGTM1, I'm excited to see this ship! I'm also terrified about how many of my tabs will want to use more than 4GB of RAM at once for their AI models, but of course that is not a good reason to hold back the full power of devices from web developers. Thank you for doing all the work to extend WASM m

Re: [blink-dev] Intent to Ship: Atomics.pause

LGTM1 as TC39 stage 3 On Fri, Nov 15, 2024 at 2:49 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails s...@chromium.org > > Explainer None > > Specification https://tc39.es/proposal-atomics-microwait > > Summary > > Adds the Atomics.pause method to hint the CPU that the cu

Re: [blink-dev] Intent To Prototype: Delegation-oriented FedCM

Thanks for the high-level framing Sam putting this in perspective. I'm excited about this as an additional possible tool in the identity toolbox. Of course it's ultimately user preference and other market forces well outside our control that will determine which technologies and tradeoffs get used

Re: [blink-dev] Intent to Prototype: Subresource Reporting for scripts

Sounds cool Yoav, and PCI-DSS v4 compliance does seem like a generally useful thing to be doing to help better secure payments on the web. Thank you for driving this! On Thu, Nov 7, 2024 at 9:36 AM Yoav Weiss (@Shopify) wrote: > Contact emailsyoavwe...@chromium.org > > Explainer > https://github

Re: [blink-dev] Intent to ship: WebGPU: Expose GPUAdapterInfo from GPUDevice

LGTM2 On Thu, Nov 7, 2024 at 10:39 AM Mike Taylor wrote: > LGTM1 > On 11/7/24 12:52 AM, 'François Beaufort' via blink-dev wrote: > > Contact emails > > fbeauf...@google.com > > Explainer > > It is important for libraries that take user-provided GPUDevice objects to > access information about the

Re: [blink-dev] Intent to Ship: MediaDevices devicechange event

;>behavior of Edge and what you'd like to ship. >>>>>>>>>>- Comment on the other relevant issues what you intend to >>>>>>>>>>ship, so that nobody is surprised. >>>>>>>>>> >>>>>

Re: [blink-dev] Re: Intent to Ship: Explicit Compile Hints with Magic Comments

The main reason I'm personally gung-ho on shipping this is that, as far as I can tell, it has extremely low interoperability and compatibility risk. This is just metadata that influences performance heuristics and (despite some risk) all browsers tweak performance heuristics all the time without ne

Re: [blink-dev] Web-Facing Change PSA: Document picture-in-picture: copy document mode

Thanks Tommy, sounds like a bugfix to me. Cheers, Rick On Tue, Oct 1, 2024 at 2:19 PM 'Tommy Steimel' via blink-dev < blink-dev@chromium.org> wrote: > Contact emailsstei...@chromium.org > > Specificationhttps://github.com/WICG/document-picture-in-picture/pull/128 > > Summary > > This makes the

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

On Wed, Sep 11, 2024 at 3:04 PM Mike Taylor wrote: > Hey Chris, > > A few thoughts: > > We do not block shipping features if TAG is slow with their responses. But > that said, I see the TAG review was requested just 20 hours ago - we do > like to give them a reasonable amount of time to respond (

Re: [blink-dev] Intent to Ship: Dynamic safe area insets

On Thu, Sep 12, 2024 at 9:09 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu wrote: > >> Thank you for the feedback Robert! >> >> > updating the safe area while scrolling requires a main thread update >> for the developer drawn controls (e.g.

Re: [blink-dev] PSA: Add Permission modals for Keyboard and Pointer Lock

rome://flags/#keyboard-and-pointer-lock-prompt for testing. You > can find the list of open bugs here > <https://g-issues.chromium.org/issues/314694812/dependencies>. > > Thanks, > Muyao > > On Tue, Sep 10, 2024 at 6:45 PM Rick Byers wrote: > >> Thanks for the he

Re: [blink-dev] PSA: Add Permission modals for Keyboard and Pointer Lock

Thanks for the heads up on this. Is the functionality complete in 130 already? I.e. is Chrome dev channel suitable for developers to test this behavior and confirm it works OK for their product? Or are there flags that should be turned on for testing still? I assume this behavior is controlled via

Re: [blink-dev] Intent to Ship: FedCM (was WebID)

>>>> >>>>> /Daniel >>>>> On 2022-10-11 23:13, 'Ilya Grigorik' via blink-dev wrote: >>>>> >>>>> At Shopify, we've followed progress closely, and I'm really excited to >>>>> see the i2s! >>>&

Re: [blink-dev] Intent to Ship: FedCM (was WebID)

x27; via blink-dev wrote: >>>>> >>>>> At Shopify, we've followed progress closely, and I'm really excited to >>>>> see the i2s! >>>>> >>>>> Agree with the analysis tradeoffs and proposed rollout. This is a >>&

Re: [blink-dev] Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

On Fri, Jul 26, 2024 at 12:17 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Fri, Jul 26, 2024 at 5:04 PM Rick Byers wrote: > >> >> >> On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

I'm a bit worried about primarily chromium-sites or Android WebView apps who might have used this by accident instead of innerHTML. I took a look at WebView-specific UseCounters and found them to be less than half of the Chrome Android values (~0.0007% vs. 0.0002%), so I expect that just represents

Re: [blink-dev] Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed wrote: > >> Contact emailsmus...@chromium.org >> >> Specification >> https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicte

Re: [blink-dev] Intent to Extend Experiment: JavaScript Promise Integration

Hi Francis, We only do OT extensions for 3 milestones at a time

Re: [blink-dev] Intent to Experiment: Digital Credential API

experiment for 6 milestones from M128 to M133 inclusive. >> On 6/22/24 1:44 PM, Rick Byers wrote: >> >> Hello blink-dev, >> I'd like to request permission to start an OT for this API. There's still >> a lot to figure out in the larger space of digit

[blink-dev] Intent to Experiment: Digital Credential API

Hello blink-dev, I'd like to request permission to start an OT for this API. There's still a lot to figure out in the larger space of digital credentials on the web

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

LGTM3 On Friday, May 3, 2024 at 1:34:21 PM UTC-4 Chris Harrelson wrote: > Thanks for these mini-explainers, they clarified what is changing for me! > > LGTM2 > > On Fri, May 3, 2024 at 9:31 AM 'Akash Nadan' via blink-dev < > blin...@chromium.org> wrote: > >> Hi Alex, >> >> Thanks for the feedback

Re: [blink-dev] Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

but since developers testing 3PCD > have been living in this world for a while and Firefox also has the > behavior, it seemed better to go the long route. > > ~ Ari Chivukula (Their/There/They're) > > > On Tue, Apr 30, 2024 at 11:34 AM Rick Byers wrote: > >> S

Re: [blink-dev] Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

Seems maybe like we introduced a bug in regressing from expected behavior and this could arguably be handled as a bug-fix? Regardless LGTM1 On Tue, Apr 30, 2024 at 11:32 AM Mike Taylor wrote: > On 4/30/24 7:15 AM, Ari Chivukula wrote: > > Contact emails > > aric...@chromium.org, johann...@googl

Re: [blink-dev] Intent to Ship: CSS Anchor Positioning

LGTM3 There's definitely some forward compat risk here, but we know adoption for these sorts of features tends to be slow before reaching all engines, so I'm confident in our ability to make small breaking changes as needed as the spec continues to mature. Seeing how much diligence and review has

  1   2   3   4   5   >