[blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

2025-03-12 Thread Jake Archibald
Fwiw the spec is already written to allow this. On Wed, 12 Mar 2025 at 02:35, Jiacheng Guo wrote: > I have checked with @Vladimir Levin . Currently chrome > is not supporting inserting any kind of render-blocking elements from > javascript. Since it is a very practical use case we may work on ad

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

2025-03-12 Thread Noam Rosenthal
On Wed, Mar 12, 2025 at 2:35 AM 'Jiacheng Guo' via blink-dev < blink-dev@chromium.org> wrote: > I have checked with @Vladimir Levin . Currently chrome > is not supporting inserting any kind of render-blocking elements from > javascript. Since it is a very practical use case we may work on adding t

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

2025-03-12 Thread 'Jiacheng Guo' via blink-dev
Yes, inserting render-blocking elements in the headers is supported. I'm not very accurate in the previous message. The current situation is that Chrome cannot fulfill a render-blocking element to unblock the renderer if it is inserted from the script. For instance, this page will not work:

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

2025-03-12 Thread Jake Archibald
I guess the result of the above is that rendering is blocked longer than expected, since it renders when the document readiness is no longer "loading"? Yeah, it'd be nice to follow the spec here and allow #target-id to be decided even if it isn't inserted by the parser. This is important for "ren

Re: [blink-dev] Intent to Ship: Bounce Tracking Mitigations on HTTP Cache

2025-03-12 Thread Andrew Liu
On Tuesday, March 11, 2025 at 10:12:49 PM UTC-4 Martin Thomson wrote: On Wed, 12 Mar 2025 at 03:15, Andrew Liu wrote: I don't have permissions in the repo to merge the PR. I formally became a spec editor a week ago, but GH permission changes have to go through the PrivacyCG chairs. I’ve f

Re: [EXTERNAL] [blink-dev] Intent to Ship: CSS anchor positioning remembered scroll offset

2025-03-12 Thread Chris Harrelson
Sorry, redundant email. You have 3 LGTMs. On Wed, Mar 12, 2025, 7:52 AM Chris Harrelson wrote: > LGTM2 > > On Mon, Mar 10, 2025, 11:34 AM 'Alex Russell' via blink-dev < > blink-dev@chromium.org> wrote: > >> LGTM1 >> >> On Wednesday, March 5, 2025 at 11:47:20 PM UTC-8 Morten Stenshorne wrote: >>

Re: [EXTERNAL] [blink-dev] Intent to Ship: CSS anchor positioning remembered scroll offset

2025-03-12 Thread Chris Harrelson
LGTM2 On Mon, Mar 10, 2025, 11:34 AM 'Alex Russell' via blink-dev < blink-dev@chromium.org> wrote: > LGTM1 > > On Wednesday, March 5, 2025 at 11:47:20 PM UTC-8 Morten Stenshorne wrote: > >> Daniel Clark writes: >> >> > Can you remind me what the current behavior is without the remembered >> > sc

Re: [blink-dev] Re: Intent to Ship: SharedWorker script inherit controller for blob script URL

2025-03-12 Thread Mike Taylor
These proposed metrics sound reasonable to us, so long as they capture all cases where the behavior is changing. But we defer to you and your team as the experts. On 3/11/25 3:08 AM, 'Yoshisato Yanagisawa' via blink-dev wrote: The UMA and use count is recorded in the following code: https://so

Re: [blink-dev] Re: Intent to Ship: Nested view transitions

2025-03-12 Thread Yoav Weiss (@Shopify)
LGTM3 On Tuesday, March 11, 2025 at 5:33:15 PM UTC+1 Noam Rosenthal wrote: > On Mon, Mar 10, 2025 at 11:33 PM Noam Rosenthal > wrote: > >> >> >> On Mon, Mar 10, 2025 at 8:50 PM Mike Taylor >> wrote: >> >>> LGTM2. >>> >>> Maybe toss something like >>> assert_true(CSS.supports('selector(::vie

Re: [blink-dev] Re: Intent to Ship: Partitioning cross-site top-level navigations in the HTTP cache

2025-03-12 Thread Alex Russell
LGTM3 On Wednesday, March 5, 2025 at 6:21:35 AM UTC-8 Mike Taylor wrote: > FYI, it looks like WebKit is trending supportive on this change: > https://github.com/WebKit/standards-positions/issues/462#issuecomment-2693662676 > > On 3/2/25 9:32 PM, Domenic Denicola wrote: > > LGTM2. > > I'm sadd

Re: [blink-dev] Re: Intent to Ship: Language support for CanvasTextDrawingStyles

2025-03-12 Thread Chris Harrelson
LGTM1 On Wed, Mar 5, 2025 at 6:38 AM Stephen Chenney wrote: > Thanks Vlad. Answers inline. > > On Tue, Mar 4, 2025 at 10:34 PM Vladimir Levin > wrote: > >> >> >> On Tuesday, March 4, 2025 at 11:17:42 AM UTC-5 Chromestatus wrote: >> >> Contact emails schen...@chromium.org >> >> Explainer https:/

[blink-dev] I2P&S: Strict Same Origin Policy for Storage Access API

2025-03-12 Thread Chris Fredrickson
Contact emails cfred...@chromium.org Explainer None Specification https://github.com/privacycg/storage-access/pull/213 Summary Adjusts the Storage Access API semantics to strictly follow the Same Origin Policy, w.r.t. security. I.e., using document.requestStorageAccess() in a frame only at

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

2025-03-12 Thread Domenic Denicola
Hi Mike! I think we covered several of these areas in the original post, but thanks for the reminders on the rest. On Thu, Mar 13, 2025 at 7:42 AM Mike Taylor wrote: > Could you also please comment on progress for the following areas >

Re: [blink-dev] Re: Intent to Ship: Language support for CanvasTextDrawingStyles

2025-03-12 Thread Alex Russell
LGTM2 On Wednesday, March 12, 2025 at 12:02:05 PM UTC-4 Chris Harrelson wrote: > LGTM1 > > On Wed, Mar 5, 2025 at 6:38 AM Stephen Chenney > wrote: > >> Thanks Vlad. Answers inline. >> >> On Tue, Mar 4, 2025 at 10:34 PM Vladimir Levin >> wrote: >> >>> >>> >>> On Tuesday, March 4, 2025 at 11:17

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

2025-03-12 Thread Noam Rosenthal
On Wed, Mar 12, 2025 at 9:18 AM Jiacheng Guo wrote: > Yes, inserting render-blocking elements in the headers is supported. > I'm not very accurate in the previous message. The current situation is > that Chrome cannot fulfill a render-blocking element to unblock the > renderer if it is inserted f

[blink-dev] Re: Intent to Experiment: Speculation rules: target_hint field

2025-03-12 Thread Alex Russell
LGTM1 I continue to be concerned that we are proliferating these declarative forms without any object model. I'd like to see an OM for speculation rules, import maps, and other similar designs. Has this come up in your discussions with the TAG? Best, Alex On Thursday, March 6, 2025 at 11:42:

Re: [blink-dev] Re: Intent to Ship: Language support for CanvasTextDrawingStyles

2025-03-12 Thread Mike Taylor
LGTM3 On 3/12/25 12:47 PM, Alex Russell wrote: LGTM2 On Wednesday, March 12, 2025 at 12:02:05 PM UTC-4 Chris Harrelson wrote: LGTM1 On Wed, Mar 5, 2025 at 6:38 AM Stephen Chenney wrote: Thanks Vlad. Answers inline. On Tue, Mar 4, 2025 at 10:34 PM Vladimir Levin

Re: [blink-dev] Re: Intent to Experiment: Speculation rules: target_hint field

2025-03-12 Thread Chris Harrelson
(BTW, for the intent owner: only one LGTM needed for this intent.) On Wed, Mar 12, 2025 at 9:50 AM Alex Russell wrote: > LGTM1 > > I continue to be concerned that we are proliferating these declarative > forms without any object model. I'd like to see an OM for speculation > rules, import maps,

Re: [blink-dev] Intent to Ship: Deprecate getters of Intl Locale Info

2025-03-12 Thread 'Panos Astithas' via blink-dev
On Wed, Mar 12, 2025 at 3:12 PM Mike Taylor wrote: > On 3/12/25 5:38 PM, Frank Tang (譚永鋒) wrote: > > > > On Wed, Mar 12, 2025 at 8:19 AM Chris Harrelson > wrote: > >> >> >> On Wed, Mar 5, 2025 at 10:39 AM 'Frank Tang (譚永鋒)' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> >>> >>> On Wed,

Re: [blink-dev] Re: Intent to Ship: H265 (HEVC) codec support in WebRTC

2025-03-12 Thread Alex Russell
Thanks to everyone for taking the time to get this to a place where we can accept it. As there are already enough LGTMs to ship, I only want to add one condition to what Philip documented (that this is only for HW-supported decode, that there may be new work to do to detect and block decode/enco

Re: [blink-dev] Intent to Ship: Deprecate getters of Intl Locale Info

2025-03-12 Thread Chris Harrelson
On Wed, Mar 5, 2025 at 10:39 AM 'Frank Tang (譚永鋒)' via blink-dev < blink-dev@chromium.org> wrote: > > > On Wed, Mar 5, 2025 at 6:02 AM Daniel Bratell wrote: > >> Looks like the use counter LocaleInfoObsoleteGetters is at 0.033% which >> is a bit high. >> > Dear Daniel: > > From your point of view

Re: [blink-dev] Intent to Ship: Bounce Tracking Mitigations on HTTP Cache

2025-03-12 Thread 'Martin Thomson' via blink-dev
On Thu, Mar 13, 2025 at 1:45 AM Andrew Liu wrote: > > > On Tuesday, March 11, 2025 at 10:12:49 PM UTC-4 Martin Thomson wrote: > > On Wed, 12 Mar 2025 at 03:15, Andrew Liu wrote: > > > I don't have permissions in the repo to merge the PR. I formally became a > spec editor a week ago, but GH permi

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

2025-03-12 Thread Mike Taylor
On 3/10/25 10:12 AM, Stephen McGruer wrote: > It may change shape before finally shipping (in particular, I'm musing over whether true/false is sufficient information and whether we could give developers more specific enum reasons without leaking user privacy) - I'll come back to the thread fo

Re: [blink-dev] Intent to Ship: Deprecate getters of Intl Locale Info

2025-03-12 Thread 譚永鋒
On Wed, Mar 12, 2025 at 8:19 AM Chris Harrelson wrote: > > > On Wed, Mar 5, 2025 at 10:39 AM 'Frank Tang (譚永鋒)' via blink-dev < > blink-dev@chromium.org> wrote: > >> >> >> On Wed, Mar 5, 2025 at 6:02 AM Daniel Bratell >> wrote: >> >>> Looks like the use counter LocaleInfoObsoleteGetters is at 0.

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

2025-03-12 Thread Mike Taylor
Could you also please comment on progress for the following areas : Draft spec (early draft is ok, but must be spec-like an

Re: [blink-dev] Re: Intent to Experiment: Speculation rules: target_hint field

2025-03-12 Thread Domenic Denicola
Thank you! On Thu, Mar 13, 2025 at 1:50 AM Alex Russell wrote: > LGTM1 > > I continue to be concerned that we are proliferating these declarative > forms without any object model. I'd like to see an OM for speculation > rules, import maps, and other similar designs. Has this come up in your > di