[blink-dev] Intent to Prototype: CSS Color Level 4

['Christopher Cameron' via blink-dev]

Hello blink-dev!

Chromium currently allows wide color gamut colors to be rendered via
images, video, and canvases. Missing from this party are wide color gamut
CSS colors. Rumblings  have already begun deep in
the bowels of the Chromium paint and compositing systems, which will
prepare the ground for this. Before they spill over to blink, here is our
intent to prototype CSS Color Level 4!

Contact emailsccame...@chromium.org, fs...@chromium.org,
aaro...@chromium.org, juanm...@chromium.org

Specificationhttps://www.w3.org/TR/css-color-4

Summary

CSS Color Level 4 allows specifying CSS colors that are not limited to the
sRGB color gamut.

Blink componentBlink>Compositing


Motivation

CSS Color Level 4 allows specifying colors outside of the sRGB color gamut.
Images, videos, and canvases (2D and WebGL) can currently specify such
colors, but CSS is limited to the sRGB color gamut.

TAG review statusNot started

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: Shipped/Shipping (
https://webkit.org/blog/10042/wide-gamut-color-in-css-with-display-p3)

*Web developers*: No signals

WebView application risks

None.



Debuggability

This feature will need integration with DevTools (the form that that takes
will need to be determined).


Is this feature fully tested by web-platform-tests

?Many tests are present here
.

Flag nameNone yet.

Requires code in //chrome?No.

Tracking bughttps://crbug.com/1333988

Estimated milestones

No milestones specified


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

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

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

[David Baron]

Despite considerably more delay (in getting the dependencies for compositor
animation landed) than I was expecting when I posted the intent to ship...
this is now on track to ship in Chrome 104.  (And I've updated chromestatus
accordingly.)

-David

On Wed, Oct 27, 2021 at 1:26 PM Joe Medley  wrote:

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

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

[Xianzhu Wang]

On Mon, Jun 6, 2022 at 3:52 PM Weizhong Xia  wrote:

> Xianzhu, yes 'baselines' is the name we agreed on previously. The reason I
> later changed back to use 'platform' is because that will make the CL
> smaller, and make it easier for gerrit to handle it. We can make one round
> rename when everything is stabilized. (I left you a message when you are
> OOO. I am not sure if that message lived long enough for you to catch it.)
>

I caught the message. I guessed that the name 'platform' might be one of
the reasons for the surprise to blink developers after the change, and the
name 'baselines' might make the change easier to explain :)

On Mon, Jun 6, 2022 at 3:52 PM Domenic Denicola 
wrote:

> I'm not sure I understand this logic. -expected.txt files are just
> more-convenient, more in-your-face versions of TestExpectations files.
> Surely you're not suggesting we get rid of TestExpectations files?
>

Sorry, "-expected.txt ... should be ... eventually be removed" in my
previous email was not clear. I meant for each individual -expected.txt we
should eventually remove it because we should fix the failure. The same
logic applies to TestExpectations. At any time we may allow a certain
number of failures but we should keep the number as small as possible.

I think we should prefer TestExpectations to -expected.txt for WPT tests
because the entries in TestExpectations have associated bugs which track
the fixing process, unless we find a better way to track the fixing of the
failures in -expected.txt. -expected.txt files do have their values, e.g.
for partially-passing tests we can discover regressions and progressions of
individual sub tests, but they should be rare.

I think separating -expected.txt from the tests has the following benefits:
- It makes it clear to blink developers that the files are not a part of
WPT.
- It simplifies the WPT export/import process and others by reducing
blink-specific files under external/wpt.

It does make it more difficult to find -expected.txt, but we already have
the similar well-known logic for platform-specific baselines. Though
platform-specific baselines are rare, ignoring a platform baseline can
still cause surprises.

I think we can improve the test result viewer

- to better show -expected.txt for passing tests
- to show information about tests without actually running the tests
WDYT?


>
> On Mon, Jun 6, 2022 at 6:30 PM Xianzhu Wang 
> wrote:
>
>> I think we first need to answer a question: Why do we need *-expected.txt
>> for WPT tests?
>>
>> Upstream WPT doesn't have *-expected.txt. *-expected.txt is a
>> blink-specific thing to allow some failing WPT tests to pass on blink with
>> temporarily allowed failures. If a test has -expected.txt, it means Chrome
>> behaves differently than the standard web platform behavior (or the test
>> itself is wrong). The files are sometimes harmful because they hide
>> failures and web platform incompatibilities (e.g.
>> ). So I think -expected.txt files for WPT tests
>> should be rare and eventually be removed. An -expected.txt should not be
>> treated as a part of the test itself because a) it doesn't exist in
>> upstream WPT and 2) it doesn't describe the standard expected behavior,
>> thus isn't necessarily placed besides the test.
>>
>> The directory name 'platform' may be misleading. 'baselines' may be a
>> better name (but we should not rename until we decide what to do for
>> generic baselines). For WPT tests, 'failures' is perhaps an even better
>> name.
>>
>> On Friday, June 3, 2022 at 6:55:49 AM UTC-7 Dominic Farolino wrote:
>>
>>> For the long term, we can definitely move this back once we have
 separate legacy tests and wpt into different folders. I can also reach out
 to you guys to better understand your needs.

 For the folders Dom mentioned, I can check to see if any of that can be
 removed. I understand the README is needed for virtual test suites.

>>>
>>> Can you define "long term" here? Is there a timeline? I was really
>>> hoping that we'd go back to how things were almost immediately. Still the
>>> need for the delay does not quite make sense to me, and I'm really
>>> hoping that for Blink developer experience we can revert this back to the
>>> previous setup ASAP.
>>>
>>> Under "web_tests/virtual" we have baselines for wpt and pure virtual
 legacy tests, we can list the folders under "virtual/prefix" for each
 virtual test suite, which will make the dependency very large(yes), and we
 need make such change each time when we add new virtual suites. I don't
 think this is something blink devs want to do.

>>>
>>> I'm sorry, but like Domenic I am not sure what to make of much of this.
>>> What I do know is that Blink developers also don't want the current WPT
>>> writing experience where expectation files are positioned f

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

[Daisuke Enomoto]

Hi Joe,

This feature is shipping in 104. I updated the chromestatus entry.

Thanks for pinging.

On Tue, Jun 7, 2022 at 12:18 AM Joe Medley  wrote:

> Is this shipping in 105? Please add that to the status entry.
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Jun 1, 2022 at 2:03 AM Hayato Ito  wrote:
>
>> Thanks all, for your support and the LGTMs.
>>
>> I appreciate the API owners, the Mozilla folks and the others, who
>> reviewed this feature carefully and gave us the advice to make this feature
>> interoperable and be an important step on future improvements on the Web
>> Platform.
>>
>> I'll continue to invest in standards. Thanks!
>>
>> On Wed, Jun 1, 2022 at 2:11 PM Yoav Weiss  wrote:
>>
>>> LGTM3
>>>
>>> I was similarly convinced by the team's efforts and by various folks
>>> chiming in that this has a good chance of reaching eventual interop on its
>>> own. The use cases this tackles span origin isolation, delivery and
>>> performance (despite the lack of cache awareness in the current version),
>>> and I'm hopeful that this would be an important stepping stone on which
>>> future improvements will be built. Thanks!!
>>>
>>> On Wed, Jun 1, 2022 at 4:15 AM Chris Harrelson 
>>> wrote:
>>>
 LGTM2

 Web bundles team: thank you for your thoroughness in responding to
 concerns raised in the TAG review, Mozilla standards position, and various
 offline conversations. I also appreciate those who weighed in on the thread
 with additional sites that would use this feature, and the multiple use
 cases mentioned.

 At first, I was concerned about the risk of not achieving eventual
 interoperability, because of the limited data from experimenting sites and
 mixed or possibly negative signals from other browser vendors. The
 additional data mentioned above, on top of the existing ads-related use
 case from the original intent, and coupled with my belief that the team
 will continue to invest in standards in this area, leads me to conclude
 that this feature is worth shipping now.


 On Wed, May 25, 2022 at 8:37 AM Alex Russell 
 wrote:

> There are high-scale operational challenges to distributing content
> optimally in many scenarios (e.g., Store packaged first-run or
> out-of-the-box-experiences) that need more than what Service Workers alone
> can provide. We are positive about this technology because it can help
> address those problems and open up new product opportunities (that we
> cannot say more about).
>
> Best Regards,
>
> Alex
>
> On Tuesday, May 24, 2022 at 10:26:28 AM UTC-7 bema...@microsoft.com
> wrote:
>
>> >>  You could have used a service worker and cache things in order to
>> get the same thing, combined with progressive web applications for
>> installability.
>>
>> This is true, but I think ergonomics of an encapsulated
>> page/application make it easier to reason about for very large
>> applications. Maintaining the service worker and the cache at scale can
>> become a barrier to entry for some developers and applications.
>>
>> On Tuesday, May 24, 2022 at 10:12:33 AM UTC-7 PhistucK wrote:
>>
>>> Not that I am against, but does this unlock previously locked
>>> opportunities in the specific examples you just mentioned?
>>> You could have used a service worker and cache things in order to
>>> get the same thing, combined with progressive web applications for
>>> installability.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Tue, May 24, 2022 at 4:35 PM 'Ben Mathwig' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Microsoft has a strong interest in seeing this feature ship. We
 believe that sub-resource bundling is opening the door to a new way of
 shipping and delivering offline web applications, changing the 
 traditional
 definition of “web application”.

 Here are some ways Microsoft products can take advantage of this:

 *PowerApps*

 Microsoft PowerApps allows a developer to author an application and
 deploy to iOS, Android, and the web. The first two platforms allow
 applications to be deployed and used when the device is offline, but 
 the
 latter is currently not “installable” on the device. Web bundling could
 unlock the capability for a web application to be “installed” on a 
 device
 to operate offline.

 *Office Online*

 Office productivity web applications are a perfect example of
 applications that could benefit from a packaged bundle of application
 resources. Combined with local storage APIs, this could help developers
 reach communities that have little to no n

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

[Domenic Denicola]

I'm not sure I understand this logic. -expected.txt files are just
more-convenient, more in-your-face versions of TestExpectations files.
Surely you're not suggesting we get rid of TestExpectations files?

On Mon, Jun 6, 2022 at 6:30 PM Xianzhu Wang 
wrote:

> I think we first need to answer a question: Why do we need *-expected.txt
> for WPT tests?
>
> Upstream WPT doesn't have *-expected.txt. *-expected.txt is a
> blink-specific thing to allow some failing WPT tests to pass on blink with
> temporarily allowed failures. If a test has -expected.txt, it means Chrome
> behaves differently than the standard web platform behavior (or the test
> itself is wrong). The files are sometimes harmful because they hide
> failures and web platform incompatibilities (e.g.
> ). So I think -expected.txt files for WPT tests
> should be rare and eventually be removed. An -expected.txt should not be
> treated as a part of the test itself because a) it doesn't exist in
> upstream WPT and 2) it doesn't describe the standard expected behavior,
> thus isn't necessarily placed besides the test.
>
> The directory name 'platform' may be misleading. 'baselines' may be a
> better name (but we should not rename until we decide what to do for
> generic baselines). For WPT tests, 'failures' is perhaps an even better
> name.
>
> On Friday, June 3, 2022 at 6:55:49 AM UTC-7 Dominic Farolino wrote:
>
>> For the long term, we can definitely move this back once we have separate
>>> legacy tests and wpt into different folders. I can also reach out to you
>>> guys to better understand your needs.
>>>
>>> For the folders Dom mentioned, I can check to see if any of that can be
>>> removed. I understand the README is needed for virtual test suites.
>>>
>>
>> Can you define "long term" here? Is there a timeline? I was really hoping
>> that we'd go back to how things were almost immediately. Still the need for
>> the delay does not quite make sense to me, and I'm really hoping that for
>> Blink developer experience we can revert this back to the previous setup
>> ASAP.
>>
>> Under "web_tests/virtual" we have baselines for wpt and pure virtual
>>> legacy tests, we can list the folders under "virtual/prefix" for each
>>> virtual test suite, which will make the dependency very large(yes), and we
>>> need make such change each time when we add new virtual suites. I don't
>>> think this is something blink devs want to do.
>>>
>>
>> I'm sorry, but like Domenic I am not sure what to make of much of this.
>> What I do know is that Blink developers also don't want the current WPT
>> writing experience where expectation files are positioned far away from the
>> source test. I think this experience matters a lot.
>>
>> On Thu, Jun 2, 2022 at 4:25 PM Weizhong Xia  wrote:
>>
>>> Previously you don't need to specify anything in BUILD.gn is because we
>>> are downloading the whole "web_tests" folder. Now we want to run legacy
>>> tests and wpt in different steps. Under "web_tests/virtual" we have
>>> baselines for wpt and pure virtual legacy tests, we can list the folders
>>> under "virtual/prefix" for each virtual test suite, which will make the
>>> dependency very large(yes), and we need make such change each time when we
>>> add new virtual suites. I don't think this is something blink devs want to
>>> do.
>>>
>>> The discussion is at the beginning of the crbug. So pls scroll back to
>>> #c1, and read from there.
>>>
>>> thanks, Weizhong
>>>
>>> On Thu, Jun 2, 2022 at 12:29 PM Domenic Denicola 
>>> wrote:
>>>


 On Thu, Jun 2, 2022 at 3:21 PM Weizhong Xia 
 wrote:

> Folks
>
> I'm sorry to see this has caused inconvenience, and sorry for being
> late in response to this, due to the same reason Dom had.
>

 Thanks for responding and listening to our concerns!


>
> The reason to move baselines to one central place at this point is to
> make it possible to specify dependency in BUILD.gn.
>

 I don't quite understand this. I've had to work with WPTs and WPT
 expectations my entire time working on Chromium. I've never had to "specify
 dependency in BUILD.gn"; I don't really know what that means. I'd love to
 hear more (or be referred to a doc explaining the issue), so that I
 understand why we're making the sacrifice we're making. (The linked bug
 isn't very understandable for me, unfortunately. I can't even understand
 enough to find the part you mentioned where you discussed different
 approaches.)

 I'm also unsure how the decision was weighed. Is the population of
 people specifying dependency in BUILD.gn very large, so that their needs
 are outweighing those of the Chromium developers working with web platform
 tests?


> This is part of the work to use upstream wptrunner to run wpt tests.
> In crbug/1299834  we have tried to discuss
> some different approaches. I

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

['Weizhong Xia' via blink-dev]

Xianzhu, yes 'baselines' is the name we agreed on previously. The reason I
later changed back to use 'platform' is because that will make the CL
smaller, and make it easier for gerrit to handle it. We can make one round
rename when everything is stabilized. (I left you a message when you are
OOO. I am not sure if that message lived long enough for you to catch it.)

thanks, Weizhong

On Mon, Jun 6, 2022 at 3:30 PM Xianzhu Wang 
wrote:

> I think we first need to answer a question: Why do we need *-expected.txt
> for WPT tests?
>
> Upstream WPT doesn't have *-expected.txt. *-expected.txt is a
> blink-specific thing to allow some failing WPT tests to pass on blink with
> temporarily allowed failures. If a test has -expected.txt, it means Chrome
> behaves differently than the standard web platform behavior (or the test
> itself is wrong). The files are sometimes harmful because they hide
> failures and web platform incompatibilities (e.g.
> ). So I think -expected.txt files for WPT tests
> should be rare and eventually be removed. An -expected.txt should not be
> treated as a part of the test itself because a) it doesn't exist in
> upstream WPT and 2) it doesn't describe the standard expected behavior,
> thus isn't necessarily placed besides the test.
>
> The directory name 'platform' may be misleading. 'baselines' may be a
> better name (but we should not rename until we decide what to do for
> generic baselines). For WPT tests, 'failures' is perhaps an even better
> name.
>
> On Friday, June 3, 2022 at 6:55:49 AM UTC-7 Dominic Farolino wrote:
>
>> For the long term, we can definitely move this back once we have separate
>>> legacy tests and wpt into different folders. I can also reach out to you
>>> guys to better understand your needs.
>>>
>>> For the folders Dom mentioned, I can check to see if any of that can be
>>> removed. I understand the README is needed for virtual test suites.
>>>
>>
>> Can you define "long term" here? Is there a timeline? I was really hoping
>> that we'd go back to how things were almost immediately. Still the need for
>> the delay does not quite make sense to me, and I'm really hoping that for
>> Blink developer experience we can revert this back to the previous setup
>> ASAP.
>>
>> Under "web_tests/virtual" we have baselines for wpt and pure virtual
>>> legacy tests, we can list the folders under "virtual/prefix" for each
>>> virtual test suite, which will make the dependency very large(yes), and we
>>> need make such change each time when we add new virtual suites. I don't
>>> think this is something blink devs want to do.
>>>
>>
>> I'm sorry, but like Domenic I am not sure what to make of much of this.
>> What I do know is that Blink developers also don't want the current WPT
>> writing experience where expectation files are positioned far away from the
>> source test. I think this experience matters a lot.
>>
>> On Thu, Jun 2, 2022 at 4:25 PM Weizhong Xia  wrote:
>>
>>> Previously you don't need to specify anything in BUILD.gn is because we
>>> are downloading the whole "web_tests" folder. Now we want to run legacy
>>> tests and wpt in different steps. Under "web_tests/virtual" we have
>>> baselines for wpt and pure virtual legacy tests, we can list the folders
>>> under "virtual/prefix" for each virtual test suite, which will make the
>>> dependency very large(yes), and we need make such change each time when we
>>> add new virtual suites. I don't think this is something blink devs want to
>>> do.
>>>
>>> The discussion is at the beginning of the crbug. So pls scroll back to
>>> #c1, and read from there.
>>>
>>> thanks, Weizhong
>>>
>>> On Thu, Jun 2, 2022 at 12:29 PM Domenic Denicola 
>>> wrote:
>>>


 On Thu, Jun 2, 2022 at 3:21 PM Weizhong Xia 
 wrote:

> Folks
>
> I'm sorry to see this has caused inconvenience, and sorry for being
> late in response to this, due to the same reason Dom had.
>

 Thanks for responding and listening to our concerns!


>
> The reason to move baselines to one central place at this point is to
> make it possible to specify dependency in BUILD.gn.
>

 I don't quite understand this. I've had to work with WPTs and WPT
 expectations my entire time working on Chromium. I've never had to "specify
 dependency in BUILD.gn"; I don't really know what that means. I'd love to
 hear more (or be referred to a doc explaining the issue), so that I
 understand why we're making the sacrifice we're making. (The linked bug
 isn't very understandable for me, unfortunately. I can't even understand
 enough to find the part you mentioned where you discussed different
 approaches.)

 I'm also unsure how the decision was weighed. Is the population of
 people specifying dependency in BUILD.gn very large, so that their needs
 are outweighing those of the Chromium developers working with web platform
 tests?

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

[Xianzhu Wang]

I think we first need to answer a question: Why do we need *-expected.txt 
for WPT tests?

Upstream WPT doesn't have *-expected.txt. *-expected.txt is a 
blink-specific thing to allow some failing WPT tests to pass on blink with 
temporarily allowed failures. If a test has -expected.txt, it means Chrome 
behaves differently than the standard web platform behavior (or the test 
itself is wrong). The files are sometimes harmful because they hide 
failures and web platform incompatibilities (e.g. ). 
So I think -expected.txt files for WPT tests should be rare and eventually 
be removed. An -expected.txt should not be treated as a part of the test 
itself because a) it doesn't exist in upstream WPT and 2) it doesn't 
describe the standard expected behavior, thus isn't necessarily placed 
besides the test.

The directory name 'platform' may be misleading. 'baselines' may be a 
better name (but we should not rename until we decide what to do for 
generic baselines). For WPT tests, 'failures' is perhaps an even better 
name.

On Friday, June 3, 2022 at 6:55:49 AM UTC-7 Dominic Farolino wrote:

> For the long term, we can definitely move this back once we have separate 
>> legacy tests and wpt into different folders. I can also reach out to you 
>> guys to better understand your needs.
>>
>> For the folders Dom mentioned, I can check to see if any of that can be 
>> removed. I understand the README is needed for virtual test suites.
>>
>
> Can you define "long term" here? Is there a timeline? I was really hoping 
> that we'd go back to how things were almost immediately. Still the need for 
> the delay does not quite make sense to me, and I'm really hoping that for 
> Blink developer experience we can revert this back to the previous setup 
> ASAP.
>
> Under "web_tests/virtual" we have baselines for wpt and pure virtual 
>> legacy tests, we can list the folders under "virtual/prefix" for each 
>> virtual test suite, which will make the dependency very large(yes), and we 
>> need make such change each time when we add new virtual suites. I don't 
>> think this is something blink devs want to do.
>>
>
> I'm sorry, but like Domenic I am not sure what to make of much of this. 
> What I do know is that Blink developers also don't want the current WPT 
> writing experience where expectation files are positioned far away from the 
> source test. I think this experience matters a lot.
>
> On Thu, Jun 2, 2022 at 4:25 PM Weizhong Xia  wrote:
>
>> Previously you don't need to specify anything in BUILD.gn is because we 
>> are downloading the whole "web_tests" folder. Now we want to run legacy 
>> tests and wpt in different steps. Under "web_tests/virtual" we have 
>> baselines for wpt and pure virtual legacy tests, we can list the folders 
>> under "virtual/prefix" for each virtual test suite, which will make the 
>> dependency very large(yes), and we need make such change each time when we 
>> add new virtual suites. I don't think this is something blink devs want to 
>> do.
>>
>> The discussion is at the beginning of the crbug. So pls scroll back to 
>> #c1, and read from there.
>>
>> thanks, Weizhong
>>
>> On Thu, Jun 2, 2022 at 12:29 PM Domenic Denicola  
>> wrote:
>>
>>>
>>>
>>> On Thu, Jun 2, 2022 at 3:21 PM Weizhong Xia  wrote:
>>>
 Folks

 I'm sorry to see this has caused inconvenience, and sorry for being 
 late in response to this, due to the same reason Dom had.

>>>
>>> Thanks for responding and listening to our concerns!
>>>  
>>>

 The reason to move baselines to one central place at this point is to 
 make it possible to specify dependency in BUILD.gn.

>>>
>>> I don't quite understand this. I've had to work with WPTs and WPT 
>>> expectations my entire time working on Chromium. I've never had to "specify 
>>> dependency in BUILD.gn"; I don't really know what that means. I'd love to 
>>> hear more (or be referred to a doc explaining the issue), so that I 
>>> understand why we're making the sacrifice we're making. (The linked bug 
>>> isn't very understandable for me, unfortunately. I can't even understand 
>>> enough to find the part you mentioned where you discussed different 
>>> approaches.)
>>>
>>> I'm also unsure how the decision was weighed. Is the population of 
>>> people specifying dependency in BUILD.gn very large, so that their needs 
>>> are outweighing those of the Chromium developers working with web platform 
>>> tests?
>>>  
>>>
 This is part of the work to use upstream wptrunner to run wpt tests. In 
 crbug/1299834  we have tried to discuss 
 some different approaches. I would say this is the least disruptive way. 
 For blink engprod, I think to make blink devs happy is our top priority.

 For the long term, we can definitely move this back once we have 
 separate legacy tests and wpt into different folders. I can also reach out 
 to you guys to better understand your needs.

[blink-dev] Where should we put generic baselines for web tests?

[weizhong via blink-dev]

I've invited you to fill out the following form:
Where should we put generic baselines for web tests?

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSec2jk2mSAGNfyI6Onbx3_otPPrgLh5zTkJ_sdbO4PfamuZeg/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link

I've invited you to fill out a form:

Google Forms: Create and analyze surveys.

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

[blink-dev] Re: Intent to Prototype: High Dynamic Range Support for HTMLCanvasElement

['Christopher Cameron' via blink-dev]

Re-sending this, since more patches are likely to land soon for this.

On Fri, Nov 26, 2021 at 9:05 PM Christopher Cameron 
wrote:

> Contact emailsccame...@chromium.org
>
> Proposal
> https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md
>
>
> Summary
>
> Add support for displaying HDR content in an HTMLCanvasElement. Add new
> HDR color spaces to PredefinedColorSpace. Add functionality to
> HTMLCanvasElement to enable display of HDR content. And functionality to
> ScreenAdvanced to query HDR capabilities of displays.
>
>
> Blink componentBlink>Canvas
> 
>
> Motivation
>
> High dynamic range content is already available on the web in the form of
> HDR video and image formats. Most operating systems support high dynamic
> range graphics through native APIs. This proposal adds HDR support to the
> web.
>
>
> This proposal is a result of discussions in the ColorWeb group. There is a
> desire among all participants to be able to test the proposal "hands-on"
> before rendering further judgment, especially in deciding some of the
> details regarding default color space conversion math.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1274220
>
> Estimated milestones
>
> No milestones specified
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5703719636172800
>
>

-- 
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/CAGnfxj_%3DcvBP8RvEmJnyeSWE%2BYA4pfD_G3AJ5jsYePOJxK7dHw%40mail.gmail.com.

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

['Joe Medley' via blink-dev]

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


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

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

 Best Regards,

 Alex

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

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

Re: [blink-dev] Intent to Experiment: Secure Payment Confirmation - Opt-Out Support

[Mike Taylor]

LGTM to experiment from M104 to M106.

On 6/6/22 11:07 AM, Rouslan Solomakhin wrote:

*Contact emails*
smcgr...@chromium.org, rous...@chromium.org

*Explainer*
https://github.com/w3c/secure-payment-confirmation/issues/172

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

*Summary*
Adds an 'opt-out' flow to Secure Payment Confirmation. When the 
(optional) input flag is set, the SPC UXes will render an 'opt-out' 
link of some sort that the user can interact with to indicate to the 
relying party that they wish to be opted out.


*Blink component*
Blink>Payments

*TAG review status*
Not applicable

*Risks
*

*Interoperability and Compatibility
*/Gecko/: No signal
/WebKit/: No signal
/Web developers/: Positive. The feature is proposed by web
developers
.

*
Ergonomics
*SPC feature is a combination of WebAuthn and PaymentRequest APIs.
*
Activation
*To take advantage of this feature, developers have to specify a
new optional API parameter `showOptOut: true`.

*

Debuggability*
Normal devtools javascript debugging capabilities should suffice.

*Will this feature be supported on all six Blink platforms (Windows, 
Mac, Linux, Chrome OS, Android, and Android WebView)?*
No. SPC is currently launched only on Mac and Windows. This opt-out 
feature also exists only on Mac and Windows.


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

*Flag name*
--enable-blink-features=SecurePaymentConfirmationOptOut

*Requires code in //chrome?*
True

*Tracking bug*
https://crbug.com/1325854

*Launch bug*
https://crbug.com/1329512

*Estimated milestones*
OriginTrial desktop last106
OriginTrial desktop first104
DevTrial on desktop104

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

*Links to previous Intent discussions*
Intent to prototype 
.


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/CAMMzaWHTs2nBYT7bFKEd%2BtLvFvyzrunzq7bD6%3DXJtwWpb8J2%2BA%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/310026e7-c60d-9f79-561e-99a60a788fac%40chromium.org.

[blink-dev] Intent to Experiment: Secure Payment Confirmation - Opt-Out Support

[Rouslan Solomakhin]

*Contact emails*
smcgr...@chromium.org, rous...@chromium.org

*Explainer*
https://github.com/w3c/secure-payment-confirmation/issues/172

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

*Summary*
Adds an 'opt-out' flow to Secure Payment Confirmation. When the (optional)
input flag is set, the SPC UXes will render an 'opt-out' link of some sort
that the user can interact with to indicate to the relying party that they
wish to be opted out.

*Blink component*
Blink>Payments

*TAG review status*
Not applicable


*Risks*


*Interoperability and Compatibility**Gecko*: No signal
*WebKit*: No signal
*Web developers*: Positive. The feature is proposed by web developers
.



*Ergonomics*SPC feature is a combination of WebAuthn and PaymentRequest
APIs.


*Activation*To take advantage of this feature, developers have to specify a
new optional API parameter `showOptOut: true`.


*Debuggability*
Normal devtools javascript debugging capabilities should suffice.

*Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?*
No. SPC is currently launched only on Mac and Windows. This opt-out feature
also exists only on Mac and Windows.

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

*Flag name*
--enable-blink-features=SecurePaymentConfirmationOptOut

*Requires code in //chrome?*
True

*Tracking bug*
https://crbug.com/1325854

*Launch bug*
https://crbug.com/1329512

*Estimated milestones*
OriginTrial desktop last106
OriginTrial desktop first104
DevTrial on desktop104

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

*Links to previous Intent discussions*
Intent to prototype

.

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/CAMMzaWHTs2nBYT7bFKEd%2BtLvFvyzrunzq7bD6%3DXJtwWpb8J2%2BA%40mail.gmail.com.