Re: [blink-dev] Ready for Developer Testing: Intl.DurationFormat

[Daniel Bratell]

This was meant to be an Intent to Ship, right? It isn't in that state in 
ChromeStatus so it doesn't appear on the todo lists right now. Maybe you 
can navigate it to the right state and get the prerequisite reviews started?


/Daniel

On 2024-07-02 06:30, Frank Tang wrote:



Contact emails

ft...@google.com


Explainer

https://github.com/tc39/proposal-intl-duration-format


Specification

https://tc39.es/proposal-intl-duration-format


Design docs


https://docs.google.com/document/d/1UMwkeeiqVyVNhNW8CS1vwN9g2cIH0AryaU16DT-vGg0/edit


Summary

Intl.DurationFormat API is a TC39 ECMA402 proposal See 
https://github.com/tc39/proposal-intl-duration-format for the proposal 
The proposal advanced to Stage 3 on 2021-10 Spec: 
https://tc39.es/proposal-intl-duration-format/




Blink component

Blink>JavaScript>Internationalization 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

The spec is sync with Temporal . If Temporal dramatically change the 
definition of Temporal Duration, we may need to adjust the implemetation




/Gecko/: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1648139)

/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=214794) 
https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes


/Web developers/: Positive 
(https://github.com/tc39/ecma402-mdn/issues/22) 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat


/Other signals/:


Ergonomics

Temporal.Duration as defined in 
https://tc39.es/proposal-temporal/#sec-temporal-maximumtemporaldurationroundingincrement




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?


low



Goals for experimentation



Ongoing technical constraints

None



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://github.com/tc39/test262/issues/3305



Flag name on chrome://flags

harmony_intl_duration_format


Finch feature name

None


Non-finch justification

v8



Requires code in //chrome?

False


Tracking bug

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


Measurement

Use Count CL is under review in 
https://chromium-review.googlesource.com/c/chromium/src/+/5646725



Availability expectation

Feature is available on Web Platform mainline within 6 months of 
launch in Chrome.



Adoption expectation

Feature is considered a best practice for some use case within 6 
months of reaching Web Platform baseline.



Adoption plan

intl dev team inside google will rewrite closure duration format to 
use this feature with a thinner wrapper



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?


The feature depend on ICU and therefore also CLDR project


Estimated milestones

DevTrial on desktop 128

DevTrial on Android 128



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


https://github.com/tc39/proposal-intl-duration-format/issues


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5193021205774336


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL-vykLL8UDTG1QcKptGfyRPw8T6StP2%2BqMPFv09aUHPbg%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/CAOcELL_%2BO4nsuNmspoOr9fJx8YkV%2Bi1F%2BaNBvsLLGuriDBoGRA%40mail.gmail.com 

Re: [blink-dev] Intent to Experiment: Partitioning :visited links history Phase 2

[Daniel Bratell]

LGTM2 for a low percentage finch experiment in M128-M130 (inclusive)

/Daniel

On 2024-07-03 22:02, Chris Harrelson wrote:

LGTM1

(probably 3 needed because this is a non-standard experiment)

On Wed, Jul 3, 2024 at 12:28 PM Kyra Seevers 
 wrote:


One point of clarification: we are intending to experiment for one
milestone (M128), but would like to request 3 milestones (M128 -
M130) in case of any delays.

Thanks so much!

On Wed, Jul 3, 2024 at 2:16 PM Kyra Seevers
 wrote:

Update: I wanted to update the thread that WebKit left
positive indications of support for this proposal in the
request for position recently:
https://github.com/WebKit/standards-positions/issues/363.

Daniel: Thanks for the question! We will be using a
traditional Finch experiment rollout starting with Canary/Dev
in M128. I will update this thread with any changes to the
experiment that occur.

As for why we chose our keying structure: top-level site
allows us to prevent cross-site leaks and frame origin allows
us to adhere to the same-origin policy and avoid cross-frame
leaks. For example, if I have an iframe c.com <http://c.com>
embedded in both a.com <http://a.com> and b.com
<http://b.com>, keying by top-level site removes the
opportunity for cross-site tracking to occur between these two
iframes. For a visual example of this, please see the
explainer (especially Key Scenarios #2 and #3):

https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios.

Thanks all,
Kyra

On Wed, Jul 3, 2024 at 10:48 AM Daniel Bratell
 wrote:

What milestones do you plan to run the experiment in?

(Also, why isn't it enough to key on frame origin? I'm
sure there is a good reason but it's not obvious.)

/Daniel

On 2024-07-02 22:42, Kyra Seevers wrote:



Intent to Experiment: Partitioning :visited links
historyPhase 2 (User-facing partitioning for
:visited links)


Contact emails

kyraseev...@chromium.org


Explainer

https://github.com/kyraseevers/Partitioning-visited-links-history
<https://github.com/kyraseevers/Partitioning-visited-links-history>


Specification

We plan to specify our solution before shipping. This
work currently falls under the wording in CSS Selectors
Level 4 <https://www.w3.org/TR/selectors-4/#link>: “UAs
may treat all links as unvisited links or implement other
measures to preserve the user’s privacy while rendering
visited and unvisited links differently.”


Summary

To eliminate user browsing history leaks, anchor elements
will be styled as :visited if and only if they have been
clicked from this top-level site and frame origin before.
On the browser-side, this means that the VisitedLinks
hashtable will now be partitioned via "triple-keying", or
by storing the following for each visited link: . By only styling links
that have been clicked on this site and frame before, the
many side-channel attacks that have been developed to
obtain :visited links styling information are now
obsolete, as they no longer provide sites with new
information about users.


Blink component

Blink>History>VisitedLinks

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory%3EVisitedLinks>


Search tags

visited links
<https://chromestatus.com/features#tags:visited%20links>,
:visited selector
<https://chromestatus.com/features#tags::visited%20selector>,
partitioning history
<https://chromestatus.com/features#tags:partitioning%20history>


TAG review

https://github.com/w3ctag/design-reviews/issues/896
<https://github.com/w3ctag/design-reviews/issues/896>


TAG review status

Issues addressed


Risks


Interoperability and Compatibility


Gecko: Positive
(https://github.com/mozilla/standards-positions/issues/1040
<https://github.com/mozilla/standards-positions/issues/1040>)


WebKit: Under Review
(https://github.com/WebKit/standards-positions/issues/363
<https://github.com/WebKit/standards-positions/issues/363>)


Web developers: No signal

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Daniel Bratell]

LGTM1

/Daniel

On 2024-06-26 20:16, 'Sahir Vellani' via blink-dev wrote:

The PR is ready and has been *approved *by the PEWG.

The shape of the API has been reverted to an id (albeit with a slight 
name change, persistentDeviceId) on the main PointerEvent interface. 
All links along with request for positions have been updated. Linking 
the spec pr here for 
convenience.


On Thursday, May 23, 2024 at 7:00:38 AM UTC-7 fla...@chromium.org wrote:

There were some fresh concerns raised about the shape of the spec
PR  which are being
hashed out on that review thread. I will give it approval once we
reach a consensus there.

On Wed, May 22, 2024 at 4:30 PM Yoav Weiss (@Shopify)
 wrote:

OK, thanks for outlining the spec mechanics :)

Regardless of whether the PR actually lands in the spec, for
the purpose of risk-assessment, it's even more interesting to
know if the PR is *ready* to land in the spec.
Can y'all clarify its review status? If it's ready to land,
can a spec editor approve it, even if it doesn't land until later?

On Fri, May 17, 2024 at 10:18 AM Patrick H. Lauke
 wrote:



On 16/05/2024 21:05, Robert Flack wrote:
> I believe the reason for waiting is that the intention
is to switch to a
> different publishing model after level 3 is published?
@Patrick H. Lauke
>  to confirm.

Apologies for the convoluted model here ... I have to
admit that I'm
actually not sure what the expected way of working around
this is, as
Pointer Events has been such a "slow and steady" process
so far, with a
very linear way of working - it's only now that we're just
hoping to get
PE3 to REC and then had this extra functionality come in
that we've hit
this snag. I will check with Philippe at W3C to work out
what the best
way forward here is (have the "frozen" version that makes
its way
through the steps to REC, while being able to already have a
"future/next" branch).

P
-- 
Patrick H. Lauke


* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

--
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/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/619d8f4a-54ef-4b0b-8e02-869cc455bb16%40sarasas.se.

Re: [blink-dev] Intent to Experiment: Partitioning :visited links history Phase 2

[Daniel Bratell]

What milestones do you plan to run the experiment in?

(Also, why isn't it enough to key on frame origin? I'm sure there is a 
good reason but it's not obvious.)


/Daniel

On 2024-07-02 22:42, Kyra Seevers wrote:



Intent to Experiment: Partitioning :visited links historyPhase
2 (User-facing partitioning for :visited links)


Contact emails

kyraseev...@chromium.org


Explainer

https://github.com/kyraseevers/Partitioning-visited-links-history 




Specification

We plan to specify our solution before shipping. This work currently 
falls under the wording in CSS Selectors Level 4 
: “UAs may treat all links as 
unvisited links or implement other measures to preserve the user’s 
privacy while rendering visited and unvisited links differently.”



Summary

To eliminate user browsing history leaks, anchor elements will be 
styled as :visited if and only if they have been clicked from this 
top-level site and frame origin before. On the browser-side, this 
means that the VisitedLinks hashtable will now be partitioned via 
"triple-keying", or by storing the following for each visited link: 
. By only styling links that 
have been clicked on this site and frame before, the many side-channel 
attacks that have been developed to obtain :visited links styling 
information are now obsolete, as they no longer provide sites with new 
information about users.



Blink component

Blink>History>VisitedLinks 




Search tags

visited links 
, :visited 
selector , 
partitioning history 




TAG review

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




TAG review status

Issues addressed


Risks


Interoperability and Compatibility


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



WebKit: Under Review 
(https://github.com/WebKit/standards-positions/issues/363 
)



Web developers: No signals


Other signals:

 *

Positive initial signals from presentation at WebAppSec from both
Apple and Firefox



 *

At the XS Leaks Summit, Firefox stated exploration of :visited
links partitioning in their privacy goals for the upcoming year at
the XS-Leaks Summit

 *

Positive or neutral initial signals from security and privacy
researchers at the XS-Leaks summit. No security concerns about
this design. Interest in understanding user behavior around this
new model of what constitutes a :visited link.

 *

Feedback from UX that CSS extensibility is in-demand from
developers right now, and this work would pave the way for less
restricted CSS on anchor elements. In addition, support from
various developers who believe that taking care of this
long-standing privacy leak will allow their own security and
privacy solutions to advance once history sniffing is no longer an
issue.


Ergonomics

This design is asynchronous and not used in tandem with other APIs.


Activation

Since this is a Finch roll-out, there are no additional activation risks.


Security

For this design we worked with the Chrome Security Architecture team 
to ensure reasonable precautions were taken against leaks of the 
:visited links hashtable via renderer compromise.



WebView application risks

This experiment will not run on WebView. This feature deals with 
platform-specific code and the WebView implementation of :visited 
links does not integrate with the History Database.




Goals for experimentation

Our intent is to run a Finch experiment. This user-facing experiment 
will use the traditional Finch roll-out schedule. We will utilize 
newly added UMA to determine the percentage of links styled as 
:visited under partitioning, as well as observe the size, efficiency, 
and impact of the newly partitioned infrastructure in comparison to 
the unpartitioned (original) codepaths.



Experiment Risks

As this is a Finch experiment, it is per-client rather than per-site. 
The biggest potential risk to clients is a visible change to which 
links are styled as :visited once they enter the experiment. However, 
based on pre-experimental metrics analysis, we believe that most links 
the user sees will remain unchanged. In the event of an issue during 
the experiment, we will flip our kill switch via Finch.



   

Re: [blink-dev] Re: Intent to Ship: CSS Anchor Positioning: Unwrapped inset-area()

[Daniel Bratell]

LGTM2

/Daniel

On 2024-07-03 13:53, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Jul 3, 2024 at 1:50 PM Anders Hartvoll Ruud 
 wrote:


On Wed, Jul 3, 2024 at 11:35 AM Yoav Weiss (@Shopify)
 wrote:



On Wednesday, July 3, 2024 at 10:47:21 AM UTC+2 Anders
Hartvoll Ruud wrote:

Contact emailsandr...@chromium.org

ExplainerNone


Specificationhttps://drafts.csswg.org/css-anchor-position-1/#position-try-fallbacks



Summary

Replaces the inset-area() function with inset-area values
directly within position-try-fallbacks. This means that
you now just write e.g. position-try-fallbacks:top instead
of position-try-fallbacks:inset-area(top).


Just to clarify - this removes the inset-area function?


Yes, correct.


The CSSWG made this change shortly after CSS Anchor
Positioning shipped in Blink:


https://github.com/w3c/csswg-drafts/issues/10320#issuecomment-2137882897





Blink componentBlink>CSS



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility


Searching for existing cases of "inset-area(" in HTTP
Archive, I found just a single match out of 638589186 rows:

https://css3test.com/tests/css-anchor-position-1.js



Do you know if this was used in a production site?
From the name, one can assume it's a demo site..

It's just the input for the view to show the features supported by
the browser e.g.: https://css3test.com/#css-anchor-position-1

It doesn't count as "production use" IMO. Also, I sent a PR to
update it: https://github.com/LeaVerou/css3test/pull/249


Agree!



Query used:

#standardSQL

SELECTresponse_bodies.url


FROM`httparchive.response_bodies.2024_06_01_desktop`ASresponse_bodies

WHEREREGEXP_CONTAINS(response_bodies.response_body,
r'inset\-area\(')


/Gecko/: No signal

/WebKit/: No signal

/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



Debuggability

None



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

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature nameCSSInsetAreaValue

Requires code in //chrome?False

Estimated milestonesShipping on desktop128Shipping on
Android128Shipping on WebView128

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

Statushttps://chromestatus.com/feature/5116199771045888?gate=5071381116223488



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/CAOmohS%2Ba%2BW6mFB9LLuu5eh6HwLg%2BHu7HxzoH-p73%2B38MnGSiyg%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 

Re: [blink-dev] Intent to Extend Experiment: Capture all screens

[Daniel Bratell]

Any reason to not make it available for everyone? Asking for a friend.

Another thing, when extending experiments we want to see evidence of 
substantial progress on the feature so that it doesn't just roll along 
until it's burned in by pure inertia. Could you please tell us about the 
progress since the last extension?


/Daniel

On 2024-06-19 16:42, 'Simon Hangl' via blink-dev wrote:
Apologies for the delay. We'd like to ask for an extension of the 
origin trial from M129 to M132.


@Yoav, I made the design doc available for all chromium accounts here 
.


@Vladimir, we are on track with isolated web apps and an intent to 
ship will be submitted in the next milestones.


On Thursday, March 21, 2024 at 4:38:49 PM UTC+1 Vladimir Levin wrote:

On Mon, Mar 18, 2024 at 11:17 AM 'Simon Hangl' via blink-dev
 wrote:

Hello blink-dev,

We’d like to ask for an extension to our Origin Trial, from
M124 to M130. This is due to a dependency on isolated web
apps, which are delayed.


The intent process only allows extensions of 3 milestones at a
time. It also requires evidence of substantial progress on the
feature. It sounds like here, the original experiment did not go
as planned due to a dependency. Do you know if the isolated web
apps feature is ready now? In other words, is this dependency
satisfied?


Contact emails

sim...@google.com


Explainer

https://github.com/screen-share/capture-all-screens/blob/main/README.md




Specification

https://screen-share.github.io/capture-all-screens



Design docs

https://screen-share.github.io/capture-all-screens


https://github.com/screen-share/capture-all-screens/blob/main/README.md




https://docs.google.com/document/d/13el0NriAUpAzLUw96V7zQiMSjgH9zVaTXUHtuaq8-HI/edit?resourcekey=0-jRPpeLth1odq6M5iFLswig


Summary

Capture all the screens currently connected to the device
using getAllScreensMedia(). Calling getDisplayMedia() multiple
times requires multiple user gestures, burdens the user with
choosing the next screen each time, and does not guarantee to
the app that all the screens were selected.
getAllScreensMedia() improves on all of these fronts. (As this
feature has extreme privacy ramifications, it is only exposed
behind an enterprise policy, and users are warned before
recording even starts, that recording *could* start at some
point.)


Blink component

Blink>GetDisplayMediaSet




TAG review

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


TAG review status

Complete


Chromium Trial Name

GetAllScreensMedia


Link to origin trial feedback summary

https://github.com/screen-share/capture-all-screens/issues


Origin Trial documentation link

https://github.com/screen-share/capture-all-screens


Risks


Interoperability and Compatibility

This API is only available to origins allowlisted by
administrators through a policy. The policy itself is
non-standard, limiting even theoretical interoperability.This
API rejects requests from pages that are not allow-listed
through an administrator. The likelihood of this API being
adopted by a browser that does not provide administrators
mechanisms to manage clients is low.

Gecko: N/A

WebKit: N/A

Web developers: Positive
(https://github.com/screen-share/capture-all-screens/issues/9
)

Other signals:


Ergonomics

No


Activation

The challenge for developers is the limitation of the API to
origins allowlisted by an enterprise policy.


Security

1. Risk of malicious sites exploiting the API and
gaining access to sensitive information on users'
devices. This risk is mitigated by the API only being
accessible to origins allowlisted by an enterprise policy.


2. Risk of users loading private information that gets
recorded and made available to apps affiliated with

Re: [blink-dev] Intent to Ship: WebAuthn hints

[Daniel Bratell]

LGTM1

/Daniel

On 2024-06-19 23:15, Adam Langley wrote:
On Mon, Jun 10, 2024 at 9:36 PM Yoav Weiss (@Shopify) 
 wrote:



TAG review status

Not applicable


Can you clarify why that's the case?


This is a tiny change that is already in a WG's editor's draft.


Interoperability and Compatibility

None: new option which only tweaks UI.


/Gecko/: No signal

/WebKit/: No objections when asked in person.


Can you ask for positions? https://bit.ly/blink-signals


https://github.com/WebKit/standards-positions/issues/365
https://github.com/mozilla/standards-positions/issues/1043

> Is it possible to put together a small explainer for this. It's a bit difficult to 
understand what this hint would control. Do you have examples?


I'm not sure that this is big enough for a formal explainer, but I can 
summarize quickly here:


In the beginning, WebAuthn was a spec purely for security keys and 
overwhelmingly for enterprises. Those enterprises were eventually 
happy once the spec was fleshed out to cover all their needs.


Then WebAuthn started being useful for non-enterprise cases too, and 
browser UI now includes those options. Also, the UI shows 
non-security-key options prominently because most users are no longer 
using security keys.


But that makes the enterprises sad: they issue security keys to their 
employees and liked the old UI a lot better.


So this "hints" parameter lets sites express that they want the UI to 
default to security keys because they know that it's an internal 
website and all the users are required to use their company-issued 
security keys with it.


That's 90% of the motivation. There is also some desire in the WG to 
tweak the ways that some existing, somewhat similar mechanisms work 
and so the start of that also exists as a couple of other hints that 
can be expressed. The Chromium implementation does currently also 
recognise and respect those values too because it's trivial to include 
them.



Cheers

AGL

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzHtofcaVHUT9FZfCtqNbsU00%3DxnLRZqA58QcJU%2BcaM5A%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/f59010fb-4c35-4c9f-85fb-9cf81f9fe7d4%40gmail.com.

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

[Daniel Bratell]

LGTM3

/Daniel

On 2024-06-13 10:56, Yoav Weiss (@Shopify) wrote:

LGTM2

On Thu, Jun 13, 2024, 10:32 Chris Harrelson  wrote:

LGTM1

On Wed, Jun 12, 2024 at 10:26 PM 'Siye Liu' via blink-dev
 wrote:

Yes, these tests will all pass if we enable the runtime flag
`CaretPositionFromPoint`.

The few Mozilla failures do represent their non-spec compliant
behavior.

Thanks,
Siye

On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7
yoav...@chromium.org wrote:

On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev
 wrote:

Reviews requested.

Thanks,
Siye

On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris
Harrelson wrote:

Hi, please fill out these reviews on
your chromestatus entry:

image.png

On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via
blink-dev  wrote:

Yes, the API returns offset inside text input
and textarea elements.

Thanks,
Siye

On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7
Brian Birtles wrote:

Hi,

Does this return the offset inside text
input elements like Gecko's implementation?

Best regards,

Brian

2024年6月6日木曜日 3:20:24 UTC+9
si...@microsoft.com:

Contact emails
si...@microsoft.com, sa...@microsoft.com

Explainer
None

Specification

https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint

Summary
This new API allows users to get
current caret position from a given
screen point.
The API returns a CaretPosition object
which represents the caret position
indicating current text insertion
point including the containing DOM
node, caret's character offset, and
the client rectangle of caret range.
The API also supports get
CaretPosition inside Shadow DOM. To
get CaretPosition inside Shadow DOM,
caller needs to provide reference to
all the shadow roots that this API can
pierce into.


Blink component
Blink>CSS



TAG review
document.caretPositionFromPoint API in
shadow DOM scenario · Issue #949 ·
w3ctag/design-reviews (github.com)



TAG review status
Issues open

Risks


Interoperability and Compatibility
Gecko already implemented the API
without the argument that contains
shadow roots that this API can pierce
into. Webkit/Blink didn't implement
it. The Gecko implementation in shadow
DOM scenario is not spec-compliant
either (Spec changed recently to cover
shadow DOM scenario). Gecko 's
position is positive on this API. We
expect that Gecko's behavior will be
changed to be spec-compliant in the
future. There is also a future compat
risk too if we decided to deprecate
the non-standard API
`document.caretRangeFromPoint`:
https://crbug.com/690599


/Gecko/: Positive

Re: [blink-dev] Intent to Ship: Support 'color-interpolation: linearrgb' on SVG gradients

[Daniel Bratell]

LGTM3

/Daniel

On 2024-06-12 17:50, Yoav Weiss (@Shopify) wrote:

LGTM2

On Wed, Jun 12, 2024 at 5:50 PM Chris Harrelson 
 wrote:


LGTM1

On Tue, Jun 11, 2024 at 10:23 AM Fredrik Söderquist 
wrote:

On Tue, Jun 11, 2024 at 6:08 AM Yoav Weiss (@Shopify)
 wrote:



On Mon, Jun 10, 2024 at 11:25 AM Fredrik Söderquist
 wrote:


Contact emails

f...@opera.com


Explainer

None


Specification

https://svgwg.org/svg2-draft/painting.html#ColorInterpolation


Summary

Allows SVG gradients to interpolate in a linear-light
sRGB color space. Currently all SVG gradients
interpolate in a gamma-encoded sRGB color space.



Blink component

Blink>SVG




Search tags

SVG , CSS
, Color



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

The risk along both axes is fairly low since the
difference is in rendering only (even if the rendering
can differ quite significantly).



/Gecko/: Shipped/Shipping
(https://www.mozilla.org/en-US/firefox/123.0/releasenotes)

/WebKit/: No signal


Can you file for a signal?

https://github.com/WebKit/standards-positions/issues/362


/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



Debuggability

None



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

Yes


Is this feature fully tested by
web-platform-tests

?

Yes


https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg



Flag name on chrome://flags

None


Finch feature name

SvgGradientColorInterpolationLinearRgbSupport


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/324440102


Estimated milestones

Shipping on desktop 127

Shipping on Android 127

Shipping on WebView 127



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/5131849549742080?gate=6228725141340160

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/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%40mail.gmail.com

.

-- 
You received this message because 

Re: [blink-dev] Intent to Ship: Snap Events

[Daniel Bratell]

LGTM2

/Daniel

On 2024-06-12 13:14, Yoav Weiss (@Shopify) wrote:

LGTM1

This seems like a useful addition, with lots of developer demand. 
While more detailed explainers would have been helpful, I don't feel 
it's a blocker atm, as the demos provided helped me understand what 
we're shipping and how developers will use it.


On Tue, Jun 11, 2024 at 4:46 PM Adam Argyle  wrote:

Slightly different strategy to share a public photo
https://photos.app.goo.gl/5vHQ4cecJqHWN7DGA, try this one?  

On Tue, Jun 11, 2024 at 12:36 AM Yoav Weiss (@Shopify)
 wrote:



On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev
 wrote:

Indeed, developer sentiment is full of excitement! Who
wouldn't want to throw out their hyper intersection
observers with a perfectly timed callback? or even better,
getting insights into the concept of "changing" which is
currently opaque to authors.

> Philip: For the scrollsnapchange event it's easy to
imagine updating some state below a carousel to match the
snapped element, such as item description or store
inventory. For scrollsnapchanging I don't dare hazard a
guess, can someone say what the canonical use case for
this is?
I think you'll find that snapchanging is very prominent in
mobile gesture based UI and may be used even more than
snapchange. Like one of those features you can't unsee
once you see it working. Consider this video I took of a
game on mobile

,


It's 404ing for me..

snapchanging and snapchanged are distinctly used for 2
separate moments of UI feedback. I have many examples like
this! The examples are what led to the APIs. Another
really common example will be revealing the caption or
action buttons in a carousel. Which it's probably worth
noting we're working on a CSS way to know some of this
information too, we're prototyping snapped as a "state
query."

Here's a few demo's showing some "picker" use cases,
which I feel will be the majority cases, where folks are
observing the snapped or soon to be snapped item and
updating ancillary UI for the user. I have a backlog of
many more to make  Think of these things like snap
triggered animation, which can be a very healthily
compliment to scroll driven animation (which currently
doesn't have a "trigger" feature, only linked).

I bucket the 2 events like:
- the *scrollsnapchanging* event is eager to provide user
feedback, can fire many more times than change
- while *scrollsnapchange* is great for user feedback
after they've lifted their finger or scroll has ended,
timed better for confirmation or whatever. I show an
example below that I use change instead of changing so the
animation trigger isn't too busy.

*Color picker*:
https://codepen.io/argyleink/pen/zYXdgew

*Date time picker (both eager and timed):*
https://codepen.io/argyleink/pen/WNageoZ

*Date time picker (eager):*
https://codepen.io/argyleink/pen/oNOWwKq

*Date time picker (timed for view transitions):*
https://codepen.io/argyleink/pen/LYvzGRW

> Regarding origin trials:
I havent met a front-end dev who's been interested in an
origin trial, but fullstack or backend devs needing a high
impact business feature (like a fugu feature) do. We
didn't do an origin trial for scrollend

,
and that felt like the right path forward. Feels like
these 2 events are in a similar bucket as scrollend.

Let me know how else I can help!

On Wed, Jun 5, 2024 at 7:40 PM Alex Russell
 wrote:

Thanks for the link, Phillip. Absolutely agree that
this is an unmet need and something we should have
added long ago; I'd just like to see evidence that
we're matching that need with a sufficient solution
and that we've done our homework. There's almost
nothing worse than getting to the end of a launch and
realizing that some important use-cases isn't covered,
and I don't have confidence based on what we've
produced that we would not end up in this situation.

An exhaustive explainer with considered alternatives
and sample 

Re: [blink-dev] Intent to Ship: Protected Audience - Fix implementation and spec for renderSize

[Daniel Bratell]

LGTM2

/Daniel

On 2024-06-12 13:09, Yoav Weiss (@Shopify) wrote:

LGTM1

This sounds like a web-exposed bug fix, and I agree that the risk 
seems low.


On Tue, Jun 11, 2024 at 6:10 PM 'Xiaochen Zhou' via blink-dev 
 wrote:


I have started the requests, thank you. This item was originated
from a previous launch:
https://chromestatus.com/feature/5140606359175168?gate=5143092244250624.
This feature was added to the Protected Audience explainer, but
was never implemented or spec'd. This launch implemented this
missing feature and added it to the spec. Please refer to the
previous launch for reviews, thank you.

On Tuesday, June 11, 2024 at 11:36:28 AM UTC-4 vmp...@chromium.org
wrote:

Hi,

Can you please start the various reviews in chromestatus?
chipsna.png

Thanks,
Vlad

On Fri, Jun 7, 2024 at 11:10 AM 'Xiaochen Zhou' via blink-dev
 wrote:


Contact emails

xiaoc...@google.com, shiva...@google.com, jka...@google.com


Explainer

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


Specification

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



Design docs


https://docs.google.com/document/d/1JSUZzEnVGn6Rz6ncLbyhThModoxTGnBn-jS5xJf4Aq0/edit?usp=sharing




Summary

We will complete the renderSize implementation to match
what the Protected Audience explainer claims

.
The explainer states that if the Protected Audience
generateBid function returns a render URL with size
specified, then the browserSignals argument to the scoreAd
function will have a renderSize field reflecting that size
(so that all relevant information about the bid is
available for scoring). However this was missed during
implementation.


Setting this field is unlikely to break existing usage as
this field has been a part of the explainer for 7 months
and has always been optional. renderSizeis only passed
into scoreAd(), as part of browserSignals, if
generateBid() returned a width and height. If it is
specified, script can check whether the fix is enabled by
executing:


'renderSize' in browserSignals


See Github issue
and
explainer sections for renderSize

.


Blink component

Blink>InterestGroups




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None


Gecko: No signal


WebKit: No signal


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



Debuggability

Additional debugging capabilities are not necessary for
these feature changes.



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

No

Supported on all six Blink platforms except Android WebView.



Is this feature fully tested by web-platform-tests

?

Yes, it is tested by

third_party/blink/web_tests/external/wpt/fledge/tentative/score-ad-browser-signals.https.window.js.


Flag name on chrome://flags

None


Finch feature name

None


Please add a runtime flag with a base feature for this, just in case 
this turns out riskier than expected.



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/u/1/issues/333628467

Re: [blink-dev] Re: Intent to Ship: No-Vary-Search support for prerender

[Daniel Bratell]

Now, when it looks like this will be shipped, can you please update the 
stalled standard-position issues for Mozilla and WebKit so that they 
know that we'll proceed with it.


/Daniel

On 2024-06-06 19:21, Vladimir Levin wrote:

LGTM3

On Thu, Jun 6, 2024 at 12:45 PM Chris Harrelson 
 wrote:


LGTM2

On Wed, Jun 5, 2024 at 9:56 PM Mike Taylor
 wrote:

LGTM1 - I'm very happy to see this ship.

On 6/6/24 11:42 AM, Domenic Denicola wrote:

I will abstain from approving this feature as an API Owner,
as one of the people responsible for it. But I will urge
other API owners to approve it, and give a bit of reasoning.

In my opinion, this is a straightforward extension from
prefetch to prerender which makes the web platform more
uniform. It is good that it is being done as a separate
intent, since it is shipping at a different time, and thus
need to appear separately in e.g. beta blog posts and other
developer-facing documentation. But I think the same
considerations that helped the prefetch version get a prompt
approval should apply here.

BTW, looking back on that previous thread

,
some of the non-blocking discussion raised there was about
engaging the HTTPWG. I'm happy to report that we've started
this process, producing a draft RFC
 
and
getting some discussion

started on the relevant mailing list, which seem relatively
positive to me. There was also some concern about ensuring
that compression dictionaries and this header aligned on the
same naming; as far as I can tell that issue no longer exists
as the latest compression dictionaries draft

 
only
has "match", and no longer "match-query".

On Wednesday, June 5, 2024 at 11:04:10 PM UTC+9 Liviu Tinta
wrote:

Contact emails

dome...@chromium.org, jbro...@chromium.org,
liviuti...@chromium.org


Explainer


https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#prerendering-activation




Specification

https://wicg.github.io/nav-speculation/no-vary-search.html



Summary

Enables a prerender entry to match even if URL query
parameters change. The No-Vary-Search HTTP response
header declares that some or all parts of a URL's query
can be ignored for cache matching purposes. It can
declare that the order of query parameter keys should not
cause cache misses, that specific query parameters should
not cause cache misses or that only certain known query
parameters should cause cache misses. It could apply to
multiple caches, but this entry refers to support for
prerender.



Blink component

Internals>Preload>Prerender




TAG review

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



TAG review status

Pending


Risks

Interoperability and Compatibility

None



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


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


Web developers: No signals Below is the text from the I2S
of the No-Vary-Search on navigational prefetch, and we
believe the same applies to Prerendering. Google Search
has been experimenting with No-Vary-Search header /
Speculation Rules "expects_no_vary_search". This
functionality helps Google Search to match prefetched
content to the next user navigation. Developers can use
parameters in the prefetched URL that are not needed when
navigating to the actual link (e.g. the source of the
link click). The server can customize behavior using
these parameters without causing a cache miss in the
browser. 

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

[Daniel Bratell]

I agree. One lgtm is enough for this, but thanks to John for raising it.

/Daniel

On 2024-06-06 07:59, Mike Taylor wrote:


I will claim that it doesn't, since it's just for 1 more milestone.

(if other API OWNERS disagree, now is a great time to chime in!)

On 6/6/24 2:30 PM, John Delaney wrote:
Thanks Mike. I should have included this in the original email, but 
the initial I2E for this feature needed 3 LGTMs as it was a 
non-standard experiment. Does this extension also require 3?


Thanks again!

On Thu, Jun 6, 2024 at 1:00 AM Mike Taylor  
wrote:


LGTM to extend one more milestone (M126).

On 6/5/24 11:57 PM, John Delaney wrote:


We would like to extend the Cookie Deprecation Label
experimental feature being used for Chrome Facilitated Testing. 
This feature previously received approval to run through the end
of M125 (ending roughly June 10, 2024).  The Facilitated Testing
period, however, is scheduled to run through June 30, 2024.


Therefore, we would like to extend Cookie Deprecation Labels for
another milestone through M126.


Contact emails

johni...@chromium.org ,
wanderv...@chromium.org ,
lin...@chromium.org 


Explainer


https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md



https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing



Summary

To prepare for the third-party cookie deprecation, it is
important to understand the full impact of Chrome’s planned
transition from third-party cookies to the Privacy Sandbox Ads APIs.


This experiment exposes a temporary set of APIs which provide
access to browser-determined treatment and control groups to
support opt-in server side testing of the third-party cookie
deprecation.


We are exploring ways to address ecosystem feedback that we
should continue supporting labels after 30 June.  We expect to
provide more information soon.

Link to “Intent to Experiment” blink-dev discussion


https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ



Goals for experimentation

The goal of this experiment is to allow adtechs to evaluate the
impact of third party cookie phase out through opt-in server
side testing. We expect partners to run experiments downstream
from the browser provided treatment and control groups.


Experimental timeline

Previously the feature was approved until M125.  We'd like to
extend the experiment by one milestone to M126 so that we can
continue to support the Chrome Facilitated Testing period until
June 30, 2024. Any experimentation after June 30 will be covered
by another Intent.


Any risks when the experiment finishes?

Minimal. The feature is designed in a way that websites must
feature detect for the web API. This feature is also only
available for a subset of users.


Reason this experiment is being extended

This feature is necessary to support the ongoing Chrome
Facilitated Testing effort

.
The Facilitated Testing period is scheduled to complete on June
30, 2024 which is slightly beyond our previous approval for the
feature.  Therefore we are requesting to extend the experimental
feature access to M126.


Ongoing technical constraints

None


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

No, not supported on webview.


Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264



-- 
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/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%40chromium.org

.



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

Re: [blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

[Daniel Bratell]

LGTM1

/Daniel

On 2024-06-03 18:03, 'David Adrian' via blink-dev wrote:



Contact emails

l...@chromium.org


Explainer

None


Specification

https://wicg.github.io/private-network-access


Summary

We propose to block access to IP address 0.0.0.0 in advance of PNA 
completely rolling out. Chrome is deprecating direct access to private 
network endpoints from public websites as part of the Private Network 
Access (PNA) specification 
(https://developer.chrome.com/blog/private-network-access-preflight/). 
Services listening on the localhost (127.0.0.0/8 ) 
are considered private according to the specification 
(https://wicg.github.io/private-network-access/#ip-address-space-heading). 
Chrome's PNA protection (rolled out as part of 
https://chromestatus.com/feature/5436853517811712) can be bypassed 
using the IP address 0.0.0.0 to access services listening on the 
localhost on macOS and Linux. This can also be abused in DNS rebinding 
attacks targeting a web application listening on the localhost. Since 
0.0.0.0 is not used in practice (and should not be used), but was 
overlooked during https://chromestatus.com/feature/5436853517811712, 
we're deprecating it separately from the rest of the private network 
requests deprecation. This will be a Finch (experimental) rollout, 
rather than a Developer Trial.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




Search tags

security , Private 
Network Access 




TAG review

None


TAG review status

Not applicable


Chromium Trial Name

PrivateNetworkAccessNullIpAddressAllowed


Origin Trial documentation link

https://crbug.com/1300021


WebFeature UseCounter name

kPrivateNetworkAccessNullIpAddress


Risks



Interoperability and Compatibility

None



/Gecko/: Closed Without a Position 
(https://github.com/mozilla/standards-positions/issues/143)


/WebKit/: Support 
(https://github.com/WebKit/standards-positions/issues/163)


/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



Goals for experimentation



Ongoing technical constraints

Eventually, all private network access will be limited according to 
the developing Private Network Access spec.




Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

block-null-ip-address


Finch feature name

PrivateNetworkAccessNullIpAddress


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1300021


Estimated milestones

Shipping on desktop 133
Origin trial desktop first  127
Origin trial desktop last   133
DevTrial on desktop 127

Shipping on Android 133
OriginTrial Android last133
OriginTrial Android first   127
DevTrial on Android 127

Shipping on WebView 133
OriginTrial webView last133
OriginTrial webView first   127



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5106143060033536

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/CAGkh42L-7xt9YY-jmq-G4-nuitqELpgqgnvECkbCoPpAWWMMjw%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/683cadae-9413-4125-9209-4ecfe1b812aa%40sarasas.se.

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

[Daniel Bratell]

If so, it's not visible to me. They are all shown as grey, i.e. not 
started. Is there maybe more than one chromestatus entry and the review 
was done somewhere else?


/Daniel

On 2024-06-04 16:20, David Adrian wrote:
> Can you please start (or possibly N/A) the 
Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus?


I believe it already has all the pils approved.

On Tue, Jun 4, 2024 at 3:18 AM Daniel Bratell  wrote:

Can you please start (or possibly N/A) the
Privacy/Security/Enterprise/Debuggability/Testing pills in
Chromestatus?

/Daniel

On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote:

> Can you please elaborate on the analysis: how low is the usage
and how did you check that the use is malware?

The Blink.UseCounter.Feature
for PrivateNetworkAccessNullIpAddress shows

<https://uma.googleplex.com/p/chrome/timeline_v2?sid=a4f412aa940bd3dd7b2bc6c960c2d91d>
below 0.001% on all platforms.

We've had multiple reports of malware leveraging this to attack
specific developer tooling frameworks, e.g.
https://crbug.com/40058874.

> Also, just to confirm, this is an intent to deprecate and
remove but you're planning on rolling out the removal gradually
via finch, right?

Correct.

On Mon, Jun 3, 2024 at 1:25 PM Vladimir Levin
 wrote:



On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev
 wrote:

Chrome Status doesn't generate emails for the deprecation
trails, only developer trials, so I've repurposed that
here. This is a Finch managed rollout, not a developer
opt-in, due to the extremely low usage that seems to be
almost entirely malware.


Can you please elaborate on the analysis: how low is the
usage and how did you check that the use is malware?

Also, just to confirm, this is an intent to deprecate and
remove but you're planning on rolling out the removal
gradually via finch, right?

Thanks!
Vlad


On Mon, Jun 3, 2024 at 12:03 PM David Adrian
 wrote:


Contact emails

l...@chromium.org


Explainer

None


Specification

https://wicg.github.io/private-network-access


Summary

We propose to block access to IP address 0.0.0.0 in
advance of PNA completely rolling out. Chrome is
deprecating direct access to private network
endpoints from public websites as part of the Private
Network Access (PNA) specification

(https://developer.chrome.com/blog/private-network-access-preflight/).
Services listening on the localhost (127.0.0.0/8
<http://127.0.0.0/8>) are considered private
according to the specification

(https://wicg.github.io/private-network-access/#ip-address-space-heading).
Chrome's PNA protection (rolled out as part of
https://chromestatus.com/feature/5436853517811712)
can be bypassed using the IP address 0.0.0.0 to
access services listening on the localhost on macOS
and Linux. This can also be abused in DNS rebinding
attacks targeting a web application listening on the
localhost. Since 0.0.0.0 is not used in practice (and
should not be used), but was overlooked during
https://chromestatus.com/feature/5436853517811712,
we're deprecating it separately from the rest of the
private network requests deprecation. This will be a
Finch (experimental) rollout, rather than a Developer
Trial.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>


Search tags

security
<https://chromestatus.com/features#tags:security>,
Private Network Access

<https://chromestatus.com/features#tags:Private%20Network%20Access>


TAG review

None


TAG review status

Not applicable


Chromium Trial Name

PrivateNetworkAccessNullIpAddressAllowed


Origin Trial documentation link

https://crbug.com/1300021


WebFeature UseCounter name

kPrivateNetworkAccessNullIpAddress


Risks



Interope

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

[Daniel Bratell]

Doh, make that a bonus LGTM4. Sorry for the confusion.

/Daniel

On 2024-06-04 09:29, Daniel Bratell wrote:


LGTM3

/Daniel

On 2024-05-30 19:41, Vladimir Levin wrote:

LGTM2

On Wed, May 29, 2024 at 11:41 AM Mike Taylor  
wrote:


LGTM1

On 5/24/24 3:13 PM, Yoav Weiss (@Shopify) wrote:



On Fri, May 24, 2024 at 7:12 PM Panos Astithas
 wrote:



On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify)
 wrote:



On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify)
 wrote:



On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav
Weiss wrote:

Contact emailsyoavwe...@chromium.org


Explainerhttps://github.com/guybedford/import-maps-extensions#integrity

<https://github.com/guybedford/import-maps-extensions#integrity>

Specificationhttps://github.com/whatwg/html/pull/10269
<https://github.com/whatwg/html/pull/10269>

The PR is ready to land, but we're holding off
on that for 2 weeks at Mozilla's request. See below.

Summary

Imported ES modules can't currently have their
integrity checked, and hence cannot run in
environments that require Subresource Integrity
or with `require-sri-for` CSP directives. This
feature adds an `integrity` section to import
maps, enabling developers to map ES module URLs
to their integrity metadata, and ensure they
only load when they match their expected hashes.



Blink componentBlink>Loader

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>

TAG
reviewhttps://github.com/w3ctag/design-reviews/issues/944
<https://github.com/w3ctag/design-reviews/issues/944>

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

On the interoperability front, this got a
positive position from WebKit, and I'm
implementing the feature there
<https://github.com/whatwg/html/pull/10269>.
Mozilla didn't object to the feature, but asked

<https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>



I just realized that the meeting notes are not publicly
viewable.
+Panos Astithas <mailto:pastit...@google.com> - would
you be able to open them up to the public somehow? (e.g.
as a Chromium.org doc)


They were published

<https://github.com/whatwg/html/issues/10340#:~:text=Benjamin%3A%20I%27d%20like%20a%20further%20two%20weeks>
 that
same day, we try to post the minutes publicly in less than
24 hours.


Oops!! My bad for using the wrong artifact!

for a couple more weeks to evaluate it and
provide a position, as they might be planning
broader-scope work on the front of application
integrity, and want to make sure this doesn't
collide with it.


On the compatibility front, the feature is
polyfilled
<https://github.com/guybedford/es-module-shims/pull/424>,
but it's turned off for browsers that support
import maps

<https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>.


Adding Guy Bedford, the polyfill author to this
thread. Guy, can you confirm this is the case?


/Gecko/: No signal
<https://github.com/mozilla/standards-positions/issues/1010>

/WebKit/: Support
<https://github.com/WebKit/standards-positions/issues/335>

WebKit PR
<https://github.com/WebKit/WebKit/pull/28253> has
landed.



/Web developers/: Positive
<https://x.com/yoavweiss/status/1778067431417954803>
This is based on a proposal from a developer
(Guy Bedford).
Multiple Shopify properties are interested in
this, to enable using ES modules as bundler
output in security sensi

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

[Daniel Bratell]

LGTM3

/Daniel

On 2024-05-30 19:41, Vladimir Levin wrote:

LGTM2

On Wed, May 29, 2024 at 11:41 AM Mike Taylor  
wrote:


LGTM1

On 5/24/24 3:13 PM, Yoav Weiss (@Shopify) wrote:



On Fri, May 24, 2024 at 7:12 PM Panos Astithas
 wrote:



On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify)
 wrote:



On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify)
 wrote:



On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav
Weiss wrote:

Contact emailsyoavwe...@chromium.org


Explainerhttps://github.com/guybedford/import-maps-extensions#integrity



Specificationhttps://github.com/whatwg/html/pull/10269


The PR is ready to land, but we're holding off on
that for 2 weeks at Mozilla's request. See below.

Summary

Imported ES modules can't currently have their
integrity checked, and hence cannot run in
environments that require Subresource Integrity
or with `require-sri-for` CSP directives. This
feature adds an `integrity` section to import
maps, enabling developers to map ES module URLs
to their integrity metadata, and ensure they only
load when they match their expected hashes.



Blink componentBlink>Loader



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


TAG review statusIssues addressed

Risks


Interoperability and Compatibility

On the interoperability front, this got a
positive position from WebKit, and I'm
implementing the feature there
.
Mozilla didn't object to the feature, but asked





I just realized that the meeting notes are not publicly
viewable.
+Panos Astithas  - would you
be able to open them up to the public somehow? (e.g. as a
Chromium.org doc)


They were published


 that
same day, we try to post the minutes publicly in less than 24
hours.


Oops!! My bad for using the wrong artifact!

for a couple more weeks to evaluate it and
provide a position, as they might be planning
broader-scope work on the front of application
integrity, and want to make sure this doesn't
collide with it.


On the compatibility front, the feature is
polyfilled
,
but it's turned off for browsers that support
import maps

.


Adding Guy Bedford, the polyfill author to this
thread. Guy, can you confirm this is the case?


/Gecko/: No signal


/WebKit/: Support


WebKit PR
 has landed.



/Web developers/: Positive

This is based on a proposal from a developer (Guy
Bedford).
Multiple Shopify properties are interested in
this, to enable using ES modules as bundler
output in security sensitive environments. Asking
about this on twitter and mastodon showed that
some developers are interested in this, while
others discount SRI in general.

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

[Daniel Bratell]

LGTM3 for the deprecation in 127. I'd like to hold off on stamping the 
removal approval until later but threatening (well, targetting) removal 
in 129 seems ok.


/Daniel

On 2024-05-31 02:44, Mason Freed wrote:

Thanks for the LGTMs!

On Wed, May 29, 2024 at 7:54 AM Daniel Bratell  wrote:

Deprecating seems fine, especially since it's a relatively new API
and less likely to be used on non-maintained sites, but removal
seems a bit premature even if done slowly. Would it be better to
let it bake a few milestones and see if a scary deprecation
message threatening removal after the summer drives the usage down?

I'm starting to get the feeling that this would be a good idea. The 
Enterprise folks on the chromestatus gate also asked for something 
similar - 3 milestones of warning period before the deprecation.


I'm inclined to just do that - it feels safer, and I don't think 
there's a huge rush to turn this off. Especially with usage going in 
the right direction, instead of further up.


So I've modified the chromestatus 
<https://chromestatus.com/feature/5081733588582400> to show a shipping 
milestone of M129. Does that work? And I'll add a big console error 
starting in M127.



On Wed, May 29, 2024 at 1:22 AM Yoav Weiss (@Shopify) 
 wrote:


Your questions prompted me to take a closer look at the
sample sites still hitting the use counter. I took a close
look at the first 10 entries listed, and I think I found
perhaps where the big drop came from. Of those ten sites,
seven do not use getInnerHTML or getHTML at all. Likely
not coincidentally, all seven are Shopify sites. My guess
would be that Shopify very recently removed its usage of
getInnerHTML?


FWIW, internal code search brought up nothing. It's possible that
this is a 3P app
<https://shopify.dev/docs/apps/build/online-store/theme-app-extensions> that
changed their use. (or that I'm simply failing to find the
relevant change :D)


Thanks for checking that! It's always hard to figure out what happened 
after the fact like this.


The plan to ramp down usage is a good one, although as we
previously discussed in a different thread, it may cause some
debugging challenges for developers. It is worthwhile to also
reach out to some of the developers whose sites you noticed
would throw an exception -- just an FYI email that this
feature is being removed. Given the fairly low usage, readily
available fixes (via getHTML() or possibly innerHTML) and your
commitment to monitor for breakages, this looks good to me.


I might want to tweak this plan now that we're extending by 2/3 
milestones. Maybe now (after console warnings) it makes more sense to 
just disable in one shot?


I'll try to reach out to the sites I noticed.

Thanks,
Mason


/Daniel

On 2024-05-29 10:22, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tue, May 28, 2024 at 11:10 PM Vladimir Levin
 wrote:



On Tue, May 28, 2024 at 12:30 PM Mason Freed
 wrote:



On Mon, May 27, 2024 at 8:15 AM Vladimir Levin
 wrote:


Interoperability and Compatibility

The use counter for getInnerHTML()

(https://chromestatus.com/metrics/feature/timeline/popularity/3874)
peaked at 0.05% of page loads using this function
as of January 2024, and dropped precipitously
toward 0.01% in May, 2024. This is presumably due
to the shipment of its replacement, getHTML().


It's great to see the numbers reduce significantly.
If the numbers are being migrated to getHTML() though
I would have expected

https://chromestatus.com/metrics/feature/timeline/popularity/4781
to grow by ~0.04 percentage points, but that one is
still significantly lower (although growing). Is it
possible that June 1 numbers would show a better
balance? Do you by any chance know when the next data
point is expected to be visible on chromestatus?

I'm also assume people are using a readily available
replacement as opposed to just not using
getInnerHTML, but it would be nice if number
supported that


Great questions. So AFAIK the use counter plot for the
current month is a continuous aggregation. I.e. the
0.0168% I see today (May 28) is as of the 28th, and will
change tomorrow (slightly). Given that we're almost to
the end of the month, I wouldn't expect a ton of shift.
So I think you might be right that this isn't actually a
shift to getHTML, but just a shi

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

[Daniel Bratell]

Can you please start (or possibly N/A) the 
Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus?


/Daniel

On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote:
> Can you please elaborate on the analysis: how low is the usage and 
how did you check that the use is malware?


The Blink.UseCounter.Feature for PrivateNetworkAccessNullIpAddress 
shows 
 
below 0.001% on all platforms.


We've had multiple reports of malware leveraging this to attack 
specific developer tooling frameworks, e.g. https://crbug.com/40058874.


> Also, just to confirm, this is an intent to deprecate and remove but 
you're planning on rolling out the removal gradually via finch, right?


Correct.

On Mon, Jun 3, 2024 at 1:25 PM Vladimir Levin  wrote:



On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev
 wrote:

Chrome Status doesn't generate emails for the deprecation
trails, only developer trials, so I've repurposed that here.
This is a Finch managed rollout, not a developer opt-in, due
to the extremely low usage that seems to be almost entirely
malware.


Can you please elaborate on the analysis: how low is the usage and
how did you check that the use is malware?

Also, just to confirm, this is an intent to deprecate and remove
but you're planning on rolling out the removal gradually via
finch, right?

Thanks!
Vlad


On Mon, Jun 3, 2024 at 12:03 PM David Adrian
 wrote:


Contact emails

l...@chromium.org


Explainer

None


Specification

https://wicg.github.io/private-network-access


Summary

We propose to block access to IP address 0.0.0.0 in
advance of PNA completely rolling out. Chrome is
deprecating direct access to private network endpoints
from public websites as part of the Private Network Access
(PNA) specification

(https://developer.chrome.com/blog/private-network-access-preflight/).
Services listening on the localhost (127.0.0.0/8
) are considered private according to
the specification

(https://wicg.github.io/private-network-access/#ip-address-space-heading).
Chrome's PNA protection (rolled out as part of
https://chromestatus.com/feature/5436853517811712) can be
bypassed using the IP address 0.0.0.0 to access services
listening on the localhost on macOS and Linux. This can
also be abused in DNS rebinding attacks targeting a web
application listening on the localhost. Since 0.0.0.0 is
not used in practice (and should not be used), but was
overlooked during
https://chromestatus.com/feature/5436853517811712, we're
deprecating it separately from the rest of the private
network requests deprecation. This will be a Finch
(experimental) rollout, rather than a Developer Trial.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess




Search tags

security
, Private
Network Access



TAG review

None


TAG review status

Not applicable


Chromium Trial Name

PrivateNetworkAccessNullIpAddressAllowed


Origin Trial documentation link

https://crbug.com/1300021


WebFeature UseCounter name

kPrivateNetworkAccessNullIpAddress


Risks



Interoperability and Compatibility

None



/Gecko/: Closed Without a Position
(https://github.com/mozilla/standards-positions/issues/143)

/WebKit/: Support
(https://github.com/WebKit/standards-positions/issues/163)

/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



Goals for experimentation



Ongoing technical constraints

Eventually, all private network access will be limited
according to the developing Private Network Access spec.

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

[Daniel Bratell]

LGTM2

/Daniel

On 2024-06-04 04:16, TAMURA, Kent wrote:
The test "text-wrap.tentative.html" is tentative because of 
text-wrap:balance and text-wrap:pretty.  I'll do:

- File a spec issue for them, and
- Make a non-tetative test for text-wrap:nowrap.


On Mon, Jun 3, 2024 at 5:57 PM Philip Jägenstedt  
wrote:


LGTM1

This is a change of default behavior, but the previous behavior is
likely very rare and it can be achieved using `text-wrap: nowrap`.

Since the text-wrap part is important for adoption of this, can
you check if text-wrap.tentative.html still needs to be tentative?
The test has a comment about Chrome support, but no link to open
spec issues.

On Fri, May 31, 2024 at 10:49 AM TAMURA, Kent 
wrote:


Contact emails

tk...@chromium.org


Explainer


https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?pli=1#heading=h.acpilydj9j1d


Specification

https://drafts.csswg.org/css-ruby/#break-within


Design docs



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


Summary

Line-breaks are possible within elements with `display: ruby`.
A single pair of a ruby-base and a ruby-text has never been
line-breakable, and it has been pushed to the next line if the
current line had no enough space for the entire pair. Now each
of the ruby-base and the ruby-text can be split into multiple
lines.



Blink component

Blink>Layout>Ruby




Search tags

ruby 


TAG review

None; This is a small behavior change, and there is no API to
cover this behavior.


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Compatibility risk: * Web authors might expect rubies are not
line-breakable. They need to specify `text-wrap: nowrap` or
something to disable line-breaking if they don't want
line-breaking. Interoperability risk: * This would be the
first implementation of the behavior.


 appears in about 0.14% of page views [1].  Rubies with
long content are very rare, and this change will affect much
less than 0.14% page views.

[1]
https://chromestatus.com/metrics/feature/timeline/popularity/576

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

/WebKit/: Support
(https://github.com/WebKit/standards-positions/issues/232) It
seems the latest Safari has implemented line-breakable ruby
partially.

/Web developers/: Positive

(https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?pli=1#heading=h.giqn8tqur4ig)

/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

Existing DevTools functionalities are enough.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/css-ruby/break-within-bases



Flag name on chrome://flags

enable-experimental-web-platform-features


Finch feature name

RubyLineBreakable


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/324111880


Estimated milestones

Shipping on desktop 128
DevTrial on desktop 127

Shipping on Android 128
DevTrial on Android 127

Shipping on WebView 128



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

This 

Re: [blink-dev] Intent to Ship: The ServiceWorker static routing API not condition support

[Daniel Bratell]

LGTM2

/Daniel

On 2024-05-29 10:31, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wednesday, May 29, 2024 at 2:39:02 AM UTC+2 Yoshisato Yanagisawa wrote:



2024年5月28日(火) 0:21 Vladimir Levin :



On Fri, May 24, 2024 at 3:43 AM Yoshisato Yanagisawa
 wrote:

Contact emails

yyanagis...@chromium.org


Explainer

https://github.com/WICG/service-worker-static-routing-api



Specification

https://w3c.github.io/ServiceWorker/#dom-routercondition-not



Design docs


https://docs.google.com/document/d/1B2D8w_2M4j9CZC1VccBOAhfCdiRP3yPCSV5UKKDhU70/edit#heading=h.ns1mpsv4yi7x




Summary

The ServiceWorker static routing API is an API used for
routing the request to the network, the ServiceWorker
fetch handler, or directly looking up from cache, and so
on.  Each route consists of a condition and a source, and
the condition is used for matching the request.


For Chromium implementations, the "or" condition is only
the supported condition.  However, to write the condition
more flexibly, supporting the "not" condition is expected,
which matches the inverted condition inside.



Blink component

Blink>ServiceWorker




TAG review

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



TAG review status

Issues addressed


Risks

Interoperability and Compatibility

No compatibility concerns.

This change just starts supporting the not condition. 
Since existing routes won't have the not condition, adding
the not condition support won't affect any existing router
rules.




Gecko: Positive
(https://github.com/mozilla/standards-positions/pull/894
)


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


Web developers: No signals


Other signals:


Ergonomics

The "not" condition calculates the conditions below and
inverts the result, such calculation may also take a
time.  Also, the element does not run concurrently.
However, the inversion is very quick, and rules should be
sequentially evaluated, it should not be a large
performance risk.



Activation

n/a



Security

This just adds the "not" condition.  I believe the
security risk is low.



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 The debuggability should not be changed by adding the
not condition.  Note that the "not" condition also shows
up in chrome://serviceworker-internals and devtools.



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

Yes

This is a part of the ServiceWorker static routing API. 
There is no reason not enabling the feature in specific
platforms.



Is this feature fully tested by web-platform-tests

?


Yes


https://wpt.fyi/results/service-workers/service-worker/tentative/static-router/static-router-main-resource.https.html?label=experimental=master



* Main resource load should not match the condition with not

* Main resource load should match the condition without not



https://wpt.fyi/results/service-workers/service-worker/tentative/static-router/static-router-subresource.https.html?label=experimental=master

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

[Daniel Bratell]

Deprecating seems fine, especially since it's a relatively new API and 
less likely to be used on non-maintained sites, but removal seems a bit 
premature even if done slowly. Would it be better to let it bake a few 
milestones and see if a scary deprecation message threatening removal 
after the summer drives the usage down?


/Daniel

On 2024-05-29 10:22, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tue, May 28, 2024 at 11:10 PM Vladimir Levin  
wrote:




On Tue, May 28, 2024 at 12:30 PM Mason Freed 
wrote:



On Mon, May 27, 2024 at 8:15 AM Vladimir Levin
 wrote:


Interoperability and Compatibility

The use counter for getInnerHTML()

(https://chromestatus.com/metrics/feature/timeline/popularity/3874)
peaked at 0.05% of page loads using this function as
of January 2024, and dropped precipitously toward
0.01% in May, 2024. This is presumably due to the
shipment of its replacement, getHTML().


It's great to see the numbers reduce significantly. If the
numbers are being migrated to getHTML() though I would
have expected
https://chromestatus.com/metrics/feature/timeline/popularity/4781
to grow by ~0.04 percentage points, but that one is still
significantly lower (although growing). Is it possible
that June 1 numbers would show a better balance? Do you by
any chance know when the next data point is expected to be
visible on chromestatus?

I'm also assume people are using a readily available
replacement as opposed to just not using getInnerHTML, but
it would be nice if number supported that


Great questions. So AFAIK the use counter plot for the current
month is a continuous aggregation. I.e. the 0.0168% I see
today (May 28) is as of the 28th, and will change tomorrow
(slightly). Given that we're almost to the end of the month, I
wouldn't expect a ton of shift. So I think you might be right
that this isn't actually a shift to getHTML, but just a shift
away from getInnerHTML. See more below.

Your questions prompted me to take a closer look at the sample
sites still hitting the use counter. I took a close look at
the first 10 entries listed, and I think I found perhaps where
the big drop came from. Of those ten sites, seven do not use
getInnerHTML or getHTML at all. Likely not coincidentally, all
seven are Shopify sites. My guess would be that Shopify very
recently removed its usage of getInnerHTML?


FWIW, internal code search brought up nothing. It's possible that this 
is a 3P app 
 
that changed their use. (or that I'm simply failing to find the 
relevant change :D)



The real issue is that the remaining three sites *do* still
use getInnerHTML, and all three throw exceptions when the
feature is disabled. I can't perceive anything broken on the
site, but the exception isn't a good sign. A few interesting
tidbits: one of the three does appear to (properly)
feature-detect getInnerHTML() yet an exception is still thrown
that might or might not be related. The other two do not
feature detect, and the exception is clear: "getInnerHTML is
not a function". Very interestingly, none of the three use
getInnerHMTL for anything declarative shadow dom related. They
seem to just be using it as a way to get the innerHTML value.
All three seem to be hand-written JS, so it's possible the
sites were developed on Chrome in the last few years and the
developer didn't notice that they should have done
foo=el.innerHTML instead of foo=el.getInnerHTML().

Given that the use counter is very low (0.01%), I'd still like
to push ahead with this deprecation. The above sites likely
represent interop problems, since they'll break on other
browsers already today. But I'd like to revise my plan:
instead of going immediately to 100% removal, I'd like to use
a slow ramp down over time, to monitor for reported breakage.

Thoughts?


The plan to ramp down usage is a good one, although as we
previously discussed in a different thread, it may cause some
debugging challenges for developers. It is worthwhile to also
reach out to some of the developers whose sites you noticed would
throw an exception -- just an FYI email that this feature is being
removed. Given the fairly low usage, readily available fixes (via
getHTML() or possibly innerHTML) and your commitment to monitor
for breakages, this looks good to me.

LGTM1


Thanks,
Mason


While 

Re: [blink-dev] Intent to Experiment: Keyboard-focusable scroll containers Opt Out

[Daniel Bratell]

That is 7 milestones.

End at 132 inclusive instead?

/Daniel

On 2024-05-28 18:58, Vladimir Levin wrote:

LGTM to experiment from 127 to 133 inclusive

On Tue, May 28, 2024 at 12:54 PM Di Zhang  wrote:

Thanks Mike. Your explanation makes sense and we are good with 6
milestones to start.
We expect the deprecation trial period to be longer to give web
users enough time to adjust, but can request a renewal when the
time comes.

I have updated the Origin Trial period to start on 127 and end on 133.

On Wednesday, May 22, 2024 at 7:00:52 PM UTC-7 Mike Taylor wrote:

Thanks Di - this is a useful clarification.

You can request up to 6 milestones for a Deprecation Trial,
and only need a single LGTM. Renewals are possible, with
sufficient justification.

That said, if you do think that 9 milestones is sufficient for
your needs - that is also possible, but will require 3 LGTMs.
If that is the route you would like to propose, can your let
us know why you think 9 milestones is sufficient, and wouldn't
require a renewal? What outreach or comms plans do you have in
place to ensure that the previously broken sites will be ready
for this change in ~9 months?

Either way, please let us know how many (and which)
milestonesyou are requesting for the deprecation trial.

thanks!
Mike

On 5/13/24 2:27 PM, Di Zhang wrote:


Sorry for missing information! I haven’t created a request
for a Deprecation Trial before, which is what I intended this
to be, and I missed some parts of the process. The
chromestatus is located here, which is for the overall
KeyboardFocusableScrollers feature:
https://chromestatus.com/feature/5231964663578624
. The
origin trial section details why we are requesting a
Deprecation trial for this feature, which I’ve copied below.
I believe this answers the questions I’ve received here, but
please let me know if anything else is missing!

Summary

The feature KeyboardFocusableScrollers changes the
focusability of a scroll container. This feature includes the
following changes:

 *

Scrollers are click-focusable and
programmatically-focusable by default.

 *

Scrollers without focusable children are
keyboard-focusable by default.

This is an important improvement to help make scrollers and
contents within scrollers more accessible to all users.


We attempted to ship the above changes, and found that a
limited number of sites had broken expectations around some
of their components. As a result, we had to unship the
feature to avoid this breakage. However, given the benefits
mentioned above, we’d like to ship this feature again.

To allow more time for the affected sites to migrate their
components, we are requesting a Deprecation Trial. This trial
(called “KeyboardFocusableScrollersOptOut”), when enabled,
will disablethe KeyboardFocusableScrollers feature. To give
adequate time, we’d like to let this deprecation trial run
for 9 months. It might be ok to limit this to 6-months, but
would like the option to extend the depreciation period if
needed.

On Friday, May 10, 2024 at 12:38:47 PM UTC-7 Vladimir Levin
wrote:

On Fri, May 10, 2024 at 2:18 PM Mike Taylor
 wrote:

Is there a chromestatus entry associated with this
intent? There's a lot of information missing from
this Intent (see

https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ
as what is typical) - could you reply with the
missing info?

(Did you use ChromeStatus to generate the email?)

Also note that origin trials can only run for 6
milestones initially (see

https://www.chromium.org/blink/launching-features/#origin-trials)
- or are you requesting a deprecation trial?

FWIW, according to

https://www.chromium.org/blink/launching-features/#deprecation-trial,
deprecation trials also only run for up to 6 milestones
before extensions

On 5/10/24 12:36 PM, Di Zhang wrote:

Contact emails

dizha...@chromium.org

dom-...@google.com


*Experiment Goals*The feature
KeyboardFocusableScrollers changes the focusability
of a a scroll container. This is an important
improvement to help make scrollers and contents
within scrollers 

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate old CSS custom state syntax

[Daniel Bratell]

To be particular about the usage number, it's about a magnitude more 
than our informal limit. That doesn't mean it can't be shipped, but it 
means that we want to be fairly certain that >90% of the users are 
unaffected by the change.


How should I interpret the results from your investigation? That none of 
the 8 investigated sites would be negatively affected?


/Daniel

On 2024-05-22 18:03, Vladimir Levin wrote:



On Tue, May 21, 2024 at 2:20 PM Joey Arhar  wrote:

> Do you know what the breakage looks like

I pushed to make sure that using the old syntax with
CustomStateSet.add() wouldn't throw exceptions when in the new
mode in order to reduce breakage. When websites use the old syntax
after it's removed, they will just have styling differences
because their selectors won't parse anymore.

> or whether this usage is limited to a library/a small set of
large websites or something else?

Based on the analysis that I linked in the previous thread

,
there are some websites which all look very similar which use it,
but they are all hidden behind display:none elements that I had to
manually reveal. There was only one website I found which was
actually using it which has a carousel which has buttons that
didn't work in safari and firefox because CustomStateSet didn't
exist yet.

I don't think there is a popular library which is using the
deprecated syntax.

> Ideally, this is feature detected with some fallback syntax

Websites just have to replace ":--foo" with ":state(foo)", I don't
think any feature detection is necessary. If they are interested
in supporting older browsers, then I don't see why they would have
any interest in looking at whether the deprecated syntax works or
not because the other browsers didn't have it before and neither
did we until a couple years ago.


I meant I hope that existing use is either feature-detected or it's 
using both properties. In either case, it's very easy to fix if 
problems arise since alternate syntax is shipped already in multiple 
browsers.


LGTM1


On Tue, May 21, 2024 at 11:09 AM Vladimir Levin
 wrote:

Hey,

0.04% seems like a fairly sizable number. Do you know what the
breakage looks like or whether this usage is limited to a
library/a small set of large websites or something else?

Ideally, this is feature detected with some fallback syntax


On Tue, May 21, 2024 at 1:39 PM Joey Arhar
 wrote:


Contact emails


jar...@chromium.org


Explainer


None


Specification


https://github.com/whatwg/html/pull/8467


Summary


The CSS custom state pseudo-class is being renamed
from :--foo to :state(foo). The new syntax,
:state(foo), has been enabled by default, and now
we have to deprecate and remove the :--foo syntax.
Gecko and webkit never implemented the old syntax
and they have both shipped the new syntax. We are
currently shipping both the new syntax and the old
syntax at the same time. There have been console
errors and DevTools deprecations for the old
syntax for many milestones already. Previous
thread on this topic:

https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ
The UseCounter is currently at 0.04%

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



Blink component


Blink>HTML>CustomElements




Motivation


The syntax of this feature needs to change in
order to get support from the other browsers and
eventually have interoperable behavior.



Initial public proposal


None


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Websites which are currently using the old syntax
and don't migrate to the new syntax will have CSS
selectors which become invalid which would impact
the styling of their custom elements.



/Gecko/: Positive Firefox has shipped the new syntax

/WebKit/: Positive
 

Re: [blink-dev] Intent to Implement and Experiment: Skip Ad in Picture-in-Picture window

[Daniel Bratell]

Unfortunately it doesn't show up in the API Owner UI/ToDo list and I 
can't directly see how to make it appear. jrobbins, is there anything 
strange with this one? It is very old so it might be different from 
anything done the last couple of years.


/Daniel

On 2024-05-17 22:39, 'Jiaming Cheng' via blink-dev wrote:

Hi team,

This feature was initially proposed and implemented 4 years ago but 
remained disabled due to a lack of practical use cases. Given our 
team's (chromeOS UI team) plan to use this SkipAd action in our 
upcoming project, we are now resending this intent email for LGTMs. 
Please let me know if you have any questions :]


TAG: https://github.com/w3ctag/design-reviews/issues/957
Mozilla: https://github.com/mozilla/standards-positions/issues/1026
Webkit: https://github.com/WebKit/standards-positions/issues/350

Below are the auto generated intent content:
Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org, 
jiami...@chromium.org


ExplainerNone

Specificationhttps://wicg.github.io/picture-in-picture/#media-session

Design docs
https://developers.google.com/web/updates/2019/02/chrome-73-media-updates#skipad
https://github.com/WICG/mediasession/pull/203

Summary

Support the SkipAd media session action. This skipad action allows 
Chrome to show a button in the system media controls or in the PiP window.




Blink componentBlink>Media>PictureInPicture 



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

TAG review statusPending

Chromium Trial NameSkipAd

Link to origin trial feedback 
summaryhttps://github.com/WICG/picture-in-picture/issues


Origin Trial documentation 
linkhttps://wicg.github.io/mediasession/#dom-mediasessionaction-skipad


Risks


Interoperability and Compatibility

None



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

/WebKit/: Positive 
(https://github.com/WICG/mediasession/pull/203#issuecomment-432529816)
And a new one created: 
https://github.com/WebKit/standards-positions/issues/350


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


None



Debuggability

None



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


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


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

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

Sample links
https://googlechrome.github.io/samples/picture-in-picture/skip-ad.html

Estimated milestones
Shipping on desktop
127
Origin trial desktop first
73
Origin trial desktop last
74

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 
Statushttps://chromestatus.com/feature/4749278882824192?gate=4775000754618368


Links to previous Intent discussionsIntent to Experiment: 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/l6sW0G4jzhE

On Sunday, February 10, 2019 at 2:08:11 AM UTC-8 Yoav Weiss wrote:

Still LGTM

On Thu, Feb 7, 2019 at 9:51 PM François Beaufort
 wrote:

After more thoughts, we'd like to extend the original trial to
expire when M75 Stable is cut, instead of M74 Stable cut.
Note that the origin trial didn't start yet.

On Thursday, February 7, 2019 at 2:24:52 PM UTC+1, Yoav Weiss
wrote:

LGTM to experiment

On Mon, Feb 4, 2019 at 8:40 PM François Beaufort
 wrote:

Contact emails

fbea...@chromium.org, mlam...@chromium.org


Explainer


https://github.com/WICG/mediasession/pull/203

Design doc/Spec


https://wicg.github.io/mediasession/#dom-mediasessionaction-skipad

Summary

Show a “Skip Ad” button in Picture-in-Picture window
that websites can be notified when user interact with.

Motivation

Video advertisement model usually consist of pre-roll
ads. Content providers often provide the ability to
skip the ad after a few seconds. The

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Daniel Bratell]

LGTM2

/Daniel

On 2024-05-15 07:13, Domenic Denicola wrote:

LGTM1.

I have a small non-blocking request: update your Chrome Status entry 
to avoid using ClassName.staticMethod() syntax for what appears to be 
an instance method. (See e.g. this related discussion 
 and this bug I filed on 
Chrome Status a year ago 
.) 
This will avoid a confusing experience for web developers when this 
information makes its way into the beta blog post and other documentation.


On Wednesday, May 15, 2024 at 5:49:30 AM UTC+9 Eugene Zemtsov wrote:

By reading an MDN article that I'll update after the launch.

Even now allocationSize() is supposed to be called before copyTo()
anyway, to figure out the size of the buffer for the output. (see
example

1,
example2
)

That's why I don't think that it's an ergonomic burden for
developers.

On Tue, May 14, 2024 at 1:41 PM Mike Taylor
 wrote:

Ergonomics-wise, it does not seem intuitive to use a method
called allocationSize() to feature detect copyTo support, even
if the semantics are the same. Besides a very careful reading
of the spec, how do we expect developers to know about it?

On 5/14/24 4:32 PM, Eugene Zemtsov wrote:

In that discussion Marcos Cáceres asked for a synchronous way
to detect if format conversion is supported.
We have a synchronous call allocationSize()
 that
throws an unsupported error in cases where format conversion
is not supported.
I added a WPT test around it in a recent CL
.

canCopyTo() might be needed if we have more settings in
VideoFrameCopyToOptions
 and
might want to know which part exactly is causing an error.

On Tue, May 14, 2024 at 12:25 PM Mike Taylor
 wrote:

I see that WebKit raised an API concern around
detectability

.
In your reply, you said "we should consider...". Has that
consideration happened, perhaps as follow-up work? :)

On 5/8/24 4:05 PM, Eugene Zemtsov wrote:

This feature has Privacy, Security, Enterprise, and
Debuggability approvals. Webkit gave a positive signal.

Any objections or questions from the API owners?



On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov
 wrote:

I've filed issues for TAG review and firefox and
webkit positions.

>  Have you looked into other platform APIs that
could benefit from being able to explicitly specify
intermediate format hinting and/or transformation?
I don't think this kind of review can be done for
all web APIs by one person. It's up to spec
editors in each area to identify these small changes
that improve dev experience and performance.

For media related things:
- VideoFrame is a versatile tool that can be created
from HTMLOrSVGImageElement, HTMLVideoElement,
HTMLCanvasElement, ImageBitmap,
         OffscreenCanvaswithout a copy. In a way
this change extends variety of export formatsfor all
of them.
  So lots of things can be exported to RGB bitmaps
without a canvas now.
- AudioData has a way to be exported into different
sampling formats.



On Wed, May 1, 2024 at 9:41 AM Mike Taylor
 wrote:

+1. Would you mind also filing gecko and webkit
positions? I expect them to be positive, given
the informal signals you have in the spec PRs
already - but this also lets them know we're
moving ahead with shipping. Thanks - Mike

On 5/1/24 11:51 AM, Alex Russell wrote:

hey Eugene,

This is an exciting an useful addition! Have
you looked into other platform APIs that could
benefit from being able to explicitly specify
intermediate format hinting and/or
transformation? It's a place where (had the TAG
been consulted) I would have expected to see a
  

Re: [blink-dev] Intent to Prototype: Find-in-page highlight pseudos

[Daniel Bratell]

I appreciate that someone is working on this because Chromium has 
atrociously bad search hit highlights. That said, I wonder if it would 
be better fixing Chromium than the web. There are a lot of web pages out 
and this could at best help those with very active ongoing development.


/Daniel

On 2024-05-03 15:27, Delan Azabani wrote:



*Contact emails
*schen...@chromium.org, dazab...@igalia.com


*Explainer

*https://github.com/Igalia/explainers/blob/66623464ba1f2410a130d687116302b4a30b1148/css/find-in-page/README.md




*Specification
*None yet; to be specified in
https://drafts.csswg.org/css-pseudo/#highlight-pseudos



*Summary
*Exposes find-in-page search results to authors as a highlight
pseudo-element, like selections and spelling errors. This
allows authors to change the foreground and background colors
or add text decorations, which can be especially useful if the
UA defaults have insufficient contrast with the page colors or
are otherwise unsuitable.


*Blink component
*Blink>CSS




*Motivation
*Authors would like to customize the highlighted text from
find-in-page to have a style consistent with that of the rest
of the page. In particular, the existing find-in-page
highlights may offer poor contrast, harming accessibility. The
find-in-page highlights may also conflict with other
highlights on the page, such as syntax highlighting.


*Initial public proposal
*https://github.com/w3c/csswg-drafts/issues/3812



*Search tags
*search 


*TAG review
*None


*TAG review status
*Pending


*Risks*


*Interoperability and Compatibility
*None

/Gecko/: Not yet requested

/WebKit/: Not formally requested, but feedback on the CSS WG issue and 
in meetings. Unlikely to implement due to Safari’s unique UI behavior, 
but not opposed to the spec as long as UAs are allowed to parse but 
ignore the pseudo. CSS Working Group discussed and is OK with moving 
forward with prototyping under these conditions.


/Web developers/: Resolve problems with choosing code syntax 
highlighting colors 
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 
; 
Explicit request for the feature How to style/detect highlighted boxes 
generated from browser native search in page - Stack Overflow 
; 
Another use case Confuse browsers in-built "find in page" feature - 
Stack Overflow 



/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


*Is this feature fully tested byweb-platform-tests*

*?
*Not yet; tests will be written during the spec and impl process


*Flag name on chrome://flags
*#enable-experimental-web-platform-features
SearchTextHighlightPseudo


*Finch feature name
*None


*Non-finch justification
*None


*Requires code in //chrome?
*False


*Estimated milestones
*No milestones specified


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


This intent message was generated byChrome 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/c447ed4dfd05b588e2afc650277371fd%40igalia.com 
.


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

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Daniel Bratell]

LGTM3

/Daniel

On 2024-05-15 15:47, Guido Urdaneta wrote:

I just opened access to the doc.

On Wed, May 15, 2024 at 2:57 PM Daniel Bratell wrote:

The document seems to be an internal one. Is there anything you
can share publicly?

/Daniel

On 2024-05-15 07:34, Domenic Denicola wrote:

LGTM2

On Wednesday, May 15, 2024 at 4:47:32 AM UTC+9 Mike Taylor wrote:

Thanks for the doc. It sounds like the design evolved during
the OT based on fedback from the WG, and at least one partner
was satisfied with the shape and functionality.

LGTM1

On 5/14/24 8:05 AM, Guido Urdaneta wrote:

Here is a doc with feedback from the Origin Trial. There
were two registrants reported with a large usage scale. We
received feedback from one of them and will update the doc
if/when we get feedback from the other one.


https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing


On Wed, May 8, 2024 at 5:45 PM Alex Russell
 wrote:

Hey Guido,

This is a cool feature! The Milestones section shows
that an OT was run; is there a summary someplace of what
we learned from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido
Urdaneta wrote:


Contact emails


h...@chromium.org, gui...@chromium.org,
agpa...@chromium.org


Explainer



https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md


Specification



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor


Summary


Allow WebRTC Encoded Transform API to create
encoded audio and video frames specifying
custom metadata. This is achieved by
introducing constructors for encoded frames
that take the original frame and custom
metadata as input. This supports use cases
that involve manipulation of not only the
payload of encoded video / audio frames but
also its metadata. Some examples: * Changing
the mime type of the frame if the transform
changes the type of the payload * Forwarding
of media to a new peer connection set up to
use different metadata values * Altering the
timestamp of a frame to introduce a delay
Use cases:

https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media

https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
https://w3c.github.io/webrtc-nv-use-cases/#auction
Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77



This change has consensus in the WebRTC Working
Group and has been merged into the WebRTC Encoded
Transform spec.


Blink component


Blink>WebRTC

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC>


TAG review


TAG review request for this specific change:
https://github.com/w3ctag/design-reviews/issues/942


The original version of the full spec was
reviewed by TAG here:
https://github.com/w3ctag/design-reviews/issues/531


TAG review status


Pending


Chromium Trial Name


RTCEncodedFrameSetMetadata


Origin Trial documentation link



https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md


WebFeature UseCounter name


RTCEncodedFrameSetMetadata


Risks




Interoperability and Compatibility


Interoperability risk: There is always the
risk that other browsers will not implement
this feature. This risk is mitigated by
alignment across browser vendors in the W3C
WebRTC Working Group around

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Daniel Bratell]

The document seems to be an internal one. Is there anything you can 
share publicly?


/Daniel

On 2024-05-15 07:34, Domenic Denicola wrote:

LGTM2

On Wednesday, May 15, 2024 at 4:47:32 AM UTC+9 Mike Taylor wrote:

Thanks for the doc. It sounds like the design evolved during the
OT based on fedback from the WG, and at least one partner was
satisfied with the shape and functionality.

LGTM1

On 5/14/24 8:05 AM, Guido Urdaneta wrote:

Here is a doc with feedback from the Origin Trial. There were two
registrants reported with a large usage scale. We received
feedback from one of them and will update the doc if/when we get
feedback from the other one.


https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing




On Wed, May 8, 2024 at 5:45 PM Alex Russell
 wrote:

Hey Guido,

This is a cool feature! The Milestones section shows that an
OT was run; is there a summary someplace of what we learned
from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido Urdaneta
wrote:


Contact emails


h...@chromium.org, gui...@chromium.org
,
agpa...@chromium.org 


Explainer



https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md




Specification



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor





https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor




Summary


Allow WebRTC Encoded Transform API to create
encoded audio and video frames specifying custom
metadata. This is achieved by introducing
constructors for encoded frames that take the
original frame and custom metadata as input. This
supports use cases that involve manipulation of
not only the payload of encoded video / audio
frames but also its metadata. Some examples: *
Changing the mime type of the frame if the
transform changes the type of the payload *
Forwarding of media to a new peer connection set
up to use different metadata values * Altering
the timestamp of a frame to introduce a delay
Use cases:

https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media



https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media


https://w3c.github.io/webrtc-nv-use-cases/#auction

Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77




This change has consensus in the WebRTC Working Group and
has been merged into the WebRTC Encoded Transform spec.


Blink component


Blink>WebRTC




TAG review


TAG review request for this specific change:
https://github.com/w3ctag/design-reviews/issues/942



The original version of the full spec was
reviewed by TAG here:
https://github.com/w3ctag/design-reviews/issues/531



TAG review status


Pending


Chromium Trial Name


RTCEncodedFrameSetMetadata


Origin Trial documentation link



https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

[Daniel Bratell]

LGTM2

/Daniel

On 2024-05-08 17:11, Yoav Weiss (@Shopify) wrote:

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org



Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/117



Design docs



https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing




Summary

This makes user activations in a document picture-in-picture
window usable inside its opener window and vice versa. This makes
it more ergonomic to use user-activation-gated APIs, since often
event handlers in the document picture-in-picture window are
actually run in the opener's context, so the opener's context
needs access to the user gesture.



Blink component

Blink>Media>PictureInPicture




TAG review

https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171




TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367

)

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691

)

/Web developers/: No signals

/Other signals/:


Ergonomics

This should improve the ergnomics of user-activation-gated APIs in
document picture-in-picture windows, as the website no longer
needs to ensure that the user gesture occurred in the same context
as the code that is calling the API.



Activation

N/A



Security

One potential risk is that the website could use the same gesture
as two gestures (by using it in the opener and in the
picture-in-picture window). We mitigate this by ensuring that
consuming user activation in one uses it in the other.



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, ChromeOS, Android, and Android WebView)?

No

Document picture-in-picture is only available on desktop platforms



Is this feature fully tested by web-platform-tests

?

Yes

document-picture-in-picture/propagate-user-activation-from-opener.https.html
document-picture-in-picture/propagate-user-activation-to-opener.https.html



Flag name on chrome://flags

document-picture-in-picture-user-activation


Finch feature name

DocumentPictureInPictureUserActivation


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/331246719



Sample links


https://steimelchrome.github.io/document-pip/user-gesture.html



Estimated milestones

Shipping on desktop 126



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 Status

https://chromestatus.com/feature/5185710702460928?gate=5078256593403904



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com



This intent message was generated 

Re: [blink-dev] Intent to Ship: Declarative shadow DOM serialization

[Daniel Bratell]

LGTM2

/Daniel

On 2024-04-10 18:43, Alex Russell wrote:
Ok, so Chris reminded me that we'd already shipped a setter via 
`setHTMLUnsafe()` and that Mozilla has an intent out for this new 
version of the getter, which suggests to me that we should, indeed, 
handle the streams thing separately.


LGTM1.

On Friday, April 5, 2024 at 3:31:10 PM UTC-7 Mason Freed wrote:

Thanks for the comments!

On Fri, Apr 5, 2024 at 8:26 AM Vladimir Levin
 wrote:

I think this is the case, but just to clarify: this is
shipping a new function and not renaming/updating the
previously shipped one, right? So, at least for the time
being, there will be two similar functions shipped


That's correct. This intent ships `getHTML()`. And then (after
some time) this other intent
 will be used
to remove the old `getInnerHTML()` function. But as you said, I'd
like the new one to be available for at least a few milestones to
give folks time to migrate.

On Thu, Apr 4, 2024 at 9:27 PM Alex Russell
 wrote:

Drive-by API design comments:

Was this run past the TAG? Did they ask this is not adding a
way to return a stream? And was there a discussion of a setter
API that supports streams? It would be disappointing if we
added new surface of this sort without resolving the core data
type issues.


So yes, the original declarative shadow DOM feature was submitted
for TAG review
, and its
explainer had a section about `getInnerHTML()`


which is basically the same except for the name. The TAG review
itself has quite a bit of discussion about `getInnerHTML` and
serialization (starting roughly here

)
and doesn't bring up the stream-based API you mention here, which
is too bad.

The original feature shipped in 2020 and this intent represents
the penultimate of a series of about eight chromestatus entries
over 4.5 years to finally get it standardized. I'm really hoping
we can tackle stream based serialization as a separate effort. :-)

Thanks,
Mason

Best,

Alex




Blink component

Blink>DOM>ShadowDOM




Search tags

getHTML ,
declarative shadow dom



TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

This is a new feature, so there should be no compat risks.
And the spec PRs got comments and support from multiple
implementers, so I would expect support coming soon from
other browsers.



/Gecko/: Positive

(https://github.com/whatwg/html/pull/10139#pullrequestreview-1966263347

)

/WebKit/: Neutral
(https://github.com/whatwg/html/pull/10139
) General
comments from annevk@ seem supportive, but no LGTM directly.

/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



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/shadow-dom/declarative?label=master=experimental=gethtml





Flag name on chrome://flags

ElementGetHTML


Finch feature name

ElementGetHTML


Requires code in //chrome?

False


Tracking bug

https://crbug.com/41490936


Estimated milestones

Re: [blink-dev] Intent to Ship: CSS Stepped Value Functions

[Daniel Bratell]

LGTM3

/Daniel

On 2024-04-08 17:37, Mike Taylor wrote:


LGTM2

On 4/8/24 10:41 AM, Yoav Weiss (@Shopify) wrote:
Can you please flip on the "debuggability" review bit in 
chromestatus? (feel free to mark it as "N/A" if you think that's the 
case)


On Mon, Apr 8, 2024 at 4:40 PM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

Thanks for catching us up here!

On Fri, Apr 5, 2024 at 3:53 PM Daniil Sakhapov
 wrote:


Contact emails

sakha...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-values/#round-func


Summary

The stepped-value functions, round(), mod(), and rem(), all
transform a given value according to another "step value".
The round() CSS function returns a rounded number based on a
selected rounding strategy. The mod() CSS function returns a
modulus left over when the first parameter is divided by the
second parameter, similar to the JavaScript remainder
operator (%). The modulus is the value left over when one
operand, the dividend, is divided by a second operand, the
divisor. It always takes the sign of the divisor. The rem()
CSS function returns a remainder left over when the first
parameter is divided by the second parameter, similar to the
JavaScript remainder operator (%). The remainder is the value
left over when one operand, the dividend, is divided by a
second operand, the divisor. It always takes the sign of the
dividend.



Blink component

Blink>CSS




TAG review

None


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

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

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/css-values/round-mod-rem-computed.html
https://wpt.fyi/results/css/css-values/round-mod-rem-invalid.html
https://wpt.fyi/results/css/css-values/round-mod-rem-serialize.html



Flag name on chrome://flags

CSSSteppedValueFunctions


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40253179


Estimated milestones

Shipping on desktop 125
DevTrial on desktop 119

Shipping on Android 125
DevTrial on Android 119

Shipping on WebView 125



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

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/CAH3Z92_-CiZrV1FR4wBuDV2ootDfhgcERNO6%3DB5HGfPwW1aaBA%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 

Re: [blink-dev] Re: Intent to Implement and Ship: OpusEncoderConfig `signal` and `application` parameters

[Daniel Bratell]

LGTM2

/Daniel

On 2024-04-08 17:35, Mike Taylor wrote:


LGTM1

On 4/4/24 2:29 PM, 'Thomas Guilbert' via blink-dev wrote:

The last launch gate approval came in today.

Thanks!

On Wed, Apr 3, 2024 at 11:49 AM Thomas Guilbert 
 wrote:


I agree that this would have been a viable solution, and this was
considered and discussed with the spec editors too [1]. These
Opus flags were originally supposed to be contentHint, but
ultimately it would have only ever been useful for Opus, so it
was decided to keep it in the Opus config.

[1] :
https://github.com/w3c/webcodecs/pull/759#issuecomment-1928349508

On Wed, Apr 3, 2024 at 9:10 AM Daniel Bratell
 wrote:

This may be a bit of a tangent, but we had a discussion about
AV1-only encoder configuration a while back[1][2]. In the end
they elected to have a top level dictionary where some
encoding configuration ended up. I wonder if there is
anything to learn from that process and their choices or if
you consider that orthogonal to this.

/Daniel

[1] AV1:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLH6ViLccGxHZzbCG_ChtSxiG59XoeYMPRqeW1Wk410rg%40mail.gmail.com

[2] ContentHint:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9K9_YmJRFn%3DQBKb0GsETsSFex0DPprMRRpWUWgcvAtbA%40mail.gmail.com


On 2024-03-28 08:43, Yoav Weiss (@Shopify) wrote:

Thanks!

On Wed, Mar 27, 2024 at 10:41 PM Thomas Guilbert
 wrote:

I've flipped all the reviews and will update this thread
when they are all completed.

Thanks!

On Wed, Mar 27, 2024 at 8:25 AM Yoav Weiss (@Shopify)
 wrote:

Hey! Can you flip on the various reviews (privacy,
enterprise, etc) in the chromestatus entry?

On Tuesday, March 26, 2024 at 11:29:53 PM UTC+1
Thomas Guilbert wrote:


Contact emails


tguilb...@chromium.org


Explainer


None


Specification



https://w3c.github.io/webcodecs/opus_codec_registration.html#dom-opusencoderconfig-signal


Summary


`OpusEncoderConfig.signal` and
`OpusEncoderConfig.application` were
recently added to the WebCodecs spec
[1]. Both parameters are mapped directly
to implementation specific encoder
knobs. These allow web authors to
provide hints as to what type of data is
being encoded, and in which context the
data is being used. `signal` can be one
of {"auto", "music", "voice"}. It
configures the encoder for the best
performance in encoding the specified
type of data. `application` can be one
of {"voip", "audio", "lowdelay"}. It
configures the encoder to favor speech
intelligibility, faithful reproduction
of the original input, or minimal
latency. [1] :
https://github.com/w3c/webcodecs/pull/777



Blink component


Blink>Media>WebCodecs

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>


TAG review


None


Why not?




TAG review status


Not applicable


Risks




Interoperability and Compatibility


None



/Gecko/: Positive
(https://github.com/w3c/webcodecs/pull/777)
Spec change approved by Mozilla
representative. For an almost identical
feature, Mozilla said the "request for
standards position" was not warranted,
as they were active spec participants:

https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364

/WebKit/: No signal. Review from WebKit
was requested on the spec change.


Can you ask for official positions? https:

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

[Daniel Bratell]

LGTM3

/Daniel

On 2024-04-08 17:37, Yoav Weiss (@Shopify) wrote:

LGTM2

On Mon, Apr 8, 2024 at 5:36 PM Mike Taylor  wrote:

LGTM1

On 4/3/24 11:05 AM, Daniel Bratell wrote:


Thanks, that clarifies a bit and calms my worries considerably.

/Daniel

On 2024-03-29 14:27, Paul Jensen wrote:

Daniel, I hear your concerns, but I should clarify that this
splitting up of large requests does not do any reassembly or
combining of responses, so sequencing or ordering between
responses is not a concern.  The Key-Value servers answering
the queries are stateless and should have no ability to
associate requests

<https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_trust_model.md#:~:text=the%20return%20value%20for%20each%20key%20will%20be%20based%20only%20on%20that%20key>.

The browser has a number of interest groups or bids that need
their trusted signals fetched.  The browser can make each fetch
individually or in a combined fashion, but each individual
response is only supplied to the corresponding requesters;
responses are not combined for requesters.

On Wed, Mar 27, 2024 at 12:21 PM Daniel Bratell
 wrote:

I can't help thinking about all the problems exposed when
malicious use of Out of Sequence TCP became a thing among
the evil-doers. It turned out that once you split something
up, it's not always easy to put it back together again. It
is a solved problem (but not quite, I found newly discovered
exploits when searching for references) in network layers
but only through a lot of pain and suffering.

There were the things that people with evil intent did, like
sending only part of a sequence, filling up buffers that
were waiting for the rest or reorder in complicated ways, or
make a million small parts instead of one large. Could that
become an attack surface here?

And there were the random reordering that just happened due
to networks being unpredictable which servers were in
general badly equipped to handle. Could reordering happen here?

Either way, I worry that this could become a source of
random problems that would be hard to understand or debug.
Is there any third or fourth option to consider?

/Daniel

On 2024-03-25 17:44, 'Paul Jensen' via blink-dev wrote:



On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify)
 wrote:



On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 wrote:


Contact emails

pauljen...@chromium.org


Explainer

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1070
<https://github.com/WICG/turtledove/pull/1070>

deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1069
<https://github.com/WICG/turtledove/pull/1069>


Specification

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1065
<https://github.com/WICG/turtledove/pull/1065>

deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1051
<https://github.com/WICG/turtledove/pull/1051>


Summary

These are the changes to Protected Audience that
we’d like to ship:


Split up large trusted signals fetches:

During Protected Audience auctions the browser
fetches real-time signals from buyers' and sellers'
key-value servers. These fetches are currently HTTP
GET requests with URLs that the browser assembles
by concatenating several individual requests
together. The URLs can grow larger than some HTTP
servers support resulting in failing requests and
reduced website ad revenue. The proposal here is
for buyers and sellers to specify the maximum size
of these URLs and for the browser to split large
requests into chunks no larger than the specified
maximum size.


If I understand correctly what y'all are trying to do
here, you're trying to effectively recreate with GETs
what should've been a POST.
Is the reasoning for that outlined somewhere?

POSTs have many advantages over GETs when transferring
large amounts of data to the server. Most importantly,
they tend to actually pass through. Beyond that, the
data is not typically saved to logs (whereas URLs o

Re: [blink-dev] Re: Intent to Implement and Ship: OpusEncoderConfig `signal` and `application` parameters

[Daniel Bratell]

This may be a bit of a tangent, but we had a discussion about AV1-only 
encoder configuration a while back[1][2]. In the end they elected to 
have a top level dictionary where some encoding configuration ended up. 
I wonder if there is anything to learn from that process and their 
choices or if you consider that orthogonal to this.


/Daniel

[1] AV1: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLH6ViLccGxHZzbCG_ChtSxiG59XoeYMPRqeW1Wk410rg%40mail.gmail.com


[2] ContentHint: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9K9_YmJRFn%3DQBKb0GsETsSFex0DPprMRRpWUWgcvAtbA%40mail.gmail.com



On 2024-03-28 08:43, Yoav Weiss (@Shopify) wrote:

Thanks!

On Wed, Mar 27, 2024 at 10:41 PM Thomas Guilbert 
 wrote:


I've flipped all the reviews and will update this thread when they
are all completed.

Thanks!

On Wed, Mar 27, 2024 at 8:25 AM Yoav Weiss (@Shopify)
 wrote:

Hey! Can you flip on the various reviews (privacy, enterprise,
etc) in the chromestatus entry?

On Tuesday, March 26, 2024 at 11:29:53 PM UTC+1 Thomas
Guilbert wrote:


Contact emails


tguilb...@chromium.org


Explainer


None


Specification



https://w3c.github.io/webcodecs/opus_codec_registration.html#dom-opusencoderconfig-signal


Summary


`OpusEncoderConfig.signal` and
`OpusEncoderConfig.application` were recently
added to the WebCodecs spec [1]. Both parameters
are mapped directly to implementation specific
encoder knobs. These allow web authors to provide
hints as to what type of data is being encoded,
and in which context the data is being used.
`signal` can be one of {"auto", "music", "voice"}.
It configures the encoder for the best performance
in encoding the specified type of data.
`application` can be one of {"voip", "audio",
"lowdelay"}. It configures the encoder to favor
speech intelligibility, faithful reproduction of
the original input, or minimal latency. [1] :
https://github.com/w3c/webcodecs/pull/777



Blink component


Blink>Media>WebCodecs




TAG review


None


Why not?




TAG review status


Not applicable


Risks




Interoperability and Compatibility


None



/Gecko/: Positive
(https://github.com/w3c/webcodecs/pull/777) Spec
change approved by Mozilla representative. For an
almost identical feature, Mozilla said the
"request for standards position" was not
warranted, as they were active spec participants:

https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364

/WebKit/: No signal. Review from WebKit was
requested on the spec change.


Can you ask for official positions? https://bit.ly/blink-signals



/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



Debuggability




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


Yes


Is this feature fully tested by web-platform-tests

?


Yes

Existing WPTs will be modified to cover this
feature:

https://wpt.fyi/results/webcodecs/audio-encoder-config.https.any.html



Flag name on chrome://flags


None


Finch feature name


None


Non-finch justification


Simple parameter changes.



Requires code in //chrome?


False


Estimated milestones


Shipping on desktop 125

  

Re: [blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Daniel Bratell]

LGTM2

/Daniel

On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote:

LGTM1

The signals from other vendors and the CG discussion seem encouraging 
and I agree that the future risk from an "all" value is probably 
outweighed by its developer-facing benefits.


On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula  
wrote:


I'd guess that, in the future, the semantics around 'all' may
change in one of two ways:

(A) If storage methods included are deprecated, (1) we would start
warning developers via a DevTools issue when they use 'all', (2)
we would start requiring the deprecated method was specifically
included in the call to rSA rather than it being automatically
included in all, (3) the storage method would be removed from rSA.
The timeline for this would likely be rather long (alongside the
timeline for the deprecation of the storage method itself).

(B) If a new storage method were proposed, (1) we would allow
developers to use it if explicitly included in rSA (but not add it
via all) and then (2) add it under 'all' once it had fully launched.

The chances of a new storage method being added we (1) do want in
rSA but (2) wouldn't ever want under 'all' is low I think. All of
the storage/communication mechanisms besides local/session storage
either have async APIs or don't expose events to monitor changes
that would require full loading of data simply because the
handle/constructor was made available. I agree there is a
potential for a footgun here, but given the direction these APIs
seem to be heading I don't think the risk is high. What are the
chances vendors decide to add new storage mechanisms that are
loaded at document initialization with all data synchronously
available?

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify)
 wrote:



On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula
 wrote:

I think the last place it came up was in this thread:

https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352


I think it came up at TPAC, but I might me missing the
right line:

https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302

Either way, there hasn't been further concern raised
recently so we moved forward with 'all' since the function
is async (the delay from loading local/session storage
isn't high, and it was often already loaded given the
requirement to have interacted with the iframe's site in a
top-level context in the past).


The only concern I may have on the "all" front is related to
changing semantics. How likely are we to add future storage
mechanisms that users would not want to expose along with
current ones?


~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify)
 wrote:



On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari
Chivukula wrote:

Contact emails

aric...@chromium.org
,
wanderv...@chromium.org
,
johann...@chromium.org
,
rosh...@google.com 


Specification

https://privacycg.github.io/saa-non-cookie-storage/



Design Doc


https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit




Feedback

https://github.com/privacycg/saa-non-cookie-storage/issues



Intent to Prototype


https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0




Intent to Experiment


https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s




https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw




Summary

This launches the proposed extension of the
Storage Access API

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

[Daniel Bratell]

Thanks, that clarifies a bit and calms my worries considerably.

/Daniel

On 2024-03-29 14:27, Paul Jensen wrote:
Daniel, I hear your concerns, but I should clarify that this splitting 
up of large requests does not do any reassembly or combining of 
responses, so sequencing or ordering between responses is not a 
concern.  The Key-Value servers answering the queries are stateless 
and should have no ability to associate requests 
<https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_trust_model.md#:~:text=the%20return%20value%20for%20each%20key%20will%20be%20based%20only%20on%20that%20key>. 

The browser has a number of interest groups or bids that need their 
trusted signals fetched.  The browser can make each fetch individually 
or in a combined fashion, but each individual response is only 
supplied to the corresponding requesters; responses are not combined 
for requesters.


On Wed, Mar 27, 2024 at 12:21 PM Daniel Bratell  
wrote:


I can't help thinking about all the problems exposed when
malicious use of Out of Sequence TCP became a thing among the
evil-doers. It turned out that once you split something up, it's
not always easy to put it back together again. It is a solved
problem (but not quite, I found newly discovered exploits when
searching for references) in network layers but only through a lot
of pain and suffering.

There were the things that people with evil intent did, like
sending only part of a sequence, filling up buffers that were
waiting for the rest or reorder in complicated ways, or make a
million small parts instead of one large. Could that become an
attack surface here?

And there were the random reordering that just happened due to
networks being unpredictable which servers were in general badly
equipped to handle. Could reordering happen here?

Either way, I worry that this could become a source of random
problems that would be hard to understand or debug. Is there any
third or fourth option to consider?

/Daniel

On 2024-03-25 17:44, 'Paul Jensen' via blink-dev wrote:



On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify)
 wrote:



On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 wrote:


Contact emails

pauljen...@chromium.org


Explainer

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1070
<https://github.com/WICG/turtledove/pull/1070>

deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1069
<https://github.com/WICG/turtledove/pull/1069>


Specification

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1065
<https://github.com/WICG/turtledove/pull/1065>

deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1051
<https://github.com/WICG/turtledove/pull/1051>


Summary

These are the changes to Protected Audience that we’d
like to ship:


Split up large trusted signals fetches:

During Protected Audience auctions the browser fetches
real-time signals from buyers' and sellers' key-value
servers. These fetches are currently HTTP GET requests
with URLs that the browser assembles by concatenating
several individual requests together. The URLs can grow
larger than some HTTP servers support resulting in
failing requests and reduced website ad revenue. The
proposal here is for buyers and sellers to specify the
maximum size of these URLs and for the browser to split
large requests into chunks no larger than the specified
maximum size.


If I understand correctly what y'all are trying to do here,
you're trying to effectively recreate with GETs what
should've been a POST.
Is the reasoning for that outlined somewhere?

POSTs have many advantages over GETs when transferring large
amounts of data to the server. Most importantly, they tend to
actually pass through. Beyond that, the data is not typically
saved to logs (whereas URLs often are). Finally, in theory
POST request bodies could be compressed, although that's
rarely used in practice.


You make good points about POST vs GET usage here, and we agree
with most of them.  We in fact announced our plans to transition
the Protected Audience trusted signals fetches to POST and add
compression

<https://github.com/WICG/turtledove/commit/d58a984d9088978b9ee9012a8ab869addfea2d1a>more
than a year ago in our version 2 of the API.  GET,

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Daniel Bratell]

umping out at me.

Cheers,
Adam

On Mon, 26 Apr 2021 at 21:54, 'Grant Wang'
via blink-dev  wrote:

Hi all,

It’s been roughly nine months since we
first utilized Scroll To Text Fragment in
featured snippets in Google Search. In
that time, we’ve seen that Scroll To Text
Fragment links help us towards our goal
to get users the information they need. 
In particular:

 1. We find that Scroll To Text Fragment
links increase engagement -- users
are less likely to visit a page and
then quickly hit the back button,
because they can more readily
understand how relevant the page is
to their search after arriving at the
page.

 2. In user surveys, we find that users
prefer being scrolled to the relevant
section of a page that’s in a
featured snippet. Users who were
scrolled to the relevant section
preferred the experience at a rate of
2:1; even users who were not scrolled
in the control group preferred the
option of being scrolled to the
relevant section at the same 2:1 rate.

Besides their usage on Google Search,
we’ve noticed scroll to text fragments
links during our crawls of the web.  One
of the best use cases has been wikipedia
citations.  For instance, citation 9

<https://en.wikipedia.org/wiki/Melbourne_Cup_%28greyhounds%29#:~:text=%22How%20the%20Cup%20Was%20Won%22.%20Sandown%20Greyhounds.%20Retrieved%2017%20March%202021.>
on this page:

https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds)
provides the detailed attribution to the
fastest-ever time at the Melbourne Cup.

Cheers,
Grant
On Thursday, December 12, 2019 at
12:24:40 PM UTC-8 sligh...@chromium.org
wrote:

LGTM4


On Thursday, December 12, 2019 at
    12:17:49 PM UTC-8, Daniel Bratell wrote:

LGTM3

/Daniel


On Thursday, 12 December 2019
19:45:38 UTC+1, Chris Harrelson
wrote:

LGTM2

On Wed, Dec 11, 2019 at 10:27
PM Yoav Weiss 
wrote:

LGTM1


On Wed, Dec 11, 2019,
22:03 Nick Burris
 wrote:

Hi all,

We feel that we're
now in good shape for
shipping. We have
addressed all of the
shipping blockers
that I listed in my
previous email, and
the corresponding
implementation
changes have landed
in Chrome. We're
still continuing to
make improvements to
the spec,
functionality, and
web platform tests
 

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

[Daniel Bratell]

I can't help thinking about all the problems exposed when malicious use 
of Out of Sequence TCP became a thing among the evil-doers. It turned 
out that once you split something up, it's not always easy to put it 
back together again. It is a solved problem (but not quite, I found 
newly discovered exploits when searching for references) in network 
layers but only through a lot of pain and suffering.


There were the things that people with evil intent did, like sending 
only part of a sequence, filling up buffers that were waiting for the 
rest or reorder in complicated ways, or make a million small parts 
instead of one large. Could that become an attack surface here?


And there were the random reordering that just happened due to networks 
being unpredictable which servers were in general badly equipped to 
handle. Could reordering happen here?


Either way, I worry that this could become a source of random problems 
that would be hard to understand or debug. Is there any third or fourth 
option to consider?


/Daniel

On 2024-03-25 17:44, 'Paul Jensen' via blink-dev wrote:



On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) 
 wrote:




On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 wrote:


Contact emails

pauljen...@chromium.org


Explainer

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1070


deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1069



Specification

Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1065


deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1051



Summary

These are the changes to Protected Audience that we’d like to
ship:


Split up large trusted signals fetches:

During Protected Audience auctions the browser fetches
real-time signals from buyers' and sellers' key-value servers.
These fetches are currently HTTP GET requests with URLs that
the browser assembles by concatenating several individual
requests together. The URLs can grow larger than some HTTP
servers support resulting in failing requests and reduced
website ad revenue. The proposal here is for buyers and
sellers to specify the maximum size of these URLs and for the
browser to split large requests into chunks no larger than the
specified maximum size.


If I understand correctly what y'all are trying to do here, you're
trying to effectively recreate with GETs what should've been a POST.
Is the reasoning for that outlined somewhere?

POSTs have many advantages over GETs when transferring large
amounts of data to the server. Most importantly, they tend to
actually pass through. Beyond that, the data is not typically
saved to logs (whereas URLs often are). Finally, in theory POST
request bodies could be compressed, although that's rarely used in
practice.


You make good points about POST vs GET usage here, and we agree with 
most of them.  We in fact announced our plans to transition the 
Protected Audience trusted signals fetches to POST and add compression 
more 
than a year ago in our version 2 of the API.  GET, however, has the 
huge advantage of facilitating HTTP caching in the browser while it’s 
proving very complicated to architect and implement caching for the 
trusted signals fetches when POST is used.  We’re making good progress 
towards this new caching and protocol version 2, but it’s going to 
take more time, so splitting up trusted signals fetches is necessary 
until version 2 is ready.



deprectedReplaceInURN via auction config:

Protected Audience ad selection auctions return an opaque URN
or FencedFrameConfig that can be used to display the selected
ad creative. To facilitate adoption, until at least 2026, we
agreed to support an API called deprecatedReplaceInURN() that
allows replacing macros in the ad creative URL with
information from the page where the ad will be displayed. This
is useful for better supporting video ads, some brand safety
checks, and other use cases. Today, this API’s ergonomics are
not great for component sellers (i.e. sellers other than the
top-level seller). We're making it possible for all component
sellers to be able to specify macro replacements in their
auction configs.


Blink component

Blink>InterestGroups

Re: [blink-dev] Intent to Extend Deprecation Trial: Removal of X-Requested-With in WebView

[Daniel Bratell]

This being beyond the normal scope of an extension will require three 
LGTMS so here is the first one:


LGTM1

I appreciate that it's not optimal in any way to have something like 
this running this long, but I sympathize with the end result and 
understand that App developers can need both longer to develop and 
especially longer to deploy to all users. That as many as 10k 
applications have adapted the new API is a good sign too.


If I were going to ask for anything else (which might make it easier for 
others to approve it), it would be proof that usage is dropping so that 
we won't have to extend it again.


/Daniel

On 2024-03-27 12:15, Peter Birk Pakkenberg wrote:


Hello Blink-dev.


I would like to extend the ‘X-Requested-With in WebView Deprecation’ 
trial until M138 in line with the premise made below in the Summary 
below. I am asking for an extension of 12 milestones instead of the 
customary 6 
to 
avoid undue churn for the almost 100 origins that have signed up for 
the trial, as we expect that it will take at least another year to 
address the remaining use cases.



The feature is currently disabled on 5% of stable traffic, and we have 
developed the Android WebView Media Integrity API 
as 
a solution for uses of the header for media content providers. We have 
also launched an Android API for app developers to enable the header 
for select origins 
which 
has been adopted by almost 10k applications so far. This is an 
alternative available to Android apps that only display Web content 
they trust. We are still looking to address further use cases in the 
anti-abuse and anti-fraud space before we can fully disable the header.




Contact emails

pb...@google.com


Explainer

None


Specification

None


Summary

Removes the default X-Requested-With header from HTTP requests made by 
WebView.



The X-Requested-With header is set by WebView, with the package name 
of the embedding apk as the value. This use of the header will be 
discontinued.



Developers who rely on this header can sign up for a deprecation 
origin trial [1] to continue to receive the header during the 
deprecation period.



The deprecation origin trial will be extended until replacement APIs 
are available to address use cases of the header, as explained in this 
Android Developer Blog Post [2]



[1]:https://developer.chrome.com/origintrials/#/view_trial/1390486384950640641 



[2]:https://android-developers.googleblog.com/2023/02/improving-user-privacy-by-requiring-opt-in-to-send-x-requested-wih-header-from-webview.html 





Blink component

Mobile>WebView 




Search tags

Headers 


TAG review



TAG review status

Not applicable


Chromium Trial Name

WebViewXRequestedWithDeprecation


Link to origin trial feedback summary

https://docs.google.com/document/d/e/2PACX-1vR-ZraJ4sDSGpo2mhye1c2Z1HOl8ZqQ2iDnT2TCQ-Mj1cS1_-2OzN0OeV0Ctayu9Sm6XejgZmwXVDqE/pub 





Origin Trial documentation link

https://docs.google.com/document/d/e/2PACX-1vSSTEsHVfTXwOW80Tqy4c5TW6wSnt9b8v7-ZWUF3ZqLDs03EatEuyPCqwaUaa2s0a7mFm3Wh61bgVoz/pub 




Risks



Interoperability and Compatibility



Gecko: N/A


WebKit: N/A


Web developers: The X-Requested-With header is widely used for both 
anti-fraud and application allowlisting use cases, despite its 
inherent unreliability. These web services are concerned about the 
removal of the header without replacement technologies to facilitate 
their current reasons for consuming the header.



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?


This feature removes a header sent by default by WebView. It should 
have no direct impact on applications using WebViews, but sites loaded 
in the WebView will no longer receive the X-Requested-With header 
unless the app explicitly allowlist the site[1] to receive the header 
or the 

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

[Daniel Bratell]

LGTM3

/Daniel

On 2024-03-27 16:16, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tuesday, March 26, 2024 at 7:25:13 PM UTC+1 Akash Nadan wrote:

Hi Yoav, the reasoning behind this change is that there is a
privacy gap with the current attribution flow and position of the
source deactivation logic. The current position of the source
deactivation logic makes it possible for API callers to identify
when a source is noise (versus a real source) in certain
scenarios. Additional details/example in this Github issue:
https://github.com/WICG/attribution-reporting-api/issues/842


Regarding the implications, an ad-tech may get different reports
in some circumstances (or no report where they previously would
have gotten one) which may have implications when they are
comparing these reports to other mechanisms they may be using for
conversion measurement. They may see a slight difference in those
comparisons, although given that this scenario is rare, it may not
cause any issues or change in comparison.

Let me know if you have any other questions.


Thanks for the explanation. I'd consider this a (barely) web-exposed 
bug fix.



Thanks,
Akash

On Tuesday, March 26, 2024 at 10:54:02 AM UTC-7 Yoav Weiss
(@Shopify) wrote:

On Tuesday, March 19, 2024 at 12:18:00 AM UTC+1 Akash Nadan wrote:

Contact emails

akash...@google.com, lin...@chromium.org, john...@chromium.org


Explainer

Attribution Reporting with event-level reports



Attribution Reporting API with Aggregatable Reports



Aggregation Service for the Attribution Reporting API




Specification

https://wicg.github.io/attribution-reporting-api/



Blink component

Internals > AttributionReporting




Summary

We are landing the following changes to the Attribution
Reporting API focused on:

 *

additional debugging capabilities by supporting
parsing failure debug reports

 *

improving API ergonomics by supporting a field to
specify preferred registration platform

 *

improving privacy


Explainer/Spec changes

 1. Response header errors debug reports

 2. Supporting preferred platform for cross app
attribution

 3. Move source deactivation step after top level filter
matching


Can you provide more details on the reasoning and implications
of (3)? A lack of explainer or details on the PR itself make
it somewhat of an opaque change..


Risks
Interoperability and Compatibility

(1
)
Header errors debug reports and (2
)
preferred platform are both fully backwards compatible
changes and are optional features.  (3
)
The source deactivation change has very low compatibility
risk because it does not require any developer changes and
only results in ad techs getting different reports in
cases where a user had multiple interactions across
different ads when rate limits in the API are hit, which
should be very rare.

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

The attribution reporting feature bundle will be supported
on all platforms with the exception of Android WebView


Is this feature fully tested by web-platform-tests

?


Yes


Estimated milestones

This feature bundle is anticipated to ship as part
ofChrome 124 

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

[Daniel Bratell]

LGTM3

/Daniel

On 2024-03-20 23:54, Mike Taylor wrote:


LGTM2. Good luck!

On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Mar 20, 2024 at 8:35 PM David Adrian  wrote:

> What's our plan to mitigate that risk? Slow rollout? Enterprise
policy? Both? Something else entirely?

We also worked with a variety of vendors to fix incompatibilities
that were brought to our attention, including Vercel, ZScaler,
and PayPal CN (who have all since patched prior to any level of
stable deployment).

> I'll LGTM once the review gates are flipped

Ack.
On Wednesday, March 20, 2024 at 1:58:33 AM UTC-4
yoav...@chromium.org wrote:

On Tue, Mar 19, 2024 at 10:23 PM David Benjamin
 wrote:

> I'm guessing we're talking about MITM middleboxes, is
that correct?
> What's our plan to mitigate that risk? Slow rollout?
Enterprise policy? Both? Something else entirely?

Whether the middlebox MITMs the TLS connection is not
terribly important. As long as they attempt to parse the
ClientHello, they will need to handle the larger
ClientHellos. They already do in that there's nothing
stopping session tickets, etc., making the ClientHello
large already, but Kyber makes it more likely.

We have already done a slow rollout. This has been
running on 10% stable for several months now, and so far
things seem to be fine. Some initial compat problems, but
largely fixed now. We're far, far, /far/ past the point
that there's nothing more we can smoke out without
proceeding to 100%.

And, yeah, the plan to mitigate the remaining risk is an
enterprise policy, PostQuantumKeyAgreementEnabled, that
admins can set while their middlebox vendors become
post-quantum-ready. The admin policy has been in place
for quite some time now, and has been communicated in
enterprise release notes. Also the presence of any such
incompatibility on an enterprise network blocks
/any/ deployment of post-quantum algorithms, so
ultimately the middleboxes will just need to get fixed.
The various ecosystem pressures towards getting to
post-quantum are particularly strong in enterprise
anyway, so hopefully admins will be more likely to
understand why it's important for them to fix those.

https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled


Makes sense, thanks!!

I'll LGTM once the review gates are flipped.


On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify)
 wrote:



On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via
blink-dev  wrote:


Contact emails

dad...@google.com


Explainer


https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Specification


https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Summary

Protect current Chrome TLS traffic against future
quantum cryptanalysis by deploying the Kyber768
quantum-resistant key agreement algorithm. This
is a hybrid X25519 + Kyber768 key agreement based
on an IETF standard. This specification and
launch is outside the scope of W3C. This key
agreement will be launched as a TLS cipher, and
should be transparent to users.

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html



Blink component

Internals>Network>SSL




Search tags

tls ,
kem ,
kyber
,
postquantum



TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Post-quantum secure ciphers are larger than
classical ciphers. This may cause compatibility
issues with middleboxes.


I'm guessing we're talking about 

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

[Daniel Bratell]

(resending to list)

LGTM2 to go directly to removal (with a flag of course). Also, keep an 
eye on enterprise feedback since they are a blind area.


I took a look at code in github, and there was mostly just 
documentation, including the Portuguese chrome.com, and I also saw a 
page from someone named mfreednumber. Hmm.


/Daniel

On 2024-03-20 17:53, Philip Jägenstedt wrote:

LGTM1 to remove without deprecation

I looked through all 24 sites listed in 
https://chromestatus.com/metrics/feature/timeline/popularity/4455. 23 
of them are the code from client-shim.js minified in various ways, and 
one site no longer has includeShadowRoots.


On Wed, Mar 20, 2024 at 5:11 PM Mike Taylor  
wrote:


On 3/19/24 6:51 PM, Mason Freed wrote:




On Tue, Mar 19, 2024 at 1:44 PM Mike Taylor
 wrote:

Hi Mason,

Would you mind requesting reviews for the various shipping
gates (privacy, security, enterprise, etc.) in your
chromestatus entry?


Definitely! But I only need to do that before I ship this, right?
I.e. not required yet, while I’m just deprecating but not yet
removing the feature?

We discussed this in our owners meeting today, and we think it's
probably useful to go ahead and do that now - Enterprise in
particular would probably be very interested in knowing about a
deprecation. And for the rest if you think they're N/A, it's not
much work to request that.



On 3/15/24 6:49 PM, Mason Freed wrote:



Contact emails


mas...@chromium.org


Explainer


None


Specification


https://github.com/whatwg/html/pull/10139


Summary


The includeShadowRoots argument was a
never-standardized argument to the
DOMParser.parseFromString() function, which was
there to allow imperative parsing of HTML content
that contains declarative shadow DOM. This was
shipped in M90 [1] as part of the initial shipment
of declarative shadow DOM. Since the standards
discussion rematerialized in 2023, the shape of DSD
APIs changed, including this feature for imperative
parsing. (See [2] for more context on the standards
situation and recent changes, and see [3] and [4]
for other related deprecations.) Now that a
standardized version of this API, in the form of
setHTMLUnsafe() and parseHTMLUnsafe() will ship in
M124 ([5]), the non-standard includeShadowRoots
argument needs to be deprecated and removed. All
usage should shift accordingly: Instead of: (new

DOMParser()).parseFromString(html,'text/html',{includeShadowRoots:
true}); this can be used instead:
document.parseHTMLUnsafe(html); [1]
https://chromestatus.com/feature/5191745052606464
[2]
https://chromestatus.com/feature/5161240576393216
[3]
https://chromestatus.com/feature/5081733588582400
[4]
https://chromestatus.com/feature/6239658726391808
[5] https://chromestatus.com/feature/6560361081995264



Blink component


Blink>DOM>ShadowDOM




Motivation


Now that there is a standardized version of this
API, it makes sense to remove the non-standard,
Chrome-only version of the API.



Initial public proposal


None


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Because this is a removal of an API, there is some
compat risk if sites use the API without feature
detection. Additionally, feature detection is a bit
difficult for this feature directly, and typical
usage would instead feature-detect the old
`shadowroot` attribute. In that case, there should
be no breakage, since that attribute has since been
removed. The use counter [1] for this feature has
unfortunately had a recent spike in usage, peaking
at just over 0.01% of page loads as of March, 2024.
However, I analyzed 8 of the top sites, and 8 of 8
are due to the exact same code snippet, from
AstroJS/Lit [2]. And that code amounts to feature
detection, which as-written will properly detect the
  

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Daniel Bratell]

LGTM3

I'm also a bit concerned with the risk, but it sounds like you have it 
under control and will be able to handle the rollout appropriately.


/Daniel

On 2024-03-18 07:42, Yoav Weiss (@Shopify) wrote:

LGTM2 actually..

On Mon, Mar 18, 2024 at 7:40 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1 to ship the ID assertion endpoint CORS requirements.

On Wed, Mar 13, 2024 at 3:11 PM Nicolás Peña  wrote:


On Wednesday, March 13, 2024 at 7:37:29 AM UTC-4 Yoav Weiss wrote:

On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás
Peña wrote:

Regarding risk: we are going to implement this and
test the IDPs we know are currently using FedCM, but
we do not anticipate them to break since they are
currently already relying on using third-party cookies
in iframes. We also plan to have developer
outreach/blogpost for this change so developers
currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with
Firefox and Apple to align on the correct behavior of
the FedCM fetches: see
https://github.com/fedidcg/FedCM/issues/320
 and
https://github.com/fedidcg/FedCM/issues/428
. This
I2S is a result of a lot of discussions, and the small
addition was a result of a very recent discussion
occurring on our FedCM CORS breakout session

.

Regarding spec, during our breakout Anne also
mentioned that the small addition is not possible to
specify properly, as it depends on the ongoing cookie
layering work. I will add a note
 on the
spec in that fetch so IDPs know which cookies should
be sent.

Anyways, I understand it is a bit late to add
something to this I2S so if you prefer that we send a
separate I2S/PSA for the SameSite change, we can do
that instead.


Is the accounts endpoint the same endpoint to which this
intent applies? Or is it different from the ID assertion
endpoint?
If it's different, a separate I2S would be best. If it's
the same, then I think we can probably fold it into this
intent.


This change is to the ID assertion endpoint, which is
different from the accounts endpoint. Then based on your
comment, we will keep those two in separate intents. Consider
the small addition I suggested above removed.



On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike
Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:


Thanks for the suggestion, Yoav! It seems
something fetch experts have some concerns about,
so we do not plan to proceed with that suggestion
at the moment.


Thanks for considering! Anne makes a good point that
active defense here (by filtering requests based on
destination) would work better against timing attacks than
passive defense (where the responses are blocked by the
browser). Please make sure that IDPs are aware of the
destination filtering requirement, by having it emphasized
in developer facing documentation.


Yes, we will work with devrel to continue ensuring IDP best
practices are easily discoverable.



I'd like to append a small addition to this I2S
(mainly to avoid having an additional PSA since
it is very related to this one): we would also
like approval to only send Same-Site=None cookies
in the accounts endpoint, instead of all cookies
(so not Same-Site=Lax or Same-Site=Strict). This
is also a breaking change but we do not
anticipate IDPs to break, and also plan to work
with them to ensure that they are aware of this
change and are not caught by surprise.

To my non-FedCM expert brain, this doesn't feel
like a small addition (happy to be wrong!), beyond
not understanding the scale of the risk, the
normal process questions come to mind i.e., is it
specced, do we have tests, what do other vendors

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

[Daniel Bratell]

I don't think we, in general, want open ended deprecations. Nowadays 
they are a bit more hidden in DevTools, but they used to be a source of 
console spam and cause warning fatigue. Many also don't react to 
deprecations unless there is some kind of timeline so I really prefer 
there to be a set point in the future where we plan to remove something.


I will also admit to being a bit mislead by the way chromestatus 
generates mail titles, thinking you had already planned for a removal.


/Daniel

On 2024-03-19 23:51, Mason Freed wrote:



On Tue, Mar 19, 2024 at 1:44 PM Mike Taylor  
wrote:


Hi Mason,

Would you mind requesting reviews for the various shipping gates
(privacy, security, enterprise, etc.) in your chromestatus entry?


Definitely! But I only need to do that before I ship this, right? I.e. 
not required yet, while I’m just deprecating but not yet removing the 
feature?


Thanks,
Mason


On 3/15/24 6:49 PM, Mason Freed wrote:



Contact emails


mas...@chromium.org


Explainer


None


Specification


https://github.com/whatwg/html/pull/10139


Summary


The includeShadowRoots argument was a never-standardized
argument to the DOMParser.parseFromString() function,
which was there to allow imperative parsing of HTML
content that contains declarative shadow DOM. This was
shipped in M90 [1] as part of the initial shipment of
declarative shadow DOM. Since the standards discussion
rematerialized in 2023, the shape of DSD APIs changed,
including this feature for imperative parsing. (See [2]
for more context on the standards situation and recent
changes, and see [3] and [4] for other related
deprecations.) Now that a standardized version of this
API, in the form of setHTMLUnsafe() and parseHTMLUnsafe()
will ship in M124 ([5]), the non-standard
includeShadowRoots argument needs to be deprecated and
removed. All usage should shift accordingly: Instead of:
(new
DOMParser()).parseFromString(html,'text/html',{includeShadowRoots:
true}); this can be used instead:
document.parseHTMLUnsafe(html); [1]
https://chromestatus.com/feature/5191745052606464 [2]
https://chromestatus.com/feature/5161240576393216 [3]
https://chromestatus.com/feature/5081733588582400 [4]
https://chromestatus.com/feature/6239658726391808 [5]
https://chromestatus.com/feature/6560361081995264



Blink component


Blink>DOM>ShadowDOM




Motivation


Now that there is a standardized version of this API, it
makes sense to remove the non-standard, Chrome-only
version of the API.



Initial public proposal


None


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Because this is a removal of an API, there is some compat
risk if sites use the API without feature detection.
Additionally, feature detection is a bit difficult for
this feature directly, and typical usage would instead
feature-detect the old `shadowroot` attribute. In that
case, there should be no breakage, since that attribute
has since been removed. The use counter [1] for this
feature has unfortunately had a recent spike in usage,
peaking at just over 0.01% of page loads as of March,
2024. However, I analyzed 8 of the top sites, and 8 of 8
are due to the exact same code snippet, from AstroJS/Lit
[2]. And that code amounts to feature detection, which
as-written will properly detect the lack of
`includeShadowRoots` and fall back to other behavior.
This, plus the lack of support in other browsers, makes
me less concerned about the compat risk here. [1]
https://chromestatus.com/metrics/feature/timeline/popularity/4455
[2]

https://github.com/withastro/astro/blob/main/packages/integrations/lit/client-shim.js



/Gecko/: No signal

/WebKit/: No signal

/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



Debuggability


None



Is this feature fully 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Daniel Bratell]

One more question, is requestAnimationFrame affected at all or will that 
still work just as before?


/Daniel

On 2024-03-13 17:32, Daniel Bratell wrote:


This intent has ended up in a strange state in the chromestatus tool, 
missing various flags I would have expected. Is that because the 
intent predates some of the chromestatus updates or because it started 
as an origin trial? If so, maybe the simplest is to refile it, or can 
it be made to be a proper Intent to Ship with all the buttons and bullets?


Another few things though, and I hope I'm not repeating something 
already covered elsewhere.


First, I really like the idea of doing optimizations that have a 
measurable impact on user behaviour and probably also power usage and 
energy usage so I approve of this work. But then I have questions.


The text mentions that WebKit uses an alignment on 30 milliseconds 
intervals, but what is the intention for Chromium? Also 30 milliseconds?


If the idea is for it to be 30 milliseconds, that would be too sparse 
to allow 60 fps animations run on setTimeout. If so, is that 
intentional, and would that be acceptable?


I ask in particular, because "uninteresting iframe" is vaguely defined 
so I don't know how much content will be misclassified as "uninteresting".


In general, is the answer to my questions above covered by some 
specification we can point people to when they wonder why something 
behaves inexplicably?


/Daniel

On 2024-03-13 03:00, Domenic Denicola wrote:
Can you fill out the interoperability and compatibility risks section 
here? I don't think standards position requests are necessary, but 
saying how this behavior might break existing sites that assume 
Chromium's current behavior, and how this new behavior compares to 
WebKit and Gecko, would be helpful.


Also, can you request the 
privacy/security/enterprise/debuggability/testing gates on Chrome Status?


On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen  wrote:

Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:

*Intent to Ship: Add JavaScript timer wake up alignment for
unimportant cross-origin frames*

Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant
frames are eligible to use JS timer alignment. WebKit uses
the policy to align DOM timer of non-interacted cross origin
frames to 30ms. This feature adds JavaScript timer wake up
alignment for unimportant frames on foreground pages.
Unimportant frames means they are cross origin, visible but
have non-large proportion of page’s visible area, and have no
user interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092



Blink component
Blink>PerformanceAPIs>Timers

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers>

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

None


/Gecko/: No signal

/WebKit/: No signal

/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


Debuggability

None



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

Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones

Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
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 proj

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Daniel Bratell]

This intent has ended up in a strange state in the chromestatus tool, 
missing various flags I would have expected. Is that because the intent 
predates some of the chromestatus updates or because it started as an 
origin trial? If so, maybe the simplest is to refile it, or can it be 
made to be a proper Intent to Ship with all the buttons and bullets?


Another few things though, and I hope I'm not repeating something 
already covered elsewhere.


First, I really like the idea of doing optimizations that have a 
measurable impact on user behaviour and probably also power usage and 
energy usage so I approve of this work. But then I have questions.


The text mentions that WebKit uses an alignment on 30 milliseconds 
intervals, but what is the intention for Chromium? Also 30 milliseconds?


If the idea is for it to be 30 milliseconds, that would be too sparse to 
allow 60 fps animations run on setTimeout. If so, is that intentional, 
and would that be acceptable?


I ask in particular, because "uninteresting iframe" is vaguely defined 
so I don't know how much content will be misclassified as "uninteresting".


In general, is the answer to my questions above covered by some 
specification we can point people to when they wonder why something 
behaves inexplicably?


/Daniel

On 2024-03-13 03:00, Domenic Denicola wrote:
Can you fill out the interoperability and compatibility risks section 
here? I don't think standards position requests are necessary, but 
saying how this behavior might break existing sites that assume 
Chromium's current behavior, and how this new behavior compares to 
WebKit and Gecko, would be helpful.


Also, can you request the 
privacy/security/enterprise/debuggability/testing gates on Chrome Status?


On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen  wrote:

Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:

*Intent to Ship: Add JavaScript timer wake up alignment for
unimportant cross-origin frames*

Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant frames
are eligible to use JS timer alignment. WebKit uses the policy
to align DOM timer of non-interacted cross origin frames to
30ms. This feature adds JavaScript timer wake up alignment for
unimportant frames on foreground pages. Unimportant frames
means they are cross origin, visible but have non-large
proportion of page’s visible area, and have no user
interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092



Blink component
Blink>PerformanceAPIs>Timers



TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

None


/Gecko/: No signal

/WebKit/: No signal

/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


Debuggability

None



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

Is this feature fully tested by web-platform-tests

?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones

Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
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).

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

[Daniel Bratell]

LGTM3

(Mozilla has responded that they think this makes sense)

/Daniel

On 2024-03-06 22:02, 'Sunggook Chue' via blink-dev wrote:
Request for Mozilla: 
https://github.com/mozilla/standards-positions/issues/996.


Yes, the new feature already works on Safari.

On Wednesday, March 6, 2024 at 8:53:12 AM UTC-8 mike...@chromium.org 
wrote:


We met today and discussed this intent as OWNERS, and would like
you to still request a vendor position from Mozilla (as I
requested earlier). If this change doesn't result in interop with
Safari, can you also file a vendor position for them? My read of
the explainer is that we should be matching Safari, but confirming
would be good. Please consider shipping contingent on this request.

https://github.com/mozilla/standards-positions
https://github.com/WebKit/standards-positions

thanks,
Mike

On 3/6/24 11:48 AM, Alex Russell wrote:

LGTM3

At a higher level, it would be great for AV1/VP9 encode to end up
in something like Interop. It makes me sad to be adding a vote
here to enable a closed format when open ones are better.

On Wednesday, March 6, 2024 at 8:43:11 AM UTC-8 Philip Jägenstedt
wrote:

LGTM2

I think that

https://wpt.fyi/results/mediacapture-record?label=master=experimental=mp4


are the relevant tests. LGTM assuming all of these tests pass
with MediaRecorderEnableMp4Muxer enabled. If that's not the
case, is there some functionality that won't be supported
initially?

On Wed, Mar 6, 2024 at 7:19 AM Yoav Weiss (@Shopify)
 wrote:

LGTM1

On Tue, Mar 5, 2024 at 5:01 PM 'Michaela Merz' via
blink-dev  wrote:

Thank you for adding this. Finally we're going to be
able to do cross-browser video-recordings and
playing. Can't wait to see it in production.

M.


On Monday, March 4, 2024 at 3:50:13 PM UTC-7
sun...@microsoft.com wrote:

Mike, I've added feature detection and developer
engagement on

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


On Monday, March 4, 2024 at 2:13:11 PM UTC-8
Sunggook Chue wrote:

Yoav,

Philipp's answer is correct, please let me
know if you need any more info to unblock.

On Thursday, February 29, 2024 at 11:53:47 AM
UTC-8 philipp...@googlemail.com wrote:

Yoav,

in WebRTC land "we have a sample for
that" (thanks to the one and only WebRTC
devrel guy Sam Dutton, I think I stole
this tagline from him)!

https://webrtc.github.io/samples/src/content/getusermedia/record/
with recent changes to improve MP4 support.

Discovery currently happens
with isTypeSupported but it seems the WG
just decided to deprecate that:

https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141
(not sure how I feel about that, I'd
rather nuke MediaRecorder entirely in
favor of WebCodecs + IndexedDB)

Am Do., 29. Feb. 2024 um 09:13 Uhr
schrieb Yoav Weiss (@Shopify)
:



On Thu, Feb 29, 2024 at 1:46 AM
'Sunggook Chue' via blink-dev
 wrote:

Here is an explainer, summary only.


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


Thanks! That's very useful! :)

What's the feature detection story?
How can developers know which formats
are supported?



On Wednesday, February 28, 2024
at 7:53:29 AM UTC-8
yoav...@chromium.org wrote:

On Tue, Feb 27, 2024 at
1:45 AM Mike Taylor
 wrote:


On 2/22/24 9:21 PM,
'Sunggook Chue' 

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

[Daniel Bratell]

LGTM3

/Daniel

On 2024-03-13 16:19, Yoav Weiss (@Shopify) wrote:

LGTM2

On Wed, Mar 13, 2024 at 10:59 AM Noam Rosenthal 
 wrote:




On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify)
 wrote:



On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal
wrote:

I've run a rough HTTP archive query on it, testing all
HTTP responses last month (666 million):
getComputedStyle with an argument that doesn't begin with
"::" is called in 0.45% of pages, out of which 55% is
":before", 28% is after, and the vast majority of the rest
are invalid pseudo-element names (e.g. "height" or
"display").
There were extremely rare cases that would be affected:
getComputedStyle(element, ":placeholder") or
getComputedStyle(element, ":marker"), about 0.1% of
requests (34 out of 666 million).

Is this considering all requests? What's the %age when only
looking at HTML and CSS responses? (or on pages)


I refined the query a bit and use January dataset. So this will
potentially affect 89 pages out of 17M (226 responses of 420M). So
one in every 200,000 pages:
Total Pages 17,399,427
Total URLs  420,144,799
Potentially affected Pages  89
Potentially affected URLs   226
% Affected Pages0.0005%
% affected URLs 0.0001%


I'm still running the refinement to only use HTML/JS responses
(this is not CSS) but I'm not sure it will tell us something new.


Pages %age seems sufficiently small to give confidence here. Thanks!!
--
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/CAOmohSLTt%3DMgVzGw%2Beij8Hsga4%3DTaqDHcsDKwUH3H0khN0acSw%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/97c5bd80-6b1a-4d8a-a129-facfe36d4d26%40gmail.com.

Re: [blink-dev] Intent to Ship: RegExp duplicate named capture groups

[Daniel Bratell]

LGTM3

/Daniel

On 2024-03-11 17:16, Yoav Weiss (@Shopify) wrote:

LGTM2

On Mon, Mar 11, 2024 at 5:00 PM Shu-yu Guo  wrote:

On Mon, Mar 11, 2024 at 8:26 AM Mike Taylor
 wrote:

On 3/11/24 6:49 AM, Yoav Weiss (@Shopify) wrote:




On Fri, Mar 8, 2024 at 4:26 PM Mike Taylor
 wrote:

LGTM1

On 3/7/24 6:22 PM, Shu-yu Guo wrote:



Contact emails

pth...@chromium.org, s...@chromium.org


Explainer

None


Specification

https://github.com/tc39/ecma262/pull/2721



What are the implications of this on regexes that already
have duplicate named capture groups? Would their behavior
change?

Shu can confirm, but my understanding is any regexes in the
wild that have duplicate named capture groups today are just
busted (they should throw a SyntaxError - and those are pretty
hard to miss). If they do exist in the wild, they should start
working, which in theory would match author intent. The risk
seems very low IMHO, if it exists at all.


Exactly right. This is a case of going from a SyntaxError to
working, so there should be no back compat issues.


Makes sense, thanks for clarifying! :)


The concrete example from the explainer currently throws a
SyntaxError:

```
/(?[0-9]{4})-[0-9]{2}|[0-9]{2}-(?[0-9]{4})/
^^^
SyntaxError: Invalid regular expression:
/(?[0-9]{4})-[0-9]{2}|[0-9]{2}-(?[0-9]{4})/: Duplicate
capture group name
```




Summary

https://github.com/tc39/proposal-duplicate-named-capturing-groups



Blink component

Blink>JavaScript>Regexp




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is a Stage 3 TC39 proposal. No known interop risk.
No known web incompatibility risk.



/Gecko/: Positive Firefox uses V8's regexp engine, so it
is not actually an independent implementation here.

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=252553) Stage 3
TC39 proposal.

/Web developers/: No signals

/Other signals/:


Ergonomics

No known ergonomics risks.



Activation

This is unlikely to be polyfillable since it's adding a
new kind of RegExp syntax.



Security

No known security risks.



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

Debuggable like any other JS RegExp.



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

Yes


Is this feature fully tested by
web-platform-tests

?

Yes

Tested in test262.
https://github.com/tc39/test262/pull/3625
https://github.com/tc39/test262/pull/3706
https://github.com/tc39/test262/pull/3709



Flag name on chrome://flags

--js-regexp-duplicate-named-groups


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

DevTrial on desktop 123

DevTrial on Android 123



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

This intent message was generated by Chrome Platform
Status 

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

[Daniel Bratell]

Just to ask what is probably a FAQ to get it out here...

The Service Worker timeout is 30 seconds right, so regardless of how 
heavy the calculations are, a service worker and its associated 
calculations will die in 30 seconds after the user closes the associated 
page?


I ask because while it's been possible to run heavy calculations in 
various workers in the past, this explicitly encourages it. It would be 
a bad situation if a user cannot detect or stop a runaway WebGPU 
operation from a possibly hostile site.


/Daniel

On 2024-03-13 08:06, 'François Beaufort' via blink-dev wrote:



On Tue, Mar 12, 2024 at 10:14 PM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

On Tue, Mar 12, 2024, 15:10 'François Beaufort' via blink-dev
 wrote:



On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor
 wrote:

On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None

Could you write a few sentences why this is a useful addition?

Service Workers enable offline capabilities and background
processing for WebGPU. This means graphics-intensive web
applications or Chrome Extensions can cache resources and
perform computations even when the user isn't actively
interacting with the page.
Shared Workers allow multiple tabs or extension contexts to
coordinate and share WebGPU resources. This leads to smoother
performance and more efficient use of the user's graphics
hardware.



Specification

https://gpuweb.github.io/gpuweb/#navigator-gpu


Summary

Functionality added to the WebGPU spec after its first
shipment in a browser. ServiceWorker and SharedWorker
support is added to WebGPU, aligning with existing WebGL
capabilities.


Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

ServiceWorker and SharedWorker support have not yet been
implemented in any browser, but have been approved by the
GPU for the Web Community Group, with representatives
from Chrome, Firefox, and Safari. See minutes at

https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43



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

Not officially a positive signal, but looking positive
based on the comments.


Indeed.



/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)

This is kind of an "N/A to positive", given it's WebGPU.


Agree ;)



/Web developers/: Positive
(https://github.com/gpuweb/gpuweb/issues/4197)

/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, ChromeOS,
Android, and Android WebView)?

No
All platforms will eventually have support. Will
immediately be available on Android, ChromeOS, Mac, and
Windows, since those platforms already support WebGPU.
Linux is planned to have WebGPU support in the future, so
this feature will become available when WebGPU does.

What about WebView? Do we ship support for WebGPU there?


Yes. WebGPU is supported on Android WebView as well.


Note that Shared Workers are not available on Android for now. See 
https://issues.chromium.org/issues/40290702





Is this feature fully tested by
web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled
into Chromium and part of the testing of Dawn/Tint in
Chromium. PRs: https://github.com/gpuweb/cts/pull/3419 -
https://github.com/gpuweb/cts/pull/3345


Flag name on chrome://flags

None


  

Re: [blink-dev] Intent to Ship: CSSImportRule.styleSheet

[Daniel Bratell]

(resending to list since I accidentally dropped it)

Hi,

We discussed this intent in the API Owner meeting, and I ended up with 
some questions.


Question 1: What is the current behaviour in the case where the 
specification wants us to return null?


Question 2: I understand that Gecko currently follows the specification 
as it is written, but if this change has a web compat risk, maybe it is 
the specification that should change. Was that something you considered?


Question 3: What is the web compatibility risk? Do you have any 
information about how many pages that would be affected (possibly 
negatively)? We want to have an idea of how impactful a change will be 
before shipping it, and at least I don't know if this is used by one 
page in a billion or half the web.


/Daniel


On 2024-03-06 15:48, eui-sa...@samsung.com wrote:

Sorry for the delay.

I am not sure if there is any interest from developers. The spec was 
updated last April [1]. I started this from the spec change and the 
related crbug.


I filed an issue[2] last week and got a comment[3] in WebKit. The 
reviewer's worry would be that the lifetime of these objects is not 
carefully defined and as such when they return null and non-null can 
end up varying in edge cases.


I thought this was very clear to be changed in spec that CSSOM was not 
matched with at-rule behavior and it has low compat risk.


[1] https://github.com/w3c/csswg-drafts/issues/8608
[2] https://github.com/WebKit/standards-positions/issues/325
[3] 
https://github.com/WebKit/standards-positions/issues/325#issuecomment-1966698090
On Wednesday, March 6, 2024 at 7:28:32 PM UTC+9 yoav...@chromium.org 
wrote:


Friendly ping on the above questions! :)

On Wed, Feb 28, 2024 at 6:18 PM Yoav Weiss (@Shopify)
 wrote:

Do I understand correctly that this would partially align us
with Firefox (modulo the crash), and take us away from WebKit
interoperability?

If so, it'd be good to understand if:
* There is interest from developers in this
* WebKit is planning to follow
* This has low compat risk (in terms of current sites relying
on this value not being null somehow)


On Tue, Feb 27, 2024 at 2:52 AM eui-sa...@samsung.com
 wrote:

> Would you mind explaining why this is a useful addition
for developers? Or is the motivation improved spec
compliance?

In both perspectives. The CSS OM spec was fixed because it
was not matched with the spec of @import in css-cascade.
The behaviour of CSSImportRule is not following @import.


> Can you request a signal?
https://github.com/WebKit/standards-positions

Sure, I filed an issue.
https://github.com/WebKit/standards-positions/issues/325


> All of these tests are passing right now - will you be
adding new tests?Yes, I will add new tests in

https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental=master


I am working on it.

https://chromium-review.googlesource.com/c/chromium/src/+/5065830/8/third_party/blink/web_tests/external/wpt/css/cssom/cssimportrule.html

On Sunday, February 25, 2024 at 7:14:59 AM UTC+9
mike...@chromium.org wrote:

On 2/23/24 8:31 AM, Amos Lim wrote:



Contact emails

eui-sa...@samsung.com


Explainer

None

Would you mind explaining why this is a useful
addition for developers? Or is the motivation improved
spec compliance?



Specification

https://drafts.csswg.org/cssom/#the-cssimportrule-interface


Summary

Allow CSSImportRule.styleSheet to be nullable. The
styleSheet attribute in CSSImportRule can be null if
there is no associated CSS style sheet.



Blink component

Blink>CSS




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

/WebKit/: No signal

Can you request a signal?
https://github.com/WebKit/standards-positions



/Web developers/: No signals

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of
existing 

Re: [blink-dev] Intent to Ship: 'pageswap' event

[Daniel Bratell]

LGTM2

/Daniel

On 2024-03-06 16:58, 'Khushal Sagar' via blink-dev wrote:



On Wed, Mar 6, 2024 at 6:32 AM Manuel Rego Casasnovas 
 wrote:


What's going on with the tests?


https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master=experimental=chrome=firefox=safari




The code to dispatch this event is partly in the browser process, so 
turning on experimental web features doesn't enable the flag there. We 
have a virtual tests suite 
 to 
run the test on the bots, won't be necessary once we switch runtime 
feature status to stable.




Thanks,
   Rego

On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:
> LGTM1
>
> On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal
 > wrote:
>
>
>
>                         Summary
>
>                 The `pageswap` event is fired on a Document's window
>                 object when a navigation will replace this
Document with
>                 a new Document. The event provides activation
info about
>                 the navigation (type, NavigationHistoryEntry for
the new
>                 Document). If the navigation has a cross-document
>                 ViewTransition, the event is dispatched before
capturing
>                 state for the old Document. This allows the
page-author
>                 to configure the old state captured for the
transition
>                 based on the navigation's activation info and the
>                 current visual state of the old Document. This
feature
>                 is split out from the larger
>                 ViewTransition-on-Navigation project.
>
>
>         Why is it split out? Is there some utility for this
regardless
>         of view transitions?
>
>     Absolutely! For example it's a place where you can figure
out that
>     you're navigating away to a different same-origin document
(after
>     redirects), and act on it in some way, e.g. put something in
>     `sessionStorage` like a video playback position.
>     It's different from `pagehide` in that sense, because with
>     `pagehide` you don't know you're going to a new document.
>
>     Also by having a generic event with an optional viewTransition
>     property, it can tell the author that a view transition *didn't*
>     take place, which we can't do with a view-transition event.
>
>     The design for this (as for `pagerveal`) started from
>     view-transition-specific events and ended up gravitating towards
>     this kind of event with an optional attribute for this
reason, and
>     also to avoid a situation where people create fake view
transitions
>     for the purpose of getting these events.
>
>
> Makes sense!
>
>
>                         Blink component
>
>                 Blink>ViewTransitions
>               
 

>
>
>                         TAG review
>
>
https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258


>
>
>                         TAG review status
>
>                 Pending
>
>
>                         Risks
>
>
>                         Interoperability and Compatibility
>
>                 None
>
>
>                 /Gecko/: Positive
>               
 (https://github.com/mozilla/standards-positions/issues/969
)
>
>
>         Is that the right position?
>
>     Yes, the name was changed while iterating, but it's the same
feature
>     and Gecko folks took active part in the design and reviews.
>
>
> Ooh, got it!
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from
it, send
> an email to blink-dev+unsubscr...@chromium.org

> >.
> To view this discussion on the web visit
>

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKjwe8bHquJ09vUW%2BeSvXr3tuBASCOKh1SAk7ay4Fay4Q%40mail.gmail.com

Re: [blink-dev] Re: Intent to experiment - WebAssembly JavaScript Promise Integration (update)

[Daniel Bratell]

The policy has changed a bit to accept a direct extension, without any 
breaks, where we previously didn't so it's possible the documentation 
you saw was outdated. The enforced break was to prevent burn-in that 
would make it painful to do suitable changes or drop an idea, but it 
seems that has not been a big problem so the process was tweaked.


/Daniel

On 2024-02-20 19:14, 'Francis McCabe' via blink-dev wrote:
I can live with that. However, the bureaucracy is overwhelming. To get 
an extension, the documentation I saw stated that I have to create a 
new OT.


On Tuesday, February 20, 2024 at 10:02:44 AM UTC-8 rby...@chromium.org 
wrote:


Sorry I missed this question! No, I did not notice that the entry
was for 10 milestones. Our policy


is a maximum of 6 milestones with 3-milestone renewals dependent
on showing significant progress towards standardization.Francis,
do you want to make this for M123-128 instead then plan to request
a renewal after that?

Rick

On Fri, Feb 2, 2024 at 9:09 PM Panos Astithas 
wrote:

Hey Rick,

This intent was updated to last between M123-M132 after
posting, but before approval. Since it's not clear whether you
looked at Chromestatus or the email thread, can you confirm
that your approval is indeed for these milestones?

Thanks,
Panos

On Thu, Jan 25, 2024 at 10:29 AM Mike Taylor
 wrote:

Yep - that is an official positive signal, thanks!

On 1/24/24 7:40 PM, Francis McCabe wrote:

Does this:

https://mozilla.github.io/standards-positions/#wasm-js-promise-integration
count as an official positive signal?

Francis

On Wed, Jan 24, 2024 at 3:09 AM Yoav Weiss (@Shopify)
 wrote:



On Friday, January 5, 2024 at 7:25:28 PM UTC+1
Francis McCabe wrote:

This is an update to the previous
intent-to-experiment (filled out a few more fields)

Contact emailsf...@chromium.org


Explainerhttps://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md




Specificationhttps://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md



Summary

Stack Switching denotes a technology that allows
programs to suspend and resume computation. This
is an active area that is part of the WebAssembly
standards track. See
https://github.com/WebAssembly/stack-switching

and
https://github.com/WebAssembly/meetings/tree/main/stack
.
This particular feature refers to the integration
between JavaScript Promises and stack switching.
This is described in more detail in

https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#





Blink componentBlink>JavaScript>WebAssembly



Search tagsstack switching
,
Promise
,
JSPI 

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


TAG review statusPending

Risks


Interoperability and Compatibility

This spec is backed by a standardization effort.
We do not plan to ship the JSPI until it has been
standardized by the W3C Wasm WG. However, post
standardization, we will depend on all browsers
implementing the standard.



/Gecko/: 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Daniel Bratell]

Mike didn't refer to the TAG review or browser signals, but the review 
steps in chromestatus. The intent should request, privacy, security, 
enterprise, and the other steps there.


I agree that this lives in the borderland between user agent UI and a 
web visible change so some shortcuts might be possible to motivate, but 
you still need to click the the appropriate buttons in the chromestatus 
tool.


/Daniel

On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:


Hello Mike,

Thank you for taking a look!

I am seeking consensus on how to approach the feature from a 
standardization perspective. I think the feature can be considered a 
browser UI change, which is why I haven't requested a TAG review or 
signals from other engines. However, I am open to doing so if necessary.


I apologize for any confusion. We did the general experimentation in 
Edge (not the "origin trials" as I mentioned in the email). Retention 
reports were neutral, and we observed no regressions in scorecards. 
Also, we have not received any negative user feedback thus far.


I am working on requesting reviews for my chromestatus entry. Thanks 
for pointing this out!


Thanks,
Yaroslav


On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:

Hi there,


Would you mind requesting reviews for the various review gates in
your chromestatus entry?


On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote:



Contact emails

gerc...@microsoft.com, yshal...@microsoft.com


Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1


Summary

Makes the browser use the user's preferred color scheme to render
the viewport scrollbars if the value of "page’s supported color
schemes" is 'normal' or not specified, and the computed value of
the color-scheme for the root element is 'normal'. Viewport
scrollbars can be considered to be outside the web content.
Therefore, the user agents should honor the user's preferred
color scheme when rendering viewport scrollbars if page authors
have not explicitly specified support for color schemes.



Blink component

Blink>Layout>Scrollbars




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested
TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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, ChromeOS, Android, and Android
WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909


Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The
counter tracks the number of users who have dark mode root
scrollbars due to the feature. Adoption in Edge Stable population
based on this metric is approximately 13%.


Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other
browsers adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



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

124
DevTrial on desktop

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

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Daniel Bratell]

LGTM

Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS 
still apply, but this still seems ready to ship.


/Daniel

On 2024-02-23 19:14, Chris Harrelson wrote:

My LGTM still stands, and have recorded it in the tool.

On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev 
 wrote:


Gentle ping.. Received signoffs for all review gates for this feature.

*From:* Anupam Snigdha 
*Sent:* Monday, February 12, 2024 10:37 AM
*To:* Thomas Steiner ; Chris Harrelson

*Cc:* Evan Stade ; Anupam Snigdha
; 一丝 ; blink-dev
; sligh...@chromium.org
; svo...@gmail.com ;
pwn...@chromium.org ; Marijn Kruisselbrink
; yoav...@chromium.org ;
huang...@chromium.org ;
mk...@chromium.org ; Joshua Bell
; christin...@chromium.org
; etiennen...@chromium.org
; Sanket Joshi (EDGE) 
*Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship:
Clipboard API: Svg
I've made some changes

to
address the loss of styles and other formatting issues during
write. During read, if the authors have added `image/svg+xml` to
the `unsanitized` list, then the SVG image content is returned
without any strict processing by the browser. By-default, read
processes the `image/svg+xml`using the strict HTML fragment parser
that inlines the styles and strips out certain tags that may be
security sensitive.
I have started the privacy/security reviews for this change. Thanks!

-Anupam

*From:* Thomas Steiner 
*Sent:* Friday, February 2, 2024 12:45 AM
*To:* Chris Harrelson 
*Cc:* Evan Stade ; Anupam Snigdha
; 一丝 ; blink-dev
; sligh...@chromium.org
; svo...@gmail.com ;
pwn...@chromium.org ; Marijn Kruisselbrink
; yoav...@chromium.org ;
huang...@chromium.org ;
mk...@chromium.org ; Joshua Bell
; Anupam Snigdha ;
christin...@chromium.org ;
etiennen...@chromium.org 
*Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard
API: Svg
Regarding developer interest, there's definitely some false
positives in there, but a quick GitHub search


 demonstrates
that quite a few developers attempt to write `image/svg+xml` onto
the clipboard. (Including my own app, SVGcode

).


On Thu, Feb 1, 2024 at 11:45 PM Chris Harrelson
 wrote:



On Thu, Feb 1, 2024 at 2:43 PM Evan Stade
 wrote:

My understanding is that SVG support got lost in a
personnel shuffle and that we would like to ship it in
theory. This comment

has some more context, the takeaways being that:

  * we need to be more sure of the implementation
  * we need partner confirmation, i.e. addressing "LGTM3
with the caveat that we should only flip this flag to
ship if big customers like Sean's team are able to use
this successfully to minimally cover their needs."

From my perspective the LGTMs are no longer caveated. I think
there is enough evidence of demand to just do it.

No one has done that outreach as of yet.

-- Evan Stade


On Thu, Feb 1, 2024 at 2:35 PM Chris Harrelson
 wrote:

Hi,

From my perspective, you still have 3 LGTMs to ship
from the API owners. However, please fill out the
cross-functional reviews for privacy, security, etc
that have been added to the process since this intent
was created. If that doesn't seem possible with your
existing chromestatus entry, let me know or just
create a new one and I'll LGTM it after those
reviews have started.

On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha
 wrote:

Thanks Chris!
cc'ing estade@.
I think Darwin and Victor are not working on
clipboard anymore so this feature was stalled.

Recently another bug was opened

(https://bugs.chromium.org/p/chromium/issues/detail?id=1410321)
where support for copying/pasting svg images is
needed. More discussions:

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

[Daniel Bratell]

Never mind. My mail was backed up and I hadn't seen that it was already 
approved, thus no longer on the list. All is well, and my LGTM1 is 
actually a bonus LGTM4


/Daniel

On 2024-02-21 17:23, Daniel Bratell wrote:


This doesn't show up in the shipping status in chromestatus so it's 
not on our radar. My LGTM1 still stands, but it can easily be 
forgotten, and we might miss some important review step, if it's not 
there.


/Daniel

On 2024-02-16 18:14, Joey Arhar wrote:
> Is this the relevant explainer (referenced from the PR below): 
https://github.com/WICG/sanitizer-api/blob/main/explainer.md


Yes, as far as I know.

> This seems positive, right?

Whoops, meant to put positive. I updated the chromestatus.

> Both of these look like "Shipped/Shipping", per 
https://bit.ly/blink-signals. That status is a little odd, because it 
doesn't look like they've actually made it to a stable release, but 
if I'm reading the bug trackers right they're both merged, so they're 
past "In Development".


Ok, I'll change them to shipped/shipping.

On Thu, Feb 15, 2024 at 9:35 AM Luke  wrote:

Just to keep everyone up to date, you can disregard my remarks
above I've landed a patch which addresses the lack of trusted
types protection, thanks for the quick review Joey.

Regards,
Luke

On Wednesday, February 14, 2024 at 10:49:23 PM UTC Luke wrote:

Hi,

In it's current form Chromium's implementation of these
functions bypasses trusted types protection.

The below WPT tests cover this behaviour:


https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master

<https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master>


https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master

<https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master>

https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master

<https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master>

This should be addressed before shipping, else it will be an
unexpected security regression.

On Wednesday, February 14, 2024 at 10:23:01 PM UTC Vladimir
Levin wrote:

On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin
 wrote:

Non-API-owner opinions inline:

On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via
blink-dev  wrote:

I just had some clarifying questions

On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar
 wrote:

Some additional notes:
- This API is tested in the declarative
ShadowDOM tests in interop2024, and it is
counting against us to not have it enabled by
default.
- The future sanitization options will be
added as an optional second parameter to both
methods, so there will not be any compat
issues with shipping now.

On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar
 wrote:


Contact emails

jar...@chromium.org


Explainer

None


Is this the relevant explainer (referenced from
the PR below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md



Specification


https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods

https://github.com/whatwg/html/pull/9538


Summary

The setHTMLUnsafe and parseHTMLUnsafe
methods allow Declarative ShadowDOM to be
used from javascript. In the future, they
may also get new parameters for sanitization.



Blink component

Blink>HTML

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>


TAG review

None


TAG review status

Not applicable


There seems to be consensus within browser
  

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

[Daniel Bratell]

This doesn't show up in the shipping status in chromestatus so it's not 
on our radar. My LGTM1 still stands, but it can easily be forgotten, and 
we might miss some important review step, if it's not there.


/Daniel

On 2024-02-16 18:14, Joey Arhar wrote:
> Is this the relevant explainer (referenced from the PR below): 
https://github.com/WICG/sanitizer-api/blob/main/explainer.md


Yes, as far as I know.

> This seems positive, right?

Whoops, meant to put positive. I updated the chromestatus.

> Both of these look like "Shipped/Shipping", per 
https://bit.ly/blink-signals. That status is a little odd, because it 
doesn't look like they've actually made it to a stable release, but if 
I'm reading the bug trackers right they're both merged, so they're 
past "In Development".


Ok, I'll change them to shipped/shipping.

On Thu, Feb 15, 2024 at 9:35 AM Luke  wrote:

Just to keep everyone up to date, you can disregard my remarks
above I've landed a patch which addresses the lack of trusted
types protection, thanks for the quick review Joey.

Regards,
Luke

On Wednesday, February 14, 2024 at 10:49:23 PM UTC Luke wrote:

Hi,

In it's current form Chromium's implementation of these
functions bypasses trusted types protection.

The below WPT tests cover this behaviour:


https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master




https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master



https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master



This should be addressed before shipping, else it will be an
unexpected security regression.

On Wednesday, February 14, 2024 at 10:23:01 PM UTC Vladimir
Levin wrote:

On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin
 wrote:

Non-API-owner opinions inline:

On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via
blink-dev  wrote:

I just had some clarifying questions

On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar
 wrote:

Some additional notes:
- This API is tested in the declarative
ShadowDOM tests in interop2024, and it is
counting against us to not have it enabled by
default.
- The future sanitization options will be
added as an optional second parameter to both
methods, so there will not be any compat
issues with shipping now.

On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar
 wrote:


Contact emails

jar...@chromium.org


Explainer

None


Is this the relevant explainer (referenced from
the PR below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md



Specification


https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods

https://github.com/whatwg/html/pull/9538


Summary

The setHTMLUnsafe and parseHTMLUnsafe
methods allow Declarative ShadowDOM to be
used from javascript. In the future, they
may also get new parameters for sanitization.



Blink component

Blink>HTML




TAG review

None


TAG review status

Not applicable


There seems to be consensus within browser vendors
that this is a good idea, but I'm just wondering
why you decided against filing TAG here?


IMO, either Firefox or Safari folks should have filed
a TAG review for this before they merged their
patches. Now 

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

[Daniel Bratell]

LGTM1

/Daniel

On 2024-02-16 18:14, Joey Arhar wrote:
> Is this the relevant explainer (referenced from the PR below): 
https://github.com/WICG/sanitizer-api/blob/main/explainer.md


Yes, as far as I know.

> This seems positive, right?

Whoops, meant to put positive. I updated the chromestatus.

> Both of these look like "Shipped/Shipping", per 
https://bit.ly/blink-signals. That status is a little odd, because it 
doesn't look like they've actually made it to a stable release, but if 
I'm reading the bug trackers right they're both merged, so they're 
past "In Development".


Ok, I'll change them to shipped/shipping.

On Thu, Feb 15, 2024 at 9:35 AM Luke  wrote:

Just to keep everyone up to date, you can disregard my remarks
above I've landed a patch which addresses the lack of trusted
types protection, thanks for the quick review Joey.

Regards,
Luke

On Wednesday, February 14, 2024 at 10:49:23 PM UTC Luke wrote:

Hi,

In it's current form Chromium's implementation of these
functions bypasses trusted types protection.

The below WPT tests cover this behaviour:


https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master




https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master



https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master



This should be addressed before shipping, else it will be an
unexpected security regression.

On Wednesday, February 14, 2024 at 10:23:01 PM UTC Vladimir
Levin wrote:

On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin
 wrote:

Non-API-owner opinions inline:

On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via
blink-dev  wrote:

I just had some clarifying questions

On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar
 wrote:

Some additional notes:
- This API is tested in the declarative
ShadowDOM tests in interop2024, and it is
counting against us to not have it enabled by
default.
- The future sanitization options will be
added as an optional second parameter to both
methods, so there will not be any compat
issues with shipping now.

On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar
 wrote:


Contact emails

jar...@chromium.org


Explainer

None


Is this the relevant explainer (referenced from
the PR below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md



Specification


https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods

https://github.com/whatwg/html/pull/9538


Summary

The setHTMLUnsafe and parseHTMLUnsafe
methods allow Declarative ShadowDOM to be
used from javascript. In the future, they
may also get new parameters for sanitization.



Blink component

Blink>HTML




TAG review

None


TAG review status

Not applicable


There seems to be consensus within browser vendors
that this is a good idea, but I'm just wondering
why you decided against filing TAG here?


IMO, either Firefox or Safari folks should have filed
a TAG review for this before they merged their
patches. Now that they've merged, I think it falls
into the "[already specified && already shipped]"
exception category

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

[Daniel Bratell]

On 2024-02-17 03:22, Mason Freed wrote:
On Sat, Feb 10, 2024 at 5:39 AM Daniel Bratell  
wrote:


Just thinking about possible use cases for mutation events, do you
know what the browser extension situation is? Those might have
legitimate reason to react to page changes and maybe some of them
use the old events?

That's a good question, and I don't have a great answer. Except 
perhaps to say that I would hope MutationObserver should be able to 
handle any such reactions in the same way that an open web site would. 
Do you have a reason to think extensions specifically need synchronous 
events for mutations?


No, not at all. Just covering all the bases.

I assume injected extension scripts would show up in use counter data 
too, so if there are such extensions, they are unlikely to be one of the 
more popular ones.


/Daniel



On 2024-02-09 21:35, Mason Freed wrote:


On Wed, Feb 7, 2024 at 6:52 AM Yoav Weiss (@Shopify)
 wrote:

LGTM to run a deprecation trial M124-M134 inclusive.


Thanks!


May our mutations no longer be eventful!!





On Wed, Feb 7, 2024 at 3:50 PM Mason Freed
 wrote:



On Wed, Feb 7, 2024 at 6:06 AM Yoav Weiss (@Shopify)
 wrote:

Just to clarify - this intent is asking to start a
deprecation trial for mutation events in 124 and
ending it in 134, but you'd send a separate intent on
the actual removal of mutation events?


Yes, that’s correct. Here’s the request for deprecation
thread:


https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/P_iXWapTBgAJ

And I’ll send a request for removal closer to 126.

Thanks,
Mason



On Tue, Feb 6, 2024 at 5:12 PM Mason Freed
 wrote:



On Tue, Feb 6, 2024 at 3:38 AM Yoav Weiss
(@Shopify)  wrote:


Note that them shipping 2.0 and everyone
upgrading to 2.0 are not the same thing, and
is unlikely to happen at the same time..


Agreed for sure. That’s why I’ve been trying to
get them to confirm exactly what functionality
will be broken. I can’t see any breakage myself.

What would breakage look like? Are we
expecting JS to be borked entirely? Or do
we expect the events to stop firing,
resulting in hopefully smaller and
less-visible breakage?


No there shouldn’t be any exceptions thrown, so
the JS should be fine. It’s just that those
events will not be fired. The breakage, whatever
it is, is so small that I’ve yet been able to
notice it. That’s not to say there isn’t risk -
there surely is. Just that I’m hopeful.

Thanks,
Mason




 The npm package you listed,
for example, would use the
actual events if available,
so sites using that polyfill
would also count towards the
event usage if the browser
supports those even though
that's "safe", right?


This is an excellent point that I
hadn't thought of. I'm going to
modify the polyfill right now to
*always* run. That way polyfilled
usage will no longer be counted.
I'm used to writing polyfills for
features that are getting
*added*, where you want to avoid
using the polyfill when the
feature is supported. This is the
opposite.

Thanks,
Mason




/Gecko/: Positive

(https://github.com/mozilla/standards-positions/issues/807)
"very strong positive
position"

/WebKit/: No signal

(https://github.com/WebKit/standards-

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

[Daniel Bratell]

LGTM3 but don't forget to verify that the chromestatus NAs for security 
and privacy are eventually confirmed. (I don't see how it could not be, 
but they are experts)


/Daniel

On 2024-02-14 19:19, Chris Harrelson wrote:

LGTM2

On Wed, Feb 14, 2024 at 9:03 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

Thanks for aligning us on an interoperable name!!

On Wednesday, February 14, 2024 at 4:37:25 PM UTC+1 Henrik Boström
wrote:

From a code owner and W3C participant's perspective, I'm very
happy that we're finally aligning our attribute name with the
spec + Firefox' implementation. Thank you Eldar!

(Ultimately we should deprecate and remove the old attribute
name, but not until this has been shipped for a long time.)

On Tuesday, February 13, 2024 at 11:29:09 PM UTC+1 Mike Taylor
wrote:

Thanks! I had intended to reply that it's very simple to
add a runtime enabled feature to IDL, but it's been a busy
day. :)

On 2/13/24 3:57 PM, Eldar Rello wrote:


>Can we add a flag?

https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

>(Or someone can explain why that's difficult and the
risk is low here...).

I made it as a runtime enabled feature now.


On Monday, February 12, 2024 at 10:50:18 PM UTC+2 Eldar
Rello wrote:

On Monday, February 12, 2024 at 4:53:50 PM UTC+2
mike...@chromium.org wrote:

On 2/12/24 6:36 AM, Eldar Rello wrote:


Contact emails eldar...@gmail.com

Explainer None

Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget

Summary

JitterBufferTarget attribute allows applications
to specify a target duration of time in
milliseconds of media for the RTCRtpReceiver's
jitter buffer to hold. This influences the
amount of buffering done by the user agent,
which in turn affects retransmissions and packet
loss recovery. Altering the target value allows
applications to control the tradeoff between
playout delay and the risk of running out of
audio or video frames due to network jitter.


Essentially it is a rename of already shipped
playoutDelayHint attribute.


Is this purely a rename, or are there changes to
the semantics?

Other than the name change, it throws RangeError when
delay parameter is out of range. playoutDelayHint is
throwing only if delay is negative. Another
difference is that jitterBuffferTarget is in
milliseconds unit while playoutDelayHint is using
seconds.

And do we have any sense how widely used
playoutDelayHint is in the wild? There is some
discussion of the bikeshedding in

https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html,
but no consideration of existing usage (at least
as reflected in the minutes).

I do not have visibility over usage, but
playoutDelayHint remains supported to enable smooth
adaption.



Blink component Blink>WebRTC



TAG review None

TAG review status Not applicable

Opening an issue seems useful, but that seems
like a heavy tax for a contributor (vs the spec
editors...).



Risks


Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Mind providing a link to a bug?

Added



/WebKit/: No signal

Can we request a permission please?
https://github.com/WebKit/standards-positions


Created ticket there.




/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



Debuggability

None



Will this feature be 

Re: [blink-dev] Intent to Prototype and Ship: Standardized CSS zoom

[Daniel Bratell]

Same for me. A proprietary long term CSS property is now fully 
standardized and will be interoperable. This is a win for the web, and 
thank you for all who worked to make it happen!


/Daniel

On 2024-02-14 18:13, Yoav Weiss (@Shopify) wrote:
Just wanted to say that it's exciting to see this standardized after 
all these years. Given the manual inspection, it seems like shipping 
this to 100% with a killswitch is (hopefully) safe enough!


On Wed, Feb 14, 2024 at 6:11 PM Yoav Weiss (@Shopify) 
 wrote:


LGTM3

On Wed, Feb 14, 2024 at 6:00 PM Philip Jägenstedt
 wrote:

LGTM2

On Wed, Feb 14, 2024 at 11:53 PM Daniel Bratell
 wrote:
>
> LGTM1
>
> /Daniel
>
> On 2024-02-09 20:24, 'Yotam Hacohen' via blink-dev wrote:
>
>
>
> On Thursday, February 8, 2024 at 6:46:00 PM UTC-8 Domenic
Denicola wrote:
>
> On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen
 wrote:
>
> Hey Dominic and thanks for the input!
>
> On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic
Denicola wrote:
>
> It's always exciting to move such an old feature from
nonstandard to standardized!
>
> On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev
 wrote:
>
> Contact emailsyo...@google.com
>
> ExplainerNone
>
>
> FWIW, I think the contents of
https://github.com/w3c/csswg-drafts/pull/9699 and
https://drafts.csswg.org/css-viewport/#zoom-property are
probably a good enough explainer. It might be a good idea to
update ChromeStatus to link to them.
>
> Added those. Thanks!
>
>
>
>
>
> Specificationhttps://github.com/w3c/csswg-drafts/pull/9699
<http://github.com/w3c/csswg-drafts/pull/9699>
>
> Design

docshttps://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

<http://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit>
>
> Summary
>
> Aligns the existing implementation of the previously
non-standard CSS zoom property to align with the new standard.
This changes various JS APIs to align with the spec (see
design doc), change zoom to apply to iframes, and change it to
apply to all inherit all length properties (currently it only
changes inherited font-size)
>
>
> Blink componentBlink>Paint
>
> TAG reviewNone
>
> TAG review statusPending
>
>
> Probably this fits under the first exception here.
>
>
>
>
> Risks
>
> Interoperability and Compatibility
>
> There is web compatibility risk for these changes. However,
previous research indicates broken content due to unexpected
changes of the JS APIs is very unlikely, since: * The changes
to the JS API simply change the coordinate space of the
responses, not the syntax or what APIs are available. * Most
pages found during the research didn't appear to use CSS zoom
at all and the ones that did only relied on the visual effect,
not JS APIs. It's possible some pages will be broken by the
changes to inherited properties other than font-size, or
applying zoom to sub-frames, but based on previous research,
those are very likely to be minor visual changes that don't
break fundamental user interaction with the site. None of the
sites reviewed contained iframes underneath a zoomed ancestor.
We will use direct outreach to avoid any broken features in
Office 365 or the Gmail native mobile app
>
>
> Can you give more quantitative details on this previous
research? E.g. when you say "most pages", is that 3/5 pages?
99/100?
>
>   Sampling pages from the doc, I couldn't find even one
example of a page that uses zoom in a way that will change
it's behavior (i.e. - calling GetBoundingClientRect or
GetBoundingRects on an element with CSS zoom). I also compared
those sites visually side by side on a stable version of
chrome and a local version with the planned changes in effect,
and couldn't see any change.
>
>
> This sounds like a good sign, but I'd still appreciate some
numbers. So it's zero out of how many?
>
> I checked the first

Re: [blink-dev] Intent to Prototype and Ship: Standardized CSS zoom

[Daniel Bratell]

LGTM1

/Daniel

On 2024-02-09 20:24, 'Yotam Hacohen' via blink-dev wrote:



On Thursday, February 8, 2024 at 6:46:00 PM UTC-8 Domenic Denicola wrote:

On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen 
wrote:

Hey Dominic and thanks for the input!

On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic
Denicola wrote:

It's always exciting to move such an old feature from
nonstandard to standardized!

On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via
blink-dev  wrote:

Contact emailsyo...@google.com

ExplainerNone


FWIW, I think the contents of
https://github.com/w3c/csswg-drafts/pull/9699 and
https://drafts.csswg.org/css-viewport/#zoom-property are
probably a good enough explainer. It might be a good idea
to update ChromeStatus to link to them.

Added those. Thanks!



Specificationhttps://github.com/w3c/csswg-drafts/pull/9699

Design

docshttps://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously
non-standard CSS zoom property to align with the new
standard. This changes various JS APIs to align with
the spec (see design doc), change zoom to apply to
iframes, and change it to apply to all inherit all
length properties (currently it only changes inherited
font-size)


Blink componentBlink>Paint



TAG reviewNone

TAG review statusPending


Probably this fits under the first exception here

.



Risks

Interoperability and Compatibility

There is web compatibility risk for these changes.
However, previous research indicates broken content
due to unexpected changes of the JS APIs is very
unlikely, since: * The changes to the JS API simply
change the coordinate space of the responses, not the
syntax or what APIs are available. * Most pages found
during the research didn't appear to use CSS zoom at
all and the ones that did only relied on the visual
effect, not JS APIs. It's possible some pages will be
broken by the changes to inherited properties other
than font-size, or applying zoom to sub-frames, but
based on previous research, those are very likely to
be minor visual changes that don't break fundamental
user interaction with the site. None of the sites
reviewed contained iframes underneath a zoomed
ancestor. We will use direct outreach to avoid any
broken features in Office 365 or the Gmail native
mobile app


Can you give more quantitative details on this previous
research? E.g. when you say "most pages", is that 3/5
pages? 99/100?

  Sampling pages from the doc, I couldn't find even one
example of a page that uses zoom in a way that will change
it's behavior (i.e. - calling GetBoundingClientRect or
GetBoundingRects on an element with CSS zoom). I also compared
those sites visually side by side on a stable version of
chrome and a local version with the planned changes in effect,
and couldn't see any change.


This sounds like a good sign, but I'd still appreciate some
numbers. So it's zero out of how many?

I checked the first 15 websites in the list on this doc: 
https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd




Regarding the direct outreach targets you mentioned, are
they already fixed, or do they need more time to update?

We have reached out to the relevant people.


So, you have contacted them, but they still need more time to
update? Do you have an estimate for when they will be updated?

We already got a response from the gmail team, and everything is ok 
there, we even have a jsfiddle example 
 that shows that the visual aspect 
doesn't change for them. Still waiting for a response from the Office 
365, if we don't get a response in the next week we will reach out 
again for a better defined timeline.




What is your rollout plan for this change---straight to
100% with a killswitch, or a gradual rollout, or...?

Our plan is to go straight to 100% 

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

[Daniel Bratell]

Just thinking about possible use cases for mutation events, do you know 
what the browser extension situation is? Those might have legitimate 
reason to react to page changes and maybe some of them use the old events?


/Daniel

On 2024-02-09 21:35, Mason Freed wrote:


On Wed, Feb 7, 2024 at 6:52 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM to run a deprecation trial M124-M134 inclusive.


Thanks!


May our mutations no longer be eventful!!





On Wed, Feb 7, 2024 at 3:50 PM Mason Freed 
wrote:



On Wed, Feb 7, 2024 at 6:06 AM Yoav Weiss (@Shopify)
 wrote:

Just to clarify - this intent is asking to start a
deprecation trial for mutation events in 124 and ending it
in 134, but you'd send a separate intent on the actual
removal of mutation events?


Yes, that’s correct. Here’s the request for deprecation thread:


https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/P_iXWapTBgAJ

And I’ll send a request for removal closer to 126.

Thanks,
Mason



On Tue, Feb 6, 2024 at 5:12 PM Mason Freed
 wrote:



On Tue, Feb 6, 2024 at 3:38 AM Yoav Weiss (@Shopify)
 wrote:


Note that them shipping 2.0 and everyone upgrading
to 2.0 are not the same thing, and is unlikely to
happen at the same time..


Agreed for sure. That’s why I’ve been trying to get
them to confirm exactly what functionality will be
broken. I can’t see any breakage myself.

What would breakage look like? Are we
expecting JS to be borked entirely? Or do we
expect the events to stop firing, resulting in
hopefully smaller and less-visible breakage?


No there shouldn’t be any exceptions thrown, so the JS
should be fine. It’s just that those events will not
be fired. The breakage, whatever it is, is so small
that I’ve yet been able to notice it. That’s not to
say there isn’t risk - there surely is. Just that I’m
hopeful.

Thanks,
Mason




 The npm package you listed, for
example, would use the actual
events if available, so sites
using that polyfill would also
count towards the event usage if
the browser supports those
even though that's "safe", right?


This is an excellent point that I
hadn't thought of. I'm going to modify
the polyfill right now to *always*
run. That way polyfilled usage will no
longer be counted. I'm used to writing
polyfills for features that are
getting *added*, where you want to
avoid using the polyfill when the
feature is supported. This is the
opposite.

Thanks,
Mason




/Gecko/: Positive

(https://github.com/mozilla/standards-positions/issues/807)
"very strong positive position"

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/192)

/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



Goals for experimentation



Ongoing technical
constraints



Debuggability



Will this feature be
supported on all six

Re: [blink-dev] Intent to Ship: CSS paint-order for non-SVG text

[Daniel Bratell]

I didn't really get how it affects non-SVG text. The documentation and 
the examples are all for SVG. Is there HTML text that is also a mix of 
stroke, fill and marker blitting?


/Daniel

On 2024-02-08 10:14, Fredrik Söderquist wrote:

On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager  wrote:


Contact emails

sza...@chromium.org


Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order


Specification

https://svgwg.org/svg2-draft/painting.html#PaintOrder


Summary

Adds support for the existing CSS property `paint-order`. This
change only affects html (non-SVG) text; SVG text already supports
paint-order via attribute or CSS property.



Blink component

Blink>Paint



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped in version 60 (2018)

/WebKit/: No signal


Also shipped in WebKit (since Safari 11 according to MDN; Safari TP 25 
looking at changelog)



/fs


/Web developers/: Positive; 48 stars on tracking bug

/Other signals/:


WebView application risks

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

123



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5178467903864832

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/CAHOQ7J9i%3DwoeX%2Bh%2B1rwpidM%3D5SiMPnCq9fskupy2tDUjXcMAMw%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/CAHediLRsC%3DiYN%3D5iKfpYF99c62gqb_1nw4PnFQpawECXiQp7WQ%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/3720e507-7f37-4247-a327-bcc23e5049e2%40gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Daniel Bratell]

LGTM3 to add a warning.

Normally we don't like open ended deprecation warnings, end, which this 
is, but this should be a rare warning, except possibly in enterprise 
situations, and even there, warnings might trigger some feedback from a 
group that is normally not aware of upcoming changes.


/Daniel

On 2024-02-07 14:40, Yoav Weiss (@Shopify) wrote:

LGTM2

On Fri, Feb 2, 2024 at 11:10 PM Mike Taylor  
wrote:


Correction: LGTM1, conditioned on requesting Enterprise,
Debuggability, and Testing bits in chromestatus. :)

On 2/2/24 5:09 PM, Mike Taylor wrote:


LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs



https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing=0-7cfhrTo57AElxA6M9EVScg




Summary

Before a website A navigates to another site B in the user's
private network, this feature does the following:
1. Checks whether the request has been initiated from a secure
context
2. Sends a preflight request, and checks whether B responds with
a header that allows private network access.

The above checks are made to protect the user's private network.
There are already features for subresources and workers, but
this one is for navigation requests specifically.


Since this feature is the "warning-only" mode, we do not fail
the requests if any of the checks fails.  Instead, a warning
will be shown in the DevTools, to help developers prepare for
the coming enforcement.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess




Motivation

To prevent malicious websites from pivoting through the user
agent's network position to attack devices and services which
reasonably assumed they were unreachable from the Internet at
large, by virtue of residing on the user’s local intranet or the
user's machine.



Initial public proposal


https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there
isn't any compatibility risks on the client side. On the server
side, it shouldn't pose any risk either as the server can ignore
the preflight requests.



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

https://mozilla.github.io/standards-positions/#cors-and-rfc1918
makes it a bit clearer that this is indeed positive (vs the issue).


/WebKit/: Positive
(https://github.com/WebKit/standards-positions/issues/163)
Safari disagrees with the spec name and header names, but still
overall positive.

/Web developers/: Mixed signals Anecdotal evidence so far
suggests that most web developers are OK with this new
requirement, though some do not control the target endpoints and
would be negatively impacted.

/Other signals/:


Security

This change aims to be security-positive, preventing CSRF
attacks against soft and juicy targets such as router admin
interfaces. DNS rebinding threats were of particular concern
during the design of this feature:

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9



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

Relevant information (client and resource IP address space) is
already piped into the DevTools network panel. Deprecation
warnings and errors will be surfaced in the DevTools issues
panel explaining the problem when it arises.



Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access_id=5090117631868928_id=6245938696814592_id=5769215446351872_id=5679819023974400

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Daniel Bratell]

LGTM3

/Daniel

On 2024-02-05 11:47, Domenic Denicola wrote:

LGTM2

On Mon, Feb 5, 2024 at 5:38 PM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

Thanks for including these values in the I-D.

On Fri, Feb 2, 2024 at 9:17 PM Victor Tan 
wrote:

the code point PR is merged. Feel free to take a look again.
Thanks.

On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan
wrote:

create a PR for the code point change on the RFC draft,
will work on there:
https://github.com/vasilvv/tls-alps/pull/15, thanks.

On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik
Anderson wrote:

Thanks, it will be helpful to make sure this is
documented outside of Chromium. I will also chat with
some folks on Microsoft’s end that both own server
implementations and have more IETF experience to
explore how we can help with moving things forward.

*From:*Victor Tan 
*Sent:* Wednesday, January 24, 2024 9:00 AM
*To:* blink-dev 
*Cc:* Yoav Weiss ; blink-dev
; Erik Anderson
; Chris Harrelson
; David Benjamin
; Mike Taylor
; Victor Tan
; Rick Byers 
*Subject:* Re: [blink-dev] Re: Intent to Ship: New
ALPS code point




You don't often get email from victor...@chromium.org.
Learn why this is important




Rick, thanks for question, I will create a PR on the
ALPS RFC draft to document the new code point
regarding the early experiment.

On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5
Yoav Weiss wrote:

On Wed, Jan 24, 2024 at 4:48 PM Rick Byers
 wrote:

Oof, I agree it's not good that the only
documentation for the actual code point value
is in Chromium code - that's the sort of thing
our blink I2S process is supposed to prevent.
In addition to confusion, there's also
potential IP-risk downsides to this. Our blink
process is generally to block shipping on the
existence of some specification for everything
necessary for a compatible implementation in a
forum that ensures IP protection. While this
isn't typically an adoption barrier for many
companies, I know it has been in the past for
some (including Microsoft). This doesn't mean
we have to block on getting consensus in the
"right" standards venue, we can just do a
monkey-patch spec in a venue like the WICG, or
an unlanded PR in a formal WG where the PR
counts as an IP contribution. Then we can ship
it as an "incubation" while doing the
standards maturation work in parallel. Erik,
can you comment on the extent to which such
incubation spec work would help with Microsoft
adoption?

Victor, is there any chance you can throw
something together quickly (spec PR or
monkey-patch) that would cover the gaps in
what's necessary for compatible
implementations? This particular delta seems
very tiny and straightforward to me, so I was
originally thinking I'd just approve it. But
in principle I don't think we should be
continuing to approve changes to APIs which we
realize are struggling with adoption due to
the standards work not quite being up to our
I2S bar.

+1 to defining these codepoints somewhere. Where
are such codepoints typically defined? I'd have
assumed they'd go into one of the relevant I-Ds..

Erik, thank you for your offer of help on the
standardization front! It definitely sounds to
me like we should be pushing on the full
standards effort in parallel to this specific
intent. Having Microsoft and Google work
together on that 

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

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-31 17:53, Chris Harrelson wrote:

LGTM2

On Wed, Jan 31, 2024 at 8:00 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

On Friday, January 26, 2024 at 10:27:50 AM UTC+1 Noam Rosenthal wrote:

Contact emailsjap...@chromium.org, nrosent...@chromium.org



Explainerhttps://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md





Specificationhttps://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface



Summary

navigation.activation stores state about when the current
Document was activated (e.g., when it was initialized, or
restored from the back/forward cache).


I was confused by "when" here (as we already shipped
activationStart

).
The explainer does a good job of explaining this though.



Blink componentBlink>History



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


TAG review statusIssues addressed

Risks


Interoperability and Compatibility

None



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

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

/Web developers/: Positive

/Other signals/:

Security

This is a cross-document (navigation) feature, so designing it
we needed to take care of cross-origin navigation related
risks. Since `navigation.activation` is part of the navigation
API, it uses the same semantics and protections. We only
expose things that are otherwise exposed by the navigation API
or in other means.



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, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes



https://wpt.fyi/results/navigation-api/navigation-activation?label=master=experimental=navigation%20activation





Flag name on chrome://flagsNavigationActivation

Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.



Requires code in //chrome?False

Estimated milestonesShipping on desktop123Shipping on
Android123Shipping on WebView123Shipping on WebView123

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
Statushttps://chromestatus.com/feature/5076557983121408


Links to previous Intent discussionsIntent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJa-_9cEjMU3Ds660KmW0u_G_M9S1Ah-14gAfk9Qhrp2g%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/bda4f055-7c7a-4684-b8f3-42ee1cdd786cn%40chromium.org

Re: [blink-dev] Intent to Ship: CSS light-dark() Color Function

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-30 21:23, Mike Taylor wrote:


LGTM2

On 1/30/24 1:11 PM, Chris Harrelson wrote:

LGTM1

On Tue, Jan 30, 2024 at 10:08 AM Rune Lillesveen 
 wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-color-5/#light-dark


Summary

Allows authors to provide separate colors for light and dark
color-schemes on a per element basis. System colors and UA form
controls are rendered with different colors depending on the
color-scheme set on an element. Authors can have the same
possibility through the light-dark() function: #target {
background-color: light-dark(lime, green); } The #target element
will have a green background if the used color-scheme for the
element is 'dark'. Otherwise, the background will be lime.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



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

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=262914) Enabled by
default: https://github.com/WebKit/WebKit/pull/23364

/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



Debuggability

Colors in the light-dark() function can be edited like it is
currently possible for the color-mix() function. No changes needed.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

Existing tests:
https://wpt.fyi/results/css/css-color/light-dark-basic.html
https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
https://wpt.fyi/results/css/css-color/light-dark-inheritance.html
To be added by Chromium implementation:
https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html

(https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)




Flag name on chrome://flags

None


Finch feature name

CSSLightDarkColors


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1490618


Estimated milestones

Shipping on desktop 123

Shipping on Android 123

Shipping on WebView 123



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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


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

.

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

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

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-24 11:45, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tuesday, January 23, 2024 at 11:17:35 AM UTC+1 Mike Taylor wrote:

Thanks Liam. This seems fine to me given that both parties need to
opt in.

LGTM1

On 1/22/24 6:10 PM, Liam Brady wrote:

Hi Mike,

"crossOrigin=true" is just a typo. "crossOrigin" was the original
naming convention for "crossOriginExposed". It was renamed during
code review, but I forgot to update the I2S wording to match that.

We chose to not go with Permissions-Policy for a few reasons.
First is that for fenced frames created through something like
Protected Audience, they have a fixed list of permissions that
must be enabled for the frame to load, so refactoring that to
support one permissions policy that can be either enabled or
enabled would be a lot of effort. Doing that would also allow 1
bit of information to leak from the embedder to the fenced frame,
which is the whole reason we locked down permissions policies in
the first place. We also didn't want the embedder to have any
control over how this header is set (such as having an embedder
opt in on the frame's behalf), and since permissions policies are
based on inheritance, that was something we needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5
mike...@chromium.org wrote:

Hi Liam,

On 1/16/24 3:49 PM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org


Explainer(s)

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



Spec(s)

https://github.com/WICG/fenced-frame/pull/133



Summary

As part of the Privacy Sandbox experiment, we introduced a
way for beacons to be sent automatically if a top-level
navigation is initiated from within an ad frame

.
At the time, we restricted this feature to frames and
subframes that were same-origin to the root ad frame.
However, there is a use case that this is not able to
handle. With third-party ad serving (3PAS), the actual
contents of the ad (including links/click handlers) are
loaded in a cross-origin subframe. Because it is
cross-origin, the frame does not get access to the automatic
beacon API, and therefore is not able to report a top-level
navigation when a user clicks on the ad.


A cross-origin subframe can now opt in to sending automatic
beacons by setting a new response header:
"Allow-Fenced-Frame-Automatic-Beacons". The cross-origin
frame still cannot set automatic beacon data; instead, the
main ad frame will set the automatic beacon data, but opt in
to having the data be used for cross-origin automatic
beacons using a new "crossOrigin=true" parameter. When these
2 criteria are met, the cross-origin subframe will send an
automatic beacon when a top-level navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed"
boolean defined in the spec? Or just a typo?

Another question: is there any reason you chose to create a
new HTTP header, rather than use something like
Permissions-Policy? (Maybe that's not supported for fenced
frames?)



This feature will also fix a separate issue

brought
up externally and allow for ad components to opt into
sending automatic beacons without needing to invoke
setReportEventDataForAutomaticBeacons(); they instead will
just need to supply the
"Allow-Fenced-Frame-Automatic-Beacons" response header. This
will not remove the existing way for ad components to opt
into sending beacons.


Blink component

Blink>FencedFrames




TAG reviews and status

Fenced frames existing TAG review appended with these spec
changes https://github.com/w3ctag/design-reviews/issues/838#




Link to Origin Trial feedback summary

No Origin Trial performed


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

Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for
these feature changes.


Risks


Compatibility

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Daniel Bratell]

Unreliable use counters sound scary. We base a lot of decisions off 
those. So far they have only been shown to over-count though? But still, 
would be great if someone could get a grip on that bug and either fix it 
or make us understand what is going on.


For this feature, what is the status of getHTML()? Can we redirect users 
to it already?


/Daniel

On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
I guess a theoretical risk is that someone feature-checks for 
HTMLTemplateElement.shadowRootMode and then assumes the existence of 
getInnerHTML() based on that check. But given the lack of usage in the 
top sites I agree that this seems to not be an issue in practice.


I saw that there's a support email listed at 
https://www.heap.io/auryc. Maybe worth a ping?


-- Dan

On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:

On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
wrote:

Yeah, I think the risk is low here.


Great, thanks!

FWIW, I couldn't find any relevant github or contact info for
this library but if you had better luck finding contact
information, we might as well file an issue or send an email.


I also tried to find it, but failed. It appears to be closed source.

Thanks,
Mason


Thanks,
Mason



/Gecko/: No signal

/WebKit/: No signal

/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



Debuggability

None



Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/1519972

Estimated milestones

No milestones specified



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


This intent message was generated by me, manually,
because of this bug

.

-- 
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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%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/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.com.

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

[Daniel Bratell]

Sounds like something that should be reflected in the specs. Again, not 
directly related to this Intent, but maybe something that should happen 
in parallel.


/Daniel

On 2024-01-17 23:38, 'Siye Liu' via blink-dev wrote:
Blink has similar concept called "affinity" when placing caret at 
wrapped line. definition: 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/visible_position.h;l=39-54 



Thanks,
Siye

On Wednesday, January 17, 2024 at 6:35:14 AM UTC-8 Daniel Bratell wrote:

This is not directly related to this one function but more to the
whole API. I quickly skimmed the spec and I could not find out how
it handles line breaks which make caret positions ambigious?

When you press the END key at one line, and the HOME key at the
following line your caret DOM position can be the same, but the
visual caret positions should be different, and so should certain
actions like arrow-down and arrow-up.

When developing code to handle this in Opera, I solved it by
letting carets know if they were connected forward or backwards
(basically a bool) in the dom element, but maybe this is solved in
some other way now?

/Daniel

On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:

Hi Brian,

To answer your question,
1. This prototype only covers the main dom scenario
(https://crbug.com/388976). Shadow dom scenario is tracked in
https://crbug.com/1514810.
2. The prototype should have similar behavior as
caretRangeFromPoint's implementation in Blink (when the point is
over an input element, the returned CaretPosition should be the
nearest ancestor of the input element) because I expect both APIs
share same hit testing logic under the hood.

Once the prototype is ready for dev trial, we can discuss further
about improving current implementation in both
caretRangeFromPoint and caretPositionFromPoint in Blink.


Thanks,
Siye

On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:

Hi,

Will this also cover the behavioral differences between
caretPositionFromPoint as implemented in Gecko and
caretRangeFromPoint as implemented in Blink such as:

1. caretPositionFromPoint in Gecko digs into shadow DOM
elements whereas caretRangeFromPoint in Blink does not.
2. When the point is over a text input element,
caretPositionFromPoint in Gecko returns the text input
element and offset into it but caretRangeFromPoint in Blink
returns the nearest ancestor of the text input element. (Note
that caretRangeFromPoint in Webkit returns the text input
element but always returns a zero offset into it.)

Thanks,

Brian

2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

Contact emails
si...@microsoft.com, sa...@microsoft.com

Explainer
None

Specification

https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

Summary

This new API allows users to get current caret position
from a given screen point. The API returns a
CaretPosition object which represents the caret position
indicating current text insertion point including the
containing DOM node, caret's character offset, and the
client rectangle of caret range.



Blink component
Blink>CSS

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>

Motivation

document.caretPositionFromPoint API is in CSSOM View and
is already implemented by Gecko. WebKit/Blink has similar
document.caretRangeFromPoint API which returns a text
range indicating the text insertion point. The existing
API was in CSSOM View at the time it was implemented:
https://bugs.webkit.org/show_bug.cgi?id=27046

http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
The existing API was replaced by the new API later:
https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch
happened around 2009 and we don't have the historical
context about the decision. Given how long it has been
since the spec was updated, we believe it's best that
Blink complies with the spec so that future innovations
with the API can be spec compliant and have lower
interop/compat risk.



Initial public proposal
None

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

Gecko already implemented the API. Webkit/Blink didn't
  

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

[Daniel Bratell]

This is not directly related to this one function but more to the whole 
API. I quickly skimmed the spec and I could not find out how it handles 
line breaks which make caret positions ambigious?


When you press the END key at one line, and the HOME key at the 
following line your caret DOM position can be the same, but the visual 
caret positions should be different, and so should certain actions like 
arrow-down and arrow-up.


When developing code to handle this in Opera, I solved it by letting 
carets know if they were connected forward or backwards (basically a 
bool) in the dom element, but maybe this is solved in some other way now?


/Daniel

On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:

Hi Brian,

To answer your question,
1. This prototype only covers the main dom scenario 
(https://crbug.com/388976). Shadow dom scenario is tracked in 
https://crbug.com/1514810.
2. The prototype should have similar behavior as caretRangeFromPoint's 
implementation in Blink (when the point is over an input element, the 
returned CaretPosition should be the nearest ancestor of the input 
element) because I expect both APIs share same hit testing logic under 
the hood.


Once the prototype is ready for dev trial, we can discuss further 
about improving current implementation in both caretRangeFromPoint and 
caretPositionFromPoint in Blink.



Thanks,
Siye

On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:

Hi,

Will this also cover the behavioral differences between
caretPositionFromPoint as implemented in Gecko and
caretRangeFromPoint as implemented in Blink such as:

1. caretPositionFromPoint in Gecko digs into shadow DOM elements
whereas caretRangeFromPoint in Blink does not.
2. When the point is over a text input element,
caretPositionFromPoint in Gecko returns the text input element and
offset into it but caretRangeFromPoint in Blink returns the
nearest ancestor of the text input element. (Note that
caretRangeFromPoint in Webkit returns the text input element but
always returns a zero offset into it.)

Thanks,

Brian

2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

Contact emails
si...@microsoft.com, sa...@microsoft.com

Explainer
None

Specification
https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

Summary

This new API allows users to get current caret position from a
given screen point. The API returns a CaretPosition object
which represents the caret position indicating current text
insertion point including the containing DOM node, caret's
character offset, and the client rectangle of caret range.



Blink component
Blink>CSS



Motivation

document.caretPositionFromPoint API is in CSSOM View and is
already implemented by Gecko. WebKit/Blink has similar
document.caretRangeFromPoint API which returns a text range
indicating the text insertion point. The existing API was in
CSSOM View at the time it was implemented:
https://bugs.webkit.org/show_bug.cgi?id=27046

http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
The existing API was replaced by the new API later:
https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch
happened around 2009 and we don't have the historical context
about the decision. Given how long it has been since the spec
was updated, we believe it's best that Blink complies with the
spec so that future innovations with the API can be spec
compliant and have lower interop/compat risk.



Initial public proposal
None

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

Gecko already implemented the API. Webkit/Blink didn't
implement it. The interop risk is that it's unclear at this
moment about Webkit's position on this. We won't be able to
achieve full interop with this API if Webkit isn't willing to
support this API. There is a compat risk too if we decided to
deprecate the old API: https://crbug.com/690599



/Gecko/: Shipped/Shipping

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

/Web developers/: Positive
(https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34)
Web developers are asking to have
document.caretPositionFromPoint API implemented in Blink:
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

/Other signals/:

WebView application risks

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

[Daniel Bratell]

On 2024-01-10 18:27, Noam Rosenthal wrote:



On Wed, Jan 10, 2024 at 5:25 PM Michal Mocny  wrote:



On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal
 wrote:


Great, perhaps the best way forward is with a flag that's
starting as "stable" from the get go and we can later remove it.


Just curious-- is this the same as a "kill switch" (default
enabled flag)? (which are already included in the guidelines)


Yea, though the kill switch is 6 lines and the feature itself is 7 
lines (albeit web-facing) so the value is marginal :)


The value comes from being able to do it remotely, by pushing an updated 
finch configuration rather than rebuilding and upgrading everyone's binary.


If we have misunderstood the risk, or if there is a critical bug. We 
make every feature developer pay the (small) cost of adding a flag to 
save everyone a ton of effort for the hopefully rare occurrences when it 
is needed.


/Daniel

--
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/2ddf6cbd-9f0e-4ae7-8b72-ac1b0d4c754b%40gmail.com.

Re: [blink-dev] Re: Intent to Ship: Use specific fetch destination for JSON/CSS modules

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-10 17:46, Philip Jägenstedt wrote:

LGTM2, thanks for fixing this!

On Wed, Jan 10, 2024 at 5:03 PM Yoav Weiss  wrote:

LGTM1



On Wed, Jan 10, 2024 at 4:58 PM Nicolò Ribaudo
 wrote:

Yes I made a mistake in the description. The destination for
CSS modules is indeed "style", and not "css". Thanks for
catching it!


Thanks for confirming!! :)


On Wednesday, January 10, 2024 at 3:55:29 PM UTC+1 Yoav Weiss
wrote:

On Monday, January 8, 2024 at 7:59:23 PM UTC+1
nrib...@igalia.com wrote:

Hello,

For those looking for the spec diff relative to this
change, you can find it in the HTML and Fetch PRs that
introduced it:
https://github.com/whatwg/html/pull/9486
,
https://github.com/whatwg/fetch/pull/1691


---
Nicolò Ribaudo
On Monday, January 8, 2024 at 2:20:43 PM UTC+1 Nicolò
Ribaudo wrote:

Contact emails nrib...@igalia.com


Explainer None

Specification
https://html.spec.whatwg.org/#fetch-a-single-module-script



Summary

CSS and JSON modules will be fetched using a
specific fetch destination (either "css" or
"json") rather than a generic "script", that is
normally used for JavaScript modules. This has the
following effects: - the `Accept` HTTP header in
the request will describe the expected mime type
(`text/css,*/*;q=0.1` or
`application/json,*/*;q=0.5`) - those modules will
respect the style-src or connect-src Content
Security Policies, rather than using JavaScript's
script-src - When inspecting the request's
destination (either through a service worker or
through the `Sec-Fetch-Destination` HTTP header)
it will be reported as `"css"` or `"json"`, rather
than empty.


Can you confirm that you meant "style" destination for CSS
modules, rather than "css"?
That's what seemed to be defined in the spec PR, and it
also makes more sense IMO. (as it aligns with , and doesn't a new destination for CSS
modules)



Blink component Blink>HTML>Modules




Search tags CSS modules
,
JSON modules
,
imports
,
CSP ,
fetch destination



TAG review None

TAG review status Not applicable

Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: Positive
(https://github.com/WebKit/standards-positions/issues/128
)
Webkit was supportive of the import attributes
proposal conditional on these changes to how
JSON/CSS modules are fetched

/Web developers/: No signals

/Other signals/:

Security

This feature better aligns usage of CSP directives
to user expectations (e.g. using style-src for CSS)



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, ChromeOS, Android,
and Android WebView)? No

Is this feature fully tested by web-platform-tests

Re: [blink-dev] Intent to Ship: CSS Pseudo Element ::backdrop inheriting from Originating Element

[Daniel Bratell]

LGTM2

/Daniel

On 2024-01-10 16:41, Rick Byers wrote:
Given how trivial and niche this is and that WebKit and Gecko have 
both shipped this without any apparent compat fallout, I agree the 
compat risk is very low. I'm ok treating it as a bugfix, but please 
circle back here (and consider using your killswitch) if you hear of 
any breakage in practice. LGTM1 to ship.


On Tue, Jan 9, 2024 at 6:50 AM Rune Lillesveen  
wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-position-4/#backdrop


Summary

The ::backdrop pseudo element used to inherit from initial values.
That meant ::backdrop could not use custom property values unless
specified directly on the ::backdrop rule. The specification has
now changed so that ::backdrop inherits from the originating
element, and with that the implementation.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

A compatibility risk is that existing content may rely on
inheriting initial values. For instance, this rule may change from
having a backdrop with the initial foreground color to using the
color property of the originating element: ::backdrop {
background: currentColor } Interop risk is low for shipping since
Firefox and Safari already do ship.



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1855668) Shipped in
Firefox 120

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

/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



Debuggability

N/A



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.live/css/css-position/backdrop-inherit-computed.html
https://wpt.live/css/css-position/backdrop-inherit-rendered.html



Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

BackdropInheritOriginating


Requires code in //chrome?

False


Tracking bug

https://crbug.com/827397


Estimated milestones

Shipping on desktop 122
DevTrial on desktop 119

Shipping on Android 122
DevTrial on Android 119

Shipping on WebView 122



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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


-- 
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/CACuPfeRpWk%2BOh_g1LD7wUwXk7L1Agu%2Bd84Myk8uCkZQy_-S35g%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/CAFUtAY-8sefA9ZJh5q0cDnqRjUAcaBBM_wEVw0DLvHiqYErCtw%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 

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

[Daniel Bratell]

LGTM1 - I agree that this is small enough to just proceed.

/Daniel

On 2024-01-10 16:40, Noam Rosenthal wrote:



On Wed, Jan 10, 2024 at 3:32 PM Rick Byers  wrote:

Hi Noam,
This seems pretty trivial to me. The spec change is trivial and
presumably any review feedback will only be editorial (not
functional), so I'm OK not blocking approval on the spec PR
landing. But could you get a WPTs implemented and at least ready
to land (eg. along with the implementation CL) before we approve
please?


Of course, already done:
https://github.com/web-platform-tests/wpt/pull/43919


Thanks,
   Rick

On Mon, Jan 8, 2024 at 12:10 PM Noam Rosenthal
 wrote:


Contact emails


nrosent...@chromium.org


Explainer


None (this is a small change to an existing feature)


Specification


https://github.com/whatwg/html/pull/10035


Summary


Currently 

Re: [blink-dev] Intent to deprecate and remove import assertion 'assert' syntax

[Daniel Bratell]

LGTM3 for the plan as outlined by Mike and Philip.

/Daniel

On 2023-12-14 10:18, Philip Jägenstedt wrote:

On Wed, Dec 13, 2023 at 6:10 PM Shu-yu Guo  wrote:

On Wed, Dec 13, 2023 at 9:03 AM Philip Jägenstedt
 wrote:

LGTM2 for Mike's plan of deprecating for 3 milestones, doing
outreach, and then revisiting this thread.

If we still know of serious breakage after this, is it an
option to simply support both keywords indefinitely, but treat
`assert` as legacy? Documentation, linters and autoformatters
could all direct developers to `with`, without breaking any
existing sites.


Yes, it is an option to support both keywords indefinitely and
treat `assert` as legacy. TC39 consensus includes `assert` legacy
support, on account of Chrome having shipped in good faith. We're
trying to remove it for maximal interop since no other browsers
shipped `assert`, but if it's not feasible it will not be a
willful violation of spec to continue shipping it.


I see, thank you for clarifying. Looking forward to seeing what the 
deprecation and outreach result in.

--
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/CAARdPYetzaKxSi_yWTCHd4xJrLh1OAY4YQBdwEN1cHd22kUnoA%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/16f2bc22-1ed8-412e-ae61-89d64e6392a8%40gmail.com.

Re: [blink-dev] Intent to Ship: CSSKeyframesRule.length

[Daniel Bratell]

LGTM2

I would recommend a flag but given Philip's arguments I'll not consider 
it an absolute requirement.


/Daniel

On 2023-12-13 15:28, Philip Jägenstedt wrote:

LGTM1 with or without a feature flag.

I'm comfortable to LGTM this even without a flag because the length 
property was exposed in Gecko 
 
and WebKit 
 quite 
recently, so `'length' in CSSKeyframesRule.prototype` is not a 
reasonable proxy for "is not Chrome". Firefox 108 and Safari 16 
(source 
) 
would fall into the same code path, and those are still in wide enough 
use that this API doesn't work for engine detection.


On Mon, Dec 11, 2023 at 3:48 PM Mike Taylor  
wrote:


This seems like a fairly trivial and useful addition, but can we
put this behind a feature flag? It's not hard to imagine some code
looking at `CSSKeyframesRule.length` as a proxy for "is not
Chrome" and something going wrong (though, I imagine this is a
very small risk).


https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

On 12/8/23 11:50 PM, Amos Lim wrote:



Contact emails

eui-sang@samsung.com


Explainer

None


Specification

https://drafts.csswg.org/css-animations/#interface-csskeyframesrule


Summary

Exposes length attribute of CSSKeyframesRule. Interfaces that
support indexed properties must define an integer-typed attribute
named "length".



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/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



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/css-animations/idlharness.html
https://wpt.fyi/results/css/cssom/CSSKeyframesRule.html



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


Estimated milestones

No milestones specified



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

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/CAOGEg00LjpMvMpkdeOQWaLoCsgeCrDMck9wMP4wvX7ttMEE3SQ%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/cc41c466-0562-455c-a6de-2ac2094693de%40chromium.org

.

--
You received 

Re: [blink-dev] Intent to Ship: Third-party cookie deprecation exemption heuristics

[Daniel Bratell]

While this is approved, I do have a followup question about:

> we intend to eventually retire these heuristics as alternative 
solutions become widely used, subject to further feasibility analysis.


In many other plans there have been dates or milestones mentioned, and 
even though they have not always been achievable, they have acted as a 
clear signal that something will happen.


In comparison this sounds open ended, and almost defeatist. Would it be 
good to set a target end date on this as well?


/Daniel

On 2023-12-06 17:11, Yoav Weiss wrote:

LGTM3

On Tuesday, December 5, 2023 at 6:53:30 PM UTC+1 Rick Byers wrote:

LGTM2

Thank you for putting the extra rigor and effort into trying to
specify and align on this behavior, rather than just copy the
precedent set by the other two engines in relying on
non-standards-track heuristics! It's exactly in these messy
real-world examples of web behavior that our principles around
real interoperability are tested. Also +1 to not worrying too much
about venue at this stage of paying back technical debt incurred
by other engines. I've always seen the webcompat spec as the place
for pragmatically documenting what the web really depends on when
the "right" group was too idealistic to want to be accountable for
the reality. If we can graduate some or all of this out of web
compat into better homes, then great! But if the PR doesn't land
in webcompat soon (before the end of the year?) then we should
explore other lightweight temporary homes.



On Tue, Dec 5, 2023 at 12:40 PM Mike Taylor
 wrote:

I see this as a critical web compatibility intervention, so LGTM1.

It seems like there is some disagreement about spec venue
(compat vs fetch/html), but I don't think we need to block on
landing given the other browsers shipped their heuristics
without specifying in any standards venue. Thanks for doing
the work to unify these and push for interop.

And good luck on removing them one day (one can dream...).

On 12/4/23 5:55 PM, 'Anton Maliev' via blink-dev wrote:



Contact emails

amal...@chromium.org 

johann...@chromium.org 

rtarp...@chromium.org 

wanderv...@chromium.org 


Explainer


https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md




Specification

Pull request: https://github.com/whatwg/compat/pull/253



Summary

This proposal examines a heuristics-based pattern of allowing
temporary third-party cookie access in limited scenarios,
which would mitigate site breakages after third-party cookies
are blocked by default in Chrome. These scenarios are tightly
scoped and build on similar work from other browsers such as
Firefox (docs

)
and Safari (docs

).


These heuristics will include:

1.

When a third party is loaded in a popup, after possible
redirects, and the third party receives user interaction,
the third party receives storage access on the opener site.

1.

Use cases: identity provider login, payments
processing, etc.

2.

Example: nintendo.de (bug
)

2.

When a first party redirects to a third party, the third
party receives a user interaction, and navigates back to
the first party, the third party receives short-term
storage access on the opener site.

1.

Use cases: identity provider login, etc.

2.

Example: pixnet.net (bug
)


See the explainer

for
details on background, additional considerations and our
approach to prototyping. Aligned with what other browsers
have indicated, we intend to eventually retire these
heuristics as alternative solutions become widely used,
subject to further feasibility analysis.


Blink component

Privacy>Heuristics
 

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

[Daniel Bratell]

LGTM3

/Daniel

On 2023-11-29 18:01, Chris Harrelson wrote:

LGTM2

On Wed, Nov 29, 2023 at 8:27 AM Yoav Weiss  wrote:

LGTM1

This seems to reduce interop risk. Thanks!

On Tuesday, November 21, 2023 at 6:45:00 PM UTC+1 snianu wrote:


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 it

https://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 

-- 

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

[Daniel Bratell]

LGTM2

/Daniel

On 2023-11-23 10:11, Yoav Weiss wrote:

LGTM1

These all seem like useful improvements! :)


On Wed, Nov 22, 2023 at 8:14 PM Jeremy Roman  wrote:



On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss
 wrote:



On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman
 wrote:


Note: This intent email spans three Chromestatus
entries for different sub-features that we
experimented with together and would like
permission to ship together in M121.


Contact emails

jbro...@chromium.org, adith...@chromium.org,
isabo...@google.com, dome...@chromium.org, mc...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html


Summary

(1) An extension to speculation rules syntax that lets the
browser obtain URLs for speculation from link elements in
a page. They may include criteria which restrict which of
these links can be used.


Any specific parts of the explainer/spec that cover this one?


Sure:
https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules

https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching

https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links


That's very useful, thanks!!




(2) Adding the eagerness field to the speculation rules
will let the developers control how eagerly the browser
preloads links in order to balance the performance
advantage against resource overhead. This field accepts
one of "conservative", "moderate", "eager", or "immediate"
strings as the value, and it is applicable to both
"prefetch" and "prerender" actions and both "list" or
"document" sources. If not explicitly specified, list
rules default to "immediate" and document rules default to
"conservative".


(3) Currently developers can only specify speculation
rules using inline script tags. The proposed feature
provides an alternative through the "Speculation-Rules"
header. Its value must be a URL to a text resource with
"application/speculationrules+json" MIME type. The
resource's rules will be added to the document's rule set.



Blink component

Internals>Preload




TAG review

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


TAG review status

Issues addressed (TAG still has reservations)


Chromium Trial Name

SpeculationRulesPrefetchFuture


Link to origin trial feedback summary


https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing


Origin Trial documentation link


https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md


WebFeature UseCounter name

SpeculationRulesDocumentRules
SpeculationRulesSelectorMatches
SpeculationRulesHeader
SpeculationRulesExplicitEagerness


Risks



Interoperability and Compatibility

Because authors cannot rely on document rules being
evaluated (or preloading generally), applications which
use them should function correctly in other browsers and
should continue to function correctly were the feature to
be deprecated. Of course, ideally other browsers do find
it compelling to implement this feature.


Similar reasoning applies to the response header and
eagerness field.



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

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

/Web developers/: Positive

(https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
positive feedback from Akamai and use within Chrome on
web.dev 

/Other signals/:


Activation

Some developers might not be immediately aware of which
URLs they can prefetch or prerender without side effects;
this risk is reduced if they primarily use the feature for
same-origin URL patterns they are familiar with.

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

[Daniel Bratell]

LGTM3

/Daniel

On 2023-11-29 17:45, Chris Harrelson wrote:

LGTM2

On Wed, Nov 29, 2023 at 7:40 AM Yoav Weiss  wrote:



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

I wonder if we should hold off on adding @import support until
such a solution emerges.


On second thought, since we didn't delay `layer`, there's no real
reason to delay shipping here.
But I strongly urge you to nudge this along :)


In any case, similar to layer


 support,
you probably want to add tests that make sure that the preload
scanner is properly preloading such inlined rules, and want to
make sure that developer facing advice clarifies the huge cost
of using this in external styles.

On Wednesday, November 22, 2023 at 2:33:22 PM UTC+1 Daniil
Sakhapov wrote:

Yes, thanks, I saw this discussion and will keep my eye on
it. So, once the solution for back comp is found there,
I'll work on it.

On Wednesday, November 22, 2023 at 12:40:27 PM UTC+1 Noam
Rosenthal wrote:

One open issue that I didn't see mentioned and is
worth noting, is a missing equivalent in 
elements (similar to . This creates an
inconsistency where you can have conditional imports
in CSS but not directly from HTML. This is mentioned
in https://github.com/whatwg/html/issues/7540. Not
saying it should block shipping, but rather that it
should be considered an open issue.

On Wed, Nov 22, 2023 at 5:47 AM Yoav Weiss
 wrote:

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 emails

sakha...@chromium.org


Specification

https://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 component

Blink>CSS




TAG review

None


TAG review status

Not 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://flags

CSSSupportsForImportRules


Requires code in //chrome?

False


Estimated milestones

DevTrial on desktop 121

DevTrial on Android 121



Anticipated spec changes

Open questions about 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 

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

[Daniel Bratell]

Thanks for getting the security people to weigh in on this because that 
was really the main question for me. And it will still be controllable 
by a finch flag.


LGTM1 dependent on there being a published document outlining the 
options for web developers (i.e. the document you are already working on).


/Daniel

On 2023-11-10 09:45, Fergal Daly wrote:

On Fri, 10 Nov 2023 at 17:29, Yoav Weiss  wrote:

Thanks David!
It's great to see that this will be disabled in modes where we
*know* the machine is shared.

Fergal - could you address concerns about web developer advice?
What should we tell web developers to do on their logout pages?


Yes, we are in discussion with dev-rel about this. They were already 
looking at producing advice for auth best practices. We will ensure 
that this is covered in that,


F



On Fri, Nov 10, 2023 at 8:37 AM David Dworken
 wrote:

Chiming in to say that we discussed the security concerns
around this proposal quite extensively internally and overall
we believe that with the short timeout, the security risks are
acceptable. The residual security risk is for servers that
implement purely server-side logouts and is only exploitable
for a very short period of time (3 minutes). In addition,
other mitigations like this one
 further
reduce the risk such that we believe it is unlikely that this
will lead to new security issues.

On Friday, October 13, 2023 at 7:14:46 AM UTC-7
vmp...@chromium.org wrote:

On Fri, Oct 13, 2023 at 12:00 AM 'Fergal Daly' via
blink-dev  wrote:

On Thu, 12 Oct 2023 at 23:05, Yoav Weiss
 wrote:



On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin
 wrote:

Are there any spec changes planned for this
feature? I'm not sure if the README linked
under Specification is meant to make it into
WHATWG, maybe to close out
https://github.com/whatwg/html/issues/7189

The only spec I could find about CCNS is
https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5,
so I'm not sure how to reconcile possibly
contradicting language in the specs


Great questions! Fergal - can you answer that?


RFC9111 is about HTTP caches. BFCache is not a HTTP
cache, so RFC 9111 does not apply. Of course the
reality of implementations and expectations vs spec is
a problem. Some more discussion here




I'm not sure I agree with this, or the reasoning in the
link. First of all, this intent thread is
about ignoring CCNS in _some cases_. In other cases, CCNS
is respected, so it seems like BFCache is de facto subject
to RFC 9111.

This is, I guess, a bit philosophical but the spec says:
the cache MUST NOT intentionally store the information in
non-volatile storage and MUST make a best-effort attempt
to remove the information from volatile storage as
promptly as possible after forwarding it.

Note that the spec here does not make any exceptions for
things like cookie state not changing or anything else.
The document when frozen is indeed a volatile storage of
the server response, processed and stored in some
particular format (ie the DOM tree). I admit it's a bit
weird to think about it this way, since the live document
is technically also this cache. Whereas I agree that
BFCache is not strictly an HTTP Cache, I don't quite
follow why CCNS should not apply to the BFCache in some cases.

To me, BFCache seems like "a better http cache" which
already has rendered results, not a completely separate
cache that is not subject to CCNS.

But I'm late to the game, and I see that the topic of
"BFCache is not HTTP Cache" has already been discussed a
lot. I'm not convinced by existing arguments, but I also
don't think I'll be able to convince anyone of my position.

My problem with the consensus in
https://github.com/whatwg/html/issues/5744 is the
following. People seem to agree that we don't want a *new*
api that specifically prevents pages from entering
BFCache. I don't believe it's appropriate to draw a
conclusion that there 

Re: [blink-dev] Intent to Deprecate & Remove: Third-Party Cookies

[Daniel Bratell]

You say Q1 2024, but do you know a more exact date? I ask because we are 
entering the holiday freeze period when companies do no changes 
whatsoever and even if this makes a site want to fix something, they 
might not be able to until some time into the quarter.


I also think it might be good to split it into the 1% part, and a 100% 
part since it is hard to judge the web compatibility level already and 
that is part of what the 1% run will do.


/Daniel

On 2023-11-13 17:52, David Dabbs wrote:

Thanks for the explanation.

David


On Monday, November 13, 2023 at 9:30:55 AM UTC-6 Johann Hofmann wrote:

Hey David, yeah, that was me trying to fix the entry not showing
up on API Owner dashboards. I don't think that was what fixed it
though, so I can change it back to "In Developer Trial" (which
feels like the most accurate right now?)

Thanks!

Johann


On Mon, Nov 13, 2023, 16:10 David Dabbs  wrote:

This morning's Implementation status change to /Deprecated/
results in

Deprecate Third-Party Cookies
 (Deprecated)

Did you intend to also rename the feature to "Third-Party
Cookies?"


Thanks



On Monday, November 13, 2023 at 4:20:47 AM UTC-6
yoav...@chromium.org wrote:

LGTM1

I cannot imagine a more thorough and thoughtful approach
than the one the Privacy Sandbox team has taken to tackle
this significant change to the web's privacy model while
minimizing breakage and providing replacement APIs. Thanks
for pushing this important work through!!

On Mon, Nov 13, 2023 at 10:31 AM Johann Hofmann
 wrote:


Contact emails

joha...@chromium.org, wande...@chromium.org,
dylan...@chromium.org, kaust...@chromium.org,
jka...@chromium.org, john...@chromium.org


Explainer

For general information on Privacy Sandbox for the Web
and Google’s plans to phase out third-party cookies,
seehttps://privacysandbox.com/open-web/
.


For additional information on the planned semantics of
third-party cookie blocking and its interaction with
the SameSite cookie attribute, see

https://github.com/DCtheTall/standardizing-cross-site-cookie-semantics




Specification

The Cookies RFC contains some language

that,
in theory, allows user agents to block third-party
cookies, leaving a lot of details unspecified. We are
not happy with this status quo and are collaborating
with other browsers on a significant spec refactoring
effort called cookie layering
to
give Fetch/HTML more responsibility over specifying
how and when cookies are stored and attached, as well
as a WebAppSec Note based on our existing explainer

that
describes how cookie blocking interacts with SameSite
cookies.


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
   

Re: [blink-dev] Intent to Ship: EditContext API

[Daniel Bratell]

LGTM4 (yes, a bonus LGTM since I felt ninja'd by Mike and I think this 
will be a nice addition to the web platform)


/Daniel

On 2023-11-08 20:42, Mike Taylor wrote:


LGTM3

On 11/8/23 12:13 PM, Alex Russell wrote:

+1 to the evidence from OT being persuasive.

LGTM2

On Wednesday, November 8, 2023 at 8:56:24 AM UTC-8 Rick Byers wrote:

It certainly sounds to me that there's additional work to be done
here, but I agree with Daniel that changing event order is not
something we can do lightly. Gregg, could you please file an
issue  on the spec so
the discussion can continue there?

Given the positive feedback we have from major real-world
deployments in OT and the 3+ years of design work that's gone
into this API via the editing WG, I personally don't think
this concern is sufficient to block shipping at this stage.
Editing is going to continue to be an area to work on improving
rationality and interop and shipping this API now seems like the
right pragmatic next step to me. Since fundamentally fixing this
issue is going to need breaking changes anyway, and EditContext
is most likely to be eagerly adopted just by a few large
applications, I'm reasonably confident that we can continue to
improve over time as driven by real-world deployment experience.
LGTM1

Rick

On Wed, Nov 1, 2023 at 2:55 PM 'Daniel Clark' via blink-dev
 wrote:

To the extent that firing keydown before compositionstart is
a problem for apps, that’s an issue that equally affects
contenteditable. Changing the order may be a good
improvement, but it will be a breaking change for the web
that should be carefully considered and hopefully done in
tandem with Firefox and Webkit so that browsers can arrive at
matching behavior. I think tying EditContext to this is not
necessary, as EditContext aims to solve a variety of problems
around receiving text input aside from how keydown
specifically is handled. Since EditContext does not make any
changes around the order of keydown relative to other events,
shipping EditContext should not add any additional
complications to changing that event order if the Editing
Working group decides to go that route.

The API is supported on Mac as well. If the sample you tried
didn’t work it may be because we failed to update it in
response to breaking changes. This sample is up-to-date and
should serve to show simple text input and composition:
https://magic-organic-yam.glitch.me/
. Note that a lot of
basic editing functionality isn’t implemented here, and the
text formatting for compositions is with highlights rather
than underlines -- this was built for testing the API, not
real-world editing.

As part of the Origin Trial, developers at Google Docs and
Adobe included Mac in their testing and reported several
Mac-specific issues that we’ve since fixed. If you’d like to
try with the Docs implementation, let me know and I can ask
about getting you opted in to that rollout.

For reconversions, when a page is using EditContext the same
UI will still be available to the user via the menu or
hotkeys. The page keeps the platform informed about which
text is selected by the user by calling
EditContext.updateSelection()
.
When the user triggers a reconversion, Blink will send the
page another TextUpdateEvent
indicating
to it that it should change the text in the specified range
to the new value.

-- Dan

*From:*Gregg Tavares 
*Sent:* Tuesday, October 31, 2023 5:19 PM
*To:* Daniel Clark 
*Cc:* Gregg Tavares ; blink-dev
; Alex Keng ;
Anupam Snigdha ; ko...@chromium.org
*Subject:* Re: [blink-dev] Intent to Ship: EditContext API




You don't often get email from g...@chromium.org
. Learn why this is important




I don't think the keydown issue should be ignored until
after shipping this API. I think it's essential for this API
to actually function.

Consider an app that responds to Control-Shift-J for say
"jump to definition".

keydown = key = 'Control'

keydown = key = 'Shift' (CtrlKey = true)

keydown = key = 'K' (CtrlKey = true, Shift = true)  And the
app would trigger it's jump-to-definition command  But what
should have happened is the IME switched to 

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

[Daniel Bratell]

Hi, could you please request signals from the other vendors? 
https://bit.ly/blink-signals will tell you how they work.


Also, you may want to file a TAG review, or give them a FYI or let us 
know why that is not necessary.


/Daniel

On 2023-11-08 13:56, 'Munira Tursunova' via blink-dev wrote:



Contact emails

moon...@google.com, dr...@google.com


Explainer

https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing


Specification

https://drafts.csswg.org/css-fonts-4/#font-palette-prop


Summary

The CSS font-palette property allows selection of a specific palette 
used to render a font. The CSS Fonts 4 spec defines the animation 
behavior of this property as discrete, which is insufficient to 
achieve a smooth transition between two selected palettes. Instead, 
animating the font-palette property should happen by interpolating 
each of the colour record values from the defined palette, i.e. if the 
start or the end of the animation has a different colour value for 
some record in the palette, such colour value should be interpolated.




Blink component

Blink>Fonts 




Search tags

font-palette , 
animation , 
transition , 
font-palette-values 
, color 
fonts 



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Low, new feature, was resolved by W3C working group 
https://github.com/w3c/csswg-drafts/issues/8922#issuecomment-1720930646, 
but not yet implemented in other browsers.



/Gecko/: No signal Not implemented.

/WebKit/: No signal Not implemented.

/Web developers/: Positive 
(https://css-tricks.com/colrv1-and-css-font-palette-web-typography/#:~:text=Another%20limitation%3A%20animations%20and%20transitions%20from%20one%20font%2Dpalette%20to%20another%20don%E2%80%99t%20interpolate%20%E2%80%94%20meaning%20you%20can%20switch%20instantly%20from%20one%20palette%20to%20another%2C%20but%20can%E2%80%99t%20gradually%20animate%20between%20them.%20My%20dream%20of%20a%20luridly%20animated%20emoji%20font%20is%20sadly%20unrealized) 
Ollie Williams expressed his interest in the feature in his article on 
CSS Tricks. Scott Kellum (of typetura.com ) has 
also been suggesting it as a useful feature for the web (origin: a 
Twitter thread and email conversation, Scott in the meantime deleted 
their Twitter account).


/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

Same as any other CSS property, font-palette property is inspectable 
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-fonts/palette-mix-computed.html 
https://wpt.fyi/results/css/css-fonts/animations/font-palette-interpolation.html




Flag name on chrome://flags

FontPaletteAnimation


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://drafts.csswg.org/css-fonts-4/images/nabla-animated.webp


Estimated milestones

Shipping on desktop 121
DevTrial on desktop 119

Shipping on Android 121
DevTrial on Android 119

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


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_DFvgY9yqz_Tr%2B2sHMwsydbWMQ66yZWwF7ZoxDZ2yE1QA%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 

Re: [blink-dev] Intent to Ship: WebGPU timestamp queries

[Daniel Bratell]

LGTM2

100 microseconds sound very coarse for this, but I guess that just means 
they have to average data over many frames. And if they are happy, I'm 
happy.


/Daniel

On 2023-11-08 09:41, Yoav Weiss wrote:

LGTM1

Thanks for working through this issue!!

On Wed, Nov 8, 2023 at 2:34 AM Domenic Denicola  
wrote:




On Tue, Nov 7, 2023 at 5:42 PM François Beaufort
 wrote:



On Mon, Oct 30, 2023 at 7:39 PM Mike Taylor
 wrote:

On 10/30/23 12:59 PM, Corentin Wallez wrote:


On Fri, Oct 27, 2023 at 2:19 AM Domenic Denicola
 wrote:



On Thu, Oct 26, 2023 at 7:21 PM François Beaufort
 wrote:



On Thu, Oct 26, 2023 at 11:05 AM Domenic Denicola
 wrote:



On Thu, Oct 26, 2023 at 5:21 PM 'François
Beaufort' via blink-dev
 wrote:


Contact emails

fbeauf...@google.com, cwal...@google.com


Explainer

https://github.com/gpuweb/gpuweb/issues/614



Specification

https://gpuweb.github.io/gpuweb/#timestamp



Summary

WebGPU timestamp queries allow WebGPU
applications to measure precisely (down
to the nanosecond) how much time their
GPU commands take to execute, especially
at the beginning and end of passes.
Timestamp queries are heavily used to
gain insights into the performance and
behavior of GPU workloads.

While the WebGPU specification makes
timestamp queries an optional feature due
to timing attack concerns, we believe
that timestamp queries quantization
provides a good middle ground by reducing
the precision of timers. To offer even
more advanced protection against timing
attacks and fingerprinting, timestamp
queries are also coarsened based on site
isolation status:

- Isolated contexts: timestamp queries
are exposed with a resolution of 100
microseconds.

- Non-isolated contexts: timestamp
queries are not exposed at all.


By "isolated" do you mean "has the
cross-origin isolated capability

"?


Yes.


I wasn't able to find any spec or tests for
this requirement, which seems like a
potential interoperability issue.


The WebGPU spec currently says: "The feature is
optional, and a WebGPU implementation may limit
its exposure only to those scenarios that are
trusted."
See

https://gpuweb.github.io/gpuweb/#security-timing:~:text=The%20feature%20is%20optional%2C%20and%20a%20WebGPU%20implementation%20may%20limit%20its%20exposure%20only%20to%20those%20scenarios%20that%20are%20trusted


I realize that. I was suggesting that, for
interoperability purposes, you should consider
specifying the actual condition, instead of leaving
it vague and optional. (E.g. at least in other
standards bodies, we have guidance to avoid optional
or implementation-defined features; instead, we try
to work together with other browser engines to come
to a common, interoperable implementation, backed by
a test suite.)

I hope the API Owners can consider this when deciding
whether or not to approve, as I believe that letting
these sorts of non-specified and non-tested features
be shipped is harmful for the platform's health.

I'll add discussion of that to the agenda for this week's
WebGPU meeting: can we agree on the availability of
timestamp queries (provided there is hardware support)
and the quantization depending on 

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

[Daniel Bratell]

They seem to be in state "preparing" which is the stage before they are 
actually requested. The system is a bit new so maybe there is some 
confusing UI or bug, but they are not yet requested. jrobbins, do you 
know what might have gone awry?


/Daniel

On 2023-11-08 05:04, 'Eugene Zemtsov' via blink-dev wrote:

Done for Privacy, Security, Enterprise, Debuggability and Testing.


On Mon, Nov 6, 2023 at 7:19 AM Mike Taylor  wrote:

Hi Eugene,

Could you please request reviews for all the other review gates in
your chromestatus entry?

thanks,
Mike

On 11/1/23 6:32 PM, 'Eugene Zemtsov' via blink-dev wrote:



Contact emails

ezemt...@google.com


Specification

https://www.w3.org/TR/webcodecs/#dom-videoencoderconfig-contenthint


Explainer

https://gist.github.com/Djuffin/c3742404b7c53ada227849c8b2b76b4c


Summary

Adding a contentHint field to VideoEncoderConfig Content hint
takes values that are already used for MediaStreamTrack:
"motion", "text", "detail". This gives web developers a way to
communicate to VideoEncoder the expected type video frames they
intend to encode.


Blink component

Blink>Media>WebCodecs




TAG review

N/A



Interoperability and Compatibility



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

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

/Web developers/: Positive RTC software vendors (including Google
Meet) are interested in using it for screen sharing vs live cam
scenarios.


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://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webcodecs/video-encoder-content-hint.https.any.js



Finch feature name

WebCodecsContentHint


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1493588


Estimated milestones

Shipping on desktop 121

Shipping on Android 121


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5103493249761280

--
Thanks,
Eugene Zemtsov.
-- 
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/CAK8JDrGKnc0Jc_doyR9ZsGVfcnk8aNfNS_t%2BTNQ-KLL%3DW%3DiZdA%40mail.gmail.com

.




--
Thanks,
Eugene Zemtsov.
--
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/CAK8JDrHnO-en4d_%2BKcwRBCRWYeVEi8hzcnGUsSkb%3D3dNgh0%2Bdw%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/6ffa1b86-4f0e-4e07-afb3-f3ad20cb2ebe%40gmail.com.

Re: [blink-dev] Intent to Ship: CSS spelling and grammar features

[Daniel Bratell]

LGTM2

This one could use a ping in the mozilla standards position issue like 
that other one.


/Daniel

On 2023-11-07 01:58, Mike Taylor wrote:


Thanks - LGTM1

On 11/6/23 7:27 PM, Stephen Chenney wrote:

Thanks Mike.

On Mon, Nov 6, 2023 at 10:22 AM Mike Taylor  
wrote:


Hi Stephen,

Could you please request reviews for all the other review gates
in your chromestatus entry?

Yes, done. Sorry I overlooked that.

thanks,
Mike

On 10/30/23 8:37 PM, Stephen Chenney wrote:



The CSS Spelling and Grammar feature has been active
behind experimental web platform features since M89!
There are no open bugs. I would like to turn it on at
last for M120.



Contact emails

schen...@chromium.org, dazab...@igalia.com


Explainer

https://drafts.csswg.org/css-pseudo-4/#selectordef-spelling-error
https://drafts.csswg.org/css-pseudo-4/#selectordef-grammar-error

https://drafts.csswg.org/css-text-decor-4/#valdef-text-decoration-line-spelling-error

https://drafts.csswg.org/css-text-decor-4/#valdef-text-decoration-line-grammar-error


Specification

https://drafts.csswg.org/css-pseudo-4/#selectordef-spelling-error


Summary

CSS highlight pseudo-elements for styling text that the UA has
flagged as misspelled or grammatically incorrect, and line
decorations exposing the UA’s default decorations for spelling
and grammar errors. These features allow authors to choose more
legible colors for the default spelling and grammar errors,
highlight misspelled words with background colors or other
decorations, and implement custom spell checking with
almost-native appearance.




Blink component

Blink>CSS



Search tags

spelling-error
,
grammar-error
,
highlight pseudos



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

https://developer.mozilla.org/en-US/docs/Web/CSS/::spelling-error
https://developer.mozilla.org/en-US/docs/Web/CSS/::grammar-error



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

/WebKit/: In development
(https://lists.webkit.org/pipermail/webkit-dev/2021-January/031660.html)
WebKit has an old WIP patch from 2018 at
https://webkit.org/b/175784 CSS Working group minutes imply
Safari is planning an implementation:
https://github.com/w3c/csswg-drafts/issues/7522

/Web developers/: Positive

(https://dev.to/lampewebdev/css-pseudo-elements-classes-you-have-never-heard-of-30hl#the-grammarerror-and-spellingerror-pseudoelement)

/Other signals/: The spec for the text-decoration-line:
spelling-error/grammar-error is
https://drafts.csswg.org/css-text-decor-4/#text-decoration-line-property


Ergonomics

The new pseudo-elements depend on the new ‘text-decoration-line’
values for UA stylesheet support. They are highlight pseudos,
which should pose minimal performance risk due to the limited
set of CSS properties they allow:




Security

See, for example,
https://github.com/w3c/csswg-drafts/issues/5731 The final spec
says that only a minimal set of properties is allowed, and those
cannot load resources or otherwise expose timing attacks that
inform of a user's dictionary. The reported styles (to JS, to
DevTools) do not depend on whether or not the style is currently
applied, so do not reveal anything about the state of the styled
text.



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

Devtools support is the same as ::selection, ::target-text, and
::highlight(), which appear in the Styles panel. Properties
inherited from ancestor spelling and grammar styles are also
shown in the Styles panel.



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

Yes

There are no platform specific aspects to the feature and it is
useful on all platforms.



Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/css/css-pseudo?label=experimental=master

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prefetch Speculation Rules

[Daniel Bratell]

LGTM2

/Daniel

On 2023-11-07 01:57, Mike Taylor wrote:


LGTM1

On 11/1/23 9:55 AM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md#no-vary-search-hint


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html#speculation-rules-processing


Summary

Adds a hint to speculation rules that informs the navigation prefetch 
cache that the URL to be prefetched expects to receive the same 
No-Vary-Search header in the response. The hint is useful because 
prefetches that depend on No-Vary-Search to match to navigations do 
not benefit the user if the navigation happens before prefetch 
headers return from the server. Using the hint, the web browser will 
expect, but verify, that the No-Vary-Search hint matches with the 
No-Vary-Search header. If the No-Vary-Search hint does not match the 
No-Vary-Search header received then the web browser will send a new 
request.



We would like to ship "No-Vary-Search Hint for Prefetch Speculation 
Rules" together with "No-Vary-Search support in navigation prefetch 
cache" (https://chromestatus.com/feature/5071247189213184).



Blink component

Internals>Preload 




TAG review

Not applicable. The TAG has already given a negative opinion on the 
overall complexity of speculation rules 
(https://github.com/w3ctag/design-reviews/issues/721), so we 
anticipate it would not be a good use of their time to review 
additions to the syntax. The addition itself is small and any 
architectural questions about it would be covered under the general 
closed speculation rules review.



TAG review status

Not applicable


Chromium Trial Name

NoVarySearchPrefetch


Origin Trial documentation link

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193



WebFeature UseCounter name

kSpeculationRulesNoVarySearchHint


Risks



Interoperability and Compatibility



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/620#issuecomment-1608195274)


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/54#issuecomment-1608197504)


/Web developers/: Google Search has been experimenting with 
No-Vary-Search header / Speculation Rules "expects_no_vary_search" 
(referred in this intent as No-Vary-Search hint for prefetch 
Speculation Rules). This functionality helps Google Search to match 
prefetched content to the next user navigation. Developers can use 
parameters in the prefetched URL that are not needed when navigating 
to the actual link (e.g. the source of the link click). The server 
can customize behavior using these parameters without causing a cache 
miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows the 
browser to completely handle the case where the user navigates to a 
URL that is currently prefetched by waiting for the ongoing prefetch 
instead of directly requesting the page from the server.
Google Search conducted experiments prefetching Search results pages 
from the search box and other links that lead to another Search 
results page. There was significant latency improvement for 
navigating to Search result pages prefetched using No-Vary-Search 
header and "expects_no_vary_search".


/Other signals/: No-Vary-Search Hint for Prefetch Speculation Rules 
has been discussed, together with No-Vary-Search header at Web Perf 
WG meeting at TPAC 2023 
. 




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

The No-Vary-Search hint is represented as a new json attribute 
("expects_no_vary_search") in prefetch Speculation Rules. The 
Speculation Rules can be viewed in DevTools on the Application tab 
under Preloading->Speculation Rules.



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/speculation-rules/prefetch/no-vary-search?label=master=experimental 





Flag name on chrome://flags



Finch feature name

SpeculationRulesNoVarySearchHint


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 121
OriginTrial desktop last120
OriginTrial desktop 

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Daniel Bratell]

LGTM2

/Daniel

On 2023-11-07 01:57, Mike Taylor wrote:


Thanks Liviu.

I've spent some time today reviewing the explainer and spec, and find 
the use cases compelling.


LGTM1 to ship. A non-blocking request would be to add the security & 
privacy considerations from the explainer into the draft WICG spec (or 
something similar).


(Also, kudos to all who contributed to the explainer - it's very 
thorough and answered every question I had as I began to review in 
depth. Excellent work.)


On 11/6/23 5:08 PM, Liviu Tinta wrote:
> Are there any open issues that would result in breaking changes, 
after we ship?


There are 2 open issues related to No-Vary-Search: 
https://github.com/WICG/nav-speculation/labels/no-vary-search. None 
of the open issues requires modifying No-Vary-Search header. We are 
not expecting breaking changes after we ship.


On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:

On 11/1/23 9:59 AM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org
, liviuti...@chromium.org



Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md



Specification

https://wicg.github.io/nav-speculation/no-vary-search.html



Summary

Enables prefetch to match even if URL query parameters change.
The No-Vary-Search HTTP response header declares that some or
all parts of a URL's query can be ignored for cache matching
purposes. It can declare that the order of query parameter keys
should not cause cache misses, that specific query parameters
should not cause cache misses or that only certain known query
parameters should cause cache misses. It could apply to multiple
caches, but this entry refers to support for prefetch cache.


We would like to ship "No-Vary-Search support in navigation
prefetch cache" together with "No-Vary-Search Hint for Prefetch
Speculation Rules"
(https://chromestatus.com/feature/4887338302308352
).


Blink component

Internals>Preload




TAG review

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



TAG review status

Positive.


Chromium Trial Name

NoVarySearchPrefetch


Link to origin trial feedback summary

https://github.com/WICG/nav-speculation/issues


Are there any open issues that would result in breaking changes,
after we ship?



Origin Trial documentation link

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193



Risks



Interoperability and Compatibility



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

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

/Web developers/: Google Search has been experimenting with
No-Vary-Search header / Speculation Rules
"expects_no_vary_search". This functionality helps Google Search
to match prefetched content to the next user navigation.
Developers can use parameters in the prefetched URL that are not
needed when navigating to the actual link (e.g. the source of
the link click). The server can customize behavior using these
parameters without causing a cache miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows
the browser to completely handle the case where the user
navigates to a URL that is currently prefetched by waiting for
the ongoing prefetch instead of directly requesting the page
from the server.
Google Search conducted experiments prefetching Search results
pages from the search box and other links that lead to another
Search results page. There was significant latency improvement
for navigating to Search result pages prefetched using
No-Vary-Search header and "expects_no_vary_search".

/Other signals/: No-Vary-Search header has been discussed,
together with No-Vary-Search Hint for Prefetch Speculation
Rules at Web Perf WG meeting at TPAC 2023

.



Ergonomics

No-Vary-Search will be used in tandem with Speculation 

Re: [blink-dev] Intent to Ship: CSS Highlight Inheritance

[Daniel Bratell]

LGTM2

You may want to ping the Mozilla standards position issue and let them 
know that we are close to shipping. It looks like they forgotten it.


/Daniel

On 2023-11-06 16:43, Mike Taylor wrote:


Thanks for the detailed explanation of compat and for filing a TAG 
review. The risk of breakage seems low (and I suppose we'll learn how 
true that is as the change rides the trains), and breakage in this 
case would just be cosmetic (unless someone is doing something really 
clever).


LGTM1 to ship. Good luck. :)

On 11/3/23 12:19 PM, Stephen Chenney wrote:
Note that I have moved the shipping milestone to M121, and have 
created a TAG review issue.


On Thu, Nov 2, 2023 at 10:07 AM Stephen Chenney 
 wrote:




On Wed, Nov 1, 2023 at 11:11 AM Stephen Chenney
 wrote:

Answers inline. Regarding Ander's comment on the current
base_feature setting: I'll fix that.

Cheers,
Stephen.

On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss
 wrote:



On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney
 wrote:


Contact emails

schen...@chromium.org


Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade


Summary

With CSS Highlight Inheritance, the CSS Highlight
pseudo classes, such as ::selection and ::highlight,
inherit their properties through the pseudo highlight
chain, rather than the element chain. The result is a
more intuitive model for inheritance of properties in
highlights. Specifically, "When any supported
property is not given a value by the cascade ... its
specified value is determined by inheritance from the
corresponding highlight pseudo-element of its
originating element’s parent element."
(https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)



Blink component

Blink>CSS




TAG review

None


Features are exempt from a TAG review only when another
vendor has already shipped them. That doesn't seem to be
the case here.


The feature is in the CSS pseudos spec and has been for quite
a while. The CSS Working Group has been discussing issues too
and Safari, at least, is implementing according to the spec.
I think the ship has sailed for any major revision to the
behavior. (For context, there was no feature defined for this
change until recently because it was originally viewed as a
"make the code implement the spec" change.)


TAG Review Issue: https://github.com/w3ctag/design-reviews/issues/914





TAG review status

Not applicable


Risks



Interoperability and Compatibility

The feature is still under implementation in other
browser engines, but the standards are well developed
and there is general agreement on the spec. I think
compat risk is very limited at this time.


Does this feature change the behavior of existing uses of
::highlight and ::selection? Is there risk from breakage
there?


The change aligns the behavior of ::selection with Firefox.
::highlight is already implemented with this behavior. There
was breakage of ::selection due to custom property handling,
which was resolved at the spec level and fixed in chromium
before sending this intent. No other bugs have come in over
the extended period that this has been on for experimental
web platform features (since M111).


My above comment is wrong: The spec defining this feature does
change the behavior of ::selection (not ::highlight) for all
browsers. But evidence suggests that the mitigations that sites
used to work around the old behavior still work with the new
behavior, so breakage is very limited. There was a single source
of significant breakage when the feature was first turned on and
the spec and code have been changed to maintain the former
behavior (related to custom properties on root applying to
::selection). We have had zero other reported bugs from enabling
the feature experimentally.

Some history ... The spec was changed in response to an issue
where Firefox wanted to un-prefix -moz-selection but was not
obeying the old spec. As I understand it, the selection style was
checking for ::selection on the selected element, using it if
found, otherwise using the root selection styling. All
browsers 

Re: [blink-dev] Intent to Ship: Ruby-specific display values

[Daniel Bratell]

LGTM3 but attend to Rick's comment below before shipping.

(Fantasia/Kent: It should be possible to test the implementation using 
the flags the WPT bots use to test so I assume Fantasia can test it with 
an appropriate flag and new enough build? 
chrome://flags/#enable-experimental-web-platform-features ? )


/Daniel

On 2023-11-01 16:53, Rick Byers wrote:

Hey Kent,
To Fantasai's point, can you point to the specific WPT test cases for 
this intent? Are Chrome or Firefox failing any, and if so can you 
explain why?


Tentative LGTM2 assuming WPT coverage shows we're matching Firefox 
behavior. Also happy to discuss the nuance here first if it's not 
completely the case that we match Firefox.


Rick

On Mon, Oct 30, 2023 at 3:12 PM fantasai 
 wrote:


On 10/19/23 22:39, TAMURA, Kent wrote:
> fantasai wrote:
> >  It seems you're listing a subset of values, which makes me
wonder what
> > differences you would be introducing between Blink's behavior
and the
> > behavior described in the specs (if any)?
>
> I think the new behavior will be a subset of CSS ruby. Blink
will be
> compatible with CSS ruby box generation, but web authors won't
have a way to
> specify ruby-base-container and ruby-text-container to elements.

OK, that seems reasonable. So therefore if the author writes in
their stylesheet:

   ruby { display: ruby; }
   rt { display: ruby-text; }
   rb { display: ruby-base; }

They will get the exact same rendering as in Firefox for all markup
permutations of , , and , correct?

If that's true, then I agree with setting those values on ,
, and
 and shipping such an implementation.

> > WebKit's position is also against the whole spec...
>
> I don't think WebKit is against the specification though their ruby
> development is not active.

Sorry, I wrote that confusingly. WebKit's position is *regarding*
the whole
spec. :) They are obviously in support.

> >  I think it would be important to understand how Blink's proposed
> > implementation might differ from the spec and from Firefox's
implementation,
> > particularly in terms of the box model and layout structures
it generates for
> > various ruby markup patterns.
> >
> > Also, CSS Ruby Layout is quite complicated, do you have a
prototype already? I
> > didn't see an Intent to Prototype come through earlier. I
think it would be a
> > good idea to evaluate the quality of the implementation and
any differences
> > with Firefox before approving an intent to ship. At least, if
I were in
> > charge, I would want to...
>
> We don't have an implementation of this change yet.

I think it would be good to evaluate the change before deciding
whether it's
ready to ship. If you don't have an implementation, you can't
evaluate which
bugs need to be fixed before you ship vs which you are willing to
fix afterwards.

~fantasai

-- 
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/973e0592-b537-4c14-b3b0-87953bad890c%40inkedblade.net.

--
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/CAFUtAY_xCX0L%2Bf0HDj2Uy%2B%2BkXNMRKmRbuaaFvuUHZGXdk7mymg%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/d10585c2-478b-4a60-9f5b-f37e91c0524f%40gmail.com.

Re: [blink-dev] Intent to ship: The Login Status API and its use in FedCM

[Daniel Bratell]

Hi, I just have a couple of questions without having read through the 
intent in detail.


You say "Our goal is to open this up to other websites in the future.", 
but what does that mean? Is there some kind of web site restriction today?


Not creating a https://github.com/mozilla/standards-positions/issues 
entry seems a bit wrong even if someone at Mozilla has said it is not 
needed. They have in the past specifically wanted us to explicitly use 
the standards-positions repo rather than relying on negative or positive 
statements elsewhere. Would it be best to post one just in case?


/Daniel

On 2023-10-12 21:04, Christian Biesinger wrote:



Contact emails

cbiesin...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md 




Specification

https://github.com/fedidcg/FedCM/pull/436 




Summary

The Login Status API 
(formerly IdP Sign-in Status 
API) allows identity providers to signal to the browser when their 
users are logging-in/out. Our goal is to open this up to other 
websites in the future.


This signal, in this intent, is used by FedCM to address a silent 
timing attack, and in doing so, allows FedCM to operate without third 
party cookies altogether. This update would address the last remaining 
backwards incompatible changes we had previously identified in the 
original I2S of FedCM 
as 
part of our scope of work.


In the future, we expect that the Login Status API may also be used 
outside of FedCM (e.g. the Storage Access API 
) and may 
be useful for websites that are not identity providers (e.g. extending 
browser storage 
).



Blink component

Blink>Identity>FedCM 




Search tags

fedcm , login 




TAG review

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




TAG review status

Pending


Chromium Trial Name

FedCmIdpSigninStatus


Link to origin trial feedback summary

https://github.com/fedidcg/FedCM/issues/


Origin Trial documentation link

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
https://developer.chrome.com/blog/fedcm-chrome-116-updates/#idp-signin-status 




Risks


Interoperability and Compatibility

For interop:

This I2S is composed of two different (but interdependent) APIs: The 
Login Status API and FedCM.


With regards to the Login Status API 
, both Firefox and Safari are 
on board with the general API (breakout notes 
, follow up 
notes 
) 
. There is an overall agreement on starting from a self-declared 
status and also some general agreement on where the Login Status API 
may lead in the future, including having higher assurance levels and 
applications outside of FedCM.


With regards to its use in FedCM, Firefox is generally in agreement 
with the shape of the solution. Firefox is working on the 
implementation behind a flag. Safari isn’t shipping FedCM yet.


For compat:

While this is a backwards incompatible change for FedCM, we are in 
active conversations with all IdPs that are currently using FedCM (as 
shown by our UKM metrics) and they are onboard with this change.


Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436 
) We have been working with 
the Firefox team for the last year or so on this API (e.g. TPAC 2022 
). 
We generally agree on the shape of the solution and we are working 
with them to write the spec in a way that allows Chrome and Firefox to 
implement FedCM in an interoperable way. (Firefox has asked us 
(https://github.com/fedidcg/FedCM/issues/431#issuecomment-1425025469 
) 
to rely on PR comments instead of filing standards positions for these 
FedCM extensions)


WebKit: Under consideration 

Re: [blink-dev] Intent to Ship: Media Session API: enterpictureinpicture action

[Daniel Bratell]

LGTM2

(For some reason your chromestatus entry has two "Enterprise" and no 
"Debuggability" shipping bullets, @jrobbins?)


/Daniel

On 2023-10-13 09:33, 'François Beaufort' via blink-dev wrote:
Last position from Mozilla is still "defer" despite developers asking 
for reconsiderations over the years. See 
https://mozilla.github.io/standards-positions/#picture-in-picture


Picture-in-Picture was shipped in Safari 13.1. See 
https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes


On Thu, Oct 12, 2023 at 6:44 PM Tommy Steimel  wrote:

Good question. +François Beaufort
 who is the editor of the video
picture-in-picture spec who might have more insight

On Thu, Oct 12, 2023 at 9:01 AM Chris Harrelson
 wrote:

Are there official and up-to-date standards positions from
Firefox and Webkit about picture-in-picture in general?
(setting aside document picture-in-picture). The Mozilla
position from quite a while ago is "defer". If not, and you
think their stance might have changed, please file a new
position request for picture-in-picture generally.

On Wed, Oct 11, 2023 at 9:29 PM Yoav Weiss
 wrote:

LGTM1

On Wed, Oct 11, 2023 at 11:26 PM Tommy Steimel
 wrote:



On Wed, Oct 11, 2023 at 7:43 AM Yoav Weiss
 wrote:



On Friday, October 6, 2023 at 12:55:09 AM UTC+2
chri...@google.com wrote:

Hi,

Please update your chromestatus entry to
trigger the other 5 review categories for this
intent. I think it's probably the case that
you ended up with the wrong feature category
and need to update it, sorry for any
confusion. @Jason Robbins
 also.

On Wed, Oct 4, 2023 at 3:35 PM 'Tommy Steimel'
via blink-dev  wrote:

Contact emails

stei...@chromium.org
,
liber...@chromium.org



Explainer

https://github.com/w3c/mediasession/issues/294



Can you explain what this action does and how
developers are likely to use it?


Sure. In general, websites can register handlers on
the Media Session for various actions (e.g.
"nexttrack"). The UA can then trigger those actions on
the page via browser UI or other user actions (e.g. a
next track button in the browser native UI or if the
user presses the "next track" key on their keyboard).
For the case of 'enterpictureinpicture', the website
would register a handler for that action and the UA
can trigger it when appropriate (e.g. Chrome has a
picture-in-picture button in its global media controls
UI). The website can use that handler to call
requestPictureInPicture on a video element or request
a document picture-in-picture window.


Specification

https://github.com/w3c/mediasession/pull/295



What's blocking the PR from landing?


I was waiting on review from the other Media Session
author. I pinged them today and have landed the PR.


API spec

Yes


Summary

Adds an 'enterpictureinpicture' action to
the Media Session API. Websites can
register an action handler which can be
used to open a Picture-in-Picture or
Document Picture-in-Picture window.


Blink component

Blink>Media>Session


TAG review

This small addition to the Media Session
API doesn’t seem to qualify for a TAG review.

Note that one for video conferencing
actions was approved previously

athttps://github.com/w3ctag/design-reviews/issues/608

Re: [blink-dev] Intent to Ship: Accordion pattern using name attribute on elements

[Daniel Bratell]

LGTM2

/Daniel

On 2023-10-11 16:36, Yoav Weiss wrote:

LGTM1

Thanks for the compat analysis! :)

On Wednesday, October 11, 2023 at 3:28:03 AM UTC+2 David Baron wrote:

On Wed, Oct 4, 2023 at 6:30 AM Yoav Weiss 
wrote:


On Fri, Sep 29, 2023 at 11:04 PM David Baron
 wrote:


Summary


This feature adds the ability to construct
exclusive accordions using a sequence of HTML
 elements. It adds a name attribute to
the  element. When this attribute is
used, multiple  elements that have the
same name form a group. At most one element in the
group can be open at once.


This looks great!!
The only tiny concern I have is the question of compatibility:
Is it possible that existing  elements share a name
attribute?
Would it be possible for you to run a quick HTTPArchive scan
and see this is not a semi-common pattern?


I ran a query with HTTPArchive

,
in particular, the following query:

SELECT page, url
FROM `httparchive.all.requests`
WHERE
date = '2023-09-01' AND
client = 'desktop' AND
is_main_document AND
REGEXP_CONTAINS(response_body,
r'(?is)]*?[[:space:]]name(=|[[:space:]]|>)')

This produced 6 urls (for 7 pages; two of them redirect to the
same URL).  I did view-source: of the 6 urls and based on visual
inspection found that 0 of the 6 would be broken by shipping this
feature.  In more detail:

  * 3 of the 6 (associated with the same site, mailchimp.com
) had multiple  elements, on
each of which the name and id attributes had the same value,
and these values were properly unique (at least among the
 elements)
  * 1 had a single  with name="somename"
  * 1 had a single  with name="body" and id="body"; there
were other elements with this name/id, but none of the others
were 
  * 1 had a single  element with a unique-ish looking name

So none of the pages found used the name attribute in a way that
would be affected by shipping this feature (i.e., multiple
 elements with the same name).


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

There may still be some small changes as part of
the process of getting
https://github.com/whatwg/html/pull/9400
finished,
but I hope to implement those before shipping (at
least those that happen soon).


The PR is merged. Is there more work happening on it?


No.  I sent the intent before the PR was merged.  I do still need
to follow up on a piece of the discussion there and file an issue
on html-aam, though.

-David

--
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/392c410e-acb3-4e55-bba1-d2d6612b4ba0n%40chromium.org 
.


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

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Daniel Bratell]

I see that various mandatory steps in chromestatus 
(privacy,security,enterprise,debuggability,testing) seems to be 
unstarted. It is possible they were made mandatory after you create the 
entry, but it would be good if you could get them started now at least.


Also, it's unfortunate that TAG and standards positions requests have 
not resulted in anything, but that is hardly your fault. There were some 
questions in the WebKit request. Is all that ok now?


/Daniel

On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:



On Friday, October 6, 2023 at 9:03:35 AM UTC-7 mike...@chromium.org wrote:


On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails
gerc...@microsoft.com, sahir@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Specification

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Summary

As devices with advanced pen input capabilities are becoming
increasingly prevalent, it is important that the web platform
continues to evolve to fully support these advanced features in
order to unlock rich experiences for both end users and
developers. One such advancement is the ability for a device's
digitizer to recognize more than one pen device interacting with
it simultaneously. This feature is an extension to the
PointerEvent interface to include a new attribute, deviceId, that
represents a session-persistent, document isolated, unique
identifier that a developer can reliably use to identify
individual pens interacting with the page.



Blink component
Blink>Input


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

TAG review status
Pending. TAG review has been pending for 2 months.

Risks


Interoperability and Compatibility


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

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

/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



Debuggability


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. However, there are web tests in Chromium that test
PointerEventInit with this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name


Non-finch justification
Edge origin trials successfully underway.

Any Origin Trial feedback you can share?


Absolutely, the feature has been working well. Our partners (Microsoft 
Whiteboard) have enabled the feature that is dependent on this API for 
their general audience! We did not receive any constructive feedback. 
This API is being used by them on Microsoft Surface Hub devices, which 
support multi-pen inking.




Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Initially available on Chromium browsers on Windows.

Out of curiosity, are there limitations on other platforms that
prevent supporting this feature?


We haven't been able to get our hands on hardware that supports other 
platforms in addition to multi pen inking in order to implement and 
appropriately test this feature. We welcome any sponsors for 
implementing and testing this, especially on Linux/Android.




Adoption expectation
Feature is used by specific partner(s) to provide functionality
immediately upon launch.

Adoption plan
This feature has been through origin trials on Edge. It is being
used by partners that provide features on devices with multi pen
support.

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

Operating system API's are used to obtain the device id, and are
necessary for this feature to function. Please see the security
questionnaire in the TAG review on security and privacy concerns
related to the use of these APIs.

Estimated milestones
Shipping on desktop
120


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 

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

[Daniel Bratell]

LGTM1 (dependent on the PR landing)

Looks like the spec text is more or less complete with no remaining 
possible showstoppers. I do find it both amusing and a bit Kafkaesque 
that the web community seems to have a process where the spec waits for 
implementers and implementers (at least us) wait for the spec. In this 
case it was a small and positive change so it was no issue but it could 
be for larger changes.


(Security review not completed in chromestatus but since this is a clone 
of the other showPicker(), I find it unlikely that it uncovers some problem)


/Daniel

On 2023-10-04 17:34, Mason Freed wrote:

On Tuesday, October 3, 2023 at 9:47:02 AM UTC-7 Luke wrote:

That makes perfect sense. For now I've removed the target
milestones all together (they were rather arbitrary). But
targeting 120 or 121 seems like a good idea. As for merging the
spec change I think it should be ready to go assuming my response
on the PR satisfies the question you had?


Thanks! I think it'd be good to explicitly target a milestone - 
perhaps 121? And yes, thanks for your reply on the spec. It sounds 
like there is only a focus question remaining.


Thanks,
Mason

Thanks,
Luke

On Tuesday, 3 October 2023 at 17:34:15 UTC+1 mas...@chromium.org
wrote:

I'm generally supportive of adding showPicker to select
elements - it's a handy API for developers and it avoids some
JS hacks. I do think we should a) land the spec changes
, and b) allow some
developer test time, before we ship this API. There were some
bugs that got discovered while testing input.showPicker, so
I'd like to leave some time for those to be found for select.
Your chromestatus
 lists M119
as the target shipping milestone, but the addition of the code

landed Sept 29, after the feature freeze for M119. Maybe we
should instead target M120 or M121 to ship, at the earliest?

Thanks,
Mason

On Tuesday, October 3, 2023 at 6:53:59 AM UTC-7 Luke wrote:



On Tuesday, 3 October 2023 at 14:43:23 UTC+1
yoav...@chromium.org wrote:

On Mon, Oct 2, 2023 at 4:40 AM Luke
 wrote:

Contact emails
lukewa...@gmail.com, lu...@warlow.dev

Explainer
https://github.com/whatwg/html/pull/9754



Thanks for the explainer! :)

What's preventing us from landing the PR?

+Chris Harrelson - Can we mark Chromium as positive
for WHATWG purposes?

I think it's just the needing two supporters, we have
Gecko now and I was told Chrome would require this intent
process. WebKit also don't seem opposed.



Specification

https://whatpr.org/html/9754/input.html#dom-select-showpicker



Summary
Developers have been asking for a way to
programmatically open the option picker of a
select element. See

https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com



This is currently impossible in almost every
browser. Providing showPicker() gives developers a
supported way to do this. Following the pattern of
input.showPicker().



Blink component
Blink>Forms

Search tags
showPicker

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



+Aaron Leventhal - Can you take a look at the a11y
questions and see that a) the implementation behavior
makes sense from your perspective b) that we have
testing in place to make sure it stays that way.

Yeah it'd be great if the accessibility aspect could be
reviewed (possibly in the wider context of
input.showPicker too?) as for any missing tests I'm happy
to add any that are needed. I think right now it's just
the WPT tests. Wasn't sure how or if it was even possible
to test further than that.


TAG review status
Pending

Risks