date:20211007

LGTM3 (I sent an LGTM1 yesterday but as a direct mail, doh)

On 2021-10-08 06:18, Yoav Weiss wrote:

LGTM2

On Fri, Oct 8, 2021 at 2:40 AM Chris Harrelson
wrote:

LGTM1

On Thu, Oct 7, 2021 at 10:22 AM 'Shu-yu Guo' via blink-dev
wrote:

Contact emails

s...@chromium.org

Explainer

https://github.com/tc39/proposal-array-find-from-last

Specification

https://tc39.es/proposal-array-find-from-last/index.html

Summary

This is a Stage 3 TC39 proposal that adds the methods findLast
and findLastIndex to Array.prototype and the various
TypedArray.prototypes. These methods are the "from the end"
versions of find and findIndex.

Blink component

Blink>JavaScript>Language

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Adding any new methods to Array.prototype runs the risk of web
incompatibility due to breaking old libraries. Rollout will
need to be monitored.

Gecko: Positive This is Stage 3 in TC39

WebKit: Positive This is Stage 3 in TC39

Web developers: Positive
(https://twitter.com/mgechev/status/1432199126570131459?s=20)

Debuggability

It is a new prototype method, so can be debugged like any
other prototype method.

Is this feature fully tested by web-platform-tests

Yes, in test262

Flag name

--harmony-array-find-last

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

DevTrial on desktop 94

DevTrial on android 94

DevTrial on Webview 94

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5693639729610752

This intent message was generated by Chrome Platform Status
.
--
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e8M7%3DfAX%2BfwmAzEY_bngPrJPzrD4sgctRoq-7TV46tCUg%40mail.gmail.com

--
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_F5dw-Qg1tZ12kW8UQwQWg1w1PuFjLvfgwQ6ixoc%2B7vg%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/CAL5BFfVNFPD6Dmim%3D0grmdVkSfRMm_XJQ3%3D-Hf5pEb8%2BZhv09g%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/ceadc5cd-8199-4069-c496-9090a9d41b96%40gmail.com.

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

*LGTM2* to ship without certificate fingerprints. It'd be great to ensure
public documentation for this includes the fallback mechanism we want
developers to implement. (both in the web.dev article and future MDN
documentation).

On Thu, Oct 7, 2021 at 9:19 PM Mike West  wrote:

> LGTM1, to ship this without the certificate fingerprint portion of 349
> discussed above. There's still some conversation to be had there, and I
> think it's worth finishing the discussion before shipping it since it's
> quite clearly separable. I'd suggest shipping that as a separate intent if
> that's the way the conversation goes.
>
> I appreciate Philip's comments as well, and I'm happy to see that y'all
> have already put up a PR to add CSP support. I think we should probably
> alter the CSP spec to make your PR more clear, but that's not something I
> think we ought to block on.
>
> I'll also note that the TAG just put this on their agenda for this coming
> week. If concerns are raised there, I would appreciate us addressing them
> thoroughly before shipping.
>
> -mike
>
>
> On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
 wrote:

> Thank you!
>
> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
> wrote:
>
>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
 wrote:

> Hi Philip,
>
> Sorry for the belated reply. Comments inline:
>
> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of
>> questions, but am pretty convinced we should ship this, it's just a 
>> matter
>> of what things need to block that, and what things can be left until 
>> later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
>> yhir...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>> multiple issues filed by other browser vendors. Are any of the 
>> remaining
>> issues ones that could change the API's shape or behavior? It would 
>> be good
>> to resolve any such issues, since they won't be possible to address 
>> once
>> the API is locked in by sites depending on it.
>>
>>
> I believe we've addressed issues that may require breaking
> changes. You can see open
> /closed
>  issues
> for the initial launch (this intent).  I shared our plan
> 
>  at a WG meeting in May
> 
>  and
> we've been working to find and resolve such issues since then.
>

 I see, creating a milestone for this is really handy! Are the
 remaining issue in https://github.com/w3c/webtransport/milestone/1
 not blocking then, even issue #349
 ?

>>>
>>> *Except for issue #349* we have consensus on discussions. As Victor
>>> commented in this thread, we can ship WebTransport *except for *
>>> customeCertificationHashes
>>> 
>>>  if
>>> needed.
>>>
>>
>> If custom certificates is a nice-to-have then shipping without it
>> seems fine to me. That would mean removing serverCertificateHashes from 
>> the
>> dictionary, right? I ask because the spec also says something
>> about NotSupportedError when the protocol doesn't support it, but it 
>> seems
>> better to behave as if the feature doesn't exis

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

2021-10-07 Thread traci phebus

Guys i guess i don't deserve to have  this , because I don't really 
understand what it is and how it works, any tips?
On Thursday, October 7, 2021 at 12:27:56 PM UTC-7 Chris Harrelson wrote:

> LGTM3
>
> On Thu, Oct 7, 2021 at 3:34 AM 'Munira Tursunova' via blink-dev <
> blin...@chromium.org> wrote:
>
>> > Looking at the font-synthesis-* tests in 
>> https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
>>  
>> many pass in Firefox and Safari, but not all of them. Do all of these tests 
>> pass with the implementation now in Blink?
>>
>> Yes, they do. Actually these tests had been added with the Chrome 
>> implementation and they are responsible for longhands for font-synthesis 
>> property which is not supported by other browsers yet.
>>
>> > In the chromestatus entry I see "There are additional tests for system 
>> fonts with platform specific results, so we keep those as internal tests." 
>> Is the problem there that the tests rely on system fonts, or that there are 
>> platform-specific results? The latter is possible with WPT using the 
>> regular third_party/blink/web_tests/platform/ expectations. For system 
>> fonts, perhaps these tests could be written to pass if the fonts aren't 
>> present? If these are testharness.js tests, 
>> https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
>>  
>> might be a path forward.
>>
>> Yes, they rely on particular aspects of which fonts are available on the 
>> system. As the font-synthesis property, when applied to system fonts, is 
>> closely connected to font matching and identifying whether a true bold / 
>> true italic variant exists, it’d be hard to make those flexible in terms of 
>> a default passing when the font does not exist. They are ref tests for that 
>> purpose.
>>
>> >Also, looking at 
>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
>>  
>> I wonder if small-caps is going to be supported? If that table is correct 
>> it's not supported by Safari and it's only just now coming to Firefox.
>>
>> Yes, small-caps support was also implemented in Blink (as longhand and as 
>> part of the shorthand). Also I’m not sure if that table is correct because 
>> Safari also supports ‘small-caps’ (only as a keyword in the shorthand) . 
>> They just have a bug in ref for this test: 
>> https://wpt.fyi/results/css/css-fonts/font-synthesis-06.html?label=experimental&label=master&aligned
>>
>> On Thursday, October 7, 2021 at 11:28:57 AM UTC+3 Philip Jägenstedt wrote:
>>
>>> It's great to see this feature getting ready to ship, it's one of a 
>>> relatively small number of features already supported by Firefox and Safari 
>>> but not by Chromium browsers, so it's been on my radar :)
>>>
>>> I just have a few questions.
>>>
>>> Looking at the font-synthesis-* tests in 
>>> https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
>>>  
>>> many pass in Firefox and Safari, but not all of them. Do all of these tests 
>>> pass with the implementation now in Blink?
>>>
>>> In the chromestatus entry I see "There are additional tests for system 
>>> fonts with platform specific results, so we keep those as internal tests." 
>>> Is the problem there that the tests rely on system fonts, or that there are 
>>> platform-specific results? The latter is possible with WPT using the 
>>> regular third_party/blink/web_tests/platform/ expectations. For system 
>>> fonts, perhaps these tests could be written to pass if the fonts aren't 
>>> present? If these are testharness.js tests, 
>>> https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
>>>  
>>> might be a path forward.
>>>
>>> Also, looking at 
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
>>>  
>>> I wonder if small-caps is going to be supported? If that table is correct 
>>> it's not supported by Safari and it's only just now coming to Firefox.
>>>
>>> On Thu, Oct 7, 2021 at 9:59 AM Daniel Bratell  wrote:
>>>
 LGTM2

 /Daniel
 On 2021-10-07 09:08, Yoav Weiss wrote:

 *LGTM1*
 Thanks for working on this!! This seems like an important thing to 
 catch up on! 



 On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev <
 blin...@chromium.org> wrote:

> Contact emails 
>
> moo...@google.com, dr...@chromium.org
>
> Explainer 
>
> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis
>
> Specification 
>
> https://drafts.csswg.org/css-fonts/#font-synthesis
>
> Summary 
>
> The font-synthesis CSS property controls whether user agents are 
> allowed to synthesize oblique, bold and small-caps font faces when a font 
> family lacks oblique, bold and small-caps faces, respectively.
>
>
> Blink component 
>
> Blink>Fon

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

LGTM2

On Fri, Oct 8, 2021 at 2:40 AM Chris Harrelson 
wrote:

> LGTM1
>
> On Thu, Oct 7, 2021 at 10:22 AM 'Shu-yu Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails...@chromium.org
>>
>> Explainerhttps://github.com/tc39/proposal-array-find-from-last
>>
>> Specificationhttps://tc39.es/proposal-array-find-from-last/index.html
>>
>> Summary
>>
>> This is a Stage 3 TC39 proposal that adds the methods findLast and
>> findLastIndex to Array.prototype and the various TypedArray.prototypes.
>> These methods are the "from the end" versions of find and findIndex.
>>
>>
>> Blink componentBlink>JavaScript>Language
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Adding any new methods to Array.prototype runs the risk of web
>> incompatibility due to breaking old libraries. Rollout will need to be
>> monitored.
>>
>>
>> Gecko: Positive This is Stage 3 in TC39
>>
>> WebKit: Positive This is Stage 3 in TC39
>>
>> Web developers: Positive (
>> https://twitter.com/mgechev/status/1432199126570131459?s=20)
>>
>>
>> Debuggability
>>
>> It is a new prototype method, so can be debugged like any other prototype
>> method.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes, in test262
>>
>> Flag name--harmony-array-find-last
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=11990
>>
>> Estimated milestones
>> DevTrial on desktop 94
>> DevTrial on android 94
>> DevTrial on Webview 94
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5693639729610752
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e8M7%3DfAX%2BfwmAzEY_bngPrJPzrD4sgctRoq-7TV46tCUg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_F5dw-Qg1tZ12kW8UQwQWg1w1PuFjLvfgwQ6ixoc%2B7vg%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/CAL5BFfVNFPD6Dmim%3D0grmdVkSfRMm_XJQ3%3D-Hf5pEb8%2BZhv09g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: interactionID in Event Timing

LGTM1

On Thu, Oct 7, 2021 at 1:15 PM Nicolás Peña  wrote:

> We do want to make it easier to track asynchronous work, and I think this
> will require something such as `measureUntil`. Once we implement that, it
> would be plausible to extend EventTiming to include that
> developer-annotated async duration. It would also make it possible to
> annotate any User Timing entries with the relevant interactionID. We're
> also thinking about heuristics to track asynchronous work automatically in
> a meaningful way. Without this, the annotations might be too noisy. For
> instance, a user input can trigger a long animation, and having the async
> duration be arbitrarily long or having the marks inside that animation be
> indefinitely tied to that interactionID seems odd.
>
> On Thu, Oct 7, 2021 at 2:15 PM Alex Russell 
> wrote:
>
>> So this design looks pretty good in terms of auto-generating a uniform ID
>> for pre-baked events, but I'm curious about how it will interact with
>> asynchronous tasks generated from within task callbacks, and how a
>> user-timing mark from within one of these scopes might inherit the
>> interactionID?
>>
>>
>> On Thursday, October 7, 2021 at 7:17:01 AM UTC-7 Nicolás Peña wrote:
>>
>>> On Thursday, October 7, 2021 at 1:58:59 AM UTC-4 Yoav Weiss wrote:
>>>
 On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña  wrote:

> Contact emails
>
> n...@chromium.org, hbs...@chromium.org
>
> Explainer
>
> https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777
>
> Specification
>
>
> https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid
>
> Summary
>
> Developers currently use the Event Timing API to gather performance
> data about events they care about. However, it is currently hard to link
> events that correspond to the same user interaction. For instance, when a
> user taps, many events are generated, such as pointerdown, mousedown,
> pointerup, mouseup, and click. The interactionID enables developers to 
> link
> multiple PerformanceEventTiming entries when they correspond to the same
> user interaction.
>
> Blink component
>
> Blink>PerformanceAPIs
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/670
>
> TAG review status
>
> Open
>
> Risks
> Interoperability and Compatibility
>
> The main interop risk is that this feature does not become implemented
> in other browsers. This is an attribute in a performance feature so even 
> if
> this is not implemented there websites using this feature should not break
> in any way.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/283) Updated
> the Event Timing issue to note this addition.
>
> WebKit: Negative (
> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html)
> This is a negative on Event Timing as a whole, so we consider this to be
> negative for this feature in particular.
>
> Web developers: No signals. We presented this to WebPerf WG
> https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html
>
>
 My read of the minutes is that there was a developer need for grouping
 interactions, but even more demand (at least from the folks in the room)
 for scroll grouping. Is that accurate?

>>>
>>> Yea, that is accurate.
>>>
>>>


>
> Ergonomics
>
> N/A
>
>
> Activation
>
> Seems tricky to impossible to polyfill, so developers would need to
> use the API in order to obtain the more accurate data.
>
>
> Security
>
> One consideration was whether it is ok to expose the number of
> interactions that have occurred in the page. This is already observable 
> via
> event handlers. Cross-origin events are not exposed.
>
>
> Debuggability
>
> Use PerformanceObserver in the console. We don't have concrete plans
> to add Event Timing support in DevTools yet, but maybe in the future. Lab
> tools in general do not currently have great support for user inputs.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html
>
>
> Flag name
>
> InteractionId
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1236758
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1245771
>
> Estimated milestones
>

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

LGTM1

On Thu, Oct 7, 2021 at 10:22 AM 'Shu-yu Guo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails...@chromium.org
>
> Explainerhttps://github.com/tc39/proposal-array-find-from-last
>
> Specificationhttps://tc39.es/proposal-array-find-from-last/index.html
>
> Summary
>
> This is a Stage 3 TC39 proposal that adds the methods findLast and
> findLastIndex to Array.prototype and the various TypedArray.prototypes.
> These methods are the "from the end" versions of find and findIndex.
>
>
> Blink componentBlink>JavaScript>Language
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Adding any new methods to Array.prototype runs the risk of web
> incompatibility due to breaking old libraries. Rollout will need to be
> monitored.
>
>
> Gecko: Positive This is Stage 3 in TC39
>
> WebKit: Positive This is Stage 3 in TC39
>
> Web developers: Positive (
> https://twitter.com/mgechev/status/1432199126570131459?s=20)
>
>
> Debuggability
>
> It is a new prototype method, so can be debugged like any other prototype
> method.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes, in test262
>
> Flag name--harmony-array-find-last
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=11990
>
> Estimated milestones
> DevTrial on desktop 94
> DevTrial on android 94
> DevTrial on Webview 94
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5693639729610752
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e8M7%3DfAX%2BfwmAzEY_bngPrJPzrD4sgctRoq-7TV46tCUg%40mail.gmail.com
> 
> .
>

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

Re: [blink-dev] Intent to Ship: interactionID in Event Timing

2021-10-07 Thread Nicolás Peña

We do want to make it easier to track asynchronous work, and I think this
will require something such as `measureUntil`. Once we implement that, it
would be plausible to extend EventTiming to include that
developer-annotated async duration. It would also make it possible to
annotate any User Timing entries with the relevant interactionID. We're
also thinking about heuristics to track asynchronous work automatically in
a meaningful way. Without this, the annotations might be too noisy. For
instance, a user input can trigger a long animation, and having the async
duration be arbitrarily long or having the marks inside that animation be
indefinitely tied to that interactionID seems odd.

On Thu, Oct 7, 2021 at 2:15 PM Alex Russell 
wrote:

> So this design looks pretty good in terms of auto-generating a uniform ID
> for pre-baked events, but I'm curious about how it will interact with
> asynchronous tasks generated from within task callbacks, and how a
> user-timing mark from within one of these scopes might inherit the
> interactionID?
>
>
> On Thursday, October 7, 2021 at 7:17:01 AM UTC-7 Nicolás Peña wrote:
>
>> On Thursday, October 7, 2021 at 1:58:59 AM UTC-4 Yoav Weiss wrote:
>>
>>> On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña  wrote:
>>>
 Contact emails

 n...@chromium.org, hbs...@chromium.org

 Explainer

 https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777

 Specification

 https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid

 Summary

 Developers currently use the Event Timing API to gather performance
 data about events they care about. However, it is currently hard to link
 events that correspond to the same user interaction. For instance, when a
 user taps, many events are generated, such as pointerdown, mousedown,
 pointerup, mouseup, and click. The interactionID enables developers to link
 multiple PerformanceEventTiming entries when they correspond to the same
 user interaction.

 Blink component

 Blink>PerformanceAPIs

 TAG review

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

 TAG review status

 Open

 Risks
 Interoperability and Compatibility

 The main interop risk is that this feature does not become implemented
 in other browsers. This is an attribute in a performance feature so even if
 this is not implemented there websites using this feature should not break
 in any way.

 Gecko: No signal (
 https://github.com/mozilla/standards-positions/issues/283) Updated the
 Event Timing issue to note this addition.

 WebKit: Negative (
 https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html)
 This is a negative on Event Timing as a whole, so we consider this to be
 negative for this feature in particular.

 Web developers: No signals. We presented this to WebPerf WG
 https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html

>>> My read of the minutes is that there was a developer need for grouping
>>> interactions, but even more demand (at least from the folks in the room)
>>> for scroll grouping. Is that accurate?
>>>
>>
>> Yea, that is accurate.
>>
>>
>>>
>>>

 Ergonomics

 N/A

 Activation

 Seems tricky to impossible to polyfill, so developers would need to use
 the API in order to obtain the more accurate data.

 Security

 One consideration was whether it is ok to expose the number of
 interactions that have occurred in the page. This is already observable via
 event handlers. Cross-origin events are not exposed.

 Debuggability

 Use PerformanceObserver in the console. We don't have concrete plans to
 add Event Timing support in DevTools yet, but maybe in the future. Lab
 tools in general do not currently have great support for user inputs.

 Is this feature fully tested by web-platform-tests

 ?

 https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html

 Flag name

 InteractionId

 Requires code in //chrome?

 False

 Tracking bug

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

 Launch bug

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

 Estimated milestones

 96

 Link to entry on the Chrome Platform Status

 https://www.chromestatus.com/feature/5674224959094784

 This intent message was generated by Chrome Platform Status
 .
>>>

Re: [blink-dev] Intent to Ship: URL Protocol Handler Registration for PWAs

LGTM3 once the spec PR lands.

I agree with your reasoning about why an email to webkit-dev would not be
productive.

On Thu, Oct 7, 2021 at 12:40 PM Yoav Weiss  wrote:

> LGTM2
>
> On Thu, Oct 7, 2021 at 9:28 PM Mike West  wrote:
>
>> LGTM1. The UX treatment ran through internal security/privacy review, and
>> doesn't create risk above and beyond the existing JavaScript API, which we
>> ship currently and accept.
>>
>> -mike
>>
>>
>> On Mon, Oct 4, 2021 at 10:56 PM Diego González  wrote:
>>
>>> Hola Chris,
>>>
>>> 1. We have applied for signals through the methods specified in the
>>> document linked, for reference:
>>> * Gecko: https://github.com/mozilla/standards-positions/issues/340
>>> * I believe there is no entry in the webkit-dev list, although there is
>>> the bug file in webkit bug tracker. (I can add the thread in the mailing
>>> list if it is necessary for the process, but as a fellow webkit engineer
>>> told me, if there is no interaction in the whole standard process it means
>>> there is not interest in the feature.)
>>>
>>> 2. I'll work on landing these changes to manifest incubations for the
>>> time being, that way we can unblock the process since I do not expect to
>>> get any signal from another engine any time soon.
>>>
>>> 3. Overall the summary is positive, with no actionable feedback. A few
>>> "lgtm please ship" and "if we can't use this we'll have to use Electron".
>>>
>>> Regards
>>>
>>> Diego
>>>
>>> On Thursday, 30 September 2021 at 20:30:51 UTC+1 Chris Harrelson wrote:
>>>
 Hi, a few points.

 1. Please file for signals via the mechanism at bit.ly/blink-signals.
 2. Ok if we block approval on landing the spec PR?
 3. Can you send us a summary of feedback received during the Origin
 Trial?

 Thanks,
 Chris


 On Wed, Sep 29, 2021 at 9:25 AM 'Diego Gonzalez' via blink-dev <
 blin...@chromium.org> wrote:

> Contact emails
>
> samue...@microsoft.com, mjac...@microsoft.com, luig...@microsoft.com,
> dmu...@chromium.org
>
>
> Explainer
>
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md
>
> https://web.dev/url-protocol-handler/
>
>
> Specification
>
>
> https://pr-preview.s3.amazonaws.com/w3c/manifest/pull/972.html#protocol_handlers-member
>
>
> Design docs
>
>
> https://docs.google.com/document/d/1NHlWLjAPZ-dyxcz3AoTWibeerDeHW7Vqrx6FmhB0XmE
> Summary
>
> Enable web applications to register themselves as handlers of custom
> URL protocols/schemes using their installation manifest.
> Blink component
>
> UI>Browser>WebAppInstalls
> 
> Search tags
>
> protocol , web app
> , protocol handlers
> , custom
> schemes 
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/482
> TAG review status
>
> Issues addressed, resolution: satisfied.
> Risks Interoperability and Compatibility
>
> Low; manifest elements will be ignored if unsupported by the client.
>
> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1635272
> )
>
> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=211401)
>
> Web developers: Positive (
> https://twitter.com/search?q=url%3Ahttps%3A%2F%2Fweb.dev%2Furl-protocol-handler%2F&src=typed_query&f=live
> )
> Security
>
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/URLProtocolHandler/explainer.md#security-considerations
>
>
> Debuggability Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes -
> https://chromium-review.googlesource.com/c/chromium/src/+/3166820
>
>
> DevTrial instructions
>
>
> https://web.dev/url-protocol-handler/#enabling-via-about:flags-or-edge:flags
> Flag name
>
> #enable-desktop-pwas-protocol-handling
>
>
> Requires code in //chrome?
>
> Yes
> Tracking bug
>
> https://crbug.com/1019239
>
>
> Launch bug
>
> https://crbug.com/1063658
>
>
> Sample links
>
> https://protocol-handler.glitch.me/
>
> https://fabiorocha.github.io/pwa
>
>
> Estimated milestones
>
> OriginTrial desktop last
>
> 95
>
> OriginTrial desktop first
>
> 92
>
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5151703944921088
>
>
> Lin

Re: [blink-dev] Intent to Ship: URL Protocol Handler Registration for PWAs

LGTM2

On Thu, Oct 7, 2021 at 9:28 PM Mike West  wrote:

> LGTM1. The UX treatment ran through internal security/privacy review, and
> doesn't create risk above and beyond the existing JavaScript API, which we
> ship currently and accept.
>
> -mike
>
>
> On Mon, Oct 4, 2021 at 10:56 PM Diego González  wrote:
>
>> Hola Chris,
>>
>> 1. We have applied for signals through the methods specified in the
>> document linked, for reference:
>> * Gecko: https://github.com/mozilla/standards-positions/issues/340
>> * I believe there is no entry in the webkit-dev list, although there is
>> the bug file in webkit bug tracker. (I can add the thread in the mailing
>> list if it is necessary for the process, but as a fellow webkit engineer
>> told me, if there is no interaction in the whole standard process it means
>> there is not interest in the feature.)
>>
>> 2. I'll work on landing these changes to manifest incubations for the
>> time being, that way we can unblock the process since I do not expect to
>> get any signal from another engine any time soon.
>>
>> 3. Overall the summary is positive, with no actionable feedback. A few
>> "lgtm please ship" and "if we can't use this we'll have to use Electron".
>>
>> Regards
>>
>> Diego
>>
>> On Thursday, 30 September 2021 at 20:30:51 UTC+1 Chris Harrelson wrote:
>>
>>> Hi, a few points.
>>>
>>> 1. Please file for signals via the mechanism at bit.ly/blink-signals.
>>> 2. Ok if we block approval on landing the spec PR?
>>> 3. Can you send us a summary of feedback received during the Origin
>>> Trial?
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>> On Wed, Sep 29, 2021 at 9:25 AM 'Diego Gonzalez' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails

 samue...@microsoft.com, mjac...@microsoft.com, luig...@microsoft.com,
 dmu...@chromium.org


 Explainer


 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md

 https://web.dev/url-protocol-handler/


 Specification


 https://pr-preview.s3.amazonaws.com/w3c/manifest/pull/972.html#protocol_handlers-member


 Design docs


 https://docs.google.com/document/d/1NHlWLjAPZ-dyxcz3AoTWibeerDeHW7Vqrx6FmhB0XmE
 Summary

 Enable web applications to register themselves as handlers of custom
 URL protocols/schemes using their installation manifest.
 Blink component

 UI>Browser>WebAppInstalls
 
 Search tags

 protocol , web app
 , protocol handlers
 , custom
 schemes 
 TAG review

 https://github.com/w3ctag/design-reviews/issues/482
 TAG review status

 Issues addressed, resolution: satisfied.
 Risks Interoperability and Compatibility

 Low; manifest elements will be ignored if unsupported by the client.

 Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1635272)

 WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=211401)

 Web developers: Positive (
 https://twitter.com/search?q=url%3Ahttps%3A%2F%2Fweb.dev%2Furl-protocol-handler%2F&src=typed_query&f=live
 )
 Security


 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/URLProtocolHandler/explainer.md#security-considerations


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

 Yes - https://chromium-review.googlesource.com/c/chromium/src/+/3166820



 DevTrial instructions


 https://web.dev/url-protocol-handler/#enabling-via-about:flags-or-edge:flags
 Flag name

 #enable-desktop-pwas-protocol-handling


 Requires code in //chrome?

 Yes
 Tracking bug

 https://crbug.com/1019239


 Launch bug

 https://crbug.com/1063658


 Sample links

 https://protocol-handler.glitch.me/

 https://fabiorocha.github.io/pwa


 Estimated milestones

 OriginTrial desktop last

 95

 OriginTrial desktop first

 92




 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5151703944921088


 Links to previous Intent discussions

 Intent to prototype:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/x4Ev_l9Oj2U/m/6bGPs7MVCwAJ

 Ready for Trial:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/GbTdEVNPhng

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

Re: [blink-dev] Intent to Implement and Ship: Allow simple Range header values without preflight

LGTM2

On Thursday, October 7, 2021 at 9:31:00 PM UTC+2 Mike West wrote:

> LGTM1.
>
> This seems correct to me from a behavior perspective, and I'm comfortable 
> considering this to be small enough to avoid explicit signal requirements, 
> and to accept the fact that it's landed in the spec as being Good Enough.
>
> -mike
>
>
> On Thu, Oct 7, 2021 at 2:12 PM Yoav Weiss  wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 11:58 AM Rayan Kanso  
>> wrote:
>>
>>> Can we ask WebKit folks for a signal?
>>>
>>>
>>> There's this bug  filed 
>>> against WebKit. I'm not aware of any other channels to get feedback.
>>>
>>
>> https://bit.ly/blink-signals
>>  
>>
>>>
>>> On Thu, Oct 7, 2021 at 8:24 AM Yoav Weiss  
>>> wrote:
>>>


 On Wed, Oct 6, 2021 at 10:22 PM Mike Taylor  
 wrote:

> On 10/5/21 6:50 AM, Rayan Kanso wrote:
>
> Contact emails rayank...@chromium.org, jakearchib...@chromium.org
>
> Specification https://fetch.spec.whatwg.org/ 
> Diff: https://github.com/whatwg/fetch/pull/1312
>
> Summary 
>
> Allows requests with simple range headers to go through without 
> preflight. CORS requests will be able to use the Range header in limited 
> ways (having only one valid range) without triggering a preflight.
>
> Blink component Blink>SecurityFeature>CORS 
> 
>
> TAG review Not applicable - this is a simple amendment that does not 
> require an architectural review.
>
> Risks 
>
> Interoperability and Compatibility 
> Gecko: Positive 
> 
>
>
 Also, this doesn't count as a positive Mozilla position. I agree it's a 
 good signal, and am not sure we need to file for an official position 
 though. 

>
>
> WebKit: No signal
>
> Can we ask WebKit folks for a signal?
>
>
> Web developers: No signal
>
>
> Debuggability N/A
>
> Is this feature fully tested by web-platform-tests 
> 
> ? https://github.com/web-platform-tests/wpt/pull/31058
>
> Flag name N/A
>
> Requires code in //chrome? False
>
> Launch bug 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1255711
>
> Estimated milestones 
>
> M96/M97
>
> Link to entry on the Chrome Platform Status 
> https://chromestatus.com/feature/5652396366626816
> -- 
> 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/CAAe2mZ1N0Oqz%3DVgEm%2BFQdJBVJCQbG%3Dv-6aO_JqRzm-9uBeQ%3Dfg%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/83e97b2b-cad3-07fc-747e-24a786b89ccd%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/CAL5BFfXjEvYT0OP%3Df1U0sZ7cAcrKx9LYWyVS3GEUv4rnqRx3dw%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/0bf72a14-7ff5-4898-98d1-4b9fdd19ab53n%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Allow simple Range header values without preflight

LGTM1.

This seems correct to me from a behavior perspective, and I'm comfortable
considering this to be small enough to avoid explicit signal requirements,
and to accept the fact that it's landed in the spec as being Good Enough.

-mike


On Thu, Oct 7, 2021 at 2:12 PM Yoav Weiss  wrote:

>
>
> On Thu, Oct 7, 2021 at 11:58 AM Rayan Kanso 
> wrote:
>
>> Can we ask WebKit folks for a signal?
>>
>>
>> There's this bug  filed
>> against WebKit. I'm not aware of any other channels to get feedback.
>>
>
> https://bit.ly/blink-signals
>
>
>>
>> On Thu, Oct 7, 2021 at 8:24 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Wed, Oct 6, 2021 at 10:22 PM Mike Taylor 
>>> wrote:
>>>
 On 10/5/21 6:50 AM, Rayan Kanso wrote:

 Contact emails rayank...@chromium.org, jakearchib...@chromium.org

 Specification https://fetch.spec.whatwg.org/
 Diff: https://github.com/whatwg/fetch/pull/1312

 Summary

 Allows requests with simple range headers to go through without
 preflight. CORS requests will be able to use the Range header in limited
 ways (having only one valid range) without triggering a preflight.

 Blink component Blink>SecurityFeature>CORS
 

 TAG review Not applicable - this is a simple amendment that does not
 require an architectural review.

 Risks

 Interoperability and Compatibility
 Gecko: Positive
 


>>> Also, this doesn't count as a positive Mozilla position. I agree it's a
>>> good signal, and am not sure we need to file for an official position
>>> though.
>>>


 WebKit: No signal

 Can we ask WebKit folks for a signal?


 Web developers: No signal


 Debuggability N/A

 Is this feature fully tested by web-platform-tests
 
 ? https://github.com/web-platform-tests/wpt/pull/31058

 Flag name N/A

 Requires code in //chrome? False

 Launch bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1255711

 Estimated milestones

 M96/M97

 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5652396366626816
 --
 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/CAAe2mZ1N0Oqz%3DVgEm%2BFQdJBVJCQbG%3Dv-6aO_JqRzm-9uBeQ%3Dfg%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/83e97b2b-cad3-07fc-747e-24a786b89ccd%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/CAL5BFfXjEvYT0OP%3Df1U0sZ7cAcrKx9LYWyVS3GEUv4rnqRx3dw%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/CAKXHy%3Dco2KaiwRG%2Be%2BZ9W0G%3DaivoRCvzUmf1U__N%2BrjMwmmhEQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: URL Protocol Handler Registration for PWAs

LGTM1. The UX treatment ran through internal security/privacy review, and
doesn't create risk above and beyond the existing JavaScript API, which we
ship currently and accept.

-mike


On Mon, Oct 4, 2021 at 10:56 PM Diego González  wrote:

> Hola Chris,
>
> 1. We have applied for signals through the methods specified in the
> document linked, for reference:
> * Gecko: https://github.com/mozilla/standards-positions/issues/340
> * I believe there is no entry in the webkit-dev list, although there is
> the bug file in webkit bug tracker. (I can add the thread in the mailing
> list if it is necessary for the process, but as a fellow webkit engineer
> told me, if there is no interaction in the whole standard process it means
> there is not interest in the feature.)
>
> 2. I'll work on landing these changes to manifest incubations for the time
> being, that way we can unblock the process since I do not expect to get any
> signal from another engine any time soon.
>
> 3. Overall the summary is positive, with no actionable feedback. A few
> "lgtm please ship" and "if we can't use this we'll have to use Electron".
>
> Regards
>
> Diego
>
> On Thursday, 30 September 2021 at 20:30:51 UTC+1 Chris Harrelson wrote:
>
>> Hi, a few points.
>>
>> 1. Please file for signals via the mechanism at bit.ly/blink-signals.
>> 2. Ok if we block approval on landing the spec PR?
>> 3. Can you send us a summary of feedback received during the Origin Trial?
>>
>> Thanks,
>> Chris
>>
>>
>> On Wed, Sep 29, 2021 at 9:25 AM 'Diego Gonzalez' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> samue...@microsoft.com, mjac...@microsoft.com, luig...@microsoft.com,
>>> dmu...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md
>>>
>>> https://web.dev/url-protocol-handler/
>>>
>>>
>>> Specification
>>>
>>>
>>> https://pr-preview.s3.amazonaws.com/w3c/manifest/pull/972.html#protocol_handlers-member
>>>
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1NHlWLjAPZ-dyxcz3AoTWibeerDeHW7Vqrx6FmhB0XmE
>>> Summary
>>>
>>> Enable web applications to register themselves as handlers of custom URL
>>> protocols/schemes using their installation manifest.
>>> Blink component
>>>
>>> UI>Browser>WebAppInstalls
>>> 
>>> Search tags
>>>
>>> protocol , web app
>>> , protocol handlers
>>> , custom
>>> schemes 
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/482
>>> TAG review status
>>>
>>> Issues addressed, resolution: satisfied.
>>> Risks Interoperability and Compatibility
>>>
>>> Low; manifest elements will be ignored if unsupported by the client.
>>>
>>> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1635272)
>>>
>>> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=211401)
>>>
>>> Web developers: Positive (
>>> https://twitter.com/search?q=url%3Ahttps%3A%2F%2Fweb.dev%2Furl-protocol-handler%2F&src=typed_query&f=live
>>> )
>>> Security
>>>
>>>
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/URLProtocolHandler/explainer.md#security-considerations
>>>
>>>
>>> Debuggability Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes - https://chromium-review.googlesource.com/c/chromium/src/+/3166820
>>>
>>>
>>> DevTrial instructions
>>>
>>>
>>> https://web.dev/url-protocol-handler/#enabling-via-about:flags-or-edge:flags
>>> Flag name
>>>
>>> #enable-desktop-pwas-protocol-handling
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> Yes
>>> Tracking bug
>>>
>>> https://crbug.com/1019239
>>>
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1063658
>>>
>>>
>>> Sample links
>>>
>>> https://protocol-handler.glitch.me/
>>>
>>> https://fabiorocha.github.io/pwa
>>>
>>>
>>> Estimated milestones
>>>
>>> OriginTrial desktop last
>>>
>>> 95
>>>
>>> OriginTrial desktop first
>>>
>>> 92
>>>
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5151703944921088
>>>
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/x4Ev_l9Oj2U/m/6bGPs7MVCwAJ
>>>
>>> Ready for Trial:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/GbTdEVNPhng
>>>
>>> Intent to Experiment:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AuKUdqTkUAs
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> *Diego González-Zúñiga*
>>>
>>> PM, Microsoft Edge
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

LGTM3

On Thu, Oct 7, 2021 at 3:34 AM 'Munira Tursunova' via blink-dev <
blink-dev@chromium.org> wrote:

> > Looking at the font-synthesis-* tests in
> https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
> many pass in Firefox and Safari, but not all of them. Do all of these tests
> pass with the implementation now in Blink?
>
> Yes, they do. Actually these tests had been added with the Chrome
> implementation and they are responsible for longhands for font-synthesis
> property which is not supported by other browsers yet.
>
> > In the chromestatus entry I see "There are additional tests for system
> fonts with platform specific results, so we keep those as internal tests."
> Is the problem there that the tests rely on system fonts, or that there are
> platform-specific results? The latter is possible with WPT using the
> regular third_party/blink/web_tests/platform/ expectations. For system
> fonts, perhaps these tests could be written to pass if the fonts aren't
> present? If these are testharness.js tests,
> https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
> might be a path forward.
>
> Yes, they rely on particular aspects of which fonts are available on the
> system. As the font-synthesis property, when applied to system fonts, is
> closely connected to font matching and identifying whether a true bold /
> true italic variant exists, it’d be hard to make those flexible in terms of
> a default passing when the font does not exist. They are ref tests for that
> purpose.
>
> >Also, looking at
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
> I wonder if small-caps is going to be supported? If that table is correct
> it's not supported by Safari and it's only just now coming to Firefox.
>
> Yes, small-caps support was also implemented in Blink (as longhand and as
> part of the shorthand). Also I’m not sure if that table is correct because
> Safari also supports ‘small-caps’ (only as a keyword in the shorthand) .
> They just have a bug in ref for this test:
> https://wpt.fyi/results/css/css-fonts/font-synthesis-06.html?label=experimental&label=master&aligned
>
> On Thursday, October 7, 2021 at 11:28:57 AM UTC+3 Philip Jägenstedt wrote:
>
>> It's great to see this feature getting ready to ship, it's one of a
>> relatively small number of features already supported by Firefox and Safari
>> but not by Chromium browsers, so it's been on my radar :)
>>
>> I just have a few questions.
>>
>> Looking at the font-synthesis-* tests in
>> https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
>> many pass in Firefox and Safari, but not all of them. Do all of these tests
>> pass with the implementation now in Blink?
>>
>> In the chromestatus entry I see "There are additional tests for system
>> fonts with platform specific results, so we keep those as internal tests."
>> Is the problem there that the tests rely on system fonts, or that there are
>> platform-specific results? The latter is possible with WPT using the
>> regular third_party/blink/web_tests/platform/ expectations. For system
>> fonts, perhaps these tests could be written to pass if the fonts aren't
>> present? If these are testharness.js tests,
>> https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
>> might be a path forward.
>>
>> Also, looking at
>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
>> I wonder if small-caps is going to be supported? If that table is correct
>> it's not supported by Safari and it's only just now coming to Firefox.
>>
>> On Thu, Oct 7, 2021 at 9:59 AM Daniel Bratell  wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2021-10-07 09:08, Yoav Weiss wrote:
>>>
>>> *LGTM1*
>>> Thanks for working on this!! This seems like an important thing to catch
>>> up on!
>>>
>>>
>>>
>>> On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails

 moo...@google.com, dr...@chromium.org

 Explainer

 https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro

 https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis

 Specification

 https://drafts.csswg.org/css-fonts/#font-synthesis

 Summary

 The font-synthesis CSS property controls whether user agents are
 allowed to synthesize oblique, bold and small-caps font faces when a font
 family lacks oblique, bold and small-caps faces, respectively.


 Blink component

 Blink>Fonts
 

 TAG review status

 Already shipped in other browsers, see below, no TAG review required.

 Risks

 Interoperability and Compatibility Low, feature already shipped in
 Firefox and Safari.

 Expected graceful degradation if an engine has so far not im

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

LGTM1, to ship this without the certificate fingerprint portion of 349
discussed above. There's still some conversation to be had there, and I
think it's worth finishing the discussion before shipping it since it's
quite clearly separable. I'd suggest shipping that as a separate intent if
that's the way the conversation goes.

I appreciate Philip's comments as well, and I'm happy to see that y'all
have already put up a PR to add CSP support. I think we should probably
alter the CSP spec to make your PR more clear, but that's not something I
think we ought to block on.

I'll also note that the TAG just put this on their agenda for this coming
week. If concerns are raised there, I would appreciate us addressing them
thoroughly before shipping.

-mike


On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano  wrote:

>
>
> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>>> wrote:
>>>
 Thank you!

 On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
 wrote:

> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>>> wrote:
>>>
 Hi Philip,

 Sorry for the belated reply. Comments inline:

 On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of
> questions, but am pretty convinced we should ship this, it's just a 
> matter
> of what things need to block that, and what things can be left until 
> later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
> yhir...@chromium.org> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see
> multiple issues filed by other browser vendors. Are any of the 
> remaining
> issues ones that could change the API's shape or behavior? It would 
> be good
> to resolve any such issues, since they won't be possible to address 
> once
> the API is locked in by sites depending on it.
>
>
 I believe we've addressed issues that may require breaking changes.
 You can see open /
 closed  
 issues
 for the initial launch (this intent).  I shared our plan
 
  at a WG meeting in May
 
  and
 we've been working to find and resolve such issues since then.

>>>
>>> I see, creating a milestone for this is really handy! Are the
>>> remaining issue in https://github.com/w3c/webtransport/milestone/1
>>> not blocking then, even issue #349
>>> ?
>>>
>>
>> *Except for issue #349* we have consensus on discussions. As Victor
>> commented in this thread, we can ship WebTransport *except for *
>> customeCertificationHashes
>> 
>>  if
>> needed.
>>
>
> If custom certificates is a nice-to-have then shipping without it
> seems fine to me. That would mean removing serverCertificateHashes from 
> the
> dictionary, right? I ask because the spec also says something
> about NotSupportedError when the protocol doesn't support it, but it seems
> better to behave as if the feature doesn't exist at all.
>
>
 The property is protected by WebTransportCustomCertificates
 ,
 so when we enable only WebTransport, the property will be invisible.

>>>
>>> Great, thanks for confirming!
>>>
>>>
 Looking through some other issues:
>
>- Can https://github.com

Re: [blink-dev] Intent to Ship: Content-Security-Policy delivery via response headers for dedicated workers.


LGTM3

/Daniel

On 2021-10-07 21:16, Chris Harrelson wrote:

Thanks!

LGTM2

On Fri, Oct 1, 2021 at 9:11 AM Antonio Sartori 
 wrote:




On Fri, Oct 1, 2021 at 5:09 PM Chris Harrelson
 wrote:

One more requirement from my perspective, and one question below.


Thanks. Replies inline.

On Fri, Oct 1, 2021 at 2:50 AM Yoav Weiss
 wrote:

*LGTM1*

Thank you for doing this analysis! 2/550K is significantly
less than 80% :P

I believe that puts us at ~0.00036%, and the actual number
of affected sites (as opposed to workers) is an order of
magnitude lower. Also, there's no particular reason to
believe HA is unrepresentative for this particular change.
(as I wouldn't expect main page workers to vary vastly
from workers in other pages)
That makes me agree with your assessment of this being low
risk.

On Fri, Oct 1, 2021 at 10:12 AM Antonio Sartori
 wrote:

Sorry, of course. I just forgot.

On Fri, Oct 1, 2021 at 9:30 AM Yoav Weiss
 wrote:

Thanks!!

On Fri, Oct 1, 2021 at 9:23 AM Antonio Sartori
 wrote:

I did some more research in httparchive. By
filtering out only interesting CSPs delivered
by workers and comparing them with their owner
document's CSP, I was left with only two
entries (out of the total 457,780 worker
requests) which might actually break. The
details are in this document

.



Could the doc be made public?

Could this give us confidence that content
won't break, even without adding user counters
in the code?

Regarding Safari, I did some more experiments
and checked their code

.
I would now say confidently that they do
implement this.

Thanks!

On Wed, Sep 29, 2021 at 5:05 PM Yoav Weiss
 wrote:



On Wed, Sep 29, 2021 at 4:16 PM Antonio
Sartori  wrote:



On Wed, Sep 29, 2021 at 2:50 PM Yoav
Weiss  wrote:



On Wed, Sep 29, 2021 at 2:14 PM
Antonio Sartori
 wrote:

From a quick search through
httparchive (data from
httparchive.requests.2021_07_01_desktop)
it looks like out of 549,668
outgoing requests for
dedicated workers, 457,780 of
them returned a
Content-Security-Policy header
(hence ~80%). As a comparison,
from the same data it looks
like ~15% of document requests
return a Content-Security-Policy.


That's a lot!


Better data could be gathered
by building some use counters
in chromium's code.


Unless there's particular urgency
here, I think use-counters would
make sense here. That can give us
confidence that content won't
break as a result of this change
in CSP rule application.


Just to double-check that I understand
correctly: For giving us confidence
that content won't break, we would
have to build a mechanism to check
workers' response CSPs (without
enforcing them) and report via use
counters in case a resource wh

Re: [blink-dev] Intent to Ship: Content-Security-Policy delivery via response headers for dedicated workers.

Thanks!

LGTM2

On Fri, Oct 1, 2021 at 9:11 AM Antonio Sartori 
wrote:

>
>
> On Fri, Oct 1, 2021 at 5:09 PM Chris Harrelson 
> wrote:
>
>> One more requirement from my perspective, and one question below.
>>
>>
> Thanks. Replies inline.
>
>
>> On Fri, Oct 1, 2021 at 2:50 AM Yoav Weiss  wrote:
>>
>>> *LGTM1*
>>>
>>> Thank you for doing this analysis! 2/550K is significantly less than 80%
>>> :P
>>>
>>> I believe that puts us at ~0.00036%, and the actual number of affected
>>> sites (as opposed to workers) is an order of magnitude lower. Also, there's
>>> no particular reason to believe HA is unrepresentative for this particular
>>> change. (as I wouldn't expect main page workers to vary vastly from workers
>>> in other pages)
>>>
>>> That makes me agree with your assessment of this being low risk.
>>>
>>> On Fri, Oct 1, 2021 at 10:12 AM Antonio Sartori <
>>> antoniosart...@chromium.org> wrote:
>>>
 Sorry, of course. I just forgot.

 On Fri, Oct 1, 2021 at 9:30 AM Yoav Weiss 
 wrote:

> Thanks!!
>
> On Fri, Oct 1, 2021 at 9:23 AM Antonio Sartori <
> antoniosart...@chromium.org> wrote:
>
>> I did some more research in httparchive. By filtering out only
>> interesting CSPs delivered by workers and comparing them with their owner
>> document's CSP, I was left with only two entries (out of the total 
>> 457,780
>> worker requests) which might actually break. The details are in this
>> document
>> .
>>
>>
>
> Could the doc be made public?
>
>
>> Could this give us confidence that content won't break, even without
>> adding user counters in the code?
>>
>> Regarding Safari, I did some more experiments and checked their code
>> .
>> I would now say confidently that they do implement this.
>>
>> Thanks!
>>
>> On Wed, Sep 29, 2021 at 5:05 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 29, 2021 at 4:16 PM Antonio Sartori <
>>> antoniosart...@chromium.org> wrote:
>>>


 On Wed, Sep 29, 2021 at 2:50 PM Yoav Weiss 
 wrote:

>
>
> On Wed, Sep 29, 2021 at 2:14 PM Antonio Sartori <
> antoniosart...@chromium.org> wrote:
>
>> From a quick search through httparchive (data from
>> httparchive.requests.2021_07_01_desktop) it looks like out
>> of 549,668 outgoing requests for dedicated workers, 457,780 of them
>> returned a Content-Security-Policy header (hence ~80%). As a 
>> comparison,
>> from the same data it looks like ~15% of document requests return a
>> Content-Security-Policy.
>>
>
> That's a lot!
>
>
>>
>> Better data could be gathered by building some use counters in
>> chromium's code.
>>
>
> Unless there's particular urgency here, I think use-counters would
> make sense here. That can give us confidence that content won't break 
> as a
> result of this change in CSP rule application.
>

 Just to double-check that I understand correctly: For giving us
 confidence that content won't break, we would have to build a 
 mechanism to
 check workers' response CSPs (without enforcing them) and report via 
 use
 counters in case a resource which is currently allowed would have been
 blocked. This is what I was sketching below, and requires quite some
 implementation work, which I am not sure when we would be able to
 prioritize.

>>>
>>> Maybe I'm missing the mark, but wouldn't that implementation work be
>>> something that's on path to what you'd need to implement anyway for 
>>> this?
>>> I certainly have no interest in making you do extra work, but with
>>> 80% (!!) of workers currently having CSP headers, I'm concerned that
>>> mismatches between the worker headers and the main document headers 
>>> exist,
>>> which can result in broken content.
>>> I take your point that if such discrepancies exist, they are
>>> currently reflected in broken content in e.g. Firefox. At the same time,
>>> I'd be more comfortable with taking a decision here based on a bit more
>>> data.
>>>
>>>
 I don't think there is a particular urgency, although this is a
 bugfix and I believe this is a big security improvement, since it 
 allows
 servers to have different policies on their main page and on the 
 worker (so
 for example an application which needs eval inside a worker would not 
 need

Re: [blink-dev] Intent to Ship: App Shortcuts Menu (Mac/Linux)

LGTM3

/Daniel

On 2021-10-07 20:58, Chris Harrelson wrote:

LGTM2

On Thu, Oct 7, 2021 at 11:57 AM Mike West wrote:

Extending the existing support from Android and Windows to Mac and
Linux is quite reasonable. LGTM1.

That said, it would be ideal to ping
https://github.com/mozilla/standards-positions/issues/338 in the
hopes of keeping this on Mozilla's radar in the hopes of eventual
interop.

-mike

On Thu, Oct 7, 2021 at 6:53 PM 'Ajay Rahatekar' via blink-dev
wrote:

Contact emails

mjack...@microsoft.com ,
mandy.c...@microsoft.com ,
est...@google.com ,
ajayrahate...@google.com

Explainer

Shortcuts Explainer

Spec

W3C spec:https://w3c.github.io/manifest/#shortcuts-member

Tag Review:https://github.com/w3ctag/design-reviews/issues/510

Summary

This feature provides PWA developers the ability to show a
shortcuts menu of common tasks in their app. The menu can be
invoked by right clicking the app icon in the quick launch bar
after the PWA has been installed on the user’s desktop, or
long pressing on the app on Android. This capability already
exists for native apps on various platforms (Android, Linux,
macOS, and Windows).

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0

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

This feature was previously shipped for Windows and Android

https://groups.google.com/a/chromium.org/g/blink-dev/c/FgzYX7AFbUQ/m/f2i0-f-BAQAJ

Requesting approval to ship on Mac and Linux
https://bugs.chromium.org/p/chromium/issues/detail?id=1248101

Demo link

Test Website .

The enable-desktop-pwas-app-icon-shortcuts-menu-ui flag needs
to be enabled.

Risks

Interoperability and Compatibility

No Interoperability/Compatibility risk. When a web developer
doesn’t provide a shortcuts member in the PWA’s
WebAppManifest, current installation behavior is not affected
by this feature.

Edge: In development/Public Support

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive feedback from web developers

Ergonomics

Shortcuts will be used as part of the WebAppManifest. Use will
not affect performance.

Activation

Use will be straightforward, it will only require developers
to list their shortcuts in their manifest.

Is this feature fully tested byweb-platform-tests

?
Link to test suite results fromwpt.fyi .

Pre-existing manual WPT tests exist:
appmanifest/shortcuts-member/

Entry on thefeature dashboard

https://www.chromestatus.com/feature/5706099464339456

--
Ajay Rahatekar | Technical Program Manager

|ajayrahate...@google.com |650-797-1279
--
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/CAHB%2BDAgpD1v%2Bp0Y4HtXa43TiySyA_R0_%3Do4Dg4U1AJtQrQu_vQ%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

Re: [blink-dev] Intent to Ship: Auto-expand details elements

LGTM2.

Please do follow up on any feedback you obtain from the TAG, since I
believe the review request there is still outstanding. It doesn't appear to
me that there are substantial design questions that are still open, but if
something interesting is raised, we should respond to it expediently.

In particular, if we do end up deciding that we need an opt-out, it should
be straightforward to ship on top of this feature.

-mike


On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy  wrote:

> Thank you for the detailed differential threat analysis, SGTM from the
> permissions side. Glad to see the ongoing work on robust and comprehensive
> mitigations.
>
> On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:
>
>> > in anticipation of a future world where the preexisting vectors of
>> snooping have been mitigated
>>
>> I am planning on adding a delay to find-in-page in order to mitigate
>> find-in-page snooping which would work with this feature, beforematch, and
>> the existing scroll events:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1250158
>> I am hoping that this mitigation, when complete, will make it harder or
>> impossible to recreate what the user typed into the find-in-page dialog
>> regardless of the attack vector and I believe it will be much more robust
>> than the beforematch mitigations I proposed.
>>
>> > For the `beforeMatch` event we requested that if the website does not
>> reveal `hidden-matchable` content in response to this event, sending the
>> event be stopped for the reminder of the lifetime of the page. This was to
>> prevent adding new ways of snooping on what the user types in the
>> find-in-page box without any user-visible feedback
>>
>> > However, back then, we were unsure if there exists a robust solution to
>> verify that content actually got revealed in response to `beforeMatch`.
>> There was some discussion about this on the TAG review thread, but I am not
>> sure if we ended up finding a good approach. Do you think there is a viable
>> technical enforcement here, for the  element?
>>
>> This feature is different from beforematch in a couple ways:
>> 1. We aren't adding a new signal to the page like the beforematch event.
>> 2. The existing toggle event which would be fired upon expanding the
>> details element is fired asynchronously, so it wouldn't be able to close
>> the details element again and undo the scroll "without any user-visible
>> feedback" as you mentioned.
>>
>> Technically, the page could also listen to deprecated mutation events to
>> be notified when the open attribute is added to the details element, but
>> this still happens at the same time that the existing problematic scroll
>> events are fired: synchronously.
>> Since I don't see the open attribute or the toggle event as being worse
>> than the existing scroll event, I don't believe we need a mitigation like
>> we discussed for beforematch.
>>
>> On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy 
>> wrote:
>>
>>> For the `beforeMatch` event we requested that if the website does not
>>> reveal `hidden-matchable` content in response to this event, sending the
>>> event be stopped for the reminder of the lifetime of the page. This was to
>>> prevent adding new ways of snooping on what the user types in the
>>> find-in-page box without any user-visible feedback; and in anticipation of
>>> a future world where the preexisting vectors of snooping have been
>>> mitigated.
>>>
>>> However, back then, we were unsure if there exists a robust solution to
>>> verify that content actually got revealed in response to `beforeMatch`.
>>> There was some discussion about this on the TAG review thread, but I am not
>>> sure if we ended up finding a good approach. Do you think there is a viable
>>> technical enforcement here, for the  element?
>>> On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:
>>>
 On 9/23/21 8:19 AM, Yoav Weiss wrote:

 On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner 
 wrote:

> Not sure this was discussed before, but could a new boolean attribute
> that opts the element in to the new behavior be the answer?
>
> 
>
 At the risk of jinxing UseCounter metrics
 ,
 another option would be to spec the `search` event such that
 `preventDefault()` provides an opt-out here.

>>> --
> 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/cc3efcbb-85a8-4689-a892-100b81e4ee70n%40chromium.org
> 
> .
>

-- 
You received this message because you

Re: [blink-dev] Intent to Ship: App Shortcuts Menu (Mac/Linux)

LGTM2

On Thu, Oct 7, 2021 at 11:57 AM Mike West  wrote:

> Extending the existing support from Android and Windows to Mac and Linux
> is quite reasonable. LGTM1.
>
> That said, it would be ideal to ping
> https://github.com/mozilla/standards-positions/issues/338 in the hopes of
> keeping this on Mozilla's radar in the hopes of eventual interop.
>
> -mike
>
>
> On Thu, Oct 7, 2021 at 6:53 PM 'Ajay Rahatekar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> mjack...@microsoft.com, mandy.c...@microsoft.com, est...@google.com,
>> ajayrahate...@google.com
>>
>> Explainer
>>
>> Shortcuts Explainer
>> 
>>
>> Spec
>>
>> W3C spec: https://w3c.github.io/manifest/#shortcuts-member
>>
>> Tag Review: https://github.com/w3ctag/design-reviews/issues/510
>>
>> Summary
>>
>> This feature provides PWA developers the ability to show a shortcuts menu
>> of common tasks in their app. The menu can be invoked by right clicking the
>> app icon in the quick launch bar after the PWA has been installed on the
>> user’s desktop, or long pressing on the app on Android. This capability
>> already exists for native apps on various platforms (Android, Linux, macOS,
>> and Windows).
>>
>> Link to “Intent to Prototype” blink-dev discussion
>>
>>
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> This feature was previously shipped for Windows and Android
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/FgzYX7AFbUQ/m/f2i0-f-BAQAJ
>>
>>
>> Requesting approval to ship on Mac and Linux
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1248101
>>
>>
>> Demo link
>>
>> Test Website .
>>
>> The enable-desktop-pwas-app-icon-shortcuts-menu-ui flag needs to be
>> enabled.
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> No Interoperability/Compatibility risk. When a web developer doesn’t
>> provide a shortcuts member in the PWA’s WebAppManifest, current
>> installation behavior is not affected by this feature.
>>
>> Edge: In development/Public Support
>>
>> Firefox: No signals
>>
>> Safari: No signals
>>
>> Web / Framework developers: Positive feedback from web developers
>>
>> Ergonomics
>>
>> Shortcuts will be used as part of the WebAppManifest. Use will not affect
>> performance.
>>
>> Activation
>>
>> Use will be straightforward, it will only require developers to list
>> their shortcuts in their manifest.
>>
>> Is this feature fully tested by web-platform-tests
>> ?
>> Link to test suite results from wpt.fyi.
>>
>> Pre-existing manual WPT tests exist: appmanifest/shortcuts-member/
>> 
>>
>> Entry on the feature dashboard 
>>
>> https://www.chromestatus.com/feature/5706099464339456
>>
>> --
>> Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
>> 650-797-1279 <(650)%20650-797-1279>
>>
>> --
>> 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/CAHB%2BDAgpD1v%2Bp0Y4HtXa43TiySyA_R0_%3Do4Dg4U1AJtQrQu_vQ%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/CAKXHy%3DdFdH6rqKq7yCZWgiHueWxjhwoJGLJ8pN%2BA4bhBQX1uSw%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-eXy%2BxAXCUc%2BKt4L3C3kN7%3DzOUJz8eA4CaTzTLtF8Mng%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: App Shortcuts Menu (Mac/Linux)

Extending the existing support from Android and Windows to Mac and Linux is
quite reasonable. LGTM1.

That said, it would be ideal to ping
https://github.com/mozilla/standards-positions/issues/338 in the hopes of
keeping this on Mozilla's radar in the hopes of eventual interop.

-mike


On Thu, Oct 7, 2021 at 6:53 PM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> mjack...@microsoft.com, mandy.c...@microsoft.com, est...@google.com,
> ajayrahate...@google.com
>
> Explainer
>
> Shortcuts Explainer
> 
>
> Spec
>
> W3C spec: https://w3c.github.io/manifest/#shortcuts-member
>
> Tag Review: https://github.com/w3ctag/design-reviews/issues/510
>
> Summary
>
> This feature provides PWA developers the ability to show a shortcuts menu
> of common tasks in their app. The menu can be invoked by right clicking the
> app icon in the quick launch bar after the PWA has been installed on the
> user’s desktop, or long pressing on the app on Android. This capability
> already exists for native apps on various platforms (Android, Linux, macOS,
> and Windows).
>
> Link to “Intent to Prototype” blink-dev discussion
>
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> This feature was previously shipped for Windows and Android
> https://groups.google.com/a/chromium.org/g/blink-dev/c/FgzYX7AFbUQ/m/f2i0-f-BAQAJ
>
>
> Requesting approval to ship on Mac and Linux
> https://bugs.chromium.org/p/chromium/issues/detail?id=1248101
>
>
> Demo link
>
> Test Website .
>
> The enable-desktop-pwas-app-icon-shortcuts-menu-ui flag needs to be
> enabled.
>
> Risks
>
> Interoperability and Compatibility
>
> No Interoperability/Compatibility risk. When a web developer doesn’t
> provide a shortcuts member in the PWA’s WebAppManifest, current
> installation behavior is not affected by this feature.
>
> Edge: In development/Public Support
>
> Firefox: No signals
>
> Safari: No signals
>
> Web / Framework developers: Positive feedback from web developers
>
> Ergonomics
>
> Shortcuts will be used as part of the WebAppManifest. Use will not affect
> performance.
>
> Activation
>
> Use will be straightforward, it will only require developers to list their
> shortcuts in their manifest.
>
> Is this feature fully tested by web-platform-tests
> ?
> Link to test suite results from wpt.fyi.
>
> Pre-existing manual WPT tests exist: appmanifest/shortcuts-member/
> 
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/5706099464339456
>
> --
> Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
> 650-797-1279 <(650)%20650-797-1279>
>
> --
> 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/CAHB%2BDAgpD1v%2Bp0Y4HtXa43TiySyA_R0_%3Do4Dg4U1AJtQrQu_vQ%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/CAKXHy%3DdFdH6rqKq7yCZWgiHueWxjhwoJGLJ8pN%2BA4bhBQX1uSw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: interactionID in Event Timing

2021-10-07 Thread Alex Russell

So this design looks pretty good in terms of auto-generating a uniform ID 
for pre-baked events, but I'm curious about how it will interact with 
asynchronous tasks generated from within task callbacks, and how a 
user-timing mark from within one of these scopes might inherit the 
interactionID?


On Thursday, October 7, 2021 at 7:17:01 AM UTC-7 Nicolás Peña wrote:

> On Thursday, October 7, 2021 at 1:58:59 AM UTC-4 Yoav Weiss wrote:
>
>> On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña  wrote:
>>
>>> Contact emails
>>>
>>> n...@chromium.org, hbs...@chromium.org
>>>
>>> Explainer
>>>
>>> https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777
>>>
>>> Specification
>>>
>>>
>>> https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid
>>>
>>> Summary
>>>
>>> Developers currently use the Event Timing API to gather performance data 
>>> about events they care about. However, it is currently hard to link events 
>>> that correspond to the same user interaction. For instance, when a user 
>>> taps, many events are generated, such as pointerdown, mousedown, pointerup, 
>>> mouseup, and click. The interactionID enables developers to link multiple 
>>> PerformanceEventTiming entries when they correspond to the same user 
>>> interaction.
>>>
>>> Blink component
>>>
>>> Blink>PerformanceAPIs 
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/670
>>>
>>> TAG review status
>>>
>>> Open
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> The main interop risk is that this feature does not become implemented 
>>> in other browsers. This is an attribute in a performance feature so even if 
>>> this is not implemented there websites using this feature should not break 
>>> in any way.
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/283) Updated the 
>>> Event Timing issue to note this addition.
>>>
>>> WebKit: Negative (
>>> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) 
>>> This is a negative on Event Timing as a whole, so we consider this to be 
>>> negative for this feature in particular.
>>>
>>> Web developers: No signals. We presented this to WebPerf WG 
>>> https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html
>>>  
>>>
>> My read of the minutes is that there was a developer need for grouping 
>> interactions, but even more demand (at least from the folks in the room) 
>> for scroll grouping. Is that accurate?
>>
>
> Yea, that is accurate.
>  
>
>>  
>>
>>>
>>> Ergonomics
>>>
>>> N/A
>>>
>>>
>>> Activation
>>>
>>> Seems tricky to impossible to polyfill, so developers would need to use 
>>> the API in order to obtain the more accurate data. 
>>>
>>>
>>> Security
>>>
>>> One consideration was whether it is ok to expose the number of 
>>> interactions that have occurred in the page. This is already observable via 
>>> event handlers. Cross-origin events are not exposed.
>>>
>>>
>>> Debuggability
>>>
>>> Use PerformanceObserver in the console. We don't have concrete plans to 
>>> add Event Timing support in DevTools yet, but maybe in the future. Lab 
>>> tools in general do not currently have great support for user inputs.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>>
>>>
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html
>>>  
>>>
>>> Flag name
>>>
>>> InteractionId
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1236758
>>>
>>> Launch bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1245771
>>>
>>> Estimated milestones
>>>
>>> 96
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://www.chromestatus.com/feature/5674224959094784
>>>
>>> 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/ec282b39-cd45-46f1-a542-cbdc7354347an%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.

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

2021-10-07 Thread 'Shu-yu Guo' via blink-dev

Contact emails...@chromium.org

Explainerhttps://github.com/tc39/proposal-array-find-from-last

Specificationhttps://tc39.es/proposal-array-find-from-last/index.html

Summary

This is a Stage 3 TC39 proposal that adds the methods findLast and
findLastIndex to Array.prototype and the various TypedArray.prototypes.
These methods are the "from the end" versions of find and findIndex.

Blink componentBlink>JavaScript>Language

TAG review

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Adding any new methods to Array.prototype runs the risk of web
incompatibility due to breaking old libraries. Rollout will need to be
monitored.

Gecko: Positive This is Stage 3 in TC39

WebKit: Positive This is Stage 3 in TC39

Web developers: Positive (
https://twitter.com/mgechev/status/1432199126570131459?s=20)

Debuggability

It is a new prototype method, so can be debugged like any other prototype
method.

Is this feature fully tested by web-platform-tests

?Yes, in test262

Flag name--harmony-array-find-last

Requires code in //chrome?False

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

Estimated milestones
DevTrial on desktop 94
DevTrial on android 94
DevTrial on Webview 94

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

This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] Intent to Implement and Ship: transform: perspective(none)

2021-10-07 Thread David Baron

Thanks for the LGTMs.

I filed WebKit bug 231361  for
implementing perspective(none) in WebKit, and for MDN documentation of
perspective() I created PR mdn/content#9653
 (fixing some other issues as
well) and filed issue mdn/browser-compat-data#12742
.

It's indeed expected that the existing WPT tests for perspective(none) are
all passing in Firefox since they were all added as part of the patch that
implemented it in Firefox.  I have one more WPT test addition in the
Chromium patch.

-David

On Thu, Oct 7, 2021 at 3:55 AM Philip Jägenstedt 
wrote:

> LGTM3, this is an easy case, an improvement to an existing feature already
> on track to ship in another browser.
>
> Although not part of our launch process, can I ask what documentation
> updates will be needed here?
> https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/perspective()
> doesn't mention "none" at all, is that the page to update? If so, a new
> entry in the compat table at the bottom of the page would also be a good
> idea. If it's clear what needs to be done, would you mind filing issues at
> https://github.com/mdn/content/issues and
> https://github.com/mdn/browser-compat-data/issues? (Again, not a proper
> part of our launch process, so optional.)
>
> For WPT, indeed it looks like this is already passing in Firefox:
>
> https://wpt.fyi/results/css/css-transforms/animation/transform-interpolation-001.html?label=experimental&label=master&aligned
>
> On Thu, Oct 7, 2021 at 8:49 AM Manuel Rego Casasnovas 
> wrote:
>
>> LGTM2
>>
>> On 07/10/2021 08:07, Yoav Weiss wrote:
>> > LGTM1
>> >
>> > On Mon, Oct 4, 2021 at 10:42 PM David Baron > > > wrote:
>> >
>> >
>> > Contact emails
>> >
>> > dba...@chromium.org 
>> >
>> >
>> > Explainer
>> >
>> > None
>> >
>> >
>> > Specification
>> >
>> > https://drafts.csswg.org/css-transforms-2/#funcdef-perspective
>> > 
>> >
>> >
>> > Summary
>> >
>> > Implement support for a 'none' argument to the perspective()
>> > function within the syntax of the CSS transform property. This
>> > provides the perspective() function with a value that gives the
>> > identity matrix. Its effect is as though the perspective() function
>> > was given an argument that is infinite. This makes it easier (or, in
>> > some cases, possible) to do animations involving the perspective()
>> > function where one of the endpoints of the animation is the identity
>> > matrix.
>> >
>> >
>> >
>> > Blink component
>> >
>> > Blink>CSS
>> > <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>> >
>> >
>> > Search tags
>> >
>> > css , transform
>> > , perspective
>> > 
>> >
>> >
>> > TAG review
>> >
>> > Not needed for a single value addition to a single function within a
>> > CSS property.
>> >
>> >
>> > TAG review status
>> >
>> > Not applicable
>> >
>> >
>> > Risks
>> >
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> >
>> >
>> > Gecko: Shipped/Shipping
>> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1725207
>> > ) Will ship
>> > very soon in Firefox 93.
>> >
>> > WebKit: No signal
>> > (
>> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025
>> > <
>> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025>)
>> > Safari developers participated in the CSS Working Group discussion
>> > about adding it and were ok with the addition. I recognize this
>> > isn't an official signal, but this seems perhaps too small a feature
>> > to ask for an explicit one.
>> >
>> >
>> > Can you file a webkit bug for this?
>> >
>> >
>> >
>> > Web developers: Positive
>> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1723266#c2
>> > ) this is
>> > the one explicit signal from a developer that I could find
>> >
>> >
>> > Debuggability
>> >
>> > Should be equally debuggable as existing values of the perspective()
>> > function.
>> >
>> >
>> >
>> > Is this feature fully tested by web-platform-tests
>> > <
>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
>> >?
>> >
>> > Yes
>> >
>> >
>> > Flag name
>> >
>> >
>> >
>> > Requires code in //chrome?
>> >
>> > False
>> >
>> >
>> > Tracking

RE: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

2021-10-07 Thread 'Anupam Snigdha' via blink-dev

Yep, I'll address the feedback from Anne and mbrodesser (from Mozilla).
Thanks for all your help Anne and Yoav!

From: Yoav Weiss 
Sent: Thursday, October 7, 2021 12:03 AM
To: Anupam Snigdha 
Cc: ann...@annevk.nl; blink-dev@chromium.org; m...@chromium.org; Bo Cupp 

Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

On Tue, Oct 5, 2021 at 4:02 AM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
Here is a WIP PR to address the spec issue: 
https://github.com/w3c/clipboard-apis/pull/158.

Can you address feedback from Anne on the PR?

From: Anupam Snigdha
Sent: Monday, October 4, 2021 10:45 AM
To: 'Yoav Weiss' mailto:yoavwe...@chromium.org>>; Anne 
van Kesteren mailto:ann...@annevk.nl>>
Cc: blink-dev mailto:blink-dev@chromium.org>>; Marijn 
Kruisselbrink mailto:m...@chromium.org>>; Bo Cupp 
mailto:pc...@microsoft.com>>
Subject: RE: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

For #1: I don't think we would want to diverge from the spec. There is a reason 
why we have promises to Blobs and not just Blobs in the ClipboardItem because, 
well, not having promises defeats the purpose of having an async API. Also 
waiting for the Blob data synchronously without triggering the clipboard write 
operation leads to problems like 
this
 and performance issues in sites like Excel Online where the copy payload is in 
MBs.

That makes sense.

For #2: This might sound more of a rant so apologies in advance.

I agree with Anne that the spec is not really clear at all on the specifics of 
the async clipboard API and some of the terminologies used in the algorithms.
However, making changes to the spec or even clarifying the language after an 
API has been shipped, is really hard, as we need to get consensus from all 
browser vendors.
I tried to clarify what "sanitization" means just for the HTML 
format
 and Apple opposed to this 
change.

That's unfortunate :/

Perhaps I can add a non-normative note which would at least give some clarity 
on the sanitization process, but that would probably require UA specific non 
normative notes which defeats the purpose of standardization.
I also tried to make changes to address Mozilla's concern about mandatory data 
types supported by async clipboard APIs: 
https://github.com/w3c/clipboard-apis/pull/155,
 but this PR has been sitting for almost a month now and I'm not able to make 
any progress.

FWIW, it seemed to have made some progress initially and then stalled. Pinging 
it may make sense.

In order to make progress on spec changes, we decided to have a discussion with 
the Editing WG members and submit changes to the spec if no one objects to it. 
Currently the Editing WG has representatives from Apple and MS who reg

[blink-dev] Intent to Ship: App Shortcuts Menu (Mac/Linux)

2021-10-07 Thread 'Ajay Rahatekar' via blink-dev

Contact emails

mjack...@microsoft.com, mandy.c...@microsoft.com, est...@google.com,
ajayrahate...@google.com

Explainer

Shortcuts Explainer

Spec

W3C spec: https://w3c.github.io/manifest/#shortcuts-member

Tag Review: https://github.com/w3ctag/design-reviews/issues/510

Summary

This feature provides PWA developers the ability to show a shortcuts menu
of common tasks in their app. The menu can be invoked by right clicking the
app icon in the quick launch bar after the PWA has been installed on the
user’s desktop, or long pressing on the app on Android. This capability
already exists for native apps on various platforms (Android, Linux, macOS,
and Windows).

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0

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

This feature was previously shipped for Windows and Android
https://groups.google.com/a/chromium.org/g/blink-dev/c/FgzYX7AFbUQ/m/f2i0-f-BAQAJ

Requesting approval to ship on Mac and Linux
https://bugs.chromium.org/p/chromium/issues/detail?id=1248101

Demo link

Test Website .

The enable-desktop-pwas-app-icon-shortcuts-menu-ui flag needs to be enabled.

Risks

Interoperability and Compatibility

No Interoperability/Compatibility risk. When a web developer doesn’t
provide a shortcuts member in the PWA’s WebAppManifest, current
installation behavior is not affected by this feature.

Edge: In development/Public Support

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive feedback from web developers

Ergonomics

Shortcuts will be used as part of the WebAppManifest. Use will not affect
performance.

Activation

Use will be straightforward, it will only require developers to list their
shortcuts in their manifest.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

Pre-existing manual WPT tests exist: appmanifest/shortcuts-member/

Entry on the feature dashboard

https://www.chromestatus.com/feature/5706099464339456

--
Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
650-797-1279 <(650)%20650-797-1279>

--
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/CAHB%2BDAgpD1v%2Bp0Y4HtXa43TiySyA_R0_%3Do4Dg4U1AJtQrQu_vQ%40mail.gmail.com.

[blink-dev] Intent to Ship: App Shortcuts Menu

2021-10-07 Thread 'Ajay Rahatekar' via blink-dev

Contact emails

mjack...@microsoft.com, mandy.c...@microsoft.com, est...@google.com,
ajayrahate...@google.com

Explainer

Shortcuts Explainer

Spec

W3C spec: https://w3c.github.io/manifest/#shortcuts-member

Tag Review: https://github.com/w3ctag/design-reviews/issues/510

Summary

This feature provides PWA developers the ability to show a shortcuts menu
of common tasks in their app. The menu can be invoked by right clicking the
app icon in the quick launch bar after the PWA has been installed on the
user’s desktop, or long pressing on the app on Android. This capability
already exists for native apps on various platforms (Android, Linux, macOS,
and Windows).

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0

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

This feature was previously shipped for Windows and Android
https://groups.google.com/a/chromium.org/g/blink-dev/c/FgzYX7AFbUQ/m/f2i0-f-BAQAJ

Requesting approval to ship on Mac and Linux
https://bugs.chromium.org/p/chromium/issues/detail?id=1248101

Demo link

Test Website .

The enable-desktop-pwas-app-icon-shortcuts-menu-ui flag needs to be enabled.

Risks

Interoperability and Compatibility

No Interoperability/Compatibility risk. When a web developer doesn’t
provide a shortcuts member in the PWA’s WebAppManifest, current
installation behavior is not affected by this feature.

Edge: In development/Public Support

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive feedback from web developers

Ergonomics

Shortcuts will be used as part of the WebAppManifest. Use will not affect
performance.

Activation

Use will be straightforward, it will only require developers to list their
shortcuts in their manifest.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

Pre-existing manual WPT tests exist: appmanifest/shortcuts-member/

Entry on the feature dashboard

https://www.chromestatus.com/feature/5706099464339456

--
Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
650-797-1279 <(650)%20650-797-1279>

--
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/CAHB%2BDAjkuxR3G-QvKh5_swJBNnLdPzV0Mnvod2qtJSCOOMcdtA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Auto Dark Mode & the CSS color-scheme “only” keyword

LGTM to experiment M96-M99 (inclusive)

On Thu, Oct 7, 2021 at 5:12 PM Peter Beverloo  wrote:

> Thanks Yoav!
>
> On Thu, Oct 7, 2021 at 8:15 AM Yoav Weiss  wrote:
>
>> This seems extremely useful!
>>
>> What are the timelines for experimentation? Do you have partners lined up
>> that are ready to play with this?
>>
>
> The experiment will start in M96, and will last until (& including M99).
> We have several partners lined up indeed.
>
> Also, the intent seems to be missing many fields (signals from other
>> vendors and developers, TAG review, etc)
>> Can you complete the missing ones from the Chrome status entry?
>>
>
> Yikes! Hereby:
>
> *Blink component*
> Blink>DarkMode
>
> *TAG review*
> CSS Color Adjust Level 1 has already seen a TAG review, but (re)inclusion
> of the "only" keyword was not part of that:
> https://github.com/w3ctag/design-reviews/issues/583
>
> We're still pursuing some additions for a more complete developer story
> (e.g. https://github.com/w3c/csswg-drafts/issues/6664) and will request
> review after that.
>
>
> *TAG review status*Not applicable
>
> *Interoperability and Compatibility*
>
> *Gecko*: No signal
> *WebKit*: No signal, although Web contents in Apple Mail on iOS supports
> a force dark mode.
>
>
Would be good to get such signals, but that's not blocking:
https://bit.ly/blink-signals


> *Web developers*: Mixed: we've received positive feedback regarding the
> decrease in cost of providing a dark mode with the availability of a
> per-element opt-out, but have also heard concerns about the quality of the
> darkening algorithms. This experiment will allow us to gather more data on
> both.
>
>
Makes sense.


>
> *Is this feature fully tested by web-platform-tests?*
> Yes, parsing tests are included in //css/css-color-adjust/.
>
> *Requires code in //chrome?*
> No.
>
> Thanks,
> Peter
>
>
>>
>> On Tue, Oct 5, 2021 at 10:18 PM Peter Beverloo 
>> wrote:
>>
>>> *Contact emails*
>>> futh...@chromium.org, p...@chromium.org, pe...@chromium.org
>>>
>>> *Spec*
>>> https://drafts.csswg.org/css-color-adjust/#color-scheme-prop
>>>
>>> *Summary*
>>> This Origin Trial covers two pieces of related functionality:
>>>
>>> First, websites that decide to participate in this trial will have their
>>> appearance algorithmically adjusted to be darkened, and thus appropriate
>>> for display whilst a device is in Dark Mode. Rendered colors will have
>>> their lightness adjusted to appear dark, and images will be classified,
>>> where images will be classified first based on their size and properties,
>>> then by a machine learning model to help distinguish iconography from
>>> photos and other images.
>>>
>>> Second, support for the CSS color-scheme “only” keyword, which forbids
>>> the user agent from overriding the color scheme for an element. This
>>> enables participating websites to manually touch-up certain elements when
>>> the algorithm gets it wrong, which will happen.
>>>
>>> *Goals for experimentation*
>>> Modern operating systems, particularly mobile ones, feature extensive,
>>> platform-wide Dark Mode implementations. Dark Mode is the default,
>>> out-of-the-box experience on some Android devices, and automatically
>>> enabled during nighttime on many more.
>>>
>>> Early data is suggesting that dark themes use 10% less battery than
>>> light themes at 75% brightness, and suggest significant differences in user
>>> behaviour on websites that don’t provide a dark mode whilst the user’s
>>> device is in dark mode.
>>>
>>> However, we heard feedback from developers that one of the reasons why
>>> dark themes haven’t been more widely adopted on the web is the cost of
>>> creating and maintaining a second theme for web applications.
>>>
>>> With this Origin Trial for Auto Dark Mode, we’d like to experiment with
>>> both partners and developers to understand the impact of Dark Mode on their
>>> websites, and to understand the quality of our algorithms outside of our
>>> own testing environment.
>>>
>>> *Experimental timeline*
>>> The experiment will start in M96, and will last until (& including M99).
>>> Auto Dark Mode is already programmatically detectable by developers to
>>> inspect the computed styles, but we might want to iterate during the Origin
>>> Trial with an addition if the CSS working group agrees on one:
>>>
>>> https://github.com/w3c/csswg-drafts/issues/6664
>>>
>>> *Any risks when the experiment finishes?*
>>> No, websites will revert back to their original appearance.
>>>
>>> *Ongoing technical constraints*
>>> Auto Dark Mode in particular is a fairly intrusive feature, but builds
>>> upon the force dark mode feature already launched for Android WebView.
>>>
>>> *Debuggability*
>>> Developers already have the ability to test this functionality on their
>>> pages by opening DevTools, selecting the Rendering option in "More tools",
>>> and then emulating Auto Dark Mode.
>>>
>>> Users and developers alike have the ability to enable this functionality
>>> for all websites throu

[blink-dev] Promise to blobs in Clipboard

2021-10-07 Thread 'Joe Medley' via blink-dev

Anupam,

Thank you for letting me know. This is off my list.

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


On Wed, Oct 6, 2021 at 2:27 PM Anupam Snigdha 
wrote:

> Hey Joe,
>
> I don't think I would be able to land the change for Add support for
> Promise to Blobs in clipboard item
>  by tomorrow so
> this probably is not going to ship in 96. I'll make the changes in the
> status entry as well.
>
> -Anupam
>
> On Wed, Oct 6, 2021 at 6:54 AM 'Joe Medley' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Thank you.
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Tue, Oct 5, 2021 at 8:07 AM Diego González  wrote:
>>
>>> Hola Joe,
>>>
>>> No, the feature you link to is Protocol Handlers. The one I am referring
>>> to is URL Handling
>>> .  This is the
>>> relevant Chrome OT entry
>>> 
>>> .
>>>
>>> Diego
>>> On Tuesday, 5 October 2021 at 15:36:02 UTC+1 Joe Medley wrote:
>>>
 This is exactly the kind of information I need.

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

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

 Joe

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

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

> Hola Joe,
>
> Just in case this info is useful to you for the post, I wanted to let
> you know Window Controls Overlay was planned to launch in 96 but we added
> an extra cycle to the OT and now it is launching in 97.
>
> Also missing from this list is URL Handlers
> ,
> which is expected in 97, even though there are changes coming to the
> feature to be substituted by `handle_links` `scope_extensions` and
> `launch_handler`.
>
> -Diego
>
> On Thursday, 30 September 2021 at 17:51:53 UTC+1 Joe Medley wrote:
>
>> Gang,
>>
>> I apologize for sending this a week late.
>>
>> Chrome 96 is planned for beta on October 21. Developer Relations
>> needs information to help us plan. We want a complete list of everything
>> in Chrome beta for the beta post
>> . We try when possible
>> to have articles for important new features on web.dev
>> .
>>
>> Please let me know of anything that might be shipping in Chrome 96
>> or 97. I don't care if it's a new API, a bug to add a missing interface
>> member, a spec change or whatever. I need to know all of it. If you have
>> any questions about this, just ask, or refer to the FAQ in my 
>> communication
>> instructions
>> 
>> .
>>
>> Also, please make sure your Chrome Status entries reflect the
>> current state of your feature. Origin trial and shipping milestone 
>> numbers
>> may be edited by clicking the "Edit all fields" link and scrolling down 
>> the
>> page.
>>
>> The list of what I currently believe to be shipping is in this
>> spreadsheet
>> .
>> For those who can't reach it, here's a summary.
>>
>> (Deprecations and removals are in red.)
>>
>> 103 Early Hints for Navigation
>> 
>> Add support for Promise to Blobs in clipboard item
>> 
>> App history API
>> 
>> Attribution Reporting API
>> 
>> Auto-expand details elements
>> 
>> (Block external protocol in sandboxed iframe.)
>> 
>> Capability Delegation
>> 
>> COEP for shared worker
>>

Re: [blink-dev] Intent to Experiment: Auto Dark Mode & the CSS color-scheme “only” keyword

2021-10-07 Thread Peter Beverloo

Thanks Yoav!

On Thu, Oct 7, 2021 at 8:15 AM Yoav Weiss  wrote:

> This seems extremely useful!
>
> What are the timelines for experimentation? Do you have partners lined up
> that are ready to play with this?
>

The experiment will start in M96, and will last until (& including M99). We
have several partners lined up indeed.

Also, the intent seems to be missing many fields (signals from other
> vendors and developers, TAG review, etc)
> Can you complete the missing ones from the Chrome status entry?
>

Yikes! Hereby:

*Blink component*
Blink>DarkMode

*TAG review*
CSS Color Adjust Level 1 has already seen a TAG review, but (re)inclusion
of the "only" keyword was not part of that:
https://github.com/w3ctag/design-reviews/issues/583

We're still pursuing some additions for a more complete developer story
(e.g. https://github.com/w3c/csswg-drafts/issues/6664) and will request
review after that.


*TAG review status*Not applicable

*Interoperability and Compatibility*

*Gecko*: No signal
*WebKit*: No signal, although Web contents in Apple Mail on iOS supports a
force dark mode.
*Web developers*: Mixed: we've received positive feedback regarding the
decrease in cost of providing a dark mode with the availability of a
per-element opt-out, but have also heard concerns about the quality of the
darkening algorithms. This experiment will allow us to gather more data on
both.


*Is this feature fully tested by web-platform-tests?*
Yes, parsing tests are included in //css/css-color-adjust/.

*Requires code in //chrome?*
No.

Thanks,
Peter


>
> On Tue, Oct 5, 2021 at 10:18 PM Peter Beverloo  wrote:
>
>> *Contact emails*
>> futh...@chromium.org, p...@chromium.org, pe...@chromium.org
>>
>> *Spec*
>> https://drafts.csswg.org/css-color-adjust/#color-scheme-prop
>>
>> *Summary*
>> This Origin Trial covers two pieces of related functionality:
>>
>> First, websites that decide to participate in this trial will have their
>> appearance algorithmically adjusted to be darkened, and thus appropriate
>> for display whilst a device is in Dark Mode. Rendered colors will have
>> their lightness adjusted to appear dark, and images will be classified,
>> where images will be classified first based on their size and properties,
>> then by a machine learning model to help distinguish iconography from
>> photos and other images.
>>
>> Second, support for the CSS color-scheme “only” keyword, which forbids
>> the user agent from overriding the color scheme for an element. This
>> enables participating websites to manually touch-up certain elements when
>> the algorithm gets it wrong, which will happen.
>>
>> *Goals for experimentation*
>> Modern operating systems, particularly mobile ones, feature extensive,
>> platform-wide Dark Mode implementations. Dark Mode is the default,
>> out-of-the-box experience on some Android devices, and automatically
>> enabled during nighttime on many more.
>>
>> Early data is suggesting that dark themes use 10% less battery than light
>> themes at 75% brightness, and suggest significant differences in user
>> behaviour on websites that don’t provide a dark mode whilst the user’s
>> device is in dark mode.
>>
>> However, we heard feedback from developers that one of the reasons why
>> dark themes haven’t been more widely adopted on the web is the cost of
>> creating and maintaining a second theme for web applications.
>>
>> With this Origin Trial for Auto Dark Mode, we’d like to experiment with
>> both partners and developers to understand the impact of Dark Mode on their
>> websites, and to understand the quality of our algorithms outside of our
>> own testing environment.
>>
>> *Experimental timeline*
>> The experiment will start in M96, and will last until (& including M99).
>> Auto Dark Mode is already programmatically detectable by developers to
>> inspect the computed styles, but we might want to iterate during the Origin
>> Trial with an addition if the CSS working group agrees on one:
>>
>> https://github.com/w3c/csswg-drafts/issues/6664
>>
>> *Any risks when the experiment finishes?*
>> No, websites will revert back to their original appearance.
>>
>> *Ongoing technical constraints*
>> Auto Dark Mode in particular is a fairly intrusive feature, but builds
>> upon the force dark mode feature already launched for Android WebView.
>>
>> *Debuggability*
>> Developers already have the ability to test this functionality on their
>> pages by opening DevTools, selecting the Rendering option in "More tools",
>> and then emulating Auto Dark Mode.
>>
>> Users and developers alike have the ability to enable this functionality
>> for all websites through a flag which can be found on
>> chrome://flags/#enable-force-dark.
>>
>
> Neat!
>
>
>>
>> *Will this feature be supported on all five Blink platforms supported by
>> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?*
>> The Origin Trial will be available for Android only.
>>
>> There are no strict technical reasons for this, but given that the
>> fu

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

2021-10-07 Thread Yutaka Hirano

On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano  wrote:

>
>
> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
> wrote:
>
>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>> wrote:
>>
>>> Thank you!
>>>
>>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
 wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of questions,
 but am pretty convinced we should ship this, it's just a matter of what
 things need to block that, and what things can be left until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
 wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see
 multiple issues filed by other browser vendors. Are any of the 
 remaining
 issues ones that could change the API's shape or behavior? It would be 
 good
 to resolve any such issues, since they won't be possible to address 
 once
 the API is locked in by sites depending on it.


>>> I believe we've addressed issues that may require breaking changes.
>>> You can see open /
>>> closed  issues
>>> for the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the
>> remaining issue in https://github.com/w3c/webtransport/milestone/1
>> not blocking then, even issue #349
>> ?
>>
>
> *Except for issue #349* we have consensus on discussions. As Victor
> commented in this thread, we can ship WebTransport *except for *
> customeCertificationHashes
> 
>  if
> needed.
>

 If custom certificates is a nice-to-have then shipping without it seems
 fine to me. That would mean removing serverCertificateHashes from the
 dictionary, right? I ask because the spec also says something
 about NotSupportedError when the protocol doesn't support it, but it seems
 better to behave as if the feature doesn't exist at all.


>>> The property is protected by WebTransportCustomCertificates
>>> ,
>>> so when we enable only WebTransport, the property will be invisible.
>>>
>>
>> Great, thanks for confirming!
>>
>>
>>> Looking through some other issues:

- Can https://github.com/w3c/webtransport/issues/59 be resolved for
the WebPKI case? If CSP currently has no effect, then adding it on later
could be hard because some sites could already be using CSP that would
block it, and those sites would be broken by adding CSP support later.


>>> Yes I think so. We check the "connect-src" directive. It is tested as
>>> csp-fail.https.window.js
>>> 
>>> and csp-pass.window.js
>>> 
>>> .
>>>
>>
>> That's good, the risk I was worried about doesn't exist then. Would you
>> consider that this behavior is required by some spec, even though it's not
>> mentioned in https://w3c.github.io/webtransport/? If not, then do you
>> think it's reasonable to prioritize the spec work for this before this
>> reaches stable?
>>
>
> This behavior should be specified, and yes I think that effo

Re: [blink-dev] Intent to Ship: interactionID in Event Timing

2021-10-07 Thread Nicolás Peña



On Thursday, October 7, 2021 at 1:58:59 AM UTC-4 Yoav Weiss wrote:

> On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña  wrote:
>
>> Contact emails
>>
>> n...@chromium.org, hbs...@chromium.org
>>
>> Explainer
>>
>> https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777
>>
>> Specification
>>
>>
>> https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid
>>
>> Summary
>>
>> Developers currently use the Event Timing API to gather performance data 
>> about events they care about. However, it is currently hard to link events 
>> that correspond to the same user interaction. For instance, when a user 
>> taps, many events are generated, such as pointerdown, mousedown, pointerup, 
>> mouseup, and click. The interactionID enables developers to link multiple 
>> PerformanceEventTiming entries when they correspond to the same user 
>> interaction.
>>
>> Blink component
>>
>> Blink>PerformanceAPIs 
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/670
>>
>> TAG review status
>>
>> Open
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The main interop risk is that this feature does not become implemented in 
>> other browsers. This is an attribute in a performance feature so even if 
>> this is not implemented there websites using this feature should not break 
>> in any way.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/283) Updated the 
>> Event Timing issue to note this addition.
>>
>> WebKit: Negative (
>> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) 
>> This is a negative on Event Timing as a whole, so we consider this to be 
>> negative for this feature in particular.
>>
>> Web developers: No signals. We presented this to WebPerf WG 
>> https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html
>>  
>>
> My read of the minutes is that there was a developer need for grouping 
> interactions, but even more demand (at least from the folks in the room) 
> for scroll grouping. Is that accurate?
>

Yea, that is accurate.
 

>  
>
>>
>> Ergonomics
>>
>> N/A
>>
>>
>> Activation
>>
>> Seems tricky to impossible to polyfill, so developers would need to use 
>> the API in order to obtain the more accurate data. 
>>
>>
>> Security
>>
>> One consideration was whether it is ok to expose the number of 
>> interactions that have occurred in the page. This is already observable via 
>> event handlers. Cross-origin events are not exposed.
>>
>>
>> Debuggability
>>
>> Use PerformanceObserver in the console. We don't have concrete plans to 
>> add Event Timing support in DevTools yet, but maybe in the future. Lab 
>> tools in general do not currently have great support for user inputs.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html
>>  
>>
>> Flag name
>>
>> InteractionId
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1236758
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1245771
>>
>> Estimated milestones
>>
>> 96
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://www.chromestatus.com/feature/5674224959094784
>>
>> 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/ec282b39-cd45-46f1-a542-cbdc7354347an%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/fba89573-6d31-416e-b054-2dadb07d4debn%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Allow simple Range header values without preflight

On Thu, Oct 7, 2021 at 11:58 AM Rayan Kanso  wrote:

> Can we ask WebKit folks for a signal?
>
>
> There's this bug  filed
> against WebKit. I'm not aware of any other channels to get feedback.
>

https://bit.ly/blink-signals


>
> On Thu, Oct 7, 2021 at 8:24 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Oct 6, 2021 at 10:22 PM Mike Taylor 
>> wrote:
>>
>>> On 10/5/21 6:50 AM, Rayan Kanso wrote:
>>>
>>> Contact emails rayank...@chromium.org, jakearchib...@chromium.org
>>>
>>> Specification https://fetch.spec.whatwg.org/
>>> Diff: https://github.com/whatwg/fetch/pull/1312
>>>
>>> Summary
>>>
>>> Allows requests with simple range headers to go through without
>>> preflight. CORS requests will be able to use the Range header in limited
>>> ways (having only one valid range) without triggering a preflight.
>>>
>>> Blink component Blink>SecurityFeature>CORS
>>> 
>>>
>>> TAG review Not applicable - this is a simple amendment that does not
>>> require an architectural review.
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>> Gecko: Positive
>>> 
>>>
>>>
>> Also, this doesn't count as a positive Mozilla position. I agree it's a
>> good signal, and am not sure we need to file for an official position
>> though.
>>
>>>
>>>
>>> WebKit: No signal
>>>
>>> Can we ask WebKit folks for a signal?
>>>
>>>
>>> Web developers: No signal
>>>
>>>
>>> Debuggability N/A
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? https://github.com/web-platform-tests/wpt/pull/31058
>>>
>>> Flag name N/A
>>>
>>> Requires code in //chrome? False
>>>
>>> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1255711
>>>
>>> Estimated milestones
>>>
>>> M96/M97
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5652396366626816
>>> --
>>> 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/CAAe2mZ1N0Oqz%3DVgEm%2BFQdJBVJCQbG%3Dv-6aO_JqRzm-9uBeQ%3Dfg%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/83e97b2b-cad3-07fc-747e-24a786b89ccd%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/CAL5BFfXjEvYT0OP%3Df1U0sZ7cAcrKx9LYWyVS3GEUv4rnqRx3dw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

2021-10-07 Thread 'Munira Tursunova' via blink-dev



> Looking at the font-synthesis-* tests in 
https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned, 
many pass in Firefox and Safari, but not all of them. Do all of these tests 
pass with the implementation now in Blink?

Yes, they do. Actually these tests had been added with the Chrome 
implementation and they are responsible for longhands for font-synthesis 
property which is not supported by other browsers yet.

> In the chromestatus entry I see "There are additional tests for system 
fonts with platform specific results, so we keep those as internal tests." 
Is the problem there that the tests rely on system fonts, or that there are 
platform-specific results? The latter is possible with WPT using the 
regular third_party/blink/web_tests/platform/ expectations. For system 
fonts, perhaps these tests could be written to pass if the fonts aren't 
present? If these are testharness.js tests, 
https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
 
might be a path forward.

Yes, they rely on particular aspects of which fonts are available on the 
system. As the font-synthesis property, when applied to system fonts, is 
closely connected to font matching and identifying whether a true bold / 
true italic variant exists, it’d be hard to make those flexible in terms of 
a default passing when the font does not exist. They are ref tests for that 
purpose.

>Also, looking at 
https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
 
I wonder if small-caps is going to be supported? If that table is correct 
it's not supported by Safari and it's only just now coming to Firefox.

Yes, small-caps support was also implemented in Blink (as longhand and as 
part of the shorthand). Also I’m not sure if that table is correct because 
Safari also supports ‘small-caps’ (only as a keyword in the shorthand) . 
They just have a bug in ref for this test: 
https://wpt.fyi/results/css/css-fonts/font-synthesis-06.html?label=experimental&label=master&aligned

On Thursday, October 7, 2021 at 11:28:57 AM UTC+3 Philip Jägenstedt wrote:

> It's great to see this feature getting ready to ship, it's one of a 
> relatively small number of features already supported by Firefox and Safari 
> but not by Chromium browsers, so it's been on my radar :)
>
> I just have a few questions.
>
> Looking at the font-synthesis-* tests in 
> https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
>  
> many pass in Firefox and Safari, but not all of them. Do all of these tests 
> pass with the implementation now in Blink?
>
> In the chromestatus entry I see "There are additional tests for system 
> fonts with platform specific results, so we keep those as internal tests." 
> Is the problem there that the tests rely on system fonts, or that there are 
> platform-specific results? The latter is possible with WPT using the 
> regular third_party/blink/web_tests/platform/ expectations. For system 
> fonts, perhaps these tests could be written to pass if the fonts aren't 
> present? If these are testharness.js tests, 
> https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
>  
> might be a path forward.
>
> Also, looking at 
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
>  
> I wonder if small-caps is going to be supported? If that table is correct 
> it's not supported by Safari and it's only just now coming to Firefox.
>
> On Thu, Oct 7, 2021 at 9:59 AM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2021-10-07 09:08, Yoav Weiss wrote:
>>
>> *LGTM1*
>> Thanks for working on this!! This seems like an important thing to catch 
>> up on! 
>>
>>
>>
>> On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails 
>>>
>>> moo...@google.com, dr...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis
>>>
>>> Specification 
>>>
>>> https://drafts.csswg.org/css-fonts/#font-synthesis
>>>
>>> Summary 
>>>
>>> The font-synthesis CSS property controls whether user agents are allowed 
>>> to synthesize oblique, bold and small-caps font faces when a font family 
>>> lacks oblique, bold and small-caps faces, respectively.
>>>
>>>
>>> Blink component 
>>>
>>> Blink>Fonts 
>>> 
>>>
>>> TAG review status 
>>>
>>> Already shipped in other browsers, see below, no TAG review required.
>>>
>>> Risks 
>>>
>>> Interoperability and Compatibility Low, feature already shipped in 
>>> Firefox and Safari. 
>>>
>>> Expected graceful degradation if an engine has so far not implemented 
>>> this feature: if the font-synthesis: property is not understood by an 
>>> engine, this means unintended synthesis can occur. That's expected and the 
>>> reason why this

Re: [blink-dev] Intent to Implement and Ship: Allow simple Range header values without preflight

2021-10-07 Thread Rayan Kanso

>
> Can we ask WebKit folks for a signal?


There's this bug  filed
against WebKit. I'm not aware of any other channels to get feedback.

On Thu, Oct 7, 2021 at 8:24 AM Yoav Weiss  wrote:

>
>
> On Wed, Oct 6, 2021 at 10:22 PM Mike Taylor 
> wrote:
>
>> On 10/5/21 6:50 AM, Rayan Kanso wrote:
>>
>> Contact emails rayank...@chromium.org, jakearchib...@chromium.org
>>
>> Specification https://fetch.spec.whatwg.org/
>> Diff: https://github.com/whatwg/fetch/pull/1312
>>
>> Summary
>>
>> Allows requests with simple range headers to go through without
>> preflight. CORS requests will be able to use the Range header in limited
>> ways (having only one valid range) without triggering a preflight.
>>
>> Blink component Blink>SecurityFeature>CORS
>> 
>>
>> TAG review Not applicable - this is a simple amendment that does not
>> require an architectural review.
>>
>> Risks
>>
>> Interoperability and Compatibility
>> Gecko: Positive
>> 
>>
>>
> Also, this doesn't count as a positive Mozilla position. I agree it's a
> good signal, and am not sure we need to file for an official position
> though.
>
>>
>>
>> WebKit: No signal
>>
>> Can we ask WebKit folks for a signal?
>>
>>
>> Web developers: No signal
>>
>>
>> Debuggability N/A
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? https://github.com/web-platform-tests/wpt/pull/31058
>>
>> Flag name N/A
>>
>> Requires code in //chrome? False
>>
>> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1255711
>>
>> Estimated milestones
>>
>> M96/M97
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5652396366626816
>> --
>> 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/CAAe2mZ1N0Oqz%3DVgEm%2BFQdJBVJCQbG%3Dv-6aO_JqRzm-9uBeQ%3Dfg%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/83e97b2b-cad3-07fc-747e-24a786b89ccd%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/CAAe2mZ18AoZ7H3NxqX4Un-9nLm_p39AnvTW4d%2Bo4Aq47CF8mqg%40mail.gmail.com.

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

LGTM to experiment M97-M100 (inclusive)

On Thu, Oct 7, 2021 at 10:34 AM Elad Alon  wrote:

> Thanks for catching that typo. The corrected request is m97 - m100.
>
> On Thu, Oct 7, 2021 at 9:20 AM Yoav Weiss  wrote:
>
>> Do I understand correctly and you want to experiment for a single
>> milestone? (M97)
>>
>> On Tue, Oct 5, 2021 at 11:12 PM 'Elad Alon' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailselada...@chromium.org, mfo...@chromium.org,
>>> jop...@chromium.org
>>>
>>> Explainer
>>> https://github.com/eladalon1983/region-capture/blob/main/README.md
>>>
>>
When looking at the API, I found that it's unclear why a cropID is needed
(compared to using an element ID instead, or just passing the element to
`cropTo`). Would be good to further explain that.


>
>>>
>>> Specificationhttps://eladalon1983.github.io/region-capture/
>>>
>>
May be good to try and move the spec over to the WICG. I saw activity on
the related proposal , so it
may be good to get explicit support from folks that'd enable such a move.


>
>>>
>>> Summary
>>>
>>> Recall that applications may currently obtain a capture of the tab in
>>> which they run using getDisplayMedia, either with or without
>>> preferCurrentTab. Moreover, soon another API will allow similar
>>> functionality - getViewportMedia. In either case, the application may then
>>> also wish to crop the resulting video track so as to remove some content
>>> from it (typically before sharing it remotely). We introduce a performant
>>> and robust API for cropping a self-capture video track.
>>>
>>>
>>> Blink componentBlink
>>> 
>>>
>>> TAG reviewPending
>>>
>>
Plans to file for a TAG review?


>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>
Can you file for https://bit.ly/blink-signals?


>
>>> Web developers: No signals
>>>
>>> Ergonomics
>>>
>>> N/A
>>>
>>>
>>> Activation
>>>
>>> Should be relatively unchallenging to use.
>>>
>>>
>>> Security
>>>
>>> This is a mechanism by which an application purposefully strips away
>>> information which it already has access to (via pre-existing mechanisms
>>> such as getDisplayMedia).
>>>
>>>
>>> Goals for experimentation
>>>
>>> Evaluate the usefulness of the feature and gather Web-developer feedback
>>> about how it may improve.
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?No
>>>
>>> Supported on all desktop platforms, but not on mobile platforms, as the
>>> prerequisite API of getDisplayMedia is currently only available on desktop.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag nameRegionCapture
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1247761
>>>
>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1168076
>>>
>>> Estimated milestones
>>> OriginTrial desktop last 97
>>> OriginTrial desktop first 97
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/feature/5712447794053120
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dib14W1B0Xc
>>>
>>>
>>> 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/CAMO6jDPGYJBWv6xTaRPPAkCtCCU5RRhskk459kY4yhhsZtTSdg%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/CAL5BFfVTcKW562SCqsH_kouUkYd4wQuRgezjpfuA7uVB3sin-w%40mail.gmail.com.

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

2021-10-07 Thread Yutaka Hirano

On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
wrote:

> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
> wrote:
>
>> Thank you!
>>
>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>>> wrote:
>>>


 On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
 wrote:

> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
> wrote:
>
>> Hi Philip,
>>
>> Sorry for the belated reply. Comments inline:
>>
>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Hi again,
>>>
>>> I've made a full pass of the intent now. I have a lot of questions,
>>> but am pretty convinced we should ship this, it's just a matter of what
>>> things need to block that, and what things can be left until later.
>>>
>>> Comments inline...
>>>
>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>>> wrote:
>>>
 Contact emails

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

 Explainer

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

 Specification

 https://w3c.github.io/webtransport

 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

 https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

>>>
>>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>>> multiple issues filed by other browser vendors. Are any of the remaining
>>> issues ones that could change the API's shape or behavior? It would be 
>>> good
>>> to resolve any such issues, since they won't be possible to address once
>>> the API is locked in by sites depending on it.
>>>
>>>
>> I believe we've addressed issues that may require breaking changes.
>> You can see open /
>> closed  issues
>> for the initial launch (this intent).  I shared our plan
>> 
>>  at a WG meeting in May
>> 
>>  and
>> we've been working to find and resolve such issues since then.
>>
>
> I see, creating a milestone for this is really handy! Are the
> remaining issue in https://github.com/w3c/webtransport/milestone/1
> not blocking then, even issue #349
> ?
>

 *Except for issue #349* we have consensus on discussions. As Victor
 commented in this thread, we can ship WebTransport *except for *
 customeCertificationHashes
 
  if
 needed.

>>>
>>> If custom certificates is a nice-to-have then shipping without it seems
>>> fine to me. That would mean removing serverCertificateHashes from the
>>> dictionary, right? I ask because the spec also says something
>>> about NotSupportedError when the protocol doesn't support it, but it seems
>>> better to behave as if the feature doesn't exist at all.
>>>
>>>
>> The property is protected by WebTransportCustomCertificates
>> ,
>> so when we enable only WebTransport, the property will be invisible.
>>
>
> Great, thanks for confirming!
>
>
>> Looking through some other issues:
>>>
>>>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>>>the WebPKI case? If CSP currently has no effect, then adding it on later
>>>could be hard because some sites could already be using CSP that would
>>>block it, and those sites would be broken by adding CSP support later.
>>>
>>>
>> Yes I think so. We check the "connect-src" directive. It is tested as
>> csp-fail.https.window.js
>> 
>> and csp-pass.window.js
>> 
>> .
>>
>
> That's good, the risk I was worried about doesn't exist then. Would you
> consider that this behavior is required by some spec, even though it's not
> mentioned in https://w3c.github.io/webtransport/? If not, then do you
> think it's reasonable to prioritize the spec work for this before this
> reaches stable?
>

This behavior should be specified, and yes I think that effort should be
prioritized. I'm happy to work on that.


>
>
>>>- https://github.com/w3c/webtransport/issues/175 sounds editorial
>>>but doesn't have that label. If any code would change as a result of 
>

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

On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano  wrote:

> Thank you!
>
> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
> wrote:
>
>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
 wrote:

> Hi Philip,
>
> Sorry for the belated reply. Comments inline:
>
> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of questions,
>> but am pretty convinced we should ship this, it's just a matter of what
>> things need to block that, and what things can be left until later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>> multiple issues filed by other browser vendors. Are any of the remaining
>> issues ones that could change the API's shape or behavior? It would be 
>> good
>> to resolve any such issues, since they won't be possible to address once
>> the API is locked in by sites depending on it.
>>
>>
> I believe we've addressed issues that may require breaking changes.
> You can see open /
> closed  issues
> for the initial launch (this intent).  I shared our plan
> 
>  at a WG meeting in May
> 
>  and
> we've been working to find and resolve such issues since then.
>

 I see, creating a milestone for this is really handy! Are the remaining
 issue in https://github.com/w3c/webtransport/milestone/1 not blocking
 then, even issue #349 ?

>>>
>>> *Except for issue #349* we have consensus on discussions. As Victor
>>> commented in this thread, we can ship WebTransport *except for *
>>> customeCertificationHashes
>>> 
>>>  if
>>> needed.
>>>
>>
>> If custom certificates is a nice-to-have then shipping without it seems
>> fine to me. That would mean removing serverCertificateHashes from the
>> dictionary, right? I ask because the spec also says something
>> about NotSupportedError when the protocol doesn't support it, but it seems
>> better to behave as if the feature doesn't exist at all.
>>
>>
> The property is protected by WebTransportCustomCertificates
> ,
> so when we enable only WebTransport, the property will be invisible.
>

Great, thanks for confirming!


> Looking through some other issues:
>>
>>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>>the WebPKI case? If CSP currently has no effect, then adding it on later
>>could be hard because some sites could already be using CSP that would
>>block it, and those sites would be broken by adding CSP support later.
>>
>>
> Yes I think so. We check the "connect-src" directive. It is tested as
> csp-fail.https.window.js
> 
> and csp-pass.window.js
> 
> .
>

That's good, the risk I was worried about doesn't exist then. Would you
consider that this behavior is required by some spec, even though it's not
mentioned in https://w3c.github.io/webtransport/? If not, then do you think
it's reasonable to prioritize the spec work for this before this reaches
stable?


>>- https://github.com/w3c/webtransport/issues/175 sounds editorial but
>>doesn't have that label. If any code would change as a result of fixing 
>> it,
>>should this be done before shipping?
>>
>> I think this is to describe our current protection and won't affect
> implementation.
>
>
>>
>>- https://github.com/w3c/webtransport/issues/236 has no discussion,
>>could it have any impact on implementation?
>>
>> This is about how to describe algorithms in the spec

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

2021-10-07 Thread 'Elad Alon' via blink-dev

Thanks for catching that typo. The corrected request is m97 - m100.

On Thu, Oct 7, 2021 at 9:20 AM Yoav Weiss  wrote:

> Do I understand correctly and you want to experiment for a single
> milestone? (M97)
>
> On Tue, Oct 5, 2021 at 11:12 PM 'Elad Alon' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailselada...@chromium.org, mfo...@chromium.org,
>> jop...@chromium.org
>>
>> Explainer
>> https://github.com/eladalon1983/region-capture/blob/main/README.md
>>
>> Specificationhttps://eladalon1983.github.io/region-capture/
>>
>> Summary
>>
>> Recall that applications may currently obtain a capture of the tab in
>> which they run using getDisplayMedia, either with or without
>> preferCurrentTab. Moreover, soon another API will allow similar
>> functionality - getViewportMedia. In either case, the application may then
>> also wish to crop the resulting video track so as to remove some content
>> from it (typically before sharing it remotely). We introduce a performant
>> and robust API for cropping a self-capture video track.
>>
>>
>> Blink componentBlink
>> 
>>
>> TAG reviewPending
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> Ergonomics
>>
>> N/A
>>
>>
>> Activation
>>
>> Should be relatively unchallenging to use.
>>
>>
>> Security
>>
>> This is a mechanism by which an application purposefully strips away
>> information which it already has access to (via pre-existing mechanisms
>> such as getDisplayMedia).
>>
>>
>> Goals for experimentation
>>
>> Evaluate the usefulness of the feature and gather Web-developer feedback
>> about how it may improve.
>>
>> Debuggability
>>
>> N/A
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No
>>
>> Supported on all desktop platforms, but not on mobile platforms, as the
>> prerequisite API of getDisplayMedia is currently only available on desktop.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag nameRegionCapture
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1247761
>>
>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1168076
>>
>> Estimated milestones
>> OriginTrial desktop last 97
>> OriginTrial desktop first 97
>>
>> Link to entry on the Chrome Platform Status
>> https://www.chromestatus.com/feature/5712447794053120
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dib14W1B0Xc
>>
>>
>> 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/CAMO6jDPGYJBWv6xTaRPPAkCtCCU5RRhskk459kY4yhhsZtTSdg%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/CAMO6jDN1X2yOXG7_TuxjFbVFr-JUooAn8iHn8_OeNSOrGM9fzA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

It's great to see this feature getting ready to ship, it's one of a
relatively small number of features already supported by Firefox and Safari
but not by Chromium browsers, so it's been on my radar :)

I just have a few questions.

Looking at the font-synthesis-* tests in
https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned,
many pass in Firefox and Safari, but not all of them. Do all of these tests
pass with the implementation now in Blink?

In the chromestatus entry I see "There are additional tests for system
fonts with platform specific results, so we keep those as internal tests."
Is the problem there that the tests rely on system fonts, or that there are
platform-specific results? The latter is possible with WPT using the
regular third_party/blink/web_tests/platform/ expectations. For system
fonts, perhaps these tests could be written to pass if the fonts aren't
present? If these are testharness.js tests,
https://web-platform-tests.org/writing-tests/testharness-api.html#optional-features
might be a path forward.

Also, looking at
https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility
I wonder if small-caps is going to be supported? If that table is correct
it's not supported by Safari and it's only just now coming to Firefox.

On Thu, Oct 7, 2021 at 9:59 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2021-10-07 09:08, Yoav Weiss wrote:
>
> *LGTM1*
> Thanks for working on this!! This seems like an important thing to catch
> up on!
>
>
>
> On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> moon...@google.com, dr...@chromium.org
>>
>> Explainer
>>
>> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>>
>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis
>>
>> Specification
>>
>> https://drafts.csswg.org/css-fonts/#font-synthesis
>>
>> Summary
>>
>> The font-synthesis CSS property controls whether user agents are allowed
>> to synthesize oblique, bold and small-caps font faces when a font family
>> lacks oblique, bold and small-caps faces, respectively.
>>
>>
>> Blink component
>>
>> Blink>Fonts
>> 
>>
>> TAG review status
>>
>> Already shipped in other browsers, see below, no TAG review required.
>>
>> Risks
>>
>> Interoperability and Compatibility Low, feature already shipped in
>> Firefox and Safari.
>>
>> Expected graceful degradation if an engine has so far not implemented
>> this feature: if the font-synthesis: property is not understood by an
>> engine, this means unintended synthesis can occur. That's expected and the
>> reason why this property was designed.
>>
>> Signals
>>
>> Gecko: Shipped/Shipping (
>> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility)
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1706080
>>
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=144180)
>>
>> Web developers: No signals
>>
>> Activation
>>
>> None expected, feature already implemented in other browsers.
>>
>>
>> Debuggability
>>
>> Same as any other CSS property, css_properties.json will be rolled to
>> DevTools during development.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes, 36 new web tests pass: 16 new internal platform specific tests were
>> added, 12 new WPT tests were added and 8 existing WPT tests are now passing.
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=509989
>>
>> Sample links
>>
>> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://www.chromestatus.com/feature/5640605355999232
>>
>> 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/CAAO7W_AmPR6X7evqGz9P7bkW2ysRmr%3DqP4ajgGA%2BjOGfsp_FrA%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/

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

2021-10-07 Thread Yutaka Hirano

Thank you!

On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
wrote:

> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>>> wrote:
>>>
 Hi Philip,

 Sorry for the belated reply. Comments inline:

 On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
 wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of questions,
> but am pretty convinced we should ship this, it's just a matter of what
> things need to block that, and what things can be left until later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see
> multiple issues filed by other browser vendors. Are any of the remaining
> issues ones that could change the API's shape or behavior? It would be 
> good
> to resolve any such issues, since they won't be possible to address once
> the API is locked in by sites depending on it.
>
>
 I believe we've addressed issues that may require breaking changes. You
 can see open /closed
  issues for
 the initial launch (this intent).  I shared our plan
 
  at a WG meeting in May
 
  and
 we've been working to find and resolve such issues since then.

>>>
>>> I see, creating a milestone for this is really handy! Are the remaining
>>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
>>> then, even issue #349 ?
>>>
>>
>> *Except for issue #349* we have consensus on discussions. As Victor
>> commented in this thread, we can ship WebTransport *except for *
>> customeCertificationHashes
>> 
>>  if
>> needed.
>>
>
> If custom certificates is a nice-to-have then shipping without it seems
> fine to me. That would mean removing serverCertificateHashes from the
> dictionary, right? I ask because the spec also says something
> about NotSupportedError when the protocol doesn't support it, but it seems
> better to behave as if the feature doesn't exist at all.
>
>
The property is protected by WebTransportCustomCertificates
,
so when we enable only WebTransport, the property will be invisible.




> Looking through some other issues:
>
>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>the WebPKI case? If CSP currently has no effect, then adding it on later
>could be hard because some sites could already be using CSP that would
>block it, and those sites would be broken by adding CSP support later.
>
>
Yes I think so. We check the "connect-src" directive. It is tested as
csp-fail.https.window.js

and csp-pass.window.js

.


>- https://github.com/w3c/webtransport/issues/175 sounds editorial but
>doesn't have that label. If any code would change as a result of fixing it,
>should this be done before shipping?
>
> I think this is to describe our current protection and won't affect
implementation.


>
>- https://github.com/w3c/webtransport/issues/236 has no discussion,
>could it have any impact on implementation?
>
> This is about how to describe algorithms in the spec in terms of
threading, and this won't impact implementation.


>
>-
>
> Having consensus on the issues is great, but some things are still much
> harder to fix after shipping, or harder to get prioritized after shipping,
> so that's why I'm asking.
>
> Activation
>>
>> Since UDP is often blocked on the network, the developers have to
>> assume that the API often would not work even in the situations when it 
>> is
>> implemented in the browser.
>>
>
> This is interesting. How do web develope

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

LGTM2

/Daniel

On 2021-10-07 09:08, Yoav Weiss wrote:

*LGTM1*
Thanks for working on this!! This seems like an important thing to
catch up on!

On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev
wrote:

Contact emails

moon...@google.com, dr...@chromium.org

Explainer

https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro

https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis

Specification

https://drafts.csswg.org/css-fonts/#font-synthesis

Summary

The font-synthesis CSS property controls whether user agents are
allowed to synthesize oblique, bold and small-caps font faces when
a font family lacks oblique, bold and small-caps faces, respectively.

Blink component

Blink>Fonts

TAG review status

Already shipped in other browsers, see below, no TAG review required.

Risks

Interoperability and CompatibilityLow, feature already
shipped in Firefox and Safari.

Expected graceful degradation if an engine has so far not
implemented this feature: if the font-synthesis: property is not
understood by an engine, this means unintended synthesis can
occur. That's expected and the reason why this property was designed.

Signals

Gecko: Shipped/Shipping

(https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility

)
https://bugzilla.mozilla.org/show_bug.cgi?id=1706080

WebKit: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=144180
)

Web developers: No signals

Activation

None expected, feature already implemented in other browsers.

Debuggability

Same as any other CSS property, css_properties.json will be rolled
to DevTools during development.

Is this feature fully tested by web-platform-tests

Yes, 36 new web tests pass: 16 new internal platform specific
tests were added, 12 new WPT tests were added and 8 existing WPT
tests are now passing.

Requires code in //chrome?

False

Tracking bug

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

Sample links

https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5640605355999232

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/CAAO7W_AmPR6X7evqGz9P7bkW2ysRmr%3DqP4ajgGA%2BjOGfsp_FrA%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/CAL5BFfXyqaq60U%2BEzTWxYLhhZcW%3DyjZMetHjkgfmjpWibOWLxg%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/948ab999-2298-be47-ecab-d9585ea31b22%40gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebAssembly Content Security Policy


LGTM3

/Daniel

On 2021-10-07 09:25, Yoav Weiss wrote:

LGTM2

On Thu, Oct 7, 2021 at 12:11 AM 'Francis McCabe' via blink-dev 
 wrote:


Confirming: there is no current plan to modify how extensions
would work.
I was alluding to semi-solid thoughts on how a possible wasm-src
policy would work. But, in any case, wasm-unsafe-eval would
continue even without any new wasm-src.

Also, currently, extensions (and only extensions and chrome apps),
can use the 'wasm-eval' policy source keyword. There was a lot of
discussion about using wasm-eval for normal web pages but the
community eventually decided against doing that.

wasm-eval will continue to work for extensions. But, IMO, that
sets up a problem for the future. Chrome extensions will be able
to use wasm-eval; but noone else will (they will have to use
wasm-unsafe-eval, or, in the future, a wasm-src policy). I can see
there being some pressure to normalize this down the road.


On Wednesday, October 6, 2021 at 11:05:26 AM UTC-7
oli...@oliverdunk.com wrote:

Hey! Just to confirm, it seems like this change wouldn't
impact extensions at all? My understanding is that the current
implementation supports extensions by adding the
chrome-extension:// URL scheme to an allow-list. With that in
mind, I imagine the implementation here would be removing that
allow-list but keeping the behaviour for extensions otherwise
the same?

On Thursday, September 23, 2021 at 10:36:20 PM UTC+1 Francis
McCabe wrote:


Contact emails

ad...@chromium.org
f...@chromium.org


Explainer


https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md


Specification

https://github.com/w3c/webappsec-csp/pull/293


Design docs



https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md


Summary

Enhancements to Content Security Policy to improve
interoperability with WebAssembly.

The change involves adding a new CSP source keyword:
wasm-unsafe-eval that would allow a web page to compile
and execute WebAssembly modules.


Blink component

Blink



Search tags

wasm ,
webassembly
,
csp 


TAG review

Not needed in our view, as this is a very small change to
existing CSP functionality.


TAG review status



Risks



Interoperability and Compatibility



Gecko:
https://github.com/mozilla/standards-positions/issues/580

WebKit:

https://lists.webkit.org/pipermail/webkit-dev/2021-August/031974.html

Web developers: There has been a considerable amount of
discussion of this within the WebAppSec WG and there is
some pressure from developers to adopt this (see
https://bugs.chromium.org/p/chromium/issues/detail?id=841404 and
https://bugs.chromium.org/p/chromium/issues/detail?id=948834
and
https://bugs.chromium.org/p/chromium/issues/detail?id=915648)


Debuggability



Is this feature fully tested by web-platform-tests

?

Yes * CL
https://chromium-review.googlesource.com/c/chromium/src/+/3171519 
under
review


Flag name

Blink feature flag WebAssemblyCSP


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

M96


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5499765773041664

-- 
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/339519e8-ab1c-4a84-b332-dc49bdcd6b72n%40chromium.org

Re: [blink-dev] Intent to Implement and Ship: transform: perspective(none)

LGTM3, this is an easy case, an improvement to an existing feature already
on track to ship in another browser.

Although not part of our launch process, can I ask what documentation
updates will be needed here?
https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/perspective()
doesn't mention "none" at all, is that the page to update? If so, a new
entry in the compat table at the bottom of the page would also be a good
idea. If it's clear what needs to be done, would you mind filing issues at
https://github.com/mdn/content/issues and
https://github.com/mdn/browser-compat-data/issues? (Again, not a proper
part of our launch process, so optional.)

For WPT, indeed it looks like this is already passing in Firefox:
https://wpt.fyi/results/css/css-transforms/animation/transform-interpolation-001.html?label=experimental&label=master&aligned

On Thu, Oct 7, 2021 at 8:49 AM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> On 07/10/2021 08:07, Yoav Weiss wrote:
> > LGTM1
> >
> > On Mon, Oct 4, 2021 at 10:42 PM David Baron  > > wrote:
> >
> >
> > Contact emails
> >
> > dba...@chromium.org 
> >
> >
> > Explainer
> >
> > None
> >
> >
> > Specification
> >
> > https://drafts.csswg.org/css-transforms-2/#funcdef-perspective
> > 
> >
> >
> > Summary
> >
> > Implement support for a 'none' argument to the perspective()
> > function within the syntax of the CSS transform property. This
> > provides the perspective() function with a value that gives the
> > identity matrix. Its effect is as though the perspective() function
> > was given an argument that is infinite. This makes it easier (or, in
> > some cases, possible) to do animations involving the perspective()
> > function where one of the endpoints of the animation is the identity
> > matrix.
> >
> >
> >
> > Blink component
> >
> > Blink>CSS
> > <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
> >
> >
> > Search tags
> >
> > css , transform
> > , perspective
> > 
> >
> >
> > TAG review
> >
> > Not needed for a single value addition to a single function within a
> > CSS property.
> >
> >
> > TAG review status
> >
> > Not applicable
> >
> >
> > Risks
> >
> >
> >
> > Interoperability and Compatibility
> >
> >
> >
> > Gecko: Shipped/Shipping
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1725207
> > ) Will ship
> > very soon in Firefox 93.
> >
> > WebKit: No signal
> > (
> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025
> > <
> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025>)
> > Safari developers participated in the CSS Working Group discussion
> > about adding it and were ok with the addition. I recognize this
> > isn't an official signal, but this seems perhaps too small a feature
> > to ask for an explicit one.
> >
> >
> > Can you file a webkit bug for this?
> >
> >
> >
> > Web developers: Positive
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1723266#c2
> > ) this is
> > the one explicit signal from a developer that I could find
> >
> >
> > Debuggability
> >
> > Should be equally debuggable as existing values of the perspective()
> > function.
> >
> >
> >
> > Is this feature fully tested by web-platform-tests
> > <
> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
> >?
> >
> > Yes
> >
> >
> > Flag name
> >
> >
> >
> > Requires code in //chrome?
> >
> > False
> >
> >
> > Tracking bug
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1253596
> > 
> >
> >
> > Estimated milestones
> >
> > No milestones specified
> >
> >
> >
> > Link to entry on the Chrome Platform Status
> >
> > https://chromestatus.com/feature/5687325523705856
> > 
> >
> > 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 v

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

On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano  wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
>>> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of questions, but
 am pretty convinced we should ship this, it's just a matter of what things
 need to block that, and what things can be left until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
 wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
 issues filed by other browser vendors. Are any of the remaining issues ones
 that could change the API's shape or behavior? It would be good to resolve
 any such issues, since they won't be possible to address once the API is
 locked in by sites depending on it.

>>> I believe we've addressed issues that may require breaking changes. You
>>> can see open /closed
>>>  issues for
>>> the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the remaining
>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
>> then, even issue #349 ?
>>
>
> *Except for issue #349* we have consensus on discussions. As Victor
> commented in this thread, we can ship WebTransport *except for *
> customeCertificationHashes
> 
>  if
> needed.
>

If custom certificates is a nice-to-have then shipping without it seems
fine to me. That would mean removing serverCertificateHashes from the
dictionary, right? I ask because the spec also says something
about NotSupportedError when the protocol doesn't support it, but it seems
better to behave as if the feature doesn't exist at all.

Looking through some other issues:

   - Can https://github.com/w3c/webtransport/issues/59 be resolved for the
   WebPKI case? If CSP currently has no effect, then adding it on later could
   be hard because some sites could already be using CSP that would block it,
   and those sites would be broken by adding CSP support later.
   - https://github.com/w3c/webtransport/issues/175 sounds editorial but
   doesn't have that label. If any code would change as a result of fixing it,
   should this be done before shipping?
   - https://github.com/w3c/webtransport/issues/236 has no discussion,
   could it have any impact on implementation?

Having consensus on the issues is great, but some things are still much
harder to fix after shipping, or harder to get prioritized after shipping,
so that's why I'm asking.

Activation
>
> Since UDP is often blocked on the network, the developers have to
> assume that the API often would not work even in the situations when it is
> implemented in the browser.
>

 This is interesting. How do web developers detect and deal with this
 situation, and distinguish it from the network temporarily going down? I've
 skimmed https://web.dev/webtransport/ and it doesn't mention this kind
 of blocking, does this need to be highlighted in documentation and
 reference docs for WebTransport?

>>>
>>> For usual loading browsers detect the network conditions and choose the
>>> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar
>>> things in the future (on the other hand, we may end up asking web
>>> developers to detect it). Some people are working on WebTransport over
>>> HTTP/2 .
>>>
>>
>> With the implementation as it is now, what will the behavior be on a
>> network where UDP is blocked? Presumably the initial connection that serves
>> HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is
>> there any indication in the API that WebTransport is going to fail ahead of
>> time, or error that c

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

After talking to Nidhi offline, we can consider this intent on hold until 
the feedback is addressed.

On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:

> Hi, 
>
> Just as an update, we have received some feedback on our TAG review (
> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419), 
> and hence we are having some discussions and deciding on next best steps 
> accordingly.
>
> Best regards,
> Nidhi
>
> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju  wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:
>>
>>> The Web Serial API is also interested in this capability. See the note 
>>> on the abort algorithm when initializing the WritableStream 
>>> .
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome 
>>> 
>>>
>>>
>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson  
>>> wrote:
>>>


 On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  
 wrote:

>
>
> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell  
> wrote:
>
>> Incremental features often benefit from TAG guidance. I'd feel better 
>> if this intent at least cited prior TAG reviews in this area or filed an 
>> FYI (with potential for TAG to request full review).
>>
>> If it was covered in a previous review of WritableStreams, that would 
>> also be good to know.
>>
>
> This feature wasn't covered in a previous review of WritableStreams, 
> so I have filed a new TAG review: 
> https://github.com/w3ctag/design-reviews/issues/672
>  
>
>>
>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju  
>>> wrote:
>>>
 Contact emailsnidhij...@chromium.org, ri...@chromium.org, 
 yhir...@chromium.org

 Explainer
 https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
   

>>>

 Specification
 https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

 Summary

 The streams APIs provide ubiquitous, interoperable primitives for 
 creating, composing, and consuming streams of data. This change 
 permits an 
 underlying sink to rapidly abort an ongoing write or close when 
 requested 
 by the writer.


 Previously, when writer.abort() was called, a long-running write 
 would still have to continue to completion before the stream could be 
 aborted. With this change, the write can be aborted immediately.

>>>
>>> Am I correct in assuming that the stream developer would have to 
>>> change their code in order for that to happen, and if they won't, the 
>>> current behavior won't change?
>>>
>>
> Yes, that's correct.
>
>  
>>>
 In addition to being exposed to streams authored in JavaScript, 
 this facility will also be used by platform-provided streams such as 
 WebTransport.

 Blink componentBlink>Network>StreamsAPI 
 

 TAG reviewNot needed as this is an incremental improvement to an 
 existing feature.

 TAG review statusNot applicable

 Risks
 Interoperability and Compatibility

 Low risk because streams has already been standardised for a long 
 time (since around 2014). Other browsers have implemented other parts 
 of 
 the standard, and they will most likely also adapt this feature as 
 well 
 soon.

 Gecko: Positive (
 https://github.com/whatwg/streams/pull/1132#issuecomment-867114529 
 )
  
 Mozilla is supportive of Streams but has not yet shipped 
 WritableStream. It 
 is expected that they will include this feature when they do. They 
 have 
 also expressed interest in implementing WebTransport, and therefore 
 are 
 supportive of this feature.

>>>
>>> While such comments don't typically count as a position, combining 
>>> them with https://github.com/mozilla/standards-positions/issues/167 
>>> seems reasonable, given the size of this change.
>>>
>>
 That said, could you comment on issue 167 giving at least an FYI that 
 this intent is happening?

>>>
>> Yes, I just left a comment on the issue. (
>> https://github.com/mozilla/standards-positions/issues/167#issuecomment-912184900
>> )
>>  
>>
>>>  

>  
>>>

 WebKit: No signal

>>>
>>>

[blink-dev] Re: Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

+1 to Mike's request. I think a Fetch PR for this seems both useful and 
not-extremely-onerous to pull together.

On Thursday, September 30, 2021 at 9:20:23 PM UTC+2 Mike West wrote:

> This all looks good, thanks.
>
> I'd like to see the Fetch PR up before we ship this. It's a little 
> surprising that neither WebKit nor Gecko wired that up, but if we have 
> three interoperable implementations, it should be quite straightforward to 
> specify.
>
> I also wonder a little about WPT; we should probably at least file a `
> type:untestable 
> `
>  
> issue to point to this as something that's not feasible to validate without 
> additional WebDriver support.
>
> -mike
>
>
> On Thu, Sep 30, 2021 at 4:42 PM Eric Orth  wrote:
>
>>
>>
>> On Thu, Sep 30, 2021 at 6:53 AM Kaustubha Govind  
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 28, 2021, 2:08 PM Eric Orth  wrote:
>>>


 On Tue, Sep 28, 2021 at 1:13 PM Eric Orth  
 wrote:

>
>
> On Tue, Sep 28, 2021 at 6:09 AM Mike West  wrote:
>
>> Hey Eric!
>>
>> On Thu, Sep 23, 2021 at 10:36 PM Eric Orth  
>> wrote:
>>
>>> Contact emails
>>>
>>> erico...@chromium.org
>>>
>>> Explainer
>>>
>>> None
>>>
>>> Specification
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
>>>
>>> Summary
>>>
>>> Query DNS for HTTPS records (alongside traditional A and  
>>> queries). When a website has deployed an HTTPS DNS record and Chrome 
>>> receives it, Chrome will always connect to the website via HTTPS.
>>>
>>> Design doc for all Chrome DNS HTTPS plans: 
>>> https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
>>>
>>> This feature covers just the basic query and HTTP->HTTPS upgrade 
>>> part of those plans, and only for simpler cases that do not require 
>>> followup DNS queries by the Chrome DNS stack.
>>>
>>>
>>> Blink component
>>>
>>> Internals>Network>DNS 
>>> 
>>>
>>> TAG review
>>>
>>> Not applicable. No direct changes to web platform APIs. Change is to 
>>> underlying DNS infrastructure, following an IETF spec, with only 
>>> indirect 
>>> web-facing side effects.
>>>
>>
>> This seems like an overly narrow take on the feature: it seems like 
>> this needs to be wired up to Fetch in order to explain how the DNS 
>> assertion turns into a decision about how to connect to sites (similar 
>> to HSTS's 
>> integration 
>> ),
>>  
>> and that upgrade will have web-visible impacts. 
>>
>
> Seems accurate to me.  All the signals and triggering happen in DNS, 
> outside web platform APIs, with no direct web-platform-API interaction, 
> e.g. a header like was done for HSTS.  Then the result is a redirect, 
> which 
> yes, is web-visible, hence the "indirect web-facing side effects".
>
> But I think you are right that this should get at least a mention in 
> the Fetch spec, and I think the ideal situation would be a single 
> additional sentence in that point about HSTS upgrade ("[...] or a DNS 
> lookup for the request's current URL per [link to section 8.5 of SVCB 
> RFC] 
> returns an HTTPS DNS record." or something like that).  Does that sound 
> reasonable to you, or do you think this will take more comprehensive 
> updates to Fetch?
>  
>
>> Can I assume that you'll be following the same algorithm (e.g. 
>> shifting from 80 to 443 by switching the protocol, but not altering 
>> non-standard ports)?
>>
>
> Correct.  Non-standard ports result in a redirect to https with the 
> same non-standard port.  Also noteworthy that non-standard ports would 
> require the HTTPS DNS record to be specific to that non-standard port, 
> e.g. 
> if the request URL were "http://example.com:1234";, the redirect will 
> only happen if there is an HTTPS record for DNS queries for "_1234._
> https.example.com", not merely at "example.com" as would be 
> sufficient if the request URL were "http://example.com[:80]";.
>  
>
>>
>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Not directly part of the web API surface; only has indirect behavior 
>>> implications on the web platform in the form of the HTTP->HTTPS 
>>> redirect 
>>> triggered by DNS signals.
>>>
>>> HTTPS DNS records are a feature of DNS.  The spec is a draft of the 
>>> IETF DNSOP working group, and while no

Re: [blink-dev] Intent to Extend Origin Trial: Early Hints preload/preconnect during Navigation

LGTM to extend to M98. 5 milestones overall seems reasonable.

On Thu, Oct 7, 2021 at 8:39 AM Kenichi Ishibashi  wrote:

> We would like to extend Early Hints preload/preconnect Origin Trial to M98
> (originally planned to end in M96).
>
> Contact emailsba...@chromium.org, yhir...@chromium.org,
> denom...@chromium.org
>
> Explainer
> https://github.com/bashi/early-hints-explainer/blob/main/explainer.md
>
> Specificationhttps://tools.ietf.org/html/rfc8297
>
> Design docs
>
> https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing
>
> Summary
>
> Support 103 Early Hints informational responses for navigation. When a 103
> response includes  or other link headers Chromium tries
> to preload (and/or preconnect, prefetch) specified resources even before
> the final response is received. This gives Web developers a way to optimize
> Core Web Vitals such as Largest Contentful Paint (LCP).
>
>
> Blink componentInternals>Preload
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/638
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> Several servers/proxies may not understand a 103 response. They may treat
> the 103 response as a part of the final response when the response is sent
> over HTTP/1.1. The problem is less likely to happen over HTTP/2 thanks to
> their frame format. Chromium only handles 103 responses over HTTP/2 and
> HTTP/3.
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/134)
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html)
>
> Web developers: Positive (
> https://www.fastly.com/blog/faster-websites-early-priority-hints) Web
> developers: Positive (
> https://www.fastly.com/blog/faster-websites-early-priority-hints)
> Positive interest and intent of support by popular CDNs. We've been
> collaborating with Fastly to do the preliminary measurement.
>
>
> Goals for experimentation
>
> Allows web developers to opt-in Early Hints preloads. We use custom page
> load metrics (FCP, LCP FID) to measure performance impact.
>
>
> Reason this experiment is being extended
>
> We added preconnect support in M95 based on Web developer's feedback and
> we are now evaluating the impact of preload and preconnect. We realized
> that we need more time to evaluate the impact of this feature. We have
> partners lined up for the feature and we expect to get more data in coming
> months.
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> If a resource is preloaded by Early Hints, the corresponding
> PerformanceResourceTiming object reports initiatorType is "early-hints".
> For more details, see
> https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/early-hints.md#checking-early-hints-preload-is-working
>
>
> 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
>
> Flag nameEarlyHintsPreloadForNavigation
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/671310
>
> Launch bughttps://crbug.com/1197989
>
> Estimated milestones
> OriginTrial desktop last 95 → *98*
> OriginTrial desktop first 94
> OriginTrial android last 95 → *98*
> OriginTrial android first 94
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5207422375297024
>
> Links to previous Intent discussionsIntent to Experiment:
> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/xb_NHDS3twY
>
>
> 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/CAPLXX-8G77uvOt6%3DomTRhQBS%2BcmxB6UaAbeeHiKRRumMPnd8bg%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/CAL5BFfVyegQjZEym1T9Nq9e%3D0BR8U6DLZjnbTFCWLuzKnL_%2BLQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebAssembly Content Security Policy

LGTM2

On Thu, Oct 7, 2021 at 12:11 AM 'Francis McCabe' via blink-dev <
blink-dev@chromium.org> wrote:

> Confirming: there is no current plan to modify how extensions would work.
> I was alluding to semi-solid thoughts on how a possible wasm-src policy
> would work. But, in any case, wasm-unsafe-eval would continue even without
> any new wasm-src.
>
> Also, currently, extensions (and only extensions and chrome apps), can use
> the 'wasm-eval' policy source keyword. There was a lot of discussion about
> using wasm-eval for normal web pages but the community eventually decided
> against doing that.
>
> wasm-eval will continue to work for extensions. But, IMO, that sets up a
> problem for the future. Chrome extensions will be able to use wasm-eval;
> but noone else will (they will have to use wasm-unsafe-eval, or, in the
> future, a wasm-src policy). I can see there being some pressure to
> normalize this down the road.
>
>
> On Wednesday, October 6, 2021 at 11:05:26 AM UTC-7 oli...@oliverdunk.com
> wrote:
>
>> Hey! Just to confirm, it seems like this change wouldn't impact
>> extensions at all? My understanding is that the current implementation
>> supports extensions by adding the chrome-extension:// URL scheme to an
>> allow-list. With that in mind, I imagine the implementation here would be
>> removing that allow-list but keeping the behaviour for extensions otherwise
>> the same?
>>
>> On Thursday, September 23, 2021 at 10:36:20 PM UTC+1 Francis McCabe wrote:
>>
>>> Contact emailsad...@chromium.org
>>> f...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md
>>>
>>> Specificationhttps://github.com/w3c/webappsec-csp/pull/293
>>>
>>> Design docs
>>>
>>> https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md
>>>
>>> Summary
>>>
>>> Enhancements to Content Security Policy to improve interoperability with
>>> WebAssembly.
>>> The change involves adding a new CSP source keyword: wasm-unsafe-eval
>>> that would allow a web page to compile and execute WebAssembly modules.
>>>
>>> Blink componentBlink
>>> 
>>>
>>> Search tagswasm ,
>>> webassembly ,
>>> csp 
>>>
>>> TAG reviewNot needed in our view, as this is a very small change to
>>> existing CSP functionality.
>>>
>>> TAG review status
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> Gecko: https://github.com/mozilla/standards-positions/issues/580
>>>
>>> WebKit:
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031974.html
>>>
>>> Web developers: There has been a considerable amount of discussion of
>>> this within the WebAppSec WG and there is some pressure from developers to
>>> adopt this (see
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=841404 and
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=948834 and
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=915648)
>>>
>>>
>>> Debuggability
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes * CL
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3171519 under
>>> review
>>>
>>> Flag nameBlink feature flag WebAssemblyCSP
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=841404
>>>
>>> Estimated milestones
>>>
>>> M96
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/feature/5499765773041664
>>>
>> --
> 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/339519e8-ab1c-4a84-b332-dc49bdcd6b72n%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/CAL5BFfWaXo5d362EEhmtcHAMtmJPPqc9rOk2J9N_58mzELnG9A%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: Allow simple Range header values without preflight

On Wed, Oct 6, 2021 at 10:22 PM Mike Taylor  wrote:

> On 10/5/21 6:50 AM, Rayan Kanso wrote:
>
> Contact emails rayank...@chromium.org, jakearchib...@chromium.org
>
> Specification https://fetch.spec.whatwg.org/
> Diff: https://github.com/whatwg/fetch/pull/1312
>
> Summary
>
> Allows requests with simple range headers to go through without preflight.
> CORS requests will be able to use the Range header in limited ways (having
> only one valid range) without triggering a preflight.
>
> Blink component Blink>SecurityFeature>CORS
> 
>
> TAG review Not applicable - this is a simple amendment that does not
> require an architectural review.
>
> Risks
>
> Interoperability and Compatibility
> Gecko: Positive
> 
>
>
Also, this doesn't count as a positive Mozilla position. I agree it's a
good signal, and am not sure we need to file for an official position
though.

>
>
> WebKit: No signal
>
> Can we ask WebKit folks for a signal?
>
>
> Web developers: No signal
>
>
> Debuggability N/A
>
> Is this feature fully tested by web-platform-tests
> 
> ? https://github.com/web-platform-tests/wpt/pull/31058
>
> Flag name N/A
>
> Requires code in //chrome? False
>
> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1255711
>
> Estimated milestones
>
> M96/M97
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5652396366626816
> --
> 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/CAAe2mZ1N0Oqz%3DVgEm%2BFQdJBVJCQbG%3Dv-6aO_JqRzm-9uBeQ%3Dfg%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/83e97b2b-cad3-07fc-747e-24a786b89ccd%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/CAL5BFfUOsYnB%3DBDvpfrK5CpkNvjaq1Udqk1gcG3_9x8kVAhozQ%40mail.gmail.com.

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

Do I understand correctly and you want to experiment for a single
milestone? (M97)

On Tue, Oct 5, 2021 at 11:12 PM 'Elad Alon' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailselada...@chromium.org, mfo...@chromium.org,
> jop...@chromium.org
>
> Explainer
> https://github.com/eladalon1983/region-capture/blob/main/README.md
>
> Specificationhttps://eladalon1983.github.io/region-capture/
>
> Summary
>
> Recall that applications may currently obtain a capture of the tab in
> which they run using getDisplayMedia, either with or without
> preferCurrentTab. Moreover, soon another API will allow similar
> functionality - getViewportMedia. In either case, the application may then
> also wish to crop the resulting video track so as to remove some content
> from it (typically before sharing it remotely). We introduce a performant
> and robust API for cropping a self-capture video track.
>
>
> Blink componentBlink
> 
>
> TAG reviewPending
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> Should be relatively unchallenging to use.
>
>
> Security
>
> This is a mechanism by which an application purposefully strips away
> information which it already has access to (via pre-existing mechanisms
> such as getDisplayMedia).
>
>
> Goals for experimentation
>
> Evaluate the usefulness of the feature and gather Web-developer feedback
> about how it may improve.
>
> Debuggability
>
> N/A
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Supported on all desktop platforms, but not on mobile platforms, as the
> prerequisite API of getDisplayMedia is currently only available on desktop.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag nameRegionCapture
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1247761
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1168076
>
> Estimated milestones
> OriginTrial desktop last 97
> OriginTrial desktop first 97
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5712447794053120
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/dib14W1B0Xc
>
>
> 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/CAMO6jDPGYJBWv6xTaRPPAkCtCCU5RRhskk459kY4yhhsZtTSdg%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/CAL5BFfVxWAutWOFq0ZsheND%3D0B7OfDT0d8DpsCxXuszKFyp9BA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Auto Dark Mode & the CSS color-scheme “only” keyword

This seems extremely useful!

What are the timelines for experimentation? Do you have partners lined up
that are ready to play with this?

Also, the intent seems to be missing many fields (signals from other
vendors and developers, TAG review, etc)
Can you complete the missing ones from the Chrome status entry?

On Tue, Oct 5, 2021 at 10:18 PM Peter Beverloo  wrote:

> *Contact emails*
> futh...@chromium.org, p...@chromium.org, pe...@chromium.org
>
> *Spec*
> https://drafts.csswg.org/css-color-adjust/#color-scheme-prop
>
> *Summary*
> This Origin Trial covers two pieces of related functionality:
>
> First, websites that decide to participate in this trial will have their
> appearance algorithmically adjusted to be darkened, and thus appropriate
> for display whilst a device is in Dark Mode. Rendered colors will have
> their lightness adjusted to appear dark, and images will be classified,
> where images will be classified first based on their size and properties,
> then by a machine learning model to help distinguish iconography from
> photos and other images.
>
> Second, support for the CSS color-scheme “only” keyword, which forbids the
> user agent from overriding the color scheme for an element. This enables
> participating websites to manually touch-up certain elements when the
> algorithm gets it wrong, which will happen.
>
> *Goals for experimentation*
> Modern operating systems, particularly mobile ones, feature extensive,
> platform-wide Dark Mode implementations. Dark Mode is the default,
> out-of-the-box experience on some Android devices, and automatically
> enabled during nighttime on many more.
>
> Early data is suggesting that dark themes use 10% less battery than light
> themes at 75% brightness, and suggest significant differences in user
> behaviour on websites that don’t provide a dark mode whilst the user’s
> device is in dark mode.
>
> However, we heard feedback from developers that one of the reasons why
> dark themes haven’t been more widely adopted on the web is the cost of
> creating and maintaining a second theme for web applications.
>
> With this Origin Trial for Auto Dark Mode, we’d like to experiment with
> both partners and developers to understand the impact of Dark Mode on their
> websites, and to understand the quality of our algorithms outside of our
> own testing environment.
>
> *Experimental timeline*
> The experiment will start in M96, and will last until (& including M99).
> Auto Dark Mode is already programmatically detectable by developers to
> inspect the computed styles, but we might want to iterate during the Origin
> Trial with an addition if the CSS working group agrees on one:
>
> https://github.com/w3c/csswg-drafts/issues/6664
>
> *Any risks when the experiment finishes?*
> No, websites will revert back to their original appearance.
>
> *Ongoing technical constraints*
> Auto Dark Mode in particular is a fairly intrusive feature, but builds
> upon the force dark mode feature already launched for Android WebView.
>
> *Debuggability*
> Developers already have the ability to test this functionality on their
> pages by opening DevTools, selecting the Rendering option in "More tools",
> and then emulating Auto Dark Mode.
>
> Users and developers alike have the ability to enable this functionality
> for all websites through a flag which can be found on
> chrome://flags/#enable-force-dark.
>

Neat!


>
> *Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?*
> The Origin Trial will be available for Android only.
>
> There are no strict technical reasons for this, but given that the
> functionality is most appropriate for mobile devices, there might be
> different considerations between mobile and desktop, and that the team is
> currently focused on improving the Android experience, we’d like to begin
> there.
>
> *Link to entry on the feature dashboard*
> https://chromestatus.com/feature/5672533924773888
>
> --
> 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/CALt3x6%3DkTVanrag5ePo39E-FXBzgNChkxqU35CvfQsYZ6AxZeg%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/CAL5BFfXH4eWMSS12Tfx8H62V0%3DEa4MSK8JReEtfZsaCNLZKMzA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-synthesis property

*LGTM1*
Thanks for working on this!! This seems like an important thing to catch up
on!



On Tue, Oct 5, 2021 at 6:56 PM 'Munira Tursunova' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> moon...@google.com, dr...@chromium.org
>
> Explainer
>
> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis
>
> Specification
>
> https://drafts.csswg.org/css-fonts/#font-synthesis
>
> Summary
>
> The font-synthesis CSS property controls whether user agents are allowed
> to synthesize oblique, bold and small-caps font faces when a font family
> lacks oblique, bold and small-caps faces, respectively.
>
>
> Blink component
>
> Blink>Fonts
> 
>
> TAG review status
>
> Already shipped in other browsers, see below, no TAG review required.
>
> Risks
>
> Interoperability and Compatibility
> Low, feature already shipped in Firefox and Safari.
>
> Expected graceful degradation if an engine has so far not implemented this
> feature: if the font-synthesis: property is not understood by an engine,
> this means unintended synthesis can occur. That's expected and the reason
> why this property was designed.
>
> Signals
>
> Gecko: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#browser_compatibility)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1706080
>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=144180)
>
> Web developers: No signals
>
> Activation
>
> None expected, feature already implemented in other browsers.
>
>
> Debuggability
>
> Same as any other CSS property, css_properties.json will be rolled to
> DevTools during development.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes, 36 new web tests pass: 16 new internal platform specific tests were
> added, 12 new WPT tests were added and 8 existing WPT tests are now passing.
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=509989
>
> Sample links
>
> https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5640605355999232
>
> 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/CAAO7W_AmPR6X7evqGz9P7bkW2ysRmr%3DqP4ajgGA%2BjOGfsp_FrA%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/CAL5BFfXyqaq60U%2BEzTWxYLhhZcW%3DyjZMetHjkgfmjpWibOWLxg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: App Shortcuts Menu

Can you send a new intent for that purpose? Thanks! :)

On Tue, Oct 5, 2021 at 6:18 PM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi All,
>
> This feature previously shipped for Windows and Android
> https://chromestatus.com/feature/5706099464339456. Requesting approval to
> ship on Mac and Linux
> https://bugs.chromium.org/p/chromium/issues/detail?id=1248101
>
> -Ajay
> On Thursday, May 28, 2020 at 12:13:39 PM UTC-7 yo...@yoav.ws wrote:
>
>> LGTM3
>>
>> On Thu, May 28, 2020 at 9:12 PM Mike West  wrote:
>>
>>> LGTM2.
>>>
>>> The risk raised on the Mozilla standards positions thread is not
>>> specific to these links; the same capability exists with `start_url`. If we
>>> change that, we should change this as well.
>>>
>>> -mike
>>>
>>> On Thursday, May 28, 2020 at 9:11:00 PM UTC+2, Chris Harrelson wrote:
>>>
>> LGTM1

 On Tue, May 26, 2020 at 10:09 AM Rayan Kanso 
 wrote:

>>> Hi Yoav,
>
> FWIW, https://github.com/mozilla/standards-positions/issues/338 seems
>> promising, although we should let it play out.
>> Have we considered the "super cookie" issues raised there? Are there
>> mitigations in place against that?
>
>
>  Yeah, the behaviour matches that of "start_url". There are no
> additional mitigations.
>
>
> Have we reached out?
>
>
>  https://bugs.webkit.org/show_bug.cgi?id=201964
>
>
> Links?
>
>
> There have been quite a few positive interactions within discussions
> and updates. Here's an example of a recent chromium tweet
> 
> regarding the issue.
>
>
> Have we filed a WPT issue that will enable such testing?
>
>
> Not one specifically for shortcuts. It should be covered by the
> ability to test app manifest features in general.
>
> Thanks,
> ~Rayan
>
> On Tue, May 26, 2020 at 2:34 PM Yoav Weiss  wrote:
>
 Apologies for the delay in replying. It seems like this intent fell
>> between the script's cracks...
>>
>> On Mon, May 11, 2020 at 6:01 PM Rayan Kanso 
>> wrote:
>>
>>> Contact emails
>>>
>>> rah...@microsoft.com, 
>>> jungke...@microsoft.com, cmum...@google.com, raya...@chromium.org
>>>
>>> Explainer
>>>
>>> Shortcuts Explainer
>>> 
>>>
>>> Spec
>>>
>>> W3C spec: https://w3c.github.io/manifest/#shortcuts-member
>>>
>>> Tag Review: https://github.com/w3ctag/design-reviews/issues/510
>>>
>>> Summary
>>>
>>> This feature provides PWA developers the ability to show a shortcuts
>>> menu of common tasks in their app. The menu can be invoked by right
>>> clicking the app icon in the quick launch bar after the PWA has been
>>> installed on the user’s desktop, or long pressing on the app on Android.
>>> This capability already exists for native apps on various platforms
>>> (Android, Linux, macOS, and Windows).
>>>
>>>
>>> Link to “Intent to Prototype” blink-dev discussion
>>>
>>>
>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gK4XF2vbvf0
>>>
>>>
>>> Is this feature supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> The feature will not be supported on WebView since web apps don't
>>> exist in that context. The feature will initially be enabled on Android,
>>> with support for Desktop platforms to follow.
>>>
>>> Demo link
>>>
>>> Test Website .
>>>
>>> For Android, it needs to be installed via an unstable Chrome channel
>>> (canary/dev/beta).
>>>
>>> For Windows, the *kDesktopPWAsAppIconShortcutsMenu* flag needs to
>>> be enabled.
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> No Interoperability/Compatibility risk. When a web developer doesn’t
>>> provide a shortcuts member in the PWA’s WebAppManifest, current
>>> installation behavior is not affected by this feature.
>>>
>>>
>>> Edge: In development/Public Support
>>>
>>> Firefox: No signals
>>>
>>
>> FWIW, https://github.com/mozilla/standards-positions/issues/338 seems
>> promising, although we should let it play out.
>> Have we considered the "super cookie" issues raised there? Are there
>> mitigations in place against that?
>>
>> Safari: No signals
>>>
>>
>> Have we reached out?
>>
>>
>>> Web / Framework developers: Positive feedback from web developers
>>>
>>
>> Links?
>>
>>
>>>
>>> Ergonomics
>>>
>>> Shortcuts will be used as part of the WebAppManifest. Use will not
>>> affect performance.
>>>
>

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item