date:20211021



On Thursday, October 21, 2021 at 9:31:23 AM UTC+2 Yoav Weiss wrote:

> This is an exciting improvement to PWA parity with native apps! :) 
>
> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails 
>>
>> amb...@microsoft.com, luigo...@microsoft.com, hata...@microsoft.com, 
>> c...@chromium.org
>>
>>  
>> Explainer 
>>
>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
>>
>>  
>> Specification 
>>
>> https://wicg.github.io/window-controls-overlay/ 
>>
>
> The spec looks like it could use some work. Beyond the editorial, it 
> doesn't seem like it defines the novel concepts that it introduces, nor the 
> relevant processing models.
>

Let me expand on that a bit. The spec introduces a new concept of a "window 
overlay" without really creating it as a concept. 
What I expect an interoperable spec to define the concept with as much 
detail as possible without getting OS- or implementation-specific. 
(Just to draw an example of what I have in mind, if I had to make something 
up, I'd go with something like: "Window overlay is an interface 
element that the operating system uses consistently across applications to 
enable the user to perform certain action to control the application such 
as closing it, expanding it to full screen, etc. This UI element takes 
fixed dimensions")

Then, once you have that concept defined, you can start building on it and 
define the processing of the different methods based on that.

I'll open issues with other suggestions.

 
>
>>  
>> Design docs 
>>
>>  
>>
>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md
>>
>>  
>> Summary 
>>
>> Window Controls Overlay allows a developer to create a custom title bar 
>> UX by extending the installed app’s client area. The client area now covers 
>> the entire window except for the window controls (close, maximize/restore, 
>> minimize), which are overlaid in their respective position. 
>>
>>  
>>
>> The web app developer is responsible for drawing and input-handling for 
>> the entire window except for the window controls overlay. This includes 
>> defining which area of the window is draggable as well, with a prefixed and 
>> non-prefixed version of a css property supported, as implemented in: 
>> crrev.com/c/3094474.
>>
>>  
>>
>> Intended uses for the Window Controls Overlay are creating seamless UX 
>> that can use the area that was reserved for the title bar before. Many 
>> modern applications include menus, search bars and other controls in the 
>> title bar, and this feature enables this on installed web apps.
>>
>>  
>> Blink component 
>>
>> UI>Browser>WebAppInstalls 
>> 
>>
>>  
>> Search tags 
>>
>> PWA , web app 
>> , title bar 
>> , titlebar 
>> , customization 
>> , window controls 
>> 
>>
>>  
>> TAG review 
>>
>> https://github.com/w3ctag/design-reviews/issues/481
>>
>>  
>> TAG review status 
>>
>> Resolution: satisfied
>>
>>  
>> Risks 
>>
>>  
>> Interoperability and Compatibility 
>>
>> Given that Edge has interest in the feature, there would be at least one 
>> other browser that implements it. The feature involves additive changes 
>> (new web app manifest entry, new JS API, new CSS env variables) and 
>> modifications (changes to frame, new use of env(safe-area-inset-*), but no 
>> removals, so the compatibility risk is minimal.
>>
>  
>>
>> Gecko: defer https://github.com/mozilla/standards-positions/issues/529 
>>
>>  
>>
>> WebKit: No signal 
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html 
>>
>>  
>>
>> Web developers: Positive
>>
>> https://twitter.com/firt/status/1385238446046859268?s=20
>>
>> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20
>>
>> https://twitter.com/bashik7/status/1385821988208275457?s=20
>>
>> https://twitter.com/abraham/status/1385201046767738880?s=20
>>
>>  
>> Ergonomics 
>>
>> The changes associated with this feature will only be enabled for PWAs 
>> that opt-in to it, so there are minimal risks posed to the browser as a 
>> whole. A PWA that opts-in to the feature should also have minimal 
>> ergonomics risk since the manifest already needs to be parsed on startup to 
>> determine the correct display mode in which the app should be launched, so 
>> adding one extra manifest check on startup should have minimal impact.
>>
>>  
>> Activation 
>>
>> The activation risk is low since this feature includes all the tools 
>> needed to create an app that uses the full extent of the window: new 
>> UA-provided window controls overlay, JS APIs to

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

For a gapless origin trial->shipping it is important to be sure we don't
overlook any feedback in the race to shipping. The normal process has
gaps built in which form natural points to do that final polish based on
received feedback and that will be missing here.

It does sound like the feedback has been positive though and that there
are no known problems that can't be fixed after shipping, and with that
in mind:

LGTM2

On 2021-10-21 21:53, Yoav Weiss wrote:
Discussing amongst the API owners (Alex, Daniel, Rego and myself),
this is essentially a request for a gapless OT, only that the
would-be-gap is slightly longer than usual. Given the evidence
of
developer feedback presented in the I2S, that seems like a reasonable
request.

LGTM1 (as gapless OT requests require 3 LGTMs)

On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

Contact emails

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

Explainer

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

Design docs/spec

Specification:https://w3c.github.io/webtransport/#web-transport

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

TAG review

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

Summary

WebTransport is an interface representing a set of
reliable/unreliable streams to a server. The interface potentially
supports multiple protocols, but based on discussions on the IETF
webtrans working group, we are developing WebTransport over HTTP/3
which uses HTTP3 as the underlying protocol.

Note that we were developing QuicTransport a.k.a. WebTransport
over QUIC and we ran an origin trial M84 through M90. It uses the
same interface WebTransport, but because of the protocol
difference ("quic-transport" vs. "https") it is difficult for web
developers to be confused by them.

new WebTransport("quic-transport://example.com:9922
")

represents a WebTransport over QUIC connection, and

new WebTransport("https://example.com:9922
")

represents a WebTransport over HTTP/3 connection.

Goals for experimentation

We're shipping the API in M97

.
Twitch, one of our partners, wants to continue their experiment
until the API is fully shipped. I think this is a reasonable
request given we originally aimed to ship the feature in M96 but
we missed the branch point.

The original goals follow:

To see whether the API (and the implementation) is useful in
various circumstances.

Our partners want to evaluate this API on various network
circumstances (i.e., lab environments are not enough) to see its
effectiveness.

We also expect feedback for performance.

Experimental timeline

M95 and M96

Ongoing technical constraints

None

Debuggability

The devtools support is under development.

Just like with regular HTTP/3 traffic, the detailed information
about the connection can be obtained via chrome://net-export
interface.

Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested byweb-platform-tests

We have browser tests, but we are going to port them to WPT.

Link to entry on the Chrome Platform Status

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

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

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

Discussing amongst the API owners (Alex, Daniel, Rego and myself), this is 
essentially a request for a gapless OT, only that the would-be-gap is 
slightly longer than usual. Given the evidence 

 of 
developer feedback presented in the I2S, that seems like a reasonable 
request.

LGTM1 (as gapless OT requests require 3 LGTMs)

On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

> Contact emails
>
> yhir...@chromium.org,vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Design docs/spec
>
> Specification: https://w3c.github.io/webtransport/#web-transport
>
>
> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/669
>
>
> Summary
>
> WebTransport is an interface representing a set of reliable/unreliable 
> streams to a server. The interface potentially supports multiple protocols, 
> but based on discussions on the IETF webtrans working group, we are 
> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying 
> protocol.
>
> Note that we were developing QuicTransport a.k.a. WebTransport over QUIC 
> and we ran an origin trial M84 through M90. It uses the same interface 
> WebTransport, but because of the protocol difference ("quic-transport" vs. 
> "https") it is difficult for web developers to be confused by them.
>
> new WebTransport("quic-transport://example.com:9922")
>
> represents a WebTransport over QUIC connection, and
>
> new WebTransport("https://example.com:9922;)
>
> represents a WebTransport over HTTP/3 connection.
>
> Goals for experimentation
>
> We're shipping the API in M97 
> .
>  
> Twitch, one of our partners, wants to continue their experiment until the 
> API is fully shipped. I think this is a reasonable request given we 
> originally aimed to ship the feature in M96 but we missed the branch point.
>
>
> The original goals follow:
>
>
> To see whether the API (and the implementation) is useful in various 
> circumstances.
>
> Our partners want to evaluate this API on various network circumstances 
> (i.e., lab environments are not enough) to see its effectiveness.
>
> We also expect feedback for performance.
>
> Experimental timeline
>
> M95 and M96
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> The devtools support is under development.
>
> Just like with regular HTTP/3 traffic, the detailed information about the 
> connection can be obtained via chrome://net-export interface.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux,
>
> Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> No
>
> We have browser tests, but we are going to port them to WPT.
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/4854144902889472
>
>

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

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

Inspired by the recent talk about user interaction, I feel like there is 
one thing I want to understand.


So with a Promise you move the execution to a later time. Is it possible 
here for a malicious page to delay an action to much, much later and 
then do that clipboard operation on data that was not available at the 
time of the clipboard operation the user initiated?


If so, could that have security implications?

Could there even be more than one ongoing clipboard operation at a time?

/Daniel


On 2021-10-21 17:20, Domenic Denicola wrote:



On Thu, Oct 21, 2021 at 5:21 AM Yoav Weiss  wrote:

LGTM1 to ship conditional that y'all continue to work on PR #158
 specifically, and
clarifying the spec's processing model in general.

On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:

Gentle ping as the branch cutoff date for 97 is pretty close.
While I agree that the issues related to clipboard API spec
need to be addressed, I don’t think this feature needs to be
blocked on that. It’s not a breaking change i.e. sites can
continue to use Blobs if they want to(although I don’t think
any developer would want to have different codepaths for Apple
and Chromium browsers)


FWIW, I got curious RE why that *should* work, and did some digging.
It seems like the bindings methods that accept a `Promise`
input value call `NativeValueTraits

`
on that value, which casts


the value foo into a `Promise.resolve(foo)`, if it wasn't a
Promise already.
The same seems to work in WebKit as well. Do you know if this
bindings behavior is specified?


It is: https://webidl.spec.whatwg.org/#es-promise


Also, can you add tests for both input cases as part of your CLs
for this?

, and Apple has already shipped this feature. Please let me
know in case of any concerns.

-Anupam

*From:* Anupam Snigdha
*Sent:* Thursday, October 7, 2021 9:53 AM
*To:* 'Yoav Weiss' 
*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

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
 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' ; Anne van
Kesteren 
*Cc:* blink-dev ; Marijn
Kruisselbrink ; Bo Cupp

*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

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

I think this is a great question, but somewhat out of scope for the Intent. 
Please ping your local design/security teams ;-)

On Thursday, October 21, 2021 at 4:19:24 AM UTC-7 Thomas Steiner wrote:

> Any plans to move the ﹀ icon into the three dots menu? It looks a bit 
> ugly. There is an experiment to move the puzzle piece into the three dots 
> menu, too, so maybe this icon could be there, too? Maybe after the user has 
> toggled it for the first time to not hurt discoverability of WCO (even 
> further). 
>
> On Thu, Oct 21, 2021 at 9:31 AM Yoav Weiss  wrote:
>
>> This is an exciting improvement to PWA parity with native apps! :) 
>>
>> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails 
>>>
>>> amb...@microsoft.com, luigo...@microsoft.com, hata...@microsoft.com, 
>>> c...@chromium.org
>>>
>>>  
>>> Explainer 
>>>
>>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
>>>
>>>  
>>> Specification 
>>>
>>> https://wicg.github.io/window-controls-overlay/ 
>>>
>>
>> The spec looks like it could use some work. Beyond the editorial, it 
>> doesn't seem like it defines the novel concepts that it introduces, nor the 
>> relevant processing models.
>>  
>>
>>>  
>>> Design docs 
>>>
>>>  
>>>
>>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md
>>>
>>>  
>>> Summary 
>>>
>>> Window Controls Overlay allows a developer to create a custom title bar 
>>> UX by extending the installed app’s client area. The client area now covers 
>>> the entire window except for the window controls (close, maximize/restore, 
>>> minimize), which are overlaid in their respective position. 
>>>
>>>  
>>>
>>> The web app developer is responsible for drawing and input-handling for 
>>> the entire window except for the window controls overlay. This includes 
>>> defining which area of the window is draggable as well, with a prefixed and 
>>> non-prefixed version of a css property supported, as implemented in: 
>>> crrev.com/c/3094474.
>>>
>>>  
>>>
>>> Intended uses for the Window Controls Overlay are creating seamless UX 
>>> that can use the area that was reserved for the title bar before. Many 
>>> modern applications include menus, search bars and other controls in the 
>>> title bar, and this feature enables this on installed web apps.
>>>
>>>  
>>> Blink component 
>>>
>>> UI>Browser>WebAppInstalls 
>>> 
>>>
>>>  
>>> Search tags 
>>>
>>> PWA , web app 
>>> , title bar 
>>> , titlebar 
>>> , customization 
>>> , window controls 
>>> 
>>>
>>>  
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/481
>>>
>>>  
>>> TAG review status 
>>>
>>> Resolution: satisfied
>>>
>>>  
>>> Risks 
>>>
>>>  
>>> Interoperability and Compatibility 
>>>
>>> Given that Edge has interest in the feature, there would be at least one 
>>> other browser that implements it. The feature involves additive changes 
>>> (new web app manifest entry, new JS API, new CSS env variables) and 
>>> modifications (changes to frame, new use of env(safe-area-inset-*), but no 
>>> removals, so the compatibility risk is minimal.
>>>
>>  
>>>
>>> Gecko: defer https://github.com/mozilla/standards-positions/issues/529 
>>>
>>>  
>>>
>>> WebKit: No signal 
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html 
>>>
>>>  
>>>
>>> Web developers: Positive
>>>
>>> https://twitter.com/firt/status/1385238446046859268?s=20
>>>
>>> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20
>>>
>>> https://twitter.com/bashik7/status/1385821988208275457?s=20
>>>
>>> https://twitter.com/abraham/status/1385201046767738880?s=20
>>>
>>>  
>>> Ergonomics 
>>>
>>> The changes associated with this feature will only be enabled for PWAs 
>>> that opt-in to it, so there are minimal risks posed to the browser as a 
>>> whole. A PWA that opts-in to the feature should also have minimal 
>>> ergonomics risk since the manifest already needs to be parsed on startup to 
>>> determine the correct display mode in which the app should be launched, so 
>>> adding one extra manifest check on startup should have minimal impact.
>>>
>>>  
>>> Activation 
>>>
>>> The activation risk is low since this feature includes all the tools 
>>> needed to create an app that uses the full extent of the window: new 
>>> UA-provided window controls overlay, JS APIs to query the size of the 
>>> overlay, and CSS environment variables to layout content around the overlay.
>>>
>>
>> What do we expect developers to do as a fallback in non-supporting 
>> browsers?  
>>
>>>

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

LGTM3.

In future, if you assert a TAG review isn't necessary, please provide links 
to previous reviews that cover the same space.

On Thursday, October 21, 2021 at 12:17:45 PM UTC-7 Manuel Rego wrote:

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

Re: [blink-dev] Intent to Ship: COLRv1 Color Gradient Vector Fonts

LGTM3.

Thanks everyone for providing compelling evidence that this is solving an 
important need well.

On Thursday, October 21, 2021 at 5:10:27 AM UTC-7 一丝 wrote:

> > Chinese version of this email: 
> https://www.yuque.com/docs/share/ba9f5d45-b1d3-49d6-9a69-d4cb5841de7f
>
> Thanks to Dominik's hard work behind the scenes, COLRv1 has gone from an 
> idea to a technology that everyone can use.
>
> Since Adobe released PostScript in 1984, font technology has undergone a 
> huge transformation. Looking back on the history, there have been many 
> detours due to commercial competition. Today, we are at a crossroads again, 
> and I believe COLRv1 will leave a strong mark on the history of fonts.
>
>
> I am the head of development at www.iconfont.cn 
> , *iconfont fully endorses the 
> COLRv1 font format and fully agrees with Chromium's views here.*
>
> Please allow me to briefly introduce:
>
> iconfont is the vector (SVG) material management platform of Alibaba 
> Group, we have millions of massive icons. With iconfont, designers and 
> developers can easily collaborate. When designers draw icons, they only 
> need to export SVG and upload it to iconfont to generate code and various 
> fonts easily.
>
> Generating colorful fonts with gradients has been the biggest request from 
> our users. We have also considered the SVG in OT format, but there are 
> several significant problems.
>
>1. generating large font files
>2. variable fonts are not supported
>3. Not supported in *MiniApp*: 
>https://www.w3.org/TR/mini-app-white-paper/
>
> [image: image (3).png]
>
> Test page(64 emojis): https://at.alicdn.com/t/iconfont/project/900373.html
>
>
> In the end, we chose the COLRv0 format, which does not support gradients. 
> As of 2021-10-21, here are some data of iconfont.cn.
>
>- Total number of icons: *1680+*
>- Total number of color icon collections: *4559*
>- Total number of projects: *267+*
>- Total number of color fonts (COLRv0) projects: *4535*
>
>
> There are already 4535 projects with COLRv0 enabled, but nowhere near the 
> total number of projects 267+, I believe a big reason is that they are 
> waiting for font icons with gradients. So, as soon as Chrome ships COLRv1, 
> iconfont can implement it quickly so that all users can easily generate 
> COLRv1 fonts.
>
>
> At Alibaba, many apps are using font icons and I'm pushing to switch the 
> emoji in Dingtalk App  from png to vector 
> color fonts, which will be a brand new experience.
>
> [image: 2021-10-21 18_35_22.gif]
>
> Let's drink to that  and wait for the good news of the release.
>
>
> Acknowledgements
>
> Heartfelt thanks to Dominik Röttsches, Behdad Esfahbod, Roderick Sheeter, 
> Cosimo Lupo and others for their help and support.
>
>- English users can visit: https://www.iconfont.cn/?lang=en-us
>- More iconfont color font introduction: 
>https://www.yuque.com/yisi/iconfont/colr-font
>
>
> 一丝(Percy Ley)
>
> 在2021年10月21日星期四 UTC+8 上午7:36:40 写道：
>
>> +1, thanks for driving this Dominik. Edge is looking forward to COLRv1 
>> shipping to provide a compact format that enables a wider set of features 
>> that icon and emoji fonts can take advantage of. 
>> On Wednesday, October 20, 2021 at 5:43:52 AM UTC-10 
>> pcons...@microsoft.com wrote:
>>
>>> @Dominik: Thanks for the detailed write-up, and for driving the process 
>>> to ship support for COLR v1 in chromium. Naturally, as collaborator on the 
>>> COLR v1 spec, and the one getting it added to OpenType (for version 1.9, to 
>>> be released soon), I  can say that Microsoft is in general supportive of 
>>> this extension to the OpenType format, and am fully in support of seeing 
>>> this supported in Chromium.
>>>
>>> Color fonts have been around for almost a decade, but have not really 
>>> taken off. I suspect a contributing factor for that is that there hasn't 
>>> been one format that is widely supported in applications. 
>>>
>>> I also suspect there hasn't been excitement around the bitmap formats 
>>> ('sbix' or 'CBDT' tables) because bitmaps aren't scalable and lead to large 
>>> font files. (That's especially the case when alternate bitmaps of different 
>>> sizes are added to compensate for the lack of scalability.) The bitmap 
>>> formats also don't integrate at all with variations, which is a downside 
>>> against them.
>>>
>>> Clearly a colour vector format is to be preferred. OT-SVG is already 
>>> available as a vector format. But for reasons I mentioned in the webkit-dev 
>>> list (cited above), I don't think we should expect it to be adopted widely 
>>> in environments that don't already have XML and CSS parsers. OT-SVG and 
>>> COLR v1 will require similar 2D graphics support, and both require ttf 
>>> parsing, but OT-SVG also requires XML/CSS parsing, which is certainly more 
>>> complex than parsing the structures added for COLR v1.
>>>
>>> COLR v1 also has the

Re: [blink-dev] Intent to Ship: New Canvas 2D API

I'm excited to see these move forward. I probably missed it from the github 
explainers (which seem pretty IDL heavy, but not particularly use-case 
driven?), but which of these will be available on Paint Worklets as part of 
this intent?

On Thursday, October 21, 2021 at 12:07:21 AM UTC-7 Yoav Weiss wrote:

> Thanks for modernizing Canvas! :)
>
> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski  
> wrote:
>
>>
>> *Contact emails*aaro...@chromium.org, fs...@chromium.org
>>
>> *Explainer*
>> https://github.com/fserb/canvas2d
>> https://youtu.be/dfOKFSDG7IM
>>
>
> Great video, thanks for that!!
>  
>
>>
>> *Specification*
>> Context Lost Event 
>> 
>> Context Restored Event 
>> 
>> Will Read Frequently 
>> 
>> New Text Modifiers 
>> 
>> Reset 
>> 
>>
>
> Were the concerns WebKit raised on the issue 
>  addressed? Can you expand on 
> that front?
>
>
>> RoundRect
>>
>> Conic
>>  
>> Gradient
>>
>> 
>> Filters  (still in progress)
>>
>
> Is the hold-up on the Filters PR editorial or something more fundamental?
> I noticed Mozilla's opposition on their position. Is that something that 
> has changed since?
>
> Are these features individually detectable? Do we have reasonable 
> developer advice on how we want folks to use those features with backwards 
> compat/fallbacks in mind?
>  
>
>>
>> *Summary*
>> Updated functionality for the Canvas2D API. Adds seven new 
>> features/functions to CanvasRenderingContext2D:
>>
>> - "ContextLost" and "ContextRestored" events
>> - "willReadFrequently" option for canvases where lots of readback is 
>> expected
>> - More CSS text modifier support
>> - A reset function
>> - A roundRect draw primitive
>> - Conic gradients
>> - Better support for SVG filters
>>
>> https://github.com/fserb/canvas2d
>>
>> *Blink component*
>> Blink>Canvas 
>> 
>>
>>
>> *TAG review status*Resolution: satisfied 
>> 
>>
>> *Risks*
>> Security and privacy team expressed concerns with ContextLost and 
>> ContextRestored events during the intent to implement phase. These concerns 
>> were addressed by re-designing the event to not launch simultaneously 
>> across different contexts.
>>
>> *Interoperability and Compatibility*
>> Gecko: In development (https://github.com/whatwg/html/issues/5431 
>> )
>>  
>> Already implemented conic gradient. Okay with willReadFrequently, 
>> transforms and reset.
>>
>> WebKit: Positive (https://github.com/whatwg/html/issues/5619). Positive 
>> signal on text modifiers, round rect and color input.
>>
>> Web developers: Positive (https://www.youtube.com/watch?v=dfOKFSDG7IM) 
>> CDN talk in December was received very positively.
>>
>> *Signals*
>> Gecko: https://github.com/mozilla/standards-positions/issues/519
>> WebKit: 
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html
>>
>> *Is this feature fully tested by* web-platform-tests 
>> 
>> ?
>> Yes
>>
>> *Flag name*
>> #new-canvas-2d-api
>>
>> *Requires code in //chrome?*
>> False
>>
>> *Tracking bug*
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1201359
>>
>> *Estimated milestones*
>> OriginTrial desktop first
>> 95
>>
>> OriginTrial desktop last
>> 98
>>
>> OriginTrial android first
>> 95
>>
>> OriginTrial android last
>> 98
>>
>> *Link to entry on the Chrome Platform Status*
>> https://www.chromestatus.com/feature/6051647656558592
>>
>> 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/eb702e7e-88d6-4b6f-b419-6051511689f1n%40chromium.org
>>  
>> 
>> .
>>
>

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

Re: [blink-dev] Intent to Ship: [WebAuthn] Authenticator Attachment in Public Key Credential

Thanks for explaining, Adam.

I'm LGTM1 contingent on:

   - An explainer being produced with at least the content of Adam's last 
   post being included.
   - An FYI being sent to the TAG w/ that Explainer attached. We don't have 
   a policy that allows folks to arbitrarily decide not to send things to them 
   w/o justification.

Thanks

On Friday, October 15, 2021 at 12:15:34 PM UTC-7 Adam Langley wrote:

> On Thursday, October 14, 2021 at 1:49:39 AM UTC-7 yoav...@chromium.org 
> wrote:
>
>> Apologies, but it's not clear to me what this does. A higher-level 
>> explainer may be helpful here.
>>
>
> When returning a WebAuthn assertion, browsers will say whether the 
> assertion came from a removable device or not. I.e. if you touch a security 
> key it'll say "cross-platform", but if you use Touch ID / Windows Hello 
> it'll say "platform".
>
> Sites could already figure this out because they learn the supported 
> transports of an authenticator during registration and removable devices 
> offer things like "usb" or "ble", while the platform authenticators (Touch 
> ID / Hello) say "internal". But we want to make this simpler for sites so 
> that they have a clear signal when offering to register the platform as an 
> authenticator might be useful.
>
> The vision is that, when phones are fully usable as security keys, users 
> will be able to sign into sites on a desktop browser with them. But that 
> site might want to know that a "removable" device was used (e.g. a phone) 
> because registering the platform authenticator for future sign-ins is 
> probably a better experience.
>
>
>>> *TAG review*
>>>
>>> N/A
>>>
>>
>> Why is a TAG review not applicable? 
>>
>
> Seems like a very minor change and TAG is a very heavy process.
>  
>
>> Web developers: No signals
>>>
>>  
>> Are developers likely to adopt this? If not, why are we adding this?
>> https://goo.gle/developer-signals
>>
>
> Other parts of an ecosystem need to slot into place in order for 
> everything to hang together: phones as security keys, syncing credentials, 
> conditional UI, etc. So developers are probably uninterested in this part 
> in isolation, but all together there's a fair amount of interest. GitHub, 
> at least, are public about WebAuthn L2 being insufficient without several 
> of changes in this set: 1  2 
>  3 
> .
>  
>
>>
>>> Edge: Support Signals
>>>
>> Any links?
>>
>
> Microsoft supporting here 
> . 
> (See "Assertion Transports" section; WG discussion changed "transports" to 
> "attachment", which is what this thread is talking about.)
>
>
> Cheers
>
> AGL
>

-- 
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/dd8302d9-709c-4d5a-9d14-b33da77039f8n%40chromium.org.

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

Not consulting the TAG in this instance may have been an error. In general, 
we should be putting things into consistent surfaces that they affect. In 
this case, it seems like we're missing integrations w/ the Permissions API.

I'm LGTM2 on this intent contingent on a commitment to follow up w/ the TAG 
as an FYI and a commitment to investigate Permissions API integration.

Best Regards,

Alex

On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:

> LGTM1
>
> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola  
> wrote:
>
>> Just chiming in from the sidelines: in general I think this sort of 
>> exposure via permissions policies is a good thing, and should be encouraged.
>>
>> It shouldn't have any additional concerns for an API like this which is 
>> about exposing information:
>>
>>- Same-origin iframes can already call 
>>top.navigator.keyboard.getLayoutMap()
>>- The parent can call navigator.keyboard.getLayoutMap(), serialize 
>>the information, and send it to any cross-origin descendants that it 
>> wants 
>>to receive that information via postMessage().
>>
>> Permissions policy just streamlines this: same-origin iframes now don't 
>> need to go via top, and the parent can avoid writing custom code to 
>> communicate the information to cross-origin descendants, instead replacing 
>> it with a simple allow="keyboard-map" or allow="keyboard-map 
>> https://specific-origin;.
>>
>> I hope the API owners can support this kind of improvement to the 
>> platform, not only for this case but in general whenever we introduce 
>> ergonomic permissions policy-based delegation for any feature.
>>
>>
>> On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> getLayoutMap() can already be accessed by the top level browsing context 
>>> and I believe it does have fingerprinting concerns: a site can gain 
>>> knowledge of the keyboard layout of the user even before the user has typed 
>>> anything. Try this site switching between French and English keyboard 
>>> layouts: https://fortunate-onyx-wren.glitch.me/french-or-english.html. 
>>> The privacy mitigation section 
>>>  describes 
>>> some mitigations we could add for fingerprinting related concerns.
>>>
>>>
>>> I don't think exposing this by default to same origin iframes and 
>>> allowing the top-level browsing context to delegate its authority to use 
>>> getLayoutMap() to other iframes increases the concern any. If I'm thinking 
>>> about that wrong please let me know.
>>>
>>>  
>>>
>>> For the privacy section: I’ll make a change to add permission policy 
>>> along with the top level browsing context restriction to the spec.
>>>
>>>  
>>>
>>> *From:* Yoav Weiss  
>>> *Sent:* Friday, October 15, 2021 5:46 AM
>>> *To:* blink-dev 
>>> *Cc:* Anupam Snigdha ; Bo Cupp <
>>> pc...@microsoft.com>; Scott Low ; 
>>> gar...@chromium.org ; Yoav Weiss <
>>> yoavwe...@chromium.org>
>>> *Subject:* Re: [EXTERNAL] Re: Intent to Implement and Ship: Feature 
>>> policy for Keyboard API
>>>
>>>  
>>>
>>> Reading through https://wicg.github.io/keyboard-map/#privacy the only 
>>> risk here is increased fingerprinting surface. Is that correct?
>>>
>>> (aside - the privacy section states that the API is only available in 
>>> top-level contexts. You probably want to change that)
>>>
>>> On Thursday, October 14, 2021 at 10:09:04 PM UTC+2 snianu wrote:
>>>
>>> *Can you clarify what the current situation is?*
>>>
>>> getLayoutMap() which is part of the Keyboard API can only be accessed in 
>>> the top browsing context which cuts off access from same and cross origin 
>>> iframes.
>>>
>>> With this permission policy based solution, the default value would be 
>>> “Self” that grants access to same origin iframe by-default, but requires 
>>> web authors to add the “keyboard-map” value to allow attribute in order to 
>>> grant access within cross-origin iframes.
>>>
>>>  
>>>
>>> *IIUC, currently layout maps are not available at all to iframes. Is 
>>> that correct?*
>>>
>>> Correct.
>>>
>>>  
>>>
>>> *Also, are you suggesting to add a permission policy that would enable 
>>> it by default for same-origin iframes, and enable explicit delegation for 
>>> cross-origin iframes?*
>>>
>>> Yes.
>>>
>>>  
>>>
>>> -Anupam
>>>
>>>  
>>>
>>> *From:* Yoav Weiss  
>>> *Sent:* Thursday, October 14, 2021 12:29 PM
>>> *To:* blink-dev 
>>> *Cc:* Anupam Snigdha ; Bo Cupp <
>>> pc...@microsoft.com>; Scott Low ; 
>>> gar...@chromium.org 
>>> *Subject:* [EXTERNAL] Re: Intent to Implement and Ship: Feature policy 
>>> for Keyboard API
>>>
>>>  
>>>
>>>  
>>>
>>> On Tuesday, October 12, 2021 at 12:33:19 AM UTC+2 snianu wrote:
>>>
>>> Contact emails 
>>>
>>> sni...@microsoft.com
>>> Explainer 
>>>
>>> https://github.com/WICG/keyboard-map/issues/38 
>>>

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

2021-10-21 Thread Manuel Rego Casasnovas

LGTM2

On 21/10/2021 21:16, Daniel Bratell wrote:
> LGTM1
> 
> /Daniel
> 
> On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org wrote:
> 
> Correct, they’ll behave the same as the other non-legacy hints.
> 
> On Fri, Oct 15, 2021 at 05:34 Yoav Weiss  wrote:
> 
> Thanks for working on this, Ari!
> 
> IIUC, this intent will add these new hint names, but would
> also ensure their behavior when it comes to 3P delegation would
> be different from the legacy hints (as they don't have the same
> legacy baggage). Is that correct?
> 
> 
> On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula
>  wrote:
> 
> Contact emails
> 
> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
> 
> 
> Design Doc
> 
> 
> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
> 
> 
> 
> 
> Specification
> 
> https://wicg.github.io/client-hints-infrastructure/
> 
> 
> https://wicg.github.io/responsive-image-client-hints/
> 
> 
> https://wicg.github.io/savedata/#save-data-request-header-field
> 
> 
> https://wicg.github.io/netinfo/#networkinformation-interface
> 
> 
> 
> Summary
> 
> This proposal seeks to align our implementation with the
> Client Hint proposal
> by
> adding the `sec-ch-` prefix where it’s missing.
> 
> 
> Blink component
> 
> Privacy>Fingerprinting
> 
> 
> 
> 
> Motivation
> 
> Client Hints
> , a
> method to request information about the user's device or
> conditions, have been implemented in Chrome, but since the
> initial implementation the naming scheme has changed. If
> implemented, this proposal would add new client hints with a
> `sec-ch-` prefix to re-implement the following: `dpr`,
> `width`, `viewport-width`, and `device-memory`. The three
> network related client hints with legacy names, `rtt`,
> `downlink`, and `ect`, will not be updated as they may be
> replaced by different hints in an independent process.
> 
> 
> TAG review
> 
> Not needed
> 
> 
> Risks
> 
> Only Blink implements client hints and we are not (yet)
> removing any current ones, just re-implementing existing
> ones under the correct name. If usage permits, we will
> remove the legacy names in the future.
> 
>  
> 
> 
> Interoperability and Compatibility
> 
> Gecko: Client hints not implemented
> 
> WebKit: Client hints not implemented
> 
> Web developers: Positive interest from Cloudinary
> 
> 
> 
> 
> Is this feature fully tested by web-platform-tests?
> 
> Yes
> 
> 
> 
> 
> Tracking bug
> 
> https://crbug.com/1227043 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://www.chromestatus.com/feature/6658223894429696
> 
> 
> 
> -- 
> You received this message because you are subscribed to the
> Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to blink-dev+...@chromium.org.
> To view this discussion on the web visit
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
> 
> .
> 
> -- 
> ~ Ari Chivukula (Their/There/They’re)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group

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

LGTM1

/Daniel

On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org wrote:

> Correct, they’ll behave the same as the other non-legacy hints.
>
> On Fri, Oct 15, 2021 at 05:34 Yoav Weiss  wrote:
>
>> Thanks for working on this, Ari!
>>
>> IIUC, this intent will add these new hint names, but would also ensure 
>> their behavior when it comes to 3P delegation would be different from the 
>> legacy hints (as they don't have the same legacy baggage). Is that correct?
>>
>>
>> On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula  
>> wrote:
>>
>>> Contact emails
>>>
>>> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>>>
>>> Design Doc
>>>
>>>
>>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
>>>
>>> Specification
>>>
>>> https://wicg.github.io/client-hints-infrastructure/
>>>
>>> https://wicg.github.io/responsive-image-client-hints/
>>>
>>> https://wicg.github.io/savedata/#save-data-request-header-field
>>>
>>> https://wicg.github.io/netinfo/#networkinformation-interface
>>>
>>> Summary
>>>
>>> This proposal seeks to align our implementation with the Client Hint 
>>> proposal  by 
>>> adding the `sec-ch-` prefix where it’s missing.
>>>
>>> Blink component
>>>
>>> Privacy>Fingerprinting 
>>> 
>>>
>>> Motivation
>>>
>>> Client Hints , a 
>>> method to request information about the user's device or conditions, have 
>>> been implemented in Chrome, but since the initial implementation the naming 
>>> scheme has changed. If implemented, this proposal would add new client 
>>> hints with a `sec-ch-` prefix to re-implement the following: `dpr`, 
>>> `width`, `viewport-width`, and `device-memory`. The three network related 
>>> client hints with legacy names, `rtt`, `downlink`, and `ect`, will not be 
>>> updated as they may be replaced by different hints in an independent 
>>> process.
>>>
>>> TAG review
>>>
>>> Not needed
>>>
>>> Risks
>>>
>>> Only Blink implements client hints and we are not (yet) removing any 
>>> current ones, just re-implementing existing ones under the correct name. If 
>>> usage permits, we will remove the legacy names in the future.
>>>
>>>  
>>> Interoperability and Compatibility
>>>
>>> Gecko: Client hints not implemented
>>>
>>> WebKit: Client hints not implemented
>>>
>>> Web developers: Positive interest from Cloudinary 
>>> 
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> Yes 
>>> 
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1227043
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://www.chromestatus.com/feature/6658223894429696
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
> ~ Ari Chivukula (Their/There/They’re)
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop 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/c78c1e05-f468-4035-b444-629acee2f7a1n%40chromium.org.

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

2021-10-21 Thread Manuel Rego Casasnovas

LGTM3.

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

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

This got 3 LGTMs on a different thread.

On 2021-10-21 19:57, Daniel Bratell wrote:

LGTM2

/Daniel

On 2021-10-21 08:34, Yoav Weiss wrote:

LGTM1 to catch up with other implementations on this.

On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla wrote:

Contact emails

ssin...@igalia.com,

fw...@chromium.org

Explainer:

The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event

).
The securitypolicyviolation event is dispatched when there is
aContent Security Policy
violation.
Typically, the JS code of the web component will listen to
securitypolicyviolation events and react with necessary updates.

One could just use addEventListener, but for convenience and
consistency with other events (e.g. slotchange) it makes sense to
add a IDL onsecuritypolicyviolation attribute.We recently shipped
onslotchange idl attribute as well. See -

https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ

Developers are used to use EventTarget.onload = ... and , but if this does not work for all events, it will
be surprising.

Currently, the way to listen an event is:

target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be

availlable for the developers

element

Doc Link(s):

- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation

- https://github.com/whatwg/html/pull/2651

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

Specification

https://html.spec.whatwg.org

Summary

The securitypolicyviolation event is fired when a Content
Security Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers interface, so that one can register a
listener by attaching this attribute to target elements.

Blink component

Blink>DOM

Motivation

The securitypolicyviolation event is fired when a Content
Security Policy is violated.

One can naturally listen to that event via the

EventTarget.addEventListener() API. However, web developers are also

familiar with the alternative attribute-based form (e.g.

element.addEventListener("securitypolicyviolation

", ...) Vs on )

which is sometimes convenient for quick testing. For consistency with

other events, an attribute onsecuritypolicyviolation is thus added.

TAG review

TAG review status

This is asmall change to an existing spec implemented in
browsers and discussed at WHATWG -
https://github.com/whatwg/html/pull/2651,
https://github.com/w3c/webappsec-csp/issues/184

Agree that a TAG review is not needed in this case.

Risks

Interoperability and Compatibility

Gecko:

Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

WebKit:

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

Web developers:

N/A

Debuggability

No DevTools changes are required, treated like any other
event/attribute.

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

Yes

Web Platform Tests:

w3c/web-platform-tests/dom/idlharness.window.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt

w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html

Requires code in //chrome?

False

Tracking bug

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

Patch:

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

Estimated milestones

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5639484386312192

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

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email

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

Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on this 
thread.


/Daniel

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

LGTM2 to catch up here

(Apparently we have 2 intent emails for this..)

On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:

LGTM1.  It's a small straight-forward change.



On Thu, Oct 21, 2021 at 12:44 AM  wrote:

Contact emails
ssin...@igalia.com, fw...@chromium.org

Explainer:
The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation,

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event).
The securitypolicyviolation event is dispatched when there is
a Content
Security Policy violation. Typically, the JS code of the web
component
will listen to securitypolicyviolation events and react with
necessary
updates.

One could just use addEventListener, but for convenience and
consistency
with other events (e.g. slotchange) it makes sense to add a IDL
onsecuritypolicyviolation attribute which also reflect the
attribute on
elements. We recently shipped slotchange idl attriubte as well

(https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ)

Developers are habitual to use EventTarget.onload = ... and
 , but if this does not work for all events, it
will be
surprising.

Currently, the way to listen an event is:
target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be
availlable for the developers
element


Doc Link(s):
- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
- https://github.com/whatwg/html/pull/2651
-
https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Specification
https://html.spec.whatwg.org

Summary
The securitypolicyviolation event is fired when a Content Security
Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers
interface, so that one can register a listener by attaching this
attribute to target elements.

Blink component
Blink>DOM

Motivation
The securitypolicyviolation event is fired when a Content Security
Policy is violated.
One can naturally listen to that event via the
EventTarget.addEventListener() API. However, web developers
are also
familiar with the alternative attribute-based form (e.g.
element.addEventListener("securitypolicyviolation
", ...) Vs on )
which is sometimes convenient for quick testing. For
consistency with
other events, an attribute onsecuritypolicyviolation is thus
added.

TAG review
TAG review status
This is just a small change to an existing spec implemented in
browsers
and discussed at WHATWG

Risks
Interoperability and Compatibility

Gecko:
Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

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

Web developers:
N/A

Debuggability
No DevTools changes are required, treated like any other
event/attribute.

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

Web Platform Tests:
w3c/web-platform-tests/dom/idlharness.window.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt


w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html


Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1242893

Patch:
https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Estimated milestones
-

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5639484386312192

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

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

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

2021-10-21 Thread David Baron

The spec  requires
that "The combination of the User Agent and the output device fulfill all
of the following criteria" when describing what it means to be high
dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
HTML, or Canvas, I think it's probably incorrect to report that (dynamic-range:
high) is true based only on the device, which is what it looks to me like
the current code

does.  Admittedly, the spec could probably use some clarification as to
what it means for the User Agent to fulfill the criteria for both the
dynamic-range and video-dynamic-range queries, but my understanding of what
the spec is trying to say is that Chrome probably shouldn't say that
(dynamic-range:
high) is true until it supports wide-gamut colors in at least some and
maybe all of those contexts.

-David

On Wed, Oct 20, 2021 at 11:41 AM 'Will Cassella' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailscas...@chromium.org, chcunning...@chromium.org,
> videostack-...@chromium.org
>
> Explainer
> Adds MediaQueries for detecting HDR vs HDR displays
> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>
> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>
> Summary
>
> Adds media queries to CSS which allow a page to detect the current display
> device’s support for HDR. This feature adds two new CSS media queries:
> 'dynamic-range' and 'video-dynamic-range', both of which may be one of
> 'standard' or 'high'. Chrome will resolve these queries according to the
> capabilities of the display device the browser window is currently
> positioned on, allowing pages to toggle CSS rules accordingly or respond in
> Javascript via 'window.matchMedia()'.
>
>
> Blink componentBlink>CSS
> 
>
> Motivation
>
> As HDR-supported displays become more common, web developers need ways to
> enable HDR content on their web pages without compromising the experience
> for users of non-HDR displays, or mixed-HDR multi-display setups. CSS
> already provides the 'media query' concept for toggling rules based on
> display device characteristics, and this feature extends that set of
> queries to enable detecting HDR support on the current display device.
>
>
> Initial public proposal
>
> TAG reviewNot Filed. This is an incremental change to CSS Media Queries,
> already adopted by CSS WG.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/584)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
> Partially implemented - `video-dynamic-range` not yet supported
>
> Web developers: Positive (
> https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935)
> Feature designed with the help of Netflix.
>
>
> Debuggability
>
> No specific DevTools support
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
> https://wpt.fyi/results/css/mediaqueries/dynamic-range.html
>
> Flag nameCSSDynamicRangeMediaQueries
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1224711
>
> Estimated milestones97
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680926106320896
>
> 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/CAKj4DkD1-oS5OSZye8DwcGhdrYVwKYv3omYOwE0p-WCm3L77iw%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/CAG0MU3gHMxyCBxWphPTg4mP8RNbsJQC30pAaB4-P4%3D-FLA4B0w%40mail.gmail.com.

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

LGTM2

/Daniel

On 2021-10-21 08:34, Yoav Weiss wrote:

LGTM1 to catch up with other implementations on this.

On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla wrote:

Contact emails

ssin...@igalia.com,

fw...@chromium.org

Explainer:

The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event

https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ

Developers are used to use EventTarget.onload = ... and , but if this does not work for all events, it will
be surprising.

Currently, the way to listen an event is:

target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be

availlable for the developers

element

Doc Link(s):

- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation

- https://github.com/whatwg/html/pull/2651

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

Specification

https://html.spec.whatwg.org

Summary

The securitypolicyviolation event is fired when a Content Security
Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers interface, so that one can register a listener
by attaching this attribute to target elements.

Blink component

Blink>DOM

Motivation

The securitypolicyviolation event is fired when a Content Security
Policy is violated.

One can naturally listen to that event via the

EventTarget.addEventListener() API. However, web developers are also

familiar with the alternative attribute-based form (e.g.

element.addEventListener("securitypolicyviolation

", ...) Vs on )

which is sometimes convenient for quick testing. For consistency with

other events, an attribute onsecuritypolicyviolation is thus added.

TAG review

TAG review status

This is asmall change to an existing spec implemented in browsers
and discussed at WHATWG -
https://github.com/whatwg/html/pull/2651,
https://github.com/w3c/webappsec-csp/issues/184

Agree that a TAG review is not needed in this case.

Risks

Interoperability and Compatibility

Gecko:

Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

WebKit:

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

Web developers:

N/A

Debuggability

No DevTools changes are required, treated like any other
event/attribute.

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

Yes

Web Platform Tests:

w3c/web-platform-tests/dom/idlharness.window.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt

w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html

Requires code in //chrome?

False

Tracking bug

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

Patch:

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

Estimated milestones

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5639484386312192

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

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

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

2021-10-21 Thread Will Cassella

I created a thread in the webkit-dev mailing list

asking for clarification on their status on video-dynamic-range.
Reading the discussion on that GitHub thread, I don't think that should
have any effect on this MQ since it's unitless, and the primary concern
there is just inconsistencies with units.

On Thu, Oct 21, 2021 at 9:38 AM Fernando Serboncini 
wrote:

> Is there any signal from WebKit about video-* specifically?
>
> Also, are we assuming that the current issue on CSSWG
>  (and the implementation
> warning) about video-* numerical properties will have no impact on this?
> I.e., Is it just about the units or is there a chance that the whole
> video-* approach may be completely changed?
>
>
>
> On Wed, Oct 20, 2021 at 11:41 AM 'Will Cassella' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailscas...@chromium.org, chcunning...@chromium.org,
>> videostack-...@chromium.org
>>
>> Explainer
>> Adds MediaQueries for detecting HDR vs HDR displays
>> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
>> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>>
>> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>>
>> Summary
>>
>> Adds media queries to CSS which allow a page to detect the current
>> display device’s support for HDR. This feature adds two new CSS media
>> queries: 'dynamic-range' and 'video-dynamic-range', both of which may be
>> one of 'standard' or 'high'. Chrome will resolve these queries according to
>> the capabilities of the display device the browser window is currently
>> positioned on, allowing pages to toggle CSS rules accordingly or respond in
>> Javascript via 'window.matchMedia()'.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> Motivation
>>
>> As HDR-supported displays become more common, web developers need ways to
>> enable HDR content on their web pages without compromising the experience
>> for users of non-HDR displays, or mixed-HDR multi-display setups. CSS
>> already provides the 'media query' concept for toggling rules based on
>> display device characteristics, and this feature extends that set of
>> queries to enable detecting HDR support on the current display device.
>>
>>
>> Initial public proposal
>>
>> TAG reviewNot Filed. This is an incremental change to CSS Media Queries,
>> already adopted by CSS WG.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: Worth prototyping (
>> https://github.com/mozilla/standards-positions/issues/584)
>>
>> WebKit: Shipped/Shipping (
>> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
>> Partially implemented - `video-dynamic-range` not yet supported
>>
>> Web developers: Positive (
>> https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935)
>> Feature designed with the help of Netflix.
>>
>>
>> Debuggability
>>
>> No specific DevTools support
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>> https://wpt.fyi/results/css/mediaqueries/dynamic-range.html
>>
>> Flag nameCSSDynamicRangeMediaQueries
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1224711
>>
>> Estimated milestones97
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5680926106320896
>>
>> 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/CAKj4DkD1-oS5OSZye8DwcGhdrYVwKYv3omYOwE0p-WCm3L77iw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/OpUsOWnnN6c/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CADp2-T87%3DwjHw-M1TUHQTiPN26WyXijkxzcrO2XXezCHH8sY4g%40mail.gmail.com
> 
> .
>

-- 
You received this message because

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


LGTM2.

/Daniel

On 2021-10-21 08:19, Yoav Weiss wrote:

LGTM1
Seems important to catch up here, so thanks for working on this!!

On Mon, Oct 18, 2021 at 11:05 PM David Baron  wrote:


Contact emails


dba...@chromium.org, kev...@chromium.org, fla...@chromium.org


Explainer


None


Specification


https://drafts.csswg.org/css-transforms-2/#individual-transforms


Summary


This adds three new CSS properties: translate, rotate, and
scale. This exposes a simple way for web developers to
access transforms in an intuitive way, without having to
think about how functions in the transform property
interact with each other. The properties are individually
animatable.



Blink component


Blink



TAG review


Already shipped in two browser engines.


TAG review status


Not applicable (I think)


Risks




Interoperability and Compatibility




Gecko: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
Shipped in Firefox 72, January 2020.

WebKit: Shipped/Shipping
(https://webkit.org/blog/11420/css-individual-transform-properties/)
Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.

Web developers: Positive: 25 stars on
https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
Notable early developer request for the feature (before WG
adoption) in:
https://twitter.com/rachelnabors/status/618266391993454592
https://twitter.com/rachelnabors/status/618267483296825344 and
early reaction to WG adoption in
https://twitter.com/SaraSoueidan/status/613368671315054592 .
Positive developer reactions to
https://twitter.com/argyleink/status/1338907239990497280 .
Largely positive reactions to news of other engines
shipping the feature in responses to
https://twitter.com/jensimmons/status/1387870244392382468 ,
https://twitter.com/simevidas/status/627956718098485248 ,
https://twitter.com/dancwilson/status/121457225783989862 ,
and in
https://twitter.com/guerriero_se/status/1338468028804001796 ,
https://twitter.com/eladsc/status/1216286886697885696 ,
https://twitter.com/_zouhir/status/1389461399026294791 .
More recent developer interest in
https://twitter.com/anatudor/status/1377491818636587008 ,
https://twitter.com/anatudor/status/1309200388311199751 .


Debuggability


Has the standard exposure in devtools that all CSS
properties have.



Is this feature fully tested by web-platform-tests

?


Yes


Flag name


CSSIndependentTransformProperties


Requires code in //chrome?


False


Tracking bug


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


Estimated milestones

The feature has been implemented behind a flag on
desktop/android/WebView since Chrome 45 (not a typo).

For an estimated milestone for shipping, I think the feature is
close to being ready, so I'm still hoping for Chrome 97 but can't
promise that it will be ready in time.  It's waiting on a single
chain of dependencies, as described in the bug
,
so that more than one of the transform properties on a single
element can be simultaneously animated on the compositor.


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5705698193178624


Links to previous Intent discussions


Intent to prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/-GfE73tlLX8/m/hv7Qitys6j8J


This intent message was generated by Chrome Platform
Status  and then
hand-edited a bit.



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

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

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

LGTM1 to ship conditional that y'all continue to work on PR 
#158
 specifically, and clarifying the spec's processing model in general
Yes, we’re committed to work on improving the clipboard API spec. That is sort 
of a prerequisite for Pickling API 

Also, can you add tests for both input cases as part of your CLs for this?
Yep, already added: 
https://chromium-review.googlesource.com/c/chromium/src/+/3169593

@Ashley Gullen user activation is orthogonal to this 
change. The intent of this change is to align the Clipboarditem API with the 
spec and Safari. This is needed to support promises to Blobs so web authors 
don’t have to create Blobs synchronously. This may not matter much to sites 
that have small payloads, but sites like Excel Online where the workbook could 
contain charts, images etc wouldn’t be able to synchronously create Blobs just 
in time to satisfy the user activation requirement of async clipboard write 
method.

From: Ashley Gullen 
Sent: Thursday, October 21, 2021 6:37 AM
To: Yoav Weiss 
Cc: Anupam Snigdha ; ann...@annevk.nl ; 
blin...@chromium.org ; Marijn Kruisselbrink 
; Bo Cupp 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

I'm not sure why this API needs to exist.

It used to be the case that you could not write to the clipboard after await in 
Chrome. That's because after an await it was no longer in a synchronous user 
input trigger, and so the call was blocked.

User Activation v2 fixed that. Now you can write to the clipboard after await 
in Chrome, because the User Activation v2 rules mean you get a 1 second timeout 
during which you can write to the clipboard. So long as the async code runs 
quickly (and it almost always will if you're just doing something like reading 
a Blob), then everything works.

Safari and Firefox don't support User Activation v2, so still have the original 
problem. It appears this proposal aims to solve the same problem that User 
Activation v2 does. IMO it would be better if Safari and Firefox just support 
User Activation v2 as well.

Assuming a browser supports UAv2, the only benefit this API would appear to 
bring, is the ability to write to the clipboard beyond the 1 second deadline. 
If the deadline is unlimited, then this effectively grants the web page 
permission to write to the clipboard *at any time* after the first copy 
operation.

Is the intent of this API really just to allow an unlimited deadline? Aren't 
there ways that could be abused?


On Thu, 21 Oct 2021 at 10:21, Yoav Weiss 
mailto:yoavwe...@chromium.org>> wrote:
LGTM1 to ship conditional that y'all continue to work on PR 
#158
 specifically, and clarifying the spec's processing model in general.
On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:
Gentle ping as the branch cutoff date for 97 is pretty close. While I agree 
that the issues related to clipboard API spec need to be addressed, I don’t 
think this feature needs to be blocked on that. It’s not a breaking change i.e. 
sites can continue to use Blobs if they want to(although I don’t think any 
developer would want to have different codepaths for Apple and Chromium 
browsers)

FWIW, I got curious RE why that *should* work, and did some digging.
It seems like the bindings methods that accept a `Promise` input value call 
`NativeValueTraits`
 on that value, which

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

2021-10-21 Thread Fernando Serboncini

Is there any signal from WebKit about video-* specifically?

Also, are we assuming that the current issue on CSSWG
 (and the implementation
warning) about video-* numerical properties will have no impact on this?
I.e., Is it just about the units or is there a chance that the whole
video-* approach may be completely changed?



On Wed, Oct 20, 2021 at 11:41 AM 'Will Cassella' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailscas...@chromium.org, chcunning...@chromium.org,
> videostack-...@chromium.org
>
> Explainer
> Adds MediaQueries for detecting HDR vs HDR displays
> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>
> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>
> Summary
>
> Adds media queries to CSS which allow a page to detect the current display
> device’s support for HDR. This feature adds two new CSS media queries:
> 'dynamic-range' and 'video-dynamic-range', both of which may be one of
> 'standard' or 'high'. Chrome will resolve these queries according to the
> capabilities of the display device the browser window is currently
> positioned on, allowing pages to toggle CSS rules accordingly or respond in
> Javascript via 'window.matchMedia()'.
>
>
> Blink componentBlink>CSS
> 
>
> Motivation
>
> As HDR-supported displays become more common, web developers need ways to
> enable HDR content on their web pages without compromising the experience
> for users of non-HDR displays, or mixed-HDR multi-display setups. CSS
> already provides the 'media query' concept for toggling rules based on
> display device characteristics, and this feature extends that set of
> queries to enable detecting HDR support on the current display device.
>
>
> Initial public proposal
>
> TAG reviewNot Filed. This is an incremental change to CSS Media Queries,
> already adopted by CSS WG.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/584)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
> Partially implemented - `video-dynamic-range` not yet supported
>
> Web developers: Positive (
> https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935)
> Feature designed with the help of Netflix.
>
>
> Debuggability
>
> No specific DevTools support
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
> https://wpt.fyi/results/css/mediaqueries/dynamic-range.html
>
> Flag nameCSSDynamicRangeMediaQueries
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1224711
>
> Estimated milestones97
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680926106320896
>
> 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/CAKj4DkD1-oS5OSZye8DwcGhdrYVwKYv3omYOwE0p-WCm3L77iw%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/CADp2-T87%3DwjHw-M1TUHQTiPN26WyXijkxzcrO2XXezCHH8sY4g%40mail.gmail.com.

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

2021-10-21 Thread Ryan Sleevi

Thanks Sasha!

TL;DR: I think we've got enough information here to make a decision. You've
been *incredibly* *helpful* for that. What follows is my personal views,
not a decision, and I share them not to shut down the conversation, but
instead, to keep the conversation going and to continue to move us closer
to a conclusion :)

Speaking personally, I'd be worried about implementing this in Chromium.
You've been *incredibly* helpful here in helping understand, but I worry
this highlights a worrying lack of documentation here, as well as a lack of
holistic integration into the Web Platform. Extensions obviously have
incredible power and flexibility, and can "break" the assumptions of the
Web Platform in many ways, to both the delight (e.g. introducing new
features) and consternation (e.g. breaking existing features) of users. Yet
as extensions, it's also an area where it's "not our problem" to support.

That seems like I'm arguing we (Chromium) shouldn't do it because it means
more work for us, but that's not quite where I'm going. Rather, to
integrate this into Chromium means making sure Chromium developers have the
knowledge to understand and reason about how this will interact with the
Web Platform, how the Web Platform can co-evolve with features like this,
and how it fits overall into Chromium's 4 S's (Simplicity, Speed, Security,
Stability). In particular, I think as mmenke@ alluded to, this makes it
difficult to reason about privacy properties: for example, it means
clearing cookies in Chrome may no longer clear cookies, because these IDP
APIs may hold on to them. For things like the effort to safely partition
and isolate cookies, this means it's difficult to reason about how these
APIs behave in 1P vs 3P contexts. In terms of stability, this seems
intended to be an extensible platform, and thus potentially brings more 3P
code into whatever process implements this (the proposals, at present, are
for the browser process, due to network service sandboxing). When we think
about how potential 3P (non-MS) IdPs would use this API, it sounds like
that this would de facto mean that they'd need to use "x-ms-" as a prefix
for their headers, and that, similarly, there's a lack of way to feed back
in to the IdP the state of the user as to whether headers-or-cookies should
be used.

I appreciate Microsoft's attempt to provide some isolation for the Web from
their experimental headers ("x-"), but as RFC 6648 Section 3 highlights,
this doesn't really work in practice, and the use of "x-" headers doesn't
really prevent them from becoming de facto standards (as the previous
remark highlights).

My worry is that if directly implemented in Chromium, these all become
concerns Chromium needs to worry about, and Chromium needs to support and
address. We can't just remove a feature when it gets difficult, or there
isn't sufficient documentation, and while I'm not trying to suggest we can
arbitrarily break extensions either, we don't necessarily have to reason
about every extension's behaviour prior to making any changes to Chromium,
like we do need to do with Chromium features. For users, "Chromium is
broken", and there's not an option to point out that "no, the extension is
broken" as there is today.

I do worry that because this flow can only really be implemented in
conjunction with Windows (and WAM), it makes it easy for websites to
construct experiences that "Work best with Edge" or, if Chromium
implements, "Work best with Chromium". For example, if an internal website
required these assertions, then they would not work with Firefox - unless
the user installed the extension or unless Firefox also integrated with
Microsoft's proprietary APIs. While it's certainly true that an internal
website (or IdP) could provide a "fallback path" for a "less" secure
browser (i.e. one that doesn't provide TPM-bound cookies), I think
practical experience of enterprises in the past suggest that may be less
likely.

I'm very concerned that this sort of thing doesn't have a path towards
standardization or interoperability. I realize that, in part, this approach
to WAM is a reflection of the fact that Token Binding shared many of these
limitations, and we intentionally removed Token Binding precisely because
of its incompatibility with, and lack of explaininability with, the overall
Web Platform. This is conceptually similar in the challenges, but with even
less multi-stakeholder agreement or interoperable specification, and so
that does worry me. Similarly, I do worry that this favors a particular IdP
being able to offer both technical solutions and ease of use over those of
others, both because at least one IdP will always work "out of the box" on
some OSes, but also because the access to change those requirements as
needed (e.g. the shift from cookies to headers) that other IdPs can't
easily do.

But that's just my opinion, and I certainly wouldn't be the one to have
final say here, especially since I'm known for taking the most

[blink-dev] Intent to Extend Origin Trial: Conversion Measurement API (Attribution Reporting API)

2021-10-21 Thread John Delaney

*Contact emails*
johni...@chromium.org, csharri...@chromium.org

*Explainer*
https://github.com/WICG/conversion-measurement-api/blob/main/event_attribution_reporting_clicks.md

*Design docs/spec*
https://wicg.github.io/conversion-measurement-api/

*Summary*
This is a new API for measuring conversions (e.g. purchases) and
attributing them to clicked ads, without using cross-site persistent
identifiers like third party cookies.

*Link to “Intent to Prototype” blink-dev discussion*
https://groups.google.com/a/chromium.org/d/msg/blink-dev/7B0ldtZR_68/GjLBu0n4DgAJ

*Link to “Intent to Experiment” blink-dev discussion*
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ib9-tDFitns/Sm9RXTNaBwAJ

First extension:
https://groups.google.com/a/chromium.org/g/blink-dev/c/C0P7ePjITJQ/m/ZYFmn30SDQAJ

Second extension:
https://groups.google.com/a/chromium.org/g/blink-dev/c/xCWP1ltlAgw/m/acwN0GIRBQAJ
Third extension:
https://groups.google.com/a/chromium.org/g/blink-dev/c/DmsUL3KHqMk/m/J2v3I_aEBAAJ

*Goals for experimentation*
We hope to see that the data produced by the API is comparable to existing
cookie-based mechanisms.

*Experimental timeline*
We'd like to extend the origin trial for 3 milestones, continuing through
Chrome 97 (95/96/97). The experiment has been running from Chrome 86-94.

*Any risks when the experiment finishes?*
This API is only additive and does not affect any existing state. Current
conversion measurement solutions will work as expected with and without the
API, so we don’t believe there are any risks.

The Origin Trial tokens for Chrome 94 expired on October 12th. The API has
been effectively disabled since then, so there will be a gap in
availability.

We have previously requested an exception to the .5% page load usage limit
for Origin Trials. Page load usage is currently around .48% in October, and
was at .5% on average in September.
https://chromestatus.com/metrics/feature/timeline/popularity/3365

*Reason this experiment is being extended*
We have two more non-google testers interested in experimenting with the
API who have not yet been able to start experiments. The proposed API is
fundamentally different in a number of ways from cookie-based mechanisms,
which can make setting up experiments time consuming.

Given the wide range of environments where this API will be used, we expect
new testers to produce different learnings and feedback on the API, even
without changes to the API.

*Ongoing technical constraints*
None.

*Will this feature be supported on all five Blink platforms supported by
Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?*
Yes.

*Link to entry on the feature dashboard*
*https://chromestatus.com/feature/6412002824028160
*

--
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/979272b9-a236-49ec-b333-cb700b82fcd3n%40chromium.org.

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

2021-10-21 Thread 'Ashley Gullen' via blink-dev

I'm not sure why this API needs to exist.

It used to be the case that you could not write to the clipboard after
await in Chrome. That's because after an await it was no longer in a
synchronous user input trigger, and so the call was blocked.

User Activation v2 fixed that. Now you can write to the clipboard after
await in Chrome, because the User Activation v2 rules mean you get a 1
second timeout during which you can write to the clipboard. So long as the
async code runs quickly (and it almost always will if you're just doing
something like reading a Blob), then everything works.

Safari and Firefox don't support User Activation v2, so still have the
original problem. It appears this proposal aims to solve the same problem
that User Activation v2 does. IMO it would be better if Safari and Firefox
just support User Activation v2 as well.

Assuming a browser supports UAv2, the only benefit this API would appear to
bring, is the ability to write to the clipboard beyond the 1 second
deadline. If the deadline is unlimited, then this effectively grants the
web page permission to write to the clipboard *at any time* after the first
copy operation.

Is the intent of this API really just to allow an unlimited deadline?
Aren't there ways that could be abused?

On Thu, 21 Oct 2021 at 10:21, Yoav Weiss  wrote:

> LGTM1 to ship conditional that y'all continue to work on PR #158
>  specifically, and
> clarifying the spec's processing model in general.
>
> On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:
>
>> Gentle ping as the branch cutoff date for 97 is pretty close. While I
>> agree that the issues related to clipboard API spec need to be addressed, I
>> don’t think this feature needs to be blocked on that. It’s not a breaking
>> change i.e. sites can continue to use Blobs if they want to(although I
>> don’t think any developer would want to have different codepaths for Apple
>> and Chromium browsers)
>>
>
> FWIW, I got curious RE why that *should* work, and did some digging.
> It seems like the bindings methods that accept a `Promise` input value
> call `NativeValueTraits
> `
> on that value, which casts
> 
> the value foo into a `Promise.resolve(foo)`, if it wasn't a Promise already.
> The same seems to work in WebKit as well. Do you know if this bindings
> behavior is specified?
>
> Also, can you add tests for both input cases as part of your CLs for this?
>
> , and Apple has already shipped this feature. Please let me know in case
>> of any concerns.
>>
>>
>>
>> -Anupam
>>
>>
>>
>> *From:* Anupam Snigdha
>> *Sent:* Thursday, October 7, 2021 9:53 AM
>> *To:* 'Yoav Weiss' 
>> *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
>>
>>
>>
>> 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 
>> 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' ; Anne van Kesteren <
>> ann...@annevk.nl>
>> *Cc:* blink-dev ; Marijn Kruisselbrink <
>> 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
>>
>>
>>
>> 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

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

2021-10-21 Thread 'Thomas Steiner' via blink-dev

Any plans to move the ﹀ icon into the three dots menu? It looks a bit ugly.
There is an experiment to move the puzzle piece into the three dots menu,
too, so maybe this icon could be there, too? Maybe after the user has
toggled it for the first time to not hurt discoverability of WCO (even
further).

On Thu, Oct 21, 2021 at 9:31 AM Yoav Weiss  wrote:

> This is an exciting improvement to PWA parity with native apps! :)
>
> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> amb...@microsoft.com, luigo...@microsoft.com, hata...@microsoft.com,
>> c...@chromium.org
>>
>>
>> Explainer
>>
>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
>>
>>
>> Specification
>>
>> https://wicg.github.io/window-controls-overlay/
>>
>
> The spec looks like it could use some work. Beyond the editorial, it
> doesn't seem like it defines the novel concepts that it introduces, nor the
> relevant processing models.
>
>
>>
>> Design docs
>>
>>
>>
>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md
>>
>>
>> Summary
>>
>> Window Controls Overlay allows a developer to create a custom title bar
>> UX by extending the installed app’s client area. The client area now covers
>> the entire window except for the window controls (close, maximize/restore,
>> minimize), which are overlaid in their respective position.
>>
>>
>>
>> The web app developer is responsible for drawing and input-handling for
>> the entire window except for the window controls overlay. This includes
>> defining which area of the window is draggable as well, with a prefixed and
>> non-prefixed version of a css property supported, as implemented in:
>> crrev.com/c/3094474.
>>
>>
>>
>> Intended uses for the Window Controls Overlay are creating seamless UX
>> that can use the area that was reserved for the title bar before. Many
>> modern applications include menus, search bars and other controls in the
>> title bar, and this feature enables this on installed web apps.
>>
>>
>> Blink component
>>
>> UI>Browser>WebAppInstalls
>> 
>>
>>
>> Search tags
>>
>> PWA , web app
>> , title bar
>> , titlebar
>> , customization
>> , window controls
>> 
>>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/481
>>
>>
>> TAG review status
>>
>> Resolution: satisfied
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Given that Edge has interest in the feature, there would be at least one
>> other browser that implements it. The feature involves additive changes
>> (new web app manifest entry, new JS API, new CSS env variables) and
>> modifications (changes to frame, new use of env(safe-area-inset-*), but no
>> removals, so the compatibility risk is minimal.
>>
>
>>
>> Gecko: defer https://github.com/mozilla/standards-positions/issues/529
>>
>>
>>
>> WebKit: No signal
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html
>>
>>
>>
>> Web developers: Positive
>>
>> https://twitter.com/firt/status/1385238446046859268?s=20
>>
>> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20
>>
>> https://twitter.com/bashik7/status/1385821988208275457?s=20
>>
>> https://twitter.com/abraham/status/1385201046767738880?s=20
>>
>>
>> Ergonomics
>>
>> The changes associated with this feature will only be enabled for PWAs
>> that opt-in to it, so there are minimal risks posed to the browser as a
>> whole. A PWA that opts-in to the feature should also have minimal
>> ergonomics risk since the manifest already needs to be parsed on startup to
>> determine the correct display mode in which the app should be launched, so
>> adding one extra manifest check on startup should have minimal impact.
>>
>>
>> Activation
>>
>> The activation risk is low since this feature includes all the tools
>> needed to create an app that uses the full extent of the window: new
>> UA-provided window controls overlay, JS APIs to query the size of the
>> overlay, and CSS environment variables to layout content around the overlay.
>>
>
> What do we expect developers to do as a fallback in non-supporting
> browsers?
>
>>
>> Security
>>
>> The major risk is that giving sites partial control over the top of the
>> app window allows developers to spoof content in what was previously a
>> trusted, UA-controlled region. To minimize the risk of spoofing, the app
>> will open by default in “standalone” mode with a full width title bar, and
>> the user can toggle window controls overlay on and off via a button in the
>> title bar/overlay.
>>
>
> OK, so both the app *and*

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

2021-10-21 Thread Yutaka Hirano

On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss  wrote:

>
>
> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano 
> wrote:
>
>> (The implementation CL
>>  is
>> under review. This intent is written as if it's landed.)
>>
>> Contact emailsyhir...@chromium.org
>>
>> Specification
>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>
>> Summary
>>
>> A CORS non-wildcard request header[1] is an HTTP request header which is
>> not covered by the wildcard symbol ("*") in the
>> access-control-allow-headers header. "authorization" is the only member of
>> CORS non-wildcard request-header. Currently we treat the header as a usual
>> header, which is problematic for security reasons. Implement it, and change
>> the current behavior. 1:
>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>
>>
>> Blink componentBlink>SecurityFeature>CORS
>> 
>>
>> TAG reviewNot needed because this implements an existing feature.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk is low because Mozilla and Apple showed an intent
>> to implement this behavior. There is some compatibility risk, as the use
>> counter[2] shows 0.04% websites would be affected. To mitigate the risk,
>> we've shown a deprecation message for a few milestones.
>>
>
> Can you similarly send deprecation reports as well? How long have the
> deprecation messages been in place? Did we see any decline in the numbers?
>
> We've shown the deprecation message since Chrome 94

whose
beta promotion was on Aug 26 and stable release was on Sep 21.
We use CountDeprecation which sends deprecation reports automatically IIUC.

I don't see any decline.


> Have we looked into which URLs are triggering this? (and if it's a few
> medium-sized properties or many tiny ones)
>

I haven't looked at the data.

> Did we try outreach?
>
No.

>
> We have an enterprise policy so that administrators can keep the existing
>> behavior. We're planning to remove the policy on Chrome 103. 2:
>> https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCovered
>> ByWildcard
>>
>>
>> Gecko: Positive Firefox showed a positive signal in a private thread.
>>
>> WebKit: Positive Apple showed a positive signal in a private thread.
>>
>> Web developers: No signals
>>
>>
>> Debuggability
>>
>> We'll show a CORS error to the devtools console.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag nameCorsNonWildcardRequestHeadersSupport
>>
>> Requires code in //chrome?False (or, True only for the enterprise
>> policy.)
>>
>> Tracking bughttps://crbug.com/1176753
>>
>> Estimated milestones
>>
>> 97
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5742041264816128
>>
>> --
>> 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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano  wrote:

> (The implementation CL
>  is
> under review. This intent is written as if it's landed.)
>
> Contact emailsyhir...@chromium.org
>
> Specification
> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>
> Summary
>
> A CORS non-wildcard request header[1] is an HTTP request header which is
> not covered by the wildcard symbol ("*") in the
> access-control-allow-headers header. "authorization" is the only member of
> CORS non-wildcard request-header. Currently we treat the header as a usual
> header, which is problematic for security reasons. Implement it, and change
> the current behavior. 1:
> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>
>
> Blink componentBlink>SecurityFeature>CORS
> 
>
> TAG reviewNot needed because this implements an existing feature.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low because Mozilla and Apple showed an intent to
> implement this behavior. There is some compatibility risk, as the use
> counter[2] shows 0.04% websites would be affected. To mitigate the risk,
> we've shown a deprecation message for a few milestones.
>

Can you similarly send deprecation reports as well? How long have the
deprecation messages been in place? Did we see any decline in the numbers?

Have we looked into which URLs are triggering this? (and if it's a few
medium-sized properties or many tiny ones)
Did we try outreach?

We have an enterprise policy so that administrators can keep the existing
> behavior. We're planning to remove the policy on Chrome 103. 2:
> https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard
>
>
> Gecko: Positive Firefox showed a positive signal in a private thread.
>
> WebKit: Positive Apple showed a positive signal in a private thread.
>
> Web developers: No signals
>
>
> Debuggability
>
> We'll show a CORS error to the devtools console.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag nameCorsNonWildcardRequestHeadersSupport
>
> Requires code in //chrome?False (or, True only for the enterprise policy.)
>
> Tracking bughttps://crbug.com/1176753
>
> Estimated milestones
>
> 97
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5742041264816128
>
> --
> 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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%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/CAL5BFfW0ofFGpY-JrYjb%3DZFVeq%2BCE4-pqFBVE%3D87cHrCzaCx3w%40mail.gmail.com.

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

LGTM1 to ship conditional that y'all continue to work on PR #158 
 specifically, and 
clarifying the spec's processing model in general.

On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:

> Gentle ping as the branch cutoff date for 97 is pretty close. While I 
> agree that the issues related to clipboard API spec need to be addressed, I 
> don’t think this feature needs to be blocked on that. It’s not a breaking 
> change i.e. sites can continue to use Blobs if they want to(although I 
> don’t think any developer would want to have different codepaths for Apple 
> and Chromium browsers)
>

FWIW, I got curious RE why that *should* work, and did some digging.
It seems like the bindings methods that accept a `Promise` input value 
call `NativeValueTraits 
`
 
on that value, which casts 

 
the value foo into a `Promise.resolve(foo)`, if it wasn't a Promise already.
The same seems to work in WebKit as well. Do you know if this bindings 
behavior is specified?

Also, can you add tests for both input cases as part of your CLs for this?

, and Apple has already shipped this feature. Please let me know in case of 
> any concerns.
>
>  
>
> -Anupam
>
>  
>
> *From:* Anupam Snigdha 
> *Sent:* Thursday, October 7, 2021 9:53 AM
> *To:* 'Yoav Weiss' 
> *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
>
>  
>
> 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  
> 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' ; Anne van Kesteren <
> ann...@annevk.nl>
> *Cc:* blink-dev ; Marijn Kruisselbrink <
> 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
>
>  
>
> 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 
>

[blink-dev] Intent to Ship: CORS non-wildcard request-header

2021-10-21 Thread Yutaka Hirano

(The implementation CL
is
under review. This intent is written as if it's landed.)

Contact emailsyhir...@chromium.org

Specification
https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is
not covered by the wildcard symbol ("*") in the
access-control-allow-headers header. "authorization" is the only member of
CORS non-wildcard request-header. Currently we treat the header as a usual
header, which is problematic for security reasons. Implement it, and change
the current behavior. 1:
https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink componentBlink>SecurityFeature>CORS

TAG reviewNot needed because this implements an existing feature.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to
implement this behavior. There is some compatibility risk, as the use
counter[2] shows 0.04% websites would be affected. To mitigate the risk,
we've shown a deprecation message for a few milestones. We have an
enterprise policy so that administrators can keep the existing behavior.
We're planning to remove the policy on Chrome 103. 2:
https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals

Debuggability

We'll show a CORS error to the devtools console.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameCorsNonWildcardRequestHeadersSupport

Requires code in //chrome?False (or, True only for the enterprise policy.)

Tracking bughttps://crbug.com/1176753

Estimated milestones

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

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

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

This is an exciting improvement to PWA parity with native apps! :)

On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> amb...@microsoft.com, luigo...@microsoft.com, hata...@microsoft.com,
> c...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
>
>
> Specification
>
> https://wicg.github.io/window-controls-overlay/
>

The spec looks like it could use some work. Beyond the editorial, it
doesn't seem like it defines the novel concepts that it introduces, nor the
relevant processing models.


>
> Design docs
>
>
>
> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md
>
>
> Summary
>
> Window Controls Overlay allows a developer to create a custom title bar UX
> by extending the installed app’s client area. The client area now covers
> the entire window except for the window controls (close, maximize/restore,
> minimize), which are overlaid in their respective position.
>
>
>
> The web app developer is responsible for drawing and input-handling for
> the entire window except for the window controls overlay. This includes
> defining which area of the window is draggable as well, with a prefixed and
> non-prefixed version of a css property supported, as implemented in:
> crrev.com/c/3094474.
>
>
>
> Intended uses for the Window Controls Overlay are creating seamless UX
> that can use the area that was reserved for the title bar before. Many
> modern applications include menus, search bars and other controls in the
> title bar, and this feature enables this on installed web apps.
>
>
> Blink component
>
> UI>Browser>WebAppInstalls
> 
>
>
> Search tags
>
> PWA , web app
> , title bar
> , titlebar
> , customization
> , window controls
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/481
>
>
> TAG review status
>
> Resolution: satisfied
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> Given that Edge has interest in the feature, there would be at least one
> other browser that implements it. The feature involves additive changes
> (new web app manifest entry, new JS API, new CSS env variables) and
> modifications (changes to frame, new use of env(safe-area-inset-*), but no
> removals, so the compatibility risk is minimal.
>

>
> Gecko: defer https://github.com/mozilla/standards-positions/issues/529
>
>
>
> WebKit: No signal
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html
>
>
>
> Web developers: Positive
>
> https://twitter.com/firt/status/1385238446046859268?s=20
>
> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20
>
> https://twitter.com/bashik7/status/1385821988208275457?s=20
>
> https://twitter.com/abraham/status/1385201046767738880?s=20
>
>
> Ergonomics
>
> The changes associated with this feature will only be enabled for PWAs
> that opt-in to it, so there are minimal risks posed to the browser as a
> whole. A PWA that opts-in to the feature should also have minimal
> ergonomics risk since the manifest already needs to be parsed on startup to
> determine the correct display mode in which the app should be launched, so
> adding one extra manifest check on startup should have minimal impact.
>
>
> Activation
>
> The activation risk is low since this feature includes all the tools
> needed to create an app that uses the full extent of the window: new
> UA-provided window controls overlay, JS APIs to query the size of the
> overlay, and CSS environment variables to layout content around the overlay.
>

What do we expect developers to do as a fallback in non-supporting
browsers?

>
> Security
>
> The major risk is that giving sites partial control over the top of the
> app window allows developers to spoof content in what was previously a
> trusted, UA-controlled region. To minimize the risk of spoofing, the app
> will open by default in “standalone” mode with a full width title bar, and
> the user can toggle window controls overlay on and off via a button in the
> title bar/overlay.
>

OK, so both the app *and* the user need to opt-in?

>
> Debuggability
>
> The feature itself can be easily debugged by installing the PWA. Since it
> is a visual feature on the window itself, it is easy to test. Nonetheless,
> making sure parsing the “display-override” mode and associated values
> correctly is desired, which should be incorporated into the application tab
> of devtools, where all the other manifest warnings are displayed.
>
>
> Is this feature fully tested by web-platform-tests
>

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

LGTM2 to catch up here

(Apparently we have 2 intent emails for this..)

On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:

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

Re: [blink-dev] Intent to Ship: New Canvas 2D API

Thanks for modernizing Canvas! :)

On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski 
wrote:

>
> *Contact emails*aaro...@chromium.org, fs...@chromium.org
>
> *Explainer*
> https://github.com/fserb/canvas2d
> https://youtu.be/dfOKFSDG7IM
>

Great video, thanks for that!!


>
> *Specification*
> Context Lost Event
> 
> Context Restored Event
> 
> Will Read Frequently
> 
> New Text Modifiers
> 
> Reset
> 
>

Were the concerns WebKit raised on the issue
 addressed? Can you expand on
that front?


> RoundRect
>
> Conic
> Gradient
>
> 
> Filters  (still in progress)
>

Is the hold-up on the Filters PR editorial or something more fundamental?
I noticed Mozilla's opposition on their position. Is that something that
has changed since?

Are these features individually detectable? Do we have reasonable developer
advice on how we want folks to use those features with backwards
compat/fallbacks in mind?


>
> *Summary*
> Updated functionality for the Canvas2D API. Adds seven new
> features/functions to CanvasRenderingContext2D:
>
> - "ContextLost" and "ContextRestored" events
> - "willReadFrequently" option for canvases where lots of readback is
> expected
> - More CSS text modifier support
> - A reset function
> - A roundRect draw primitive
> - Conic gradients
> - Better support for SVG filters
>
> https://github.com/fserb/canvas2d
>
> *Blink component*
> Blink>Canvas
> 
>
>
> *TAG review status*Resolution: satisfied
> 
>
> *Risks*
> Security and privacy team expressed concerns with ContextLost and
> ContextRestored events during the intent to implement phase. These concerns
> were addressed by re-designing the event to not launch simultaneously
> across different contexts.
>
> *Interoperability and Compatibility*
> Gecko: In development (https://github.com/whatwg/html/issues/5431
> )
> Already implemented conic gradient. Okay with willReadFrequently,
> transforms and reset.
>
> WebKit: Positive (https://github.com/whatwg/html/issues/5619). Positive
> signal on text modifiers, round rect and color input.
>
> Web developers: Positive (https://www.youtube.com/watch?v=dfOKFSDG7IM)
> CDN talk in December was received very positively.
>
> *Signals*
> Gecko: https://github.com/mozilla/standards-positions/issues/519
> WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html
>
> *Is this feature fully tested by* web-platform-tests
> 
> ?
> Yes
>
> *Flag name*
> #new-canvas-2d-api
>
> *Requires code in //chrome?*
> False
>
> *Tracking bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1201359
>
> *Estimated milestones*
> OriginTrial desktop first
> 95
>
> OriginTrial desktop last
> 98
>
> OriginTrial android first
> 95
>
> OriginTrial android last
> 98
>
> *Link to entry on the Chrome Platform Status*
> https://www.chromestatus.com/feature/6051647656558592
>
> 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/eb702e7e-88d6-4b6f-b419-6051511689f1n%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/CAL5BFfX1XQD%3DnqLkc_1X1-aQE-%2Bsu_kt5fi30oDN6AEGfp_hFg%40mail.gmail.com.

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

LGTM1 to catch up with other implementations on this.


On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla  wrote:

> Contact emails
>
> ssin...@igalia.com,
>
> fw...@chromium.org
>
> Explainer:
>
> The securitypolicyviolation event is already implemented in all browsers,
> one can find document on MDN(
> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation,
>
> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event).
> The securitypolicyviolation event is dispatched when there is a Content
> Security Policy 
> violation. Typically, the JS code of the web component will listen to
> securitypolicyviolation events and react with necessary updates.
>
> One could just use addEventListener, but for convenience and consistency
> with other events (e.g. slotchange) it makes sense to add a IDL
> onsecuritypolicyviolation attribute.We recently shipped onslotchange idl
> attribute as well. See -
> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ
>
> Developers are used to use EventTarget.onload = ... and  onload="..."> , but if this does not work for all events, it will be
> surprising.
>
> Currently, the way to listen an event is:
>
> target.addEventListener("securitypolicyviolation", mylistener);
>
> After this addition an alternative attribute-based form will be
>
> availlable for the developers
>
> element
>
> 
> Doc Link(s):
>
> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
> 
>
> - https://github.com/whatwg/html/pull/2651
> 
>
> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
> 
>
> Specification
>
> https://html.spec.whatwg.org
>
> Summary
>
> The securitypolicyviolation event is fired when a Content Security Policy
> is violated.One can listen to that event via the
> EventTarget.addEventListener() API. The goal is now to expose the
> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
> interface, so that one can register a listener by attaching this attribute
> to target elements.
>
> Blink component
>
> Blink>DOM
>
> Motivation
>
> The securitypolicyviolation event is fired when a Content Security Policy
> is violated.
>
> One can naturally listen to that event via the
>
> EventTarget.addEventListener() API. However, web developers are also
>
> familiar with the alternative attribute-based form (e.g.
>
> element.addEventListener("securitypolicyviolation
>
> ", ...) Vs on )
>
> which is sometimes convenient for quick testing. For consistency with
>
> other events, an attribute onsecuritypolicyviolation is thus added.
>
> TAG review
>
> TAG review status
>
> This is  asmall change to an existing spec implemented in browsers and
> discussed at WHATWG - https://github.com/whatwg/html/pull/2651,
> https://github.com/w3c/webappsec-csp/issues/184
>

Agree that a TAG review is not needed in this case.


>
> Risks
>
> Interoperability and Compatibility
>
> Gecko:
>
> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>
> WebKit:
>
> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
> Web developers:
>
> N/A
>
> Debuggability
>
> No DevTools changes are required, treated like any other event/attribute.
> Is this feature fully tested by web-platform-tests?
>
> Yes
> Web Platform Tests:
>
>1.
>
>w3c/web-platform-tests/dom/idlharness.window.html
>2.
>
>
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>3.
>
>
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>4.
>
>
>
> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
> Patch:
>
> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>
> Estimated milestones
>
> -
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/features/5639484386312192
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77047bf5-496b-41cc-9cf8-bcc0fcf9562bn%40chromium.org
> 
> .
>

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

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

On Thu, Oct 21, 2021 at 7:01 AM Will Cassella  wrote:

> Thanks for the feedback! I've updated that section:
>
> Debuggability
>
> Styles with these media queries can be viewed and edited in the devtools
> frontend, albeit without proper highlighting. I've created pull requests on
> the relevant libraries used in the devtools frontend to enable this.
> https://github.com/stylelint/stylelint/pull/5613
> https://github.com/codemirror/CodeMirror/pull/6803
>
> On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
>
>> On Wed, Oct 20, 2021 at 5:44 PM Will Cassella 
>> wrote:
>>
>>> Contact emailscas...@chromium.org, chcunning...@chromium.org,
>>> videostack-...@chromium.org
>>>
>>> Explainer
>>> Adds MediaQueries for detecting HDR vs HDR displays
>>> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
>>> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>>>
>>> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>>>
>>> Summary
>>>
>>> Adds media queries to CSS which allow a page to detect the current
>>> display device’s support for HDR. This feature adds two new CSS media
>>> queries: 'dynamic-range' and 'video-dynamic-range', both of which may be
>>> one of 'standard' or 'high'. Chrome will resolve these queries according to
>>> the capabilities of the display device the browser window is currently
>>> positioned on, allowing pages to toggle CSS rules accordingly or respond in
>>> Javascript via 'window.matchMedia()'.
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> Motivation
>>>
>>> As HDR-supported displays become more common, web developers need ways
>>> to enable HDR content on their web pages without compromising the
>>> experience for users of non-HDR displays, or mixed-HDR multi-display
>>> setups. CSS already provides the 'media query' concept for toggling rules
>>> based on display device characteristics, and this feature extends that set
>>> of queries to enable detecting HDR support on the current display device.
>>>
>>>
>>> Initial public proposal
>>>
>>> TAG reviewNot Filed. This is an incremental change to CSS Media
>>> Queries, already adopted by CSS WG.
>>>
>>
I agree a TAG review is not needed for the `dynamic-range` MQ, as it's
shipped in Safari and adopted by the CSSWG.
The video variant however doesn't meet that criteria. Was the concept of
`video-*` MQs discussed with the TAG? Are there other `video-*` MQs that
are already shipped?


>
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> Gecko: Worth prototyping (
>>> https://github.com/mozilla/standards-positions/issues/584)
>>>
>>> WebKit: Shipped/Shipping (
>>> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
>>> Partially implemented - `video-dynamic-range` not yet supported
>>>
>>> Web developers: Positive (
>>> https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935)
>>> Feature designed with the help of Netflix.
>>>
>>>
>>> Debuggability
>>>
>>> No specific DevTools support
>>>
>>
>> Please follow https://goo.gle/devtools-checklist and elaborate on this a
>> little bit. Per the guide, we need to ensure DevTools supports basic
>> editing of this new media query. It looks like this works out of the box in
>> Canary.
>>
>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>> https://wpt.fyi/results/css/mediaqueries/dynamic-range.html
>>>
>>> Flag nameCSSDynamicRangeMediaQueries
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1224711
>>>
>>> Estimated milestones97
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5680926106320896
>>>
>>> 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/CA%2BF%3DP4hQtag7Ja_7HF4jRHbuC8h5-_0TzjoJvVEMHmrUeZYW9g%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/6655cbcd-90a1-4b34-a332-5adeada4b53fn%40chromium.org
>

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