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

[Yoav Weiss]

LGTM2


On Thu, Dec 16, 2021 at 2:02 AM Chris Harrelson 
wrote:

> LGTM1
>
> On Wed, Dec 15, 2021 at 4:59 PM TAMURA, Kent  wrote:
>
>> Contact emailstk...@chromium.org
>>
>> Specificationhttps://drafts.csswg.org/css-text-decor/#emphasis-marks
>>
>> Summary
>>
>> This feature introduces 'text-emphasis', 'text-emphasis-color', '
>> text-emphasis-position', and 'text-emphasis-style' CSS properties. They
>> are unprefixed versions of existing '-webkit-text-emphasis', '-
>> webkit-text-emphasis-color', '-webkit-text-emphasis-position', and '
>> -webkit-text-emphasis-style'.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone; Other browsers already shipped it.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Risks are very low. This feature doesn't change existing behavior, and
>> other browsers already shipped the feature.
>>
>>
>> Gecko: Shipped/Shipping
>>
>> WebKit: Shipped/Shipping
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>> Debuggability
>>
>> Same as other CSS properties.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=666433
>>
>> Sample links
>> https://developer.mozilla.org/en-US/docs/Web/CSS/text-emphasis
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5679635154075648
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>> --
>> 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/CAGH7WqFdzK2-kfz%2BwR%3DMGrm460T%2BU_3GnciR5T74nCUgzuBcUg%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%2Bw-UYP5ez%2Bh5a3%2BmhkAoFgT4mdranmTo%2BmvK-zZPzZZXLQ%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/CAL5BFfVZN1BkLUuc5Ly%3Dt4MDsr-jRXdpoO50R8ekBvSsmVL%2BVg%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Mike West]

LGTM. Good luck with the extension!

-mike

On Thu 16. Dec 2021 at 02:50 Hiroki Nakagawa  wrote:

> Good point. I think actually they don't need 4 more milestones for
> starting the experiment, so extending to 100 should be enough. Let me
> change the requesting milestones as follows:
>
> Estimated milestones
>
> Previous experiment timeline: M94 to M98
>
> Requested extension timeline: *M99 to M100*
>
>
> On Thu, Dec 16, 2021 at 12:33 AM Mike West  wrote:
>
>> In that case, do you need 4 more milestones? We've set a cap of 9
>> milestones
>> 
>>  for
>> OTs generally; this would bring y'all to 8. Do you need that entire period
>> if folks are actively experimenting now? If folks started testing in 97,
>> extending to 100 would give them 4 milestones to work with, which might be
>> enough?
>>
>> -mike
>>
>>
>> On Wed, Dec 15, 2021 at 4:22 PM Hiroki Nakagawa 
>> wrote:
>>
>>> Hi Mike,
>>>
>>> We are aware that some sites are now running their experiments. In
>>> addition to that, another site has been preparing for the experiment. We
>>> are now actively helping them.
>>>
>>> On Thu, Dec 16, 2021 at 12:08 AM Mike West  wrote:
>>>
 Was any site able to try this out during the initial experimental
 period? Or is this really just a delayed start to the trial? I think it's
 reasonable to extend out 4 additional milestones, but if you really didn't
 see any usage at all, it might be reasonable to consider this as a new
 starting date as opposed to an extension.

 -mike


 On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
 wrote:

> Hi Yoav,
> The requesting milestones are from M99 to M103 (The previous
> milestones were from M94 to M98).
>
>
> On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss 
> wrote:
>
>> What are the milestones for the continued experimentation?
>>
>> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
>> wrote:
>>
>>> Contact emails
>>>
>>> nhir...@chromium.org, navigation-...@chromium.org
>>>
>>> Explainer
>>>
>>> This feature:
>>> 
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>>
>>> This trial:
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>>
>>> Larger project:
>>> 
>>> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>>
>>> Summary
>>>
>>> Prerendering loads a web page before it is needed, so that when the
>>> actual navigation to that page occurs, it can be shown instantly.
>>>
>>> This experiment is for the specific case of same-origin prerendering
>>> triggered by the Speculation Rules API. An earlier, related experiment
>>> supported prefetching
>>> 
>>> using this API. This is a separate experiment that requires its own 
>>> origin
>>> trial token.
>>>
>>> This experiment has some limitations. See the explainer
>>> 
>>> for details.
>>>
>>> Blink component
>>>
>>> Internals>Preload>Prerender
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/667
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: We believe that some browsers already have
>>> prerendering implementations which are not well-specified and may differ
>>> from each other. 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. The danger here is that different
>>> browsers have different ways to trigger a prerendered page, and 
>>> prerendered
>>> pages behave differently in different browsers.
>>>
>>> Prerendering is a web-visible behavior, since it involves fetching
>>> the page an

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Good point. I think actually they don't need 4 more milestones for starting
the experiment, so extending to 100 should be enough. Let me change the
requesting milestones as follows:

Estimated milestones

Previous experiment timeline: M94 to M98

Requested extension timeline: *M99 to M100*


On Thu, Dec 16, 2021 at 12:33 AM Mike West  wrote:

> In that case, do you need 4 more milestones? We've set a cap of 9
> milestones
> 
>  for
> OTs generally; this would bring y'all to 8. Do you need that entire period
> if folks are actively experimenting now? If folks started testing in 97,
> extending to 100 would give them 4 milestones to work with, which might be
> enough?
>
> -mike
>
>
> On Wed, Dec 15, 2021 at 4:22 PM Hiroki Nakagawa 
> wrote:
>
>> Hi Mike,
>>
>> We are aware that some sites are now running their experiments. In
>> addition to that, another site has been preparing for the experiment. We
>> are now actively helping them.
>>
>> On Thu, Dec 16, 2021 at 12:08 AM Mike West  wrote:
>>
>>> Was any site able to try this out during the initial experimental
>>> period? Or is this really just a delayed start to the trial? I think it's
>>> reasonable to extend out 4 additional milestones, but if you really didn't
>>> see any usage at all, it might be reasonable to consider this as a new
>>> starting date as opposed to an extension.
>>>
>>> -mike
>>>
>>>
>>> On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
>>> wrote:
>>>
 Hi Yoav,
 The requesting milestones are from M99 to M103 (The previous
 milestones were from M94 to M98).


 On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss 
 wrote:

> What are the milestones for the continued experimentation?
>
> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
> wrote:
>
>> Contact emails
>>
>> nhir...@chromium.org, navigation-...@chromium.org
>>
>> Explainer
>>
>> This feature:
>> 
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>
>> This trial:
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>
>> Larger project:
>> 
>> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>
>> Summary
>>
>> Prerendering loads a web page before it is needed, so that when the
>> actual navigation to that page occurs, it can be shown instantly.
>>
>> This experiment is for the specific case of same-origin prerendering
>> triggered by the Speculation Rules API. An earlier, related experiment
>> supported prefetching
>> 
>> using this API. This is a separate experiment that requires its own 
>> origin
>> trial token.
>>
>> This experiment has some limitations. See the explainer
>> 
>> for details.
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/667
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk: We believe that some browsers already have
>> prerendering implementations which are not well-specified and may differ
>> from each other. 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. The danger here is that different
>> browsers have different ways to trigger a prerendered page, and 
>> prerendered
>> pages behave differently in different browsers.
>>
>> Prerendering is a web-visible behavior, since it involves fetching
>> the page and executing its scripts.
>>
>> Prerendering can depend on UA-specific heuristics. For example, the
>> browser might decide to act on a hint to prerender based on the system
>> load, and the presence of other prerenders. W

Re: [blink-dev] Intent to Ship: Allow infinity, -infinity and NaN in CSS calc()

[Seokho Song]

On Thursday, December 16, 2021 at 9:16:54 AM UTC+9 Seokho Song wrote:

> Hi, mike! Thanks for response :)
> On Saturday, December 11, 2021 at 3:39:16 PM UTC+9 mike...@chromium.org 
> wrote:
>
>> Hi Seokho,
>>
>> Thanks for working on this!
>>
>> On 12/9/21 6:56 PM, Seokho Song wrote:
>>
>> Contact emails 
>>
>> 0xde...@gmail.com
>>
>> Explainer 
>>
>> https://github.com/DevSDK/calc-infinity-and-NaN/blob/master/explainer.md
>>
>> Specification 
>>
>>
>> https://drafts.csswg.org/css-values/#ref-for-math-function%E2%91%A1%E2%91%A0
>>
>> Design docs
>>
>> https://bit.ly/349gXjq
>>
>> Summary 
>>
>> CSS calc() math function should allow infinity and NaN values by 
>> 'infinity', '-infinity', 'NaN' keywords or expressions that could be 
>> evaluated into infinity or NaN such as 'calc(1/0)'.
>>
>>
>> Blink component 
>>
>> Blink>CSS 
>> 
>>
>> Search tags 
>>
>> css , calc 
>> , infinity 
>> , nan 
>> 
>>
>> TAG review 
>>
>> Not required. It's a very small part of CSS.
>>
>> TAG review status 
>>
>> Not applicable
>>
>> Risks 
>>
>>  
>> Interoperability and Compatibility 
>>
>> This feature may have interoperability risks. Other browsers have not yet 
>> implemented this feature.
>>
>> Looking at 
>> https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=infinity-nan,
>>  
>> it seems like Chrome and Safari disagree on handling a top-level 
>> calculation that produces NaN, like "calc(NaN * 1px)" - I think we're 
>> treating it as positive Infinity, and they seem to be treating as 
>> (unsigned?) zero? 
>>
>> I filed https://bugs.webkit.org/show_bug.cgi?id=234176 to track that.
>>
>> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1682444)
>>
>> Can you please request a position? https://bit.ly/blink-signals
>>
>
> Sure. I've filed on 
> https://github.com/mozilla/standards-positions/issues/602.
> But not yet responded.
>  
>
>>
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=231044)
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>> Debuggability 
>>
>> N/A
>>
>> DevTools should support this out of the box, I think.
>>
>
> Can I ask what features or supports we need on devtools?
> What do I need some action on it? 
>
 
For this project,  the degenerate values are correctly reflected when we 
inspect the style of an element.

I think DevTools is already supporting this. No extra work is needed. 


>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? 
>>
>> Yes
>>
>>
>> Flag name
>>
>> Requires code in //chrome? 
>>
>> False
>>
>> Tracking bug 
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1133390
>>
>> Estimated milestones 
>>
>> 99
>>
>>
>> Link to entry on the Chrome Platform Status 
>>
>> https://chromestatus.com/feature/5657825571241984
>>
>> Links to previous Intent discussions 
>>
>> Intent to prototype: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/4cT9dMkzVXE/m/aCT8B6PDAwAJ
>>
>>
>> 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/f98064ee-9d8a-44a5-bf37-4a32a5471496n%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/c10dbce3-19ef-462b-965e-b5e5a851e7b1n%40chromium.org.

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

[Chris Harrelson]

LGTM1

On Wed, Dec 15, 2021 at 4:59 PM TAMURA, Kent  wrote:

> Contact emailstk...@chromium.org
>
> Specificationhttps://drafts.csswg.org/css-text-decor/#emphasis-marks
>
> Summary
>
> This feature introduces 'text-emphasis', 'text-emphasis-color', '
> text-emphasis-position', and 'text-emphasis-style' CSS properties. They
> are unprefixed versions of existing '-webkit-text-emphasis', '-
> webkit-text-emphasis-color', '-webkit-text-emphasis-position', and '
> -webkit-text-emphasis-style'.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone; Other browsers already shipped it.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Risks are very low. This feature doesn't change existing behavior, and
> other browsers already shipped the feature.
>
>
> Gecko: Shipped/Shipping
>
> WebKit: Shipped/Shipping
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> Same as other CSS properties.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=666433
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/CSS/text-emphasis
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5679635154075648
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> --
> 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/CAGH7WqFdzK2-kfz%2BwR%3DMGrm460T%2BU_3GnciR5T74nCUgzuBcUg%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%2Bw-UYP5ez%2Bh5a3%2BmhkAoFgT4mdranmTo%2BmvK-zZPzZZXLQ%40mail.gmail.com.

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

[TAMURA, Kent]

Contact emailstk...@chromium.org

Specificationhttps://drafts.csswg.org/css-text-decor/#emphasis-marks

Summary

This feature introduces 'text-emphasis', 'text-emphasis-color', '
text-emphasis-position', and 'text-emphasis-style' CSS properties. They are
unprefixed versions of existing '-webkit-text-emphasis', '-
webkit-text-emphasis-color', '-webkit-text-emphasis-position', and '
-webkit-text-emphasis-style'.


Blink componentBlink>CSS


TAG reviewNone; Other browsers already shipped it.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Risks are very low. This feature doesn't change existing behavior, and
other browsers already shipped the feature.


Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:


Debuggability

Same as other CSS properties.


Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

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

Sample links
https://developer.mozilla.org/en-US/docs/Web/CSS/text-emphasis

Estimated milestones

No milestones specified


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

This intent message was generated by Chrome Platform Status
.

-- 
TAMURA Kent
Software Engineer, Google

-- 
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/CAGH7WqFdzK2-kfz%2BwR%3DMGrm460T%2BU_3GnciR5T74nCUgzuBcUg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Allow infinity, -infinity and NaN in CSS calc()

[Seokho Song]

Hi, mike! Thanks for response :)
On Saturday, December 11, 2021 at 3:39:16 PM UTC+9 mike...@chromium.org 
wrote:

> Hi Seokho,
>
> Thanks for working on this!
>
> On 12/9/21 6:56 PM, Seokho Song wrote:
>
> Contact emails 
>
> 0xde...@gmail.com
>
> Explainer 
>
> https://github.com/DevSDK/calc-infinity-and-NaN/blob/master/explainer.md
>
> Specification 
>
>
> https://drafts.csswg.org/css-values/#ref-for-math-function%E2%91%A1%E2%91%A0
>
> Design docs
>
> https://bit.ly/349gXjq
>
> Summary 
>
> CSS calc() math function should allow infinity and NaN values by 
> 'infinity', '-infinity', 'NaN' keywords or expressions that could be 
> evaluated into infinity or NaN such as 'calc(1/0)'.
>
>
> Blink component 
>
> Blink>CSS 
> 
>
> Search tags 
>
> css , calc 
> , infinity 
> , nan 
> 
>
> TAG review 
>
> Not required. It's a very small part of CSS.
>
> TAG review status 
>
> Not applicable
>
> Risks 
>
>  
> Interoperability and Compatibility 
>
> This feature may have interoperability risks. Other browsers have not yet 
> implemented this feature.
>
> Looking at 
> https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=infinity-nan,
>  
> it seems like Chrome and Safari disagree on handling a top-level 
> calculation that produces NaN, like "calc(NaN * 1px)" - I think we're 
> treating it as positive Infinity, and they seem to be treating as 
> (unsigned?) zero? 
>
> I filed https://bugs.webkit.org/show_bug.cgi?id=234176 to track that.
>
> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1682444)
>
> Can you please request a position? https://bit.ly/blink-signals
>

Sure. I've filed on 
https://github.com/mozilla/standards-positions/issues/602.
But not yet responded.
 

>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=231044)
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability 
>
> N/A
>
> DevTools should support this out of the box, I think.
>

Can I ask what features or supports we need on devtools?
What do I need some action on it?


>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> Yes
>
>
> Flag name
>
> Requires code in //chrome? 
>
> False
>
> Tracking bug 
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1133390
>
> Estimated milestones 
>
> 99
>
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5657825571241984
>
> Links to previous Intent discussions 
>
> Intent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/4cT9dMkzVXE/m/aCT8B6PDAwAJ
>
>
> 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/f98064ee-9d8a-44a5-bf37-4a32a5471496n%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/80e8ba5a-e82a-4ee9-9156-ad298dce3e99n%40chromium.org.

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

['Harald Alvestrand' via blink-dev]

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
>>>
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
>>> which is currently behind a flag.
>>>
>>> Best regards,
 Philip

 On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
 blin...@chromium.org> wrote:

> 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.
>
> In the interest of getting the uncontroversial parts shipped - what
> would people think of letting the Codec Capabilities list of modes remain
> behind the flag, and push the rest of the API to public?
> Many usages of the function would work quite well with only probing
> for supported modes by trying to set the ones they want; we could then let
> the issue sort itself out in peace.
>
> (On the receiver side, there seems to be consensus on abandoning the
> mode list for other reasons.)
>
>
>
>
> On Wed, Nov 24, 2021 at 3:21 PM Mike West  wrote:
>
>> Friendly ping on Yoav's question about timelines.
>>
>> -mike
>>
>>
>> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss 
>> wrote:
>>
>>> How long of a delay are we talking about here? Weeks? Months? Years?
>>>
>>> On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand
>>> wrote:
>>>
 The scalability modes (being able to set them) are the point of the
 launch.
 Figuring out which of the desired ones are availa

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

[Rick Byers]

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/CAFUtAY9LO1i4cY1k_oQEjhNFCD4tuqXOJC%3DaP4%3D%2BoVjPb6mUeA%40mail.gmail.com.

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

[Bernard Aboba]

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.  

Chris - please jump in if I'm misunderstanding the consensus on Issue 182. 

RTCRtpEncodingParameters.scalabilityMode 
 (Section 5.1) 
is  required in order to set the scalability mode in 
RTCRtpSender.setParameters() as well as addTransceiver().   There has been 
no discussion of removing it. 

On Wednesday, December 15, 2021 at 12:01:32 PM UTC-5 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
>>>
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
>>> which is currently behind a flag.
>>>
>>> Best regards,
 Philip

 On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
 blin...@chromium.org> wrote:

> 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.
>
> In the interest of getting the uncontroversial parts shipped - what 
> would people think of letting the Codec Capabilities list of modes remain 
> behind the flag, and push the rest of the API to public?
> Many usages of the function would work quite well with only probing 
> for supported modes by trying to set the ones they want; we could then 
> let 
> the issue sort itself out in peace.
>
> (On the receiver side, there seems to be consensus on abandoning the 
> mode list for other reasons.)
>
>
>
>
> On Wed, Nov 24, 2021 at 3:21 PM Mike West  wrote:
>
>> Friendly ping on Yoav's question about timelines.
>>
>> -mike
>>
>>
>> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss  
>> wrote:
>>
>>> How long of a delay are we talking about here? Weeks? Months? Years?
>>>
>>> On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand 
>>> wrote:
>>>
 The scalability modes (being able to set them) are the point of the 
 launch.
 Figuring out which of the desired ones are available seems like it 
 would be a requirement.


 On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini <
 fs...@chromium.or

RE: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

['Anupam Snigdha' via blink-dev]

Re origin trial: We did discuss about origin trials, but we are not 
anticipating any changes to the web API. Note that `unsanitized` option is a 
member of `ClipboardItemOptions` dictionary and we are not changing the shape 
of the existing read/write methods.
Also, since this feature would benefit a lot from changes in the native apps, 
we want to commit to the native format naming/structure for pickled format map. 
Native apps like Office have a different release cycle (depending on whether it 
is enterprise or not, it would vary a lot), and it'll be really hard for them 
to make any changes if we decide to change either the naming or the JSON like 
structure of the format map.

From: Daniel Bratell 
Sent: Wednesday, December 15, 2021 8:40 AM
To: Yoav Weiss ; blink-dev 
Cc: Alex Russell ; Abhishek Rathi 
; svo...@gmail.com ; Anupam Snigdha 
; ajayra...@google.com ; Bo 
Cupp ; m...@google.com ; Joshua Bell 
; Victor Costan ; Scott Low 

Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async 
Clipboard API


One idea I have here is that unless everyone agrees to a plan, this might be 
suitable for an origin trial. That would allow the major sites that have said 
they want this to try it out without locking ourselves into a certain API shape.

/Daniel
On 2021-12-15 17:21, Yoav Weiss wrote:
Reading through the issues, I saw this 
comment,
 which suggests that the `unsantizied` option would be removed. That change is 
not yet reflected in the 
explainer,
 and seems like a big change.

Can you outline the plan?
On Tuesday, December 14, 2021 at 1:02:55 AM UTC+1 Alex Russell wrote:
Thanks for the feedback, Sean and Abishek.

Sounds like strong developer support; hoping this will get resolved this week.
On Thursday, December 9, 2021 at 10:04:09 AM UTC-8 Abhishek Rathi wrote:
At Excel Online, we tried this in our dev environments have seen significant 
improvement in Copy Paste fidelity from desktop apps. This will improve user 
experience especially for app specific features like formulas, tables, etc.
On Tuesday, 7 December, 2021 at 10:31:44 pm UTC+5:30 
svo...@gmail.com wrote:
Happy to see movement on this. Just a note to say that we would like to use 
this feature at Adobe, and would be interested in using it in Photoshop Web, 
Creative Cloud Canvas, and potentially other future web initiatives, 
particularly for interop with our desktop applications. (With the 
understanding, of course, that said applications would have to be updated to 
read the custom web format map.)

Sean
On Thursday, November 18, 2021 at 1:30:32 PM UTC-8 snianu wrote:
Contact emails
sni...@microsoft.com, 
m...@chromium.org, 
pc...@microsoft.com
Explainer
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api
Specification
https://github.com/w3c/clipboard-apis/pull/162
https://github.com/w3c/clipboard-apis/pull/158

[blink-dev] RE: [EXTERNAL] Re: Intent to Ship: Pickling for Async Clipboard API

['Anupam Snigdha' via blink-dev]

Hi Yoav,

That comment is specifically for adding the `unsanitized` option to the 
clipboard API spec to which Apple opposed as they don't want to support(at 
least currently) reading/writing custom format or unsanitized well-known format 
if it's not within the same origin. That means, exchanging custom pickled 
formats between web app & native app wouldn't be supported on Safari. We think 
that this scenario is essential for unlocking high fidelity copy/paste 
scenarios for native/web apps developers. The `unsanitized` option is required 
if we want to support reading the standard MIME types (text/html, image/png 
etc) from the pickled format 
map
 which would return the unsanitized version of the format. Currently, there is 
no way for us to differentiate between reading the standard MIME types from 
well-known native 
formats
 and pickled format 
map
 without the `unsanitized` option, so we decided to add this option to the 
`ClipboardItemOptions` dictionary that would be available only on Chromium 
browsers.
 FWIW there is already an option in `ClipboardItemOptions` that is very 
specific to iPadOS/iOS and it's only supported in Safari: 
https://github.com/w3c/clipboard-apis/pull/162#issuecomment-974334049. I'm not 
even sure how this option was able to make it to the spec, but we certainly 
would have opposed to this change.
Please let me know if you have any other concerns/questions.

Thanks,
Anupam

From: Yoav Weiss 
Sent: Wednesday, December 15, 2021 8:22 AM
To: blink-dev 
Cc: Alex Russell ; Abhishek Rathi 
; svo...@gmail.com ; Anupam Snigdha 
; ajayra...@google.com ; Bo 
Cupp ; m...@google.com ; Joshua Bell 
; Victor Costan ; Scott Low 

Subject: [EXTERNAL] Re: Intent to Ship: Pickling for Async Clipboard API

Reading through the issues, I saw this 
comment,
 which suggests that the `unsantizied` option would be removed. That change is 
not yet reflected in the 
explainer,
 and seems like a big change.

Can you outline the plan?
On Tuesday, December 14, 2021 at 1:02:55 AM UTC+1 Alex Russell wrote:
Thanks for the feedback, Sean and Abishek.

Sounds like strong developer support; hoping this will get resolved this week.
On Thursday, December 9, 2021 at 10:04:09 AM UTC-8 Abhishek Rathi wrote:
At Excel Online, we tried this in our dev environments have seen significant 
improvement in Copy Paste fidelity from desktop apps. This will improve user 
experience especially for app specific features like formulas, tables, etc.
On Tuesday, 7 December, 2021 at 10:31:44 pm UTC+5:30 
svo...@gmail.com wrote:
Happy to see movement on this. Just a note to say that we would like to use 
this feature at Adobe, and would be interested in using it in Photoshop Web, 
Creative Cloud Canvas, and potentially other future web initiatives, 
particularly for interop with our desktop applications. (With the 
understanding, of course, that said applications would have to be updated to 
read the custom web format map.)

Sean
On Thursday, November 18, 2021 at 1:30:32 PM UTC-8 snianu wrote:
Contact emails
sni...@microsoft.com, 
m...@chromium.org, 
pc...@microsoft.com
Explainer
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api

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

[Hongchan Choi]

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 <
> chcunning...@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 bluetooth vs wired), so it's 
> critical
> to have the platform tell you when this changes. In terms of 
> precision, we
> can _probably_ do some rounding like to the nearest millisecond. 
> Higher
> values may lead to issues; user studies
> 

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

[Philip Jägenstedt]

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
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
>> which is currently behind a flag.
>>
>> Best regards,
>>> Philip
>>>
>>> On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 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.

 In the interest of getting the uncontroversial parts shipped - what
 would people think of letting the Codec Capabilities list of modes remain
 behind the flag, and push the rest of the API to public?
 Many usages of the function would work quite well with only probing for
 supported modes by trying to set the ones they want; we could then let the
 issue sort itself out in peace.

 (On the receiver side, there seems to be consensus on abandoning the
 mode list for other reasons.)




 On Wed, Nov 24, 2021 at 3:21 PM Mike West  wrote:

> Friendly ping on Yoav's question about timelines.
>
> -mike
>
>
> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss 
> wrote:
>
>> How long of a delay are we talking about here? Weeks? Months? Years?
>>
>> On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand
>> wrote:
>>
>>> The scalability modes (being able to set them) are the point of the
>>> launch.
>>> Figuring out which of the desired ones are available seems like it
>>> would be a requirement.
>>>
>>>
>>> On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini <
>>> fs...@chromium.org> wrote:
>>>
 It seems they are asking for a delay on Chrome launching this until
 the WebRTC WG makes a decision on it.
 It's not clear from the issue that there's a consensus on the right
 approach there.

 Did you consider launching things separately and delaying the
 scalability modes? Or does the whole launch make no sense without it?

 --
>> 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/1197505b-23e6-491a-8fc6-4b

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

[Alex Russell]

LGTM3

On Wednesday, December 15, 2021 at 7:51:30 AM UTC-8 Yoav Weiss wrote:

> LGTM2
>
> On Wednesday, December 15, 2021 at 4:18:50 PM UTC+1 Mike West wrote:
>
>> LGTM1.
>>
>> Given that this codifies existing Chrome behavior in a way that it seems 
>> like other vendors can get on board with, I'm supportive of shipping this 
>> more standardized mechanism for showing native UX. I do wonder what we're 
>> going to do with `click()` in the long term. Is there a deprecation plan 
>> for that behavior, since it seems unlikely to become interoperable 
>> otherwise?
>>
>> -mike
>>
>>
>> On Tue, Dec 14, 2021 at 4:03 PM 'Joe Medley' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> 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 
  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://gi

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

[Chris Harrelson]

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 <
 chcunning...@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 bluetooth vs wired), so it's 
 critical
 to have the platform tell you when this changes. In terms of 
 precision, we
 can _probably_ do some rounding like to the nearest millisecond. Higher
 values may lead to issues; user studies
 
 have shown sensitivity to fairly low values of drift.

 Aside: we may eventually desire a display latency value for similar
 reasons.

 On Thu, Nov 18, 2021 at 12:45 PM Hongchan Choi <
 hong...@chromium.org> wrote:

> Hi Yoav,
>
> C

Re: [blink-dev] Re: Intent to Ship: Handwriting Recognition API

[Chris Harrelson]

Coming back to the intent-to-ship part: do you consider it ready for
approval? Or are there more spec or other issues to iron out before we
should consider approval?

On Thu, Dec 9, 2021 at 9:50 PM Chris Harrelson 
wrote:

> I think it's ok. LGTM. Thanks for doing your best to ship a high-quality
> implementation!
>
> Note that this will be a total of 8 milestones
> ,
> including M98, but as was mentioned in a previous intent, there was also a
> breaking API change in M95, plus evidence of experimental feedback.
>
> On Wed, Dec 8, 2021 at 9:07 PM Glen Robertson 
> wrote:
>
>> Given that the Handwriting Recognition OT ends with M97, and M98 branches
>> today, it seems like it will be difficult to ship in M98 - a merge request
>> to enable the feature is unlikely to be approved.
>>
>> Blink Owners: Would it be acceptable to extend the OT for 1 additional
>> milestone (end in M98) and ship in M99?
>>
>> On Thu, 9 Dec 2021 at 02:57, Jiewei Qian  wrote:
>>
>>> Contact emails
>>>
>>> q...@chromium.org, hongli...@chromium.org, mgi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/handwriting-recognition/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/handwriting-recognition/ [in review]
>>>
>>> Design docs
>>>
>>> https://github.com/WICG/handwriting-recognition/blob/main/explainer.md
>>>
>>> Summary
>>>
>>> An API for web applications to make use of advanced handwriting
>>> recognition services (e.g. those on operating systems) to recognize text
>>> from handwriting drawings (inks) in real time. In this context, handwriting
>>> drawing means the temporal and positional information used to describe a
>>> human handwriting process.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Handwriting
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/591
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Link to origin trial feedback summary
>>>
>>>
>>> https://docs.google.com/document/d/1BGd3WiwiqBA1JQaG-r0bc5No0f0KkqW13EhO1YeQocA/edit
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Different browsers (and operating systems) will expose different
>>> underlying implementations and produce different outputs given the same
>>> input. We think this is acceptable given the implementation is
>>> machine-learning based, and it is not feasible or desirable to precisely
>>> specify the expected output for a given input in a standard. In the past,
>>> we have taken this approach for the Web Speech and Shape Detection APIs.
>>>
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/507) Feedback
>>> requested, no reply yet.
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-March/031762.html)
>>> Feedback requested, no reply yet.
>>>
>>> Web developers: Positive (
>>> https://github.com/WICG/handwriting-recognition/issues/21) Twitter:
>>> https://twitter.com/ChromiumDev/status/1428640785810051074
>>>
>>> Other signals:
>>>
>>>
>>> Debuggability
>>>
>>> N/A. Existing DevTools tooling works for this feature.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No. Full coverage relies on platform-specific implementation. WPT only
>>> tests failure cases.
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1207667
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1206121
>>>
>>> Estimated milestones
>>>
>>> OriginTrial desktop last
>>>
>>> 97
>>>
>>> OriginTrial desktop first
>>>
>>> 91
>>>
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5263213807534080
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/VXUq1UY4m7Y
>>>
>>> Intent to Experiment:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/o8RqlFwZItQ/m/vgHLF_pHBQAJ
>>>
>>>
>>> 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/CAPV%2BSg-5XE4cpDbwT69_T4u2CPN18O-9y_8nAW%2Bq-XYpwtjn3A%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To

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

[Mike Taylor]

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
 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  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

).

 

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

[Yoav Weiss]

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 <
>>> chcunning...@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 bluetooth vs wired), so it's 
>>> critical 
>>> to have the platform tell you when this changes. In terms of precision, 
>>> we 
>>> can _probably_ do some rounding like to the nearest millisecond. Higher 
>>> values may lead to issues; user studies 
>>> 
>>>  
>>> have shown sensitivity to fairly low values of drift. 
>>>
>>> Aside: we may eventually desire a display latency value for similar 
>>> reasons. 
>>>
>>> On Thu, Nov 18, 2021 at 12:45 PM Hongchan Choi  
>>> wrote:
>>>
 Hi Yoav, 

 Could you clarify what needs to be discussed from the spec side? 
 The feature (and its behavior) is properly specified, and its privacy 
 aspect is already reviewed by W3C:
 https://github.com/WebAudio/

Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

[Daniel Bratell]

One idea I have here is that unless everyone agrees to a plan, this 
might be suitable for an origin trial. That would allow the major sites 
that have said they want this to try it out without locking ourselves 
into a certain API shape.


/Daniel

On 2021-12-15 17:21, Yoav Weiss wrote:
Reading through the issues, I saw this comment 
, 
which suggests that the `unsantizied` option would be removed. That 
change is not yet reflected in the explainer 
, 
and seems like a big change.


Can you outline the plan?

On Tuesday, December 14, 2021 at 1:02:55 AM UTC+1 Alex Russell wrote:

Thanks for the feedback, Sean and Abishek.

Sounds like strong developer support; hoping this will get
resolved this week.

On Thursday, December 9, 2021 at 10:04:09 AM UTC-8 Abhishek Rathi
wrote:

At Excel Online, we tried this in our dev environments have
seen significant improvement in Copy Paste fidelity from
desktop apps. This will improve user experience especially for
app specific features like formulas, tables, etc.
On Tuesday, 7 December, 2021 at 10:31:44 pm UTC+5:30
svo...@gmail.com wrote:

Happy to see movement on this. Just a note to say that we
would like to use this feature at Adobe, and would be
interested in using it in Photoshop Web, Creative Cloud
Canvas, and potentially other future web initiatives,
particularly for interop with our desktop applications.
(With the understanding, of course, that said applications
would have to be updated to read the custom web format map.)

Sean
On Thursday, November 18, 2021 at 1:30:32 PM UTC-8 snianu
wrote:


Contact emails

sni...@microsoft.com, m...@chromium.org,
pc...@microsoft.com


Explainer


https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api




Specification

https://github.com/w3c/clipboard-apis/pull/162


https://github.com/w3c/clipboard-apis/pull/158




Design docs



https://docs.google.com/document/d/1afc45MQuwxEWgoUeJCO-sOWRSzs31V4JS-kKXJNMTXw/edit




Summary

Pickle Clipboard API lets websites read and write
arbitrary unsanitized payloads using a standardized
pickling format, as well as read and write a limited
subset of OS-specific formats (for supporting legacy
apps). The name of the clipboard format is mangled by
the browser in a standardized way to indicate that the
content is from the web, which allows native
applications to opt-in to accepting the unsanitized
content.


Blink component

Blink>DataTransfer




Search tags

pickle
,
pickling api
,
pickling
,
clipboard custom format




TAG review

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



TAG review status

Issues addressed


Risks


Interoperability and Compatibility

Other browsers implement an ability to write custom
clipboard data in varied shapes. Part of the value of
   

[blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

[Yoav Weiss]

Reading through the issues, I saw this comment 
, 
which suggests that the `unsantizied` option would be removed. That change 
is not yet reflected in the explainer 
,
 
and seems like a big change.

Can you outline the plan?

On Tuesday, December 14, 2021 at 1:02:55 AM UTC+1 Alex Russell wrote:

> Thanks for the feedback, Sean and Abishek.
>
> Sounds like strong developer support; hoping this will get resolved this 
> week.
>
> On Thursday, December 9, 2021 at 10:04:09 AM UTC-8 Abhishek Rathi wrote:
>
>> At Excel Online, we tried this in our dev environments have seen 
>> significant improvement in Copy Paste fidelity from desktop apps. This will 
>> improve user experience especially for app specific features like formulas, 
>> tables, etc.
>> On Tuesday, 7 December, 2021 at 10:31:44 pm UTC+5:30 svo...@gmail.com 
>> wrote:
>>
>>> Happy to see movement on this. Just a note to say that we would like to 
>>> use this feature at Adobe, and would be interested in using it in Photoshop 
>>> Web, Creative Cloud Canvas, and potentially other future web initiatives, 
>>> particularly for interop with our desktop applications. (With the 
>>> understanding, of course, that said applications would have to be updated 
>>> to read the custom web format map.)
>>>
>>> Sean
>>> On Thursday, November 18, 2021 at 1:30:32 PM UTC-8 snianu wrote:
>>>
 Contact emails 

 sni...@microsoft.com, m...@chromium.org, pc...@microsoft.com

 Explainer 


 https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api

 Specification 

 https://github.com/w3c/clipboard-apis/pull/162

 https://github.com/w3c/clipboard-apis/pull/158 
 
 Design docs 



 https://docs.google.com/document/d/1afc45MQuwxEWgoUeJCO-sOWRSzs31V4JS-kKXJNMTXw/edit

 Summary 

 Pickle Clipboard API lets websites read and write arbitrary unsanitized 
 payloads using a standardized pickling format, as well as read and write a 
 limited subset of OS-specific formats (for supporting legacy apps). The 
 name of the clipboard format is mangled by the browser in a standardized 
 way to indicate that the content is from the web, which allows native 
 applications to opt-in to accepting the unsanitized content.

  
 Blink component 

 Blink>DataTransfer 
 

 Search tags 

 pickle , pickling 
 api , 
 pickling , clipboard 
 custom format 
 

 TAG review 

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

 TAG review status 

 Issues addressed

 Risks 

  
 Interoperability and Compatibility 

 Other browsers implement an ability to write custom clipboard data in 
 varied shapes. Part of the value of this work is to standardize the names 
 of the formats that will be written per platform and to ensure a common 
 shape of data on the clipboard so that browsers can read and write from 
 this standard set of pickled formats.


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

 *WebKit*: Neutral (
 https://github.com/w3c/editing/issues/334#issuecomment-933939592) 
 Webkit has a custom format implementation which isn't well documented.

 *Web developers*: Positive (
 https://github.com/w3ctag/design-reviews/issues/636#issuecomment-854038820)
  
 Positive signal from Figma & Sketchup. Internal MS office products have 
 shown interest in supporting this API.

 *Other signals*:

 Ergonomics 

 This feature is part of the existing async clipboard read/write. It 
 doesn't affect the well-defined formats that are supported by this API.

  
 Activation 

 The feature uses the existing async clipboard read/write methods which 
 has already been shipped.

  
 Security 

 Here is a link to a more detailed security review: 
 https://github.com/w3c/editing/issues/31

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

[Yoav Weiss]

LGTM2

On Wednesday, December 15, 2021 at 4:18:50 PM UTC+1 Mike West wrote:

> LGTM1.
>
> Given that this codifies existing Chrome behavior in a way that it seems 
> like other vendors can get on board with, I'm supportive of shipping this 
> more standardized mechanism for showing native UX. I do wonder what we're 
> going to do with `click()` in the long term. Is there a deprecation plan 
> for that behavior, since it seems unlikely to become interoperable 
> otherwise?
>
> -mike
>
>
> On Tue, Dec 14, 2021 at 4:03 PM 'Joe Medley' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Mike West]

In that case, do you need 4 more milestones? We've set a cap of 9 milestones

for
OTs generally; this would bring y'all to 8. Do you need that entire period
if folks are actively experimenting now? If folks started testing in 97,
extending to 100 would give them 4 milestones to work with, which might be
enough?

-mike


On Wed, Dec 15, 2021 at 4:22 PM Hiroki Nakagawa 
wrote:

> Hi Mike,
>
> We are aware that some sites are now running their experiments. In
> addition to that, another site has been preparing for the experiment. We
> are now actively helping them.
>
> On Thu, Dec 16, 2021 at 12:08 AM Mike West  wrote:
>
>> Was any site able to try this out during the initial experimental period?
>> Or is this really just a delayed start to the trial? I think it's
>> reasonable to extend out 4 additional milestones, but if you really didn't
>> see any usage at all, it might be reasonable to consider this as a new
>> starting date as opposed to an extension.
>>
>> -mike
>>
>>
>> On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
>> wrote:
>>
>>> Hi Yoav,
>>> The requesting milestones are from M99 to M103 (The previous milestones
>>> were from M94 to M98).
>>>
>>>
>>> On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss 
>>> wrote:
>>>
 What are the milestones for the continued experimentation?

 On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
 wrote:

> Contact emails
>
> nhir...@chromium.org, navigation-...@chromium.org
>
> Explainer
>
> This feature:
> 
> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>
> This trial:
> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>
> Larger project:
> 
> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>
> Summary
>
> Prerendering loads a web page before it is needed, so that when the
> actual navigation to that page occurs, it can be shown instantly.
>
> This experiment is for the specific case of same-origin prerendering
> triggered by the Speculation Rules API. An earlier, related experiment
> supported prefetching
> 
> using this API. This is a separate experiment that requires its own origin
> trial token.
>
> This experiment has some limitations. See the explainer
> 
> for details.
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> Interoperability risk: We believe that some browsers already have
> prerendering implementations which are not well-specified and may differ
> from each other. 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. The danger here is that different
> browsers have different ways to trigger a prerendered page, and 
> prerendered
> pages behave differently in different browsers.
>
> Prerendering is a web-visible behavior, since it involves fetching the
> page and executing its scripts.
>
> Prerendering can depend on UA-specific heuristics. For example, the
> browser might decide to act on a hint to prerender based on the system
> load, and the presence of other prerenders. We do not intend to codify
> heuristics in the specification. A conforming browser might simply ignore
> all hints to prerender a page.
>
> Compatibility risk: Some use cases will need to know whether a page is
> being prerendered. Ads and analytics are likely examples of this. This
> feature exposes `document.prerendering` to detect prerendering, but there
> is a risk of sites that would benefit from using the API, not using it. We
> believe that this

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Hi Mike,

We are aware that some sites are now running their experiments. In addition
to that, another site has been preparing for the experiment. We are now
actively helping them.

On Thu, Dec 16, 2021 at 12:08 AM Mike West  wrote:

> Was any site able to try this out during the initial experimental period?
> Or is this really just a delayed start to the trial? I think it's
> reasonable to extend out 4 additional milestones, but if you really didn't
> see any usage at all, it might be reasonable to consider this as a new
> starting date as opposed to an extension.
>
> -mike
>
>
> On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
> wrote:
>
>> Hi Yoav,
>> The requesting milestones are from M99 to M103 (The previous milestones
>> were from M94 to M98).
>>
>>
>> On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss 
>> wrote:
>>
>>> What are the milestones for the continued experimentation?
>>>
>>> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
>>> wrote:
>>>
 Contact emails

 nhir...@chromium.org, navigation-...@chromium.org

 Explainer

 This feature:
 
 https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md

 This trial:
 https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md

 Larger project:
 
 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing

 Summary

 Prerendering loads a web page before it is needed, so that when the
 actual navigation to that page occurs, it can be shown instantly.

 This experiment is for the specific case of same-origin prerendering
 triggered by the Speculation Rules API. An earlier, related experiment
 supported prefetching
 
 using this API. This is a separate experiment that requires its own origin
 trial token.

 This experiment has some limitations. See the explainer
 
 for details.

 Blink component

 Internals>Preload>Prerender
 

 TAG review

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

 TAG review status

 Pending

 Risks

 Interoperability and Compatibility

 Interoperability risk: We believe that some browsers already have
 prerendering implementations which are not well-specified and may differ
 from each other. 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. The danger here is that different
 browsers have different ways to trigger a prerendered page, and prerendered
 pages behave differently in different browsers.

 Prerendering is a web-visible behavior, since it involves fetching the
 page and executing its scripts.

 Prerendering can depend on UA-specific heuristics. For example, the
 browser might decide to act on a hint to prerender based on the system
 load, and the presence of other prerenders. We do not intend to codify
 heuristics in the specification. A conforming browser might simply ignore
 all hints to prerender a page.

 Compatibility risk: Some use cases will need to know whether a page is
 being prerendered. Ads and analytics are likely examples of this. This
 feature exposes `document.prerendering` to detect prerendering, but there
 is a risk of sites that would benefit from using the API, not using it. We
 believe that this risk is tractable because prerendering has existed in
 Chrome in the recent past and currently exists in some other browsers. We
 also intend to add a header to network requests like `Purpose: prefetch` so
 that origin servers can identify requests for prerendered pages.


 Gecko: No signal


 WebKit: No signals, while Safari appears to have some form of
 prerendering already.


 Web developers: No signals


 Other signals: No signals



 Ergonomics

 This feature is triggered by the Speculation Rules API:
 https://chromestatus.com/feature/5740655424831488

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

[Mike West]

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/CAKXHy%3Dc1F0KBJ%3DKHzjEH2z%3DMk%3D13vB%2BHyqFVC-NVC5zheCMZgg%40mail.gmail.com.

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

[Mike West]

LGTM1.

Given that this codifies existing Chrome behavior in a way that it seems
like other vendors can get on board with, I'm supportive of shipping this
more standardized mechanism for showing native UX. I do wonder what we're
going to do with `click()` in the long term. Is there a deprecation plan
for that behavior, since it seems unlikely to become interoperable
otherwise?

-mike


On Tue, Dec 14, 2021 at 4:03 PM 'Joe Medley' via blink-dev <
blink-dev@chromium.org> wrote:

> 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 

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Mike West]

Was any site able to try this out during the initial experimental period?
Or is this really just a delayed start to the trial? I think it's
reasonable to extend out 4 additional milestones, but if you really didn't
see any usage at all, it might be reasonable to consider this as a new
starting date as opposed to an extension.

-mike


On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
wrote:

> Hi Yoav,
> The requesting milestones are from M99 to M103 (The previous milestones
> were from M94 to M98).
>
>
> On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss  wrote:
>
>> What are the milestones for the continued experimentation?
>>
>> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
>> wrote:
>>
>>> Contact emails
>>>
>>> nhir...@chromium.org, navigation-...@chromium.org
>>>
>>> Explainer
>>>
>>> This feature:
>>> 
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>>
>>> This trial:
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>>
>>> Larger project:
>>> 
>>> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>>
>>> Summary
>>>
>>> Prerendering loads a web page before it is needed, so that when the
>>> actual navigation to that page occurs, it can be shown instantly.
>>>
>>> This experiment is for the specific case of same-origin prerendering
>>> triggered by the Speculation Rules API. An earlier, related experiment
>>> supported prefetching
>>> 
>>> using this API. This is a separate experiment that requires its own origin
>>> trial token.
>>>
>>> This experiment has some limitations. See the explainer
>>> 
>>> for details.
>>>
>>> Blink component
>>>
>>> Internals>Preload>Prerender
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/667
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: We believe that some browsers already have
>>> prerendering implementations which are not well-specified and may differ
>>> from each other. 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. The danger here is that different
>>> browsers have different ways to trigger a prerendered page, and prerendered
>>> pages behave differently in different browsers.
>>>
>>> Prerendering is a web-visible behavior, since it involves fetching the
>>> page and executing its scripts.
>>>
>>> Prerendering can depend on UA-specific heuristics. For example, the
>>> browser might decide to act on a hint to prerender based on the system
>>> load, and the presence of other prerenders. We do not intend to codify
>>> heuristics in the specification. A conforming browser might simply ignore
>>> all hints to prerender a page.
>>>
>>> Compatibility risk: Some use cases will need to know whether a page is
>>> being prerendered. Ads and analytics are likely examples of this. This
>>> feature exposes `document.prerendering` to detect prerendering, but there
>>> is a risk of sites that would benefit from using the API, not using it. We
>>> believe that this risk is tractable because prerendering has existed in
>>> Chrome in the recent past and currently exists in some other browsers. We
>>> also intend to add a header to network requests like `Purpose: prefetch` so
>>> that origin servers can identify requests for prerendered pages.
>>>
>>>
>>> Gecko: No signal
>>>
>>>
>>> WebKit: No signals, while Safari appears to have some form of
>>> prerendering already.
>>>
>>>
>>> Web developers: No signals
>>>
>>>
>>> Other signals: No signals
>>>
>>>
>>>
>>> Ergonomics
>>>
>>> This feature is triggered by the Speculation Rules API:
>>> https://chromestatus.com/feature/5740655424831488
>>>
>>>
>>> Activation
>>>
>>> Developers can use the Speculation Rules API to use the feature. The
>>> feature should just work for most existing pages. Developers should be
>>> aware of restrictions on prerendering content (they cannot play audio or
>>> perform other disruptive behavior, etc). This feature would benefit from
>>> good documentation.
>>>
>>>
>>> Security
>>>

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

[Mike Taylor]

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/d597b804-a96d-1405-b840-82ca22197b9a%40chromium.org.

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

[Yoav Weiss]

*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/CAL5BFfUpmasvRYhGAuOVGuJdRgna8ebkWMOMxXS%3D5R3AUkrgCQ%40mail.gmail.com.

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

[Yoav Weiss]

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/CAL5BFfWmiP-T6-oJtF47cHEmfLmCWS%3DskB6_hAQTJohQwbc_0w%40mail.gmail.com.

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

[Mike Taylor]

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/0a980b69-6586-330a-a273-07d611d12cf5%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Hi Yoav,
The requesting milestones are from M99 to M103 (The previous milestones
were from M94 to M98).


On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss  wrote:

> What are the milestones for the continued experimentation?
>
> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
> wrote:
>
>> Contact emails
>>
>> nhir...@chromium.org, navigation-...@chromium.org
>>
>> Explainer
>>
>> This feature:
>> 
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>
>> This trial:
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>
>> Larger project:
>> 
>> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>
>> Summary
>>
>> Prerendering loads a web page before it is needed, so that when the
>> actual navigation to that page occurs, it can be shown instantly.
>>
>> This experiment is for the specific case of same-origin prerendering
>> triggered by the Speculation Rules API. An earlier, related experiment
>> supported prefetching
>> 
>> using this API. This is a separate experiment that requires its own origin
>> trial token.
>>
>> This experiment has some limitations. See the explainer
>> 
>> for details.
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/667
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk: We believe that some browsers already have
>> prerendering implementations which are not well-specified and may differ
>> from each other. 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. The danger here is that different
>> browsers have different ways to trigger a prerendered page, and prerendered
>> pages behave differently in different browsers.
>>
>> Prerendering is a web-visible behavior, since it involves fetching the
>> page and executing its scripts.
>>
>> Prerendering can depend on UA-specific heuristics. For example, the
>> browser might decide to act on a hint to prerender based on the system
>> load, and the presence of other prerenders. We do not intend to codify
>> heuristics in the specification. A conforming browser might simply ignore
>> all hints to prerender a page.
>>
>> Compatibility risk: Some use cases will need to know whether a page is
>> being prerendered. Ads and analytics are likely examples of this. This
>> feature exposes `document.prerendering` to detect prerendering, but there
>> is a risk of sites that would benefit from using the API, not using it. We
>> believe that this risk is tractable because prerendering has existed in
>> Chrome in the recent past and currently exists in some other browsers. We
>> also intend to add a header to network requests like `Purpose: prefetch` so
>> that origin servers can identify requests for prerendered pages.
>>
>>
>> Gecko: No signal
>>
>>
>> WebKit: No signals, while Safari appears to have some form of
>> prerendering already.
>>
>>
>> Web developers: No signals
>>
>>
>> Other signals: No signals
>>
>>
>>
>> Ergonomics
>>
>> This feature is triggered by the Speculation Rules API:
>> https://chromestatus.com/feature/5740655424831488
>>
>>
>> Activation
>>
>> Developers can use the Speculation Rules API to use the feature. The
>> feature should just work for most existing pages. Developers should be
>> aware of restrictions on prerendering content (they cannot play audio or
>> perform other disruptive behavior, etc). This feature would benefit from
>> good documentation.
>>
>>
>> Security
>>
>> This feature is the first use of the Multiple-Page Architecture, which is
>> a significant change to Chromium's internals. Both MPArch and this feature
>> in particular underwent significant security review. See the design doc for
>> more details.
>>
>> From a web-exposed perspective, the security and privacy concerns are
>> smaller, because this feature is restricted to the same-origin case only.
>>
>>
>> Goals for experimentation
>>
>> To evaluate how the prerendering feature works on real sites before
>> shipping i

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

[Sonia Singla]

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/9cd03b88-bdf7-478f-a0c5-fe08b6cb4467n%40chromium.org.

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

[Sonia Singla]

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/e6f0562b-e02e-47bb-a5b5-4f536b2ead67n%40chromium.org.

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[Daniel Vogelheim]

>
> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so it
> mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned, 0.5%
> of sites set document.domain, 0.05% seem to depend on document.domain, are
> quite high. One thing I didn't quite pick up is what happens if you try to
> set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
>
It does nothing, silently. This matches the behaviour when
Origin-Agent-Cluster is explicitly set to true. From a developer's
perspective, the current default matches explicit-false and the future
default is meant to match explicit-true.

Reference: Step 7 of "The domain setter steps are" of
https://html.spec.whatwg.org/multipage/origin.html#dom-document-domain.

There is also the question of reverse origin trial and enterprise flags. If
> Origin-Agent-Cluster can be set with , then I don't
> see any use for an origin trial since that would be activated the same way.
> An enterprise flag might still be needed though, since that covers
> installations where the client can be configured, but applications can not
> be changed.
>
>
An enterprise policy has been implemented

.
We didn't think a reverse origin trial would make sense, since any site can
already opt-out by setting the Origin-Agent-Cluster header.

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

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[Yoav Weiss]

On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  wrote:

> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so it
> mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned, 0.5%
> of sites set document.domain, 0.05% seem to depend on document.domain, are
> quite high. One thing I didn't quite pick up is what happens if you try to
> set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
> I would be surprised if it didn't behave the same as setting an arbitrary
> expando on `document` - we should be safe there.
>

https://github.com/WICG/origin-agent-cluster#no-op-documentdomain-setter-instead-of-throwing
suggests you're right.

Also - TIL https://developer.mozilla.org/en-US/docs/Glossary/Expando

> There is also the question of reverse origin trial and enterprise flags.
> If Origin-Agent-Cluster can be set with , then I
> don't see any use for an origin trial since that would be activated the
> same way. An enterprise flag might still be needed though, since that
> covers installations where the client can be configured, but applications
> can not be changed.
>
> I'd be surprised if meta http-equiv is supported, as IIUC, the decision on
an agent cluster needs to be made before the document is committed, hence
the opt-in can't be made available to markup.
I'm guessing the same would be true for a deprecation trial (as a result,
there's no difference between one and the header based opt-in).


> /Daniel
> On 2021-12-14 15:06, Daniel Vogelheim wrote:
>
> Contact emails
>
>
> * v...@chromium.org , vogelh...@chromium.org
>  * Specification
>
>
> * Explainer: https://github.com/mikewest/deprecating-document-domain
>  HTML Spec draft:
> https://github.com/whatwg/html/compare/main...otherdaniel:dd
>  * API spec
>
>
> * Yes * Summary
>
>
>
>
>
>
>
> * Change the default behavior of the Origin-Agent-Cluster: header /
> document.domain settability. Presently, pages within Chromium have
> site-keyed agent clusters by default, unless the Origin-Agent-Cluster:
> header is explicitly set to true. This accommodates pages or frames which
> want to access each other's state, despite being on different origins (but
> within a site). This is fine for any pages that wish to do so, but because
> a page *might* set document.domain later on, Chromium currently must use
> site-keyed agent clusters for *all* pages by default even though the
> overwhelming majority of pages do not ever make use of this (mis-)feature.
> In turn, this requires Chromium to use sites as the basis for renderer
> process isolation (via Site Isolation), which exposes origins to same-site
> but cross-origin attacks involving compromised renderer processes or the
> "Spectre" family of side-channel attacks. This proposal changes the default
> behaviour of Origin-Agent-Cluster. From a developer's point of view, the
> new default matches "Origin-Agent-Cluster: ?1". The initial implementation
> will use origin-keyed agent clusters for all (non-opted out) origins,
> without changing how many processes Chromium creates. Over time, we can
> then adapt Chromium's isolation strategy towards origin-keyed processes
> without further affecting web-visible behaviour. The developer-visible
> aspect of this is that for pages with origin-keyed agent clusters,
> document.domain is no longer settable. Thus, we have marked this intent as
> a deprecation. Note that this proposal is about the default. Both modes -
> site-keyed or origin-keyed agent clusters - remain available to any site,
> but origin-keyed agent clusters change from opt-in to opt-out. The current
> behaviour remains available by setting "Origin-Agent-Cluster: ?0". * Blink
> component
>
>
> * Blink>SecurityFeature * TAG review
>
>
> * https://github.com/w3ctag/design-reviews/issues/564
>  (The thread is a bit
> unwieldy, but there do not seem to be open issues.) * Risks:
> Interoperability and Compatibility
>
> * No interoperability risks. *
> Compatibility risk exists, but is fairly small as document.domain is an
> already deprecated feature. We’ve detailed UKM metrics in place and are
> planning to reach out to top users as soon as we’ve LGTMs for the plan.
>
> As Daniel mentioned, I think the compat risk should be considered to be
> higher, despite this being deprecated for a long time.
>
> Current usage of the document.domain: 0.05%
>  of
> page views rely upon document.domain to enable some cross-origin access
> that wasn't otherwise possible. 0.24%
>  of
> page views block same-origin access because only one side sets

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Yoav Weiss]

What are the milestones for the continued experimentation?

On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
wrote:

> Contact emails
>
> nhir...@chromium.org, navigation-...@chromium.org
>
> Explainer
>
> This feature:
> 
> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>
> This trial:
> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>
> Larger project:
> 
> 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>
> Summary
>
> Prerendering loads a web page before it is needed, so that when the actual
> navigation to that page occurs, it can be shown instantly.
>
> This experiment is for the specific case of same-origin prerendering
> triggered by the Speculation Rules API. An earlier, related experiment
> supported prefetching
> 
> using this API. This is a separate experiment that requires its own origin
> trial token.
>
> This experiment has some limitations. See the explainer
> 
> for details.
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> Interoperability risk: We believe that some browsers already have
> prerendering implementations which are not well-specified and may differ
> from each other. 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. The danger here is that different
> browsers have different ways to trigger a prerendered page, and prerendered
> pages behave differently in different browsers.
>
> Prerendering is a web-visible behavior, since it involves fetching the
> page and executing its scripts.
>
> Prerendering can depend on UA-specific heuristics. For example, the
> browser might decide to act on a hint to prerender based on the system
> load, and the presence of other prerenders. We do not intend to codify
> heuristics in the specification. A conforming browser might simply ignore
> all hints to prerender a page.
>
> Compatibility risk: Some use cases will need to know whether a page is
> being prerendered. Ads and analytics are likely examples of this. This
> feature exposes `document.prerendering` to detect prerendering, but there
> is a risk of sites that would benefit from using the API, not using it. We
> believe that this risk is tractable because prerendering has existed in
> Chrome in the recent past and currently exists in some other browsers. We
> also intend to add a header to network requests like `Purpose: prefetch` so
> that origin servers can identify requests for prerendered pages.
>
>
> Gecko: No signal
>
>
> WebKit: No signals, while Safari appears to have some form of prerendering
> already.
>
>
> Web developers: No signals
>
>
> Other signals: No signals
>
>
>
> Ergonomics
>
> This feature is triggered by the Speculation Rules API:
> https://chromestatus.com/feature/5740655424831488
>
>
> Activation
>
> Developers can use the Speculation Rules API to use the feature. The
> feature should just work for most existing pages. Developers should be
> aware of restrictions on prerendering content (they cannot play audio or
> perform other disruptive behavior, etc). This feature would benefit from
> good documentation.
>
>
> Security
>
> This feature is the first use of the Multiple-Page Architecture, which is
> a significant change to Chromium's internals. Both MPArch and this feature
> in particular underwent significant security review. See the design doc for
> more details.
>
> From a web-exposed perspective, the security and privacy concerns are
> smaller, because this feature is restricted to the same-origin case only.
>
>
> Goals for experimentation
>
> To evaluate how the prerendering feature works on real sites before
> shipping it by default. This is a large feature and it's risky to ship
> without trying it first on real sites. We will be evaluating performance,
> stability, and correctness, and any other feedback the sites have when they
> use this feature.
>
>
> Reason this experiment is being extended
>
> The sites 

Re: [blink-dev] Intent to Ship: Window Controls Overlay for Installed Desktop Web Apps

['Sonja Laurila' via blink-dev]

Hey,

This feature has also been implemented for ChromeOS and I was wondering if 
it needs a separate I2S or if it should go with this same one?

Most of the WML implementation worked for CrOS already just by adding CrOS 
to the about flag definition and to the directive conditions, e.g. reading 
the CSS attributes etc. The missing parts of the CrOS implementation can be 
found on this CL: https://crrev.com/c/3204967/ (was later enabled for 
LaCrOS also: https://crrev.com/c/3240745). The implementation is fairly 
similar to the implementation for W&L. The only missing piece of the puzzle 
for CrOS atm is that it is still not included in 
runtime_enabled_features.json5 

.

So just to follow the processes, what would be the next steps to get the 
CrOS side ship as well? :)

Best regards,
Sonja Laurila



On Thursday, December 9, 2021 at 9:58:02 PM UTC+2 mike...@chromium.org 
wrote:

> Great! 
>
> LGTM3
>
> On 12/9/21 2:27 PM, Diego González wrote:
>
> Hola Mike,  
>
> That is a very valid point. We've renamed the boundingRect attribute to 
> titlebarAreaRect to remove any ambiguity regarding the area being 
> referenced. 
>
> The change has now been merged. Thanks!
>
> Diego
>
>
> On Thursday, 9 December 2021 at 14:33:09 UTC mike...@chromium.org wrote:
>
>> I did, but ran out of time before sending an email last night. :)
>>
>> I see that getBoundingClientRect was renamed to getTitleBarRect 
>> ,
>>  
>> would it make sense to update the boundingRect attribute on the geometry 
>> change event as well, or do you think boundingRect is still the right name?
>>
>> On 12/9/21 4:29 AM, Mike West wrote:
>>
>> I believe @Mike Taylor had some questions around spelling decisions in 
>> the API in our last API owners meeting. Mike, did you have a chance to look 
>> into that more deeply? 
>>
>> -mike
>>
>>
>> On Wed, Dec 8, 2021 at 11:00 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM2
>>>
>>> On Tue, Dec 7, 2021 at 2:36 AM Yoav Weiss  wrote:
>>>
 *LGTM1* 
 Thanks for driving those discussions and making the spec interoperable 
 in the process.

 On Tuesday, December 7, 2021 at 11:07:21 AM UTC+1 Diego González wrote:

> Just as a heads up, all concerns have been addressed and the latest 
> version of the spec is in a state where I believe we are all happy with. 
> Thanks for all the feedback and comments!
>
> On Wednesday, 1 December 2021 at 18:26:03 UTC luig...@microsoft.com 
> wrote:
>
>> There is a PR waiting to be merged that adds a note about developers 
>> using reasonable fallbacks on unsupported browsers, I will let you know 
>> once it gets merged. 
>>
>> On Wednesday, 1 December 2021 at 17:29:03 UTC Diego González wrote:
>>
>>> YUC. 😉
>>>
>>> If a developer has used the environmental variables and the web app 
>>> gets installed in browser that does not support it (then it is a 
>>> parallel 
>>> universe because Firefox nor Safari nor other desktop browser supports 
>>> this 
>>> *kidding*) then they can specify reasonable fallback values because 
>>> they 
>>> value progressive enhancement and responsive design. I will add a note 
>>> about this to the spec, if you think it is necessary.  
>>>
>>> Lack of WCO support and lack of user opt in do not look the same. In 
>>> a supported browser both the env variables and the JS object in 
>>> navigator 
>>> exist even if the feature is turned off. 
>>>
>>> On Wednesday, 1 December 2021 at 11:11:03 UTC yoav...@chromium.org 
>>> wrote:
>>>
 On Tuesday, November 30, 2021 at 6:48:07 PM UTC+1 Diego González 
 wrote:

> Hola Yoav, 
>
> I wanted to add that we implemented the concept of a 
> display-override to control the fallback of display modes. For non 
> supported browsers, developers can also specify the display-override 
> and 
> even if this is not supported it will default to the display value in 
> the 
> manifest file.  
>
>
>
> On Monday, 29 November 2021 at 18:29:41 UTC Diego González wrote:
>
>> Hola Yoav,  
>>
>> For non supported browsers there are 2 options: 
>>
>>- env variables take the specified default value by 
>>developers (if devs enable WCO). 
>>
>>
 So IIUC developers are supposed to use the env variables with 
 reasonable fallback values for non-supporting browsers? Is that advice 
 captured/documented somewhere?