[blink-dev] Intent to Prototype: CSS calc-size() function

[David Baron]

Contact emailsdba...@chromium.org

ExplainerNone yet.  (But the starting point for writing one, particularly a
section on alternatives considered, would probably be the discussion in the
github issue starting from Tab's November 6 comment
 to
the present.)

SpecificationNone yet, but the CSS Working Group has resolved (yesterday)
to add this feature to CSS Values & Units Module Level 5
.

Summary

The CSS calc-size() function is a CSS function similar to calc(), but that
also supports operations on exactly one of the values auto, min-content,
max-content, fit-content, stretch, or contain. This allows transitions and
animations to and from these values (or mathematical functions of these
values), as long as the calc-size() function is used on at least one of the
endpoints of the transition or animation to opt in.

Blink componentBlink>Layout


Motivation

Animation to or from auto heights is a very commonly requested feature by
web developers because it is important for animation of elements (such as
the contents of disclosure widgets) opening/closing between a content-based
height (or width) and a small (often zero) height (or width). This feature
fits the desire to do such animations into the way that CSS transitions and
animations work. More generally, this allows animating any height that can
currently be specified in CSS to zero or to/from a small fixed value.

Initial public proposal
https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1800254442

TAG reviewNone yet.

TAG review statusPending

Risks


Interoperability and Compatibility

The CSS Working Group has so far had only a brief synchronous discussion of
the proposal, so I didn't get a good sense of what other engine developers
think of the proposal (and they also haven't yet had a lot of time to
examine it). However, given the history of developer demand for the
feature, I think a (hopefully) compelling prototype in Chromium may help
make a strong case for implementation in other engines.

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive. Animation to/from auto height is a very
commonly requested feature by developers. See citations, stars/votes, and
comments in https://github.com/w3c/csswg-drafts/issues/626,
https://bugs.chromium.org/p/chromium/issues/detail?id=313072, and
https://bugzilla.mozilla.org/show_bug.cgi?id=571344.

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

Expected to be similar to existing CSS calc() function.


Is this feature fully tested by web-platform-tests

?No, but I intend to write WPT tests as I work on it, with the caveat that
I might not be quite as thorough as I would be if I weren't expecting
substantial future changes to the proposal based on what we learn from
trying to prototype it.

Flag name on chrome://flagsNone

Finch feature namekCSSCalcSizeFunction

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=313072

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5196713071738880

This intent message was generated by Chrome Platform Status
 and edited by hand.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3hBtXebfpW3JSoO-RF43aCCsNK-vZ0uvqoVaBoJbfAT6g%40mail.gmail.com.

Re: [blink-dev] PSA: Changing File System Access API interaction with the back/forward cache

['Vladimir Levin' via blink-dev]

Ah that makes sense! Thank you for explaining!

On Thu, Dec 21, 2023 at 1:57 PM 'Nathan Memmott' via blink-dev <
blink-dev@chromium.org> wrote:

> Sorry, that was poorly worded. We evict "a page in BFCache if *[evicting
> the page in BFCache]* allows another page to take an FSA lock."
>
> For example, a page in BFCache may have a sync access handle open on a
> file. An active page may attempt to open a writable on that same file.
> Previous behavior is to reject with a NoModificationAllowedError. The new
> behavior is to evict the page in BFCache to allow the active page to open
> the writable.
>
> On Thu, Dec 21, 2023, 8:23 AM Vladimir Levin  wrote:
>
>>
>>
>> On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Howdy blink-dev,
>>>
>>> In Chromium M121, we will update how the File System Access (FSA) API
>>> interacts with the back/forward cache (BFCache). This should only affect
>>> the conditions a page can remain in the BFCache. There should be no
>>> behavioral changes to the FSA API.
>>>
>>> A page can hold FSA locks to files via FileSystemWritableFileStream,
>>> FileSystemSyncAccessHandle, and file operations. These FSA locks prevent
>>> incompatible concurrent access to a file (e.g. having both a writable and
>>> access handle open on a file). A page in BFCache can hold FSA locks and
>>> prevent an active (not in BFCache) page from accessing a file. This can be
>>> unexpected behavior to a developer/user.
>>>
>>> The changes made in Chromium M121 address this issue by evicting a page
>>> in BFCache if it allows another page to take an FSA lock. If it doesn't
>>> allow another page to take an FSA lock, then the page can remain in BFCache.
>>>
>>
>> This might be a misunderstanding in terminology on my part, but is this
>> backwards? If the BFCache page allows an active page to acquire a lock,
>> then it's evicted? Or is it then allowed to stay?
>>
>>
>>> This doesn't break any assumptions about concurrent access. An FSA lock
>>> is not given out until incompatible FSA locks have been released.
>>>
>>> This PR for the whatwg/fs spec defines the behavior in more detail:
>>> https://github.com/whatwg/fs/pull/154
>>>
>>> Thanks,
>>> Nathan
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SuFB_G_H%2Bqdq2OhN6Fc3gR5Npy%3D5unk5EB1bJbzvPRtHg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PPjsS7isdROkQRDDiSSfQctSaAHpk%3DWHufACxZCQPhxw%40mail.gmail.com.

Fwd: [blink-dev] PSA: Changing File System Access API interaction with the back/forward cache

['Nathan Memmott' via blink-dev]

Sorry, that was poorly worded. We evict "a page in BFCache if *[evicting
the page in BFCache]* allows another page to take an FSA lock."

For example, a page in BFCache may have a sync access handle open on a
file. An active page may attempt to open a writable on that same file.
Previous behavior is to reject with a NoModificationAllowedError. The new
behavior is to evict the page in BFCache to allow the active page to open
the writable.

On Thu, Dec 21, 2023, 8:23 AM Vladimir Levin  wrote:

>
>
> On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Howdy blink-dev,
>>
>> In Chromium M121, we will update how the File System Access (FSA) API
>> interacts with the back/forward cache (BFCache). This should only affect
>> the conditions a page can remain in the BFCache. There should be no
>> behavioral changes to the FSA API.
>>
>> A page can hold FSA locks to files via FileSystemWritableFileStream,
>> FileSystemSyncAccessHandle, and file operations. These FSA locks prevent
>> incompatible concurrent access to a file (e.g. having both a writable and
>> access handle open on a file). A page in BFCache can hold FSA locks and
>> prevent an active (not in BFCache) page from accessing a file. This can be
>> unexpected behavior to a developer/user.
>>
>> The changes made in Chromium M121 address this issue by evicting a page
>> in BFCache if it allows another page to take an FSA lock. If it doesn't
>> allow another page to take an FSA lock, then the page can remain in BFCache.
>>
>
> This might be a misunderstanding in terminology on my part, but is this
> backwards? If the BFCache page allows an active page to acquire a lock,
> then it's evicted? Or is it then allowed to stay?
>
>
>> This doesn't break any assumptions about concurrent access. An FSA lock
>> is not given out until incompatible FSA locks have been released.
>>
>> This PR for the whatwg/fs spec defines the behavior in more detail:
>> https://github.com/whatwg/fs/pull/154
>>
>> Thanks,
>> Nathan
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SuFB_G_H%2Bqdq2OhN6Fc3gR5Npy%3D5unk5EB1bJbzvPRtHg%40mail.gmail.com.

Re: [blink-dev] PSA: Changing File System Access API interaction with the back/forward cache

['Vladimir Levin' via blink-dev]

On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <
blink-dev@chromium.org> wrote:

> Howdy blink-dev,
>
> In Chromium M121, we will update how the File System Access (FSA) API
> interacts with the back/forward cache (BFCache). This should only affect
> the conditions a page can remain in the BFCache. There should be no
> behavioral changes to the FSA API.
>
> A page can hold FSA locks to files via FileSystemWritableFileStream,
> FileSystemSyncAccessHandle, and file operations. These FSA locks prevent
> incompatible concurrent access to a file (e.g. having both a writable and
> access handle open on a file). A page in BFCache can hold FSA locks and
> prevent an active (not in BFCache) page from accessing a file. This can be
> unexpected behavior to a developer/user.
>
> The changes made in Chromium M121 address this issue by evicting a page in
> BFCache if it allows another page to take an FSA lock. If it doesn't allow
> another page to take an FSA lock, then the page can remain in BFCache.
>

This might be a misunderstanding in terminology on my part, but is this
backwards? If the BFCache page allows an active page to acquire a lock,
then it's evicted? Or is it then allowed to stay?


> This doesn't break any assumptions about concurrent access. An FSA lock is
> not given out until incompatible FSA locks have been released.
>
> This PR for the whatwg/fs spec defines the behavior in more detail:
> https://github.com/whatwg/fs/pull/154
>
> Thanks,
> Nathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P7af9MprWmij%3DCpzYNgmHg8sxnC%3DDYVvPOP%3DLqr6kzHg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Highlight Inheritance

[Mike Taylor]

Thanks for the update. I might have jinxed it when I said "breakage in 
this case would just be cosmetic (unless someone is doing something 
really clever)"... I hadn't considered editor use cases.


Do you think this will ever be shippable, even with a gutenberg update? 
I would imagine old versions stick around for a very long time.


On 12/21/23 9:54 AM, Stephen Chenney wrote:
Update: Due to breakage of the Wordpress editor, and a couple of other 
sites, we plan to delay the Stable ship milestone to 122.


I'll update the status entry etc.

Stephen.

On Wed, Nov 8, 2023 at 10:34 AM Yoav Weiss  wrote:

LGTM3

On Wednesday, November 8, 2023 at 4:18:59 PM UTC+1 Daniel Bratell
wrote:

LGTM2

You may want to ping the Mozilla standards position issue and
let them know that we are close to shipping. It looks like
they forgotten it.

/Daniel

On 2023-11-06 16:43, Mike Taylor wrote:


Thanks for the detailed explanation of compat and for filing
a TAG review. The risk of breakage seems low (and I suppose
we'll learn how true that is as the change rides the trains),
and breakage in this case would just be cosmetic (unless
someone is doing something really clever).

LGTM1 to ship. Good luck. :)

On 11/3/23 12:19 PM, Stephen Chenney wrote:

Note that I have moved the shipping milestone to M121, and
have created a TAG review issue.

On Thu, Nov 2, 2023 at 10:07 AM Stephen Chenney
 wrote:



On Wed, Nov 1, 2023 at 11:11 AM Stephen Chenney
 wrote:

Answers inline. Regarding Ander's comment on the
current base_feature setting: I'll fix that.

Cheers,
Stephen.

On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss
 wrote:



On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney
 wrote:


Contact emails

schen...@chromium.org


Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade


Summary

With CSS Highlight Inheritance, the CSS
Highlight pseudo classes, such as
::selection and ::highlight, inherit their
properties through the pseudo highlight
chain, rather than the element chain. The
result is a more intuitive model for
inheritance of properties in highlights.
Specifically, "When any supported property
is not given a value by the cascade ... its
specified value is determined by inheritance
from the corresponding highlight
pseudo-element of its originating element’s
parent element."

(https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)



Blink component

Blink>CSS




TAG review

None


Features are exempt from a TAG review only when
another vendor has already shipped them. That
doesn't seem to be the case here.


The feature is in the CSS pseudos spec and has been
for quite a while. The CSS Working Group has been
discussing issues too and Safari, at least, is
implementing according to the spec. I think the ship
has sailed for any major revision to the behavior.
(For context, there was no feature defined for this
change until recently because it was originally
viewed as a "make the code implement the spec" change.)


TAG Review Issue:
https://github.com/w3ctag/design-reviews/issues/914





TAG review status

Not applicable


Risks



Interoperability and Compatibility

The feature is still under implementation in
other browser engines, but the standards are
well developed and there is general
agreement on the spec. I think compat risk
is very limited at this time.


Does this feature change the behavior of
existing uses of ::highlight and ::selection? Is
there risk from breakage there?


The change aligns the behavior of ::

Re: [blink-dev] Re: Intent to deprecate: SMIL

[Lorand Zudor]

👍 You are welcome, Philip. Have a great one!
- L.



-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/106d3214-4c6d-4db7-be37-1727e2d761b7n%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS Highlight Inheritance

[Stephen Chenney]

Update: Due to breakage of the Wordpress editor, and a couple of other
sites, we plan to delay the Stable ship milestone to 122.

I'll update the status entry etc.

Stephen.

On Wed, Nov 8, 2023 at 10:34 AM Yoav Weiss  wrote:

> LGTM3
>
> On Wednesday, November 8, 2023 at 4:18:59 PM UTC+1 Daniel Bratell wrote:
>
>> LGTM2
>>
>> You may want to ping the Mozilla standards position issue and let them
>> know that we are close to shipping. It looks like they forgotten it.
>>
>> /Daniel
>> On 2023-11-06 16:43, Mike Taylor wrote:
>>
>> Thanks for the detailed explanation of compat and for filing a TAG
>> review. The risk of breakage seems low (and I suppose we'll learn how true
>> that is as the change rides the trains), and breakage in this case would
>> just be cosmetic (unless someone is doing something really clever).
>>
>> LGTM1 to ship. Good luck. :)
>> On 11/3/23 12:19 PM, Stephen Chenney wrote:
>>
>> Note that I have moved the shipping milestone to M121, and have created a
>> TAG review issue.
>>
>> On Thu, Nov 2, 2023 at 10:07 AM Stephen Chenney 
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 1, 2023 at 11:11 AM Stephen Chenney 
>>> wrote:
>>>
 Answers inline. Regarding Ander's comment on the current base_feature
 setting: I'll fix that.

 Cheers,
 Stephen.

 On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss 
 wrote:

>
>
> On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney 
> wrote:
>
>> Contact emails schen...@chromium.org
>>
>> Specification
>> https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
>>
>> Summary
>>
>> With CSS Highlight Inheritance, the CSS Highlight pseudo classes,
>> such as ::selection and ::highlight, inherit their properties through the
>> pseudo highlight chain, rather than the element chain. The result is a 
>> more
>> intuitive model for inheritance of properties in highlights. 
>> Specifically,
>> "When any supported property is not given a value by the cascade ... its
>> specified value is determined by inheritance from the corresponding
>> highlight pseudo-element of its originating element’s parent element." (
>> https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)
>>
>>
>> Blink component Blink>CSS
>> 
>>
>> TAG review None
>>
>
> Features are exempt from a TAG review only when another vendor has
> already shipped them. That doesn't seem to be the case here.
>

 The feature is in the CSS pseudos spec and has been for quite a
 while. The CSS Working Group has been discussing issues too and Safari, at
 least, is implementing according to the spec. I think the ship has sailed
 for any major revision to the behavior. (For context, there was no feature
 defined for this change until recently because it was originally viewed as
 a "make the code implement the spec" change.)

>>>
>> TAG Review Issue: https://github.com/w3ctag/design-reviews/issues/914
>>
>>
>>>

>
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The feature is still under implementation in other browser engines,
>> but the standards are well developed and there is general agreement on 
>> the
>> spec. I think compat risk is very limited at this time.
>>
>
> Does this feature change the behavior of existing uses of ::highlight
> and ::selection? Is there risk from breakage there?
>

 The change aligns the behavior of ::selection with Firefox. ::highlight
 is already implemented with this behavior. There was breakage of
 ::selection due to custom property handling, which was resolved at the spec
 level and fixed in chromium before sending this intent. No other bugs have
 come in over the extended period that this has been on for experimental web
 platform features (since M111).

>>>
>>> My above comment is wrong: The spec defining this feature does change
>>> the behavior of ::selection (not ::highlight) for all browsers. But
>>> evidence suggests that the mitigations that sites used to work around the
>>> old behavior still work with the new behavior, so breakage is very limited.
>>> There was a single source of significant breakage when the feature was
>>> first turned on and the spec and code have been changed to maintain the
>>> former behavior (related to custom properties on root applying to
>>> ::selection). We have had zero other reported bugs from enabling the
>>> feature experimentally.
>>>
>>> Some history ... The spec was changed in response to an issue where
>>> Firefox wanted to un-prefix -moz-selection but was not obeying the old
>>> spec. As I understand it, the selection style was checking for ::selection
>>> on the selected element, using it if found, otherwise using the root
>>> sele

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Excellent, we have a plan!

On Wednesday, December 20, 2023 at 7:13:36 PM UTC+1 Mike Taylor wrote:

> LGTM3, with same condition.
> On 12/20/23 11:58 AM, Chris Harrelson wrote:
>
> LGTM2 to ship, with a commitment to move this part of the spec to WICG if 
> it gets removed from the mediacapture-extensions spec.
>
> On Thu, Dec 14, 2023 at 11:06 AM Alex Russell  
> wrote:
>
>> LGTM1
>>
>> On Thursday, December 14, 2023 at 8:00:41 AM UTC-8 Rick Byers wrote:
>>
>>> Sounds good Henrik! Yes, from our brief discussion in the API owners 
>>> meeting I believe you have support from at least 3 API owners to proceed in 
>>> this direction. It's important to us that we engage constructively in the 
>>> standards process even in areas of differing opinion, but it's also crucial 
>>> to our process that we not let such differences in opinion and priority be 
>>> an effective veto power over what we choose to ship in Chromium. I'd 
>>> encourage you and the WebRTC group to formalize processes for amicably 
>>> agreeing to disagree on the importance of different use cases, while still 
>>> being open to technical feedback and doing what we reasonably can to 
>>> maximize the chance that the APIs we ship can eventually be interoperable 
>>> if priorities of the other engines someday change [*]. API owners would 
>>> also be interested to hear any other arguments for why Chromium shipping 
>>> these APIs would be bad for the web (on this list, or anywhere else). I 
>>> know there's a messy history with WebRTC in particular and services coming 
>>> to depend on Chromium-only APIs when suitable standards-track alternatives 
>>> are available in other engines. That's IMHO definitely not a pattern we 
>>> want to risk repeating. 
>>>
>>> Of course you also need Chrome privacy and security reviews, since it's 
>>> important that features like this don't create a hole in our careful 
>>> balance of side channel attack mitigations. But I see you already have 
>>> privacy approval so hopefully security isn't too far off. You might want to 
>>> wait for a signal there before starting implementation.
>>>
>>> Personally I'm also less concerned about interoperability risks when it 
>>> comes to metrics API. It's already the case that our top 
>>> performance metrics (Core Web Vitals) have APIs exposed only in Chromium. 
>>> There's certainly some interop risk there, eg. of sites optimizing in 
>>> engine-specific ways. But in practice we've seen developers use these APIs 
>>> mostly to make their sites faster in ways that generally apply to all 
>>> engines. So in that case, Safari and Firefox are getting most of the 
>>> benefit of these APIs existing without having to incur most of the cost, 
>>> which seems like a fine outcome to me. Also, I'm confident that if we 
>>> eventually agree with other engines on some better way to expose the same 
>>> information, then we can deprecate and remove any API shape we ship today 
>>> and customers can migrate over without causing user-visible breakage 
>>> (worst-case we just return dummy values on the deprecated APIs). 
>>>
>>> Rick
>>>
>>> [*] My favorite example of this is Pointer Events where Apple was 
>>> opposed to the use case, but also had good technical critiques of the API. 
>>> We eventually (after a lot of research, open debate, and some flip-flopping 
>>> by me) shipped a version of the API that addressed the legitimate technical 
>>> concerns without addressing Apple's objections around the use case. Years 
>>> later when a use case materialized for Apple (the Apple Pen), they just 
>>> shipped the API in a fully interoperable fashion. That (as well as cases of 
>>> the inverse where we realize we were wrong and unship) is what we mean by 
>>> the blink process being designed for "eventual interoperability". 
>>>
>>>
>>> On Thu, Dec 14, 2023 at 4:34 AM Henrik Boström  
>>> wrote:
>>>
 Thanks, Rick. Responses inline.

 On Wednesday, December 13, 2023 at 6:39:48 PM UTC+1 Rick Byers wrote:

 I looked into the details of the standards debate on this issue. It 
 sounds like it's still unclear whether the spec for this has WG support or 
 not, right? I certainly wouldn't want to mislead anyone as to API maturity 
 / likely interoperability by shipping based on a WebRTC WG specification 
 if 
 there is an unresolved process concern.


 I think it's safe to say we don't have consensus on the frame counters 
 (exposing dropped/glitches), while capture latency hopefully be less 
 contentious.


 That said, I think Chromium's position on the technical debate here is 
 pretty clear - we do believe there's value in such stats APIs, even IF 
 they 
 can only represent browser bugs (it's why we ship a crash reporting API 
 , which has been similarly 
 controversial with Mozilla and Apple). We disagree that "there's nothing 
 web developers can do about it".