Re: [blink-dev] Intent to Experiment: fetchLater API

[Daisuke Enomoto]

Yoav,

What milestones do you want to run the experiment in?

We plan to run the dev trial in 120. When we request an OT, would you
recommend us to send another I2E generated on chromestatus entry?

Also, can you kick off the other review checks in your chromestatus entry?

Yes, we have kicked off Security and Privacy reviews.


On Thu, Nov 16, 2023 at 12:42 AM Yoav Weiss  wrote:

> Also, can you kick off the other review checks in your chromestatus entry?
>
> On Wednesday, November 15, 2023 at 10:40:08 AM UTC+1 Yoav Weiss wrote:
>
>> What milestones do you want to run the experiment in?
>>
>> On Wed, Nov 15, 2023 at 8:10 AM Jesugbamigbe Daniel Fadipe <
>> jdanielfad...@gmail.com> wrote:
>>
>>>
>>> Many thanks,
>>>
>>> J Daniel Fadipe
>>> 07412666868
>>>
>>>
>>> On Wed, 15 Nov 2023 at 08:09, Ming-Ying Chung  wrote:
>>>
>> Contact emailsm...@chromium.org, denom...@chromium.org,
 pending-beacon-experim...@google.com

 Explainer
 https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md

 Specificationhttps://whatpr.org/fetch/1647/9ca4bda...37a66c9.html

 Design docs
 https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md

 https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit#heading=h.ms1oipx914vf

 Summary

 fetchLater() is a JavaScript API to request a deferred fetch. Once
 called, the request is queued by the browser, and will be invoked in one of
 the following scenarios: • The document is destroyed. • After a certain
 time. The API returns a FetchLaterResult that contains a boolean field
 "activated" that may be updated to tell whether the deferred request has
 been sent out or not. On successful sending, the whole response will be
 ignored by browser, including body and headers. Nothing at all should be
 processed or updated, as the page may have already be gone. Note that from
 the point of view of the API user, the exact send time is unknown.


 Blink componentBlink>Network>FetchAPI
 

 Search tagsbeacon , pending
 beacon , page
 unload beacon
 , unload
 beacon ,
 fetchlater 

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

 TAG review statusIssues addressed

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: Positive (
 https://github.com/mozilla/standards-positions/issues/703)

 *WebKit*: Positive (
 https://github.com/WebKit/standards-positions/issues/85)

 *Web developers*: Positive (
 https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
 )

 *Other signals*: W3C WebPerf:
 https://w3c.github.io/web-performance/meetings/2022/2022-03-31/index.html

 Security


 https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md#security-considerations
 https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit?pli=1#heading=h.kztg1uvdyoki


 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?

 None


 Goals for experimentationCollecting feedbacks around the stability of
 the fetchLater API, and whether to provide more useful API or to update its
 behavior model.

 Ongoing technical constraints

 See
 https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/fetch-later.md#what_s-not-supported
 for what's supported and what's not supported in the OT implementation.


 Debuggability

 There are no particular debugging APIs made available or Chrome
 DevTools integrations yet.


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

 This is a JS API that will be available to Blink platforms.


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

 https://wpt.fyi/results/fetch/fetch-later


 DevTrial instructions
 https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/fetch-later.md

 Flag name on chrome://flagsFetchLaterAPI

 Finch feature nameFetchLaterAPI

 Requires code in //chrome?True

 Tracking bug
 https://bugs.chr

Re: [blink-dev] Intent to Experiment: fetchLater API

[Yoav Weiss]

On Tue, Nov 21, 2023 at 9:54 AM Daisuke Enomoto 
wrote:

> Yoav,
>
> What milestones do you want to run the experiment in?
>
> We plan to run the dev trial in 120. When we request an OT, would you
> recommend us to send another I2E generated on chromestatus entry?
>

A dev trial doesn't require any approvals. Please revive this thread when
you're ready to request an OT.

>
> Also, can you kick off the other review checks in your chromestatus entry?
>
> Yes, we have kicked off Security and Privacy reviews.
>
>
> On Thu, Nov 16, 2023 at 12:42 AM Yoav Weiss 
> wrote:
>
>> Also, can you kick off the other review checks in your chromestatus entry?
>>
>> On Wednesday, November 15, 2023 at 10:40:08 AM UTC+1 Yoav Weiss wrote:
>>
>>> What milestones do you want to run the experiment in?
>>>
>>> On Wed, Nov 15, 2023 at 8:10 AM Jesugbamigbe Daniel Fadipe <
>>> jdanielfad...@gmail.com> wrote:
>>>

 Many thanks,

 J Daniel Fadipe
 07412666868


 On Wed, 15 Nov 2023 at 08:09, Ming-Ying Chung 
 wrote:

>>> Contact emailsm...@chromium.org, denom...@chromium.org,
> pending-beacon-experim...@google.com
>
> Explainer
> https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
>
> Specificationhttps://whatpr.org/fetch/1647/9ca4bda...37a66c9.html
>
> Design docs
>
> https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
>
> https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit#heading=h.ms1oipx914vf
>
> Summary
>
> fetchLater() is a JavaScript API to request a deferred fetch. Once
> called, the request is queued by the browser, and will be invoked in one 
> of
> the following scenarios: • The document is destroyed. • After a certain
> time. The API returns a FetchLaterResult that contains a boolean field
> "activated" that may be updated to tell whether the deferred request has
> been sent out or not. On successful sending, the whole response will be
> ignored by browser, including body and headers. Nothing at all should be
> processed or updated, as the page may have already be gone. Note that from
> the point of view of the API user, the exact send time is unknown.
>
>
> Blink componentBlink>Network>FetchAPI
> 
>
> Search tagsbeacon , pending
> beacon , page
> unload beacon
> , unload
> beacon ,
> fetchlater 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/887
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/703)
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/85)
>
> *Web developers*: Positive (
> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
> )
>
> *Other signals*: W3C WebPerf:
> https://w3c.github.io/web-performance/meetings/2022/2022-03-31/index.html
>
> Security
>
>
> https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md#security-considerations
> https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit?pli=1#heading=h.kztg1uvdyoki
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Goals for experimentationCollecting feedbacks around the stability of
> the fetchLater API, and whether to provide more useful API or to update 
> its
> behavior model.
>
> Ongoing technical constraints
>
> See
> https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/fetch-later.md#what_s-not-supported
> for what's supported and what's not supported in the OT implementation.
>
>
> Debuggability
>
> There are no particular debugging APIs made available or Chrome
> DevTools integrations yet.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>
> This is a JS API that will be available to Blink platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> https://wpt.

Re: [blink-dev] Intent to Ship: Protected Audience - Do Not Disable Cookie Setting in ReportEvent until 3PCD (Chrome - 120)

[Mike Taylor]

LGTM2

On 11/21/23 2:52 AM, Yoav Weiss wrote:

LGTM1

Thanks for the explanation!!

On Mon, Nov 20, 2023 at 3:49 PM Garrett Tanzer  wrote:

> Can you explain more how this would help with adoption?

Allowing for cookies on the beacons lets testers utilize
Attribution Reporting API’s debug reports

,
which are helpful for migrating to the new API. These reports are
gated on third party cookie availability. It also enables testers
to experiment with a single API at a time (e.g., verify that
Protected Audiences with existing measurement methods works as
intended and then add in ARA reporting) which allows for simpler
experiments with greater understanding of the impact of each.

> Wouldn't this create a false sense of "security" amongst early
adopters and cause them to rely on those cookies up until their
deprecation?

We make it abundantly clear in our documentation


that debug reports will go away at the point of third-party cookie
deprecation. We have also documented
 that these cookies
will only be sent with automatic beacons when third-party cookies
are enabled.

On Wed, Nov 15, 2023 at 4:15 PM Yoav Weiss
 wrote:



On Fri, Nov 10, 2023 at 10:23 PM 'Garrett Tanzer' via
blink-dev  wrote:

They should all be requested now.

Thanks

On Fri, Nov 10, 2023 at 3:45 PM Mike Taylor
 wrote:

Hi Garrett,

Would you mind requesting each of the review gates in
the chromestatus entry?

thanks,
Mike

On 11/7/23 12:24 PM, Garrett Tanzer wrote:


Intent to Ship: Protected Audience - Do Not Disable
Cookie Setting in ReportEvent until 3PCD (Chrome - 120)


Contact emails

shivani...@chromium.org
,
jkar...@chromium.org ,
lbr...@google.com ,
gtan...@google.com 


Explainer(s)

https://github.com/WICG/turtledove/pull/884


Relevant issue: Don't disable cookie setting in
ReportEvent API until 3PCD




Spec(s):

Since this change is only temporarily allowing
cookies in the automatic beacons and the
functionality change will be deprecated with 3PCD and
it respects 3PC preferences as cookies do today, it
is not added to the spec.



Summary

We launched Fenced Frames for Protected Audience as a
part of Chrome 115. With this change, we are
temporarily un-disabling credentials on the automatic
beacons

initiated
from a fenced frame (or urn iframe) until 3rd party
cookie deprecation (3PCD) to help with adoption.



Can you explain more how this would help with adoption?
Wouldn't this create a false sense of "security" amongst early
adopters and cause them to rely on those cookies up until
their deprecation?



Details

We received a request
(https://github.com/WICG/turtledove/issues/866) to
not disable credentials on automatic beacon reports
until 3PCD for both fenced frames and urn-iframes,
with higher priority for urn iframes. This will help
adtech in running experiments on Protected Audience.
For example, the Attribution Reporting API’s verbose
debugging feature requires cookies to be set in
headers, so it is currently broken for automatic
beacons.


With this change, we will switch the credentials mode
for automatic beacons only from
CredentialsMode::kOmit to CredentialsMode::kInclude.
Please note:

 *

This will be gated behind a check that 3rd party
cookies are enabled. This has the effect of
respecting current user preferences and
automatically disabling the change at 3PCD.

 *

A 

Re: [blink-dev] Intent to Ship: Protected Audience - Do Not Disable Cookie Setting in ReportEvent until 3PCD (Chrome - 120)

[Daniel Bratell]

LGTM3

/Daniel

On 2023-11-21 16:49, Mike Taylor wrote:


LGTM2

On 11/21/23 2:52 AM, Yoav Weiss wrote:

LGTM1

Thanks for the explanation!!

On Mon, Nov 20, 2023 at 3:49 PM Garrett Tanzer  
wrote:


> Can you explain more how this would help with adoption?

Allowing for cookies on the beacons lets testers utilize
Attribution Reporting API’s debug reports

,
which are helpful for migrating to the new API. These reports are
gated on third party cookie availability. It also enables testers
to experiment with a single API at a time (e.g., verify that
Protected Audiences with existing measurement methods works as
intended and then add in ARA reporting) which allows for simpler
experiments with greater understanding of the impact of each.

> Wouldn't this create a false sense of "security" amongst early
adopters and cause them to rely on those cookies up until their
deprecation?

We make it abundantly clear in our documentation


that debug reports will go away at the point of third-party
cookie deprecation. We have also documented
 that these cookies
will only be sent with automatic beacons when third-party cookies
are enabled.

On Wed, Nov 15, 2023 at 4:15 PM Yoav Weiss
 wrote:



On Fri, Nov 10, 2023 at 10:23 PM 'Garrett Tanzer' via
blink-dev  wrote:

They should all be requested now.

Thanks

On Fri, Nov 10, 2023 at 3:45 PM Mike Taylor
 wrote:

Hi Garrett,

Would you mind requesting each of the review gates in
the chromestatus entry?

thanks,
Mike

On 11/7/23 12:24 PM, Garrett Tanzer wrote:


Intent to Ship: Protected Audience - Do Not Disable
Cookie Setting in ReportEvent until 3PCD (Chrome - 120)


Contact emails

shivani...@chromium.org
,
jkar...@chromium.org ,
lbr...@google.com ,
gtan...@google.com 


Explainer(s)

https://github.com/WICG/turtledove/pull/884


Relevant issue: Don't disable cookie setting in
ReportEvent API until 3PCD




Spec(s):

Since this change is only temporarily allowing
cookies in the automatic beacons and the
functionality change will be deprecated with 3PCD
and it respects 3PC preferences as cookies do today,
it is not added to the spec.



Summary

We launched Fenced Frames for Protected Audience as
a part of Chrome 115. With this change, we are
temporarily un-disabling credentials on the
automatic beacons

initiated
from a fenced frame (or urn iframe) until 3rd party
cookie deprecation (3PCD) to help with adoption.



Can you explain more how this would help with adoption?
Wouldn't this create a false sense of "security" amongst
early adopters and cause them to rely on those cookies up
until their deprecation?



Details

We received a request
(https://github.com/WICG/turtledove/issues/866) to
not disable credentials on automatic beacon reports
until 3PCD for both fenced frames and urn-iframes,
with higher priority for urn iframes. This will help
adtech in running experiments on Protected Audience.
For example, the Attribution Reporting API’s verbose
debugging feature requires cookies to be set in
headers, so it is currently broken for automatic
beacons.


With this change, we will switch the credentials
mode for automatic beacons only from
CredentialsMode::kOmit to CredentialsMode::kInclude.
Please note:

 *

This will be gated behind a check that 3rd party
cookies are enabled. This has the effect of
respecting current user preferences and
automatically disabling the

[blink-dev] Web-Facing Change PSA: Improved CSS masking for SVG

[Philip Rogers]

Contact email...@opera.com

Specificationhttps://drafts.fxtf.org/css-masking/#positioned-masks

Summary

This is a follow-on to the improved CSS mask support in chromium 120 (
https://chromestatus.com/feature/5839739127332864) and adds new mask
support to SVG (multiple masks, as well as mask-mode, mask-composite,
mask-position, and mask-repeat). In addition, remote SVG masks (e.g., mask:
url(masks.svg#star)) are now supported. Explainer:
https://docs.google.com/document/d/1IzQv56NzfV1hA6YPr2j1chtb5qijNxykkYY7JyccZgc/edit?usp=sharing


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Firefox supports all of this behavior. There is low compatibility risk as
this adds new support that previously wouldn't work.


*Gecko*: Shipped/Shipping Firefox has nearly 100% pass rate on css-masking
WPT tests.

*WebKit*: No signal

*Web developers*: Strongly positive (
https://github.com/web-platform-tests/interop/issues/148) This is part of
interop-2023.

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

Basic debugging support with existing CSS support in devtools.


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

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/css/css-masking?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop


Flag name on chrome://flags

Finch feature nameCSSMaskingInterop

Requires code in //chrome?False

Tracking bughttps://crbug.com/1496470

Estimated milestones
Shipping on desktop 121
Shipping on Android 121
Shipping on WebView 121

Anticipated spec changes

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

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

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/CAJgFLLs8kzSBRBw8BmVtQG%3DBUo%2Bs9mSZ79U-qKASe-EmAcMS8g%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: Async Clipboard API: Allow empty ClipboardItem during read

['Anupam Snigdha' via blink-dev]

Contact emails

sni...@microsoft.com, est...@chromium.org, sa...@microsoft.com, 
jsb...@google.com

Explainer

https://docs.google.com/document/d/1OLVOESy3zecxY_6jMKdKVxeIGS2Q6mDmzc85rUNrRIE/edit?usp=sharing

Specification

https://w3c.github.io/clipboard-apis/#dom-clipboard-read

Design docs
https://github.com/w3c/clipboard-apis/issues/179
https://docs.google.com/document/d/1OLVOESy3zecxY_6jMKdKVxeIGS2Q6mDmzc85rUNrRIE/edit?usp=sharing

Summary

When the system clipboard is either empty or has unsupported formats, paste 
event returns an empty DataTransfer object, but the promise for 
`navigator.clipboard.read()`API is rejected. This creates interop differences 
and confusion among web developers as they aren’t sure why read failed.


Currently in Chrome, we throw a DataError. The proposal here is to return an 
empty ClipboardItem when the system clipboard is either empty or there aren’t 
any supported formats.

Blink component

Blink>DataTransfer

Search tags

AsyncClipboardAPI, 
ClipboardItem

TAG review

None

TAG review status

Not applicable

It satisfies one of the criterias for 
exception.
 This change has already been shipped in 
Safari
 and Firefox has also implemented 
ithttps://github.com/w3c/clipboard-apis/issues/179#issuecomment-1211995581>.
 The spec already allows empty ClipboardItem during read so it doesn’t need any 
update.


Risks


Interoperability and Compatibility

None. Safari has shipped this feature and Firefox has already implemented it.


Gecko: Positive 
(https://github.com/w3c/clipboard-apis/issues/179#issuecomment-1211995581)


WebKit: Shipped/Shipping 
(https://github.com/w3c/clipboard-apis/issues/179#issuecomment-1804303784)


Web developers: Positive This was a feedback from our partners at Office who 
are migrating from DataTransfer API to Async Clipboard API.


Other signals:

Ergonomics

N/A

Activation

N/A


Security

None. The proposal only returns an empty ClipboardItem instead of rejecting the 
promise returned from the read() method when the clipboard is empty, so there 
isn’t any impact on the async clipboard API.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

None


Debuggability

Existing devtools support should suffice.

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

Currently emptying the clipboard is not exposed to the web, so it's not 
possible to add a WPT test for it.

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

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

Sample links


https://flash-lateral-nylon.glitch.me

Estimated milestones

Shipping on desktop

121


Shipping on Android

121


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5192271976988672


This intent message was generated by Chrome Platform 
Status.



Thanks,
Anupam

Sent from Outlook

-- 
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/SA2PR00MB0985AFBC7DD255DDD628F6A9CFBBA%40SA2PR00MB0985.namprd00.prod.outlook.com.

Re: [blink-dev] Request for Deprecation Trial: Deprecate Third-Party Cookies

[Ben Kelly]

FYI, please see this blog post for more information on this deprecation
trial:

https://developer.chrome.com/blog/third-party-cookie-deprecation-trial/

On Fri, Nov 17, 2023 at 7:52 PM Mike Taylor  wrote:

> LGTM for a deprecation trial from M120 to M132. For those of you who have
> followed my career (all 2 of you), it shouldn't come as a surprise that I
> appreciate the desire and efforts to minimize the compat implications for
> sites that are earnestly moving towards this brave new post-3rd-party
> cookies world.
>
> (Note: I don't work on third-party cookie deprecation but I would have
> landed on a similarly recommended timeline for migration/deprecation.
> Thanks for being accommodating and realistic to the complicated demands of
> web development and deployment of different use-cases.)
>
> On 11/17/23 1:21 PM, Ben Kelly wrote:
>
> Contact emails
>
> johann...@chromium.org, wanderv...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12#name-the-cookie-header-field
>
> Summary
>
> We intend to deprecate and remove default access to third-party (aka
> cross-site) cookies as part of the Privacy Sandbox Timeline for the Web,
> starting with an initial 1% testing period in Q1 2024, followed by a
> gradual phaseout planned to begin in Q3 2024 after consultation with the
> CMA. (The gradual phaseout is subject to addressing any remaining
> competition concerns of the UK’s Competition and Markets Authority.)
>
> Phasing out third-party cookies (3PCs) is a central effort to the Privacy
> Sandbox initiative, which aims to responsibly reduce cross-site tracking on
> the web (and beyond) while supporting key use cases through new
> technologies. Our phaseout plan was developed with the UK's Competition and
> Markets Authority, in line with the commitments we offered for Privacy
> Sandbox for the web.
>
> To support this effort we would like to run a deprecation trial for
> third-party embedded content.  Qualified third-parties participating in the
> trial can supply a token via an iframe or third-party script in order to
> continue receiving third-party cookies on requests to that origin.
>
> Goals for experimentation
>
> The primary goal of the deprecation trial is to reduce the amount of
> broken user-visible experiences as third-party cookies are phased out.
> Third-party embedded content or services with these kinds of experiences
> can use the trial to continue to receive third-party cookies while they
> work on long term solutions for their users based on CHIPS, Storage Access
> API, Related Website Sets, FedCM, etc.
>
> To meet this goal, requests to register for the deprecation trial will be
> reviewed to confirm eligibility. Specifically, third-party providers will
> need to demonstrate functional breakage in user journeys to be eligible.
> Because the deprecation trial is not intended to support cross-site
> tracking for advertising purposes, third-party embeds and services used for
> advertising will not be eligible. The ineligibility of advertising use
> cases will also help to ensure the deprecation trial does not interfere
> with the industry testing planned for the start of 2024 as described by
> the CMA
> 
> .
>
> Experiment timeline
>
> Registration opens the week of November 27, 2023.
>
> The trial will end on December 27, 2024.
>
> Effective in Chrome versions M120 through M132
>
> Blink component
>
> Internals>Network>Cookies
> 
>
> Search tags
>
> 3pcd 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> Risks
> Interoperability and Compatibility
>
> Web Compatibility:
>
> Despite 3PCs already being blocked in Firefox and Safari and developer
> outreach efforts to raise awareness and encourage developers to prepare for
> the deprecation, we currently estimate that a non-trivial number of sites
> are still relying on third-party cookies for some user-facing
> functionality. See Intent to Deprecate and Remove for more information:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ
>
>
> Interoperability:
>
> Both Firefox and Safari have removed default access to third-party cookies
> already, though there are small differences in how browsers treat
> SameSite=None cookies in so called “ABA” scenarios (site A embeds site B,
> which embeds site A again). Chrome ships the more secure and more
> restrictive variant, and from initial conversations we are optimistic that
> other browsers will adopt it as well. There are also subtle differences in
> how browsers restore access to third-party cookies through mechanisms such
> as heuristics or custom quirks. Where Chrome implements similar measures
> (such as the heuristics), we try to 

Re: [blink-dev] PSA: New baseline format for test-harness tests

['Weizhong Xia' via blink-dev]

Folks, FYI we were finally able to make changes to remove the PASS lines in
baselines, which many of you have desired. With that the work to transit to
the new baseline format is all done.

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

thanks, Weizhong

On Tue, Oct 17, 2023 at 11:49 AM Christian Biesinger <
cbiesin...@chromium.org> wrote:

> Thanks, this looks great. I particularly like the omission of PASS lines.
>
> Christian
>
> On Tue, Oct 17, 2023 at 2:33 PM Weizhong Xia  wrote:
>
>> Yes, here is the design document:
>> https://docs.google.com/document/d/1FsbRm2gXwFnhyJYaE-wz2fagRABkuHCK4KCYb6JEhMQ/edit?resourcekey=0-47lxaiexsP8wfuzOtQhkXw#heading=h.103wg95souql
>>
>> thanks, Weizhong
>>
>> On Tue, Oct 17, 2023 at 10:54 AM Christian Biesinger <
>> cbiesin...@chromium.org> wrote:
>>
>>> Interesting! When you say "machine parsable", I assume you mean you want
>>> to detect which subtests passed/failed? Could you share an example of
>>> the new format? Thanks!
>>>
>>> On Mon, Oct 16, 2023 at 9:07 PM 'Weizhong Xia' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hi Blink Developers

 We want to let you know that we are in the process of converting
 baselines for test-harness tests into a new format. The reason is that we
 want to make baselines machine-parsable so that we can regenerate Wpt
 Metadata from Test Expectations and Baselines.

 We are doing this directory by directory. Until now we have done this
 for all legacy web tests, wpt_internal and external/wpt/html, and we are
 expecting to complete this work by the end of this week.

 This should mostly have no impact on your work, but a rebaseline might
 be needed if we happened to work on the same directory at the same time.

 thanks, Weizhong

 --
 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/CADXrSiobktBNXd1WD%2BK9gnaqAgW-oAq5Fn_3xGG1H9fUZ8Ezig%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/CADXrSipM0Dz1OzX3YT89JN96BAYMbPfZyvaV-x7fbVqdn-YXSw%40mail.gmail.com.

[blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin

Summary

Changes the lazy load intersection observer's init dictionary to use a
scrollMargin instead of a rootMargin. This allows lazy loading images
contained inside CSS scrollers, like carousels, to load as expected when
near the viewport instead of the current behavior where these images load
when at least one pixel is intersecting the viewport.


Blink componentBlink>Image


Search tagslazyload ,
scrollmargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Overall low as scroll margin also applies to the root element thus not
affecting lazy loading images that are currently loading with just a root
margin.


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)
https://bugzilla.mozilla.org/show_bug.cgi?id=1864794

*WebKit*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
) https://bugs.webkit.org/show_bug.cgi?id=264864

*Web developers*: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


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

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in-


Flag name on chrome://flagsLazyLoadScrollMargin

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if
needed.


Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 121
DevTrial on desktop 121
Shipping on Android 121
DevTrial on Android 121
Shipping on WebView 121

Anticipated spec changes

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

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Yoav Weiss]

Do I understand correctly that currently lazy-loaded images in CSS
scrollers have suboptimal behavior and this would improve that without
potentially harming other cases?

On Wed, Nov 22, 2023 at 1:55 AM Traian Captan  wrote:

> Contact emailstcap...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>
> Summary
>
> Changes the lazy load intersection observer's init dictionary to use a
> scrollMargin instead of a rootMargin. This allows lazy loading images
> contained inside CSS scrollers, like carousels, to load as expected when
> near the viewport instead of the current behavior where these images load
> when at least one pixel is intersecting the viewport.
>
>
> Blink componentBlink>Image
> 
>
> Search tagslazyload ,
> scrollmargin 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Overall low as scroll margin also applies to the root element thus not
> affecting lazy loading images that are currently loading with just a root
> margin.
>
>
> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
> ) https://bugzilla.mozilla.org/show_bug.cgi?id=1864794
>
> *WebKit*: Positive (
> https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
> ) https://bugs.webkit.org/show_bug.cgi?id=264864
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in-
>
>
> Flag name on chrome://flagsLazyLoadScrollMargin
>
> Finch feature nameNone
>
> Non-finch justification
>
> This feature is behind an enabled-by-default flag that can be disabled if
> needed.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1391989
>
> Estimated milestones
> Shipping on desktop 121
> DevTrial on desktop 121
> Shipping on Android 121
> DevTrial on Android 121
> Shipping on WebView 121
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5106926245642240
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%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/CAL5BFfUgBoRPaP9FxPceugOq7i4%3D8EYYy5GtrvRicsy3Ntzhhw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Yes, that's correct.


On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss  wrote:

> Do I understand correctly that currently lazy-loaded images in CSS
> scrollers have suboptimal behavior and this would improve that without
> potentially harming other cases?
>
> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
> wrote:
>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>
>> Summary
>>
>> Changes the lazy load intersection observer's init dictionary to use a
>> scrollMargin instead of a rootMargin. This allows lazy loading images
>> contained inside CSS scrollers, like carousels, to load as expected when
>> near the viewport instead of the current behavior where these images load
>> when at least one pixel is intersecting the viewport.
>>
>>
>> Blink componentBlink>Image
>> 
>>
>> Search tagslazyload ,
>> scrollmargin 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Overall low as scroll margin also applies to the root element thus not
>> affecting lazy loading images that are currently loading with just a root
>> margin.
>>
>>
>> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
>> ) https://bugzilla.mozilla.org/show_bug.cgi?id=1864794
>>
>> *WebKit*: Positive (
>> https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
>> ) https://bugs.webkit.org/show_bug.cgi?id=264864
>>
>> *Web developers*: Positive (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in-
>>
>>
>> Flag name on chrome://flagsLazyLoadScrollMargin
>>
>> Finch feature nameNone
>>
>> Non-finch justification
>>
>> This feature is behind an enabled-by-default flag that can be disabled if
>> needed.
>>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1391989
>>
>> Estimated milestones
>> Shipping on desktop 121
>> DevTrial on desktop 121
>> Shipping on Android 121
>> DevTrial on Android 121
>> Shipping on WebView 121
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5106926245642240
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%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/CAFxahvtwYuj4dukn%3DW5m%3D0f2CGipMw7JAugFt56kouPjfFp0Sw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Yoav Weiss]

Thanks, that sounds like a strict improvement.

On Wed, Nov 22, 2023 at 6:25 AM Traian Captan  wrote:

> Yes, that's correct.
>
>
> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss  wrote:
>
>> Do I understand correctly that currently lazy-loaded images in CSS
>> scrollers have suboptimal behavior and this would improve that without
>> potentially harming other cases?
>>
>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>> wrote:
>>
>>> Contact emailstcap...@chromium.org
>>>
>>> ExplainerNone
>>>
>>
A short (inline) explainer would help reviewers to understand e.g. if this
involves changes to the API surface that developers need to care about.
Can you write a few words on the impact on developers?


>>>
>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>
>>
The spec doesn't mention anything specific around root margins or scroll
margins (other than the algorithm name).
Are these concepts interoperable?


>
>>>
>>> Summary
>>>
>>> Changes the lazy load intersection observer's init dictionary to use a
>>> scrollMargin instead of a rootMargin. This allows lazy loading images
>>> contained inside CSS scrollers, like carousels, to load as expected when
>>> near the viewport instead of the current behavior where these images load
>>> when at least one pixel is intersecting the viewport.
>>>
>>>
>>> Blink componentBlink>Image
>>> 
>>>
>>> Search tagslazyload ,
>>> scrollmargin 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Overall low as scroll margin also applies to the root element thus not
>>> affecting lazy loading images that are currently loading with just a root
>>> margin.
>>>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/w3c/IntersectionObserver/issues/431)
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1864794
>>>
>>> *WebKit*: Positive (
>>> https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
>>> ) https://bugs.webkit.org/show_bug.cgi?id=264864
>>>
>>> *Web developers*: Positive (
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>>
>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in-
>>>
>>>
>>> Flag name on chrome://flagsLazyLoadScrollMargin
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justification
>>>
>>> This feature is behind an enabled-by-default flag that can be disabled
>>> if needed.
>>>
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989
>>>
>>> Estimated milestones
>>> Shipping on desktop 121
>>> DevTrial on desktop 121
>>> Shipping on Android 121
>>> DevTrial on Android 121
>>> Shipping on WebView 121
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5106926245642240
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%40mail.gmail.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribe

[blink-dev] Re: Intent to Ship: Document picture-in-picture: require user gesture for resize APIs

[Yoav Weiss]

On Friday, November 17, 2023 at 8:47:34 PM UTC+1 Tommy Steimel wrote:

Contact emailsstei...@chromium.org, liber...@chromium.org

ExplainerNone

Specificationhttps://github.com/WICG/document-picture-in-picture/pull/104

Summary

This adds a user gesture requirement for the resizeBy() and resizeTo() 
Window APIs for document picture-in-picture windows. This allows websites 
to make use of those APIs while mitigating much of the abuse potential of 
those APIs on an always-on-top window.


Blink componentBlink>Media>PictureInPicture 


TAG reviewN/A as this is a minor change to the behavior of an existing API

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


This added requirement would mean that calls to these API can now fail. Is 
that new? Or are developers already expected to handle failures?
Do we expect developers to start checking the UserActivation API 
 before 
calling these methods?



*Gecko*: No signal (https://github.com/mozilla/standards-positions/issues/
670#issuecomment-1786354361) Added comment to existing standards position 
issue for document picture-in-picture. No response yet

*WebKit*: No signal (https://github.com/WebKit/
standards-positions/issues/41#issuecomment-1786354016) Added comment to 
existing standards position issue for document picture-in-picture. No 
response yet

*Web developers*: Positive The ability to programmatically resize the 
document picture-in-picture window is one of the most-requested features 
for document picture-in-picture

*Other signals*:

Ergonomics

N/A


Activation

N/A


Security

While being able to resize an always-on-top window at will is a 
security/annoyance risk, by making the API consume a user gesture, the 
website can only resize once per click, which limits the possible abuse 
vectors


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that 
it has potentially high risk for Android WebView-based applications?

N/A


Debuggability

N/A


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

The document picture-in-picture API is not supported on Android


Is this feature fully tested by web-platform-tests 

?Yes

document-picture-in-picture/resize-requires-user-gesture.https.html


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justification

Small, low-risk change to existing API


Requires code in //chrome?False

Tracking bughttps://crbug.com/1354325

Sample links
https://steimelchrome.github.io/document-pip/click_to_resize.html

Estimated milestonesShipping on desktop121

Anticipated spec changes

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

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5398995019235328

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/d2de84d9-a13d-4ed4-8a77-a19ac26b7c34n%40chromium.org.

[blink-dev] Re: Intent to Ship: CSS supports() condition for @import

[Yoav Weiss]

LGTM1

While I'm not excited about @import in general and think no one should use 
it, this restricts it in potentially useful ways.

On Wednesday, November 15, 2023 at 3:28:48 PM UTC+1 Daniil Sakhapov wrote:

> Contact emailssakha...@chromium.org
>
> Specificationhttps://www.w3.org/TR/css-cascade-5/#conditional-import
>
> Summary
>
> It allows to import stylesheets and layers conditioned on supports(). If 
> the support() doesn't match, the import will not be fetched.
>
>
> Example: @import "mystyle.css" supports(display: flex);
>
> Blink componentBlink>CSS 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/279)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> https://wpt.fyi/results/css/css-cascade/import-conditions.html 
> https://wpt.fyi/css/cssom/cssimportrule.html
>
>
> Flag name on chrome://flagsCSSSupportsForImportRules
>
> Requires code in //chrome?False
>
> Estimated milestones
> DevTrial on desktop 121
> DevTrial on Android 121
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5899007704694784
>
> 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/13305766-65c8-427c-85a4-fc457c855bf0n%40chromium.org.

[blink-dev] Re: Intent to Ship: Storage Buckets API

[Yoav Weiss]

On Tuesday, November 14, 2023 at 9:38:55 PM UTC+1 Evan Stade wrote:

Contact emails

est...@chromium.org, a...@chromium.org, ajayrahate...@chromium.org

Explainer

https://github.com/WICG/storage-buckets/blob/main/explainer.md

Specification

https://wicg.github.io/storage-buckets

Summary

Storage Buckets gives sites the ability to organize on-device data into 
separate "buckets", allowing user agents to evict the grouped data 
independently of that which is in other buckets, and enabling sites to 
ergonomically manage semantically related data. Each storage bucket can 
contain data associated with established storage APIs such as IndexedDB and 
CacheStorage.


Blink component

Blink>Storage>Buckets 


TAG review

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

TAG review status

Issues addressed

Chromium Trial Name

StorageBuckets

Link to origin trial feedback summary

https://docs.google.com/document/d/1C8LiQfjYj9wIt94Q4PeCVwiA57-
uf37jSLLoBHYhUCM


Can you expand on the OT results? Are the "slow to adoption" comments 
relevant only to the OT itself or to the feature at large?
 


Origin Trial documentation link

https://developer.chrome.com/blog/storage-buckets/

Risks

Interoperability and Compatibility

If no other browsers end up implementing this API, websites will only be 
able to use the default bucket that is supported today.


Gecko: Positive (https://mozilla.github.io/standards-positions/#storage-
buckets)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/181)

Web developers: Positive

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that 
it has potentially high risk for Android WebView-based applications?

Doesn't change existing APIs.


Debuggability

Devtools


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

No

Is this feature fully tested by web-platform-tests 

?

No

Flag name on chrome://flags

storage-buckets

Finch feature name

StorageBuckets

Requires code in //chrome?

False

Tracking bug

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

Launch bug

https://launch.corp.google.com/launch/4227670

Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/4378

Availability expectation

Feature is expected to be available on Firefox, but timeline unknown. 
Implementation in Safari would likely first require widespread use.

Adoption expectation

Expected to be applied **in new projects** soon after launch. Full 
utilization of the API would require data migration, which is not easy and 
may slow adoption in existing projects. Abstractions may be among the first 
adopters as the API is, itself, an abstraction layer that simplifies 
functionality such as namespacing and managing chunks of data.

Adoption plan

We intend to use the Buckets API to expose additional storage-related 
functionality to the web, for example, session-scoped data, performance 
controls, etc. This new functionality will help drive adoption.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open 
source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop

121

OriginTrial desktop last

118

OriginTrial desktop first

115

DevTrial on desktop

110

Shipping on Android

121

OriginTrial Android last

118

OriginTrial Android first

115

DevTrial on Android

110

Shipping on WebView

121

OriginTrial webView last

118

OriginTrial webView first

115



Anticipated spec changes

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


Open issues/questions are add-only enhancements.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5739224579964928

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/u/2/
a/chromium.org/g/blink-dev/c/LZsMi8heTu0/m/bh0my7vpBwAJ Intent to 
Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/
LGfcc48qBHY/m/cXjQrqRIAAAJ?utm_medium=email&utm_source=footer


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/5ceb2515-e589-4d