RE: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[BIANCONI Thomas]

I am sad to read this...
A new step before the deprecation of server push.

I would love to see comparaison in term of performance between server push and 
early hint.
On a pure theoric point of view early hint starts during the html parsing 
whereas the server push start with the response header. So server push by 
design is better.
Regarding the complexity to put it in place early hints is easy when you serve 
different page but for Single Page Application the build process don't generate 
differentiate serving based on the route since the routing of the application 
is generally managed in the frontend.
So for Single Page Application to managed server push not global to all route 
it will more complexe to include it in the build process.

Just wanted to share my feeling about this whole topic.

Thanks

Regards

Thomas BIANCONI
Head of Data Technologies
& Data Privacy Champion
Global CDMO Team
41 Rue Martre - 92110 Clichy
Mob : +33 (0) 6 15 35 33 57
Ph : +33 (0) 1 47 56 45 95
E-mail : thomas.bianc...@loreal.com


De : Chris Harrelson 
Envoyé : mercredi 2 mars 2022 18:51
À : Daisuke Enomoto 
Cc : blink-dev ; las...@chromium.org 
; pme...@chromium.org ; Francesco 
Montanari ; Maxim Makarov 
; b...@chromium.org ; 
dsch...@chromium.org ; ians...@chromium.org 
; rektide ; Ben Lesh 
; Andrew Wilder ; Vito De Giosa 

Objet : Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

Notice: External mail

The API owners met today and discussed this intent at some length.

We are very happy that Early Hints is showing very positive promise in terms of 
experimental data, and feel the positive experimental data is enough to justify 
starting the process to remove HTTP/2 push.

To that end, we approve starting official deprecation of the feature now, with 
a (publicly communicated) goal to remove support from Chromium in the next 6-9 
months. We  recommend publishing a blog post describing what's happening and 
the recommended migration paths.

However, we would like to see an Early Hints intent-to-ship before approving 
actual removal of HTTP/2 Push; please do not consider this an email an approval 
to actually remove it until we send LGTMs for such. Our understanding is that 
Early Hints is well on the way to a finished spec and readiness to ship, and 
the remaining pieces of the specification are to nail down integration with 
other related APIs such as Fetch. We think this sounds feasible to complete and 
reach a shipped-in-stable-channel status within the proposed deprecation 
period, which would allow sites to potentially have a seamless transition.

We recognize that this is a long time period, and especially long given the 
time since the start of the request to deprecate. The reason is that we'd 
really like to avoid the "old thing is deprecated, new thing is not yet 
available" situation if possible. Thank you everyone for your patience and 
efforts.

Regards,
Chris


On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto 
mailto:denom...@chromium.org>> wrote:

Hello,


We conducted an experiment for Early Hints 
(chromestatus)
 with partners in Q3 - Q4, 2021. The experiment data suggests that the 
performance impact is highly positive. Based on these insights, we are 
confident that Early Hints will be a viable alternative to H/2 Push for 
performance use cases. In addition, by design Early Hints will not run into the 
overpushing concerns that bogged down H/2 Push. We are working with some of our 
partners to share a bit more details.


Next steps (for Early Hints)

We are actively working on finalizing the shipping plan / timeline. In 
particular, Early Hints requires updating multiple specs. Once our plan becomes 
clearer, the details will be shared on a new Intent to Ship thread.


Non performance use cases

For other perceived use cases beyond performance improvements, we recommend 
sharing more details over at WICG 
Discourse
 with a focus on the problem you are trying to solve rather than how H/2 Push 
could be used. In addition, if you currently rely on H/2 Push in ways that 
Early Hints can’t address, please share 
details
 about how critical this is to your product/service, on top of your use case.

Thanks
Daisuke

On Sun, Feb 20, 2022 at 6:40 PM Morgaine 
mailto:rekt...@gmail.com>> wrote:
I'm not sure if you are being deliberately cruel & malicious, or just 
accidentally cruel. Web developers have been begging for Fetch to please for 
the love of everything holy please report HTTP PUSH 

Re: [blink-dev] Intent to Prototype + Ship: Secure Payment Confirmation API V3

[Mike Taylor]

On 3/15/22 4:42 PM, Nick Burris wrote:
On Tue, Mar 15, 2022 at 4:52 PM Mike Taylor  
wrote:


On 3/9/22 10:27 AM, Nick Burris wrote:



Contact emails

nbur...@chromium.org, rous...@chromium.org,
smcgr...@chromium.org, ma...@chromium.org


Explainer

https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md



Specification

https://w3c.github.io/secure-payment-confirmation/



Design docs

N/A


Summary

Three changes to the Secure Payment Confirmation API, implemented
and flagged as “V3” of the API.

 *

Add Relying Party ID as a required input (issue
).
This is a breaking change, see issue and compatibility section.

 *

Add an optional boolean to allow failed instrument icon
download (issue
).

 *

Add payeeName as an optional input (issue
).


Original feature summary: Secure payment confirmation augments
the payment authentication experience on the web with the help of
WebAuthn. The feature adds a new 'payment' extension to WebAuthn,
which allows a relying party such as a bank to create a
PublicKeyCredential that can be queried by any merchant origin as
part of an online checkout via the Payment Request API using the
'secure-payment-confirmation' payment method.


Blink component

Blink>Payments




TAG review

https://github.com/w3ctag/design-reviews/issues/675



TAG review status

Closed (Resolution: satisfied)


Interoperability and Compatibility

One of the API changes, the relying party ID input, is a breaking
change as it is a new required field. We are confident in this
change as the feature is relatively new and has little usage, and
we have discussed these changes with the external partners who
are using the feature. Adapting to the change is also
forwards-compatible, in that partners can add the new input
todaywithout breaking their code, and then it will just continue
working after this ships.


How confident are y'all that all SPC users will be aware of this
breaking change? Do we have UKM?

Our metrics show that SPC currently has near zero usage, so we are 
confident that there's at least no deployed usage of the feature that 
this will break. We are in contact with multiple partners working on 
products using SPC who are aware of the change. If it does break 
something that's in development that we're not aware of, the error 
message indicates what's missing, and such a developer would likely 
know where to get the latest info on SPC (the github repo, blink-dev) 
or can at least find us. :)


Thanks Nick, that sounds reasonable. If you do hear back from sites who 
were broken by this, it may be useful to update the thread so we can 
learn from the experience.


LGTM1.




Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/570
)
Historically (>1 year old) positive signal from informal
conversation in W3C Payment Handler meetings. However Firefox
have since not been involved in the API development.


WebKit: No signal
(https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html
)


Web developers: Positive
(https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html
)
Support and involvement in API development from multiple web
developers and payment industry partners. Both Stripe and AirBnB
have publicly stated that they have either completed or are in
the process of prototyping/experimenting with SPC




Debuggability

Existing devtools debugging features should cover SPC (e.g.
breakpoints, console, etc)


Is this feature fully tested by web-platform-tests

?

Yes, coverage for the new input fields will be added to the
existing test suite:


https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental




Flag name

SecurePaymentConfirmationAPIV3

[blink-dev] Re: Intent to Prototype: CSS object-view-box and object-overflow

['Tab Atkins' via blink-dev]

On Tue, Mar 15, 2022 at 9:11 AM Camille Lamy  wrote:
> We looked at this as part of the Security & privacy review process for Web 
> Platform intents, and we were wondering about the feature behavior with 
> regards to iframes. Specifically, we were concerned about the potential for a 
> child frame to draw custom content over its parent using this feature. Is 
> something like this possible as part of the overflow mechanism? If so, we 
> were concerned about the potential for spoofing.

Excellent question; the object-* properties were designed with images
in mind rather than iframes. That would indeed be possible with the
spec as currently written; however, it can only be done with the outer
page's blessing - the property needs to be set on the  element
itself, and can't be adjusted by the embedded page.

I suspect that this is still too dangerous of an ability to expose,
and the right answer is to force iframes to be `object-overflow: clip`
at all times; possibly we should force *all* of the object-*
properties to their initial values for iframes. I've raised this in
the CSSWG , and will
adjust the spec after the WG discusses this. Thanks so much for the
review!

~TJ

-- 
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/CACwK9gdyefJW294huWaspAdv2XAzMj5Zbh7LbeK6EJt4vhH4HQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype + Ship: Secure Payment Confirmation API V3

[Nick Burris]

On Tue, Mar 15, 2022 at 4:52 PM Mike Taylor  wrote:

> On 3/9/22 10:27 AM, Nick Burris wrote:
>
> Contact emails
>
> nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org,
> ma...@chromium.org
>
> Explainer
>
> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/secure-payment-confirmation/
>
> Design docs
>
> N/A
>
> Summary
>
> Three changes to the Secure Payment Confirmation API, implemented and
> flagged as “V3” of the API.
>
>-
>
>Add Relying Party ID as a required input (issue
>). This
>is a breaking change, see issue and compatibility section.
>-
>
>Add an optional boolean to allow failed instrument icon download (issue
>).
>-
>
>Add payeeName as an optional input (issue
>).
>
>
> Original feature summary: Secure payment confirmation augments the
> payment authentication experience on the web with the help of WebAuthn. The
> feature adds a new 'payment' extension to WebAuthn, which allows a relying
> party such as a bank to create a PublicKeyCredential that can be queried by
> any merchant origin as part of an online checkout via the Payment Request
> API using the 'secure-payment-confirmation' payment method.
>
> Blink component
>
> Blink>Payments
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/675
>
> TAG review status
>
> Closed (Resolution: satisfied)
>
> Interoperability and Compatibility
>
> One of the API changes, the relying party ID input, is a breaking change
> as it is a new required field. We are confident in this change as the
> feature is relatively new and has little usage, and we have discussed these
> changes with the external partners who are using the feature. Adapting to
> the change is also forwards-compatible, in that partners can add the new
> input today without breaking their code, and then it will just continue
> working after this ships.
>
> How confident are y'all that all SPC users will be aware of this breaking
> change? Do we have UKM?
>
Our metrics show that SPC currently has near zero usage, so we are
confident that there's at least no deployed usage of the feature that this
will break. We are in contact with multiple partners working on products
using SPC who are aware of the change. If it does break something that's in
development that we're not aware of, the error message indicates
what's missing, and such a developer would likely know where to get the
latest info on SPC (the github repo, blink-dev) or can at least find us. :)


>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/570) Historically
> (>1 year old) positive signal from informal conversation in W3C Payment
> Handler meetings. However Firefox have since not been involved in the API
> development.
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)
>
> Web developers: Positive (
> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html)
> Support and involvement in API development from multiple web developers and
> payment industry partners. Both Stripe and AirBnB have publicly stated that
> they have either completed or are in the process of
> prototyping/experimenting with SPC
>
>
>
> Debuggability
>
> Existing devtools debugging features should cover SPC (e.g. breakpoints,
> console, etc)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes, coverage for the new input fields will be added to the existing test
> suite:
>
>
> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>
> Flag name
>
> SecurePaymentConfirmationAPIV3
>
> Requires code in //chrome?
>
> Yes: minor changes to the chrome UI code, to possibly display a
> placeholder card icon when the new ‘iconMustBeShown’ option is false, and
> to render the optional payeeName alongside or instead of the payeeOrigin.
>
> Tracking bug
>
> API V3 bug: https://crbug.com/1298505
>
> Original feature bug: https://crbug.com/1124927
>
> Launch bug
>
> Original SPC launch bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1236570
>
> We believe this is a small enough change to an existing feature that it
> doesn’t require its own launch bug.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5675682238562304
>
> Links to previous Intent discussions
>
> Intent to Prototype v1:
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion
>
> Intent to Experiment v2:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8
>
> Intent to Ship v2:
> 

Re: [blink-dev] Intent to Prototype + Ship: Secure Payment Confirmation API V3

[Mike Taylor]

On 3/9/22 10:27 AM, Nick Burris wrote:



Contact emails

nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org, 
ma...@chromium.org



Explainer

https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md 




Specification

https://w3c.github.io/secure-payment-confirmation/ 




Design docs

N/A


Summary

Three changes to the Secure Payment Confirmation API, implemented and 
flagged as “V3” of the API.


 *

Add Relying Party ID as a required input (issue
).
This is a breaking change, see issue and compatibility section.

 *

Add an optional boolean to allow failed instrument icon download
(issue
).

 *

Add payeeName as an optional input (issue
).


Original feature summary: Secure payment confirmation augments the 
payment authentication experience on the web with the help of 
WebAuthn. The feature adds a new 'payment' extension to WebAuthn, 
which allows a relying party such as a bank to create a 
PublicKeyCredential that can be queried by any merchant origin as part 
of an online checkout via the Payment Request API using the 
'secure-payment-confirmation' payment method.



Blink component

Blink>Payments 




TAG review

https://github.com/w3ctag/design-reviews/issues/675 




TAG review status

Closed (Resolution: satisfied)


Interoperability and Compatibility

One of the API changes, the relying party ID input, is a breaking 
change as it is a new required field. We are confident in this change 
as the feature is relatively new and has little usage, and we have 
discussed these changes with the external partners who are using the 
feature. Adapting to the change is also forwards-compatible, in that 
partners can add the new input todaywithout breaking their code, and 
then it will just continue working after this ships.


How confident are y'all that all SPC users will be aware of this 
breaking change? Do we have UKM?





Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/570 
) 
Historically (>1 year old) positive signal from informal conversation 
in W3C Payment Handler meetings. However Firefox have since not been 
involved in the API development.



WebKit: No signal 
(https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html 
)



Web developers: Positive 
(https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html 
) 
Support and involvement in API development from multiple web 
developers and payment industry partners. Both Stripe and AirBnB have 
publicly stated that they have either completed or are in the process 
of prototyping/experimenting with SPC





Debuggability

Existing devtools debugging features should cover SPC (e.g. 
breakpoints, console, etc)



Is this feature fully tested by web-platform-tests

?

Yes, coverage for the new input fields will be added to the existing 
test suite:


https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental 




Flag name

SecurePaymentConfirmationAPIV3


Requires code in //chrome?

Yes: minor changes to the chrome UI code, to possibly display a 
placeholder card icon when the new ‘iconMustBeShown’ option is false, 
and to render the optional payeeName alongside or instead of the 
payeeOrigin.



Tracking bug

API V3 bug: https://crbug.com/1298505 

Original feature bug: https://crbug.com/1124927 




Launch bug

Original SPC launch bug: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1236570 



We believe this is a small enough change to an existing feature that 
it doesn’t require its own launch bug.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5675682238562304 




Links to previous Intent discussions

Intent to Prototype v1: 
https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion 

Re: [blink-dev] Intent to Ship: Add Save Data Client Hint

[Ari Chivukula]

(1) Can we omit the header when the value would be `?0` (false)?

I'm fine with that, and it would be worth updating the existing client hint
standard to allow the conflation of empty/missing values in cases where
headers are sent by default. It's not worth the bytes to clarify the header
is empty, especially when it's about saving data :-P

(2) Why add this new name if we have the existing header? Can't we just
have the permission policy apply to the old name?

Chrome on Android is removing 'lite mode', which is the only case I'm aware
of which causes `Save-Data: on` to be sent. We have a chance here to add
the new name and policy, then follow up with a removal of the old name
while it's not even being sent. The removal isn't a part of this intent,
but in any case where `Sec-CH-Save-Data` is explicitly requested or the
`CH-Save-Data` policy is touched the old `Save-Data` header wouldn't be
sent at all under this intent.

~ Ari Chivukula (Their/There/They're)


On Tue, Mar 15, 2022 at 11:05 AM Mike West  wrote:

> Hey Avi!
>
> Two questions, one small, one large:
>
> First, to reduce header bloat, the approach of not sending headers by
> default whose value is `?0` seems reasonable. Fetch Metadata's 
> `Sec-Fetch-User`
> header  is
> a good example of this. Can you help me understand why that's not the right
> thing to do here?
>
> Second, and more fundamentally, if we're not planning to remove
> `Save-Data`, adding this header doesn't make much sense to me. We'll be
> adding this new header to every request alongside `Save-Data`, with the
> same value as `Save-Data`. That feels purely duplicative. Can you help me
> understand the value? (If integration with permission policy is valuable
> (and I can understand how it could be!), did you consider carving out a
> naming exception for this header, and applying the policy control to the
> `Save-Data` header? It seems like we'd have to do that anyway in order for
> the policy control to have any meaning.)
>
> -mike
>
>
> On Wed, Mar 9, 2022 at 8:26 PM Ari Chivukula  wrote:
>
>> Sorry for not including timeline info. The plan is:
>> M102 will include the new Sec-CH-Save-Data header.
>> No plan to remove the legacy Save-Data header at this moment.
>>
>>
>> On Mon, Mar 7, 2022 at 7:57 AM Ari Chivukula 
>> wrote:
>>
>>> Fixing the subject prefix, apologies.
>>>
>>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula 
>>> wrote:
>>>
 Contact emails

 aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org

 Design Doc


 https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit

 Specification

 https://wicg.github.io/savedata/

 https://wicg.github.io/client-hints-infrastructure/

 Summary

 The Sec-CH-Save-Data client hint
  indicates
 whether the user agent intends to reduce data usage. It will be sent by
 default on all requests unless the permissions policy says otherwise.



 For example, one could limit delegation of this hint via HTTP headers:

 Permissions-Policy: ch-save-data=(self, https://bar.com/)



 Or, one could limit delegation of this hint via an HTML meta tag:

 https://bar.com/)">



 Example of new HTTP header when Data Saver is on:

 Sec-CH-Save-Data: ?1



 Example of new HTTP header when Data Saver is off:

 Sec-CH-Save-Data: ?0



 Explicitly requesting Sec-CH-Save-Data or modifying the CH-Save-Data
 permissions policy will prevent the old `Save-Data` header from being
 sent. Otherwise, the old header will not be affected.



 Blink component

 Blink>Network>ClientHints
 



 Motivation

 The current `Save-Data` header is sent when a browser or operating
 system data saver setting is on (e.g., Lite mode
 )
 for all first and third party requests, lives outside the client hints
 system , and is named
 improperly
 .
 `Sec-CH-Save-Data` will be a proper client hint and its delegation to third
 parties could be prevented via permissions policies
 
 .

 TAG review

 N/A (No new data is exposed that wasn't before)

 Compatibility

 The `Save-Data` header will not be removed, so adoption of
 `Sec-CH-Save-Data` is optional.


 Interoperability

 Gecko: Client 

Re: [blink-dev] Re: Intent to Ship: MediaCapabilities API for WebRTC

['Johannes Kron' via blink-dev]

On Tue, Mar 15, 2022 at 5:38 PM jmedley via Chromestatus <
admin+jmed...@cr-status.appspotmail.com> wrote:

> In which version are you hoping to ship?
>

All code has landed except a few minor tweaks that I'm currently working on
so my goal is to ship this in M101.
Do you think that's reasonable?


> --
> 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/d119f605da446d82%40google.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/CAFJBoCS6NYZRvTmNvC0by5Gx8oMUHEARu%3DX%2BCSGKy8%3D0GMv%3Dig%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Prototype and Ship: font-palette and custom @font-palette-values palettes

[Mike West]

LGTM3.

-mike


On Tue, Mar 15, 2022 at 5:12 PM Mike Taylor  wrote:

> LGTM2
>
> On 3/15/22 11:20 AM, Yoav Weiss wrote:
>
> LGTM1 - given the early positive signal and the fact it's already shipping
> in Safari. Please follow up on any feedback from others if it comes up on
> that thread.
>
> On Tue, Mar 15, 2022 at 3:27 PM Dominik Röttsches 
> wrote:
>
>> Hi again Yoav and others,
>>
>> On Mon, Mar 14, 2022 at 5:18 PM Dominik Röttsches 
>> wrote:
>>
>>> Hi Yoav,
>>>
>>> On Thursday, March 10, 2022 at 9:18:17 AM UTC+2 yoav...@chromium.org
>>> wrote:
>>>
 Thanks for working on this! Seems like a very cool feature!! :)

 On Tuesday, March 8, 2022 at 1:44:55 PM UTC+1 Dominik Röttsches wrote:

>>>
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/617) Position
> requested in above link, tracking bug exists:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1461588
>

 As this position request is very recent, might be worthwhile to let it
 bake for a week or two.

>>>
>>> FWIW, I pinged Jonathan Kew on the Mozilla side regarding this request
>>> as well.
>>>
>>
>> I have a small update, Jonathan preliminarily commented positively
>> 
>> :
>> "Speaking for myself, I think this is a useful and uncontroversial
>> addition, allowing authors greater flexibility and control when working
>> with multi-colored fonts (such as emoji and other symbol sets, as well as
>> decorative alphabets). [...] So I think we should classify this as "worth
>> prototyping". @tantek @annevk Any additional thoughts?"
>>
>> So, I'd be happy if this could be reviewed in this week's API owners
>> meeting round.
>>
>> Thanks,
>>
>> Dominik
>>
>>
>>
> --
> 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/CAL5BFfX8T%2BB%2BvkDDz2wcyXpDbTMctZPYz5MPHnKjuxSU2aY9uA%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/5488f955-a161-2a62-d4cb-7937085bd93f%40chromium.org
> 
> .
>

-- 
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/CAKXHy%3DfndAgfWj6LAa2w6EAmBwX1yke-L1M%2B%2Bg30kzkuUZfFSw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add Save Data Client Hint

[Mike West]

Hey Avi!

Two questions, one small, one large:

First, to reduce header bloat, the approach of not sending headers by
default whose value is `?0` seems reasonable. Fetch Metadata's `Sec-Fetch-User`
header  is a
good example of this. Can you help me understand why that's not the right
thing to do here?

Second, and more fundamentally, if we're not planning to remove
`Save-Data`, adding this header doesn't make much sense to me. We'll be
adding this new header to every request alongside `Save-Data`, with the
same value as `Save-Data`. That feels purely duplicative. Can you help me
understand the value? (If integration with permission policy is valuable
(and I can understand how it could be!), did you consider carving out a
naming exception for this header, and applying the policy control to the
`Save-Data` header? It seems like we'd have to do that anyway in order for
the policy control to have any meaning.)

-mike


On Wed, Mar 9, 2022 at 8:26 PM Ari Chivukula  wrote:

> Sorry for not including timeline info. The plan is:
> M102 will include the new Sec-CH-Save-Data header.
> No plan to remove the legacy Save-Data header at this moment.
>
>
> On Mon, Mar 7, 2022 at 7:57 AM Ari Chivukula  wrote:
>
>> Fixing the subject prefix, apologies.
>>
>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula 
>> wrote:
>>
>>> Contact emails
>>>
>>> aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org
>>>
>>> Design Doc
>>>
>>>
>>> https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
>>>
>>> Specification
>>>
>>> https://wicg.github.io/savedata/
>>>
>>> https://wicg.github.io/client-hints-infrastructure/
>>>
>>> Summary
>>>
>>> The Sec-CH-Save-Data client hint
>>>  indicates whether
>>> the user agent intends to reduce data usage. It will be sent by default on
>>> all requests unless the permissions policy says otherwise.
>>>
>>>
>>>
>>> For example, one could limit delegation of this hint via HTTP headers:
>>>
>>> Permissions-Policy: ch-save-data=(self, https://bar.com/)
>>>
>>>
>>>
>>> Or, one could limit delegation of this hint via an HTML meta tag:
>>>
>>> https://bar.com/)">
>>>
>>>
>>>
>>> Example of new HTTP header when Data Saver is on:
>>>
>>> Sec-CH-Save-Data: ?1
>>>
>>>
>>>
>>> Example of new HTTP header when Data Saver is off:
>>>
>>> Sec-CH-Save-Data: ?0
>>>
>>>
>>>
>>> Explicitly requesting Sec-CH-Save-Data or modifying the CH-Save-Data
>>> permissions policy will prevent the old `Save-Data` header from being
>>> sent. Otherwise, the old header will not be affected.
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> The current `Save-Data` header is sent when a browser or operating
>>> system data saver setting is on (e.g., Lite mode
>>> )
>>> for all first and third party requests, lives outside the client hints
>>> system , and is named
>>> improperly
>>> .
>>> `Sec-CH-Save-Data` will be a proper client hint and its delegation to third
>>> parties could be prevented via permissions policies
>>> 
>>> .
>>>
>>> TAG review
>>>
>>> N/A (No new data is exposed that wasn't before)
>>>
>>> Compatibility
>>>
>>> The `Save-Data` header will not be removed, so adoption of
>>> `Sec-CH-Save-Data` is optional.
>>>
>>>
>>> Interoperability
>>>
>>> Gecko: Client Hints not yet implemented (considered non-harmful
>>> )
>>>
>>> WebKit: Client Hints not yet implemented
>>>
>>> Web developers: No feedback yet
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> Not yet, but it will be. `Save-Data` tests are here
>>> .
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1293443
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5645928215085056
>>>
>>> --
> 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/CAGpy5DLyhJURaZAKrogjcs0QEMV0-3JM0_onQOP-GjBVY2gkXQ%40mail.gmail.com
> 
> .
>

-- 
You 

[blink-dev] Re: Intent to Ship: MediaCapabilities API for WebRTC

[jmedley via Chromestatus]

In which version are you hoping to ship?

-- 
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/d119f605da446d82%40google.com.

Re: [blink-dev] Re: Intent to Prototype and Ship: font-palette and custom @font-palette-values palettes

[Mike Taylor]

LGTM2

On 3/15/22 11:20 AM, Yoav Weiss wrote:
LGTM1 - given the early positive signal and the fact it's already 
shipping in Safari. Please follow up on any feedback from others if it 
comes up on that thread.


On Tue, Mar 15, 2022 at 3:27 PM Dominik Röttsches  
wrote:


Hi again Yoav and others,

On Mon, Mar 14, 2022 at 5:18 PM Dominik Röttsches
 wrote:

Hi Yoav,

On Thursday, March 10, 2022 at 9:18:17 AM UTC+2
yoav...@chromium.org wrote:

Thanks for working on this! Seems like a very cool
feature!! :)

On Tuesday, March 8, 2022 at 1:44:55 PM UTC+1 Dominik
Röttsches wrote:



Gecko: Under consideration
(https://github.com/mozilla/standards-positions/issues/617)
Position requested in above link, tracking bug exists:
https://bugzilla.mozilla.org/show_bug.cgi?id=1461588


As this position request is very recent, might be
worthwhile to let it bake for a week or two.


FWIW, I pinged Jonathan Kew on the Mozilla side regarding this
request as well.


I have a small update, Jonathan preliminarily commented positively

:

"Speaking for myself, I think this is a useful and uncontroversial
addition, allowing authors greater flexibility and control when
working with multi-colored fonts (such as emoji and other symbol
sets, as well as decorative alphabets). [...] So I think we should
classify this as "worth prototyping". @tantek @annevk Any
additional thoughts?"

So, I'd be happy if this could be reviewed in this week's API
owners meeting round.

Thanks,

Dominik

--
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/CAL5BFfX8T%2BB%2BvkDDz2wcyXpDbTMctZPYz5MPHnKjuxSU2aY9uA%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/5488f955-a161-2a62-d4cb-7937085bd93f%40chromium.org.

[blink-dev] Re: Intent to Prototype: CSS object-view-box and object-overflow

[Camille Lamy]

Hi!

We looked at this as part of the Security & privacy review process for Web 
Platform intents, and we were wondering about the feature behavior with 
regards to iframes. Specifically, we were concerned about the potential for 
a child frame to draw custom content over its parent using this feature. Is 
something like this possible as part of the overflow mechanism? If so, we 
were concerned about the potential for spoofing.

Thanks!
Camille

On Monday, March 7, 2022 at 6:07:28 PM UTC+1 Khushal Sagar wrote:

> Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org, 
> vmp...@chromium.org
>
> Explainerhttps://github.com/w3c/csswg-drafts/issues/7058
>
> SpecificationIn Progress
>
> Summary
>
> The object-view-box and object-overflow properties allow the content for 
> replaced elements to paint outside its content-box, similar to ink overflow 
> for other elements.
>
> Blink componentBlink>CSS 
> 
>
> Motivation
>
> object-view-box and object-overflow allows the author to specify a subset 
> within an image that should draw within the content box of the target 
> replaced element. This enables an author to create an image with a custom 
> glow or shadow applied, with proper ink-overflow behavior like a CSS shadow 
> would have.
>
>
> The property will also be used to draw ink overflow for snapshots 
> generated for shared element transitions 
>  (issue 
> ).
>
> Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7058
>
> TAG reviewIn Progress (Will file one with a draft spec)
>
> TAG review statusIn Progress
>
> Risks
>
>
> Interoperability and Compatibility
>
> Risk is minimal. This is a new feature for which support can be detected 
> by developers. 
>
> Gecko: Positive (see comment here 
> ). 
> Will file a request for position with a draft spec (see comment here 
> 
> ).
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> This is debuggable similar to other CSS object-* properties.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> Flag nameCSSObjectViewBox
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1303102
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5213032857731072
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
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/af5057b2-9d20-45b8-8196-93e12836e54an%40chromium.org.

[blink-dev] Re: Intent to Prototype and Ship: font-palette and custom @font-palette-values palettes

[Yoav Weiss]

LGTM1 - given the early positive signal and the fact it's already shipping
in Safari. Please follow up on any feedback from others if it comes up on
that thread.

On Tue, Mar 15, 2022 at 3:27 PM Dominik Röttsches 
wrote:

> Hi again Yoav and others,
>
> On Mon, Mar 14, 2022 at 5:18 PM Dominik Röttsches 
> wrote:
>
>> Hi Yoav,
>>
>> On Thursday, March 10, 2022 at 9:18:17 AM UTC+2 yoav...@chromium.org
>> wrote:
>>
>>> Thanks for working on this! Seems like a very cool feature!! :)
>>>
>>> On Tuesday, March 8, 2022 at 1:44:55 PM UTC+1 Dominik Röttsches wrote:
>>>
>>

 Gecko: Under consideration (
 https://github.com/mozilla/standards-positions/issues/617) Position
 requested in above link, tracking bug exists:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1461588

>>>
>>> As this position request is very recent, might be worthwhile to let it
>>> bake for a week or two.
>>>
>>
>> FWIW, I pinged Jonathan Kew on the Mozilla side regarding this request as
>> well.
>>
>
> I have a small update, Jonathan preliminarily commented positively
> 
> :
> "Speaking for myself, I think this is a useful and uncontroversial
> addition, allowing authors greater flexibility and control when working
> with multi-colored fonts (such as emoji and other symbol sets, as well as
> decorative alphabets). [...] So I think we should classify this as "worth
> prototyping". @tantek @annevk Any additional thoughts?"
>
> So, I'd be happy if this could be reviewed in this week's API owners
> meeting round.
>
> Thanks,
>
> Dominik
>
>
>

-- 
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/CAL5BFfX8T%2BB%2BvkDDz2wcyXpDbTMctZPYz5MPHnKjuxSU2aY9uA%40mail.gmail.com.

[blink-dev] Re: Intent to Prototype and Ship: font-palette and custom @font-palette-values palettes

[Dominik Röttsches]

Hi again Yoav and others,

On Mon, Mar 14, 2022 at 5:18 PM Dominik Röttsches  wrote:

> Hi Yoav,
>
> On Thursday, March 10, 2022 at 9:18:17 AM UTC+2 yoav...@chromium.org
> wrote:
>
>> Thanks for working on this! Seems like a very cool feature!! :)
>>
>> On Tuesday, March 8, 2022 at 1:44:55 PM UTC+1 Dominik Röttsches wrote:
>>
>
>>>
>>> Gecko: Under consideration (
>>> https://github.com/mozilla/standards-positions/issues/617) Position
>>> requested in above link, tracking bug exists:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1461588
>>>
>>
>> As this position request is very recent, might be worthwhile to let it
>> bake for a week or two.
>>
>
> FWIW, I pinged Jonathan Kew on the Mozilla side regarding this request as
> well.
>

I have a small update, Jonathan preliminarily commented positively

:
"Speaking for myself, I think this is a useful and uncontroversial
addition, allowing authors greater flexibility and control when working
with multi-colored fonts (such as emoji and other symbol sets, as well as
decorative alphabets). [...] So I think we should classify this as "worth
prototyping". @tantek @annevk Any additional thoughts?"

So, I'd be happy if this could be reviewed in this week's API owners
meeting round.

Thanks,

Dominik

-- 
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/CAN6muBt%3DMaMKbioG63Sw-kp94twCFdY8%3D5Ofb%2BnEBY6rXiD4cA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

['Kouhei Ueno' via blink-dev]

Hi,

While we are discussing, we would like to continue the incremental roll out
of the feature to non-Stable channels. As of now, we are testing out the
feature on 60% of Dev/Canary channels, and 60% of Beta channels. The
rollout is limited to Android Chrome (limitation of the current
implementation).

We expect the rollout to affect at most a tiny fraction of the Internet
traffic generated by Chrome. The population of the Beta/Dev/Canary channels
combined is less than a few percent of Stable population, and the
navigation subject to prerendering on Prerendering-enabled Chrome is less
than a percent.

Let me try to summarize the state of the discussion here (including the
questions we’ve received out-of-band).

Q: Do you offer an opt-out mechanism to developers?

A: Yes. The opt-out mechanism is now covered in this section

of the explainer.

Q: What can we do about prerender breaking “switch to already open tab” on
WhatsApp?

A: We are updating the BroadcastChannel interaction [spec
, implementation
]. In
addition, we are delaying ServiceWorker#postMessage too, to address a
similar issue [crbug ]

Q: Can Enterprise disable the feature by a policy?

A: Yes - we respect the existing NetworkPredictionOptions
 group
policy.

Q: What is the status of https://github.com/whatwg/html/issues/7533?

A: The issue is a general “call for feedback” issue. Individual issues are
tracked on wicg/nav-speculation issue tracker
.

Q: Since prerendering risks breaking certain websites, what are the
mitigation measures planned?

A:

Prerendering is not entirely new. It used to be available in Chrome M13
until M63 and has been available in many other browsers such as: Safari
since at least 2014
,
Opera from 2017
,
and more recently launched in Edge. We assume that the risk of breakage is
relatively low given these pre-existing conditions. That said, we will
remain prudent while relaunching this feature.


   1.

   Take a slow and transparent approach to our rollout:
   1.

  We’ll be careful around ramping up the experiment group population
  that we will be monitoring the metrics and user reports closely.
  2.

  We’ll also be transparent about the rollout config on this blink-dev
  thread.
  3.

  We’ll be keeping in touch with various partners to ensure that
  everything is good on their end.
  2.

   Before going to Stable, we’ll publish a heads-up article on one of our
   blogs with the following content:
   1.

  What’s being experimented with (e.g. prerendering on Chrome for
  Android from the Omnibox)
  2.

  Things to know about this feature (e.g. how it triggers, how it
  manifests itself, how it works)
  3.

  How to do hands-on testing, what to do if something breaks (e.g.
  opt-out), how to share feedback to help us get this right.
  3.

   Being as conservative as other prerendering browsers (such as Edge and
   Safari), as well as having the following extra mitigations:
   1.

  Allowing developers to opt-outs.
  2.

  Disabling prerendering on features known to be problematic or
  surprising (e.g. BroadcastChannel, Media, and Sensor APIs)


--

Kouhei, on behalf of the Prerender2 team


On Mon, Feb 21, 2022 at 1:48 AM Coco Trana  wrote:

>
> El dom., 20 de febrero de 2022 3:34 a. m., Noam Rosenthal <
> noam.j.rosent...@gmail.com> escribió:
>
>>
>>
>> On Sun, Feb 20, 2022 at 12:10 PM Jacob G  wrote:
>>
>>> Maybe a weird side-effect, but think of web.whatsapp.com: You have the
>>> tab open already, open a new tab, enter web.whatsapp.com, so you'll get
>>> an action item in the omnibox to switch to the already open tab - but with
>>> prerendering this leads to web.whatsapp.com showing you've opened the
>>> site in a new tab (even though you didn't - it got prerendered), making the
>>> "switch to already open tab" suggestion useless.
>>> Is this something site maintainers will have to fix or on the chromium
>>> side? (Prerendering interaction with already open tabs)
>>>
>> This is exactly the open issue discussed here:
>> https://github.com/WICG/nav-speculation/issues/141
>> We want the default behavior to not create unexpected behavior such as
>> the ones you've described.
>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop 

Re: [blink-dev] Intent to Ship: MediaCapabilities API for WebRTC

[Yoav Weiss]

On Tue, Mar 15, 2022 at 9:22 AM Johannes Kron  wrote:

> Thank you Mike and Yoav for your feedback!
>
> I accidentally responded with Reply to sender instead of Reply all. Trying
> again, see my response below.
>
>
> On Mon, Mar 14, 2022 at 6:33 PM Mike Taylor 
> wrote:
>
>> On 3/14/22 1:30 PM, 'Johannes Kron' via blink-dev wrote:
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020)
>>
>> Could you please request a more formal position at
>> https://github.com/mozilla/standards-positions?
>>
> I've filed a request for a formal position here,
> https://github.com/mozilla/standards-positions/issues/619
>
>
> On Mon, Mar 14, 2022 at 7:55 PM Yoav Weiss  wrote:
>
>> On Monday, March 14, 2022 at 6:33:31 PM UTC+1 Mike Taylor wrote:
>>
>>> On 3/14/22 1:30 PM, 'Johannes Kron' via blink-dev wrote:
>>>
>>> Contact emails k...@google.com
>>>
>>> Explainer
>>> https://github.com/drkron/media-capabilities/blob/webrtc_examples/explainer.md#webrtc
>>> https://github.com/w3c/media-capabilities/pull/191
>>>
>>> Specification https://w3c.github.io/media-capabilities/
>>>
>>> Summary
>>>
>>> Extends the MediaCapabilities API to support WebRTC streams. The
>>> MediaCapabilities API helps websites to make informed decisions on what
>>> codec, resolution, etc. to use for video playback by providing information
>>> about whether a configuration is supported and also whether the playback is
>>> expected to be smooth. This feature extends the MediaCapabilities API to
>>> also include WebRTC streams.
>>>
>>>
>>> Blink component Blink>Media>Capabilities
>>> 
>>>
>>> TAG review This is a straightforward extension of an existing API.
>>>
>>> That's not the right reason for this being exempt from a TAG review. I
>> think that a TAG review is not needed because this was accepted in the WG
>> and there's already another browser engine shipping this.
>> At the same time, seems worthwhile to at least file an FYI TAG review
>> issue.
>>
>
> I agree that those are better reasons for not doing a full TAG review.
> I've filed a FYI TAG review issue as you requested, see
> https://github.com/w3ctag/design-reviews/issues/720
> I hope that this is treated as a FYI and is not blocking the Intent to
> Ship?
>

It indeed shouldn't be a blocker.


>
>
>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020
>>> )
>>>
>>> Could you please request a more formal position at
>>> https://github.com/mozilla/standards-positions?
>>>
>>>
>>> WebKit: Shipped/Shipping (
>>> https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/
>>> )
>>>
>>> Web developers: No signals
>>>
>>> Any signals from web developers? https://goo.gle/developer-signals
>>
>
>  This should have been N/A. Due to the strong support from the working
> group I didn't see a reason to do an outreach to web developers, especially
> since this is a relatively straightforward extension of the existing API.
>

-- 
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/CAL5BFfXDkhJBqm8ZrSuJC%3DYzK3MABOdwDgm182y7fu52fhFb9A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: MediaCapabilities API for WebRTC

['Johannes Kron' via blink-dev]

Thank you Mike and Yoav for your feedback!

I accidentally responded with Reply to sender instead of Reply all. Trying
again, see my response below.


On Mon, Mar 14, 2022 at 6:33 PM Mike Taylor  wrote:

> On 3/14/22 1:30 PM, 'Johannes Kron' via blink-dev wrote:
>
> Risks
>
>
> Interoperability and Compatibility
>
> Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020)
>
> Could you please request a more formal position at
> https://github.com/mozilla/standards-positions?
>
I've filed a request for a formal position here,
https://github.com/mozilla/standards-positions/issues/619


On Mon, Mar 14, 2022 at 7:55 PM Yoav Weiss  wrote:

> On Monday, March 14, 2022 at 6:33:31 PM UTC+1 Mike Taylor wrote:
>
>> On 3/14/22 1:30 PM, 'Johannes Kron' via blink-dev wrote:
>>
>> Contact emails k...@google.com
>>
>> Explainer
>> https://github.com/drkron/media-capabilities/blob/webrtc_examples/explainer.md#webrtc
>> https://github.com/w3c/media-capabilities/pull/191
>>
>> Specification https://w3c.github.io/media-capabilities/
>>
>> Summary
>>
>> Extends the MediaCapabilities API to support WebRTC streams. The
>> MediaCapabilities API helps websites to make informed decisions on what
>> codec, resolution, etc. to use for video playback by providing information
>> about whether a configuration is supported and also whether the playback is
>> expected to be smooth. This feature extends the MediaCapabilities API to
>> also include WebRTC streams.
>>
>>
>> Blink component Blink>Media>Capabilities
>> 
>>
>> TAG review This is a straightforward extension of an existing API.
>>
>> That's not the right reason for this being exempt from a TAG review. I
> think that a TAG review is not needed because this was accepted in the WG
> and there's already another browser engine shipping this.
> At the same time, seems worthwhile to at least file an FYI TAG review
> issue.
>

I agree that those are better reasons for not doing a full TAG review. I've
filed a FYI TAG review issue as you requested, see
https://github.com/w3ctag/design-reviews/issues/720
I hope that this is treated as a FYI and is not blocking the Intent to Ship?


> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020)
>>
>> Could you please request a more formal position at
>> https://github.com/mozilla/standards-positions?
>>
>>
>> WebKit: Shipped/Shipping (
>> https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/
>> )
>>
>> Web developers: No signals
>>
>> Any signals from web developers? https://goo.gle/developer-signals
>

 This should have been N/A. Due to the strong support from the working
group I didn't see a reason to do an outreach to web developers, especially
since this is a relatively straightforward extension of the existing API.

-- 
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/CAFJBoCQeF9DbkF_MmBB-JwhYbiogVYAQVkaPrVK_d2OTv-PV4A%40mail.gmail.com.