Re: [blink-dev] Intent to Prototype: Script Tools API

Thanks for working on this, and it's good to see that Microsoft is also interested. I wanted to note that, as this gets closer to an Intent to Ship, the "Interoperability and Compatibility" section might need to focus on some entities that haven't traditionally been relevant to I2Ses. This API is f

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

On Tue, Jul 15, 2025 at 10:44 AM 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-credentials/blob/main/explainer.md > > Specification ht

Re: [blink-dev] Re: Intent to Ship: ScrollIntoView container option

Thanks! On Fri, Jul 4, 2025, 7:49 AM Robert Flack wrote: > Thanks, I added an example to the spec with rationale of why you might use > this: https://github.com/w3c/csswg-drafts/pull/12450. > > On Wed, Jul 2, 2025 at 11:27 AM Daniel Bratell > wrote: > >> LGTM3 (there are two LGTM1 so next is 3)

Re: [blink-dev] Re: Intent to Ship: CSS scroll-target-group property

On Thu, Jun 26, 2025 at 10:03 AM Jeffrey Yasskin >> wrote: >> >>> +Lola Odelola and +Florian Scholz >>> as the chairs of the Docs CG, who'll have a >>> better sense of the right answer here. >>> >>> My guess is that it'll work bett

Re: [blink-dev] Re: Intent to Ship: CSS scroll-target-group property

> > ср, 25 июн. 2025 г. в 15:26, Alex Russell : > >> LGTM2, contingent on a good resolution of Jeffery's concern. >> >> Best, >> >> Alex >> >> On Wednesday, June 25, 2025 at 8:14:12 AM UTC-7 Jeffrey Yasskin wrote: >> >>> Would it

Re: [blink-dev] Re: Intent to Ship: CSS scroll-target-group property

Would it be possible to put this explanation and example in the specification , instead of in an email thread where it'll get lost? Thanks, Jeffrey On Mon, Jun 23, 2025 at 5:14 AM Daniil Sakhapov wrote: > Sure! > > One example: imagine yo

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

eedback, 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

Re: [blink-dev] Intent to Ship: Language Detector API

The discussion in the API owners meeting raised the question of whether language detection has fewer fingerprinting risks than the other APIs covered by https://webmachinelearning.github.io/writing-assistance-apis/#privacy. Could you say something about that in https://webmachinelearning.github.io/

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

FYI, the TAG left comments at https://github.com/w3ctag/design-reviews/issues/1038#issuecomment-2803693504 . On Fri, Apr 4, 2025 at 10:22 AM Evan Liu wrote: > Are you thinking it might be reasonable to ship in M128 (decide by branch >> on Apr 28, plan to merge any required changes before May 21

Re: [blink-dev] Re: Intent to Ship: Accept-Language Reduction (HTTP-only)

On Wed, Apr 2, 2025 at 8:36 AM Victor Tan wrote: > Jeffrey, Thanks for raising this concern. We understand that some popular > multilingual > sites , > based on our study, do indeed use the full language list in the HTTP > header. You

Re: [blink-dev] Intent to Prototype: Limiting Access to Local Fonts

I see (in your explainer) that the CSSWG is working on this problem in https://github.com/w3c/csswg-drafts/issues/11753. Even though we have the 'explainers-by-googlers' space available for early projects, it's better to do widely-agreed work in established CGs and WGs. Can you move this explainer

Re: [blink-dev] Intent to Ship: Accept-Language Reduction (HTTP-only)

Have you proposed that a standards body adopt this into a working group of some sort? Especially since Safari is doing something similar, it seems like the WHATWG might be willing to adopt this into the Fetch standard. I'm also somewhat concerned about the internationalization concerns expressed i

Re: [blink-dev] Intent to Ship: Link rel=payment to support push payments

On Mon, Mar 17, 2025 at 12:03 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > Thanks for working on this!! > > On Wednesday, February 26, 2025 at 8:00:26 PM UTC+1 junh...@google.com > wrote: > > Thanks! I was syncing with our PM/TPM to provide the best answer of the > enterprise questi

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

On Wed, Feb 12, 2025 at 10:07 AM Noam Rosenthal wrote: > On Tuesday, January 28, 2025 at 10:49:02 AM UTC Noam Rosenthal wrote: > > On Mon, Jan 27, 2025 at 8:51 PM Noam Rosenthal > wrote: > > > >- https://github.com/w3c/csswg-drafts/issues/10647 > > This one is not actionable and doesn't affe

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

On Mon, Jan 27, 2025 at 3:08 AM Noam Rosenthal wrote: > On Mon, Jan 27, 2025 at 2:56 AM Domenic Denicola > wrote: > >> This overall seems promising, but a few inline comments. The only >> blocking one is the question about open spec edits. >> >> On Thursday, January 23, 2025 at 4:42:34 AM UTC+9

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

On Tue, Jan 7, 2025 at 10:34 AM 'Daniel Clark' via blink-dev < blink-dev@chromium.org> wrote: > Adding to Yoav’s feedback about the spec: > >- It’s implied that installOnDeviceSpeechRecognition() happens >synchronously. Making this a blocking call seems problematic since it could >invo

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

ook for guidance on web specs, I'll tag in our > local TAG rep +Jeffrey Yasskin as an FYI. > > On Thu, Dec 5, 2024 at 4:42 PM Rezvan Mahdavi Hezaveh > wrote: > >> Joshua, >> >> There is no guidance for other web specs as far as I know. But the

[blink-dev] Re: Intent to Ship: Multiple import maps

On Wed, Nov 20, 2024 at 9:25 AM Alex Russell wrote: > In future, I'd like to see the TAG push back on things like Import Maps > and Speculation Rules that use `

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

On Thu, Nov 21, 2024 at 1:26 PM Dominic Farolino wrote: > The remaining arguments seem to be about 1) whether it makes sense for the >> movement APIs to have noticeably different side-effects when moving a node >> across documents > > > Just to be super clear, we're not at all considering cross-d

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

st of elements into place. All that said, the WHATWG forum has all the relevant experts, and if y'all think this is the right design after considering the arguments, I think you should go ahead. Jeffrey On Wed, Nov 20, 2024 at 3:29 PM Noam Rosenthal > wrote: > >> >> >> On

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

The TAG feedback was a request to see if we could make this change to the other methods by default, instead of adding a parallel set. If that's web-compatible, we might not have to think about the larger package. On Wed,

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

commit/6e668e2c8904dc8c2b4d8837afe2459d00991c56 > > Works for me in Chrome Stable: https://almond-noble-kick.glitch.me/ > > And the spec PR that was in question did end up merging: > https://github.com/whatwg/html/pull/9754 > > > > -- Dan > > > > *From:* Jeffrey

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

Did this wind up shipping? It still says 121 on Chromestatus, but I don't see it on https://caniuse.com/?search=showPicker, and the TAG is wondering what to do about https://github.com/w3ctag/design-reviews/issues/900. Thanks, Jeffrey On Sat, Nov 4, 2023 at 5:08 AM Luke wrote: > Unfortunately t

Re: [blink-dev] Intent to Prototype: Container Timing

Could you work on moving this to a CG or WG? With 2 authors from different organizations, you already have enough support to be adopted by the WICG (file an issue at https://github.com/WICG/proposals), but you may also have enough support to get adopted directly into the WebPerf WG. Yoav can help w

Re: [blink-dev] Intent to Ship: File System Access on Android and WebView

It seems like the "Interoperability and Compatibility" section for this Intent is misleading: shipping a piece of an API can cause compatibility problems if developers were feature-detecting the API as a whole, and then a function is missing or doesn't work *after* they've already committed to the

Re: [blink-dev] Intent to Ship: Ignore Strict-Transport-Security for localhost

and what change to Fetch would be proposed. The >> section you flagged has two relevant clauses related to HTTPS upgrades: >> >> 5. Upgrade request to a potentially trustworthy URL, if appropriate. >> 6. Upgrade a mixed content request to a potentially trustworthy URL, if >&

Re: [blink-dev] Intent to Ship: Ignore Strict-Transport-Security for localhost

accept this one, that's fine with me. I see they haven't replied to errata on that RFC since 2017, so I'll try to poke someone... Jeffrey On Wed, Oct 23, 2024 at 5:11 PM Jeffrey Yasskin wrote: > Can you propose a matching change to the relevant standard? It probably > make

Re: [blink-dev] Intent to Ship: Ignore Strict-Transport-Security for localhost

Can you propose a matching change to the relevant standard? It probably makes sense to start by suggesting a change to https://fetch.spec.whatwg.org/#concept-main-fetch, but the editors there might ask you to write an update to the RFC. We can figure out the cheapest way to get that done if they do

Re: [blink-dev] Intent to Prototype & Ship: Private State Token API Permissions Policy Default Allowlist Wildcard

sponse > > 3. https://wicg.github.io/trust-token-api/#redemption-record > > 4. https://wicg.github.io/trust-token-api/#limit-encoded-info > > 5. https://wicg.github.io/trust-token-api/#per-issuer-limits > > 6. https://github.com/WICG/trust-token-api/issues/106 > > 7. &g

Re: [blink-dev] Intent to Ship: Dialog Toggle Events

It very nearly falls into the first exception at https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/ since it's shipping in Firefox nightly, and https://github.com/whatwg/html/pull/10091 looks close to merging. On Wed, Oct 16, 2024 at 11:53 PM Keith Cirkel wrote: > It seemed

Re: [blink-dev] Intent to Prototype & Ship: Private State Token API Permissions Policy Default Allowlist Wildcard

ponse > > 3. https://wicg.github.io/trust-token-api/#redemption-record > > 4. https://wicg.github.io/trust-token-api/#limit-encoded-info > > 5. https://wicg.github.io/trust-token-api/#per-issuer-limits > > 6. https://github.com/WICG/trust-token-api/issues/106 > >

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

On Tue, Oct 1, 2024 at 2:32 AM Yoav Weiss (@Shopify) wrote: > Thanks for working on this! This is super interesting!! > > On Monday, September 30, 2024 at 4:12:25 PM UTC+2 Marja Hölttä wrote: > > (Sending this I2S as recommended by API owners, to continue the discussion > about shipping this feat

Re: [blink-dev] Intent to Prototype: :local-link pseudo selector.

I've filed https://github.com/w3c/csswg-drafts/issues/10975 to question the current naming. Regardless, the use case seems valuable and worth prototyping. Thanks for working on it! On Mon, Sep 30, 2024, 5:09 AM PhistucK wrote: > > If the hyperlink’s target includes a fragment URL, then the frag

Re: [blink-dev] Intent to Prototype & Ship: Private State Token API Permissions Policy Default Allowlist Wildcard

This Intent makes me realize that my mental model of Private State Tokens wasn't correct. I'd been thinking of users going to a site that trusts them, having that site issue some tokens, and then going to another site which would redeem a token to increase its trust. In both cases, the sites could

Re: [blink-dev] Intent to Ship: Compression dictionary transport with Shared Brotli and Shared Zstandard

Congratulations on getting compression dictionaries through the standards gauntlet! On Tue, Aug 27, 2024 at 2:36 AM Tsuyoshi Horo wrote: > Contact emailsh...@chromium.org, pmee...@chromium.org, > nidhij...@chromium.org, yoavwe...@chromium.org, kenjibah...@chromium.org > > Explainerhttps://github

Re: [blink-dev] Intent to Prototype: canvas placeElement()

On Wed, Jun 26, 2024 at 3:08 PM Aaron Krajeski wrote: > Contact emails > > aaro...@chromium.org, fs...@chromium.org, khushalsa...@chromium.org > > Explainer > > placeElement technical paper [public] >

Re: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Write `image/svg+xml` content in UTF-8 format on Windows.

dressed properly > for all supported formats. I'll work on that next. > Thanks! > > ------ > *From:* Jeffrey Yasskin > *Sent:* Wednesday, June 12, 2024 3:01 PM > *To:* Anupam Snigdha > *Cc:* Jeffrey Yasskin ; blink-dev < > blink-dev@chromium

Re: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Write `image/svg+xml` content in UTF-8 format on Windows.

yte%20sequence.> > > Thanks, > Anupam > ------ > *From:* Jeffrey Yasskin > *Sent:* Wednesday, June 12, 2024 11:56 AM > *To:* Anupam Snigdha > *Cc:* blink-dev ; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Christine Hollingsworth >

Re: [blink-dev] Web-Facing Change PSA: Write `image/svg+xml` content in UTF-8 format on Windows.

Could you add this detail to the Clipboard spec, since it seems to be needed for programs to be interoperable? Thanks, Jeffrey On Wed, Jun 12, 2024 at 11:43 AM 'Anupam Snigdha' via blink-dev < blink-dev@chromium.org> wrote: > *Contact emails* > *sni...@microsoft.com * > *sa...@microsoft.com * >

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

The text in the default Intent email is derived from the position issue's labels, and https://github.com/mozilla/standards-positions/issues/143 was closed before the Mozilla folks had created the labels we're looking for. We don't have great help text in Chrome Status to help feature owners figure

Re: [blink-dev] Intent to Prototype: Document picture-in-picture: add option to ignore window bounds cache

Could you confirm that you meant to send an Intent to Prototype here? You have "Shipping on desktop 126" in Estimated milestones, and https://chromestatus.com/feature/5183881532932096 has some of the Prepare to ship reviews approved, but you haven't checked the box at the top of https://chromestatu

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

Oops, Ben's not at Microsoft anymore, so you've done the best you can with the Mozilla and WebKit position requests. Thanks. On Thu, May 9, 2024 at 8:48 AM Jeffrey Yasskin wrote: > If you've moved the explainer, could you replace the content of > https://git

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

If you've moved the explainer, could you replace the content of https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md with a pointer to the new location? Then people who follow the old links won't be confused. You can and should also update the links in https

Re: [blink-dev] Intent to Prototype: Importmap integrity

This looks great; thanks for working on it! One question: My understanding is that there's an alternate design here in which the integrity information is attached to the `import` statements inside modules, which would allow developers to attach integrity information to url-based modules without ne

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

Non-API-owner opinions inline: On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via blink-dev < blink-dev@chromium.org> wrote: > I just had some clarifying questions > > On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar wrote: > >> Some additional notes: >> - This API is tested in the declarative Shado

[blink-dev] As a web feature author, which Chrome Status changes would help you?

Hi Blink contributors, Chrome Status has spent the last year implementing support for approval gates, but now it's time to increase focus on things that will help feature authors work their way through the process. What would help you? I've collected an initial set of relevant bugs under the for-

Re: [blink-dev] Intent to Ship: WebGPU timestamp queries

On Thu, Oct 26, 2023 at 1:21 AM 'François Beaufort' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > fbeauf...@google.com, cwal...@google.com > > Explainer > > https://github.com/gpuweb/gpuweb/issues/614 > > Specification > > https://gpuweb.github.io/gpuweb/#timestamp > > Summar

Re: [blink-dev] Intent to Ship: Ruby-specific display values

My reading of #1771 is that the only thing keeping out of HTML is the lack of a Blink or WebKit implementation. It looks like https://github.com/whatwg/html/pull/6478 is already written to improve the text, so the only thing for Kent to do is to make sure that this change implements that PR and th

Re: [blink-dev] Intent to Prototype: Verifying IPFS client

Thanks for posting this here. I have a couple questions/suggestions: * In your explainer, I don't see a description of the use cases for each of the 3 URL forms you plan to implement. https://tag.w3.org/explainers/ has some guidance around doing that. * The explainer says "Why HTTP(s)?", but nothi

[blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

"we're about to send an intent" to the last issue discussing it, or file an "Is X ready to ship?" issue. I think +Chris Harrelson is likely to have the strongest opinions about this: should we add such a rule to our launch process for CSS features? Jeffrey On Wed, Oct 4,

[blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

go back to the > CSSWG and potentially change it back. > There is still no merged spec in HTML or CSS for this feature yet, but I > have open PRs in both specs. > Thanks! On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin > wrote: > >> +1 on the API owners discussing this.

[blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

+1 on the API owners discussing this. I'd like to understand better how we wound up shipping :--foo and then having the CSSWG ask us to change it to :state(foo) instead, and what we could do in the future to avoid it happening again. It looks like the initial proposal was :state(foo); the CSSWG a

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

uple > weeks and everything looks gray, so we should be safe to ramp up to 100%. > The only thing of note was a correlation with an unrelated crash in Blink > <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, since > the deprecation rollout was fairly large. It onl

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

This should probably be an "Intent to Deprecate and Remove" rather than an "Intent to Ship". I'll let an API owner say if there's a reason to re-send it; probably there isn't. On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' v

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

Transparency serves a bunch of different goals, as described in https://w3ctag.github.io/privacy-principles/#transparency, and the most valuable aren't always to give an end-user more information while they're trying to make a decision. I think the explainer is clear enough in saying that its goal

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

I see this as the other vendors endorsing Blink's general policy, implied by the wording in https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews, that there's a high bar for name changes after shipping. If this API, which has a clearly inaccurate name an

Re: [blink-dev] Ready for Trial: Multi-surface capture with auto-accept (for managed sessions only)

On Fri, May 19, 2023 at 6:56 AM Simon Hangl wrote: > Contact emails > > simo...@chromium.org > > Explainer > > https://github.com/screen-share/capture-all-screens/blob/main/explainer.md > > Specification > > https://screen-share.github.io/capture-all-screens/ > > Design docs > > https://screen-sh

Re: [blink-dev] Intent to Experiment: ServiceWorkerBypassFetchHandlerForMainResources

On Thu, Feb 9, 2023 at 8:23 AM Shunya Shishido wrote: > Contact emails > > sisidov...@chromium.org, kenjibah...@chromium.org > > Explainer > > > https://github.com/sisidovski/service-worker-bypass-fetch-handler-for-main-resource > Have you started moving this into an incubation venue like the WI

Re: [blink-dev] Proposal of web facing feature about Sec-GPC implementation

And, with respect to the launch process, whoever upstreams this will have to put it in Chrome Status (which I can help with) and send an Intent to Prototype, but you can stop there. While we'd love for you to take it all the way to Intent to Ship and have the discussion about how to have Chromium d

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

I see that your Chrome Status entry says "Specification being incubated in a Community Group", but your explainer is not hosted by a CG, and the specification you cite is 1) in a WG and 2) not the specification you'll need to write for thi

Re: [blink-dev] Intent to Ship: Web Authentication Conditional UI

On Mon, Sep 19, 2022 at 2:25 PM Nina Satragno wrote: > ... > Interoperability and Compatibility > > Very low: this is a new feature that's already implemented by Safari on > their Technology Preview. > > Gecko: No signal > It's probably worth filing a standards-position

[blink-dev] Process survey results

Hello Blink-dev! We took a survey of your impressions of our process and tooling back in February, and I wanted to share the results. This survey was an iteration of a survey conducted in early 2021

[blink-dev] Re: Chromium process and tooling Survey - ACTION REQUESTED

You have 1 more week to tell us what you like and don't like about the Chromium process, so please fill this out if you haven't yet. We'll send a summary of the results out next week. Thanks, Jeffrey On Wed, Feb 16, 2022 at 5:00 AM Jeffrey Yasskin wrote: > Hello blink-dev!

[blink-dev] Chromium process and tooling Survey - ACTION REQUESTED

Hello blink-dev! We continue to work on refining the Chromium process and tools, and we'd like to get YOUR thoughts to help direct how we improve the process, tools and documentation around Chromium (similar to a survey

Re: [blink-dev] Intent to Deprecate: Standardize existing client hint naming

On Tue, Nov 2, 2021 at 9:14 AM Ari Chivukula wrote: > Contact emails > > aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org > > Design Doc > > > https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit > > > https://docs.google.com/document/d/1X5bEb