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

On 10/3/24 4:05 PM, 'Sam LeDoux' via blink-dev wrote: Contact emails sled...@chromium.org, cfred...@chromium.org, johann...@chromium.org Explainer https://github.com/cfredric/storage-access-headers

Re: [blink-dev] Intent to Ship: Fetch: Request.bytes() and Response.bytes()

LGTM3 /Daniel On 2024-10-04 15:20, Yoav Weiss (@Shopify) wrote: LGTM2 Thanks for catching us up here!! On Fri, Oct 4, 2024 at 3:18 PM Mike Taylor wrote: LGTM1 On 10/4/24 6:41 AM, Chromestatus wrote: Contact emails perryuw...@chromium.org Explainer

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

[blink-dev] Intent to Ship: Support external SVG resources for 'clip-path', 'fill', 'stroke' and 'marker-*' properties

Contact emails f...@opera.com Explainer None Specification https://svgwg.org/svg2-draft/linking.html#URLReference Summary Allow external references for clip paths, markers, and paint servers (for the 'fill' and 'stroke' properties). For example, clip-path: url("resources.svg#myPath"). B

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

> > > > About a year ago, we had a thread asking about the standardization plans > for this, and I suggested giving TC39 a PSA and trying to standardize this > through the Web Perf WG. Can you point to any minutes from TC39 where you > discussed this with them, and have you proposed this to a WG as

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

On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote: miketaylr@: It's very likely that the privacy & security reviews will be very straightforward in comparison to the API owners approval. This is essentially a JavaScript feature (though, not a semantics changing one) so it doesn't have pri

Re: [blink-dev] Intent to Ship: Fetch: Request.bytes() and Response.bytes()

LGTM1 On 10/4/24 6:41 AM, Chromestatus wrote: Contact emails perryuw...@chromium.org Explainer None Specification https://fetch.spec.whatwg.org/#dom-body-bytes Summary Add a bytes() method to the Request and Response interfaces, which returns a promis

Re: [blink-dev] Intent to Ship: Fetch: Request.bytes() and Response.bytes()

LGTM2 Thanks for catching us up here!! On Fri, Oct 4, 2024 at 3:18 PM Mike Taylor wrote: > LGTM1 > On 10/4/24 6:41 AM, Chromestatus wrote: > > Contact emails perryuw...@chromium.org > > Explainer None > > Specification https://fetch.spec.whatwg.org/#dom-body-bytes > > Summary > > Add a bytes()

[blink-dev] Intent to Ship: Improvements to styling structure of and elements

Contact emailsdba...@chromium.org Explainerhttps://github.com/dbaron/details-styling https://dbaron.github.io/details-styling/phase-1 Specification https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements Summary Support more CSS styling for the structure of and

Re: [blink-dev] Intent to Ship: Private Aggregation API: increase contribution limit to 100 for Protected Audience callers

No, the reporting endpoint can’t infer the number of null contributions. Critically, the browser pads the payload before encrypting it with the Aggregation Service’s public key. That ciphertext is sent to the reporting endpoint, so the performance of HTTP compression won’t vary depending on the

Re: [blink-dev] Re: Intent to Ship: WebAuthn signal API

Shopify is also very interested in this API. I want to second what Tim said above. Today we have concerns on how *orphaned* passkeys erroneously offered to the user impact passkey sign in conversion rates. This API would address these concerns. On Thursday, October 3, 2024 at 1:21:36 PM UTC-4 Ni

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

OK - thanks John. LGTM to extend until 132 inclusive. On 10/1/24 11:49 AM, John Delaney wrote: Hey Mike, We also plan to continue sending labels for the "label_only" groups as well, overall this <8.5% of browsers (these labels are also subject to a number of eligibility requirements). Curre

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

Hey, happy to give some more information on the compatibility risk. As part of the Storage Access Header implementation, we found that, for security purposes, it was necessary to send the `Origin` header in certain cross-site requests that would not previously have had the header. We've seen s

[blink-dev] Intent to Ship: Fetch: Request.bytes() and Response.bytes()

Contact emails perryuw...@chromium.org Explainer None Specification https://fetch.spec.whatwg.org/#dom-body-bytes Summary Add a bytes() method to the Request and Response interfaces, which returns a promise that resolves with a Uint8Array. While Request and Response have an arrayBuffer() m