Re: [blink-dev] Re: List decorators on Chrome Status

['Joe Medley' via blink-dev]

It's not just for V8 features, but all features. There won't be an entry on
Chrome Status until someone is actually working on it.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jan 12, 2023 at 3:28 PM Joe Pea (Joseph Orbegoso Pea) <
trus...@gmail.com> wrote:

> > My best guess would be https://github.com/tc39/proposal-decorators
>
> Yes indeed that's what I was asking about.
>
> > that'd be a V8 question, not a Blink question
>
> That makes sense. The "Discuss" link in the footer of the chromestatus.com
> site links to this group.
>
> On Wednesday, January 11, 2023 at 8:03:28 AM UTC-8 km...@chromium.org
> wrote:
>
>> My best guess would be https://github.com/tc39/proposal-decorators, but
>> that'd be a V8 question, not a Blink question.
>>
>> On Wed, Jan 11, 2023 at 7:43 AM 'Jason Robbins' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> What do you mean by "decorators"?
>>>
>>> On Tuesday, January 10, 2023 at 5:54:04 PM UTC-8 tru...@gmail.com wrote:
>>>
 I don't see "decorators" at https://chromestatus.com/newfeatures. Can
 we add it? - Joe
>>>
>>> --
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6c78d37-9b9c-4e01-b4dd-0c5704ce920cn%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/9ae955f6-f7d9-4f10-9e26-0211e5661b42n%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/CAJUhtG_PaKbOnKV9RCS39orRn%3Dv13QOnv7SvGra%2BeDp602EQ4g%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

['Joe Medley' via blink-dev]

Thanks.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Nov 8, 2022 at 4:56 AM Elad Alon  wrote:

> This is shipping in m109.
>
> On Wednesday, June 22, 2022 at 7:20:42 PM UTC+2 Elad Alon wrote:
>
>> When I have an exact date, I will update ChromeStatus and ping this
>> thread with the target. Currently, I only know that it will be before EoY,
>> but no earlier than August.
>>
>> On Wed, Jun 22, 2022 at 7:16 PM Joe Medley  wrote:
>>
>>> When do you hope to ship this?
>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Wed, Jun 22, 2022 at 9:14 AM Daniel Bratell 
>>> wrote:
>>>
 LGTM3

 /Daniel
 On 2022-06-22 17:42, Yoav Weiss wrote:

 LGTM2

 On Wednesday, June 22, 2022 at 5:41:51 PM UTC+2 Chris Harrelson wrote:

> LGTM1
>
> On Tue, Jun 14, 2022 at 4:11 AM 'Andy Paicu' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Sounds good, thank you for the clarifications.
>>
>> Kind Regards,
>> Andy Paicu
>>
>>
>> On Mon, Jun 13, 2022 at 8:18 PM Elad Alon  wrote:
>>
>>> Hi Andy,
>>>
>>> How does the capturing web app (i.e. Meet) know what I want to do
 with audio?
>>>
>>>
>>> The capturing application might know that you're in a physical room
>>> and "presenting" to the equipment there.
>>>
>>>- You use a special user-journey to trigger sharing to a room.
>>>- The application could be "watermarking" audio coming in
>>>through the room's speakers.
>>>- You might have indicated a desire to suppress-local-audio
>>>through in-content controls the application exposes.
>>>
>>> In either case, it is extremely likely that you only want to hear
>>> the audio only through one set of speakers. The application would be 
>>> saving
>>> you effort by muting one set of speakers for you.
>>>
>>> This seems like it would be better under the control of the user
>>>
>>>
>>> Users can mute tabs manually. This new API surface will not prevent
>>> this.
>>>
>>> i.e. Meet
>>>
>>>
>>> It bears mentioning that Meet is currently using screen-sharing
>>> through an API which I am trying to deprecate. That API already 
>>> hard-codes
>>> to *always* suppress-local-audio on a captured tab. The present new
>>> API surface improves on the state of the art by (i) making this 
>>> conditional
>>> and (ii) exposing it to the Web at large.
>>>
>>> Thanks,
>>> Elad
>>>
>>> On Mon, Jun 13, 2022 at 8:02 PM Andy Paicu 
>>> wrote:
>>>
 A question came up when reviewing this, I'm hoping you can help
 clarify:

 How does the capturing web app (i.e. Meet) know what I want to do
 with audio? Would I not be able to achieve the same result by simply 
 muting
 the tab or even just muting the device (since it seems unlikely that 
 there
 are other sounds wanted from the local device when sharing a tab with
 audio)?

 This seems like it would be better under the control of the user
 instead of being a decision made by the application especially since I
 don't see a mention of how this would be presented to the user and/or
 potentially reverted by them.

 Kind Regards,
 Andy Paicu

 On Wednesday, June 1, 2022 at 9:40:02 AM UTC+2 Elad Alon wrote:

> Similar to other intents, this doesn't count as an official
>> positive signal. Let's wait a few days to see if one emerges.
>
>
> Thanks. I've set a reminder to ping this thread in one week, as
> suggested in the other intent thread.
>
> On Wed, Jun 1, 2022 at 8:42 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wednesday, May 25, 2022 at 2:44:01 PM UTC+2 Elad Alon wrote:
>>
>>> Contact emails elad...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing
>>>
>>> Specification
>>> https://github.com/w3c/mediacapture-screen-share/pull/164/files
>>>
>>> Summary
>>>
>>> Consider a Web application APP which is display-capturing a tab
>>> TAB. We add a mechanism by which APP may control whether the audio 
>>> playing
>>> in TAB would be played out of the user’s local speakers.
>>>
>>>
>>> Blink component Blink
>>> 
>>>
>>> TAG review N/A. This is just an addition of a 

Re: [blink-dev] Intent to Ship: WebXR Raw Camera Access

['Joe Medley' via blink-dev]

Is this shipping in 106 or 107?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Aug 31, 2022 at 10:23 AM Alex Cooper  wrote:

> Thanks Everyone! I've gone ahead and merged PR15 and Piotr will work on
> the change to enable this!
>
> On Wed, Aug 31, 2022 at 7:03 AM Yoav Weiss  wrote:
>
>> LGTM3
>>
>> On Fri, Aug 26, 2022 at 3:13 PM Mike Taylor 
>> wrote:
>>
>>> LGTM2 - thanks for improving the explainer in
>>> https://github.com/immersive-web/raw-camera-access/pull/15/files.
>>>
>>> On 8/24/22 6:25 PM, Chris Harrelson wrote:
>>>
>>> LGTM1 to ship. In my view, the revised explainer is enough, and the
>>> feature received a thorough going-over with the TAG.
>>>
>>> Side note: I greatly appreciate the team's responsiveness in discussions
>>> with the TAG and in this thread.
>>>
>>> On Wed, Aug 24, 2022 at 8:55 AM Alex Russell 
>>> wrote:
>>>
 Hey Alex,

 I'd like to approve this ASAP, but the explainer is still lacking
 critical detail about considered alternatives and some aspects of how the
 design is going to stay in sync with the options that are available for
 getUserMedia().

 Best,

 Alex

 On Tuesday, August 23, 2022 at 1:11:35 PM UTC-7 Alexander Cooper wrote:

> Thanks Alex,
>
> I believe I've responded to all of your questions on the github
> thread, but I still had a few follow up clarifications. We'd been hoping 
> to
> get this out in M106, but since that has already branched I definitely 
> want
> to make sure we can get this out in M107.
>
> Thanks,
> Alex Cooper
>
> On Fri, Aug 12, 2022 at 4:49 PM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> I've left some questions about the design in an issue here:
>> https://github.com/immersive-web/raw-camera-access/issues/14
>>
> --
>> 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/31066705e613ef2f%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/6810925e-7d33-45f2-bc12-13563340101fn%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/CAOMQ%2Bw8dRgwg%3D%3D8mDkapu6AEyxyxTkK5ciDa4-94YvB3HBNaqA%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/7ae81c1d-db41-d3cc-09bf-6bc9bd4b1cdf%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/CAGOLbz1vpxiP%3Dj3ceSFNcq%3DEg6tAWYNsteue%3DQbHPvz%2BZHqMcw%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 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

I think you did everything as right as anyone could. Chrome Status is a bit
confusing when it comes to shipping milestones and flags.

The only thing required for a finch experiment is the "Finch experiment:"
field, which takes a CR bug. Edit your feature, click "Edit all fields",
then search for the field.

Anyone who might be reading this who works on a web platform feature should
stop reading this now. What I'm about to say doesn't apply to you.

What's the rollout schedule for your finch flag? Will this be available to
100% of Chrome users by the time 105 reaches stable (Aug 30)? I'm trying to
work out what you need to put in the milestone fields. I need more
information to do that.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Aug 24, 2022 at 7:17 AM Angel Raposo  wrote:

> Hi Joe,
>
> We started the beta behind a finch flag with m105.
> Can you point me out to where I need to replace the DevTile milestone? I'm
> quite new on the role, helping the team on a 20% capacity so I may have
> misconfigured something in the Chromestatus entry before generating this
> template?
>
> Thanks,
> Angel.
>
> On Tue, Aug 23, 2022 at 11:49 PM Joe Medley  wrote:
>
>> I think I know why I'm confused, please tell me if this is correct. Did
>> you label this as being behind a flag (DevTrial) because it's under a Finch
>> flag? The DevTile milestone fields do not apply to finch flags.
>>
>> In which version of beta did the Finch experiment start?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo 
>> wrote:
>>
>>> Hi Joe,
>>>
>>> Thanks for your questions, Let me share some background of the project
>>> situation:
>>>
>>> Prerender loads and renders high-likely to be visited web pages before
>>> the user actually navigates to them, based on different triggers.
>>> We've already launched a few triggers for Android in stable, e.g.:
>>>
>>>- *Direct URL Input
>>>
>>> 
>>>  (M101)*:
>>>as the user types the address in the Omnibar, the browser may choose to
>>>prerender a particular site if the user is very likely to browse it. This
>>>is fully approved and already active in stable for a small percentage of
>>>users and we are ramping up.
>>>- *Speculation rules
>>> (M103)*:
>>>site owners can hint pages, through the speculation rules API, that users
>>>are likely going to browse next. This is fully launched on stable for
>>>Android
>>>
>>> With this I2S, we are aiming to launch Prerender2 for Desktop which will
>>> enable the same approved triggers for Desktop.
>>> We already got the approval for beta
>>> , which
>>> is under a finch experiment right now with a percentage of users testing
>>> with positive results.
>>>
>>> Once we get the approval for stable, we'll work on a roll-out plan,
>>> incrementing slowly the percentage of users adopting the new feature.
>>>
>>> Thanks,
>>> Angel.
>>>
>>>
>>> On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:
>>>
 Angel,

 Can you please clarify a few things for me. I'm trying to work out
 whether this is eligible for listing in the beta announcement
 .

 You said this shipped in Android already. I only see that it is behind
 a flag in Android. When was this enabled by default? The beta announcement
 doesn't include items that require enabling via the command line or an item
 in chrome://flags. (This is what 'developer trial' refers to.) Items that
 are enabled by default are included whether a flag is present or not.

 Given that information, can you please tell me what you're doing on
 desktop?

 Also, did you mean to say you were shipping in 105? It goes to stable
 in 8 days. Wouldn't you want this to be in beta first?

 Thanks,
 Joe
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped
> only on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

I think I know why I'm confused, please tell me if this is correct. Did you
label this as being behind a flag (DevTrial) because it's under a Finch
flag? The DevTile milestone fields do not apply to finch flags.

In which version of beta did the Finch experiment start?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo  wrote:

> Hi Joe,
>
> Thanks for your questions, Let me share some background of the project
> situation:
>
> Prerender loads and renders high-likely to be visited web pages before the
> user actually navigates to them, based on different triggers.
> We've already launched a few triggers for Android in stable, e.g.:
>
>- *Direct URL Input
>
> 
>  (M101)*:
>as the user types the address in the Omnibar, the browser may choose to
>prerender a particular site if the user is very likely to browse it. This
>is fully approved and already active in stable for a small percentage of
>users and we are ramping up.
>- *Speculation rules
> (M103)*:
>site owners can hint pages, through the speculation rules API, that users
>are likely going to browse next. This is fully launched on stable for
>Android
>
> With this I2S, we are aiming to launch Prerender2 for Desktop which will
> enable the same approved triggers for Desktop.
> We already got the approval for beta
> , which is
> under a finch experiment right now with a percentage of users testing with
> positive results.
>
> Once we get the approval for stable, we'll work on a roll-out plan,
> incrementing slowly the percentage of users adopting the new feature.
>
> Thanks,
> Angel.
>
>
> On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:
>
>> Angel,
>>
>> Can you please clarify a few things for me. I'm trying to work out
>> whether this is eligible for listing in the beta announcement
>> .
>>
>> You said this shipped in Android already. I only see that it is behind a
>> flag in Android. When was this enabled by default? The beta announcement
>> doesn't include items that require enabling via the command line or an item
>> in chrome://flags. (This is what 'developer trial' refers to.) Items that
>> are enabled by default are included whether a flag is present or not.
>>
>> Given that information, can you please tell me what you're doing on
>> desktop?
>>
>> Also, did you mean to say you were shipping in 105? It goes to stable in
>> 8 days. Wouldn't you want this to be in beta first?
>>
>> Thanks,
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> Summary
>>>
>>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>>> Web page before the user actually navigates to it. The main goal of
>>> prerendering is to make the next page navigation faster, or ideally nearly
>>> instant.
>>>
>>> Sites can inform the user agent about which pages the user may likely
>>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>>> user is at page A and will likely navigate to page B next). Once the
>>> prerender is triggered, the browser pre-fetches the main resource,
>>> instantiates a hidden page, and processes the main resource to fetch and
>>> process more subresources.
>>>
>>> After shipping Prerender2 for Android (I2S speculation rules triggered
>>> Prerender2
>>> 
>>> and I2S for Omnibox triggered Prerender2
>>> ),
>>> we are now requesting approval to ship Prerender2 for Desktop. This release
>>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>>
>>> With this feature, Chrome (Desktop) will start prerendering
>>> high-confidence URL suggestions provided by the page using speculation
>>> rules or directly by Omnibox. During the prerendering 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

Angel,

Can you please clarify a few things for me. I'm trying to work out whether
this is eligible for listing in the beta announcement
.

You said this shipped in Android already. I only see that it is behind a
flag in Android. When was this enabled by default? The beta announcement
doesn't include items that require enabling via the command line or an item
in chrome://flags. (This is what 'developer trial' refers to.) Items that
are enabled by default are included whether a flag is present or not.

Given that information, can you please tell me what you're doing on desktop?

Also, did you mean to say you were shipping in 105? It goes to stable in 8
days. Wouldn't you want this to be in beta first?

Thanks,
Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped only
> on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
> Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can inform the user agent about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> After shipping Prerender2 for Android (I2S speculation rules triggered
> Prerender2
> 
> and I2S for Omnibox triggered Prerender2
> ),
> we are now requesting approval to ship Prerender2 for Desktop. This release
> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>
> With this feature, Chrome (Desktop) will start prerendering
> high-confidence URL suggestions provided by the page using speculation
> rules or directly by Omnibox. During the prerendering process, a page will
> process and construct the full DOM tree, including the execution of scripts
> (this differs from No-state Prefetch
> 
> which only prefetches resources and doesn’t execute scripts).
>
> Note that we are not shipping cross-origin prerendering, which allows a
> web page to prerender another page on a different origin.
>
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> All issues have been addressed.
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android.
>
> We believe that some browsers already have prerendering implementations
> which are not specified and may differ from each other, or not always
> exposed to the platform. Our vision is to produce a specification that can
> help improve interoperability. There is a risk that other browsers do not
> converge on a prerendering standard but we hope that we’ll be able to
> address legitimate concerns if any are raised by interested parties.
>
> Compatibility risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android. There are
> some use cases that will need to know whether a page is being prerendered
> by the user agent or navigated by the user, e.g. ads and analytics are
> likely examples of this which are supported by already launched features
> such as `document.prerendering` which lets a page know that it’s being
> prerendered.
>
> Chrome Extensions have abilities to interact with web contents and have
> widely used API surfaces. We’ve been keeping in mind compatibility with
> Extensions’ compatibility, including giving enough capability for
> Extensions to properly support Prerender2 [1].
>
> A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on
> a deprecation path. In the meantime, given that NaCl 

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

['Joe Medley' via blink-dev]

So it will be disabled by default in 106 then?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 15, 2022 at 8:13 AM Brad Lassey  wrote:

> I believe Ian's timeline suggestion was to disable on trunk this week and
> let it ride to stable in m106.
>
> -Brad
>
>
> On Mon, Aug 15, 2022 at 10:39 AM Joe Medley  wrote:
>
>> Ryan,
>>
>> What's the planned schedule for deprecation and removal?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>>
>>> Howdy Chris, et al,
>>>
>>> Early Hints launched to Stable in M103. As such we would like to revive
>>> this Intent to Remove HTTP/2 Server Push.
>>>
>>> Cheers,
>>>
>>> Ryan
>>>
>>> On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson 
>>> wrote:
>>>
 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 
 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  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 responses for 3/4
>> of a decade now, so we might implement Webpush Protocol or other similar
>> reactive techniques via using Push. There have been a couple explorations
>> of this, but after a series of proposals, nothing has materialized, 
>> nothing
>> has developed. Rather than ever making PUSH useful, rather than 
>> acknowledge
>> that PUSH could implement a reactive, Webpush Protocl like system, you 
>> seem
>> intent on using negligence to destroy the baby before it has a chance. 
>> This
>> has been requested & begged for, 

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

['Joe Medley' via blink-dev]

Ryan,

What's the planned schedule for deprecation and removal?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:

> Howdy Chris, et al,
>
> Early Hints launched to Stable in M103. As such we would like to revive
> this Intent to Remove HTTP/2 Server Push.
>
> Cheers,
>
> Ryan
>
> On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson 
> wrote:
>
>> 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 
>> 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  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 responses for 3/4
 of a decade now, so we might implement Webpush Protocol or other similar
 reactive techniques via using Push. There have been a couple explorations
 of this, but after a series of proposals, nothing has materialized, nothing
 has developed. Rather than ever making PUSH useful, rather than acknowledge
 that PUSH could implement a reactive, Webpush Protocl like system, you seem
 intent on using negligence to destroy the baby before it has a chance. This
 has been requested & begged for, there's been a couple spins, but you seem
 ready to destroy possibility in this deprecation, before even having made
 the most minimum bid to make the technology useful. Please, heed
 https://github.com/whatwg/fetch/issues/51 & try to do some little bit
 of good in the world, before you go running off macabely destroying
 possibility.

 Chrome had a number of attempts where some good responsible smart
 actually-know-something developers saw that PUSH could be useful, and
 proposed trying to make Fetch spec be useful, proposed making PUSH useful.
 That the current crop of developers doesn't understand & see this
 possibility, either 

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

['Joe Medley' via blink-dev]

What's the intended milestone for this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:

> Howdy Chris, et al,
>
> Early Hints launched to Stable in M103. As such we would like to revive
> this Intent to Remove HTTP/2 Server Push.
>
> Cheers,
>
> Ryan
>
> On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson 
> wrote:
>
>> 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 
>> 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  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 responses for 3/4
 of a decade now, so we might implement Webpush Protocol or other similar
 reactive techniques via using Push. There have been a couple explorations
 of this, but after a series of proposals, nothing has materialized, nothing
 has developed. Rather than ever making PUSH useful, rather than acknowledge
 that PUSH could implement a reactive, Webpush Protocl like system, you seem
 intent on using negligence to destroy the baby before it has a chance. This
 has been requested & begged for, there's been a couple spins, but you seem
 ready to destroy possibility in this deprecation, before even having made
 the most minimum bid to make the technology useful. Please, heed
 https://github.com/whatwg/fetch/issues/51 & try to do some little bit
 of good in the world, before you go running off macabely destroying
 possibility.

 Chrome had a number of attempts where some good responsible smart
 actually-know-something developers saw that PUSH could be useful, and
 proposed trying to make Fetch spec be useful, proposed making PUSH useful.
 That the current crop of developers doesn't understand & see this
 possibility, either denies or is ignorant to the 

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

['Joe Medley' via blink-dev]

Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 10:06 PM Minoru Chikamune 
wrote:

> >> Where's the status entry for this?
> > I'll create a chrome status entry. Thank you for pointing this out.
>
> I've created a chrome status entry.
> https://chromestatus.com/guide/edit/5104987642789888
>
>
> On Tue, Aug 2, 2022 at 10:06 AM Minoru Chikamune 
> wrote:
>
>> > A change of schedule doesn't really qualify as an experiment extension.
>> My LGTM from the previous intent
>>  still
>> stands.
>>
>> Oh, I see.
>>
>> > Where's the status entry for this?
>>
>> I'll create a chrome status entry. Thank you for pointing this out.
>>
>>
>> On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:
>>
>>> Where's the status entry for this?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss 
>>> wrote:
>>>
 A change of schedule doesn't really qualify as an experiment extension.
 My LGTM from the previous intent
 
 still stands.

 On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune <
 chikam...@chromium.org> wrote:

> *Contact emails*
>
> chikam...@chromium.org, sisidov...@chromium.org
>
> Explainer:
>
>-
>
>https://github.com/nyaxt/lazyembeds
>
>
> Specification: https://github.com/nyaxt/lazyembeds
>
> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
> outside the viewport when all of the following conditions are met.
>
>
>-
>
>The loading=eager or loading=lazy attribute values are not
>specified in the iframe tag.
>
>
>-
>
>The iframe's src URL matches a pre-curated list of cross-origin
>embeds (for the sake of quick experimentation).
>
>
>-
>
>The page is visible.
>-
>
>The iframe's src URL must be cross origin.
>-
>
>The main frame is not loaded in the following ways. In the
>following operations, the user probably wants to avoid any breakage 
> caused
>by LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>
>
> LazyEmbeds has a timeout mechanism that loads all the iframes that are
> eligible for LazyEmbeds after a few seconds have elapsed even when the
> viewport doesn't come near the iframe. This timeout mechanism is the main
> difference between  LazyEmbeds and .
>
> Site authors can specify loading=eager on frames to opt-out of
> LazyEmbeds.
>
> The current LazyEmbeds implementations target a 1% stable channel for
> data gathering purposes. We don't have any plan to release LazyEmbeds in
> its current form. This experiment is to help us assess the potential
> impact, in order to motivate a proper, launchable, design.
>
> Blink component: Blink>Loader
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability and Compatibility
>
> The goal of the experiment is to test if the idea actually improves
> page load UX. Once that is proven, we would like to start pitching in the
> standardization forum on having the new behavior part of the spec.
>
> We have a rough sketch of how it would look like in terms of
> specification changes at https://github.com/nyaxt/lazyembeds.
> LazyEmbeds applies a different loading schedule to offscreen cross-origin
> s. Site authors who believe offscreen content is a critical part 
> of
> the user-experience may find this breaks their expectations. To restore 
> the
> previous behavior, authors can specify loading=eager on those frames.
>
> Ergonomics
>
> Websites don’t have to do anything.
>
> Activation
>
> LazyEmbeds works without any developer activation.
>
> Security and privacy
>
> LazyEmbeds doesn't have any security and privacy concerns.
>
> Goals for experimentation
>
> We would like to judge if this is a good idea or not before we would
> like to validate our hypothesis using the performance data (e.g. Core Web
> Vitals) collected through the experiment before we proceed to the next
> steps (open-ended discussion with other vendors, involved 3rd-parties).
>
> Reason this experiment is being extended
>
> The previous timeline was to start an 

Re: [blink-dev] Intent to Ship: MSE in Workers

['Joe Medley' via blink-dev]

Gang,

NOTE: Requested desktop and Android ship milestone: 105 (The 'edit
> estimated milestones' link from chromestatus didn't result in such ability
> to edit, so I'm adding this request explicitly here.)


I'm looking into this and will report back. Has anyone else noticed this
problem?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 8:52 AM Mike Taylor  wrote:

> LGTM3
>
> On 8/1/22 8:05 AM, Yoav Weiss wrote:
>
> LGTM2
>
> On Fri, Jul 29, 2022 at 12:40 AM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> LGTM1
>> --
>> 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/eea04c05e4e53819%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/CAL5BFfWsqYRjB%3DqCuu4UxHzEa%2B%2B2SqkDJdE8W8sUNCnS%2BwoH5w%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/91d78e87-3241-0719-eb2a-a7e8d21afd0b%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/CAJUhtG8EH2E1y33qLPJr3xdp8ZT1z1T98mCQ9bJ4WeBn19BOsQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

['Joe Medley' via blink-dev]

Where's the status entry for this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:

> A change of schedule doesn't really qualify as an experiment extension. My
> LGTM from the previous intent
> 
> still stands.
>
> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
> wrote:
>
>> *Contact emails*
>>
>> chikam...@chromium.org, sisidov...@chromium.org
>>
>> Explainer:
>>
>>-
>>
>>https://github.com/nyaxt/lazyembeds
>>
>>
>> Specification: https://github.com/nyaxt/lazyembeds
>>
>> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
>> outside the viewport when all of the following conditions are met.
>>
>>
>>-
>>
>>The loading=eager or loading=lazy attribute values are not specified
>>in the iframe tag.
>>
>>
>>-
>>
>>The iframe's src URL matches a pre-curated list of cross-origin
>>embeds (for the sake of quick experimentation).
>>
>>
>>-
>>
>>The page is visible.
>>-
>>
>>The iframe's src URL must be cross origin.
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>
>>
>> LazyEmbeds has a timeout mechanism that loads all the iframes that are
>> eligible for LazyEmbeds after a few seconds have elapsed even when the
>> viewport doesn't come near the iframe. This timeout mechanism is the main
>> difference between  LazyEmbeds and .
>>
>> Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.
>>
>> The current LazyEmbeds implementations target a 1% stable channel for
>> data gathering purposes. We don't have any plan to release LazyEmbeds in
>> its current form. This experiment is to help us assess the potential
>> impact, in order to motivate a proper, launchable, design.
>>
>> Blink component: Blink>Loader
>> 
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> RisksInteroperability and Compatibility
>>
>> The goal of the experiment is to test if the idea actually improves page
>> load UX. Once that is proven, we would like to start pitching in the
>> standardization forum on having the new behavior part of the spec.
>>
>> We have a rough sketch of how it would look like in terms of
>> specification changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds
>> applies a different loading schedule to offscreen cross-origin s.
>> Site authors who believe offscreen content is a critical part of the
>> user-experience may find this breaks their expectations. To restore the
>> previous behavior, authors can specify loading=eager on those frames.
>>
>> Ergonomics
>>
>> Websites don’t have to do anything.
>>
>> Activation
>>
>> LazyEmbeds works without any developer activation.
>>
>> Security and privacy
>>
>> LazyEmbeds doesn't have any security and privacy concerns.
>>
>> Goals for experimentation
>>
>> We would like to judge if this is a good idea or not before we would like
>> to validate our hypothesis using the performance data (e.g. Core Web
>> Vitals) collected through the experiment before we proceed to the next
>> steps (open-ended discussion with other vendors, involved 3rd-parties).
>>
>> Reason this experiment is being extended
>>
>> The previous timeline was to start an experimental 1% stable rollout in
>> M104. But while running experiments in M104 beta, we have noticed several
>> problems. So we would like to change the schedule. We want to restart the
>> experiment in M105 beta and 1% stable rollout in M105.
>>
>> The following are the notable differences between M104 and M105.
>>
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>   -
>>
>>Added a timeout mechanism that loads all the iframes that are
>>eligible for LazyEmbeds after a few seconds have elapsed even when the
>>viewport doesn't come near the iframe. This timeout mechanism is intended
>>to minimize the risk of breakage caused by LazyEmbeds.
>>-
>>
>>Expanded the pre-curated list of cross-origin embeds.
>>
>>
>> Any risks when the experiment finishes?
>>
>> No.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes.
>>
>> Is this feature fully tested by web-platform-tests
>> 

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

['Joe Medley' via blink-dev]

Apparently, I missed this so I do intend to add it to the beta post.

let TransformStreamDefaultController;
new TransformStream({ start(c) { TransformStreamDefaultController =
c.constructor; } });
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jul 14, 2022 at 7:18 AM Joe Medley  wrote:

> Domenic,
>
> Thank you for the information.
>
> I dug into this before deciding whether to include it in the blog post.
> From what I gather in the spec, the only way to get an instance of this is
> through a number of callbacks (TransformerStartCallback,
> TransformerFlushCallback, and TransformerTransformCallback). I guess this
> is what you mean by, "spec-conformance in an area developers won't notice
> directly." I can't find that Chrome currently implements these. If
> the callbacks are ever implemented, I'll need a short item about all of
> them.
>
> For future reference, here's the heuristic for what goes in a blog post.
> If Chrome get's a platform feature that was not in the previous version, it
> goes in. Whether something was implemented because of a bug or a formal
> planning process is not generally something external developers care about.
> (A single developer might if they tried to use something that was supposed
> to be available and they're the one that filed the bug. I consider that an
> edge case.)
>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Jul 13, 2022 at 5:52 PM Domenic Denicola 
> wrote:
>
>> Thanks Alex! I'll work on the Intent now. A response to Joe's question
>> below.
>>
>> On Thu, Jul 14, 2022 at 1:10 AM Joe Medley  wrote:
>>
>>> Gang,
>>>
>>> I want to make sure I understand. It seems like this is just a bug fix
>>> or something like it. I want to understand before I agree that it doesn't
>>> need a mention in the blog post.
>>>
>>> Here's what I think it sounds like. The functionality shipped in Chrome
>>> 89 as shown on the status entry, but it didn't actually work. Is that
>>> correct?
>>>
>>
>> Not quite. What shipped in Chrome 89 was exposing
>> ReadableStreamDefaultController. What I am proposing to ship in Chrome 105
>> is the analogous exposure of TransformStreamDefaultController. They are two
>> separate changes, just very similar to each other.
>>
>> They are both very small bug fixes that IMO are not really that
>> interesting to developers, since they are mostly about spec-conformance in
>> an area developers won't notice directly. So IMO they don't need a mention
>> in the blog post. But, that is not my determination to make, so feel free
>> to judge for yourself when you see the upcoming Intent. It won't hurt
>> anything if it's included.
>>
>>
>>>
>>> Joe
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Wed, Jul 13, 2022 at 8:44 AM Alex Russell 
>>> wrote:
>>>
 Hey Domenic,

 Discussed at today's API OWNERS and we decided that:

- It makes sense for this to be an intent
- We're happy to see this skipped for TAG review as it is covered
by previous reviews
- You should expect the intent to be fast-tracked once filed, and
please just link to this discussion as you file it

 Thanks in advance, and sorry for the overhead.

>>>
 Best,

 Alex

 On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:

> While I'm happy to do it, I think I may not have explained the
> situation well enough, so let me ask a clarifying question...
>
> On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss 
> wrote:
>
>> Hey Domenic!
>>
>> While I agree it's a very similar case, it's not identical.
>>
> I agree that a TAG review is not needed here, nor getting
>> positions from other vendors, but there's still some risk in exposing the
>> interface where it wasn't exposed before. (e.g. sites using the lack of
>> exposure for some weird feature detection)
>>
>> And while I don't think the risk here is high, it's non-zero. E.g.
>> quickly scanning
>> 
>> through the HTTPArchive [1], I see ~15K response bodies that contain the
>> string "ReadableStreamDefaultController".
>>
>> So, I think it'd be good to send out a new intent and discuss the
>> risks and whether we need to do something to counter them (e.g. sampled
>> analysis of HTTPArchive data, ClusterTelemetry run with tighter counters,
>> or maybe nothing at all).
>>
>> I know it'd create some extra overhead, but would enable us to keep
>> track of this specific change and its current risks.
>>
>
> 

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

['Joe Medley' via blink-dev]

Domenic,

Thank you for the information.

I dug into this before deciding whether to include it in the blog post.
>From what I gather in the spec, the only way to get an instance of this is
through a number of callbacks (TransformerStartCallback,
TransformerFlushCallback, and TransformerTransformCallback). I guess this
is what you mean by, "spec-conformance in an area developers won't notice
directly." I can't find that Chrome currently implements these. If
the callbacks are ever implemented, I'll need a short item about all of
them.

For future reference, here's the heuristic for what goes in a blog post. If
Chrome get's a platform feature that was not in the previous version, it
goes in. Whether something was implemented because of a bug or a formal
planning process is not generally something external developers care about.
(A single developer might if they tried to use something that was supposed
to be available and they're the one that filed the bug. I consider that an
edge case.)

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jul 13, 2022 at 5:52 PM Domenic Denicola 
wrote:

> Thanks Alex! I'll work on the Intent now. A response to Joe's question
> below.
>
> On Thu, Jul 14, 2022 at 1:10 AM Joe Medley  wrote:
>
>> Gang,
>>
>> I want to make sure I understand. It seems like this is just a bug fix or
>> something like it. I want to understand before I agree that it doesn't need
>> a mention in the blog post.
>>
>> Here's what I think it sounds like. The functionality shipped in Chrome
>> 89 as shown on the status entry, but it didn't actually work. Is that
>> correct?
>>
>
> Not quite. What shipped in Chrome 89 was exposing
> ReadableStreamDefaultController. What I am proposing to ship in Chrome 105
> is the analogous exposure of TransformStreamDefaultController. They are two
> separate changes, just very similar to each other.
>
> They are both very small bug fixes that IMO are not really that
> interesting to developers, since they are mostly about spec-conformance in
> an area developers won't notice directly. So IMO they don't need a mention
> in the blog post. But, that is not my determination to make, so feel free
> to judge for yourself when you see the upcoming Intent. It won't hurt
> anything if it's included.
>
>
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Jul 13, 2022 at 8:44 AM Alex Russell 
>> wrote:
>>
>>> Hey Domenic,
>>>
>>> Discussed at today's API OWNERS and we decided that:
>>>
>>>- It makes sense for this to be an intent
>>>- We're happy to see this skipped for TAG review as it is covered by
>>>previous reviews
>>>- You should expect the intent to be fast-tracked once filed, and
>>>please just link to this discussion as you file it
>>>
>>> Thanks in advance, and sorry for the overhead.
>>>
>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:
>>>
 While I'm happy to do it, I think I may not have explained the
 situation well enough, so let me ask a clarifying question...

 On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss 
 wrote:

> Hey Domenic!
>
> While I agree it's a very similar case, it's not identical.
>
 I agree that a TAG review is not needed here, nor getting
> positions from other vendors, but there's still some risk in exposing the
> interface where it wasn't exposed before. (e.g. sites using the lack of
> exposure for some weird feature detection)
>
> And while I don't think the risk here is high, it's non-zero. E.g.
> quickly scanning
> 
> through the HTTPArchive [1], I see ~15K response bodies that contain the
> string "ReadableStreamDefaultController".
>
> So, I think it'd be good to send out a new intent and discuss the
> risks and whether we need to do something to counter them (e.g. sampled
> analysis of HTTPArchive data, ClusterTelemetry run with tighter counters,
> or maybe nothing at all).
>
> I know it'd create some extra overhead, but would enable us to keep
> track of this specific change and its current risks.
>

 What risk would you be imagining? It seems like a high burden to ask
 people to do HTTPArchive analysis just to fix an exposure bug like this,
 especially one where all other browsers already expose the global. Like, we
 don't ask people to do HTTP archive analysis when exposing entire new
 features which come with multiple new globals, where Chrome is shipping
 first, so I don't see why this case would need such analysis. Indeed, many
 Intent to Ships have sailed through the API Owners with "No compat
 

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

['Joe Medley' via blink-dev]

Gang,

I want to make sure I understand. It seems like this is just a bug fix or
something like it. I want to understand before I agree that it doesn't need
a mention in the blog post.

Here's what I think it sounds like. The functionality shipped in Chrome 89
as shown on the status entry, but it didn't actually work. Is that correct?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jul 13, 2022 at 8:44 AM Alex Russell 
wrote:

> Hey Domenic,
>
> Discussed at today's API OWNERS and we decided that:
>
>- It makes sense for this to be an intent
>- We're happy to see this skipped for TAG review as it is covered by
>previous reviews
>- You should expect the intent to be fast-tracked once filed, and
>please just link to this discussion as you file it
>
> Thanks in advance, and sorry for the overhead.
>
> Best,
>
> Alex
>
> On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:
>
>> While I'm happy to do it, I think I may not have explained the situation
>> well enough, so let me ask a clarifying question...
>>
>> On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss 
>> wrote:
>>
>>> Hey Domenic!
>>>
>>> While I agree it's a very similar case, it's not identical.
>>>
>> I agree that a TAG review is not needed here, nor getting positions from
>>> other vendors, but there's still some risk in exposing the interface where
>>> it wasn't exposed before. (e.g. sites using the lack of exposure for some
>>> weird feature detection)
>>>
>>> And while I don't think the risk here is high, it's non-zero. E.g.
>>> quickly scanning
>>> 
>>> through the HTTPArchive [1], I see ~15K response bodies that contain the
>>> string "ReadableStreamDefaultController".
>>>
>>> So, I think it'd be good to send out a new intent and discuss the risks
>>> and whether we need to do something to counter them (e.g. sampled analysis
>>> of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe
>>> nothing at all).
>>>
>>> I know it'd create some extra overhead, but would enable us to keep
>>> track of this specific change and its current risks.
>>>
>>
>> What risk would you be imagining? It seems like a high burden to ask
>> people to do HTTPArchive analysis just to fix an exposure bug like this,
>> especially one where all other browsers already expose the global. Like, we
>> don't ask people to do HTTP archive analysis when exposing entire new
>> features which come with multiple new globals, where Chrome is shipping
>> first, so I don't see why this case would need such analysis. Indeed, many
>> Intent to Ships have sailed through the API Owners with "No compat
>> concerns; this is a new feature".
>>
>> To be clear, I'm willing (if not excited) to spend 2x the time I spent on
>> the CL doing all the ChromeStatus rigamarole and sending an email, if the
>> result is going to be a quick 3 LGTMs because it's trivial and we're just
>> checking some process boxes. I'm not really willing to spend more time than
>> that on this bugfix, though...
>>
>>
>>>
>>> Cheers,
>>> Yoav
>>>
>>> [1]
>>> SELECT page, url
>>> FROM `httparchive.response_bodies.2022_07_01_desktop`
>>> #FROM `httparchive.sample_data.response_bodies_desktop_10k`
>>> WHERE body like "%TransformStreamDefaultController%"
>>>
>>>
>>> On Tue, Jul 12, 2022 at 5:56 AM TAMURA, Kent  wrote:
>>>
 IMO, it's a bug fix and we don't need a dedicated I2S.

 On Tue, Jul 12, 2022 at 11:37 AM Domenic Denicola 
 wrote:

> Hey all,
>
> Today I was browsing
> https://wpt.fyi/results/streams?label=experimental=master
> and noticed that we were failing tests because of an analogous 
> non-exposure
> of TransformStreamDefaultController. I have a CL to fix this at
> https://chromium-review.googlesource.com/c/chromium/src/+/3757032 and
> was thinking it should be OK to just ping this thread with an FYI instead
> of doing a full Intent to Ship, because the change is basically the same
> (and in particular is extremely small/just updating to follow the
> spec/already implemented in other browsers). IMO this does not need a
> ChromeStatus entry or release blog post spot either.
>
> Does that sound OK? If so hopefully an API owner can stop by my CL and
> approve the webexposed/ changes. Otherwise we can start a new Intent to
> Ship thread if necessary.
>
> -Domenic
>
> On Tuesday, December 15, 2020 at 9:32:26 AM UTC Daniel Bratell wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2020-12-15 08:33, TAMURA, Kent wrote:
>>
>> LGTM2
>>
>>
>> On Tue, Dec 15, 2020 at 3:51 PM Yoav Weiss  wrote:
>>
>>> LGTM1
>>>
>>>
>>>
>>> On Fri, Dec 11, 2020 at 3:59 AM Nidhi Jaju 
>>> wrote:
>>>
 Hi Yoav,

 The 

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

['Joe Medley' via blink-dev]

David,

In which milestone will this be removed?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jul 6, 2022 at 12:50 PM David Baron  wrote:

> Contact emailsdba...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://www.w3.org/TR/css-values-3/#custom-idents
>
> Summary
>
> The CSS keyword 'default' is not allowed within CSS custom identifiers,
> which are used for many types of user-defined names in CSS (for example,
> names created by @keyframes rules, counters, @container names, custom
> layout or paint names). This adds 'default' to the list of names that are
> reserved from being used in custom identifiers, which already reserve
> 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.
>
>
> Note that some existing CSS features that accept custom identifiers check
> specifically for 'default' to avoid the risk of worsening the potential
> compatibility problem in this deprecation. This means that fixing the
> general code for custom identifiers will fix the remaining cases, though
> some cases are already fixed.
>
> Blink componentBlink>CSS
> 
>
> Motivation
>
> Keywords that CSS uses (or is likely to use in the future) as values
> accepted by any CSS property should not be allowed in custom identifiers
> because many custom identifiers are also values of CSS properties. If they
> can be custom identifiers, then developers could create content that would
> be broken by the addition of these keywords as property values either to
> all CSS properties, or to a particular CSS property that already accepts
> custom identifiers.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is some compatibility risk if pages are using default as a custom
> identifier (for example, as the name of an @keyframes rule that is
> referenced in animation-name). This risk is lessened by the fact that Gecko
> and WebKit have already shipped this change; thus shipping this deprecation
> reduces interoperability risk.
>
>
> *Gecko*: Shipped/Shipping (
> https://searchfox.org/mozilla-central/rev/f816e52d85cdaf0be7c9e1d2297f833e9ef53e2e/servo/components/style/values/mod.rs#462
> )
>
> *WebKit*: Shipped/Shipping (
> https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/parser/CSSParserIdioms.h#L77
> )
>
> *Web developers*: No signals
>
> *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?
>
>
>
> Debuggability
>
> The debuggability matches the debuggability of syntax errors produced for
> existing invalid values, which include the reserved names 'inherit',
> 'initial', etc.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No.
>
> There are tests for some, but not all, of the features that use custom
> identifiers. I hope to add a few more as part of landing this. An existing
> test that covers this case is:
> https://wpt.fyi/results/css/css-properties-values-api/register-property-syntax-parsing.html?label=stable=master
>  and
> an existing test that should be expanded is:
> https://wpt.fyi/results/css/css-font-loading/fontfaceset-load-css-wide-keywords.html?label=stable=master
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=882285
>
> Measurement
> https://chromestatus.com/metrics/feature/timeline/popularity/2628 is a
> use counter that is currently around 0.0086% and increasing.
> https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1170371304 has
> data from a cluster telemetry run showing one site in the 10K set that
> could be affected.
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5096490737860608
>
> This intent message was generated by Chrome Platform Status
>  and then hand edited.
>
> --
> 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/CAG0MU3gf2ifuNT64OM7nHvo0jnXxkbZ4BmAh%2BYw0UUSq_iG%3D_g%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, 

Re: [blink-dev] Intent to Deprecate and Remove: Expect-CT

['Joe Medley' via blink-dev]

Emily,

In which milestone will this be removed?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Jul 8, 2022 at 9:31 AM Emily Stark  wrote:

> Contact emailsest...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://datatracker.ietf.org/doc/rfc9163
>
> Summary
>
> Expect-CT is an HTTP header that allowed websites to opt in to Certificate
> Transparency enforcement before it was enforced by default. It also has
> reporting functionality to help developers discover CT misconfigurations.
>
>
> Blink componentInternals>Network>DomainSecurityPolicy
> 
>
> Motivation
>
> Expect-CT was designed to help transition to universal Certificate
> Transparency (CT) enforcement, by allowing high-value websites to opt in to
> CT enforcement/reporting for better security before CT enforcement was
> required (by Chrome) on all public websites. However, Expect-CT has now
> outlived its usefulness. Chrome requires CT on all public websites now, so
> there is no security value to Expect-CT anymore. Expect-CT was also
> designed to help site owners discover CT-related misconfigurations;
> however, now that CT is universally required, CT is generally configured in
> websites' certificates by certificate authorities and virtually never
> configured by individual site owners, thus Expect-CT has very limited value
> as a misconfiguration/debugging tool anymore either. No other browser has
> implemented Expect-CT so removing it is not an interoperability concern.
>
>
> Initial public proposal
> https://groups.google.com/a/chromium.org/g/blink-dev/c/tgn5R-58iek/m/Q6YCnu0RFQAJ
>
> TAG reviewn/a
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
> No other browser has implemented Expect-CT or given signals that they
> intend to (to my knowledge). Expect-CT is not user-visible so removing the
> feature has no compatibility risk. Developers who are currently sending the
> header should stop doing so just to save the bytes on the wire.
>
> While the header is served on a large percent of requests (~6%), this is
> likely due to a small number of large providers that can be informed of the
> deprecation via 1:1 outreach. As described above, the header serves no
> security value any longer, removing it will have no user-visible effects,
> and the header provides extremely minimal debugging value to developers
> since developers are no longer responsible for serving their own CT
> information (100.00% of requests serve CT information directly embedded in
> the certificate, which developers are not responsible for configuring).
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *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?
>
>
>
> Debuggability
>
> We'll add a console message informing developers that the header will/has
> no effect and they should remove it.
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6244547273687040
>
> 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/CAPP_2SbFjjX-AEv7bUEqOcgp8JTy5t9CoYHproGe0WkJGSY3Pg%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/CAJUhtG9tQQ60iCEB%2BPsdJF8b3XfDyo_ffS3qtc6ui%3Df96Ot3VA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Viewport-height client hint

['Joe Medley' via blink-dev]

Is this shipping in 105?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jun 30, 2022 at 1:38 PM Yoav Weiss  wrote:

> LGTM3
>
> On Thu, Jun 30, 2022 at 10:33 PM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> On Thu, Jun 30, 2022 at 1:32 PM Mike Taylor 
>> wrote:
>>
>>> Thanks for the update.
>>>
>>> LGTM1 to ship. This seems like a useful addition to the Viewport-Width
>>> hint.
>>>
>>> On 6/30/22 12:59 PM, 'Max Curran' via blink-dev wrote:
>>>
>>> Our partners found the feature useful and want to see it launched.
>>>
>>> On Wednesday, June 29, 2022 at 8:13:38 AM UTC-7 Daniel Bratell wrote:
>>>
 What was the result of the origin trial? Did you get any useful
 feedback?

 /Daniel
 On 2022-06-27 22:15, 'Max Curran' via blink-dev wrote:

 Contact emails

 ryan...@chromium.org, curr...@chromium.org

 Explainer


 https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md

 Specification


 https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height

 Summary

 Currently, Responsive Image Client Hints provide a way for origins to
 obtain the viewport’s width. However, no such attribute exists for viewport
 height. We’ve observed that to optimize the loading of content that appears
 in viewport, it is essential for the origins to adapt HTML response based
 on viewport height.


 Blink component

 Blink>Loader
 

 TAG review

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

 TAG review status

 Issues addressed

 Link to origin trial feedback summary

 https://github.com/WICG/responsive-image-client-hints/issues

 Risks

 Interoperability and Compatibility

 Gecko: No signal (
 https://github.com/mozilla/standards-positions/issues/79)

 WebKit: Negative (
 https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
 Likely to be neutral based on discussion in
 https://github.com/mozilla/standards-positions/issues/79

 Web developers: No signals

 Other signals:

 Activation

 None


 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?


 Debuggability

 N/A


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 Yes

 Is this feature fully tested by web-platform-tests
 
 ?

 Yes

 Flag name

 kViewportHeightClientHintHeader

 Requires code in //chrome?

 False

 Tracking bug

 https://bugs.chromium.org/p/chromium/issues/detail?id=1184863

 Launch bug

 https://bugs.chromium.org/p/chromium/issues/detail?id=1184862

 Estimated milestones

 OriginTrial desktop last

 104

 OriginTrial desktop first

 100

 OriginTrial Android last

 104

 OriginTrial Android first

 100




 Anticipated spec changes

 Open questions about a feature may be a source of future web compat or
 interop issues. Please list open issues (e.g. links to known github issues
 in the project for the feature specification) whose resolution may
 introduce web compat/interop risk (e.g., changing to naming or structure of
 the API in a non-backward-compatible way).


 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5646861215989760

 Links to previous Intent discussions

 Intent to Experiment:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/Q2wcqY2UyNs/m/rPePdX_NBwAJ

 Intent to Extend Experiment:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/kftmeKVDjE8/m/GlaCr5PYEQAJ


 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+...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BEneNMJuAb7K5R0Gsxp2FvcL-Ny8rTmmLR7C_WgiUiz5FNbKA%40mail.gmail.com
 

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

['Joe Medley' via blink-dev]

I asked my question badly. In which milestone are you planning to ship this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jun 30, 2022 at 9:26 AM Jihwan Kim  wrote:

> Patch is almost ready as follows.
> https://chromium-review.googlesource.com/c/chromium/src/+/3655618
>
> But there is no WPT test to check if it is :modal when fullscreen, and I'm
> writing it now.
>
> 2022년 7월 1일 금요일 오전 12시 46분 27초 UTC+9에 Joe Medley님이 작성:
>
>> When are you planning to ship this?
>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Jun 29, 2022 at 8:51 AM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> -mike
>>>
>>>
>>> On Wed, Jun 29, 2022 at 5:50 PM Manuel Rego Casasnovas 
>>> wrote:
>>>
 LGTM2 too with Philip's requests.

 On 29/06/2022 17:48, Philip Jägenstedt wrote:
 > LGTM1 to ship this with the latest spec changes applied, and WPT
 > written and passing for that.
 >
 > On Wed, Jun 29, 2022 at 5:27 PM Manuel Rego Casasnovas <
 re...@igalia.com> wrote:
 >>
 >> Does Chromium implementation match the spec resolution, so :modal
 >> applies to fullscreen too?
 >>
 >> Are there tests checking that?
 >>
 >> Cheers,
 >>   Rego
 >>
 >> On 27/06/2022 15:20, Jihwan Kim wrote:
 >>> I have updated the I2S contents including explainer, vendor signals
 >>> those are commented.
 >>> We may now progress this I2S.
 >>> thanks.
 >>>
 >>> 2022년 6월 24일 금요일 오전 4시 2분 49초 UTC+9에 Chris Harrelson님이 작성:
 >>>
 >>> The CSSWG just resolved yesterday that :modal should apply to
 >>> fullscreen, and that fullscreen should be modal. So I think this
 >>> intent is unblocked.
 >>>
 >>> On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim 
 wrote:
 >>>
 >>> Thanks for Chris Harrelson.
 >>> Once "should fullscreen be modal?" is resolved, I'll keep
 >>> progress this.
 >>> thanks.
 >>>
 >>> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson
 >>> 님이 작성:
 >>>
 >>> I've also added "should fullscreen be modal?" to the
 CSSWG
 >>> agenda. Once that is resolved this intent is ready to
 ship,
 >>> in my view.
 >>>
 >>> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson
 >>>  wrote:
 >>>
 >>>
 >>> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni
 >>>  wrote:
 >>>
 >>> Hello,
 >>> It would be nice if there was some repository or
 >>> documents were we could fill some
 security/privacy
 >>> questions. I will do it here instead.
 >>> How does this interacts with iframes? Do you
 know
 >>> where it might be defined in the spec? I
 remember
 >>> for the modal dialog, there was some "inertness"
 >>> attribute propagated toward parent/iframes. It
 was
 >>> shown it can be used to leak cross-site data,
 or it
 >>> can be used to create new communication
 channel. It
 >>> was found and fixed here:
 https://crbug.com/1293191
 >>> . I guess the two
 >>> features relies on the same mechanism and Chrome
 >>> might immune as result. Anyway, could you please
 >>> make sure the behavior is specified and show
 how it
 >>> doesn't create a cross-site leak?
 >>>
 >>>
 >>> You are correct that the same mechanism
 >>> prevented cross-site information leaks for "both".
 In
 >>> other words, thet modal dialog feature doesn't
 >>> propagate, due to the fix for issue 1293191.
 >>>
 >>> :modal is a pseudoclass state that only changes
 style
 >>> for a  element in the same document as the
 style
 >>> sheet using :modal. Therefore a cross-origin iframe
 >>> won't be able to change its document's state based
 on
 >>> :modal. So I don't see a way that this feature will
 >>> introduce new security or privacy issues. Let me
 know if
 >>> this doesn't fully answer your questions.
 >>>
 >>>
 >>> Filling
 >>> the
 https://w3ctag.github.io/security-questionnaire/
 >>> <
 

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

['Joe Medley' via blink-dev]

When are you planning to ship this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 29, 2022 at 8:51 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Wed, Jun 29, 2022 at 5:50 PM Manuel Rego Casasnovas 
> wrote:
>
>> LGTM2 too with Philip's requests.
>>
>> On 29/06/2022 17:48, Philip Jägenstedt wrote:
>> > LGTM1 to ship this with the latest spec changes applied, and WPT
>> > written and passing for that.
>> >
>> > On Wed, Jun 29, 2022 at 5:27 PM Manuel Rego Casasnovas 
>> wrote:
>> >>
>> >> Does Chromium implementation match the spec resolution, so :modal
>> >> applies to fullscreen too?
>> >>
>> >> Are there tests checking that?
>> >>
>> >> Cheers,
>> >>   Rego
>> >>
>> >> On 27/06/2022 15:20, Jihwan Kim wrote:
>> >>> I have updated the I2S contents including explainer, vendor signals
>> >>> those are commented.
>> >>> We may now progress this I2S.
>> >>> thanks.
>> >>>
>> >>> 2022년 6월 24일 금요일 오전 4시 2분 49초 UTC+9에 Chris Harrelson님이 작성:
>> >>>
>> >>> The CSSWG just resolved yesterday that :modal should apply to
>> >>> fullscreen, and that fullscreen should be modal. So I think this
>> >>> intent is unblocked.
>> >>>
>> >>> On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim 
>> wrote:
>> >>>
>> >>> Thanks for Chris Harrelson.
>> >>> Once "should fullscreen be modal?" is resolved, I'll keep
>> >>> progress this.
>> >>> thanks.
>> >>>
>> >>> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson
>> >>> 님이 작성:
>> >>>
>> >>> I've also added "should fullscreen be modal?" to the CSSWG
>> >>> agenda. Once that is resolved this intent is ready to
>> ship,
>> >>> in my view.
>> >>>
>> >>> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson
>> >>>  wrote:
>> >>>
>> >>>
>> >>> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni
>> >>>  wrote:
>> >>>
>> >>> Hello,
>> >>> It would be nice if there was some repository or
>> >>> documents were we could fill some security/privacy
>> >>> questions. I will do it here instead.
>> >>> How does this interacts with iframes? Do you know
>> >>> where it might be defined in the spec? I remember
>> >>> for the modal dialog, there was some "inertness"
>> >>> attribute propagated toward parent/iframes. It was
>> >>> shown it can be used to leak cross-site data, or
>> it
>> >>> can be used to create new communication channel.
>> It
>> >>> was found and fixed here:
>> https://crbug.com/1293191
>> >>> . I guess the two
>> >>> features relies on the same mechanism and Chrome
>> >>> might immune as result. Anyway, could you please
>> >>> make sure the behavior is specified and show how
>> it
>> >>> doesn't create a cross-site leak?
>> >>>
>> >>>
>> >>> You are correct that the same mechanism
>> >>> prevented cross-site information leaks for "both". In
>> >>> other words, thet modal dialog feature doesn't
>> >>> propagate, due to the fix for issue 1293191.
>> >>>
>> >>> :modal is a pseudoclass state that only changes style
>> >>> for a  element in the same document as the
>> style
>> >>> sheet using :modal. Therefore a cross-origin iframe
>> >>> won't be able to change its document's state based on
>> >>> :modal. So I don't see a way that this feature will
>> >>> introduce new security or privacy issues. Let me know
>> if
>> >>> this doesn't fully answer your questions.
>> >>>
>> >>>
>> >>> Filling
>> >>> the
>> https://w3ctag.github.io/security-questionnaire/
>> >>> 
>> is often
>> >>> helpful as well ;-)
>> >>>
>> >>> On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike
>> >>> Taylor wrote:
>> >>>
>> >>> On 5/26/22 9:35 AM, Mike Taylor wrote:
>>  On 5/26/22 2:42 AM, Jihwan Kim wrote:
>> >
>> > 4. Gecko vendor signal : I set gecko's
>> signal
>> > to 'Shipped/Shipping' as the
>> > doc(bit.ly/blink-signals
>> > ) defines
>> > 'Shipped/Shipping' as 'Link to public
>> > documentation or bug/issue'. I'm not sure
>> >

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

['Joe Medley' via blink-dev]

Daisuke,

That makes it either a dev trial or an origin trial. Since you've recorded
a value for origin_trial_feature_name in runtime_enabled_features.json5
that makes it an origin trial. I assume that's starting in 105?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Jun 27, 2022 at 7:14 PM Daisuke Enomoto 
wrote:

> Joe, the API is behind the flag "PendingBeaconAPI".
>
> Mike, we came to discuss the new ideas of API design after we sent this
> I2E. We will update the I2E thread when we have clarity on the design
> discussion and the timeline when an experiment can start.
>
> Caleb, thank you for filing an issue.
>
> On Tue, Jun 28, 2022 at 3:09 AM Caleb Raitto  wrote:
>
>> Hi, I filed https://github.com/darrenw/docs/issues/3 about a time limit
>> on the duration from bfcache page freeze to beacons being sent -- could you
>> PTAL?
>>
>> Thanks,
>> -Caleb
>>
>> On Friday, June 24, 2022 at 9:36:15 AM UTC-4 mike...@chromium.org wrote:
>>
>>> Thanks - sounds good.
>>>
>>> Could you clarify the desired experiment timeline? Is it just for M104,
>>> or something else?
>>>
>>> On 6/20/22 12:31 AM, Fergal Daly wrote:
>>>
>>> Sorry, there were some details left out of this I2E. We actually have a
>>> lot of signals from web devs on this. There are some comments on
>>>
>>>
>>> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
>>>
>>> but we also presented this to W3C WebPerf with a lot of positive
>>> signals. Minutes are here
>>>  
>>> from
>>> the most recent one.
>>>
>>> We don't have any reaction from Mozilla or WebKit that I know of and we
>>> will file a TAG request shortly,
>>>
>>> F
>>>
>>> On Sat, 18 Jun 2022 at 02:57, Mike Taylor  wrote:
>>>
 On 6/17/22 10:59 AM, Ming-Ying Chung wrote:

 Contact emails

 my...@chromium.org, fer...@chromium.org, deno...@chromium.org

 Explainer

 https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md

 Specification

 https://clelland.github.io/page-unload-beacon/spec.html (In draft
 state)

 Summary

 A stateful API for beacons that has the browser control the time
 beacons are sent.

 Existing beacon APIs are all based around a developer constructing and
 sending a beacon, and there's no good time for that "send" call to be made.
 (Handlers such as 'unload' are often ignored, for example.) This API
 delegates the sending to the browser itself, so it can support beacons on
 page unload or on page hide, without the developer having to implement send
 calls at exactly the right times.


 Blink component

 Blink>Network
 

 TAG review

 None yet.

 I'd recommend filing a TAG review as well as asking for signals now, to
 allow folks plenty of time to respond.

 TAG review status

 N/A

 Risks

 Interoperability and Compatibility

 Gecko: No signal

 WebKit: No signal

 Web developers: No signals

 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?


 Goals for experimentation

 The intent is for experiments to learn that developers can easily adopt
 the API shapes to achieve current use cases in addition to getting feedback
 from them. The experiment also aims to test the stability and reliability
 of the API.

 Ongoing technical constraints

 In M104, the API described in the explainer is not yet fully developed,
 such that the API

-

Supports only the GET method. Setting it to POST will fall back to
GET.
-

Does not support request payload, i.e. it does not send out data
set by setData(data).
-

Does not support pageHideTimeout.
-

Does not recover from browser crashes, forced closures, network
failure, etc.


 Debuggability

 There are no particular debugging APIs made available or Chrome
 DevTools integrations for this OT. We plan to build an integration with
 Chrome DevTools to provide a better developer experience. This OT will
 allow us to get feedback that helps us build the right design.

 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 Yes

 Is this feature fully tested by web-platform-tests
 
 ?

 No, basic 

Re: [blink-dev] Intent to Prototype and Ship: Response.json()

['Joe Medley' via blink-dev]

Thank you.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jun 23, 2022 at 12:14 AM Adam Rice  wrote:

> I expect to ship it in M105. I have updated chromestatus.com.
>
> On Thu, 23 Jun 2022 at 02:09, Joe Medley  wrote:
>
>> Adam,
>>
>> When are you hoping to ship?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Jun 22, 2022 at 8:56 AM Philip Jägenstedt 
>> wrote:
>>
>>> LGTM3
>>>
>>> The TAG review has been sitting for a month now, and this proposal has
>>> already received scrutiny in the spec discussion. If there's feedback (on
>>> naming or otherwise) before this reaches stable, we should take it into
>>> account.
>>>
>>> On Wed, Jun 22, 2022 at 5:54 PM Yoav Weiss 
>>> wrote:
>>>
 LGTM2

 On Wednesday, June 22, 2022 at 5:53:49 PM UTC+2 Chris Harrelson wrote:

> LGTM1
>
> On Tue, May 31, 2022 at 11:08 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Tue, May 31, 2022 at 4:08 AM Adam Rice  wrote:
>>
>>> Contact emailsri...@chromium.org, yhir...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit
>>>
>>> Specification
>>> https://fetch.spec.whatwg.org/#ref-for-dom-response-json
>>>
>>> Summary
>>>
>>> Improves ergonomics for creating JSON Response objects. The Response
>>> constructor allows for creating the body of the response from many 
>>> types,
>>> however it is not possible to directly create a JSON object. The
>>> Response.json() static method fills this gap. It returns a Response 
>>> object
>>> with a body consisting the first argument serialized as JSON. The second
>>> argument is a ResponseInit option bag as with the Response constructor.
>>>
>>>
>>> Blink componentBlink>Network>FetchAPI
>>> 
>>>
>>> Motivation
>>>
>>> Creating a Response object with a body of a JSON object has been
>>> harder than the other types supported by Fetch. This change improves the
>>> ergonomics of creating a JSON response.
>>>
>>>
>>> Initial public proposalhttps://github.com/whatwg/fetch/issues/1389
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/741
>>>
>>
>> The TAG review issue says they'd look into this next week. Given the
>> fact that the issue was filed a couple of weeks ago, it seems reasonable 
>> to
>> wait till then.
>>
>>
>>>
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk is low as Deno and Node have already
>>> implemented the feature, and it is a simple addition to the API. We 
>>> know of
>>> no compatibility risk. It could happen if someone is using a polyfill 
>>> with
>>> an incompatible API, but that is unlikely.
>>>
>>>
>>> *Gecko*: Worth prototyping (
>>> https://github.com/mozilla/standards-positions/issues/640)
>>>
>>> *WebKit*: Positive (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032254.html)
>>>
>>> *Web developers*: Positive (
>>> https://github.com/whatwg/fetch/issues/1389) Example positive
>>> feedback:
>>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024726318 
>>> Example
>>> negative feedback:
>>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024880489
>>>
>>
>> Great feedback from developers!!
>>
>>
>>>
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This is a convenience function that is purely an ergonomic
>>> improvement.
>>>
>>>
>>> Activation
>>>
>>> The feature can be easily polyfilled.
>>>
>>>
>>> Security
>>>
>>> The feature adds no capabilities that developers don't already have.
>>> The implementation mostly reuses existing logic, reducing the security 
>>> risk.
>>>
>>>
>>> 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?
>>>
>>> No
>>>
>>>
>>> Debuggability
>>>
>>> Automatically supported as a feature implemented in WebIDL.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1305358
>>>
>>> 

Re: [blink-dev] Re: Intent to Ship: forced-color-adjust: preserve-parent-color

['Joe Medley' via blink-dev]

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:54 AM Mike Taylor  wrote:

> LGTM3
>
> On 6/22/22 12:10 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Jun 22, 2022 at 9:05 AM Daniel Bratell 
> wrote:
>
>> LGTM1
>>
>> /Daniel
>> On 2022-06-15 23:33, Sara Tang wrote:
>>
>> Hi, reviving this thread as the CSSWG resolution at [css-color]
>> [css-color-adjust] Make system colors fully resolve (but flag they were
>> system colors) thus reversing the resolution of #3847 · Issue #6773 ·
>> w3c/csswg-drafts (github.com)
>>   has been reached
>> (though the standards posiiton for this particular feature hasn't been
>> updated yet).  preserve-parent-color value for forced-color-adjust CSS
>> property · Issue #591 · mozilla/standards-positions (github.com)
>> .
>>
>> To summarize,
>>   - If both system colors and forced colors were resolved at compute
>> time, `preserve-parent-color` would not be needed. This is similar to
>> Mozilla, which gets the behavior of `preserve-parent-color` "for free".
>>   - The resolution of #6773 is to resolve system colors at compute time.
>> Forced color are still resolved at used value time.
>>   - Thus, `preserve-parent-color` is still needed.
>>
>> I believe we should now be unblocked to ship `preserve-parent-color` :)
>>
>> Sara
>>
>>
>> On Sunday, November 21, 2021 at 1:10:54 PM UTC-8 Danny Holly wrote:
>>
>>> cause no harm
>>>
>>> On Thursday, October 28, 2021 at 4:45:04 PM UTC-5 Sara Tang wrote:
>>>
 Contact emails sar...@microsoft.com, alison...@microsoft.com

 Explainer
 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

 Specification
 https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

 Summary

 Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS
 property. When Forced Colors Mode is enabled, the ‘color’ property is
 inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the
 ‘color’ property will compute to the used value of its parent. Otherwise,
 ‘forced-color-adjust: preserve-parent-color' value behaves the same as
 ‘forced-color-adjust: none’.

 Contact emails sar...@microsoft.com, alison...@microsoft.com

 Explainer
 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

 Specification
 https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

 Summary

 Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS
 property. When Forced Colors Mode is enabled, the ‘color’ property is
 inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the
 ‘color’ property will compute to the used value of its parent. Otherwise,
 ‘forced-color-adjust: preserve-parent-color' value behaves the same as
 ‘forced-color-adjust: none’.

 *Motivation*

 * ‘forced-color-adjust' is a CSS property that allows developers to opt
 out of Forced Colors Mode.  Previously, there were
 two supported values: ‘auto’ and ‘none’, which can be used to
 control whether or not an element’s styles are adjusted by the UA in Forced
 Colors Mode. A third value, ‘preserve-parent-color', has recently been
 introduced in the spec, which provides similar behavior to ‘none’,
 except that it also allows an element to inherit its parent's
 used ‘color’ value. In other words, ‘preserve-parent-color' provides the
 ability for an element to inherit its parent’s Forced Colors Mode
 adjusted ‘color’ value.  The intention of ‘preserve-parent-color’ is to get
 a reasonable behavior for SVG icons that utilize ‘currentColor’ when
 styling ‘fill’ and ‘stroke’ in Forced Colors Mode,
 as described in [css-color-adjust-1] Spec currently breaks use of
 currentColor for SVG icons in WHCM · Issue #6310 · w3c/csswg-drafts ·
 GitHub .  The use of
 ‘currentColor’ when styling an SVG icon is a common pattern used by authors
 to ensure an accessible experience in Forced Colors Mode. For example, in
 this sample logo,  an author
 would expect the logo to automatically adjust to use the ‘CanvasText’
 system color for ‘fill’ and ‘stroke’ in Forced Colors Mode, as a result of
 setting each to ‘currentColor’.   This behavior,
 however, became broken when we moved from forcing colors at computed value
 time to used value time: [css-color-adjust-1] Is forced color computed or
 used value? · Issue #4915 · w3c/csswg-drafts · GitHub
 

Re: [blink-dev] Intent to Ship: Custom Highlight API

['Joe Medley' via blink-dev]

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:26 AM Daniel Bratell  wrote:

> With dual LGTM1 from Chris and Yoav, I'll jump directly to...
>
> LGTM3
>
> /Daniel
> On 2022-06-22 17:58, Yoav Weiss wrote:
>
> LGTM1
>
> On Wednesday, June 15, 2022 at 11:54:30 PM UTC+2 Daniel Clark wrote:
>
>> *> What's the feature detection/activation story here? Can developers use
>> the feature while it's partially supported? What would be the implications
>> of that?*
>>
>>
>>
>> Feature detection can be done by checking for the presence of
>> CSS.highlights:
>>
>>
>>
>> function supportsHighlightAPI() {
>>
>>   return !!CSS.highlights;
>>
>> }
>>
>>
>>
>> For use cases where the highlights are key to the user experience (e.g.
>> when used for an app’s custom find-on-page implementation), developers
>> should fall back to a polyfill for unsupported browsers. For use cases
>> where highlights are only added for stylistic purposes, they could be
>> omitted altogether when there isn’t support.
>>
>>
>>
>> A polyfill could be built for the feature that works by wrapping
>> “highlighted” content in styled spans. This could get tricky to implement
>> for cases involving many nested highlights (which is one thing that the API
>> makes much easier), but it would work fine for most scenarios.
>>
>>
>>
>> *> We could send a ping notifying that Chromium is planning to ship.*
>>
>>
>>
>> I pinged the mozilla/standards-positions thread about this last week,
>> still waiting to hear back
>> https://github.com/mozilla/standards-positions/issues/482#issuecomment-1152601522.
>> @Emilio , is there anything you’d be able to share
>> about this?
>>
>>
>>
>> *> Can you ask for an explicit signal to see what their plans are on that
>> front? Is there an interop risk from their incomplete implementation?*
>>
>>
>>
>> I sent a mail
>>  to
>> webkit-dev, awaiting response. I just took another look at their
>> implementation, and they’ve done some work to bring it closer to the
>> current state of the spec since last I checked. The remaining major
>> difference I see is just the lack of support for live Ranges. I expect that
>> they will close this gap prior to shipping the feature. If they don’t then
>> the difference could also be feature-detected by polyfills:
>>
>>
>>
>> function supportsLiveRangeHighlights() {
>>
>>   try {
>>
>> new Highlight(new Range());
>>
>> return true;
>>
>>   } catch(ex) {
>>
>> return false;
>>
>>   };
>>
>> }
>>
>>
>>
>> -- Dan
>>
>>
>>
>> *From:* Yoav Weiss 
>> *Sent:* Wednesday, June 15, 2022 1:32 AM
>> *To:* blink-dev 
>> *Cc:* Manuel Rego ; Sanket Joshi (EDGE) <
>> sa...@microsoft.com>; Fernando Fiori ; Bo Cupp <
>> pc...@microsoft.com>; Luis Juan Sanchez Padilla <
>> luis.snc...@microsoft.com>; Delan Azabani ; Emilio
>> Cobos Alvarez ; Rick Byers ;
>> flo...@rivoal.net ; Daniel Clark <
>> dan...@microsoft.com>
>> *Subject:* Re: [blink-dev] Intent to Ship: Custom Highlight API
>>
>>
>>
>>
>>
>> On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:
>>
>> I'm biased here as I've been working on this feature myself, so I cannot
>> give an official LGTM.
>>
>> Thanks for all the work since the previous intent thread, I believe this
>> is now in a way better status to ship.
>>
>> I'd be fine giving a LGTM with the following caveats:
>> * As mentioned at the end of the email, HighlightOverlayPainting flag
>> gets enabled before shipping this (that flag fixes lots of bugs
>> regarding paining of CSS highlight pseudos).
>> * The following CSSWG issue gets resolved:
>> https://github.com/w3c/csswg-drafts/issues/6774
>> 
>> It looks like there's an agreement already but it'd be nice to confirm
>> it, as this might change behavior if a different decision is made.
>>
>> Other than that I've just some minor comments inline.
>>
>> On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
>> > Risks
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> > Low risk: This feature received positive support from Safari and
>> Firefox
>> > at TPAC 2019. Safari is implementing it, Firefox has not yet made any
>> > clear indication on implementation.
>>
>>
>>
>> What's the feature detection/activation story here? Can developers use
>> the feature while it's partially supported? What would be the implications
>> of that?
>>
>>
>>
>>
>> >
>> >
>> >
>> > /Gecko/: No clear signal
>> > 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.surfaceSwitching

['Joe Medley' via blink-dev]

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:17 AM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2022-06-22 17:45, Yoav Weiss wrote:
>
> LGTM2
>
> On Wednesday, June 22, 2022 at 5:45:12 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM1
>>
>> On Fri, Jun 17, 2022 at 12:12 AM 'Elad Alon' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> For the record, Firefox has now formally set their position as
>>> *non-harmful*. See here
>>> 
>>> .
>>>
>>> On Thursday, June 16, 2022 at 7:38:27 PM UTC+2 Elad Alon wrote:
>>>
 Hello Blink owners. I know that this is a bit early, as TAG has not yet
 responded, and the official requests for positions have not had enough time
 for an official response. I will ping this thread when it's time. (I wanted
 to get some of the technical prerequisites out of the way before going on
 extended vacation, so that I may just ping this thread while on vacation.)

 On Thursday, June 16, 2022 at 7:35:40 PM UTC+2 Elad Alon wrote:

> Contact emails elad...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1kqdLoUcwWe8znVCMXyz2FHk9WMylHbIo7gUjhyHmY_w/edit?usp=sharing
>
> Specification
> https://github.com/w3c/mediacapture-screen-share/pull/225/files
>
> Summary
>
> Programmatically control whether Chrome exposes a button that allows
> quickly switching which tab is screen-shared.
>
>
> Blink component Blink
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/744
>
> TAG review status Pending
>
> Risks
> Interoperability and Compatibility
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/653) Jan-Ivar
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both 
> collaborated
> with us closely in shaping this PR. They have then approved merging this 
> PR
> into w3c/mediacapture-screen-share. This is implicit support, so I'd
> consider it POSITIVE even though, as of the time of this writing, the
> official request for position has not yet been answered.
>
> *WebKit*: Positive (
> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032305.html)
> Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
> collaborated with us closely in shaping this PR. They have then approved
> merging this PR into w3c/mediacapture-screen-share. This is implicit
> support, so I'd consider it POSITIVE even though, as of the time of this
> writing, the official request for position has not yet been answered.
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> N/A
>
>
> 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?
>
> N/A
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)? No. It is supported
> on all platforms that support getDisplayMedia. Namely, all desktop
> platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1337019
>
> Estimated milestones
>
> No milestones specified
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5067650299330560
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2wBykF4dgz8
>
>
> 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/aba562a7-213f-4b6d-8434-d05b53521e22n%40chromium.org
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.selfBrowserSurface

['Joe Medley' via blink-dev]

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:17 AM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2022-06-22 17:42, Yoav Weiss wrote:
>
> LGTM2
>
> On Wednesday, June 22, 2022 at 5:42:36 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM1
>>
>> On Wed, Jun 1, 2022 at 8:45 AM 'Elad Alon' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Similar to other intents, this doesn't count as an official positive
 signal. Let's wait a few days to see if one emerges.
>>>
>>>
>>> I've set a reminder to ping this thread in one week, as suggested in the
>>> other intent thread.
>>>
>>> Any external signals from developers? https://goo.gle/developer-signals
>>>
>>>
>>> Yes - here
>>> 
>>> .
>>>
>>>
>>> On Wed, Jun 1, 2022 at 8:44 AM Yoav Weiss 
>>> wrote:
>>>


 On Wednesday, May 25, 2022 at 2:41:36 PM UTC+2 Elad Alon wrote:

> Contact emails elada...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1M63lyDHV-v6LPFzHjfsjBDMfyn075pySa3xfIRSB9zU/edit?usp=sharing
>
> Specification
> https://github.com/w3c/mediacapture-screen-share/pull/216/files
>
> Summary
>
> Hint allowing Web applications to instruct the browser whether, upon
> calling getDisplayMedia(), the current tab should be excluded from the 
> list
> of tabs offered to the user.
>
>
> Blink component Blink
> 
>
> TAG review N/A. This is just an addition of a single flag to an
> existing dictionary, following well-known patterns.
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/639) Jan-Ivar
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both 
> collaborated
> with us closely in shaping this PR. They have then approved merging this 
> PR
> into w3c/mediacapture-screen-share. This is implicit support, so I'd
> consider it POSITIVE even though, as of the time of this writing, the
> official request for position has not yet been answered.
>
> *WebKit*: Positive (
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032249.html)
> Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
> collaborated with us closely in shaping this PR. They have then approved
> merging this PR into w3c/mediacapture-screen-share. This is implicit
> support, so I'd consider it POSITIVE even though, as of the time of this
> writing, the official request for position has not yet been answered.
>

 Similar to other intents, this doesn't count as an official positive
 signal. Let's wait a few days to see if one emerges.


>
> *Web developers*: Positive Interest expressed by Google Meet.
>

 Any external signals from developers? https://goo.gle/developer-signals


>
> Security
>
> The current tab is the surface most under an attacker’s control.
> Nudging the user away from this risky surface is a good thing. Of course,
> malicious applications can avoid using this new control, or use it to
> retain the old behavior (current tab still offered). This is not a problem
> - it simply means that this new surface offers no degradation in security,
> although not a security feature in its own right.
>
>
> WebView application risks
>
> N/A
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)? No
>
> Supported on all platforms that support getDisplayMedia. Namely, all
> desktop platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5118675366445056
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/COid122-_AE
>
> 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
>>> 

Re: [blink-dev] Re: Intent to Ship: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

['Joe Medley' via blink-dev]

When do you hope to ship this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:14 AM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2022-06-22 17:42, Yoav Weiss wrote:
>
> LGTM2
>
> On Wednesday, June 22, 2022 at 5:41:51 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM1
>>
>> On Tue, Jun 14, 2022 at 4:11 AM 'Andy Paicu' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Sounds good, thank you for the clarifications.
>>>
>>> Kind Regards,
>>> Andy Paicu
>>>
>>>
>>> On Mon, Jun 13, 2022 at 8:18 PM Elad Alon  wrote:
>>>
 Hi Andy,

 How does the capturing web app (i.e. Meet) know what I want to do with
> audio?


 The capturing application might know that you're in a physical room and
 "presenting" to the equipment there.

- You use a special user-journey to trigger sharing to a room.
- The application could be "watermarking" audio coming in through
the room's speakers.
- You might have indicated a desire to suppress-local-audio through
in-content controls the application exposes.

 In either case, it is extremely likely that you only want to hear the
 audio only through one set of speakers. The application would be saving you
 effort by muting one set of speakers for you.

 This seems like it would be better under the control of the user


 Users can mute tabs manually. This new API surface will not prevent
 this.

 i.e. Meet


 It bears mentioning that Meet is currently using screen-sharing through
 an API which I am trying to deprecate. That API already hard-codes to
 *always* suppress-local-audio on a captured tab. The present new API
 surface improves on the state of the art by (i) making this conditional and
 (ii) exposing it to the Web at large.

 Thanks,
 Elad

 On Mon, Jun 13, 2022 at 8:02 PM Andy Paicu 
 wrote:

> A question came up when reviewing this, I'm hoping you can help
> clarify:
>
> How does the capturing web app (i.e. Meet) know what I want to do with
> audio? Would I not be able to achieve the same result by simply muting the
> tab or even just muting the device (since it seems unlikely that there are
> other sounds wanted from the local device when sharing a tab with audio)?
>
> This seems like it would be better under the control of the user
> instead of being a decision made by the application especially since I
> don't see a mention of how this would be presented to the user and/or
> potentially reverted by them.
>
> Kind Regards,
> Andy Paicu
>
> On Wednesday, June 1, 2022 at 9:40:02 AM UTC+2 Elad Alon wrote:
>
>> Similar to other intents, this doesn't count as an official positive
>>> signal. Let's wait a few days to see if one emerges.
>>
>>
>> Thanks. I've set a reminder to ping this thread in one week, as
>> suggested in the other intent thread.
>>
>> On Wed, Jun 1, 2022 at 8:42 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, May 25, 2022 at 2:44:01 PM UTC+2 Elad Alon wrote:
>>>
 Contact emails elad...@chromium.org

 Explainer
 https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing

 Specification
 https://github.com/w3c/mediacapture-screen-share/pull/164/files

 Summary

 Consider a Web application APP which is display-capturing a tab
 TAB. We add a mechanism by which APP may control whether the audio 
 playing
 in TAB would be played out of the user’s local speakers.


 Blink component Blink
 

 TAG review N/A. This is just an addition of a single flag to an
 existing dictionary, following well-known patterns.

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility *Gecko*: Positive (
 https://github.com/mozilla/standards-positions/issues/641)
 Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
 collaborated with us closely in shaping this PR. They have then 
 approved
 merging this PR into w3c/mediacapture-screen-share. This is implicit
 support, so I'd consider it POSITIVE even though, as of the time of 
 this
 writing, the official request for position has not yet been answered.

 *WebKit*: Positive (
 https://lists.webkit.org/pipermail/webkit-dev/2022-May/032252.html)
 Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
 collaborated with us closely in shaping 

Re: [blink-dev] Re: Intent to Ship: MediaTrackConstraintSet.displaySurface

['Joe Medley' via blink-dev]

When do you hope to ship this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:13 AM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2022-06-22 17:41, Yoav Weiss wrote:
>
> LGTM2
>
> On Wednesday, June 22, 2022 at 5:41:11 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM1
>>
>> On Wed, Jun 1, 2022 at 12:37 AM 'Elad Alon' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Thanks. I've set myself a reminder to ping this thread in one week, as
>>> suggested on the other intent thread.
>>>
>>> On Wed, Jun 1, 2022 at 8:42 AM Yoav Weiss 
>>> wrote:
>>>


 On Wednesday, May 25, 2022 at 2:47:50 PM UTC+2 Elad Alon wrote:

> Contact emails elada...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1uI51R4YfFQtfiDTw1KfnLqzIu45OgxhYoUT7khlhmwQ/edit?usp=sharing
>
> Specification
> https://github.com/w3c/mediacapture-screen-share/pull/186/files
>
> Summary
>
> When getDisplayMedia() is called, the browser offers the user a choice
> of display surfaces - tabs, windows and monitors. Using the displaySurface
> constraint, the Web application may now hint to the browser if it prefers
> that a certain surface type be more prominently offered to the user.
>
>
> Blink component Blink
> 
>
> TAG review N/A. This is just an addition of a single flag to an
> existing dictionary, following well-known patterns.
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/642) Jan-Ivar
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both 
> collaborated
> with us closely in shaping this PR. They have then approved merging this 
> PR
> into w3c/mediacapture-screen-share. This is implicit support, so I'd
> consider it POSITIVE even though, as of the time of this writing, the
> official request for position has not yet been answered.
>
> *WebKit*: Positive (
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032253.html)
> Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
> collaborated with us closely in shaping this PR. They have then approved
> merging this PR into w3c/mediacapture-screen-share. This is implicit
> support, so I'd consider it POSITIVE even though, as of the time of this
> writing, the official request for position has not yet been answered.
>

 Similar to other intents, this doesn't count as an official positive
 signal. Let's wait a few days to see if one emerges.


>
> *Web developers*: Positive See Appendix I of the internal design doc:
> https://docs.google.com/document/d/1U_aNptMZuYFuFWu7leq43V3hqOQ9zMEumG3x413q2pY/edit#heading=h.693jj8mh4gkw
>
> *Other signals*:
>
> WebView application risks
>
> N/A
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)? No
>
> Supported on all platforms that support getDisplayMedia. Namely, all
> desktop platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1224912
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure 
> of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5186392840732672
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/bVVEn-TOTYs
>
> 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/CAMO6jDPv1P9YEEKwt8pTeqSU0wT%2BdyY%2BkwyagovrtFT00c--FQ%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to Prototype and Ship: Response.json()

['Joe Medley' via blink-dev]

Adam,

When are you hoping to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 8:56 AM Philip Jägenstedt 
wrote:

> LGTM3
>
> The TAG review has been sitting for a month now, and this proposal has
> already received scrutiny in the spec discussion. If there's feedback (on
> naming or otherwise) before this reaches stable, we should take it into
> account.
>
> On Wed, Jun 22, 2022 at 5:54 PM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> On Wednesday, June 22, 2022 at 5:53:49 PM UTC+2 Chris Harrelson wrote:
>>
>>> LGTM1
>>>
>>> On Tue, May 31, 2022 at 11:08 PM Yoav Weiss 
>>> wrote:
>>>


 On Tue, May 31, 2022 at 4:08 AM Adam Rice  wrote:

> Contact emailsri...@chromium.org, yhir...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit
>
> Specificationhttps://fetch.spec.whatwg.org/#ref-for-dom-response-json
>
> Summary
>
> Improves ergonomics for creating JSON Response objects. The Response
> constructor allows for creating the body of the response from many types,
> however it is not possible to directly create a JSON object. The
> Response.json() static method fills this gap. It returns a Response object
> with a body consisting the first argument serialized as JSON. The second
> argument is a ResponseInit option bag as with the Response constructor.
>
>
> Blink componentBlink>Network>FetchAPI
> 
>
> Motivation
>
> Creating a Response object with a body of a JSON object has been
> harder than the other types supported by Fetch. This change improves the
> ergonomics of creating a JSON response.
>
>
> Initial public proposalhttps://github.com/whatwg/fetch/issues/1389
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/741
>

 The TAG review issue says they'd look into this next week. Given the
 fact that the issue was filed a couple of weeks ago, it seems reasonable to
 wait till then.


>
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low as Deno and Node have already implemented
> the feature, and it is a simple addition to the API. We know of no
> compatibility risk. It could happen if someone is using a polyfill with an
> incompatible API, but that is unlikely.
>
>
> *Gecko*: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/640)
>
> *WebKit*: Positive (
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032254.html)
>
> *Web developers*: Positive (
> https://github.com/whatwg/fetch/issues/1389) Example positive
> feedback:
> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024726318 
> Example
> negative feedback:
> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024880489
>

 Great feedback from developers!!


>
>
> *Other signals*:
>
> Ergonomics
>
> This is a convenience function that is purely an ergonomic improvement.
>
>
> Activation
>
> The feature can be easily polyfilled.
>
>
> Security
>
> The feature adds no capabilities that developers don't already have.
> The implementation mostly reuses existing logic, reducing the security 
> risk.
>
>
> 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?
>
> No
>
>
> Debuggability
>
> Automatically supported as a feature implemented in WebIDL.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1305358
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> No
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5197912798658560
>
> 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 

Re: [blink-dev] Intent to Prototype: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

['Joe Medley' via blink-dev]

What do you think about saying in the summary that we're hoping to
deprecate default access to window.ondevice{motion,orientation} in the
future?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Jun 21, 2022 at 1:57 PM Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> Correct. The larger plan is to:
> - Require requestPermission() before window.ondevice{motion,orientation}
> start dispatching events
> - Change the UI side to prompt for sensor access when necessary
> - Do the same as part of Sensor.start() (meaning Accelerometer.start() etc)
>
> How to get there without breaking websites that do not use
> requestPermission() is something we are still working out and that will not
> happen in the short term.
>
> On 21-06-2022 19:45, Joe Medley wrote:
>
> "these new functions are part of the plan to start prompting for access in
> the future."
>
> Can I assume this means you're going to deprecate default access
> to window.ondevice{motion,orientation} at some point?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Jun 20, 2022 at 6:15 AM Raphael Kubo da Costa <
> raphael.kubo.da.co...@intel.com> wrote:
>
>> Contact emails raphael.kubo.da.co...@intel.com, eng...@chromium.org,
>> reil...@chromium.org
>>
>> Explainer None
>>
>> Specification https://w3c.github.io/deviceorientation
>>
>> Summary
>>
>> Allows developers to ask for permission to start using the Device
>> Orientation and Device Motion APIs. Access to these APIs is currently
>> granted by default, and these new functions are part of the plan to start
>> prompting for access in the future.
>>
>>
>> Blink component Blink>Sensor>DeviceOrientation
>> 
>>
>> Motivation
>>
>> The Device Orientation spec is more than a decade old, at a time when
>> integration with the Permissions spec was not common (or possible). As
>> such, developers can use the window.ondevice{motion,orientation} events
>> without having to ask for permission before reading sensor data. A few
>> years ago, the WebKit team added the requestPermission() functions to
>> DeviceOrientationEvent and DeviceMotionEvent when implementing the spec, so
>> that websites would have to ask for permission before being able to use the
>> API. This is the case on Safari for iOS at the moment. We want to do the
>> same thing and avoid allowing websites access to sensor data by default.
>> Doing this in Chromium is more complicated because the API is already
>> implemented, and requiring developers to add requestPermission() to their
>> websites out of the blue can risk breaking the web. In this first step, the
>> idea is to just add the API and make it report "granted" or "denied"
>> without prompting for access (i.e. it just reports the current Motion
>> Sensor permission settings) while also adding user counters to understand
>> how many pages are already using the requestPermission() calls and how many
>> pages are just using window.ondevice{motion,orientation} without it. We
>> will then evaluate how to switch to prompting by default in the future, as
>> discussed in the tracking bug.
>>
>>
>> Initial public proposal
>>
>> Search tags device orientation
>> , device
>> motion 
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Under consideration (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1536382)
>>
>> *WebKit*: Shipped/Shipping (
>> https://bugs.webkit.org/show_bug.cgi?id=195329)
>>
>> *Web developers*: No signals
>>
>> *Other signals*: Lots of comments in the Chromium tracking bug over the
>> years
>>
>> 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?
>>
>>
>> Debuggability
>>
>> -
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes (as part of the CL I am working on)
>>
>> Flag name
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=947112
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5051845089689600
>>
>> 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 

Re: [blink-dev] Intent to Prototype: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

['Joe Medley' via blink-dev]

"these new functions are part of the plan to start prompting for access in
the future."

Can I assume this means you're going to deprecate default access
to window.ondevice{motion,orientation} at some point?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Jun 20, 2022 at 6:15 AM Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> Contact emails raphael.kubo.da.co...@intel.com, eng...@chromium.org,
> reil...@chromium.org
>
> Explainer None
>
> Specification https://w3c.github.io/deviceorientation
>
> Summary
>
> Allows developers to ask for permission to start using the Device
> Orientation and Device Motion APIs. Access to these APIs is currently
> granted by default, and these new functions are part of the plan to start
> prompting for access in the future.
>
>
> Blink component Blink>Sensor>DeviceOrientation
> 
>
> Motivation
>
> The Device Orientation spec is more than a decade old, at a time when
> integration with the Permissions spec was not common (or possible). As
> such, developers can use the window.ondevice{motion,orientation} events
> without having to ask for permission before reading sensor data. A few
> years ago, the WebKit team added the requestPermission() functions to
> DeviceOrientationEvent and DeviceMotionEvent when implementing the spec, so
> that websites would have to ask for permission before being able to use the
> API. This is the case on Safari for iOS at the moment. We want to do the
> same thing and avoid allowing websites access to sensor data by default.
> Doing this in Chromium is more complicated because the API is already
> implemented, and requiring developers to add requestPermission() to their
> websites out of the blue can risk breaking the web. In this first step, the
> idea is to just add the API and make it report "granted" or "denied"
> without prompting for access (i.e. it just reports the current Motion
> Sensor permission settings) while also adding user counters to understand
> how many pages are already using the requestPermission() calls and how many
> pages are just using window.ondevice{motion,orientation} without it. We
> will then evaluate how to switch to prompting by default in the future, as
> discussed in the tracking bug.
>
>
> Initial public proposal
>
> Search tags device orientation
> , device
> motion 
>
> TAG review
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Under consideration (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1536382)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=195329
> )
>
> *Web developers*: No signals
>
> *Other signals*: Lots of comments in the Chromium tracking bug over the
> years
>
> 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?
>
>
>
> Debuggability
>
> -
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes (as part of the CL I am working on)
>
> Flag name
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=947112
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5051845089689600
>
> 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/a7bfbf70-0cbf-709f-6310-7af1101c2574%40intel.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/CAJUhtG_eM5XrS4QsfFwoLMC1ayx7gJ5pENyNc%3DBT6NsEnreYbQ%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

['Joe Medley' via blink-dev]

What's an 'off by default experiment'? Are you adding an item to
chrome://flags or is it something else?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Sun, Jun 19, 2022 at 9:31 PM 'Fergal Daly' via blink-dev <
blink-dev@chromium.org> wrote:

> Sorry, there were some details left out of this I2E. We actually have a
> lot of signals from web devs on this. There are some comments on
>
>
> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
>
> but we also presented this to W3C WebPerf with a lot of positive signals.
> Minutes are here
>  
> from
> the most recent one.
>
> We don't have any reaction from Mozilla or WebKit that I know of and we
> will file a TAG request shortly,
>
> F
>
> On Sat, 18 Jun 2022 at 02:57, Mike Taylor  wrote:
>
>> On 6/17/22 10:59 AM, Ming-Ying Chung wrote:
>>
>> Contact emails
>>
>> m...@chromium.org, fer...@chromium.org, denom...@chromium.org
>>
>> Explainer
>>
>> https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md
>>
>> Specification
>>
>> https://clelland.github.io/page-unload-beacon/spec.html (In draft state)
>>
>> Summary
>>
>> A stateful API for beacons that has the browser control the time beacons
>> are sent.
>>
>> Existing beacon APIs are all based around a developer constructing and
>> sending a beacon, and there's no good time for that "send" call to be made.
>> (Handlers such as 'unload' are often ignored, for example.) This API
>> delegates the sending to the browser itself, so it can support beacons on
>> page unload or on page hide, without the developer having to implement send
>> calls at exactly the right times.
>>
>>
>> Blink component
>>
>> Blink>Network
>> 
>>
>> TAG review
>>
>> None yet.
>>
>> I'd recommend filing a TAG review as well as asking for signals now, to
>> allow folks plenty of time to respond.
>>
>> TAG review status
>>
>> N/A
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> 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?
>>
>>
>> Goals for experimentation
>>
>> The intent is for experiments to learn that developers can easily adopt
>> the API shapes to achieve current use cases in addition to getting feedback
>> from them. The experiment also aims to test the stability and reliability
>> of the API.
>>
>> Ongoing technical constraints
>>
>> In M104, the API described in the explainer is not yet fully developed,
>> such that the API
>>
>>-
>>
>>Supports only the GET method. Setting it to POST will fall back to
>>GET.
>>-
>>
>>Does not support request payload, i.e. it does not send out data set
>>by setData(data).
>>-
>>
>>Does not support pageHideTimeout.
>>-
>>
>>Does not recover from browser crashes, forced closures, network
>>failure, etc.
>>
>>
>> Debuggability
>>
>> There are no particular debugging APIs made available or Chrome DevTools
>> integrations for this OT. We plan to build an integration with Chrome
>> DevTools to provide a better developer experience. This OT will allow us to
>> get feedback that helps us build the right design.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No, basic tests are present and we will be adding more as we complete
>> more of the implementation.
>>
>> Flag name
>>
>> PendingBeaconAPI
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1293679
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1323615
>>
>> Estimated milestones
>>
>> M104 for off-by-default experiment
>>
>> Just to confirm, the request is only for a single milestone (104)?
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5690553554436096
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com
>> 
>>
>>
>> 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 

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

['Joe Medley' via blink-dev]

Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Jun 21, 2022 at 8:14 AM Khushal Sagar 
wrote:

> Quick update, the feature is supported on WebView starting in M105.
> Depending on the progress of OT support for WebView (here
> ),
> the feature will be available for OT on WebView for 105-106 (inclusive).
>
> On Tue, Jun 14, 2022 at 10:29 AM Khushal Sagar 
> wrote:
>
>>
>>
>> On Mon, Jun 13, 2022, 1:26 PM Joe Medley  wrote:
>>
>>> Is the experiment 103 to 106 or 104 to 107.
>>>
>>
>> It's 104-106 (inclusive). The last date is October 18, 2022.
>>
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Jun 13, 2022 at 8:49 AM 'Hannah Van Opstal' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hi Nicola,

 This experimentation is still for the same-origin case.
 The difference is in the shape of the API. The first intent was
 approved for the API when it was using Viz. With Viz Shared
 Element Transitions, we did an origin trial where we received some feedback
 that led us to change it to use the renderer. So this new intent would be
 intended for the newer shape - i.e. renderer SET.

 Please let me know if we can provide any more details.

 Hannah





 On Mon, Jun 13, 2022 at 7:16 AM Nicola Tommasi 
 wrote:

> Hi API owners,
>
> This intent seems to be already approved in the past for same-origin
> experimentation, is this launch intended for the cross-origin case?If not,
> what's exactly in the scope for this particular launch?
>
> Thanks,
> Nicola
>
> On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:
>
>> LGTM to experiment M103-M106
>>
>> Thanks for working on this! I'm super excited about the possibilities
>> this will open!!
>>
>> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar <
>> khushalsa...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar <
>>> khushalsa...@chromium.org> wrote:
>>>
 Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
 hvanops...@chromium.org

 Explainer
 https://github.com/WICG/shared-element-transitions/blob/main/explainer.md

 Specification
 https://tabatkins.github.io/specs/css-shared-element-transitions

 Design docs

 https://github.com/WICG/shared-element-transitions/blob/main/explainer.md

 Summary

 Shared Element Transitions is a proposal for a new script API that
 allows a simple set of transitions in both Single-Page Applications 
 (SPAs)
 and Multi-Page Applications (MPAs). This feature enhances the visual 
 polish
 of pages without requiring a large development effort from developers 
 to
 make transitions look nice. By selecting from a set of user-agent
 implemented transition effects, the developers can achieve a polished
 transition look with minimal effort.


 Blink componentBlink>Animation
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631

 TAG review statusPending

 Link to origin trial feedback summary
 https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173

 Risks

 Interoperability and Compatibility

 Low. As a new feature, the risk here is that other browsers do not
 implement it, but since this is a progressive enhancement, sites 
 should be
 able to drop usage of the feature easily in browsers where it is not
 supported.

 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: Strongly positive
 Interest and developer experiments with the API:

 https://twitter.com/jaffathecake/status/1524782819431555074?t=itU6B0wo6SbjomGiSKLmGQ=19

 https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/

 https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw=19

 https://css-tricks.com/spas-shared-element-transitions-and-re-evaluating-technology/

 *Other signals*:

 Ergonomics

 None.

 Activation

 Low. As with interop/compat risks, 

Re: [blink-dev] Intent to Deprecate and Remove: Gesture Scroll DOM events

['Joe Medley' via blink-dev]

FYI, the status entry would have let you generate the text for the intent.
The marginal cost for using the status entry is small, but it boosts the
profile of the deprecation/removal. Most deprecations/removals are pretty
insignificant, but we don't like to assume that no one needs to know about
it.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Jun 14, 2022 at 7:54 AM Joe Medley  wrote:

> Yes, that is correct.
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Jun 13, 2022 at 11:12 AM Steve Kobes  wrote:
>
>> On Mon, Jun 13, 2022 at 1:19 PM Joe Medley  wrote:
>>
>>> What are the milestones for deprecation and removal?
>>>
>>
>> This removal is on track for M105.
>>
>>
>>> Also does this have a status entry? I can't find one.
>>>
>>
>> That's my fault, I had advised Mehdi that I did not think a chromestatus
>> entry was needed here.
>>
>> For my understanding: is it our policy to have a status entry for all
>> removals (even if minor)?
>>
>>
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Thu, Jun 9, 2022 at 9:11 AM Mehdi Kazemi 
>>> wrote:
>>>
 Contact emails


 *sko...@chromium.org ,mehd...@chromium.org
 ,blink-interactions-t...@google.com
 *Explainer


 *None*Specification

 None. Not a standard feature.

 Summary

 Gesture Scroll DOM events, namely “gesturescrollstart”,
 “gesturescrollupdate” and “gesturescrollend” are non-standard APIs, which
 were added to Blink for use in plugins, but it appears they were also
 exposed to the web unintentionally. Plugins are no longer web-exposed since
 the deprecation of Google Native Client (NaCl).

 WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=92281

 Changelog:
 https://bugs.webkit.org/attachment.cgi?id=155046=prettypatch

 Motivation

 Currently, this API doesn’t work in all situations. It only works when
 there is a *non-composited scroller*. These events are related to
 compositing state, and compositing state is not meant to have observable
 behavior impact and in Blink will vary depending on display type and other
 factors.


 Blink component

 Blink>Scroll
 


 TAG review


 TAG review status

 Not applicable


 Risks

 No other engine supports these events, so we do not expect
 interoperability issues.

 As for compatibility, usage data from Canary, Dev and Beta channels
 show that usage is very low, around 0.15% (gesturescrollstart
 
 gesturescrollupdate
 
 gesturescrollend
 ).
 For this reason we would like to just remove it, without any deprecation
 period.


 Is this feature fully tested by web-platform-tests
 
 ?

 No


 Requires code in //chrome?

 False


 Tracking bug

 https://crbug.com/1293994
 


 Estimated milestones

 No milestones specified






 --
 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/CAASN_%3DmnFnKhp7WQNYiVztF%3Dhr1jpzSTo1x02nXZtysnO2GUMQ%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/CAJUhtG-emwR3w9N9uigiWneC%2BNMoRD9Z%2Bqg-jLZR%3DT-BFyX1yg%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Gesture Scroll DOM events

['Joe Medley' via blink-dev]

Yes, that is correct.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Jun 13, 2022 at 11:12 AM Steve Kobes  wrote:

> On Mon, Jun 13, 2022 at 1:19 PM Joe Medley  wrote:
>
>> What are the milestones for deprecation and removal?
>>
>
> This removal is on track for M105.
>
>
>> Also does this have a status entry? I can't find one.
>>
>
> That's my fault, I had advised Mehdi that I did not think a chromestatus
> entry was needed here.
>
> For my understanding: is it our policy to have a status entry for all
> removals (even if minor)?
>
>
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Jun 9, 2022 at 9:11 AM Mehdi Kazemi  wrote:
>>
>>> Contact emails
>>>
>>>
>>> *sko...@chromium.org ,mehd...@chromium.org
>>> ,blink-interactions-t...@google.com
>>> *Explainer
>>>
>>>
>>> *None*Specification
>>>
>>> None. Not a standard feature.
>>>
>>> Summary
>>>
>>> Gesture Scroll DOM events, namely “gesturescrollstart”,
>>> “gesturescrollupdate” and “gesturescrollend” are non-standard APIs, which
>>> were added to Blink for use in plugins, but it appears they were also
>>> exposed to the web unintentionally. Plugins are no longer web-exposed since
>>> the deprecation of Google Native Client (NaCl).
>>>
>>> WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=92281
>>>
>>> Changelog:
>>> https://bugs.webkit.org/attachment.cgi?id=155046=prettypatch
>>>
>>> Motivation
>>>
>>> Currently, this API doesn’t work in all situations. It only works when
>>> there is a *non-composited scroller*. These events are related to
>>> compositing state, and compositing state is not meant to have observable
>>> behavior impact and in Blink will vary depending on display type and other
>>> factors.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Scroll
>>> 
>>>
>>>
>>> TAG review
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>>
>>> Risks
>>>
>>> No other engine supports these events, so we do not expect
>>> interoperability issues.
>>>
>>> As for compatibility, usage data from Canary, Dev and Beta channels show
>>> that usage is very low, around 0.15% (gesturescrollstart
>>> 
>>> gesturescrollupdate
>>> 
>>> gesturescrollend
>>> ).
>>> For this reason we would like to just remove it, without any deprecation
>>> period.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1293994
>>> 
>>>
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/CAASN_%3DmnFnKhp7WQNYiVztF%3Dhr1jpzSTo1x02nXZtysnO2GUMQ%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/CAJUhtG9HPmjcOZPFM3KZy_0V-QfJASHQWLw4BBfXC5bF-1cWdA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

['Joe Medley' via blink-dev]

Is the experiment 103 to 106 or 104 to 107.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Jun 13, 2022 at 8:49 AM 'Hannah Van Opstal' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Nicola,
>
> This experimentation is still for the same-origin case.
> The difference is in the shape of the API. The first intent was approved
> for the API when it was using Viz. With Viz Shared Element Transitions, we
> did an origin trial where we received some feedback that led us to change
> it to use the renderer. So this new intent would be intended for the newer
> shape - i.e. renderer SET.
>
> Please let me know if we can provide any more details.
>
> Hannah
>
>
>
>
>
> On Mon, Jun 13, 2022 at 7:16 AM Nicola Tommasi 
> wrote:
>
>> Hi API owners,
>>
>> This intent seems to be already approved in the past for same-origin
>> experimentation, is this launch intended for the cross-origin case?If not,
>> what's exactly in the scope for this particular launch?
>>
>> Thanks,
>> Nicola
>>
>> On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:
>>
>>> LGTM to experiment M103-M106
>>>
>>> Thanks for working on this! I'm super excited about the possibilities
>>> this will open!!
>>>
>>> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar 
>>> wrote:
>>>


 On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar 
 wrote:

> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
> hvanops...@chromium.org
>
> Explainer
> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>
> Specification
> https://tabatkins.github.io/specs/css-shared-element-transitions
>
> Design docs
>
> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>
> Summary
>
> Shared Element Transitions is a proposal for a new script API that
> allows a simple set of transitions in both Single-Page Applications (SPAs)
> and Multi-Page Applications (MPAs). This feature enhances the visual 
> polish
> of pages without requiring a large development effort from developers to
> make transitions look nice. By selecting from a set of user-agent
> implemented transition effects, the developers can achieve a polished
> transition look with minimal effort.
>
>
> Blink componentBlink>Animation
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>
> TAG review statusPending
>
> Link to origin trial feedback summary
> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>
> Risks
>
> Interoperability and Compatibility
>
> Low. As a new feature, the risk here is that other browsers do not
> implement it, but since this is a progressive enhancement, sites should be
> able to drop usage of the feature easily in browsers where it is not
> supported.
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Strongly positive
> Interest and developer experiments with the API:
>
> https://twitter.com/jaffathecake/status/1524782819431555074?t=itU6B0wo6SbjomGiSKLmGQ=19
>
> https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/
>
> https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw=19
>
> https://css-tricks.com/spas-shared-element-transitions-and-re-evaluating-technology/
>
> *Other signals*:
>
> Ergonomics
>
> None.
>
> Activation
>
> Low. As with interop/compat risks, the difficulty stems from this
> being a new feature without support in other browsers. A polyfill for the
> SPA case would be beneficial, but it will not be possible to polyfill MPA
> behavior. That said, dropping the customized transition should not impact
> the usability of a site, fundamentally, so this can easily be dropped on
> browsers that do not support the feature.
>
> Security
>
> The primary security constraint is ensuring isolation of graphics
> resources from multiple origins. The design achieves that using Chromium's
> Viz process similar to OOPIFs.
>
> See also the security and privacy self-review questionnaire that was
> completed as part of the TAG review process:
> https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
>
> 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?
>
>
>
> Goals for experimentation
>
> Learning from the feedback from the previous OT, the API has been
> updated to 

Re: [blink-dev] Intent to Deprecate and Remove: Gesture Scroll DOM events

['Joe Medley' via blink-dev]

What are the milestones for deprecation and removal? Also does this have a
status entry? I can't find one.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jun 9, 2022 at 9:11 AM Mehdi Kazemi  wrote:

> Contact emails
>
>
> *sko...@chromium.org ,mehd...@chromium.org
> ,blink-interactions-t...@google.com
> *Explainer
>
>
> *None*Specification
>
> None. Not a standard feature.
>
> Summary
>
> Gesture Scroll DOM events, namely “gesturescrollstart”,
> “gesturescrollupdate” and “gesturescrollend” are non-standard APIs, which
> were added to Blink for use in plugins, but it appears they were also
> exposed to the web unintentionally. Plugins are no longer web-exposed since
> the deprecation of Google Native Client (NaCl).
>
> WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=92281
>
> Changelog:
> https://bugs.webkit.org/attachment.cgi?id=155046=prettypatch
>
> Motivation
>
> Currently, this API doesn’t work in all situations. It only works when
> there is a *non-composited scroller*. These events are related to
> compositing state, and compositing state is not meant to have observable
> behavior impact and in Blink will vary depending on display type and other
> factors.
>
>
> Blink component
>
> Blink>Scroll
> 
>
>
> TAG review
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
> No other engine supports these events, so we do not expect
> interoperability issues.
>
> As for compatibility, usage data from Canary, Dev and Beta channels show
> that usage is very low, around 0.15% (gesturescrollstart
> 
> gesturescrollupdate
> 
> gesturescrollend
> ). For
> this reason we would like to just remove it, without any deprecation period.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://crbug.com/1293994
> 
>
>
> Estimated milestones
>
> No milestones specified
>
>
>
>
>
>
> --
> 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/CAASN_%3DmnFnKhp7WQNYiVztF%3Dhr1jpzSTo1x02nXZtysnO2GUMQ%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/CAJUhtG9MXmxQSb20Egk9ZiszphThV2hTo-7FATKhugYG4ZrqFQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Independent/Individual Properties for CSS Transforms

['Joe Medley' via blink-dev]

Thank you.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Jun 6, 2022 at 9:01 PM David Baron  wrote:

> Despite considerably more delay (in getting the dependencies for
> compositor animation landed) than I was expecting when I posted the intent
> to ship... this is now on track to ship in Chrome 104.  (And I've updated
> chromestatus accordingly.)
>
> -David
>
> On Wed, Oct 27, 2021 at 1:26 PM Joe Medley  wrote:
>
>> Hi,
>>
>> In which version of Chrome do you hope to ship?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Oct 21, 2021 at 12:03 PM Manuel Rego Casasnovas 
>> wrote:
>>
>>> LGTM3.
>>>
>>> On 21/10/2021 19:53, Daniel Bratell wrote:
>>> > LGTM2.
>>> >
>>> > /Daniel
>>> >
>>> > On 2021-10-21 08:19, Yoav Weiss wrote:
>>> >> LGTM1
>>> >> Seems important to catch up here, so thanks for working on this!!
>>> >>
>>> >> On Mon, Oct 18, 2021 at 11:05 PM David Baron 
>>> wrote:
>>> >>
>>> >>
>>> >> Contact emails
>>> >>
>>> >>
>>> >> dba...@chromium.org, kev...@chromium.org,
>>> fla...@chromium.org
>>> >>
>>> >>
>>> >> Explainer
>>> >>
>>> >>
>>> >> None
>>> >>
>>> >>
>>> >> Specification
>>> >>
>>> >>
>>> >>
>>> https://drafts.csswg.org/css-transforms-2/#individual-transforms
>>> >>
>>> >>
>>> >> Summary
>>> >>
>>> >>
>>> >> This adds three new CSS properties: translate, rotate, and
>>> >> scale. This exposes a simple way for web developers to
>>> >> access transforms in an intuitive way, without having to
>>> >> think about how functions in the transform property
>>> >> interact with each other. The properties are individually
>>> >> animatable.
>>> >>
>>> >>
>>> >>
>>> >> Blink component
>>> >>
>>> >>
>>> >> Blink
>>> >> <
>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>> >>
>>> >>
>>> >> TAG review
>>> >>
>>> >>
>>> >> Already shipped in two browser engines.
>>> >>
>>> >>
>>> >> TAG review status
>>> >>
>>> >>
>>> >> Not applicable (I think)
>>> >>
>>> >>
>>> >> Risks
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Interoperability and Compatibility
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Gecko: Shipped/Shipping
>>> >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
>>> >> Shipped in Firefox 72, January 2020.
>>> >>
>>> >> WebKit: Shipped/Shipping
>>> >> (
>>> https://webkit.org/blog/11420/css-individual-transform-properties/)
>>> >> Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.
>>> >>
>>> >> Web developers: Positive: 25 stars
>>> >> on
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
>>> >> Notable early developer request for the feature (before WG
>>> >> adoption)
>>> >> in:
>>> https://twitter.com/rachelnabors/status/618266391993454592
>>> https://twitter.com/rachelnabors/status/618267483296825344 and
>>> >> early reaction to WG adoption
>>> >> in
>>> https://twitter.com/SaraSoueidan/status/613368671315054592 .
>>> >> Positive developer reactions
>>> >> to
>>> https://twitter.com/argyleink/status/1338907239990497280 .
>>> >> Largely positive reactions to news of other engines
>>> >> shipping the feature in responses
>>> >> to
>>> https://twitter.com/jensimmons/status/1387870244392382468 ,
>>> https://twitter.com/simevidas/status/627956718098485248 ,
>>> https://twitter.com/dancwilson/status/121457225783989862 ,
>>> >> and
>>> >> in
>>> https://twitter.com/guerriero_se/status/1338468028804001796 ,
>>> https://twitter.com/eladsc/status/1216286886697885696 ,
>>> https://twitter.com/_zouhir/status/1389461399026294791 .
>>> >> More recent developer interest
>>> >> in
>>> https://twitter.com/anatudor/status/1377491818636587008 ,
>>> https://twitter.com/anatudor/status/1309200388311199751 .
>>> >>
>>> >>
>>> >> Debuggability
>>> >>
>>> >>
>>> >> Has the standard exposure in devtools that all CSS
>>> >> properties have.
>>> >>
>>> >>
>>> >>
>>> >> Is this feature fully tested by web-platform-tests
>>> >> <
>>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
>>> >?
>>> >>
>>> >>
>>> >> Yes
>>> >>
>>> >>
>>> >> Flag name
>>> >>
>>> >>
>>> >> CSSIndependentTransformProperties
>>> >>
>>> >>
>>> >> Requires code in //chrome?
>>> >>
>>> >>
>>> >> False
>>> >>
>>> >>
>>> >> 

Re: [blink-dev] Re: Intent to Ship: Subresource loading with Web Bundles

['Joe Medley' via blink-dev]

Is this shipping in 105? Please add that to the status entry.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 1, 2022 at 2:03 AM Hayato Ito  wrote:

> Thanks all, for your support and the LGTMs.
>
> I appreciate the API owners, the Mozilla folks and the others, who
> reviewed this feature carefully and gave us the advice to make this feature
> interoperable and be an important step on future improvements on the Web
> Platform.
>
> I'll continue to invest in standards. Thanks!
>
> On Wed, Jun 1, 2022 at 2:11 PM Yoav Weiss  wrote:
>
>> LGTM3
>>
>> I was similarly convinced by the team's efforts and by various folks
>> chiming in that this has a good chance of reaching eventual interop on its
>> own. The use cases this tackles span origin isolation, delivery and
>> performance (despite the lack of cache awareness in the current version),
>> and I'm hopeful that this would be an important stepping stone on which
>> future improvements will be built. Thanks!!
>>
>> On Wed, Jun 1, 2022 at 4:15 AM Chris Harrelson 
>> wrote:
>>
>>> LGTM2
>>>
>>> Web bundles team: thank you for your thoroughness in responding to
>>> concerns raised in the TAG review, Mozilla standards position, and various
>>> offline conversations. I also appreciate those who weighed in on the thread
>>> with additional sites that would use this feature, and the multiple use
>>> cases mentioned.
>>>
>>> At first, I was concerned about the risk of not achieving eventual
>>> interoperability, because of the limited data from experimenting sites and
>>> mixed or possibly negative signals from other browser vendors. The
>>> additional data mentioned above, on top of the existing ads-related use
>>> case from the original intent, and coupled with my belief that the team
>>> will continue to invest in standards in this area, leads me to conclude
>>> that this feature is worth shipping now.
>>>
>>>
>>> On Wed, May 25, 2022 at 8:37 AM Alex Russell 
>>> wrote:
>>>
 There are high-scale operational challenges to distributing content
 optimally in many scenarios (e.g., Store packaged first-run or
 out-of-the-box-experiences) that need more than what Service Workers alone
 can provide. We are positive about this technology because it can help
 address those problems and open up new product opportunities (that we
 cannot say more about).

 Best Regards,

 Alex

 On Tuesday, May 24, 2022 at 10:26:28 AM UTC-7 bema...@microsoft.com
 wrote:

> >>  You could have used a service worker and cache things in order to
> get the same thing, combined with progressive web applications for
> installability.
>
> This is true, but I think ergonomics of an encapsulated
> page/application make it easier to reason about for very large
> applications. Maintaining the service worker and the cache at scale can
> become a barrier to entry for some developers and applications.
>
> On Tuesday, May 24, 2022 at 10:12:33 AM UTC-7 PhistucK wrote:
>
>> Not that I am against, but does this unlock previously locked
>> opportunities in the specific examples you just mentioned?
>> You could have used a service worker and cache things in order to get
>> the same thing, combined with progressive web applications for
>> installability.
>>
>> ☆*PhistucK*
>>
>>
>> On Tue, May 24, 2022 at 4:35 PM 'Ben Mathwig' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Microsoft has a strong interest in seeing this feature ship. We
>>> believe that sub-resource bundling is opening the door to a new way of
>>> shipping and delivering offline web applications, changing the 
>>> traditional
>>> definition of “web application”.
>>>
>>> Here are some ways Microsoft products can take advantage of this:
>>>
>>> *PowerApps*
>>>
>>> Microsoft PowerApps allows a developer to author an application and
>>> deploy to iOS, Android, and the web. The first two platforms allow
>>> applications to be deployed and used when the device is offline, but the
>>> latter is currently not “installable” on the device. Web bundling could
>>> unlock the capability for a web application to be “installed” on a 
>>> device
>>> to operate offline.
>>>
>>> *Office Online*
>>>
>>> Office productivity web applications are a perfect example of
>>> applications that could benefit from a packaged bundle of application
>>> resources. Combined with local storage APIs, this could help developers
>>> reach communities that have little to no network connectivity.
>>>
>>>
>>>
>>> While there have been concerns brought up by the community, we
>>> welcome the opportunity to collaborate on addressing these issues in the
>>> next iteration of this project. We feel confident we can resolve them 

Re: [blink-dev] Re: Intent to Prototype: [WebRTC] Deprecate and Remove mediaConstraint's googIPv6

['Joe Medley' via blink-dev]

Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, May 18, 2022 at 2:14 AM Henrik Boström  wrote:

> Hey thanks, delay in response due to vacation but I'm back now.
>
> > According to followup to the request, the deprecation message is already
> in 102, possibly without ever having been documented. I don't know if you
> want to mention it in 103 instead.
>
>  The deprecation warning I added in M102 did not mention any specific
> timeline, only that it is deprecated and one should stop using it.
> I did sent out a PSA on a webrtc specific google group but this is the
> first I am writing about it on blink-dev, sorry if I skipped a step there.
>
> > I have you down for 108.
>
> Perfect.
>
> > Make sure you you add the removal date to the deprecation message if
> it's not already there.
>
> I will update the message to say M108 as the target.
>
>
> On Monday, May 16, 2022 at 5:01:34 PM UTC+2 Joe Medley wrote:
>
>> I really can't. That's why I have to be such a nag about when something
>> is going out.
>>
>> I have you down for 108.
>>
>> Thanks.
>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, May 12, 2022 at 1:50 PM Daniel Bratell  wrote:
>>
>>> (not the implementor) According to followup to the request, the
>>> deprecation message is already in 102, possibly without ever having been
>>> documented. I don't know if you want to mention it in 103 instead.
>>>
>>> The removal we approved is for 108.
>>>
>>> /Daniel
>>>
>>>
>>> On 2022-05-12 16:59, 'Joe Medley' via blink-dev wrote:
>>>
>>> Pinging this again. In two weeks I need to write what's in 103 beta on
>>> https://blog.chromium.org (https://blog.chromium.org/search/label/beta).
>>> Will deprecation be in 103?
>>>
>>> On Tuesday, May 10, 2022 at 12:27:49 PM UTC-7 jmedley via Chromestatus
>>> wrote:
>>>
>>>> In which version are you hoping to deprecate? remove?
>>>>
>>> --
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%40chromium.org?utm_medium=email_source=footer>
>>> .
>>>
>>>

-- 
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/CAJUhtG-DzBmcudbsT-fxruSGtdM%2BUbMqxFHj436Cjy158%3D%3Dq9w%40mail.gmail.com.

[blink-dev] Re: [webkit-dev] Intent to Remove: Legacy Client Hint Mode

['Joe Medley' via blink-dev]

Hi,

In which version do you intend to remove this?

Joe

On Monday, March 7, 2022 at 7:54:29 AM UTC-8 ari...@chromium.org wrote:

> Contact emails
>
> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>
> Design Doc
>
>
> https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit
>
> Specification
>
> https://wicg.github.io/client-hints-infrastructure/
>
> Summary
>
> One residue of the rapid Client Hints Infrastructure 
>  iteration is the 
> concept of a `legacy` client hint. It’s a set of 4 hints (`dpr`, `width`, 
> `viewport-width`, and `device-memory`) which have a default allowlist of 
> `self` (meaning that they are not sent to third-party subresources unless 
> delegated via Permissions Policy) but behave as though they have a default 
> allowlist of `*` (meaning they are sent to third-party subresources as long 
> as the first-party page requests them) on Android.
>
> This `legacy` client concept on Android will be removed and a permissions 
> policy will be required to delegate the 4 affected hints. As of M100, Markup 
> based Client Hint Delegation 
> 
>  
> is now available to allow delegation via HTML instead of HTTP headers.
>
>  
>
> Blink component
>
> Blink>Network>ClientHints 
> 
>
>  
>
> Motivation
>
> We want to bring these 4 hints in line with the spec; fixing this will 
> increase privacy on Android by requiring explicit delegation of these hints.
>
> TAG review
>
> N/A (this change brings Android behavior in line with the spec and better 
> preserves privacy)
>
> Compatibility
>
> Websites visited by android devices that request the legacy device-memory, 
> dpr, width, and viewport-width would no longer have these hints delegated 
> by default to third-party subresources. This would match the current 
> behavior on desktop. Third-party subresources which need these hints would 
> need to get the first-party that loads them to adopt HTTP 
>  or 
> HTML 
> 
>  
> delegation of client hints. The design doc 
> 
>  
> has usage/top-site information, and outreach is underway to ensure 
> third-parties expecting this information are aware of the change. The sites 
> which require default third-party delegation of these hints are likely much 
> lower than the sites which incidentally do so by default. As we encourage 
> Client Hint adoption, we want to ensure dependency doesn’t form on legacy, 
> non-compliant behavior.
>
>  
> 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?
>
> New WPT will be added to ensure these hints are not delegated by default.
>
> Tracking bug
>
> https://crbug.com/1227043
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5694492182052864
>
>
>

-- 
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/492ff1d6-09e8-454a-b3d8-d45189c60a78n%40chromium.org.

Re: [blink-dev] Re: Intent to Prototype: [WebRTC] Deprecate and Remove mediaConstraint's googIPv6

['Joe Medley' via blink-dev]

I really can't. That's why I have to be such a nag about when something is
going out.

I have you down for 108.

Thanks.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, May 12, 2022 at 1:50 PM Daniel Bratell  wrote:

> (not the implementor) According to followup to the request, the
> deprecation message is already in 102, possibly without ever having been
> documented. I don't know if you want to mention it in 103 instead.
>
> The removal we approved is for 108.
>
> /Daniel
>
>
> On 2022-05-12 16:59, 'Joe Medley' via blink-dev wrote:
>
> Pinging this again. In two weeks I need to write what's in 103 beta on
> https://blog.chromium.org (https://blog.chromium.org/search/label/beta).
> Will deprecation be in 103?
>
> On Tuesday, May 10, 2022 at 12:27:49 PM UTC-7 jmedley via Chromestatus
> wrote:
>
>> In which version are you hoping to deprecate? remove?
>>
> --
> 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/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%40chromium.org?utm_medium=email_source=footer>
> .
>
>

-- 
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/CAJUhtG-GuWCc4FfQQYwXgc%2B4nVPJuxzjKcDMogyMeAM%2BY71nAw%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype + Ship: User Activation Requirement for SPC Credential Enrollment

['Joe Medley' via blink-dev]

Thanks.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, May 12, 2022 at 8:12 AM Nick Burris  wrote:

> Thanks all! Joe, this change has now landed in M103.
>
> On Thu, May 12, 2022 at 11:04 AM Joe Medley  wrote:
>
>> Nick,
>>
>> When are you hoping to ship?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Tue, May 10, 2022 at 11:48 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM3
>>>
>>> On Wed, May 11, 2022 at 7:27 AM Mike West  wrote:
>>>
 LGTM2.

 -mike


 On Tue, May 10, 2022 at 8:01 PM Mike Taylor 
 wrote:

> LGTM1 - this seems like a useful change. Thanks for involving partners.
>
> On 5/5/22 12:23 PM, Nick Burris wrote:
>
> Contact emails
>
> nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org
>
> Explainer
>
> SPC explainer:
> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
>
> Specification
>
> SPC specification: https://w3c.github.io/secure-payment-confirmation/
>
> Design docs
>
> N/A
>
> Summary
>
> This intent is to add a user activation requirement for Secure Payment
> Confirmation (SPC) credential enrollment in a cross-origin iframe to help
> mitigate a privacy issue (see w3c/secure-payment-confirmation#128
>  for
> discussion of a potential identity tracking attack).
>
> 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
>
> SPC TAG review: https://github.com/w3ctag/design-reviews/issues/675
>
> TAG review status
>
> Closed (Resolution: satisfied)
>
> Interoperability and Compatibility
>
> While adding a new requirement for user activation is technically a
> breaking change, we are confident in this change as the feature is 
> expected
> to be used in a payment flow where the user has provided some form of 
> input
> to continue. We have confirmed with the external partners who are using
> this feature that they do currently have a user activation.
>
> 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 user activation requirement will be added to the
> existing test suite:
>
>
> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>
> Flag name
>
> N/A
>
> Requires code in //chrome?
>
> No
>
> Tracking bug
>
> User activation bug: https://crbug.com/1322603
>
> 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/guide/edit/5104475634139136
>
> 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 Prototype + Ship: User Activation Requirement for SPC Credential Enrollment

['Joe Medley' via blink-dev]

Nick,

When are you hoping to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, May 10, 2022 at 11:48 PM Yoav Weiss  wrote:

> LGTM3
>
> On Wed, May 11, 2022 at 7:27 AM Mike West  wrote:
>
>> LGTM2.
>>
>> -mike
>>
>>
>> On Tue, May 10, 2022 at 8:01 PM Mike Taylor 
>> wrote:
>>
>>> LGTM1 - this seems like a useful change. Thanks for involving partners.
>>>
>>> On 5/5/22 12:23 PM, Nick Burris wrote:
>>>
>>> Contact emails
>>>
>>> nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org
>>>
>>> Explainer
>>>
>>> SPC explainer:
>>> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> SPC specification: https://w3c.github.io/secure-payment-confirmation/
>>>
>>> Design docs
>>>
>>> N/A
>>>
>>> Summary
>>>
>>> This intent is to add a user activation requirement for Secure Payment
>>> Confirmation (SPC) credential enrollment in a cross-origin iframe to help
>>> mitigate a privacy issue (see w3c/secure-payment-confirmation#128
>>>  for
>>> discussion of a potential identity tracking attack).
>>>
>>> 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
>>>
>>> SPC TAG review: https://github.com/w3ctag/design-reviews/issues/675
>>>
>>> TAG review status
>>>
>>> Closed (Resolution: satisfied)
>>>
>>> Interoperability and Compatibility
>>>
>>> While adding a new requirement for user activation is technically a
>>> breaking change, we are confident in this change as the feature is expected
>>> to be used in a payment flow where the user has provided some form of input
>>> to continue. We have confirmed with the external partners who are using
>>> this feature that they do currently have a user activation.
>>>
>>> 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 user activation requirement will be added to the
>>> existing test suite:
>>>
>>>
>>> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>>>
>>> Flag name
>>>
>>> N/A
>>>
>>> Requires code in //chrome?
>>>
>>> No
>>>
>>> Tracking bug
>>>
>>> User activation bug: https://crbug.com/1322603
>>>
>>> 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/guide/edit/5104475634139136
>>>
>>> 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:
>>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/U5K69fbA6SU
>>>
>>>
>>> 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
>>> 

[blink-dev] Re: Intent to Prototype: [WebRTC] Deprecate and Remove mediaConstraint's googIPv6

['Joe Medley' via blink-dev]

Pinging this again. In two weeks I need to write what's in 103 beta 
on https://blog.chromium.org (https://blog.chromium.org/search/label/beta). 
Will deprecation be in 103?

On Tuesday, May 10, 2022 at 12:27:49 PM UTC-7 jmedley via Chromestatus 
wrote:

> In which version are you hoping to deprecate? remove?
>

-- 
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/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%40chromium.org.

[blink-dev] Re: Intent to Ship: Update User-Agent Client Hints GREASE implementation

['Joe Medley' via blink-dev]

In which version are you wanting to ship?

On Wednesday, May 4, 2022 at 6:06:30 AM UTC-7 mkwst via Chromestatus wrote:

> LGTM3.
>

-- 
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/3108ff66-551a-4e36-adeb-cdac929cdee5n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Region Capture

['Joe Medley' via blink-dev]

When do you intend to ship this? 103?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, May 2, 2022 at 7:55 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Mon, May 2, 2022 at 6:50 AM Mike Taylor  wrote:
>
>> LGTM2
>>
>> On 5/2/22 7:15 AM, Yoav Weiss wrote:
>>
>> LGTM1
>>
>> Thanks for initiating those discussions. My read of the minutes is that
>> they consider the async approach to be fine, and don't arbitrate on the
>> naming questions, other than saying that none of the proposals seem better
>> than where this API has landed. (and some may add confusion)
>> As such it seems that going with the API as currently defined doesn't
>> bear significant interoperability risk.
>>
>>
>>
>> On Mon, May 2, 2022 at 1:03 PM Elad Alon  wrote:
>>
>>> The discussions around Region Capture have been brought up with TAG
>>> again (after their original approval
>>> 
>>> of the design). Here are the minutes from that second meeting:
>>>
>>> https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/04-25-minutes.md#media-capture-region
>>>
>>> On Wednesday, April 20, 2022 at 6:33:52 PM UTC+2 yoav...@chromium.org
>>> wrote:
>>>
 Just to (belatedly) update this thread: Following a discussion with the
 API owners and the intent owner a few weeks back, they are planning to try
 and get more folks to weigh in on the open issues, and hopefully break the
 tie.

 On Wednesday, March 23, 2022 at 6:28:30 PM UTC+1 Elad Alon wrote:

> It may be better to ask actual web developers regarding the least
>> confusing option amongst those proposed.
>
>
> The Web-developers I am in contact with are happiest with CropTarget.
> One of them has mentioned that on issue #18
> .
> Other Web-developers have not shown up with a preference one way or
> another.
>
> It bears mentioning that we have been discussing the API in the WebRTC
> Working Group for approximately 14
> 
> months
> .
> The initial name for this part of the API was CropID. It was changed
> 
>  to
> CropTarget ~4 months ago, following discussions in the WG. Youenn filed 
> issue
> #18  ~2 months
> ago. During those two months, no WG member, browser-implementer or
> Web-developer voiced concerns about the "CropTarget" name. Youenn has made
> several suggestions (Viewport, LayoutBox). I believe I have addressed 
> these
> suggestions. I do not think there is interest in the WG for changing the
> name. I think the name CropTarget will end up sticking, and not produce a
> compat risk.
>
> Sync vs. async cropTarget creation seems like something you'd want to
>> decide on before shipping.
>
>
> It is something we have tried reaching consensus on. But I am not
> observing convergence. I proposed the following:
>
>- For Chrome, it is important to use a Promise.
>- For any browser that does not feel a Promise is necessary, they
>can immediately return a pre-resolved Promise.
>- Web-developers would be virtually unaffected by the addition of
>a Promise even - for the sake of argument - if it isn't strictly 
> necessary.
>(I still think it is necessary.)
>
> You mentioned on the thread that the browser can refuse to mint new
>> cropTargets in some cases. What happens then? Is it specified? How are
>> developers supposed to defensively program their API use against that?
>
>
> Failure to mint additional tokens happens if excessive tokens are
> minted. (Defends against memory-overuse in the browser process.)
> Failure is reflected by a Promise being rejected rather than fulfilled
> - which is an established pattern and well-understood by Web-developers.
>
>
> If minting couldn't fail, then (naively) writing the
>> process/origin<->token mapping in the browser process could've been done
>> async, while the creation of the token could be sync.
>
>
> That is an interesting alternative; thank you for suggesting it. I
> have given it thought, and I see some issues with it. To start with, an
> application could be given a "dead" token. Such a token will never be
> useful, but the application would not be able detect that until it calls
> cropTo(token), and that call fails. Then, this failure would only be
> 

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

['Joe Medley' via blink-dev]

If it's a feature flag, please put milestones in the the appropriate dev
trial milestone fields.

Thanks
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Sun, May 1, 2022 at 5:56 PM Daisuke Enomoto 
wrote:

> Hi Joe,
>
> CacheTransparancy is the feature name we use for the feature flag. As Adam
> mentioned, the feature is off by default. Yes, we use Finch to determine
> the control/experiment group on each channel (50% on canary & dev, 10% on
> beta, 1% on stable).
>
> On Thu, Apr 28, 2022 at 11:46 PM Joe Medley  wrote:
>
>> What is that?
>>
>> I'm trying to understand what this is because I need or may need to
>> explain it in writing to the external world in a few weeks. I've never
>> heard of a CacheTransparancy flag.
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Apr 28, 2022 at 1:26 AM Adam Rice  wrote:
>>
>>> Finch flag?
>>>
>>>
>>> CacheTransparency (but the code is not landed yet).
>>>
>>> On Thu, 28 Apr 2022 at 03:07, Joe Medley  wrote:
>>>
 Finch flag?
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Wed, Apr 27, 2022 at 2:30 AM Adam Rice  wrote:

> What is an 'off-by-default experiment'? Is that a dev trial flag?
>
>
> Just an ordinary experiment, behind a flag which is off-by-default. So
> most users get the default behaviour (no single-keyed cache), except for
> those in the experimental group.
>
> On Wed, 27 Apr 2022 at 00:50, Joe Medley  wrote:
>
>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto <
>> denom...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>>>
>>> Specification
>>>
>>> N/A (because there are no web-exposed changes)
>>>
>>> Summary
>>>
>>> This limited experiment measures how much "pervasive payloads"
>>> contribute to the performance impact of the split HTTP cache in each 
>>> Chrome
>>> channel over a three-week period. Pervasive payloads are those 
>>> third-party
>>> payloads included on at least 500 sites and fetched at least 10M times 
>>> in a
>>> month, based on Chrome's analysis (payload list included below). This
>>> experiment further measures the impact on Core Web Vitals metrics of
>>> restoring pervasive payloads (and only pervasive payloads) to a
>>> single-keyed cache regime. The privacy benefits of the split HTTP cache 
>>> are
>>> preserved.
>>>
>>> Blink component
>>>
>>> Blink>Network
>>> 
>>>
>>> Motivation
>>>
>>> Browsers split HTTP caches based on the top-frame visited origin
>>> (“double-keyed” or "triple-keyed" caching) to prevent sites from 
>>> tracking
>>> users via a timing attack on a cross-site client cache.
>>>
>>> Chrome’s analysis estimates that split caching results in a 3%
>>> increase in cache misses, i.e. fetches for which a payload exists in the
>>> cache of the user's device, but is unavailable to the page because it 
>>> was
>>> fetched by the user while loading a page from a different origin. This
>>> results in approximately 4% more total bytes being fetched over the 
>>> network.
>>>
>>> Our analysis further revealed that many of the redundant fetches
>>> caused by split caching were for common payloads associated with 
>>> displaying
>>> user content (libraries, fonts, widgets, ads) or common payloads that
>>> assist in operating online businesses (analytics). The delayed arrival 
>>> of
>>> these common payloads resulted in visible "jank" for users, impacting
>>> performance metrics like LCP , FCP
>>>  and CLS . This jank has
>>> been associated with negative effects to online business' engagement and
>>> conversion rates. Furthermore, delayed loads of analytics and ads 
>>> payloads
>>> can result in missed ads impressions and dropped analytics hits.
>>>
>>> Initial public proposal
>>>
>>> This experiment sends a list to Chrome of 100  pairs
>>> whose payloads are considered pervasive (the "pervasive 

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

['Joe Medley' via blink-dev]

What is that?

I'm trying to understand what this is because I need or may need to explain
it in writing to the external world in a few weeks. I've never heard of a
CacheTransparancy flag.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Apr 28, 2022 at 1:26 AM Adam Rice  wrote:

> Finch flag?
>
>
> CacheTransparency (but the code is not landed yet).
>
> On Thu, 28 Apr 2022 at 03:07, Joe Medley  wrote:
>
>> Finch flag?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Apr 27, 2022 at 2:30 AM Adam Rice  wrote:
>>
>>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>>>
>>>
>>> Just an ordinary experiment, behind a flag which is off-by-default. So
>>> most users get the default behaviour (no single-keyed cache), except for
>>> those in the experimental group.
>>>
>>> On Wed, 27 Apr 2022 at 00:50, Joe Medley  wrote:
>>>
 What is an 'off-by-default experiment'? Is that a dev trial flag?
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto 
 wrote:

> Contact emails
>
> ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org
>
> Explainer
>
>
> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>
> Specification
>
> N/A (because there are no web-exposed changes)
>
> Summary
>
> This limited experiment measures how much "pervasive payloads"
> contribute to the performance impact of the split HTTP cache in each 
> Chrome
> channel over a three-week period. Pervasive payloads are those third-party
> payloads included on at least 500 sites and fetched at least 10M times in 
> a
> month, based on Chrome's analysis (payload list included below). This
> experiment further measures the impact on Core Web Vitals metrics of
> restoring pervasive payloads (and only pervasive payloads) to a
> single-keyed cache regime. The privacy benefits of the split HTTP cache 
> are
> preserved.
>
> Blink component
>
> Blink>Network
> 
>
> Motivation
>
> Browsers split HTTP caches based on the top-frame visited origin
> (“double-keyed” or "triple-keyed" caching) to prevent sites from tracking
> users via a timing attack on a cross-site client cache.
>
> Chrome’s analysis estimates that split caching results in a 3%
> increase in cache misses, i.e. fetches for which a payload exists in the
> cache of the user's device, but is unavailable to the page because it was
> fetched by the user while loading a page from a different origin. This
> results in approximately 4% more total bytes being fetched over the 
> network.
>
> Our analysis further revealed that many of the redundant fetches
> caused by split caching were for common payloads associated with 
> displaying
> user content (libraries, fonts, widgets, ads) or common payloads that
> assist in operating online businesses (analytics). The delayed arrival of
> these common payloads resulted in visible "jank" for users, impacting
> performance metrics like LCP , FCP
>  and CLS . This jank has
> been associated with negative effects to online business' engagement and
> conversion rates. Furthermore, delayed loads of analytics and ads payloads
> can result in missed ads impressions and dropped analytics hits.
>
> Initial public proposal
>
> This experiment sends a list to Chrome of 100  pairs whose
> payloads are considered pervasive (the "pervasive payloads list"). During
> the three-week experiment period, if Chrome fetches a payload that matches
> both the URL and its hash on the pervasive payloads list, it is inserted
> into a local single-keyed cache. This payload is then available for use by
> Chrome when loading pages on other sites that include the matching URL. 
> All
> other fetches for URLs not on the pervasive payloads list are cached
> according to the existing split HTTP cache.
>
> The hash covers the payload body and most response headers, except for
> those which change on every response.
>
> To ensure we do not degrade the privacy profile of any users during
> this experiment, only users with third-party cookies currently enabled 
> will
> be eligible for the experiment. We will compare the experience of users in
> experiment and control arms according to total bytes loaded and 

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

['Joe Medley' via blink-dev]

Finch flag?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Apr 27, 2022 at 2:30 AM Adam Rice  wrote:

> What is an 'off-by-default experiment'? Is that a dev trial flag?
>
>
> Just an ordinary experiment, behind a flag which is off-by-default. So
> most users get the default behaviour (no single-keyed cache), except for
> those in the experimental group.
>
> On Wed, 27 Apr 2022 at 00:50, Joe Medley  wrote:
>
>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto 
>> wrote:
>>
>>> Contact emails
>>>
>>> ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>>>
>>> Specification
>>>
>>> N/A (because there are no web-exposed changes)
>>>
>>> Summary
>>>
>>> This limited experiment measures how much "pervasive payloads"
>>> contribute to the performance impact of the split HTTP cache in each Chrome
>>> channel over a three-week period. Pervasive payloads are those third-party
>>> payloads included on at least 500 sites and fetched at least 10M times in a
>>> month, based on Chrome's analysis (payload list included below). This
>>> experiment further measures the impact on Core Web Vitals metrics of
>>> restoring pervasive payloads (and only pervasive payloads) to a
>>> single-keyed cache regime. The privacy benefits of the split HTTP cache are
>>> preserved.
>>>
>>> Blink component
>>>
>>> Blink>Network
>>> 
>>>
>>> Motivation
>>>
>>> Browsers split HTTP caches based on the top-frame visited origin
>>> (“double-keyed” or "triple-keyed" caching) to prevent sites from tracking
>>> users via a timing attack on a cross-site client cache.
>>>
>>> Chrome’s analysis estimates that split caching results in a 3% increase
>>> in cache misses, i.e. fetches for which a payload exists in the cache of
>>> the user's device, but is unavailable to the page because it was fetched by
>>> the user while loading a page from a different origin. This results in
>>> approximately 4% more total bytes being fetched over the network.
>>>
>>> Our analysis further revealed that many of the redundant fetches caused
>>> by split caching were for common payloads associated with displaying user
>>> content (libraries, fonts, widgets, ads) or common payloads that assist in
>>> operating online businesses (analytics). The delayed arrival of these
>>> common payloads resulted in visible "jank" for users, impacting performance
>>> metrics like LCP , FCP  and
>>> CLS . This jank has been associated with negative
>>> effects to online business' engagement and conversion rates. Furthermore,
>>> delayed loads of analytics and ads payloads can result in missed ads
>>> impressions and dropped analytics hits.
>>>
>>> Initial public proposal
>>>
>>> This experiment sends a list to Chrome of 100  pairs whose
>>> payloads are considered pervasive (the "pervasive payloads list"). During
>>> the three-week experiment period, if Chrome fetches a payload that matches
>>> both the URL and its hash on the pervasive payloads list, it is inserted
>>> into a local single-keyed cache. This payload is then available for use by
>>> Chrome when loading pages on other sites that include the matching URL. All
>>> other fetches for URLs not on the pervasive payloads list are cached
>>> according to the existing split HTTP cache.
>>>
>>> The hash covers the payload body and most response headers, except for
>>> those which change on every response.
>>>
>>> To ensure we do not degrade the privacy profile of any users during this
>>> experiment, only users with third-party cookies currently enabled will be
>>> eligible for the experiment. We will compare the experience of users in
>>> experiment and control arms according to total bytes loaded and page
>>> performance metrics like the Core Web Vitals .
>>>
>>> The pervasive payloads list was produced by crawling the web and
>>> aggregating the most commonly referenced third-party resource URLs included
>>> in HTML content. We then used pseudonymous URL-keyed metrics from Chrome to
>>> estimate the traffic to sites and the number of impressions of third-party
>>> resources. Individually identifiable browsing or search histories were not
>>> used in the creation of the pervasive payload list (for more information
>>> about Chrome's data collection policies and privacy policies, see
>>> google.com/chrome/privacy). The resulting list was further filtered for
>>> any URLs that might contain PII (e.g. URLs with extensive or 

[blink-dev] Re: Intent to Ship: supports for the @font-face src: descriptor

['Joe Medley' via blink-dev]

Which milestone are you aiming for?

On Friday, June 18, 2021 at 7:57:58 AM UTC-7 dr...@chromium.org wrote:

> Contact emailsdr...@chromium.org
>
> Specificationhttps://drafts.csswg.org/css-fonts/#font-face-src-parsing
>
> API specYes
>
> Summary
>
> Support the extended `supports ` syntax of the @font-face 
> src: descriptor. The intention of this syntax is to enable UA's to choose 
> supported entries from the src: line of the @font-face. Unsupported entries 
> with "support..." lines which are not supported are to be dropped from the 
> src: line. 
>
>
> *Motivation*
>
>
> Supporting this syntax enables an inexpensive CSS or JS based check for 
> support of CORLv1 or other font technologies. 
>
> CSS based selection of the right font and technology is done by the UA 
> traversing the src: line and choosing the first successfully parsed and 
> supported entry and trying to load it. If the load fails, the next 
> supported entry is chosen.
>
> JS feature testing can be achieved by declaring a CSS @font-face in a 
> stylesheet with a src: line that contains for example a line src: 
> format(woff2) supports COLRv1; - then accessing this rule using CSSOM and 
> retrieving the value of cssText for this rule. By analysing the values of 
> cssText, specifically the serialized src: line, it can be determined 
> whether entries were dropped from the src: line. 
>
> Support for this feature across browsers allows precise selection of the 
> best, supported font technology from the @font-face definition.
>
>
> Blink componentBlink>Fonts 
> 
>
> Search tagscss , @font-face 
> , src 
> , descriptor 
> , src descriptor 
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
> Interoperability and Compatibility
>
> The `supports ` is a backwards-compatible extension of 
> the @font-face src: descriptor syntax. Existing values for the src: line 
> which contain only string values such as format("woff2") for 
> format("woff2-variations") will still be understood and working as 
> intended. The CSSOM serialisation of the parsed value will be canonicalised 
> to match the spec grammar. E.g. if the page specifies src: url(...) 
> format("woff2") supports variations; it will be serialized as src: url(...) 
> format(woff2) supports variations; to upgrade the syntax to the newer form 
> in the spec. I expect low compatibility problems from that, because a) the 
> format() syntax is not often used, b) I do not expect the serialisation of 
> the value to be accessed much at all. 
>
>
> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=650372)
>
> WebKit: No signal (https://github.com/w3c/csswg-drafts/issues/633) Case 
> made for "supports" syntax originally made my Myles Maxfield from Apple. 
> Nevertheless, "supports" syntax extension not implemented in Safari yet.
>
> Web developers: Positive 
> When working on COLRv1, we've received requests from prominent web 
> partners for an efficient way of feature testing for COLRv1 availability. 
> Implementing the supports syntax allows JS and CSS based feature 
> detection for COLRv1.
>
> Ergonomics
>
> The CSS based selection of the font src: of the right technology works 
> without ergonomic issues and is the spec-suggested approach for solving 
> this problem. The JS based feature detection as described above is a more 
> efficient check for supported font technology than using a canvas-based 
> approach as for example used in https://pixelambacht.nl/chromacheck/. At 
> the same time, it's still not as straight-forward compared to 
> CSS.supports() JS syntax. However, CSS.supports() works only for CSS 
> properties, not for descriptors of @font-face. In that sense, this is a 
> spec-compliant approach that can be deployed now, while the spec discussion 
> continues on whether a more direct JS based feature test for descriptor 
> syntax should be added. 
>
>
> Debuggability
>
> To some extent through DevTools. (Not much support exists for @font-face 
> in general) 
>
> Not supported src: entries will be removed from the src: line and will not 
> show up in DevTools. As such, DevTools helps to identify which types of 
> entries are supported and how parsing of the src: line succeeded.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No, WPT tests will be added while completing implementation work 
>  of 
> this feature.
>
>
> Tracking bughttps://crbug.com/1216460
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5741063488667648
>
>

-- 

Re: [blink-dev] Intent to Prototype and Ship: User-Agent Reduction Phase 4 (minor version reduction)

['Joe Medley' via blink-dev]

Is this shipping in 101? That's the rumor.

On Wednesday, February 2, 2022 at 8:59:39 AM UTC-8 mk...@chromium.org wrote:

> LGTM3.
>
> -mike
>
> On Tuesday, February 1, 2022 at 10:37:59 PM UTC+1 Rick Byers wrote:
>
>> LGTM2
>>
>> On Tue, Feb 1, 2022 at 1:27 PM Domenic Denicola  
>> wrote:
>>
> On Tue, Feb 1, 2022 at 11:24 AM Mike Taylor  wrote:
>>>
 *Contact emails*



 * mike...@chromium.org, abe...@chromium.org, jadek...@chromium.org 
 Explainer 
 https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
  
 
  
 Specification https://www.chromium.org/updates/ua-reduction 
  is the closest thing that 
 specifies Chrome’s UA Reduction plans today. As these changes land in 
 Chromium, the Compat Standard  will be 
 updated to reflect them (in the newly landed UA String section 
 ).*

>>>
>>> I want to call out that this is some really great work. For years specs 
>>> have basically said "use an implementation-defined value", but we knew that 
>>> was not sufficient for web compatibility, and it was not useful to web 
>>> developers or implementers. Years ago we started to capture some 
>>> interesting constraints in HTML's definition of navigator compatibility 
>>> mode 
>>> , 
>>> but we knew there were many more.
>>>
>>> The work Mike has done has started to address this long-standing issue 
>>> of spec tech debt, and it's really great that he's put in the extra work 
>>> here instead of just taking advantage of the spec's historical looseness.
>>>
>>> I did a quick review on the spec and found some minor issues and 
>>> clarity improvement suggestions 
>>> , but 
>>> overall this is a great foundation and gives me confidence others can both 
>>> follow along with our plans, and implement compatible software based on 
>>> them.
>>>  
>>>
>>






















 * Summary As previously detailed on the Chromium Blog 
 ,
  
 we intend to proceed with Phase 4 of the User-Agent Reduction plan. In 
 Phase 4, the MINOR.BUILD.PATCH version numbers are reduced to "0.0.0". For 
 use cases requiring high-entropy full version information, developers are 
 encouraged to migrate to the User Agent Client Hints API 
 , in particular the 
 Sec-CH-UA-Full-Version-List 
  
 hint. 
 Blink component Blink 
  TAG 
 review https://github.com/w3ctag/design-reviews/issues/640 
  TAG review status 
 Issues addressed Risks Interoperability and Compatibility Any time you 
 modify the User-Agent string there is a risk of some content somewhere 
 depending on the previous format. There should not be interop risks, as 
 each browser sends its own User-Agent string. But there is a risk that 
 content somewhere is relying on “non-zero” MINOR, BUILD, or PATCH 
 information. My personal view is that the risk is low compared to the rest 
 of the changes to come in later phases. But in order to mitigate the risk 
 of this change, we intend to slowly roll it out via Finch and observe 
 health metrics (i.e., HTTP 4XX and 5XX error codes, etc.) and bug reports 
 from the community. We've surveyed dozens of User-Agent parsing libraries, 
 and as far as we know "0.0.0" will not create a problem syntactically. But 
 the web can get pretty weird in ways we don't anticipate, hence the slow 
 roll-out and incremental path towards User-Agent Reduction. Gecko: 
 Shipped/Shipping. Firefox has frozen (or capped) much of their UA string 
 already. WebKit: Shipped/Shipping. Safari has already frozen everything in 
 their UA string except for version number info. Web developers: Mixed 
 signals. Reactions have ranged from positive to indifferent to negative, 
 from various channels. Debuggability No special DevTools support needed. 
 Is 
 this feature fully tested by web-platform-tests 
 ?
  
 No Flag name reduce-user-agent Requires code in //chrome? False Tracking 
 bug https://bugs.chromium.org/p/chromium/issues/detail?id=1282229 
 

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

['Joe Medley' via blink-dev]

Mason,

In which version are you hoping to deprecate and in which are you hoping to
remove?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Apr 13, 2022 at 9:48 AM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Explainerhttps://github.com/whatwg/html/pull/7816
> https://github.com/whatwg/html/issues/6003
>
> Specificationhttps://github.com/whatwg/html/pull/7816
>
> Summary
>
> The  element can be used to specify parameters such as a URL (via
> params named "movie", "src", "code", "data", or "url") to a containing
>  element. Given the removal of plugins from the web platform, and
> the relative lack of use of this particular functionality, we would like to
> deprecate and remove it.
>
>
> Blink componentBlink
> 
>
> Motivation
>
> Given that plugins are gone from the web platform (with their full removal
> from the spec being tracked in https://github.com/whatwg/html/issues/6003),
> it is not useful. In some browsers it can be used to figure out the URL of
> an , even when that  is not being used for a plugin, via
> params named "movie", "src", "code", "data", or "url". But we decided to
> remove this behavior from browsers instead of specifying it. This retains
> the HTMLParamElement interface, as well as the parser behavior of .
>
>
> Initial public proposal
>
> Search tags ,
>  
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Shipped/Shipping (
> https://github.com/whatwg/html/issues/387#issuecomment-1088331300) Issue
> was initially raised by Mozilla, and Gecko already does not process param
> at all.
>
> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No
> response on the bug yet.
>
> Web developers: No signals
>
> Other signals:
>
> Ergonomics
>
> Since this is a deprecation, there is a Web Compat risk. I added use
> counters for the situations that will be affected: -  that specifies
> a URL, inside an  that doesn't: 0.04%,
> https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As
> above, but URL successfully resolves to a (supported) PDF resource:
> 0.2%,
> https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As
> above, but URL successfully resolves to an (unsupported) non-PDF resource:
> not measurable,
> https://chromestatus.com/metrics/feature/timeline/popularity/4111 So the
> vast majority (99.95%) of  URL usage appears to point to invalid
> resources - likely mostly Flash. A very small percentage (0.05% of
> -with-URL usage, 0.2% of web page loads) are likely to break
> when we deprecate this functionality.
>
>
> 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?
>
>
>
> Debuggability
>
> Deprecation.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1315717
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6283184588193792
>
> 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/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%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/CAJUhtG9k2Ngc1jyOrvvF%2BpMVcB%2BmvaD2MYn6MOu-sCa%3DXm0H2Q%40mail.gmail.com.

[blink-dev] Re: Intent to Enable Origin Trial support on Android WebView

['Joe Medley' via blink-dev]

So 102 stable could have an origin trial that includes WebView?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Apr 12, 2022 at 4:35 AM Peter Birk Pakkenberg 
wrote:

> Hi Joe,
>
> Yes, we are planning to start the roll out once M102 has launched on
> Stable.
>
> Sincerely,
> [image: Google Logo]
> Peter Birk Pakkenberg
> Software Engineer
> pb...@google.com
> +447469379358 <+44%207469%20379358>
>
>
> On Mon, 11 Apr 2022 at 18:42, Joe Medley  wrote:
>
>> Peter,
>>
>> Do you know any release/availability dates yet? We need to add fields to
>> the Chrome Status
>> .
>>
>> On Thursday, April 7, 2022 at 8:59:53 AM UTC-7 Peter Birk Pakkenberg
>> wrote:
>>
>>> Hello blink-dev@
>>>
>>> We are hoping to begin rolling out origin trial support on WebView. The
>>> goal is to ensure that the origins who wish to test new Blink features can
>>> reach users in Android WebView as well.
>>> Launch Bugs
>>>
>>> http://crbug.com/1186236
>>>
>>> http://crbug.com/1308425 (internal launch bug)
>>> Summary
>>>
>>> We will soon enable origin trials on Android WebView, which means that
>>> clients will start to honour Origin-Trial headers for trials that target
>>> the Android platform in runtime_enabled_features.json5
>>> ,
>>> provided the feature is implemented for WebView. This means that a number
>>> of existing Blink trials will be enabled.
>>>
>>> The long term goal is to achieve parity between WebView and Chrome on
>>> Android when it comes to experimentation for features implemented in Blink,
>>> which has two key benefits to the Chromium project. First, it provides a
>>> large number of additional clients to test new Blink features. Due to the
>>> embedded nature of WebView, this will provide new insights into a part of
>>> the web ecosystem that has previously not been accessible to
>>> experimentation (for example hybrid apps). In turn, this will help to avoid
>>> surprises for feature developers who rely on origin trials to launch new
>>> features, which will hopefully lead to smoother feature launches.
>>> Why Now
>>>
>>> Planned features on WebView require origin testing, making it a
>>> necessity to enable the framework. Additionally, the longer origin trials
>>> remain disabled on WebView, the more likely it is that a trial misses an
>>> issue on WebView that could have been found, like it has happened in
>>> the past .
>>> Affected trials
>>>
>>> By our analysis, 14 trials
>>> 
>>> will be affected by the enablement on WebView. This means that they a) are
>>> targeting the Android platform, and b) have been implemented in shared code
>>> that is used by WebView. Other trials may rely on integrations in the
>>> embedder, which have not been implemented for WebView, which means that
>>> they won’t exhibit any new behaviour during the roll-out.
>>> Rollout plan
>>>
>>> WebView does not have good penetration on the dev/beta channels, so we
>>> will have to do the primary experiment on Stable. Given that we will be
>>> enabling all applicable origin trials on WebView at the same time as part
>>> of our feature roll-out, we expect full support to reach all WebView users
>>> in 3-4 weeks.
>>> Feedback from the Blink community
>>>
>>> We’d love to receive feedback and questions from the Blink community,
>>> either via this thread, in the launch bug
>>>  or
>>> privately. Some of the things that we’ve been thinking about:
>>>
>>>
>>>-
>>>
>>>Should targeting Android in runtime_enabled_features.json5 include
>>>or exclude WebView? We propose for it to be included as the majority of
>>>trials are either applicable to WebView as well, or have the 
>>> corresponding
>>>features disabled through other means in Chromium.
>>>
>>>-
>>>
>>>How should trial owners consider WebView metrics in their analysis?
>>>For Googlers, the UMA dashboards provide this ability, although WebView
>>>does not record UKM. Externally we’re investigating whether we can 
>>> publish
>>>WebView metrics as part of chromestatus.com, but that’s adjacent to
>>>this effort.
>>>
>>>-
>>>
>>>How should Web developers consider WebView usage? For the trials
>>>that are applicable to WebView, ideally they wouldn’t. WebView powers a
>>>significant share of browsing time on Android, so in most cases this is 
>>> an
>>>audience they already reach today, but (possibly unknowingly) isn’t 
>>> covered
>>>by their own experimentation
>>>
>>>
>>>
>>> Sincerely,
>>> [image: Google Logo]
>>> Peter Birk Pakkenberg
>>> Software Engineer
>>> 

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

['Joe Medley' via blink-dev]

Please ping me if it ends up being 103. I don't like missing things in the 
beta release post.

On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org wrote:

> On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:
>
>> Are you aiming for 102?
>>
>
> That's branching very soon, so definitely not. I'm not really aiming for 
> any particular release. But if you want a prediction anyway, then likely 
> 104. 
>  
>
>>
>> On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:
>>
>>>
>>>
>>> On 4/11/22 15:02, Anders Hartvoll Ruud wrote: 
>>> > Ah, I'm not familiar with that way of doing compat research. What 
>>> would 
>>> > we gain from doing that vs. regular use-counter + HTTP Archive? 
>>> > 
>>> > Do we expect those 0.1% to visibly break? (I guess that depends on 
>>> > what they're feature testing for..) 
>>> > 
>>> > 
>>> > I would not expect that at all based on the HTTP Archive query. If 
>>> > testing against "not all" was commonplace, I'd expect more results 
>>> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
>>> > happens mostly on features that actually *are* supported at the 
>>> moment. 
>>> > 
>>> > Just as an example (and to show that "not all" testing isn't a myth), 
>>> > one of the few (non-Yandex-script) sites that did show up was 
>>> > https://ww.sapo.pt , which does the following: 
>>> > 
>>> > if(rule.mediaText.includes("not all") || ...) 
>>> > 
>>> > By the looks of it, it's an early-out related to the theme switching, 
>>> > which prevents the code from amending the query if 
>>> prefers-color-scheme 
>>> > is not supported. Had we not supported prefers-color-scheme, then I 
>>> > think the worst that could happen is that we end up with a more 
>>> > complicated query that still ultimately evaluates to false. Testing 
>>> the 
>>> > page with the feature enabled (with and without dark mode preference), 
>>> > their color switcher still works normally. 
>>> > 
>>> > That is just one site though, it's probably theoretically possible to 
>>> > write *something* that breaks. I did try to look at the "sample URLs" 
>>> > for the counters, but I couldn't actually reproduce the counters being 
>>> hit. 
>>>
>>>
>>> It's a thing that even Google DevRel people have recommended in the 
>>> past, ftr :) 
>>>
>>> https://web.dev/prefers-color-scheme/#supporting-dark-mode 
>>>
>>>
> Ouch ... 
>  
>
>> But if you have data to indicate this is not a problem in the wild I'd 
>>> be happy to implement it in Gecko after you ship this change. 
>>>
>>> Cheers, 
>>>
>>> -- Emilio 
>>>
>>

-- 
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/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org.

[blink-dev] Re: Intent to Ship: Digital Goods API 2.1

['Joe Medley' via blink-dev]

So this is different from what you shipped in 100 (desktop) and 101 
(Android).

On Monday, April 11, 2022 at 10:50:22 AM UTC-7 Joe Medley wrote:

> Just saw where you answered that. Sorry.
>
> On Monday, April 11, 2022 at 10:49:33 AM UTC-7 Joe Medley wrote:
>
>> Are you hoping to ship in 102?
>>
>> On Monday, April 11, 2022 at 7:45:43 AM UTC-7 rou...@chromium.org wrote:
>>
>>> Contact emails
>>>
>>> gle...@chromium.org, rou...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/digital-goods/blob/main/explainer.md#api-v21
>>>
>>> Specification
>>>
>>> https://wicg.github.io/digital-goods/
>>>
>>> Difference between 2.0 and 2.1 
>>> 
>>>
>>> Design docs
>>>
>>> https://github.com/WICG/digital-goods/blob/master/explainer.md
>>>
>>>
>>> https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit
>>>
>>> Summary
>>>
>>> We would like to ship a non-breaking addition to the existing Digital 
>>> Goods API. This change:
>>>
>>>- 
>>>
>>>Adds to DigitalGoodsService:
>>>- 
>>>   
>>>   Promise> listPurchaseHistory();
>>>   - 
>>>
>>>Adds to ItemDetails:
>>>- 
>>>   
>>>   ItemType type;
>>>   - 
>>>   
>>>   sequence iconUrls;
>>>   - 
>>>   
>>>   unsigned short introductoryPriceCycles;
>>>   - 
>>>
>>>Adds enum ItemType.
>>>
>>>
>>> Use of the new methods/fields will require developers to update 
>>> supporting code in their apps, such as Android Browser Helper 
>>> .
>>>
>>> Blink component
>>>
>>> Blink>Payments 
>>> 
>>>
>>> Search tags
>>>
>>> payments , billing 
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/571 
>>>
>>> TAG review status
>>>
>>> TAG continues to think of DGAPI as a “product-specific API within one 
>>> company.”
>>>
>>> Other issues addressed.
>>>
>>> RisksInteroperability and Compatibility
>>>
>>> Similar to Payment Request: this API is used to talk to specific store 
>>> backends, and so its usage is tailored to the specific store. The reason 
>>> it's a proposed web standard is so that the same code (which is specific to 
>>> one store) is portable across browsers.
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/349) Requested 
>>> 2020-05-27
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html) 
>>> Requested 2021-10-08
>>>
>>> Web developers: Positive (
>>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
>>> )
>>>
>>> Other signals: rouslan@ presented DGAPI at 2021 TPAC 
>>>  (meeting 
>>> notes ) and at a PWA 
>>> Dev Sync 
>>>  
>>> (meeting notes 
>>> ).
>>>  
>>> Other browser implementers and app stores do not appear to have immediate 
>>> plans to engage with DGAPI. There were some questions, no objections.
>>>
>>> Ergonomics
>>>
>>> Used in tandem with the Payment Request API.
>>>
>>> WebView Application Risks
>>>
>>> This API is disabled in WebView.
>>>
>>>
>>> Debuggability
>>>
>>> We have had several requests from developers to make the API easier to 
>>> debug, but it is difficult due to the interaction with a backing service 
>>> based in an app/store context. We are looking for suggestions (
>>> https://github.com/WICG/digital-goods/issues/33) on how we might 
>>> improve the debuggability of the API.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>>
>>> The tests are in 
>>> //third_party/blink/web_tests/wpt_internal/digital-goods.
>>>
>>> Flag name
>>>
>>> DigitalGoodsV2_1
>>>
>>> Requires code in //chrome?
>>>
>>> Yes
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1250604
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1288420
>>>
>>> Estimated milestones
>>>
>>> We would like to ship DGAPI v2.1 in M102.
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5339955595313152
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to prototype 1.0:
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.
>>>
>>> Intent to experiment 1.0:
>>>
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ
>>> .
>>>
>>> Intent to continue experimenting 1.0:
>>>
>>> 

[blink-dev] Re: Intent to Ship: Digital Goods API 2.1

['Joe Medley' via blink-dev]

Just saw where you answered that. Sorry.

On Monday, April 11, 2022 at 10:49:33 AM UTC-7 Joe Medley wrote:

> Are you hoping to ship in 102?
>
> On Monday, April 11, 2022 at 7:45:43 AM UTC-7 rou...@chromium.org wrote:
>
>> Contact emails
>>
>> gle...@chromium.org, rou...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/digital-goods/blob/main/explainer.md#api-v21
>>
>> Specification
>>
>> https://wicg.github.io/digital-goods/
>>
>> Difference between 2.0 and 2.1 
>> 
>>
>> Design docs
>>
>> https://github.com/WICG/digital-goods/blob/master/explainer.md
>>
>>
>> https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit
>>
>> Summary
>>
>> We would like to ship a non-breaking addition to the existing Digital 
>> Goods API. This change:
>>
>>- 
>>
>>Adds to DigitalGoodsService:
>>- 
>>   
>>   Promise> listPurchaseHistory();
>>   - 
>>
>>Adds to ItemDetails:
>>- 
>>   
>>   ItemType type;
>>   - 
>>   
>>   sequence iconUrls;
>>   - 
>>   
>>   unsigned short introductoryPriceCycles;
>>   - 
>>
>>Adds enum ItemType.
>>
>>
>> Use of the new methods/fields will require developers to update 
>> supporting code in their apps, such as Android Browser Helper 
>> .
>>
>> Blink component
>>
>> Blink>Payments 
>> 
>>
>> Search tags
>>
>> payments , billing 
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/571 
>>
>> TAG review status
>>
>> TAG continues to think of DGAPI as a “product-specific API within one 
>> company.”
>>
>> Other issues addressed.
>>
>> RisksInteroperability and Compatibility
>>
>> Similar to Payment Request: this API is used to talk to specific store 
>> backends, and so its usage is tailored to the specific store. The reason 
>> it's a proposed web standard is so that the same code (which is specific to 
>> one store) is portable across browsers.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/349) Requested 
>> 2020-05-27
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html) 
>> Requested 2021-10-08
>>
>> Web developers: Positive (
>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
>> )
>>
>> Other signals: rouslan@ presented DGAPI at 2021 TPAC 
>>  (meeting notes 
>> ) and at a PWA Dev 
>> Sync 
>>  
>> (meeting notes 
>> ).
>>  
>> Other browser implementers and app stores do not appear to have immediate 
>> plans to engage with DGAPI. There were some questions, no objections.
>>
>> Ergonomics
>>
>> Used in tandem with the Payment Request API.
>>
>> WebView Application Risks
>>
>> This API is disabled in WebView.
>>
>>
>> Debuggability
>>
>> We have had several requests from developers to make the API easier to 
>> debug, but it is difficult due to the interaction with a backing service 
>> based in an app/store context. We are looking for suggestions (
>> https://github.com/WICG/digital-goods/issues/33) on how we might improve 
>> the debuggability of the API.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> The tests are in //third_party/blink/web_tests/wpt_internal/digital-goods
>> .
>>
>> Flag name
>>
>> DigitalGoodsV2_1
>>
>> Requires code in //chrome?
>>
>> Yes
>>
>> Tracking bug
>>
>> https://crbug.com/1250604
>>
>> Launch bug
>>
>> https://crbug.com/1288420
>>
>> Estimated milestones
>>
>> We would like to ship DGAPI v2.1 in M102.
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5339955595313152
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype 1.0:
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.
>>
>> Intent to experiment 1.0:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ
>> .
>>
>> Intent to continue experimenting 1.0:
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o.
>>
>> Intent to experiment 2.0:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ
>> .
>>
>> Intent to ship 2.0:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2pjQ3O2GzDA/m/BqQ7UL6gAwAJ
>>
>> Intent to continue experimenting 

[blink-dev] Re: Intent to Ship: Digital Goods API 2.1

['Joe Medley' via blink-dev]

Are you hoping to ship in 102?

On Monday, April 11, 2022 at 7:45:43 AM UTC-7 rou...@chromium.org wrote:

> Contact emails
>
> gle...@chromium.org, rou...@chromium.org
>
> Explainer
>
> https://github.com/WICG/digital-goods/blob/main/explainer.md#api-v21
>
> Specification
>
> https://wicg.github.io/digital-goods/
>
> Difference between 2.0 and 2.1 
> 
>
> Design docs
>
> https://github.com/WICG/digital-goods/blob/master/explainer.md
>
>
> https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit
>
> Summary
>
> We would like to ship a non-breaking addition to the existing Digital 
> Goods API. This change:
>
>- 
>
>Adds to DigitalGoodsService:
>- 
>   
>   Promise> listPurchaseHistory();
>   - 
>
>Adds to ItemDetails:
>- 
>   
>   ItemType type;
>   - 
>   
>   sequence iconUrls;
>   - 
>   
>   unsigned short introductoryPriceCycles;
>   - 
>
>Adds enum ItemType.
>
>
> Use of the new methods/fields will require developers to update supporting 
> code in their apps, such as Android Browser Helper 
> .
>
> Blink component
>
> Blink>Payments 
> 
>
> Search tags
>
> payments , billing 
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/571 
>
> TAG review status
>
> TAG continues to think of DGAPI as a “product-specific API within one 
> company.”
>
> Other issues addressed.
>
> RisksInteroperability and Compatibility
>
> Similar to Payment Request: this API is used to talk to specific store 
> backends, and so its usage is tailored to the specific store. The reason 
> it's a proposed web standard is so that the same code (which is specific to 
> one store) is portable across browsers.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/349) Requested 
> 2020-05-27
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html) 
> Requested 2021-10-08
>
> Web developers: Positive (
> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
> )
>
> Other signals: rouslan@ presented DGAPI at 2021 TPAC 
>  (meeting notes 
> ) and at a PWA Dev 
> Sync 
>  
> (meeting 
> notes 
> ).
>  
> Other browser implementers and app stores do not appear to have immediate 
> plans to engage with DGAPI. There were some questions, no objections.
>
> Ergonomics
>
> Used in tandem with the Payment Request API.
>
> WebView Application Risks
>
> This API is disabled in WebView.
>
>
> Debuggability
>
> We have had several requests from developers to make the API easier to 
> debug, but it is difficult due to the interaction with a backing service 
> based in an app/store context. We are looking for suggestions (
> https://github.com/WICG/digital-goods/issues/33) on how we might improve 
> the debuggability of the API.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> The tests are in //third_party/blink/web_tests/wpt_internal/digital-goods.
>
> Flag name
>
> DigitalGoodsV2_1
>
> Requires code in //chrome?
>
> Yes
>
> Tracking bug
>
> https://crbug.com/1250604
>
> Launch bug
>
> https://crbug.com/1288420
>
> Estimated milestones
>
> We would like to ship DGAPI v2.1 in M102.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5339955595313152
>
> Links to previous Intent discussions
>
> Intent to prototype 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.
>
> Intent to experiment 1.0:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ
> .
>
> Intent to continue experimenting 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o.
>
> Intent to experiment 2.0:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ
> .
>
> Intent to ship 2.0:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2pjQ3O2GzDA/m/BqQ7UL6gAwAJ
>
> Intent to continue experimenting 2.0:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/DqnurOUBA9s/m/5H18GilKEQAJ
>
> Intent to prototype 2.1:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JaNDPCUr1ws/m/JFt-E7ePAQAJ
>
>
> This intent message was generated by Chrome Platform Status 
> 

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

['Joe Medley' via blink-dev]

Are you aiming for 102?

On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:

>
>
> On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> > Ah, I'm not familiar with that way of doing compat research. What would 
> > we gain from doing that vs. regular use-counter + HTTP Archive?
> > 
> > Do we expect those 0.1% to visibly break? (I guess that depends on
> > what they're feature testing for..)
> > 
> > 
> > I would not expect that at all based on the HTTP Archive query. If 
> > testing against "not all" was commonplace, I'd expect more results 
> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
> > happens mostly on features that actually *are* supported at the moment.
> > 
> > Just as an example (and to show that "not all" testing isn't a myth), 
> > one of the few (non-Yandex-script) sites that did show up was 
> > https://ww.sapo.pt , which does the following:
> > 
> > if(rule.mediaText.includes("not all") || ...)
> > 
> > By the looks of it, it's an early-out related to the theme switching, 
> > which prevents the code from amending the query if prefers-color-scheme 
> > is not supported. Had we not supported prefers-color-scheme, then I 
> > think the worst that could happen is that we end up with a more 
> > complicated query that still ultimately evaluates to false. Testing the 
> > page with the feature enabled (with and without dark mode preference), 
> > their color switcher still works normally.
> > 
> > That is just one site though, it's probably theoretically possible to 
> > write *something* that breaks. I did try to look at the "sample URLs" 
> > for the counters, but I couldn't actually reproduce the counters being 
> hit.
>
>
> It's a thing that even Google DevRel people have recommended in the 
> past, ftr :)
>
> https://web.dev/prefers-color-scheme/#supporting-dark-mode
>
> But if you have data to indicate this is not a problem in the wild I'd 
> be happy to implement it in Gecko after you ship this change.
>
> Cheers,
>
> -- Emilio
>

-- 
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/c3a38a8f-2029-4e05-a4f1-6f651f2fc5d1n%40chromium.org.

[blink-dev] Re: Intent to Enable Origin Trial support on Android WebView

['Joe Medley' via blink-dev]

Peter,

Do you know any release/availability dates yet? We need to add fields to 
the Chrome Status 
.

On Thursday, April 7, 2022 at 8:59:53 AM UTC-7 Peter Birk Pakkenberg wrote:

> Hello blink-dev@
>
> We are hoping to begin rolling out origin trial support on WebView. The 
> goal is to ensure that the origins who wish to test new Blink features can 
> reach users in Android WebView as well.
> Launch Bugs
>
> http://crbug.com/1186236 
>
> http://crbug.com/1308425 (internal launch bug)
> Summary
>
> We will soon enable origin trials on Android WebView, which means that 
> clients will start to honour Origin-Trial headers for trials that target 
> the Android platform in runtime_enabled_features.json5 
> ,
>  
> provided the feature is implemented for WebView. This means that a number 
> of existing Blink trials will be enabled. 
>
> The long term goal is to achieve parity between WebView and Chrome on 
> Android when it comes to experimentation for features implemented in Blink, 
> which has two key benefits to the Chromium project. First, it provides a 
> large number of additional clients to test new Blink features. Due to the 
> embedded nature of WebView, this will provide new insights into a part of 
> the web ecosystem that has previously not been accessible to 
> experimentation (for example hybrid apps). In turn, this will help to avoid 
> surprises for feature developers who rely on origin trials to launch new 
> features, which will hopefully lead to smoother feature launches. 
> Why Now
>
> Planned features on WebView require origin testing, making it a necessity 
> to enable the framework. Additionally, the longer origin trials remain 
> disabled on WebView, the more likely it is that a trial misses an issue on 
> WebView that could have been found, like it has happened in the past 
> . 
> Affected trials
>
> By our analysis, 14 trials 
> 
>  
> will be affected by the enablement on WebView. This means that they a) are 
> targeting the Android platform, and b) have been implemented in shared code 
> that is used by WebView. Other trials may rely on integrations in the 
> embedder, which have not been implemented for WebView, which means that 
> they won’t exhibit any new behaviour during the roll-out.
> Rollout plan
>
> WebView does not have good penetration on the dev/beta channels, so we 
> will have to do the primary experiment on Stable. Given that we will be 
> enabling all applicable origin trials on WebView at the same time as part 
> of our feature roll-out, we expect full support to reach all WebView users 
> in 3-4 weeks.
> Feedback from the Blink community
>
> We’d love to receive feedback and questions from the Blink community, 
> either via this thread, in the launch bug 
>  or 
> privately. Some of the things that we’ve been thinking about:
>
>
>- 
>
>Should targeting Android in runtime_enabled_features.json5 include or 
>exclude WebView? We propose for it to be included as the majority of 
> trials 
>are either applicable to WebView as well, or have the corresponding 
>features disabled through other means in Chromium.
>
>- 
>
>How should trial owners consider WebView metrics in their analysis? 
>For Googlers, the UMA dashboards provide this ability, although WebView 
>does not record UKM. Externally we’re investigating whether we can publish 
>WebView metrics as part of chromestatus.com, but that’s adjacent to 
>this effort.
>
>- 
>
>How should Web developers consider WebView usage? For the trials that 
>are applicable to WebView, ideally they wouldn’t. WebView powers a 
>significant share of browsing time on Android, so in most cases this is an 
>audience they already reach today, but (possibly unknowingly) isn’t 
> covered 
>by their own experimentation
>
>
>
> Sincerely,
> [image: Google Logo] 
> Peter Birk Pakkenberg
> Software Engineer
> pb...@google.com
> +447469379358 <+44%207469%20379358>
>

-- 
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/e1565163-8546-4781-b84a-bb6c74eed03cn%40chromium.org.

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

['Joe Medley' via blink-dev]

Is this shipping in 102?

On Wednesday, April 6, 2022 at 8:17:09 AM UTC-7 Daniel Bratell wrote:

> LGTM3
>
> /Daniel
> On 2022-03-30 18:03, Chris Harrelson wrote:
>
> LGTM2. Save-Data is already shipped (for a long time), and this seems like 
> a step in the right direction, without introducing a new header.
>
> On Wed, Mar 30, 2022 at 5:49 AM Mike West  wrote:
>
>> LGTM1. 
>>
>> This approach seems like a pretty reasonable compromise to me, thanks for 
>> iterating on it a bit.
>>
>> -mike
>>
>>
>> On Thu, Mar 24, 2022 at 8:59 PM Ari Chivukula  
>> wrote:
>>
>>> After discussion with @Mike West and @Mike Taylor the direction is 
>>> being changed, and the new approach is:
>>> (1) Keep the existing Save-Data header name
>>> (2) Keep the existing Save-Data value (`on` instead of `?1`)
>>> (3) Keep the existing Save-Data delegation by default to first and third 
>>> parties
>>> (4) Keep the existing omission of Save-Data when the value sent would be 
>>> the empty string
>>> (5) Add a new permissions policy, CH-Save-Data, which allows Save-Data 
>>> delegation to be restricted if desired
>>>
>>>
>>> https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
>>> https://github.com/WICG/savedata/pull/5
>>> https://github.com/WICG/client-hints-infrastructure/pull/101
>>>
>>> We can revisit re-naming in the future if desired, after this is 
>>> launched.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Wed, Mar 16, 2022 at 6:48 AM Ari Chivukula  
>>> wrote:
>>>
 As for usage, it's hard to gauge because it's sent by default when 
 Android Lite Mode is on. We're betting on the limited cases in which it's 
 ever sent going to zero (with the removal of Android Lite Mode) to 
 facilitate this. 

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


 On Wed, Mar 16, 2022 at 6:46 AM Ari Chivukula  
 wrote:

> (1) There's a thought to pipe OS-level data saver settings into 
> (Sec-CH-)Save-Data, but this work is not underway as far as I know. 
>
> (2) We're not making `Save-Data` subject to `Sec-CH-Save-Data`'s 
> permissions policy (`CH-Save-Data`). What I'm saying is that "explicitly 
> requesting Sec-CH-Save-Data or modifying the CH-Save-Data permissions 
> policy *will prevent* the old `Save-Data` header from being sent."
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Wed, Mar 16, 2022 at 1:29 AM Mike West  wrote:
>
>> On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula  
>> wrote:
>>
>>> (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
>>>
>>
>> SGTM. That seems like a reasonable pattern to document: I filed 
>> https://github.com/WICG/client-hints-infrastructure/issues/99.
>>
>> (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.
>>>
>>
>> Hrm. This sounds quite different from what was in the original 
>> intent. :) Two followups, if you don't mind:
>>
>> 1.  Does this intent also introduce a new triggering mechanism which 
>> would cause the header to be sent? My assumption was that we'd be basing 
>> this on the user's "lite mode" choice. If we're removing that, what's 
>> left?
>>
>> 2.  If you're additionally planning to change `Save-Data`'s behavior 
>> to make it subject to the `CH-Save-Data` policy, then it seems like the 
>> only advantage of introducing a new header is naming consistency with 
>> other 
>> client hints. Have y'all done any analysis to determine how many sites 
>> rely 
>> upon the current spelling of the header to change user-facing behavior? 
>> It 
>> seems like there might be strong reliance interests here, given the 
>> header's long tenure.
>>
>> -mike
>>
>>
>>> ~ 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 

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

['Joe Medley' via blink-dev]

When are you planning to ship this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Mar 16, 2022 at 6:19 AM Mike West  wrote:

> LGTM3.
>
> On Wednesday, March 16, 2022 at 11:08:29 AM UTC+1 Yoav Weiss wrote:
>
>> LGTM2
>>
>> On Tue, Mar 15, 2022 at 9:52 PM Mike Taylor 
>> wrote:
>>
>>> 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 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. :)
>>>
>>> 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

Re: [blink-dev] Re: Intent to Ship: WebTransport serverCertificateHashes option

['Joe Medley' via blink-dev]

Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Feb 22, 2022 at 2:17 AM Victor Vasiliev  wrote:

> Hi Joe,
>
> This is currently scheduled to ship in M100.
>
> Thanks,
>   Victor.
>
> On Wed, Feb 16, 2022 at 12:14 PM Joe Medley  wrote:
>
>> Which version of Chrome are you wanting to ship in?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Feb 16, 2022 at 8:20 AM Daniel Bratell 
>> wrote:
>>
>>> LGTM3
>>>
>>> Comment about double checking the security review stands.
>>>
>>> (We decided this was fine two weeks ago but not all the necessary mails
>>> ended up on the list - our fault, good that you pinged us!)
>>>
>>> /Daniel
>>> On 2022-02-16 13:39, 'Victor Vasiliev' via blink-dev wrote:
>>>
>>> Friendly ping.
>>>
>>> On Wed, Feb 2, 2022 at 11:53 AM Chris Harrelson 
>>> wrote:
>>>
 LGTM2

 My understanding is that there is a security/privacy review ongoing to
 double-check this feature, so if there is an LGTM3 please make sure that
 review has concluded as well.

 On Wed, Feb 2, 2022 at 3:28 AM Yoav Weiss 
 wrote:

> LGTM1
>
> On Thursday, January 20, 2022 at 7:08:59 AM UTC+1 Victor Vasiliev
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Spec
>>
>>
>> https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes
>>
>> WebTransport has been already covered by a series of TAG reviews (389
>> , 669
>> ).
>>
>> Summary
>>
>> In WebTransport, the serverCertificateHashes option allows the
>> website to connect to a WebTransport server by authenticating the
>> certificate against the expected certificate hash instead of using the 
>> Web
>> PKI.  This feature allows Web developers to connect to WebTransport 
>> servers
>> that would normally find obtaining a publicly trusted certificate
>> challenging, such as hosts that are not publically routable, or virtual
>> machines that are ephemeral in nature.
>>
>> During the WebTransport Intent to Ship email thread
>> ,
>> concerns were raised regarding the security considerations of this 
>> portion
>> of the spec being incomplete.  We believe that we have addressed those
>> concerns (notably, in this PR
>> ).
>>
>
> Please followup on the PR to ensure it lands. Thanks! :)
>
>
>>   In terms of the actual code behavior, the only major difference
>> since the previous thread is that we no longer allow RSA keys for the
>> certificates.
>>
>> Link to “Intent to Prototype” blink-dev discussion
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes.
>>
>> Debuggability
>>
>> The certificate-related errors for WebTransport sessions are logged
>> into the developer console.
>>
>> Measurement
>>
>> The use of this feature is tracked by the
>> WebTransportServerCertificateHashes use counter.
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> There is some discussion about adding a mechanism to prevent websites
>> from using this feature via an HTTP header (either CSP or a new header).
>> Some of the proposals could potentially break existing usage under 
>> certain
>> conditions (e.g. if a webpage both uses serverCertificateHashes and has a
>> connect-src directive, and we decide to extend connect-src); I expect for
>> those cases to be sufficiently niche to ultimately not be a problem, and
>> the question itself is of fairly low priority as there does not seem to 
>> be
>> a strong security reason for a website to restrict 
>> serverCertificateHashes.
>>
>
> Are you planning to file a separate intent once those plans
> materialize?
>
>
>>
>> Gecko: worth prototyping
>> 
>>
>> WebKit: no signal
>> 
>>
>> Web / Framework developers: positive (we have received indication in
>> the past that serverCertificateHashes is a blocker for migrating from
>> 

Re: [blink-dev] Re: Intent to Ship: WebTransport serverCertificateHashes option

['Joe Medley' via blink-dev]

Which version of Chrome are you wanting to ship in?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Feb 16, 2022 at 8:20 AM Daniel Bratell  wrote:

> LGTM3
>
> Comment about double checking the security review stands.
>
> (We decided this was fine two weeks ago but not all the necessary mails
> ended up on the list - our fault, good that you pinged us!)
>
> /Daniel
> On 2022-02-16 13:39, 'Victor Vasiliev' via blink-dev wrote:
>
> Friendly ping.
>
> On Wed, Feb 2, 2022 at 11:53 AM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> My understanding is that there is a security/privacy review ongoing to
>> double-check this feature, so if there is an LGTM3 please make sure that
>> review has concluded as well.
>>
>> On Wed, Feb 2, 2022 at 3:28 AM Yoav Weiss  wrote:
>>
>>> LGTM1
>>>
>>> On Thursday, January 20, 2022 at 7:08:59 AM UTC+1 Victor Vasiliev wrote:
>>>
 Contact emails

 yhir...@chromium.org, vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Spec


 https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes

 WebTransport has been already covered by a series of TAG reviews (389
 , 669
 ).

 Summary

 In WebTransport, the serverCertificateHashes option allows the website
 to connect to a WebTransport server by authenticating the certificate
 against the expected certificate hash instead of using the Web PKI.  This
 feature allows Web developers to connect to WebTransport servers that would
 normally find obtaining a publicly trusted certificate challenging, such as
 hosts that are not publically routable, or virtual machines that are
 ephemeral in nature.

 During the WebTransport Intent to Ship email thread
 ,
 concerns were raised regarding the security considerations of this portion
 of the spec being incomplete.  We believe that we have addressed those
 concerns (notably, in this PR
 ).

>>>
>>> Please followup on the PR to ensure it lands. Thanks! :)
>>>
>>>
   In terms of the actual code behavior, the only major difference since
 the previous thread is that we no longer allow RSA keys for the
 certificates.

 Link to “Intent to Prototype” blink-dev discussion


 https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ

 Is this feature supported on all six Blink platforms (Windows, Mac,
 Linux, Chrome OS, Android, and Android WebView)?

 Yes.

 Debuggability

 The certificate-related errors for WebTransport sessions are logged
 into the developer console.

 Measurement

 The use of this feature is tracked by the
 WebTransportServerCertificateHashes use counter.

 Risks

 Interoperability and Compatibility

 There is some discussion about adding a mechanism to prevent websites
 from using this feature via an HTTP header (either CSP or a new header).
 Some of the proposals could potentially break existing usage under certain
 conditions (e.g. if a webpage both uses serverCertificateHashes and has a
 connect-src directive, and we decide to extend connect-src); I expect for
 those cases to be sufficiently niche to ultimately not be a problem, and
 the question itself is of fairly low priority as there does not seem to be
 a strong security reason for a website to restrict serverCertificateHashes.

>>>
>>> Are you planning to file a separate intent once those plans materialize?
>>>
>>>

 Gecko: worth prototyping
 

 WebKit: no signal
 

 Web / Framework developers: positive (we have received indication in
 the past that serverCertificateHashes is a blocker for migrating from
 WebRTC at least one of them)

 Ergonomics

 The API is roughly modeled after a similar WebRTC API
 (RtcDtlsFingerprint), with a noted improvement that the certificate hash no
 longer requires to be serialized into a specific format.

 Activation

 Using this feature would require web developers to design their
 application in a way that supports generating and distributing ephemeral
 certificates on demand.

 Security

 Security considerations for this feature are discussed at length in PR
 #375
 
 .

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

['Joe Medley' via blink-dev]

Thank you.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Feb 15, 2022 at 9:51 AM Scott Haseley  wrote:

> Sorry for the confusion! This is enabled by default in 100, which should
> be reflected in chromestatus now.
>
> On Tue, Feb 15, 2022 at 9:35 AM Joe Medley  wrote:
>
>> Apologies. I keep using 'shipping' in a sloppy way. I should have asked,
>> will this be available by default in 100? If so, that number needs to be
>> the shipping milestone fields, not the dev trial milestone fields.
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Tue, Feb 15, 2022 at 8:59 AM Scott Haseley 
>> wrote:
>>
>>> Hi Joe -- This is shipping in 100.
>>>
>>> On Tue, Feb 15, 2022 at 8:45 AM Joe Medley  wrote:
>>>
 I'm confused about the timeline for this. Is this shipping in 100 or is
 it starting a dev trial in 100?

 Joe
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley 
 wrote:

> Contact emailsshase...@chromium.org
>
> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
> Examples:
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>
> Specification
> https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>
> Summary
>
> Throws an AbortSignal's reason if the signal is aborted. This
> convenience method can be used by signal-handling functions to check a
> signal's abort status and propagate the abort reason, e.g. after async
> operations that might change a signal's state.
>
> Blink componentBlink>DOM
> 
>
> TAG reviewN/A: the feature has been merged into the DOM standard and
> has been shipped in at least one other browser, in line with the criteria
> in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
> .
>
> TAG review statusNot applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Low risk. This feature is already part of the DOM standard, has web
> platform tests, and is implemented by Safari and Firefox. We'll improve
> eventual interop by shipping this feature.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>
> WebKit: Shipped/Shipping (
> https://bugs.webkit.org/show_bug.cgi?id=234127)
>
> Web developers: Positive. Minor positive feedback (likes) from
> announcement tweets:
> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
> https://twitter.com/jasnell/status/1466093594129756166
>
> Other signals:
>
> Ergonomics
>
> None; this feature is an ergonomic improvement for AbortSignal users.
>
> Activation
>
> The feature has already been implemented in both Safari and Firefox,
> but it would benefit from a polyfill for use in older browser versions.
>
> Security
>
> None.
>
> Debuggability
>
> Basic tooling only, i.e. autocomplete support for the new AbortSignal
> method will be provided.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes (
> https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort
> )
>
> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>
> Requires code in //chrome?False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>
> Launch bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>
> MeasurementUseCounter: AbortSignalThrowIfAborted
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>
> Estimated milestones
> DevTrial on desktop 100
> DevTrial on android 100
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5029737100476416
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
> 
>
>
> This intent message was generated by Chrome Platform Status
> .
>

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

['Joe Medley' via blink-dev]

Apologies. I keep using 'shipping' in a sloppy way. I should have asked,
will this be available by default in 100? If so, that number needs to be
the shipping milestone fields, not the dev trial milestone fields.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Feb 15, 2022 at 8:59 AM Scott Haseley  wrote:

> Hi Joe -- This is shipping in 100.
>
> On Tue, Feb 15, 2022 at 8:45 AM Joe Medley  wrote:
>
>> I'm confused about the timeline for this. Is this shipping in 100 or is
>> it starting a dev trial in 100?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley 
>> wrote:
>>
>>> Contact emailsshase...@chromium.org
>>>
>>> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
>>> Examples:
>>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>>>
>>> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>>>
>>> Summary
>>>
>>> Throws an AbortSignal's reason if the signal is aborted. This
>>> convenience method can be used by signal-handling functions to check a
>>> signal's abort status and propagate the abort reason, e.g. after async
>>> operations that might change a signal's state.
>>>
>>> Blink componentBlink>DOM
>>> 
>>>
>>> TAG reviewN/A: the feature has been merged into the DOM standard and
>>> has been shipped in at least one other browser, in line with the criteria
>>> in
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
>>> .
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk. This feature is already part of the DOM standard, has web
>>> platform tests, and is implemented by Safari and Firefox. We'll improve
>>> eventual interop by shipping this feature.
>>>
>>> Gecko: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>>>
>>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127
>>> )
>>>
>>> Web developers: Positive. Minor positive feedback (likes) from
>>> announcement tweets:
>>> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
>>> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
>>> https://twitter.com/jasnell/status/1466093594129756166
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> None; this feature is an ergonomic improvement for AbortSignal users.
>>>
>>> Activation
>>>
>>> The feature has already been implemented in both Safari and Firefox, but
>>> it would benefit from a polyfill for use in older browser versions.
>>>
>>> Security
>>>
>>> None.
>>>
>>> Debuggability
>>>
>>> Basic tooling only, i.e. autocomplete support for the new AbortSignal
>>> method will be provided.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes (
>>> https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort
>>> )
>>>
>>> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>>>
>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>>>
>>> MeasurementUseCounter: AbortSignalThrowIfAborted
>>>
>>> Sample links
>>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>>>
>>> Estimated milestones
>>> DevTrial on desktop 100
>>> DevTrial on android 100
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5029737100476416
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
>>> 
>>>
>>>
>>> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%40mail.gmail.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to 

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

['Joe Medley' via blink-dev]

I'm confused about the timeline for this. Is this shipping in 100 or is it
starting a dev trial in 100?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley  wrote:

> Contact emailsshase...@chromium.org
>
> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
> Examples:
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>
> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>
> Summary
>
> Throws an AbortSignal's reason if the signal is aborted. This convenience
> method can be used by signal-handling functions to check a signal's abort
> status and propagate the abort reason, e.g. after async operations that
> might change a signal's state.
>
> Blink componentBlink>DOM
> 
>
> TAG reviewN/A: the feature has been merged into the DOM standard and has
> been shipped in at least one other browser, in line with the criteria in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
> .
>
> TAG review statusNot applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Low risk. This feature is already part of the DOM standard, has web
> platform tests, and is implemented by Safari and Firefox. We'll improve
> eventual interop by shipping this feature.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)
>
> Web developers: Positive. Minor positive feedback (likes) from
> announcement tweets:
> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
> https://twitter.com/jasnell/status/1466093594129756166
>
> Other signals:
>
> Ergonomics
>
> None; this feature is an ergonomic improvement for AbortSignal users.
>
> Activation
>
> The feature has already been implemented in both Safari and Firefox, but
> it would benefit from a polyfill for use in older browser versions.
>
> Security
>
> None.
>
> Debuggability
>
> Basic tooling only, i.e. autocomplete support for the new AbortSignal
> method will be provided.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes (
> https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort
> )
>
> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>
> MeasurementUseCounter: AbortSignalThrowIfAborted
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>
> Estimated milestones
> DevTrial on desktop 100
> DevTrial on android 100
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5029737100476416
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
> 
>
>
> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%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/CAJUhtG_1ugj%3Dt7%3DWSNSt%3DqnFrpR22NSUPdsXLEqdNT_4zGtEUQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: hwb() color notation

['Joe Medley' via blink-dev]

Anders,

Which version of Chrome do you hope to ship in?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Feb 8, 2022 at 2:41 AM Anders Hartvoll Ruud 
wrote:

> Contact emailsandr...@chromium.org, on behalf of: 
> jan.kei...@gmail.com 
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-color/#the-hwb-notation
>
> Summary
>
> HWB (short for Hue-Whiteness-Blackness) is another method of specifying
> sRGB colors, similar to HSL, but often even easier for humans to work with.
> It describes colors with a starting hue, then a degree of whiteness and
> blackness to mix into that base hue.
>
> Example CSS declaration: color:hwb(194 0% 0%);
>
>
> Since hwb() resolves to RGB, it's a relatively straightforward addition
> that doesn't add complexity or performance concerns.
>
>
> CL: https://chromium-review.googlesource.com/c/chromium/src/+/3404291
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewDidn't file one.
>
> Risks
>
> Interoperability and Compatibility
>
>
> Gecko: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/96)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/11989/new-webkit-features-in-safari-15/)
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> Inspector support will be shipped at the same time.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes:
>
> https://wpt.fyi/results/css/css-color?label=master=experimental=hwb
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=123
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5637256860663808
>
> 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/CAKFBnUoZTq_4U9-ocMkOPDczeZ6DSfdCLZGkY8Crbp0tT68OxA%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/CAJUhtG_VuY-NLQGu8faxmj17ieuKJTRMSkM0rDbWBGRJDgX5RQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Continue Experimenting: Speculation Rules (Prefetch)

['Joe Medley' via blink-dev]

Jeremy,

When do you hope to ship this?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Jan 28, 2022 at 11:51 AM Jeremy Roman  wrote:

> On Fri, Jan 28, 2022 at 4:33 AM Yoav Weiss  wrote:
>
>> LGTM to continue experimentation. Note that this would bring the OT to 11
>> milestones, which is approaching the limits of OT timelines.
>>
>> On Wed, Jan 26, 2022 at 9:57 PM Jeremy Roman 
>> wrote:
>>
>>> On Wed, Jan 26, 2022 at 10:18 AM Yoav Weiss 
>>> wrote:
>>>
 Any current feedback from the OT up until now?

>>>
>>> Feedback on the speculation rules API itself has been relatively
>>> limited. We had one issue where server postprocessing incorrectly
>>> interpreted a 

Re: [blink-dev] Intent to Deprecate and Remove: Persistent Quota

['Joe Medley' via blink-dev]

Hi,

When are you planning to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Jan 7, 2022 at 1:17 PM Colm O Flynn  wrote:

> Quick question in relation to this.
>
> Is there any debug logging one can enable if one thinks that the browser
> is re-claiming files deleted from the temporary file system?
> i.e. Where the browser would log that is deleting file x because storage
> limit has been hit?
>
> Thanks in advance
>
>
>
> On Thursday, August 5, 2021 at 11:18:30 PM UTC+1 Marijn Kruisselbrink
> wrote:
>
>> On Thu, Aug 5, 2021 at 2:41 PM Alex Russell 
>> wrote:
>>
>>> Do we have stats on potential storage pressure evictions that would be
>>> changed as a result of this change (as that appears to be the only place
>>> behavior differs)? And is there any UI that we display (e.g. in
>>> cache/storage clearing) that will be affected?
>>>
>> Good questions. No, I don't think we have stats that would tell us
>> potential changes to storage pressure evictions as a result of this change.
>> Data stored in the persistent file system would indeed go from never being
>> evicted today to being evicted with all other data an origin stores. Having
>> said that, in more than 99.9% of the cases where we evict data, that data
>> has been last accessed years ago.
>>
>> As far as affected UI, the current UI isn't very good in displaying this
>> legacy persistent storage. I don't expect any of the storage management UI
>> to change, if anything getting rid of persistent quota will mean less
>> chance for bugs where we might inadvertently not count or include
>> persistent storage when displaying information about a site. The main thing
>> that will change UI wise is that there will no longer be a "foo.com
>> wants to permanently store data on your device" permission prompt that
>> accompanied usage of persistent quota.
>>
>>
>>> On Thursday, July 29, 2021 at 4:13:57 PM UTC-7 Chris Harrelson wrote:
>>>
>> LGTM2

 On Wed, Jul 28, 2021 at 9:48 AM Yoav Weiss 
 wrote:

>>> Thanks for clarifying! This seems like a low risk indeed.
>
> *LGTM1* to deprecate and remove (while keeping track of related
> issue, just in case)
>
> On Wed, Jul 28, 2021 at 6:41 PM Marijn Kruisselbrink <
> m...@chromium.org> wrote:
>
 To elaborate a bit more on the potential for breakage, I believe the
>> only way a website could be truly broken from this change is if it 
>> somehow
>> relies on temporary and persistent quota being separate buckets. Not sure
>> what kind of logic they would have to employ to actually be broken by 
>> that
>> no longer being the case though. As such my expectation is that it is
>> extremely unlikely that any site will be broken by this. Certainly none 
>> of
>> the sites in httparchive I looked at.
>>
> On Mon, Jul 26, 2021 at 1:25 PM Marijn Kruisselbrink <
>> m...@chromium.org> wrote:
>>
> On Mon, Jul 26, 2021 at 2:26 AM Yoav Weiss 
>>> wrote:
>>>
 Since the 0.4% usage numbers are suspected to be a very loose
 upper-bound, I wonder what's the best strategy here.
 Is there a way to use-count cases where storage quota would run out
 as temporary but not as persistent?

>>> Good question. I think today we actually generally allow websites to
>>> store much more data in the temporary quota bucket than in the 
>>> persistent
>>> quota bucket. The latter is capped at 10GB, while the former in our
>>> histograms is more than 10GB 97% of the time on desktop, and even on 
>>> mobile
>>> is larger than that 80% of the time (and actual usage doesn't tend to 
>>> get
>>> anywhere remotely near these amounts in the vast majority of cases). So
>>> even if websites that are using the persistent file system are on 
>>> average
>>> using a lot more data than other websites, in the majority of cases that
>>> should keep working just the same way.
>>>
>>>
 If not, are you planning to roll this out with a kill-switch while
 monitoring filed issues for breakage?

>>> The described approach was intentionally picked to minimize the risk
>>> of breakage, as such I'm fairly confident that just rolling out the 
>>> change
>>> directly and relying on dev & beta coverage for issues should be safe
>>> enough. Having to support persistent quota for longer will make some 
>>> other
>>> ongoing projects/refactoring in the area more challenging, so the 
>>> sooner we
>>> could get rid of the code the better. But if you feel the risk might be 
>>> too
>>> high we certainly could roll this out with a kill-switch, we'd just 
>>> prefer
>>> not to.
>>>
>> On Fri, Jul 23, 2021 at 6:21 PM Marijn Kruisselbrink <
 m...@chromium.org> wrote:

>>> On Thu, Jul 22, 

Re: [blink-dev] PSA: Aligning Resource Timing's `nextHopProtocol` attribute with the specs

['Joe Medley' via blink-dev]

Which version is this shipping in?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jan 5, 2022 at 11:13 AM Chris Harrelson 
wrote:

> If Gecko and Webkit don't have this behavior, then please file a bug
> against them to make them aware. Otherwise, it seems reasonable to treat
> this as a bugfix rather than an intent-to-ship. +Joe Medley
>  so that this change can be noted in the next beta
> blog post.
>
> On Wed, Jan 5, 2022 at 10:56 AM Tom McKee  wrote:
>
>>
>> I had assumed RUM providers wouldn't need to be notified but was hoping
>> for feedback from this list on the subject .
>> I doubt there would be problems because the empty string ought to already
>> come up for them quite often when dealing with
>> cross-origin resources but I don't know if that's a good enough bar or
>> not... It certainly wouldn't hurt to bring it up on the
>> WebPerf Working Group call tomorrow; I'll take an AI to poll the folks
>> over there for their opinions as I know at least a few RUM
>> providers typically attend.
>>
>
> +1 to asking at that WG being a good way to get signals on this question.
>
>
>> On Wednesday, January 5, 2022 at 12:26:54 PM UTC-5 Chris Harrelson wrote:
>>
>>> Hi Tom,
>>>
>>> Four questions:
>>> * Do Webkit and Gecko implement the same behavior already?
>>> * Will RUM providers need to be notified?
>>> * In what milestone will this be shipped?
>>> * I assume that the behavior you're implementing is already specified
>>> and tested in WPT?
>>>
>>> On Wed, Jan 5, 2022 at 9:10 AM Tom McKee  wrote:
>>>
 Howdy!

 I'm working to land a CL  to fix
 crbug.com/1284631 to better align our implementation of Resource
 Timing with the Resource Timing
  and Fetch
  specs.

 The result of this change will affect all `non-document destination`
 fetches (e.g. fetches that aren't iframe contents). Such fetches used to
 always expose the, potentially sensitive, `nextHopProtocol` value. After
 this change, we will treat `nextHopProtocol` the same as any other
 sensitive information in Resource Timing; expose it to same-origin
 requesters or when the response's Timing-Allow-Origin header explicitly
 allows the requester's origin.

 This change is web observable as folks that have been reading the
 `nextHopProtocol` value could start to see the empty string instead of
 things like "http/1.1", "h2", etc. AFAICT, there's only three classes of
 users who could be impacted:

- *Well-meaning/typical content*: We don't expect this change to
break anything here because Resource Timing is a diagnostic API.
- *RUM providers*: They'll see shifts in their data if/when they
collect `nextHopProtocol` but there are already many cases where they'd
need to handle the empty string already.
- *Shady folks:* Sniffing other origin's protocol values will no
longer be possible in this way which is probably what we'd have liked 
 from
the start :)

 Let me know if folks think this change warrants sharing to a larger
 audience, though!

 Cheers,
 - Tom

 P.S. crbug.com/1284631 is basically the same issue but for the
 `workerStart` attribute. A fix for that should be coming down the pipe
 shortly :)

 --
 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/CAD%2BxnEFZa1DjWf2Ap83tf9fRu6p4e2XtVMyA2kV0WeVXWYT3yA%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/CAJUhtG-jsmmJ_WEw7uUpTJEzTwnZG2ryZa3J86g%3DQT1h-oBzCQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Joe Medley' via blink-dev]

When are you hoping to ship?

On Wednesday, January 5, 2022 at 9:16:28 AM UTC-8 yoav...@chromium.org 
wrote:

> LGTM3
>
> On Wed, Jan 5, 2022 at 5:52 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2022-01-05 17:51, Chris Harrelson wrote:
>>
>> LGTM1 to ship scalabilityMode, but not the pluralized name or 
>> referenceScaling. 
>>
>> Please open a new intent if you wish to ship one of the others (otherwise 
>> this intent-to-ship would be too confusing).
>>
>> Thanks, and happy new year.
>>
>> On Mon, Dec 20, 2021 at 12:07 PM 'Chris Cunningham' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Sorry I'm late. Lots of family stuff this month. I'm about to be OOO for 
>>> the holidays. 
>>>
>>> > There seems to be agreement to add support for referenceScaling in 
>>> Media Capabilities (https://github.com/w3c/media-capabilities/issues/182) 
>>> so I'm assuming that a PR will follow.  
>>>
>>> I can confirm this agreement for MediaCapabilities. I expect +Johannes 
>>> Kron will send a PR to amend the MC spec. 
>>>
>>> On Wednesday, December 15, 2021 at 3:14:42 PM UTC-8 Harald Alvestrand 
>>> wrote:
>>>
 At the moment, I think we can safely ship: 

 - RTCRtpEncodingParameters extension scalabilityMode (
 https://w3c.github.io/webrtc-svc/#dom-rtcrtpencodingparameters-scalabilitymode
 )

 We have an open discussion on whether or not to ship this part on 
 senders (we've decided not to ship it on receivers):

 - RTCRtpCodecCapability extension scalabilityModes (
 https://w3c.github.io/webrtc-svc/#dom-rtcrtpcodeccapability-scalabilitymodes
 )

 There are no mandatory-to-implement scalability modes except for L1T1 
 (which we need to add support for).

 I think that as currently specified, feature detection can be done in 
 the absence of the RTCRtpCodecCapability extension by setting the mode to 
 L1T1, reading back the encoding parameters, and seeing if the mode is set.




 On Wed, Dec 15, 2021 at 6:01 PM Philip Jägenstedt  
 wrote:

> Hi Bernard, 
>
> Can you clarify what the consensus is on RTCRtpEncodingParameters's 
> scalabilityMode member? That remains in 
> https://w3c.github.io/webrtc-svc/, but will it be removed? Meanwhile, 
> referenceScaling is only partly spec'd, there's no IDL for it but a link 
> to 
> https://github.com/w3c/media-capabilities/issues/182.
>
> Harald, if you could confirm the precise API surface that you'd like 
> to ship, that would be great.
>
> Best regards,
> Philip
>
> On Thu, Dec 9, 2021 at 3:21 AM Bernard Aboba  
> wrote:
>
>> Harald said:  
>>
>> "It seems like we don't have a strong push towards either the 
>> MediaCapabilities or the Codec Capabilities solution in the issue on the 
>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is 
>> bad for quick resolution."
>>
>> [BA] On the receiver/decoder side (for WebRTC-SVC, Media Capabilities 
>> and WebCodecs), we have a path forward  which involves using a 
>> referenceScaling boolean and removing scalabiltyMode advertisement and 
>> configuration.  The consensus is  reflected in the current editor's 
>> draft 
>> of WebRTC-SVC (see:  https://w3c.github.io/webrtc-svc/ ) and 
>> compatible PRs are under development for MediaCapabilities and 
>> WebCodecs. 
>>
>> On the sender/encoder side, we have added the "L1T1" scalability mode 
>> and specified its use in both advertisement and encoder configuration. 
>>
>> Chris can provide more details with respect to the moving parts in 
>> Media Capabilities and WebCodecs. 
>>
>> Here are links to the (now resolved) WebRTC-SVC issues:
>> https://github.com/w3c/webrtc-svc/issues/48
>> https://github.com/w3c/webrtc-svc/issues/52
>>
>> Here are links to related WebCodecs issues: 
>> https://github.com/w3c/webcodecs/issues/399
>>
>> Here are links to the related Media Capabilities issues:  
>> https://github.com/w3c/media-capabilities/issues/182
>> https://github.com/w3c/media-capabilities/issues/183
>> https://github.com/w3c/media-capabilities/issues/185
>>
>>
>>
>>
>> On Wednesday, December 8, 2021 at 9:37:57 AM UTC-8 Philipp Hancke 
>> wrote:
>>
>>> Am Mi., 8. Dez. 2021 um 17:52 Uhr schrieb Philip Jägenstedt <
>>> foo...@chromium.org>:
>>>
 Hi Harald, 

 Can you spell out what the uncontroversial parts of this would be? 
 Looking at the IDL in https://w3c.github.io/webrtc-svc/ it looks 
 like it's all about modes.

 My guess is that it's RTCRtpEncodingParameters's scalabilityMode, 
 but is that right?

>>>
>>> yeah
>>>
>>> 

Re: [blink-dev] Intent to Ship: AudioContext.outputLatency

['Joe Medley' via blink-dev]

Please update the Chrome Status entry as soon as you know. (That will
inform me as well.)
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Dec 21, 2021 at 12:32 PM Ajay Rahatekar 
wrote:

> The metrics are landing in Jan. So likely shipping in 99.
>
> -Ajay
>
> On Tue, Dec 21, 2021 at 11:54 AM Joe Medley  wrote:
>
>> Is this shipping in 98?
>>
>> On Wednesday, December 15, 2021 at 9:02:09 AM UTC-8 hongchan wrote:
>>
>>> Thank you all!
>>>
>>> 1. I'll land the metrics CL and follow up here.
>>> 2. The discussion in the WebKit mailing list is ongoing, so I'll report
>>> back when it's done.
>>>
>>> Cheers,
>>> Hongchan
>>>
>>>
>>> On Wed, Dec 15, 2021 at 8:58 AM Chris Harrelson 
>>> wrote:
>>>
 LGTM3.

 On Wed, Dec 15, 2021 at 8:47 AM Mike Taylor 
 wrote:

> LGTM2 w/ same condition.
>
> On 12/15/21 11:47 AM, Yoav Weiss wrote:
>
> LGTM1 conditional on those metrics landing (but no need to wait for
> data from the metrics to come in).
>
> On Monday, December 6, 2021 at 3:22:26 PM UTC+1 Mike Taylor wrote:
>
>> To circle back - last week we (myself + some other
>> privacy/anti-covert tracking reviewers) met with some folks working on 
>> this
>> feature. We ended up with an AI for Hongchan to land metrics on the 
>> values
>> that getOutputTimestamp would produce (if called, when a new AudioContext
>> is created, IIRC) as a way to get some data on the utility for using 
>> either
>> of these APIs for device fingerprinting.
>>
>> On 12/1/21 11:27 AM, Hongchan Choi wrote:
>>
>> So far we have not discussed the deprecation plan, but I believe
>> that's reasonable as well.
>>
>> I registered myself to the webkit-dev list to post a question, but
>> somehow I am getting 403 forbidden. The email is sent to the list, I am 
>> not
>> seeing the message is getting posted on the list. Not sure what to do 
>> there.
>>
>> On Wed, Dec 1, 2021 at 3:18 AM Yoav Weiss 
>> wrote:
>>
>>> So are y'all planning to deprecate and remove `getOutputTimestamp`
>>> once this ships? If so, that sounds reasonable.
>>>
>>> I note Chris asked y'all to file for a webkit signal upthread. Did
>>> that happen?
>>>
>>> On Tuesday, November 30, 2021 at 12:54:17 AM UTC+1 hongchan wrote:
>>>
 I agree that outputLatency is better in terms of both usability and
 interoperability.

 FYI, the counter shows getOutputTimestamp is about 0.001% and there
 are no partners who are using this API:

 https://chromestatus.com/metrics/feature/popularity#AudioContextGetOutputTimestamp


 On Mon, Nov 22, 2021 at 3:00 PM Chris Cunningham <
 chcunn...@google.com> wrote:

> Re: privacy discussion, Hongchan and I scheduled to meet with Paul
> Jensen next week.
>
> Also, I recently determined that this new WebAudio API
> (outputLatency) is largely redundant with an existing API
> (getOutputTimestamp()).
> https://github.com/WebAudio/web-audio-api/issues/2461
>
> Chrome has already shipped the latter API, so I believe this new
> API doesn't add potential for additional fingerprinting. Shipping 
> both APIs
> is still a good idea for the sake of inter-op.
>
> On Friday, November 19, 2021 at 8:45:28 AM UTC-8 hongchan wrote:
>
>> Thanks for the clarification, Yoav!
>>
>> I hope the mitigation approach in the previous comment makes
>> sense from the privacy perspective, but it will hurt the 
>> usability/value of
>> this API significantly.
>> For the privacy-focused discussion, should I use other venues
>> rather than this I2S thread?
>>
>> Cheers,
>> Hongchan
>>
>>
>> On Thu, Nov 18, 2021 at 10:35 PM Yoav Weiss 
>> wrote:
>>
>>> Apologies, I misread the discussion. A spec issue is indeed not
>>> needed, as this is already covered.
>>>
>>> From my perspective, since this exposes active entropy, the fact
>>> that it exposes more data than the (passively exposed) platform is 
>>> not
>>> prohibitive on its own.
>>> At the same time, it'd be good to work with privacy-focused
>>> folks to make sure we expose as little information as needed to 
>>> maintain
>>> the API's functionality, but not more.
>>>
>>> On Fri, Nov 19, 2021 at 4:57 AM Chris Cunningham <
>>> chcunn...@chromium.org> wrote:
>>>
 > If the reported value is incorrect, the A/V synchronization
 won't be possible. (Perhaps chcunningham@ can say more about
 

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

['Joe Medley' via blink-dev]

Please update the status entry as soon as you know. (That will inform me so
that I know which beta post to mention it in.)
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Dec 21, 2021 at 12:17 PM Frédéric Wang  wrote:

> Patch is under review but has not landed yet.
>
> Le 21/12/2021 à 21:02, 'Joe Medley' via blink-dev a écrit :
> > Is this in 98?
>
>

-- 
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/CAJUhtG_0RxmvOjTifLBWjEVfSBWtmn%2Bnp2uGfdj-VVEwtGEhVQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Convert adoptedStyleSheets to use ObservableArray

['Joe Medley' via blink-dev]

Is this on 98?

On Tuesday, December 14, 2021 at 10:13:18 AM UTC-8 mas...@chromium.org 
wrote:

> Thanks everyone!
>
> On Tue, Dec 14, 2021 at 9:59 AM Yoav Weiss  wrote:
>
>> LGTM3
>>
>> On Tue, Dec 14, 2021 at 4:12 PM Mike Taylor  wrote:
>>
>>> LGTM2
>>>
>>> On 12/14/21 10:05 AM, Camille Lamy wrote:
>>>
>>> Thanks Mason! I wasn't sure if it was possible to share it cross-origin, 
>>> hence my question. If you can only get a non-shared copied version, then 
>>> this is fine from a security POV.
>>>
>>> On Tuesday, December 14, 2021 at 4:53:52 AM UTC+1 Mason Freed wrote:
>>>
 Thanks Alex! I did file a TAG review for ObservableArray and this 
 first use by adoptedStyleSheets 
 . No response yet.

 On Mon, Dec 13, 2021 at 4:03 PM Alex Russell  
 wrote:

> Thanks Mason, that matches my understanding of the situation too. 
>
> Can you please file an FYI with the TAG to let them know this new type 
> is being put into use? It is often helpful for them to stay informed of 
> new 
> WebIDL primitives that they can suggest to others to help drive 
> consistency.
>
> Sending LGTM1 in the tool.
>
> On Wednesday, December 8, 2021 at 3:49:55 PM UTC-8 Mason Freed wrote:
>
>> Hi Camille, 
>>
>> Thanks for the question. I guess I have two points/questions:
>> 1. That sounds like a general question about adoptedStyleSheets 
>> (which we shipped a few years ago), and isn't at all particular to the 
>> conversion from FrozenArray to ObservableArray. But did I miss something 
>> relevant about this change?
>> 2. Can you help me understand how you'd go about sharing a single 
>> CSSStyleSheet between cross-origin documents? If you passed it around 
>> via 
>> postMessage, it'd be a (structured clone) copy, so it would no longer be 
>> shared. I agree that it'd be a (huge) privacy concern if this were 
>> possible, but I don't see how it could be done. I'm sure I'm missing 
>> something - perhaps give me more specifics and I'm happy to dig further.
>>
>> Thanks,
>> Mason
>>
>>
>> On Tue, Dec 7, 2021 at 8:04 AM Camille Lamy  
>> wrote:
>>
>>> Hi Mason, 
>>>
>>> We reviewed this intent in the S review today, and we were not 
>>> quite clear on the scope of the change. In particular, is it possible 
>>> for 
>>> cross-origin documents to share the adoptedStyelSheets? If so, can a 
>>> style 
>>> sheet used across cross-origin documents be modified and the 
>>> modifications 
>>> apply cross-origin as well? If so, this would be a security and privacy 
>>> concern.
>>>
>>> Thanks!
>>> Camille
>>>
>>> On Wednesday, December 1, 2021 at 7:09:08 PM UTC+1 Mason Freed wrote:
>>>
 On Tue, Nov 30, 2021 at 8:40 AM Mason Freed  
 wrote:

> Was ObservableArray and its use in the web platform reviewed by 
>> the TAG? If not then I think it should be, as there are plans to use 
>> it in 
>> more places than just this. 
>>
>
> No, it wasn't. This is a good suggestion - I'll open a TAG review 
> for ObservableArray and this conversion of adoptedStyleSheets. There 
> definitely are plans to expand its use on the platform. 
>

 TAG review filed 
 . 

  

>  
>
>>
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> Chromium is the only shipped implementation of 
>>> adoptedStyleSheets. Gecko would like to ship this feature, but has 
>>> been 
>>> waiting for the resolution of this issue (FrozenArray vs. 
>>> ObservableArray) 
>>> to ship their implementation. This should unblock Gecko [1]. The 
>>> Edge team 
>>> supports this change [2]. WebKit continues to be skeptical [3] of 
>>> this 
>>> usefulness of this feature, despite the general agreement of the 
>>> rest of 
>>> the web components community [4], and the support of the developer 
>>> community [5][6][7]. So the interop risk is mainly that WebKit 
>>> decides not 
>>> to implement this feature. Compat risks (from the change from 
>>> FrozenArray 
>>> to ObservableArray) should be minimal, as the same re-assignment 
>>> semantics 
>>> will continue to work. As documentation improves, and usage 
>>> expands, we 
>>> expect re-assignment usage to wane, and mutation (e.g. 
>>> adoptedStyleSheets.push()) to expand. [1] 
>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-834749590
>>>  
>>> [2] 
>>> 

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

['Joe Medley' via blink-dev]

Is this in 98?

On Wednesday, December 15, 2021 at 12:40:26 PM UTC-8 rby...@chromium.org 
wrote:

> Thank you! 
> +1 to it sounding like this will be fine. LGTM4
>
> Of course we'll need to keep an eye out for regressions being filed during 
> dev/beta but we should be able to rely on any such bug getting routed 
> quickly to you Sonia as a result of bisecting. Don't hesitate to reach out 
> to any of us if you get a report of a regression and are unsure what to do 
> about it!
>
> Rick
>
> On Wed, Dec 15, 2021 at 10:19 AM Mike West  wrote:
>
>> LGTM3.
>>
>> -mike
>>
>>
>> On Wed, Dec 15, 2021 at 3:30 PM Mike Taylor  wrote:
>>
>>> Awesome - appreciate the extra due diligence here. 
>>>
>>> LGTM2
>>>
>>> On 12/15/21 9:18 AM, Yoav Weiss wrote:
>>>
>>> *LGTM1* 
>>>
>>> Thanks for doing the work of verifying this is not a breaking change!
>>>
>>> On Wed, Dec 15, 2021 at 3:17 PM Yoav Weiss  wrote:
>>>
 The public equivalent is 
 https://docs.google.com/spreadsheets/d/1WZTRBujaaFrtUaRnBOoVYzJkZuColXFN-GgToF6nR5Q/edit#gid=73457229

 On Wed, Dec 15, 2021 at 2:46 PM Mike Taylor  
 wrote:

> Hi Sonia,
>
> Could you please make this spreadsheet public?
>
> thanks,
> Mike
>
> On 12/15/21 7:38 AM, Sonia Singla wrote:
>
> Link to spreadsheet[0]
>
>
> [0] 
> https://docs.google.com/spreadsheets/d/1lChXA87u2r7yuBdfJu283UDsGhRGqT9ol2rVwVOQw0o/edit?resourcekey=0-yCKFjRfFk0RYeNm-d6DvFw#gid=1758573992
>
> On Wednesday, December 15, 2021 at 2:37:19 PM UTC+2 Sonia Singla wrote:
>
>> Hi Everyone,
>>
>> So I tested some pages on mac and did not find any visual changes or 
>> anything is breaking for the links I tested. I updated the sheet[0]. 
>> Once 
>> we get the approvals to remove the property, I will be working on patches
>>
>> Sonia
>> CE Intern
>> Igalia
>>
>>
>> On Thursday, December 9, 2021 at 2:44:01 PM UTC+2 fw...@igalia.com 
>> wrote:
>>
>>> Sorry for the delay to come back to you. I had started to check a 
>>> few pages provided by Yoav manually and it seems similar pattern shows 
>>> up: 
>>> the counter is hit when the page specifies "font-family: 
>>> -webkit-standard;" 
>>> or (more rarely) "font-family: -webkit-standard, serif;" on some 
>>> elements 
>>> (*). This is similar to what Mike found on github and the same remarks 
>>> apply, in particular:
>>>
>>> - that may theorically change the rendering, but more investigation 
>>> is needed to be sure.
>>> - -webkit-standard would internally be used as a fallback anyway so 
>>> there is no risk of missing glyphs if we ignore user-specified one.
>>>
>>> I discussed with Sonia Singla (coding experience student at Igalia) 
>>> and she was interested in double-checking a few pages visually on macOS 
>>> (since that's where the main concern is) to see if anything is broken, 
>>> as 
>>> well as finishing the work of landing this patch. We will comment 
>>> further 
>>> when this is done.
>>>
>>> (*) For completeness, see the attached output of the following bash 
>>> command:
>>>
>>> for url in `cat $TEXT_FILE_WITH_THE_LIST_OF_URLS`; do
>>> echo $url
>>> $CONTENT_SHELL --run-web-tests $url 2>&1 | grep 
>>> FamilyNameFromSettings | sed 's/.*FontSelector::FamilyNameFromSettings 
>>> /  /'
>>> echo
>>> done
>>>
>>> with the following patch logging the font-family when the counter is 
>>> hit:
>>>
>>> --- a/third_party/blink/renderer/platform/fonts/font_selector.cc
>>> +++ b/third_party/blink/renderer/platform/fonts/font_selector.cc
>>> @@ -49,6 +49,7 @@ AtomicString FontSelector::FamilyNameFromSettings(
>>>  UseCounter::Count(
>>>  use_counter,
>>>  WebFeature::kFontSelectorCSSFontFamilyWebKitPrefixStandard);
>>> +LOG(INFO) << "FontSelector::FamilyNameFromSettings " << 
>>> font_description.Family().ToString().Utf8().data();
>>>}
>>>
>>>
>>> Le 08/12/2021 à 17:56, Mike West a écrit :
>>>
>>> Friendly-pinging Mike's ping of Rick's suggestion. Is that analysis 
>>> something you can spend some time on before we ship this? 
>>>
>>> -mike
>>>
>>>
>>>
>
>>>

-- 
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/4daca7e9-44ea-4113-aa2a-3e90d480fd91n%40chromium.org.

Re: [blink-dev] Intent to Ship: AudioContext.outputLatency

['Joe Medley' via blink-dev]

Is this shipping in 98?

On Wednesday, December 15, 2021 at 9:02:09 AM UTC-8 hongchan wrote:

> Thank you all!
>
> 1. I'll land the metrics CL and follow up here.
> 2. The discussion in the WebKit mailing list is ongoing, so I'll report 
> back when it's done.
>
> Cheers,
> Hongchan
>
>
> On Wed, Dec 15, 2021 at 8:58 AM Chris Harrelson  
> wrote:
>
>> LGTM3.
>>
>> On Wed, Dec 15, 2021 at 8:47 AM Mike Taylor  wrote:
>>
>>> LGTM2 w/ same condition.
>>>
>>> On 12/15/21 11:47 AM, Yoav Weiss wrote:
>>>
>>> LGTM1 conditional on those metrics landing (but no need to wait for data 
>>> from the metrics to come in).
>>>
>>> On Monday, December 6, 2021 at 3:22:26 PM UTC+1 Mike Taylor wrote:
>>>
 To circle back - last week we (myself + some other privacy/anti-covert 
 tracking reviewers) met with some folks working on this feature. We ended 
 up with an AI for Hongchan to land metrics on the values that 
 getOutputTimestamp would produce (if called, when a new AudioContext is 
 created, IIRC) as a way to get some data on the utility for using either 
 of 
 these APIs for device fingerprinting.

 On 12/1/21 11:27 AM, Hongchan Choi wrote:

 So far we have not discussed the deprecation plan, but I believe that's 
 reasonable as well. 

 I registered myself to the webkit-dev list to post a question, but 
 somehow I am getting 403 forbidden. The email is sent to the list, I am 
 not 
 seeing the message is getting posted on the list. Not sure what to do 
 there.

 On Wed, Dec 1, 2021 at 3:18 AM Yoav Weiss  wrote:

> So are y'all planning to deprecate and remove `getOutputTimestamp` 
> once this ships? If so, that sounds reasonable. 
>
> I note Chris asked y'all to file for a webkit signal upthread. Did 
> that happen?
>
> On Tuesday, November 30, 2021 at 12:54:17 AM UTC+1 hongchan wrote:
>
>> I agree that outputLatency is better in terms of both usability and 
>> interoperability. 
>>
>> FYI, the counter shows getOutputTimestamp is about 0.001% and there 
>> are no partners who are using this API:
>>
>> https://chromestatus.com/metrics/feature/popularity#AudioContextGetOutputTimestamp
>>
>>
>> On Mon, Nov 22, 2021 at 3:00 PM Chris Cunningham <
>> chcunn...@google.com> wrote:
>>
>>> Re: privacy discussion, Hongchan and I scheduled to meet with Paul 
>>> Jensen next week. 
>>>
>>> Also, I recently determined that this new WebAudio API 
>>> (outputLatency) is largely redundant with an existing API 
>>> (getOutputTimestamp()). 
>>> https://github.com/WebAudio/web-audio-api/issues/2461
>>>
>>> Chrome has already shipped the latter API, so I believe this new API 
>>> doesn't add potential for additional fingerprinting. Shipping both APIs 
>>> is 
>>> still a good idea for the sake of inter-op.
>>>
>>> On Friday, November 19, 2021 at 8:45:28 AM UTC-8 hongchan wrote:
>>>
 Thanks for the clarification, Yoav! 

 I hope the mitigation approach in the previous comment makes sense 
 from the privacy perspective, but it will hurt the usability/value of 
 this 
 API significantly.
 For the privacy-focused discussion, should I use other venues 
 rather than this I2S thread?

 Cheers,
 Hongchan


 On Thu, Nov 18, 2021 at 10:35 PM Yoav Weiss  
 wrote:

> Apologies, I misread the discussion. A spec issue is indeed not 
> needed, as this is already covered. 
>
> From my perspective, since this exposes active entropy, the fact 
> that it exposes more data than the (passively exposed) platform is 
> not 
> prohibitive on its own.
> At the same time, it'd be good to work with privacy-focused folks 
> to make sure we expose as little information as needed to maintain 
> the 
> API's functionality, but not more.
>
> On Fri, Nov 19, 2021 at 4:57 AM Chris Cunningham <
> chcunn...@chromium.org> wrote:
>
>> > If the reported value is incorrect, the A/V synchronization 
>> won't be possible. (Perhaps chcunningham@ can say more about this 
>> use 
>> case.) 
>>
>> The typical video player design drives the clock with audio. In 
>> short, you send buffers of audio to the OS, use the latency value to 
>> know 
>> when those buffers actually reach the user's ears, and choose a 
>> video frame 
>> accordingly. Apps using WebCodecs will design apps this way (example 
>> here 
>> 
>> ).
>>
>> As Mike notes, the latency value can vary by quite a lot 
>> depending on the device (huge differences for 

Re: [blink-dev] Intent to Ship: Unprefixed text-emphasis properties

['Joe Medley' via blink-dev]

Kent,

In which version are you hoping to ship this?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Dec 16, 2021 at 9:01 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 16/12/2021 15:49, TAMURA, Kent wrote:
> > I think so.  If the current implementation has interoperability issues,
> > we should fix them before shipping the unprefixed properties.
>
> LGTM3, if we fix the potential interop issues before shipping.
>
> Cheers,
>   Rego
>
> --
> 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/e99a1321-256c-c59f-67e7-b8b3948e262a%40igalia.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/CAJUhtG_f2NG8f-xqaKXi-p-CrPcXWF8RPHusF2QRVCW5xxD3Kg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HTMLInputElement showPicker()

['Joe Medley' via blink-dev]

You already answered that in the intent. I'm blind.

On Monday, December 13, 2021 at 10:54:32 AM UTC-8 Joe Medley wrote:

> When are you hoping to ship this?
> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Dec 13, 2021 at 12:58 AM 'François Beaufort ' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Contact emails
>>
>> fbea...@google.com
>>
>> Explainer
>>
>> https://github.com/whatwg/html/pull/7319
>>
>> Specification
>>
>> https://html.spec.whatwg.org/multipage/input.html#dom-input-showpicker
>>
>> Summary
>>
>> The HTMLInputElement showPicker() method allows web developers to 
>> programmatically show a browser picker for input elements (temporal, color, 
>> file, and those with suggestions like datalist or autofill).
>>
>> Blink component
>>
>> Blink>Forms 
>> 
>>
>> Motivation
>>
>> Developers have been asking for years for a way to programmatically open 
>> a browser date picker. See 
>> https://www.google.com/search?q=programmatically+open+date+picker+site:stackoverflow.com
>>  
>> 
>>
>> Because of that, they had to rely on custom widget libraries and CSS 
>> hacks for specific browsers.
>>
>> This is currently possible in some browsers, for some controls, via the 
>> click() method. However this is not interoperable (
>> https://github.com/whatwg/html/issues/6909#issuecomment-897097048) and 
>> considered a bad idea (
>> https://github.com/whatwg/html/issues/3232#issuecomment-345279014). 
>> Providing showPicker() gives developers a supported alternative to click(), 
>> and will allow us to align Chromium's click() behavior with the 
>> specification and other browsers in a future Intent to Ship.
>>
>> Initial public proposal
>>
>> https://github.com/whatwg/html/issues/6909
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/688
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> For interoperability: This feature was developed in collaboration with 
>> Gecko engineers, who are positive. It also will help with improving click() 
>> interoperability in the future, which is currently messy (
>> https://github.com/whatwg/html/issues/6909#issuecomment-897097048).
>>
>> For compatibility: this feature is specified and designed to give 
>> browsers flexibility in whether they display a picker, or how they display 
>> it. Developers cannot observe either of these things (except for file 
>> pickers, which fire certain events), so we will not be constrained by any 
>> JavaScript-observable behavior if we need to make future changes to form 
>> control UIs.
>>
>> Gecko: Positive - 
>> https://github.com/whatwg/html/pull/7319#issuecomment-988837778
>>
>> WebKit: No signal - 
>> https://lists.webkit.org/pipermail/webkit-dev/2021-December/032071.html
>>
>> Web developers: Positive - 
>> https://twitter.com/quicksave2k/status/1420320560345661440 (6 Retweets 
>> and 29 Likes) - https://github.com/whatwg/html/issues/6909 (9   and 5 
>> ❤️) show that developers like this particular solution. Plus the evidence 
>> of developer interest in the use case, per the Motivation section above.
>>
>>
>> Debuggability
>>
>> No specific DevTools changes are required. This feature is treated like 
>> any other JS method.
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> No. We are able to test the error case behaviors but the actual showing 
>> of the picker is not testable using WPT.
>>
>>
>> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/forms/the-input-element
>>
>>
>> Flag name
>>
>> chrome://flags/#enable-experimental-web-platform-features
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=939561
>>
>> Estimated milestones
>>
>> M99
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://www.chromestatus.com/feature/5692248021794816
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fEebe5uXQ1I
>>
>> -- 
>> 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+...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5Lh3nwAzZs4P1eHdg80dViZomPc%2BY0HpQ9HYpxgUSgnQA%40mail.gmail.com
>>  
>> 

Re: [blink-dev] [ACTION REQUESTED] What's in Chrome 98

['Joe Medley' via blink-dev]

Got it marked. Thanks for the update.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Dec 13, 2021 at 9:47 AM Anupam Snigdha 
wrote:

> Add support for Promise to Blobs in clipboard item: Landed in 98. It
> missed 97 so we decided to ship it in 98. Sorry for not updating the Chrome
> status entry
> https://chromestatus.com/feature/5733949474078720
>
> On Mon, Dec 13, 2021 at 6:55 AM 'Joe Medley' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Got it. Thanks!
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Fri, Dec 10, 2021 at 1:17 AM Harald Alvestrand  wrote:
>>
>>> The removal of SDES, originally landed in M97 beta but rolled back, is
>>> landed in M98 (unless I missed the cut; CL landed yesterday).
>>>
>>> https://chromestatus.com/features/5695324321480704
>>>
>>>
>>> On Thu, Dec 9, 2021 at 3:29 PM 'Joe Medley' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Gang,
>>>>
>>>> Chrome 98 is planned for beta on January 6. Developer Relations needs
>>>> information to help us plan. We want a complete list of everything in
>>>> Chrome beta for the beta post
>>>> <https://blog.chromium.org/search/label/beta>. We try when possible to
>>>> have articles for important new features on web.dev
>>>> <https://web.dev/blog/>.
>>>>
>>>> Please let me know of anything that might be shipping in Chrome 98 or 99.
>>>> I don't care if it's a new API, a bug to add a missing interface member, a
>>>> spec change or whatever. I need to know all of it. If you have any
>>>> questions about this, just ask, or refer to the FAQ in my communication
>>>> instructions
>>>> <https://sites.google.com/a/chromium.org/dev/blink/launching-features/let-developers-know>
>>>> .
>>>>
>>>> Also, please make sure your Chrome Status entries reflect the
>>>> current state of your feature. Origin trial and shipping milestone numbers
>>>> may be edited by clicking the "Edit all fields" link and scrolling down the
>>>> page.
>>>>
>>>> The list of what I currently believe to be shipping is in this
>>>> spreadsheet
>>>> <https://docs.google.com/spreadsheets/d/155euqrhdqVhtbAID7ydaUPjBstLIYZ4PJkpFmqJ6j-o/edit#gid=215381875>.
>>>> For those who can't reach it, here's a summary.
>>>>
>>>> (Deprecations and removals are in red.)
>>>>
>>>> auto keyword for contain-intrinsic-size
>>>> <https://chromestatus.com/feature/6740477866934272> LGTMs to Ship
>>>> Barcode Detection API
>>>> <https://chromestatus.com/feature/4757990523535360> LGTMs to Ship
>>>> (Calling PaymentRequest.show without user activation)
>>>> <https://chromestatus.com/feature/5948593429020672> I2S
>>>> COLRv1 Color Gradient Vector Fonts
>>>> <https://chromestatus.com/feature/5638148514119680> LGTMs to Ship
>>>> Convert adoptedStyleSheets to use ObservableArray
>>>> <https://chromestatus.com/feature/5638996492288000> I2S
>>>> CSS Color Adjust: 'only' keyword for color-scheme
>>>> <https://chromestatus.com/feature/5157621012103168> Merged, No LGTM
>>>> Declarative Link Capturing for PWAs
>>>> <https://chromestatus.com/feature/5734953453092864> Prior OT Done
>>>> FileSystemHandle::Remove() method
>>>> <https://www.chromestatus.com/feature/6318478849998848> Milestone on
>>>> Chrome Status
>>>> Handwriting Recognition API
>>>> <https://chromestatus.com/feature/5263213807534080> Prior OT Done
>>>> High Dynamic Range Support for HTMLCanvasElement
>>>> <https://www.chromestatus.com/feature/5703719636172800> I2E
>>>> New Canvas 2D API
>>>> <https://www.chromestatus.com/feature/6051647656558592> LGTMs to Ship
>>>> New window.open() popup vs. window behavior
>>>> <https://www.chromestatus.com/feature/5663031909416960> LGTMs to Ship
>>>> Pickling for Async Clipboard API
>>>> <https://www.chromestatus.com/feature/5649558757441536> I2S
>>>> Presentation API: Site-initiated mirroring
>>>> <https://chromestatus.com/fe

Re: [blink-dev] [ACTION REQUESTED] What's in Chrome 98

['Joe Medley' via blink-dev]

Got it. Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Dec 10, 2021 at 1:17 AM Harald Alvestrand  wrote:

> The removal of SDES, originally landed in M97 beta but rolled back, is
> landed in M98 (unless I missed the cut; CL landed yesterday).
>
> https://chromestatus.com/features/5695324321480704
>
>
> On Thu, Dec 9, 2021 at 3:29 PM 'Joe Medley' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Gang,
>>
>> Chrome 98 is planned for beta on January 6. Developer Relations needs
>> information to help us plan. We want a complete list of everything in
>> Chrome beta for the beta post
>> <https://blog.chromium.org/search/label/beta>. We try when possible to
>> have articles for important new features on web.dev
>> <https://web.dev/blog/>.
>>
>> Please let me know of anything that might be shipping in Chrome 98 or 99.
>> I don't care if it's a new API, a bug to add a missing interface member, a
>> spec change or whatever. I need to know all of it. If you have any
>> questions about this, just ask, or refer to the FAQ in my communication
>> instructions
>> <https://sites.google.com/a/chromium.org/dev/blink/launching-features/let-developers-know>
>> .
>>
>> Also, please make sure your Chrome Status entries reflect the
>> current state of your feature. Origin trial and shipping milestone numbers
>> may be edited by clicking the "Edit all fields" link and scrolling down the
>> page.
>>
>> The list of what I currently believe to be shipping is in this
>> spreadsheet
>> <https://docs.google.com/spreadsheets/d/155euqrhdqVhtbAID7ydaUPjBstLIYZ4PJkpFmqJ6j-o/edit#gid=215381875>.
>> For those who can't reach it, here's a summary.
>>
>> (Deprecations and removals are in red.)
>>
>> auto keyword for contain-intrinsic-size
>> <https://chromestatus.com/feature/6740477866934272> LGTMs to Ship
>> Barcode Detection API <https://chromestatus.com/feature/4757990523535360> 
>> LGTMs
>> to Ship
>> (Calling PaymentRequest.show without user activation)
>> <https://chromestatus.com/feature/5948593429020672> I2S
>> COLRv1 Color Gradient Vector Fonts
>> <https://chromestatus.com/feature/5638148514119680> LGTMs to Ship
>> Convert adoptedStyleSheets to use ObservableArray
>> <https://chromestatus.com/feature/5638996492288000> I2S
>> CSS Color Adjust: 'only' keyword for color-scheme
>> <https://chromestatus.com/feature/5157621012103168> Merged, No LGTM
>> Declarative Link Capturing for PWAs
>> <https://chromestatus.com/feature/5734953453092864> Prior OT Done
>> FileSystemHandle::Remove() method
>> <https://www.chromestatus.com/feature/6318478849998848> Milestone on
>> Chrome Status
>> Handwriting Recognition API
>> <https://chromestatus.com/feature/5263213807534080> Prior OT Done
>> High Dynamic Range Support for HTMLCanvasElement
>> <https://www.chromestatus.com/feature/5703719636172800> I2E
>> New Canvas 2D API <https://www.chromestatus.com/feature/6051647656558592> 
>> LGTMs
>> to Ship
>> New window.open() popup vs. window behavior
>> <https://www.chromestatus.com/feature/5663031909416960> LGTMs to Ship
>> Pickling for Async Clipboard API
>> <https://www.chromestatus.com/feature/5649558757441536> I2S
>> Presentation API: Site-initiated mirroring
>> <https://chromestatus.com/feature/5648093276012544> I2E
>> Private Network Access preflight requests for subresources
>> <https://chromestatus.com/feature/5737414355058688> LGTMs to Ship
>> Progressive Web Apps as URL Handlers
>> <https://www.chromestatus.com/feature/5739732661174272> Prior OT Done
>> Propagate request origin and redirect chain in passthrough service
>> workers. <https://chromestatus.com/feature/5752539724120064> LGTMs to
>> Ship
>> Region Capture <https://www.chromestatus.com/feature/5712447794053120> 
>> Milestone
>> on Chrome Status
>> Sec-CH-UA-Full-Version-List user-agent client hint
>> <https://chromestatus.com/feature/5703317813460992> LGTMs to Ship
>> self.structuredClone <https://chromestatus.com/feature/5630001077551104> 
>> LGTMs
>> to Ship
>> Service Worker subresource filter
>> <https://www.chromestatus.com/feature/6015753541124096> Prior OT Done
>> Speculation Rules <https://chromestatus.com/feature/5740655424831488> Prior
>> OT Done
>> WebAuthn minPinLength extension
>> <https://

Re: [blink-dev] [ACTION REQUESTED] What's in Chrome 98

['Joe Medley' via blink-dev]

Awesome, thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Dec 9, 2021 at 8:12 AM Christian Biesinger 
wrote:

> auto keyword for contain-intrinsic-size is indeed shipping in 98; I've
> updated chromestatus accordingly.
>
> Christian
>

-- 
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/CAJUhtG_xqq86gJrxvBXMCiMYKODNQ2QgDBNLThhHQR%2BOvtnFHw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

['Joe Medley' via blink-dev]

I assume this is actually shipping in 98, right?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Dec 9, 2021 at 1:21 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Thu, Dec 9, 2021 at 8:29 AM Daniel Bratell  wrote:
>
>> LGTM2, same limitation.
>>
>> /Daniel
>> On 2021-12-09 07:51, Yoav Weiss wrote:
>>
>> LGTM1 to ship `dynamic-range` without the video prefixed variant.
>>
>> On Thu, Dec 9, 2021 at 4:42 AM Will Cassella  wrote:
>>
>>> Sorry for the delay! I'm currently working on that, it'll most likely be
>>> up some time tomorrow. That only covers the video-* media features,
>>> given that Safari has already shipped the regular (non-prefixed)
>>> dynamic-range media feature, should we go ahead with shipping that and
>>> follow up with video-dynamic-range after TAG review in a separate I2S?
>>>
>>> On Wed, Dec 8, 2021 at 8:34 AM Mike West  wrote:
>>>
 Friendly ping on Yoav's suggestion. Did y'all file a TAG review
 request?

 -mike


 On Wed, Dec 1, 2021 at 11:47 AM Yoav Weiss 
 wrote:

> Since we're talking about adding a full new class of MQs, that seems
> worthy of a TAG discussion.
>
> On Tuesday, November 30, 2021 at 1:38:13 AM UTC+1 Will Cassella wrote:
>
>> Sorry for missing that! There's a section in the spec for 'video-*'
>> MQ's
>> ,
>> and while this is the first to be implemented in Chrome there are others
>> detailed there (most notably video-color-gamut). The 'video-*' MQ
>> concept has not been discussed with TAG, but it was discussed at great
>> length between the media and CSS WGs. You can see the start of that
>> discussion in the media WG here
>> , and its jump
>> to the CSS WG here .
>> In both places we had representation from different user agents and 
>> domain
>> experts.
>>
>> On Thu, Nov 25, 2021 at 12:51 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks for the update!
>>>
>>> Repeating my question from above, that probably got lost along the
>>> way: Was the concept of `video-*` MQs discussed with the TAG? Are there
>>> other `video-*` MQs that are already shipped?
>>>
>>> On Wed, Nov 24, 2021 at 9:33 PM Will Cassella 
>>> wrote:
>>>
 There's been movement on the Github issue
 
  regarding
 the spec, and the consensus is that the way Safari has done things 
 (having dynamic-range:
 standard always return true, and dynamic-range: high be evaluated
 against the capabilities of the display) is what we should be doing, 
 and
 the wording of the spec should be adjusted as well. I've updated our
 implementation to reflect that.

 On Thu, Nov 18, 2021 at 12:04 PM Chris Harrelson <
 chris...@chromium.org> wrote:

> Ok thanks. It looks like the CSSWG discussed the issue and there
> still needs to be more discussion before a resolution is achieved, so 
> we'll
> wait for that.
>
> On Fri, Nov 5, 2021 at 3:45 PM Will Cassella 
> wrote:
>
>> Hey Chris,
>> I’ve filed an issue on the csswg-drafts repo
>>  asking for the
>> wording to be adjusted in the spec. In the original discussion 
>> surrounding
>> this media query, the intent was for this to be reflective of the 
>> display
>> device and not an overall representation of the user agent's 
>> capabilities.
>> I did some research into Safari's implementation
>> 
>> of this query, and while they similarly implement dynamic-range:
>> high with respect to the display device, their treatment of 
>> dynamic-range:
>> standard isn't in line with the spec (it always returns true,
>> even on HDR displays). After some discussion with +chcunningham, we 
>> think
>> this may be the correct path forward for Chrome as well as sites are
>> already using this query on Safari, and it makes sense from a 
>> backwards
>> compatibility standpoint (how should dynamic-range: high react
>> if an ultra-high enum is ever added?). I'm still waiting to get
>> feedback on the Github issue I filed at the moment.
>> Thanks,
>> Will
>> On Thu, Nov 4, 2021 at 12:30 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>

[blink-dev] [ACTION REQUESTED] What's in Chrome 98

['Joe Medley' via blink-dev]

Gang,

Chrome 98 is planned for beta on January 6. Developer Relations needs
information to help us plan. We want a complete list of everything in
Chrome beta
for the beta post . We try
when possible to have articles for important new features on web.dev
.

Please let me know of anything that might be shipping in Chrome 98 or 99. I
don't care if it's a new API, a bug to add a missing interface member, a
spec change or whatever. I need to know all of it. If you have any
questions about this, just ask, or refer to the FAQ in my communication
instructions

.

Also, please make sure your Chrome Status entries reflect the current state
of your feature. Origin trial and shipping milestone numbers may be edited
by clicking the "Edit all fields" link and scrolling down the page.

The list of what I currently believe to be shipping is in this spreadsheet
.
For those who can't reach it, here's a summary.

(Deprecations and removals are in red.)

auto keyword for contain-intrinsic-size
 LGTMs to Ship
Barcode Detection API  LGTMs
to Ship
(Calling PaymentRequest.show without user activation)
 I2S
COLRv1 Color Gradient Vector Fonts
 LGTMs to Ship
Convert adoptedStyleSheets to use ObservableArray
 I2S
CSS Color Adjust: 'only' keyword for color-scheme
 Merged, No LGTM
Declarative Link Capturing for PWAs
 Prior OT Done
FileSystemHandle::Remove() method
 Milestone on Chrome
Status
Handwriting Recognition API
 Prior OT Done
High Dynamic Range Support for HTMLCanvasElement
 I2E
New Canvas 2D API  LGTMs
to Ship
New window.open() popup vs. window behavior
 LGTMs to Ship
Pickling for Async Clipboard API
 I2S
Presentation API: Site-initiated mirroring
 I2E
Private Network Access preflight requests for subresources
 LGTMs to Ship
Progressive Web Apps as URL Handlers
 Prior OT Done
Propagate request origin and redirect chain in passthrough service workers.
 LGTMs to Ship
Region Capture 
Milestone
on Chrome Status
Sec-CH-UA-Full-Version-List user-agent client hint
 LGTMs to Ship
self.structuredClone  LGTMs
to Ship
Service Worker subresource filter
 Prior OT Done
Speculation Rules  Prior
OT Done
WebAuthn minPinLength extension
 LGTMs to Ship
WritableStream controller AbortSignal
 LGTMs to Ship
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*

-- 
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/CAJUhtG_vCD9rhqLv6Vqn-UBm%2BPKE996pDY_L6XLijRAyCziRmw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Joe Medley' via blink-dev]

Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available.
'Shipping' refers to when it can be used in production without web
developers or users doing anything. This can mean the flag was removed or
it can mean the flag's default was changed to 'Enabled'.

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Nov 29, 2021 at 7:37 AM 'Titouan Rigoudy' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org
>
> Explainer
> https://github.com/WICG/private-network-access/blob/main/explainer.md
>
> Specificationhttps://wicg.github.io/private-network-access/
>
> Design docs
>
> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit
>
> Summary
>
> Sends a CORS preflight request ahead of any private network requests for
> subresources, asking for explicit permission from the target server. A
> private network request is any request from a public website to a private
> IP address or localhost, or from a private website (e.g. intranet) to
> localhost. Sending a preflight request mitigates the risk of cross-site
> request forgery attacks against private network devices such as routers,
> which are often not prepared to defend against this threat.
>
>
> Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The main interoperability risk, as always, is if other browser engines do
> not implement this. Compat risk is straightforward: web servers that do not
> handle the new preflight requests will eventually break, once the feature
> ships. The plan to address this is as follows: 1. Send preflight request,
> ignore result, always send actual request. Failed preflight requests will
> result in a warning being shown in devtools. 2. Wait for 3 milestones. 3.
> Gate actual request on preflight request success, with deprecation trial
> for developers to buy some more time. 4. End deprecation trial 4 milestones
> later. UseCounters:
> https://chromestatus.com/metrics/feature/timeline/popularity/3753
> https://chromestatus.com/metrics/feature/timeline/popularity/3755
> https://chromestatus.com/metrics/feature/timeline/popularity/3757 The
> above measure pages that make at least one private network request for
> which we would now send a preflight request.
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/143)
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html)
> Pending response.
>
> Web developers: No signals Anecdotal evidence so far suggests that most
> web developers are OK with this new requirement, though some do not control
> the target endpoints and would be negatively impacted.
>
> Other signals:
>
> Ergonomics
>
> None.
>
>
> Activation
>
> Gating access to the private network overnight on preflight requests would
> likely result in widespread breakage. This is why the plan is to first send
> requests but not act on their result, giving server developers time to
> implement code handling these requests. Deprecation warnings will be
> surfaced in DevTools to alert web/client developers when the potential for
> breakage later on is detected. Enforcement will be turned on later (aiming
> for 3 milestones), along with a deprecation trial for impacted web
> developers to buy themselves some more time. Experience suggests a large
> fraction of developers will not notice the advance deprecation warnings
> until things break.
>
>
> Security
>
> This change aims to be security-positive, preventing CSRF attacks against
> soft and juicy targets such as router admin interfaces. DNS rebinding
> threats were of particular concern during the design of this feature:
> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9
>
>
> Debuggability
>
> Relevant information (client and resource IP address space) is already
> piped into the DevTools network panel. Deprecation warnings and errors will
> be surfaced in the DevTools issues panel explaining the problem when it
> arises.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> DevTrial instructions
> https://github.com/WICG/private-network-access/blob/main/HOWTO.md
>
> Flag namePrivateNetworkAccessRespectPreflightResults
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/591068
>
> Launch bughttps://crbug.com/1274149
>
> Estimated milestones
> DevTrial on desktop 98
> DevTrial on 

Re: [blink-dev] Re: Intent to Ship: Propagate request origin and redirect chain in passthrough service workers.

['Joe Medley' via blink-dev]

>Since the first part of the change is in M97 I updated the chromestatus
entry to indicate that as the release and added a note that the
redirect-chain change is coming in M98.

Is any of this feature usable in 97?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Nov 29, 2021 at 7:11 AM Ben Kelly  wrote:

> Thank you!
>
> FYI, I realized this morning I made one small mistake in my original
> post.  The origin propagation part of this intent is actually in M97 and
> the redirect chain part is in M98.  The CLs are large, so I don't really
> want to do a merge if I can avoid it.  Since the first part of the change
> is in M97 I updated the chromestatus entry to indicate that as the release
> and added a note that the redirect-chain change is coming in M98.  Sorry
> for the confusion here.
>
> Please let me know if there is any concern about this clarification.
> Thanks.
>
> On Thu, Nov 25, 2021 at 1:21 AM Mike West  wrote:
>
>> LGTM3.
>>
>> On Wed 24. Nov 2021 at 23:59 Rick Byers  wrote:
>>
>>> Makes sense, thanks! Arguably almost a bugfix level change. LGTM2
>>>
>>> On Wed, Nov 24, 2021 at 5:27 PM Ben Kelly 
>>> wrote:
>>>


 On Wed, Nov 24, 2021, 5:07 PM Rick Byers  wrote:

> Ben, can you speak to the web compat implications (or absence thereof)
> to this change in behavior?
>

 I believe the compat risk should be minimal.  This change only matters
 for navigation requests and many service workers will be using nav preload
 instead of calling fetch() themselves.

 For sites not using nav preload it's possible they will see changes in
 origin headers, sec-fetch-site headers, and SameSite=Strict cookies.
 Depending on server logic that could cause requests to be deemed unsafe by
 the server and fail.  However, it would match what is done without a
 service worker present.  Arguably the server wants to make this decision in
 these situations.

 If a site does not want this behavior it requires only a small service
 worker change to get previous behavior.  They just need to fetch the url
 and not the full request.  Like `fetch(evt.request.url)` instead of
 `fetch(evt.request)`.

  Nov 24, 2021 at 5:03 PM Chris Harrelson  wrote:
>
>> LGTM1
>>
>> On Wed, Nov 24, 2021 at 1:52 PM Ben Kelly 
>> wrote:
>>
>>> On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly 
>>> wrote:
>>>
 Interoperability and Compatibility



 Gecko: No signal

>>>
>>> I have not filed for formal signals, but we had a TPAC session
>>>  with mozilla
>>> where we reached consensus on these changes.
>>>
>>>
 WebKit: No signal

>>>
>>> Note, webkit already propagates the origin header.  They do not
>>> implement sec-fetch-site or SameSite cookies, so the redirect chain
>>> propagation is not observable or relevant.
>>>
>>> --
>>> 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/CAK7rkMjWDoVDeuNnYVuOOS4OjEKrRUkKSt9G9CwT13T_PPS6nQ%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/CAOMQ%2Bw9_ytnSVS4%2BciMFChuTsKEUOC0WJ_0c0-Q3Ue5eyXi8zQ%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/CAFUtAY8_ouG4MC9SkJ-gMDi7vSFYGfw5EvNEbquUcjoCuhLkGw%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> -mike
>>
> --
> You received this message because 

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

['Joe Medley' via blink-dev]

In which version is this shipping?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Nov 24, 2021 at 8:21 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Wed, Nov 24, 2021 at 6:18 AM Mike West  wrote:
>
>> LGTM2.
>>
>> Given that this has landed in both DOM and Streams with support from
>> Mozilla, and WebKit has tacitly expressed support via their implementation,
>> this is a pretty reasonable thing for us to follow along with. Thanks for
>> iterating with others in the ecosystem to land on something folks were
>> happy with!
>>
>> -mike
>>
>>
>> On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:
>>>
 On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
 wrote:

> Thanks for addressing the TAG's feedback!
>
>
> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>
>> Hi all,
>>
>> Another update: based on the feedback we received from TAG as
>> previously mentioned, we decided to remove the abortReason from
>> WritableStreamDefaultController which was initially proposed, and instead
>> add an "abort reason" property
>>  to
>> AbortSignal which was specced in
>> https://github.com/whatwg/dom/pull/1027. Related to this on the
>> interface side, the static AbortSignal.abort()
>>  as well as the
>> AbortController.abort()
>>  now take an
>> optional reason argument. Gecko and WebKit folks and some developers have
>> also expressed implementer's interest on the PR, and some have gone on to
>> update their browser implementation/polyfills already.
>>
>
> Any specifics? Does this mean other browsers are now also shipping
> AbortSignal for WritableStreams? Or did they just update their current
> AbortSignal implementation with an "abort reason"?
>

 Ah, sorry for the unclearness. I mean they (i.e. WebKit
 ,
 Deno
 ,
 and almost Node.js ) have
 updated their current AbortSignal implementation with an "abort reason". As
 far as I'm aware, the signals related to shipping AbortSignal for
 WritableStreams itself remain unchanged from earlier on in this thread.

>>>
>>> Makes sense, thanks for clarifying!
>>>
>>>

>
>
>>
>> This was also integrated into the Streams standard in
>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal
>> API is connected to various different standards, so there is also an
>> ongoing effort to update those affected specs as well here
>> .)
>>
>> I would like to resume the intent process based on these updates.
>> Please let me know if you have any questions or thoughts.
>>
>> Thank you!
>>
>> Best regards,
>> Nidhi
>>
>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
>> wrote:
>>
>>> After talking to Nidhi offline, we can consider this intent on hold
>>> until the feedback is addressed.
>>>
>>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>>
 Hi,

 Just as an update, we have received some feedback on our TAG review
 (
 https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
 and hence we are having some discussions and deciding on next best 
 steps
 accordingly.

 Best regards,
 Nidhi

 On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
 wrote:

>
>
> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
> wrote:
>
>> The Web Serial API is also interested in this capability. See the
>> note on the abort algorithm when initializing the WritableStream
>> .
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>> Chrome 
>>
>>
>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju <
>>> nidhij...@chromium.org> wrote:
>>>


 On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
 slightly...@chromium.org> wrote:

> Incremental features often benefit from TAG guidance. I'd feel
> better if this 

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

['Joe Medley' via blink-dev]

Hi,

In which version are you planning to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Oct 29, 2021 at 9:41 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Fri, Oct 29, 2021 at 12:18 AM Manuel Rego Casasnovas 
> wrote:
>
>> LGTM2
>>
>> On 29/10/2021 06:56, Yoav Weiss wrote:
>> > LGTM1
>> >
>> > On Thu, Oct 28, 2021 at 10:56 PM Andreu Botella
>> > mailto:and...@andreubotella.com>> wrote:
>> >
>> > I don't think the differences are listed anywhere. I know there are
>> > some because of the failures in
>> >
>> https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental=master
>> > <
>> https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental=master
>> >,
>> > but there might be others that aren't tested. Although it seems like
>> > some of the failures in the shared-array-buffer folder seem to be
>> > bugs with the tests rather than with the implementations.
>> >
>> >
>> > OK, as these differences are already exposed, I don't think shipping
>> > this significantly increases risk. The fact that they're covered by WPTs
>> > makes it more likely we'd (eventually) converge on the specified
>> behavior.
>> >
>> >
>> > On Wednesday, October 27, 2021 at 11:12:32 PM UTC+2
>> > fs...@chromium.org  wrote:
>> >
>> > This is amazing! :)
>> >
>> > I agree it shouldn't block this, but do we have anywhere written
>> > what are the browser's differences on structured clone
>> > algorithms? Is it a spec issue? Could we add WPT tests for it?
>> >
>> > On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella
>> >  wrote:
>> >
>> > *Contact emails*
>> > and...@andreubotella.com, jbr...@chromium.org,
>> > su...@chromium.org
>> >
>> > *Explainer*
>> > https://github.com/whatwg/html/issues/793
>> > 
>> >
>> > *Specification*
>> > https://html.spec.whatwg.org/#structured-cloning
>> > 
>> >
>> > *Summary*
>> > Enables using the HTML structured clone algorithm
>> > synchronously for cloning and transferring objects within a
>> > single realm.
>> >
>> > *Initial public proposal*
>> > https://github.com/whatwg/html/issues/793
>> > 
>> > https://github.com/whatwg/html/pull/3414
>> > 
>> >
>> > *Blink component*
>> > Blink>Messaging
>> > <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMessaging
>> >
>> >
>> >
>> > *TAG review*
>> > This is just exposing existing browser functionality, with a
>> > two-line spec. It doesn’t seem like there’s much to discuss
>> > architecturally, but I’ll file for review if the community
>> > thinks it would help.
>> >
>> > *TAG review status*
>> > Not applicable
>> >
>> > *Risks*
>> >
>> > *Interoperability and Compatibility*
>> > Low. There are some differences across the browsers’
>> > implementations of the structured cloning algorithm, but
>> > they are very minor and already present in other APIs that
>> > use it.
>> >
>> > Gecko: Shipped/Shipping
>> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1722576
>> > )
>> > Edge: No signal
>> > WebKit: Shipped/Shipping
>> > (https://bugs.webkit.org/show_bug.cgi?id=228331
>> > )
>> >
>> > Web developers: Positive
>> > (
>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942
>> > <
>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942>
>> > and following comments). There seems to be a lot of demand
>> > for a built-in deep clone, and while structured clone is not
>> > exactly that, it fulfills many of the use cases.
>> >
>> > *Debuggability*
>> > n/a
>> >
>> > *Is this feature fully tested by web-platform-tests
>> > <
>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
>> >?*
>> > Yes
>> > <
>> https://wpt.fyi/results/html/webappapis/structured-clone?label=experimental=master
>> >
>> >
>> >
>> > *Requires code in //chrome?*
>> > False
>> >
>> > *Tracking bug*
>> >
>> 

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

['Joe Medley' via blink-dev]

Hi,

Can I get some clarification?

So this extends the origin trial through 96, but you don't know yet whether
it will ship in 97? Is this correct?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
> wrote:
>
>> For a gapless origin trial->shipping it is important to be sure we don't
>> overlook any feedback in the race to shipping. The normal process has gaps
>> built in which form natural points to do that final polish based on
>> received feedback and that will be missing here.
>>
>> It does sound like the feedback has been positive though and that there
>> are no known problems that can't be fixed after shipping, and with that in
>> mind:
>>
>> LGTM2
>> On 2021-10-21 21:53, Yoav Weiss wrote:
>>
>> Discussing amongst the API owners (Alex, Daniel, Rego and myself), this
>> is essentially a request for a gapless OT, only that the would-be-gap is
>> slightly longer than usual. Given the evidence
>> 
>>  of
>> developer feedback presented in the I2S, that seems like a reasonable
>> request.
>>
>> LGTM1 (as gapless OT requests require 3 LGTMs)
>>
>> On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org,vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Design docs/spec
>>>
>>> Specification: https://w3c.github.io/webtransport/#web-transport
>>>
>>>
>>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/669
>>>
>>>
>>> Summary
>>>
>>> WebTransport is an interface representing a set of reliable/unreliable
>>> streams to a server. The interface potentially supports multiple protocols,
>>> but based on discussions on the IETF webtrans working group, we are
>>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>>> protocol.
>>>
>>> Note that we were developing QuicTransport a.k.a. WebTransport over QUIC
>>> and we ran an origin trial M84 through M90. It uses the same interface
>>> WebTransport, but because of the protocol difference ("quic-transport" vs.
>>> "https") it is difficult for web developers to be confused by them.
>>>
>>> new WebTransport("quic-transport://example.com:9922")
>>>
>>> represents a WebTransport over QUIC connection, and
>>>
>>> new WebTransport("https://example.com:9922;)
>>>
>>> represents a WebTransport over HTTP/3 connection.
>>>
>>> Goals for experimentation
>>>
>>> We're shipping the API in M97
>>> .
>>> Twitch, one of our partners, wants to continue their experiment until the
>>> API is fully shipped. I think this is a reasonable request given we
>>> originally aimed to ship the feature in M96 but we missed the branch point.
>>>
>>> The original goals follow:
>>>
>>> To see whether the API (and the implementation) is useful in various
>>> circumstances.
>>>
>>> Our partners want to evaluate this API on various network circumstances
>>> (i.e., lab environments are not enough) to see its effectiveness.
>>>
>>> We also expect feedback for performance.
>>>
>>> Experimental timeline
>>>
>>> M95 and M96
>>>
>>> Ongoing technical constraints
>>>
>>> None
>>>
>>> Debuggability
>>>
>>> The devtools support is under development.
>>>
>>> Just like with regular HTTP/3 traffic, the detailed information about
>>> the connection can be obtained via chrome://net-export interface.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux,
>>>
>>> Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No
>>>
>>> We have browser tests, but we are going to port them to WPT.
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://www.chromestatus.com/feature/4854144902889472
>>>
>>> --
>> 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/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe 

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

['Joe Medley' via blink-dev]

Hi,

In which version of Chrome do you expect to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 12:37 PM Alex Russell 
wrote:

> LGTM3.
>
> In future, if you assert a TAG review isn't necessary, please provide
> links to previous reviews that cover the same space.
>
> On Thursday, October 21, 2021 at 12:17:45 PM UTC-7 Manuel Rego wrote:
>
>> LGTM2
>>
>> On 21/10/2021 21:16, Daniel Bratell wrote:
>> > LGTM1
>> >
>> > /Daniel
>> >
>> > On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org
>> wrote:
>> >
>> > Correct, they’ll behave the same as the other non-legacy hints.
>> >
>> > On Fri, Oct 15, 2021 at 05:34 Yoav Weiss  wrote:
>> >
>> > Thanks for working on this, Ari!
>> >
>> > IIUC, this intent will add these new hint names, but would
>> > also ensure their behavior when it comes to 3P delegation would
>> > be different from the legacy hints (as they don't have the same
>> > legacy baggage). Is that correct?
>> >
>> >
>> > On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula
>> >  wrote:
>> >
>> > Contact emails
>> >
>> > ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>> >
>> >
>> > Design Doc
>> >
>> >
>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
>> > <
>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit>
>>
>> >
>> >
>> > Specification
>> >
>> > https://wicg.github.io/client-hints-infrastructure/
>> > 
>> >
>> > https://wicg.github.io/responsive-image-client-hints/
>> > 
>> >
>> > https://wicg.github.io/savedata/#save-data-request-header-field
>> > 
>> >
>> > https://wicg.github.io/netinfo/#networkinformation-interface
>> > 
>> >
>> >
>> > Summary
>> >
>> > This proposal seeks to align our implementation with the
>> > Client Hint proposal
>> > by
>> > adding the `sec-ch-` prefix where it’s missing.
>> >
>> >
>> > Blink component
>> >
>> > Privacy>Fingerprinting
>> > <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component%3APrivacy%3EFingerprinting>
>>
>> >
>> >
>> > Motivation
>> >
>> > Client Hints
>> > , a
>> > method to request information about the user's device or
>> > conditions, have been implemented in Chrome, but since the
>> > initial implementation the naming scheme has changed. If
>> > implemented, this proposal would add new client hints with a
>> > `sec-ch-` prefix to re-implement the following: `dpr`,
>> > `width`, `viewport-width`, and `device-memory`. The three
>> > network related client hints with legacy names, `rtt`,
>> > `downlink`, and `ect`, will not be updated as they may be
>> > replaced by different hints in an independent process.
>> >
>> >
>> > TAG review
>> >
>> > Not needed
>> >
>> >
>> > Risks
>> >
>> > Only Blink implements client hints and we are not (yet)
>> > removing any current ones, just re-implementing existing
>> > ones under the correct name. If usage permits, we will
>> > remove the legacy names in the future.
>> >
>> >
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> > Gecko: Client hints not implemented
>> >
>> > WebKit: Client hints not implemented
>> >
>> > Web developers: Positive interest from Cloudinary
>> > <
>> https://discourse.wicg.io/t/responsive-image-client-hints-call-for-review/5470>
>>
>> >
>> >
>> > Is this feature fully tested by web-platform-tests?
>> >
>> > Yes
>> > <
>> https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/web_tests/external/wpt/client-hints/>
>>
>> >
>> >
>> > Tracking bug
>> >
>> > https://crbug.com/1227043 
>> >
>> >
>> > Link to entry on the Chrome Platform Status
>> >
>> > https://www.chromestatus.com/feature/6658223894429696
>> > 
>> >
>> >
>> > --
>> > 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+...@chromium.org.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
>> > <
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com?utm_medium=email_source=footer>.
>>
>> >
>> > --
>> > ~ Ari Chivukula (Their/There/They’re)
>> >
>> > --
>> > 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: Independent/Individual Properties for CSS Transforms

['Joe Medley' via blink-dev]

Hi,

In which version of Chrome do you hope to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 12:03 PM Manuel Rego Casasnovas 
wrote:

> LGTM3.
>
> On 21/10/2021 19:53, Daniel Bratell wrote:
> > LGTM2.
> >
> > /Daniel
> >
> > On 2021-10-21 08:19, Yoav Weiss wrote:
> >> LGTM1
> >> Seems important to catch up here, so thanks for working on this!!
> >>
> >> On Mon, Oct 18, 2021 at 11:05 PM David Baron 
> wrote:
> >>
> >>
> >> Contact emails
> >>
> >>
> >> dba...@chromium.org, kev...@chromium.org,
> fla...@chromium.org
> >>
> >>
> >> Explainer
> >>
> >>
> >> None
> >>
> >>
> >> Specification
> >>
> >>
> >>
> https://drafts.csswg.org/css-transforms-2/#individual-transforms
> >>
> >>
> >> Summary
> >>
> >>
> >> This adds three new CSS properties: translate, rotate, and
> >> scale. This exposes a simple way for web developers to
> >> access transforms in an intuitive way, without having to
> >> think about how functions in the transform property
> >> interact with each other. The properties are individually
> >> animatable.
> >>
> >>
> >>
> >> Blink component
> >>
> >>
> >> Blink
> >> <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
> >>
> >>
> >> TAG review
> >>
> >>
> >> Already shipped in two browser engines.
> >>
> >>
> >> TAG review status
> >>
> >>
> >> Not applicable (I think)
> >>
> >>
> >> Risks
> >>
> >>
> >>
> >>
> >> Interoperability and Compatibility
> >>
> >>
> >>
> >>
> >> Gecko: Shipped/Shipping
> >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
> >> Shipped in Firefox 72, January 2020.
> >>
> >> WebKit: Shipped/Shipping
> >> (
> https://webkit.org/blog/11420/css-individual-transform-properties/)
> >> Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.
> >>
> >> Web developers: Positive: 25 stars
> >> on
> https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
> >> Notable early developer request for the feature (before WG
> >> adoption)
> >> in:
> https://twitter.com/rachelnabors/status/618266391993454592
> https://twitter.com/rachelnabors/status/618267483296825344 and
> >> early reaction to WG adoption
> >> in
> https://twitter.com/SaraSoueidan/status/613368671315054592 .
> >> Positive developer reactions
> >> to https://twitter.com/argyleink/status/1338907239990497280
>  .
> >> Largely positive reactions to news of other engines
> >> shipping the feature in responses
> >> to
> https://twitter.com/jensimmons/status/1387870244392382468 ,
> https://twitter.com/simevidas/status/627956718098485248 ,
> https://twitter.com/dancwilson/status/121457225783989862 ,
> >> and
> >> in
> https://twitter.com/guerriero_se/status/1338468028804001796 ,
> https://twitter.com/eladsc/status/1216286886697885696 ,
> https://twitter.com/_zouhir/status/1389461399026294791 .
> >> More recent developer interest
> >> in https://twitter.com/anatudor/status/1377491818636587008
>  , https://twitter.com/anatudor/status/1309200388311199751 .
> >>
> >>
> >> Debuggability
> >>
> >>
> >> Has the standard exposure in devtools that all CSS
> >> properties have.
> >>
> >>
> >>
> >> Is this feature fully tested by web-platform-tests
> >> <
> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
> >?
> >>
> >>
> >> Yes
> >>
> >>
> >> Flag name
> >>
> >>
> >> CSSIndependentTransformProperties
> >>
> >>
> >> Requires code in //chrome?
> >>
> >>
> >> False
> >>
> >>
> >> Tracking bug
> >>
> >>
> >>
> https://bugs.chromium.org/p/chromium/issues/detail?id=496550
> >>
> >>
> >> Estimated milestones
> >>
> >> The feature has been implemented behind a flag on
> >> desktop/android/WebView since Chrome 45 (not a typo).
> >>
> >> For an estimated milestone for shipping, I think the feature is
> >> close to being ready, so I'm still hoping for Chrome 97 but can't
> >> promise that it will be ready in time.  It's waiting on a single
> >> chain of dependencies, as described in the bug
> >> ,
> so
> >> that more than one of the transform properties on a single element
> >> can be simultaneously animated on the compositor.
> >>
> >>
> >> Link to entry on the Chrome Platform Status
> >>
> >>
> 

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

['Joe Medley' via blink-dev]

Hi,

In which version of Chrome do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  wrote:

> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on this
> thread.
>
> /Daniel
> On 2021-10-21 09:08, Yoav Weiss wrote:
>
> LGTM2 to catch up here
>
> (Apparently we have 2 intent emails for this..)
>
> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:
>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM  wrote:
>>
>>> Contact emails
>>> ssin...@igalia.com, fw...@chromium.org
>>>
>>> Explainer:
>>> The securitypolicyviolation event is already implemented in all
>>> browsers, one can find document on
>>> MDN(
>>> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>>> ,
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>>> ).
>>> The securitypolicyviolation event is dispatched when there is a Content
>>> Security Policy violation. Typically, the JS code of the web component
>>> will listen to securitypolicyviolation events and react with necessary
>>> updates.
>>>
>>> One could just use addEventListener, but for convenience and consistency
>>> with other events (e.g. slotchange) it makes sense to add a IDL
>>> onsecuritypolicyviolation attribute which also reflect the attribute on
>>> elements. We recently shipped slotchange idl attriubte as well
>>> (
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>>> )
>>>
>>> Developers are habitual to use EventTarget.onload = ... and >> onload="..."> , but if this does not work for all events, it will be
>>> surprising.
>>>
>>> Currently, the way to listen an event is:
>>> target.addEventListener("securitypolicyviolation", mylistener);
>>>
>>> After this addition an alternative attribute-based form will be
>>> availlable for the developers
>>> element
>>> 
>>>
>>> Doc Link(s):
>>> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>>> - https://github.com/whatwg/html/pull/2651
>>> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Specification
>>> https://html.spec.whatwg.org
>>>
>>> Summary
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.One can listen to that event via the
>>> EventTarget.addEventListener() API. The goal is now to expose the
>>> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
>>> interface, so that one can register a listener by attaching this
>>> attribute to target elements.
>>>
>>> Blink component
>>> Blink>DOM
>>>
>>> Motivation
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.
>>> One can naturally listen to that event via the
>>> EventTarget.addEventListener() API. However, web developers are also
>>> familiar with the alternative attribute-based form (e.g.
>>> element.addEventListener("securitypolicyviolation
>>> ", ...) Vs on )
>>> which is sometimes convenient for quick testing. For consistency with
>>> other events, an attribute onsecuritypolicyviolation is thus added.
>>>
>>> TAG review
>>> TAG review status
>>> This is just a small change to an existing spec implemented in browsers
>>> and discussed at WHATWG
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Gecko:
>>> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>>>
>>> WebKit:
>>> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
>>>
>>> Web developers:
>>> N/A
>>>
>>> Debuggability
>>> No DevTools changes are required, treated like any other
>>> event/attribute.
>>>
>>> Is this feature fully tested by web-platform-tests?
>>> Yes
>>>
>>> Web Platform Tests:
>>> w3c/web-platform-tests/dom/idlharness.window.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>>>
>>>
>>> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>>>
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
>>>
>>> Patch:
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Estimated milestones
>>> -
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/features/5639484386312192
>>>
>>> --
>>> 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
>>> 

[blink-dev] Misc Items in 96

['Joe Medley' via blink-dev]

Daisuke,

Thank you for letting me know.

FYI, the status entry for back-forward on desktop says it shipped in 92.
This is our fault. I'm guessing it started a dev or origin trial in that
version. We had outdated instructions giving the impression that the
shipping milestone fields applied to dev and origin trial as well.

I have the two items on my list now. I'll watch for merges on their
tracking bugs and for LGTMs on blink-dev@.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Oct 12, 2021 at 8:00 AM Daisuke Enomoto 
wrote:

> Hello Joe,
>
> We decided to land the shipping CLs after addressing TAG review comments,
> so WebTransport <https://chromestatus.com/feature/4854144902889472> won't
> ship in M96.
> There are two items currently not on your list: Back-forward cache on
> Android <https://chromestatus.com/feature/5694778600587264> and Back-forward
> cache on Desktop <https://chromestatus.com/feature/6279906713403392> we
> plan to ship in M96. I'll make the changes in the chromestatus entry.
>
> Thanks
> Daisuke
>
> On Thu, Oct 7, 2021 at 6:27 AM Anupam Snigdha 
> wrote:
>
>> Hey Joe,
>>
>> I don't think I would be able to land the change for Add support for
>> Promise to Blobs in clipboard item
>> <https://www.chromestatus.com/features/5733949474078720> by tomorrow so
>> this probably is not going to ship in 96. I'll make the changes in the
>> status entry as well.
>>
>> -Anupam
>>
>> On Wed, Oct 6, 2021 at 6:54 AM 'Joe Medley' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Thank you.
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Tue, Oct 5, 2021 at 8:07 AM Diego González  wrote:
>>>
>>>> Hola Joe,
>>>>
>>>> No, the feature you link to is Protocol Handlers. The one I am
>>>> referring to is URL Handling
>>>> <https://www.chromestatus.com/feature/5739732661174272>.  This is the
>>>> relevant Chrome OT entry
>>>> <https://developer.chrome.com/origintrials/#/view_trial/-5376172055173529599>
>>>> .
>>>>
>>>> Diego
>>>> On Tuesday, 5 October 2021 at 15:36:02 UTC+1 Joe Medley wrote:
>>>>
>>>>> This is exactly the kind of information I need.
>>>>>
>>>>> When a feature leaves an origin trial, I announce in the first version
>>>>> where it's enabled by default.
>>>>>
>>>>> URLHandlers: is that this
>>>>> <https://www.chromestatus.com/feature/5151703944921088>? Is its
>>>>> origin trial also being extended? Its Chrome Status entry says it shipped
>>>>> in 95, which means I announced it in the Chrome 95 beta post. (This is why
>>>>> I'm so naggy about keeping these things up to date.)
>>>>>
>>>>> Joe
>>>>>
>>>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>>>> 816-678-7195 <(816)%20678-7195>
>>>>> *If an API's not documented it doesn't exist.*
>>>>>
>>>>> On Mon, Oct 4, 2021 at 1:26 PM 'Diego Gonzalez' via blink-dev <
>>>>> blin...@chromium.org> wrote:
>>>>>
>>>>>> Hola Joe,
>>>>>>
>>>>>> Just in case this info is useful to you for the post, I wanted to let
>>>>>> you know Window Controls Overlay was planned to launch in 96 but we added
>>>>>> an extra cycle to the OT and now it is launching in 97.
>>>>>>
>>>>>> Also missing from this list is URL Handlers
>>>>>> <https://github.com/WICG/pwa-url-handler/blob/main/explainer.md>,
>>>>>> which is expected in 97, even though there are changes coming to the
>>>>>> feature to be substituted by `handle_links` `scope_extensions` and
>>>>>> `launch_handler`.
>>>>>>
>>>>>> -Diego
>>>>>>
>>>>>> On Thursday, 30 September 2021 at 17:51:53 UTC+1 Joe Medley wrote:
>>>>>>
>>>>>>> Gang,
>>>>>>>
>>>>>>> I apologize for sending this a week late.
>>>>>>>
>>>>>>> Chrome 96 is planned for beta on October 21. Developer Relation

Re: [blink-dev] Intent to Ship: Array and TypedArray findLast and findLastIndex

['Joe Medley' via blink-dev]

Thanks. Can you please add that to the Chrome Status entry? Open it for
editing, click "Edit all fields", then scroll all the way to the bottom.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Oct 8, 2021 at 8:56 AM Shu-yu Guo  wrote:

> Hi Joe,
>
> I will land the flag flip early next week, which would put this
> on-by-default in M97.
>
> On Fri, Oct 8, 2021 at 7:00 AM Joe Medley  wrote:
>
>> Shu-yu,
>>
>> In which version are you wanting to ship?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Oct 7, 2021 at 10:22 AM 'Shu-yu Guo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails...@chromium.org
>>>
>>> Explainerhttps://github.com/tc39/proposal-array-find-from-last
>>>
>>> Specificationhttps://tc39.es/proposal-array-find-from-last/index.html
>>>
>>> Summary
>>>
>>> This is a Stage 3 TC39 proposal that adds the methods findLast and
>>> findLastIndex to Array.prototype and the various TypedArray.prototypes.
>>> These methods are the "from the end" versions of find and findIndex.
>>>
>>>
>>> Blink componentBlink>JavaScript>Language
>>> 
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Adding any new methods to Array.prototype runs the risk of web
>>> incompatibility due to breaking old libraries. Rollout will need to be
>>> monitored.
>>>
>>>
>>> Gecko: Positive This is Stage 3 in TC39
>>>
>>> WebKit: Positive This is Stage 3 in TC39
>>>
>>> Web developers: Positive (
>>> https://twitter.com/mgechev/status/1432199126570131459?s=20)
>>>
>>>
>>> Debuggability
>>>
>>> It is a new prototype method, so can be debugged like any other
>>> prototype method.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes, in test262
>>>
>>> Flag name--harmony-array-find-last
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=11990
>>>
>>> Estimated milestones
>>> DevTrial on desktop 94
>>> DevTrial on android 94
>>> DevTrial on Webview 94
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5693639729610752
>>>
>>> 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/CAN-e9e8M7%3DfAX%2BfwmAzEY_bngPrJPzrD4sgctRoq-7TV46tCUg%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/CAJUhtG-Ut%2BX%3DEarNFb5Ta38YhTt1ZjgMSHfx1nKfiVhEn76Xrw%40mail.gmail.com.

Re: [blink-dev] Re: [RESPONSE REQUESTED] What's in Chrome 96?

['Joe Medley' via blink-dev]

Thank you.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Oct 5, 2021 at 8:07 AM Diego González  wrote:

> Hola Joe,
>
> No, the feature you link to is Protocol Handlers. The one I am referring
> to is URL Handling .  
> This
> is the relevant Chrome OT entry
> 
> .
>
> Diego
> On Tuesday, 5 October 2021 at 15:36:02 UTC+1 Joe Medley wrote:
>
>> This is exactly the kind of information I need.
>>
>> When a feature leaves an origin trial, I announce in the first version
>> where it's enabled by default.
>>
>> URLHandlers: is that this
>> ? Is its origin
>> trial also being extended? Its Chrome Status entry says it shipped in 95,
>> which means I announced it in the Chrome 95 beta post. (This is why I'm so
>> naggy about keeping these things up to date.)
>>
>> Joe
>>
>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>> On Mon, Oct 4, 2021 at 1:26 PM 'Diego Gonzalez' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hola Joe,
>>>
>>> Just in case this info is useful to you for the post, I wanted to let
>>> you know Window Controls Overlay was planned to launch in 96 but we added
>>> an extra cycle to the OT and now it is launching in 97.
>>>
>>> Also missing from this list is URL Handlers
>>> , which
>>> is expected in 97, even though there are changes coming to the feature to
>>> be substituted by `handle_links` `scope_extensions` and `launch_handler`.
>>>
>>> -Diego
>>>
>>> On Thursday, 30 September 2021 at 17:51:53 UTC+1 Joe Medley wrote:
>>>
 Gang,

 I apologize for sending this a week late.

 Chrome 96 is planned for beta on October 21. Developer Relations needs
 information to help us plan. We want a complete list of everything
 in Chrome beta for the beta post
 . We try when possible to
 have articles for important new features on web.dev
 .

 Please let me know of anything that might be shipping in Chrome 96
 or 97. I don't care if it's a new API, a bug to add a missing interface
 member, a spec change or whatever. I need to know all of it. If you have
 any questions about this, just ask, or refer to the FAQ in my communication
 instructions
 
 .

 Also, please make sure your Chrome Status entries reflect the
 current state of your feature. Origin trial and shipping milestone numbers
 may be edited by clicking the "Edit all fields" link and scrolling down the
 page.

 The list of what I currently believe to be shipping is in this
 spreadsheet
 .
 For those who can't reach it, here's a summary.

 (Deprecations and removals are in red.)

 103 Early Hints for Navigation
 
 Add support for Promise to Blobs in clipboard item
 
 App history API
 
 Attribution Reporting API
 
 Auto-expand details elements
 
 (Block external protocol in sandboxed iframe.)
 
 Capability Delegation
 
 COEP for shared worker
 
 Conditional Focus
 

 Content-Security-Policy delivery via response headers for dedicated
 workers. 
 Cross-Origin-Embedder-Policy: credentialless
 
 CSS :autofill Pseudo Class
 

 Disable propagation of body style to viewport when contained
 
 EME MediaKeySession Closed Reason
 
 fetch() upload streaming
 
 File Handling 
 File Handling Icons
 

Re: [blink-dev] Re: [RESPONSE REQUESTED] What's in Chrome 96?

['Joe Medley' via blink-dev]

This is exactly the kind of information I need.

When a feature leaves an origin trial, I announce in the first version
where it's enabled by default.

URLHandlers: is that this
? Is its origin
trial also being extended? Its Chrome Status entry says it shipped in 95,
which means I announced it in the Chrome 95 beta post. (This is why I'm so
naggy about keeping these things up to date.)

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Oct 4, 2021 at 1:26 PM 'Diego Gonzalez' via blink-dev <
blink-dev@chromium.org> wrote:

> Hola Joe,
>
> Just in case this info is useful to you for the post, I wanted to let you
> know Window Controls Overlay was planned to launch in 96 but we added an
> extra cycle to the OT and now it is launching in 97.
>
> Also missing from this list is URL Handlers
> , which
> is expected in 97, even though there are changes coming to the feature to
> be substituted by `handle_links` `scope_extensions` and `launch_handler`.
>
> -Diego
>
> On Thursday, 30 September 2021 at 17:51:53 UTC+1 Joe Medley wrote:
>
>> Gang,
>>
>> I apologize for sending this a week late.
>>
>> Chrome 96 is planned for beta on October 21. Developer Relations needs
>> information to help us plan. We want a complete list of everything
>> in Chrome beta for the beta post
>> . We try when possible to
>> have articles for important new features on web.dev
>> .
>>
>> Please let me know of anything that might be shipping in Chrome 96 or 97.
>> I don't care if it's a new API, a bug to add a missing interface member, a
>> spec change or whatever. I need to know all of it. If you have any
>> questions about this, just ask, or refer to the FAQ in my communication
>> instructions
>> 
>> .
>>
>> Also, please make sure your Chrome Status entries reflect the
>> current state of your feature. Origin trial and shipping milestone numbers
>> may be edited by clicking the "Edit all fields" link and scrolling down the
>> page.
>>
>> The list of what I currently believe to be shipping is in this
>> spreadsheet
>> .
>> For those who can't reach it, here's a summary.
>>
>> (Deprecations and removals are in red.)
>>
>> 103 Early Hints for Navigation
>> 
>> Add support for Promise to Blobs in clipboard item
>> 
>> App history API 
>> Attribution Reporting API
>> 
>> Auto-expand details elements
>> 
>> (Block external protocol in sandboxed iframe.)
>> 
>> Capability Delegation
>> 
>> COEP for shared worker
>> 
>> Conditional Focus
>> 
>>
>> Content-Security-Policy delivery via response headers for dedicated
>> workers. 
>> Cross-Origin-Embedder-Policy: credentialless
>> 
>> CSS :autofill Pseudo Class
>> 
>>
>> Disable propagation of body style to viewport when contained
>> 
>> EME MediaKeySession Closed Reason
>> 
>> fetch() upload streaming
>> 
>> File Handling 
>> File Handling Icons
>> 
>> HTTP->HTTPS redirect for HTTPS DNS records
>> 
>> preferCurrentTab 
>> Preserve PNG metadata
>> 
>> Priority Hints 
>> PWA manifest unique id - desktop
>> 
>>
>> (Remove alert(), confirm(), and prompt for cross origin iframes)
>> 
>> Reporting API: Isolate reports per-document and support the
>> Reporting-Endpoints header
>> 
>> Service Worker subresource filter
>> 

[blink-dev] [RESPONSE REQUESTED] What's in Chrome 96?

['Joe Medley' via blink-dev]

Gang,

I apologize for sending this a week late.

Chrome 96 is planned for beta on October 21. Developer Relations needs
information to help us plan. We want a complete list of everything
in Chrome beta for the beta post
. We try when possible to
have articles
for important new features on web.dev .

Please let me know of anything that might be shipping in Chrome 96 or 97. I
don't care if it's a new API, a bug to add a missing interface member, a
spec change or whatever. I need to know all of it. If you have any
questions about this, just ask, or refer to the FAQ in my communication
instructions

.

Also, please make sure your Chrome Status entries reflect the current state
of your feature. Origin trial and shipping milestone numbers may be edited
by clicking the "Edit all fields" link and scrolling down the page.

The list of what I currently believe to be shipping is in this spreadsheet
.
For those who can't reach it, here's a summary.

(Deprecations and removals are in red.)

103 Early Hints for Navigation

Add support for Promise to Blobs in clipboard item

App history API 
Attribution Reporting API

Auto-expand details elements

(Block external protocol in sandboxed iframe.)

Capability Delegation

COEP for shared worker 
Conditional Focus 

Content-Security-Policy delivery via response headers for dedicated workers.

Cross-Origin-Embedder-Policy: credentialless

CSS :autofill Pseudo Class


Disable propagation of body style to viewport when contained

EME MediaKeySession Closed Reason

fetch() upload streaming

File Handling 
File Handling Icons 
HTTP->HTTPS redirect for HTTPS DNS records

preferCurrentTab 
Preserve PNG metadata

Priority Hints 
PWA manifest unique id - desktop


(Remove alert(), confirm(), and prompt for cross origin iframes)

Reporting API: Isolate reports per-document and support the
Reporting-Endpoints header

Service Worker subresource filter

Storage Foundation API 
(The "basic-card" method of PaymentRequest API)


U2F Security Key API (Cryptotoken Component Extension)

URL Protocol Handler Registration for PWAs

WebAssembly Reference Types

WebTransport 
Window Controls Overlay for Installed Desktop Web Apps

Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*

-- 
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/CAJUhtG98%3DXDScuLah0O0Djhtfm3GktZ0rHiMUbF%2Bo9XQgb%3DOaA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Joe Medley' via blink-dev]

In which version will this ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Sep 9, 2021 at 12:05 PM Mike West  wrote:

> LGTM3.
>
> That said, we really need to stop renaming things that we've shipped. I
> think there's reasonable justification for doing so in this case, and given
> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
> for the `Report-To` model), it seems reasonable to me to follow through
> with an eventual deprecation. But more generally, shipping creates some
> unavoidable ossification. I might be over-reacting a bit to a few intents
> I'm recalling, but I think we need to carefully consider the cost of
> renaming vs the cost of asking developers to internalize a shift in
> behavior.
>
> What's the long-term plan for `Report-To`? Do you have a deprecation path
> you think is feasible, or are we going to end up trying to align it to
> `Reporting-Endpoints` as an alias at some point in the future?
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2021-09-07 16:06, Ian Clelland wrote:
>>
>>
>>
>> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
>>> wrote:
>>>
 Hey Yoav,

 Thanks for linking me in, I'm happy to provide my feedback here.

 Transparency: I'm Scott Helme, the founder of Report URI
 , which is a commercial service for allowing
 websites to collect reports sent via the Reporting API.

 We have a pretty strong position on the privacy concerns of websites
 collecting reports and outline all of the efforts we take to mitigate those
 concerns in our documentation. The change proposed here seems like a step
 in the right direction and as, I believe, the largest service of our kind
 in the world, we would like to show our support.

>>>
>> That's great to hear, thanks!
>>
>>>
 The interoperability and compatibility section states that "no
 collectors should have been relying on this behaviour" and I can indeed
 confirm that we don't rely on this behaviour and also agree that no other
 collector should rely on this behaviour either.

 The only concern I have is the idea of introducing another way to
 configure the reporting endpoint for NEL and eventually deprecating
 Report-To. Unless there's a particularly good reason for doing so, I'd like
 to avoid the confusion and added work for existing users of the Report-To
 header to have to make another change. It would be more convenient for
 sites currently using Report-To to continue to do so for NEL and document
 based reports, only making the change to add Reporting-Endpoints if they
 wish to do so. Is there an intended benefit of eventually deprecating
 Report-To in favour of yet another header?

>>>
>>> Thanks for the feedback, Scott! :)
>>>
>>> I believe the future NEL changes are not part of this intent.
>>> Ian - am I correct? If so, what's the best venue for Scott (and others)
>>> to provide that feedback and be involved in that conversation?
>>>
>>
>> That's correct; this intent is just for providing the new mechanism; we
>> deliberately introduced the new header in order to allow NEL to continue to
>> function in existing deployments.
>>
>> My eventual plan is to remove support for configuring document-centered
>> reports with Report-To, and only then to start the process of transitioning
>> network-centered reports, like NEL, away from header-based configuration
>> (if that turns out to be possible), but that will be a separate process,
>> with its own intents.
>>
>> The Network Reporting spec
>>  is probably the
>> best forum for talking about how to eventually configure those reports;
>> please file issues here  for
>> that.
>>
>> (As an aside, the biggest benefit of switching NEL away from headers, as
>> I see it, is that Report-To is currently a cookie-like mechanism, where
>> headers received with one document will affect the processing of subsequent
>> requests. It's unavoidable, certainly, that *some* state needs to be
>> persistent for NEL to actually function, but it would be better if there
>> were an origin-scoped mechanism, to avoid all of the issues with using
>> headers for this.)
>>
>> Ian
>>
>>
>>
>>
>>>

 Kind regards,

 Scott.

 On Friday, 3 September 2021 at 10:12:01 UTC+1 Yoav Weiss wrote:

> *LGTM1*
>
> Thanks for working on this. IIUC, the motivation for this change is
> feedback from other vendors to enable non-persistent document-level
> reporting.
> I'm glad to see that reflected in Mozilla's position.
>
>
> On Thursday, September 2, 2021 at 8:21:50 PM UTC+2
> 

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation

['Joe Medley' via blink-dev]

This is desktop only, right?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Fri, Aug 27, 2021 at 7:05 AM Stephen Mcgruer 
wrote:

> Contact emailsrous...@chromium.org, nbur...@chromium.org,
> smcgr...@chromium.org, ma...@chromium.org
>
> Explainerhttps://github.com/w3c/secure-payment-confirmation
>
> Specificationhttps://w3c.github.io/secure-payment-confirmation/
>
> 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 componentBlink>Payments
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/544
>
> TAG review statusPending
>
> *Supported on all platforms?*
> No.
>
> SPC is launching on MacOS and Windows only initially, as they are
> platforms that have built-in authenticators and which payment partners have
> noted as important targets.
>
> Android has browser-level support for SPC, but is excluded from the launch
> due to the lack of Discoverable Credentials currently. We will add Android
> once the platform supports that.
>
> Risks
> Interoperability and Compatibility
>
> This feature adds a WebAuthn extension and PaymentRequest payment method
> type, so the interop risk is that other browsers do not implement these
> types. The feature is detectable (though it could be easier[0]), so it
> should be possible for Web Developers to determine if SPC is enabled for a
> given user agent visiting their site. There is a risk that the feature will
> evolve away from the PaymentRequest API[1], which would then require a
> deprecation of the current API entry-point. It is worth noting that
> deprecations for payment are often easier than for the general web, as
> there are far, far fewer payment developers and websites that accept
> payments are almost always kept up to date (or their payment integrations
> might break!). [0]:
> https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-885046226
> [1]: https://github.com/w3c/secure-payment-confirmation/issues/65
>
> 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
> 
> ?Partially
>
>
> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>
> The WPT test suite is only partially complete and needs to be extended,
> but this first requires building out test automation machinery and
> content_shell support. The team is committed to this post initial launch.
>
> Requires code in //chrome?True
>
> Tracking bughttps://crbug.com/1124927
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1236570#
>
> Estimated milestones
> Ship: M95. Note that this is directly after the end of the Origin Trial,
> so we are still trying to determine whether we should do the 'week off'
> approach or apply for a no-skip transition. For the latter option, I think
> we may meet the bar. We've significantly changed the API in both M93 and
> M94 during the origin trial, and so M95 for example is not compatible with
> someone using code from M93.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5702310124584960
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8
>
>
> This intent message was generated by Chrome Platform Status
> , and then hand-edited.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To