Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

2024-01-12 Thread Yoav Weiss
Thanks for working on this important problem! :) On Fri, Jan 12, 2024 at 11:31 AM Noam Rosenthal wrote: > Contact emailsnrosent...@chromium.org > > Explainer > https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md > Can the explainer be updated? e.g. I'm assuming that the

[blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

2024-01-12 Thread Brian Birtles
Hi, Will this also cover the behavioral differences between caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as implemented in Blink such as: 1. caretPositionFromPoint in Gecko digs into shadow DOM elements whereas caretRangeFromPoint in Blink does not. 2. When the point

[blink-dev] Intent to Ship: New ALPS code point

2024-01-12 Thread Victor Tan
Contact emails victor...@chromium.org, miketa...@chromium.org, david...@chromium.org Explainer https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md Specification https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability

[blink-dev] Intent to Prototype: document.caretPositionFromPoint API

2024-01-12 Thread 'Siye Liu' via blink-dev
Contact emails si...@microsoft.com, sa...@microsoft.com Explainer None Specification https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint Summary This new API allows users to get current caret position from a given screen point. The API returns a CaretPosition object which

Re: [blink-dev] RuntimeEnabledFeatures flags that we might be able to remove

2024-01-12 Thread Xianzhu Wang
It seems that some old public features can also be removed. They have dedicated --disable-* command line switches or are bound to base features, but are not much different from the non-public ones which are also controllable with command line flags (--disable-features/--disable-blink-features) or

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

2024-01-12 Thread 'Orr Bernstein' via blink-dev
Thank you, everyone! I really appreciate it. On Thursday, January 11, 2024 at 5:37:30 PM UTC-5 rby...@chromium.org wrote: > LGTM3 > > On Wed, Jan 3, 2024 at 6:44 PM Mike Taylor wrote: > >> No concerns. LGTM2 >> On 1/3/24 1:41 PM, Chris Harrelson wrote: >> >> LGTM1 >> >> On Wed, Jan 3, 2024 at

[blink-dev] RuntimeEnabledFeatures flags that we might be able to remove

2024-01-12 Thread David Baron
Since we've recently been more careful about creating feature flags for changes that have the possibility of breaking content, we've also been creating more feature flags than before. This means that we're also creating a larger number of feature flags that have shipped to stable, been shown to

[blink-dev] Intent to Ship: Long Animation Frame Timing

2024-01-12 Thread Noam Rosenthal
Contact emailsnrosent...@chromium.org Explainer https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md Specificationhttps://w3c.github.io/longtasks/ Summary This is an extension of long tasks. It measures the task

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

2024-01-12 Thread Nonoka Muraki
spec PR was merged.(https://github.com/whatwg/html/pull/9933) On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote: > Thanks Rakina - right now the biggest blocker is the unlanded spec PR. > Things should move pretty quickly once that's resolved. > On 1/10/24 11:15 PM, Rakina Zata

Re: [blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

2024-01-12 Thread 'Harald Alvestrand' via blink-dev
This extension has consensus in the WEBRTC WG, and CLs are approved by the Chrome WebRTC folks. On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > phan...@microsoft.com, ma...@microsoft.com > > Explainer > >