[blink-dev] Re: Intent to Ship: AudioContext.onerror

2024-07-10 Thread Domenic Denicola 
I've filed a spec issue that I believe should be addressed before shipping 
(with appropriate test updates, 
etc.) https://github.com/WebAudio/web-audio-api/issues/2590

On Thursday, July 11, 2024 at 2:06:53 PM UTC+9 ajayra...@google.com wrote:

>
> Contact emails
>
> hongc...@chromium.org, mjwil...@chromium.org
>
> Explainer
>
> None; the specification (W3C Proposed Recommendation) is already published.
>
> Specification
> https://webaudio.github.io/web-audio-api/#dom-audiocontext-onerror
>
> Summary
>
> Introduces an event listener on AudioContext to notify developers of audio 
> device or rendering system failures.
>
> Blink component
>
> Blink>WebAudio 
> 
>
> Motivation
>
> Currently, developers lack visibility into the success or failure of their 
> AudioContext, whether during its creation or while actively rendering 
> audio. In the event of failure, web applications misleadingly continue to 
> function as if audio playback is proceeding normally. The 
> AudioContext.onerror event listener allows web applications to proactively 
> respond to and manage device or rendering failures.
>
> Initial public proposal
>
> https://github.com/WebAudio/web-audio-api/issues/2567
>
> TAG review
>
> http://github.com/w3ctag/design-reviews/issues/950 
>
> TAG review status
>
> Resolved
>
> Risks
> Interoperability and Compatibility
>
> Gecko: Positive  (
> http://github.com/mozilla/standards-positions/issues/1016)
>
> WebKit: Defer to Audio WG (
> https://github.com/WebKit/standards-positions/issues/340)
>
> Web developers: Positive (2020 Developer Survey 
> 
> )
>
> 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, AudioContext failure scenarios cannot be tested in WPTs. 
> Chromium-internal tests will fully exercise this scenario.
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> AudioContextOnError
>
> Non-finch justification
>
> N/A
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/41495720
>
> Launch bug
>
> https://launch.corp.google.com/launch/4317143
>
> Estimated milestones
>
> M128
>
> Note
>
> The team has requested Privacy and Security approval on the chromestatus 
>  
> entry. The same gates have already been approved on the internal launch 
> bug .
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5113439453446144
>
> 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/22beb2cf-02f6-46f6-9b23-857eb968f6ebn%40chromium.org.

Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

2024-07-10 Thread Domenic Denicola 
Can you work on filing for TAG review, and asking other browsers for
signals?

On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
> issackj...@microsoft.com, seth.bren...@microsoft.com
>
> Explainer
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
> https://github.com/WICG/crash-reporting/issues/12
>
> Specification
> https://wicg.github.io/crash-reporting
>
> Design docs
>
>
> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>
> Summary
> This feature captures the JS call stack when a web page becomes
> unresponsive due to JavaScript code running an infinite loop or other very
> long computation. This helps developers to identify the cause of the
> unresponsiveness and fix it more easily. The JS call stack is included in
> the crash reporting API when the reason is unresponsive.
>
>
> Blink component
> Chromium > Internals > Network > ReportingAndNEL
> 
>
> TAG review
> None
>
> TAG review status
>
>
> Risks
>
>
> Interoperability and Compatibility
> "The stack trace format itself is not compatible across browsers."
> However, "It is already exposed throughout the web platform (via the
> `error.stack` getter), and there is already a lot of software, both client-
> and server-side, which deals with parsing the different browsers' formats."
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Security
> Stack frames from cross-domain scripts that were not loaded with CORS must
> be omitted.
>
>
> 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
> The primary goal of this experiment is to gain insights on the usage and
> effectiveness of the call stacks in crash reports from unresponsive web
> pages feature. We aim to understand how this feature can help developers
> debug unresponsive renderers, and how it can be improved to better serve
> their needs.
>
>  Specifically, we are looking to gain insight on the following pieces of
> the API surface:
>  - The frequency under which the feature is used.
> - The usefulness of the call stacks provided by this feature in debugging
> unresponsive renderers.
>
>  To validate our designs, we will be using the following metrics and
> feedback:
>  - Usage data: We will collect data on the number of execution contexts
> for which this feature is enabled, and the call stack is generated.
> - Developer feedback: We will solicit feedback from developers on the
> usefulness of the call stacks provided by this feature, and any
> improvements they would like to see.
>
> Ongoing technical constraints
> None
>
>
> Debuggability
> Developers can launch DevTools, go to the "Application" Tab, then in the
> "Background services" section click on "Reporting API" where they can
> inspect reports that are queued to be sent. Application --> Reporting API
>
>
> 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
> This feature is not currently testable on WPT, since triggering it
> requires crashing the browser.
>
>
> DevTrial instructions
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md
>
> Flag name on chrome://flags
>
>
> Finch feature name
> DocumentPolicyIncludeJSCallStacksInCrashReports
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> Estimated milestones
> Origin trial desktop first
> 127
> Origin trial desktop last
> 132
> DevTrial on desktop
> 125
> OriginTrial Android last
> 132
> OriginTrial Android first
> 127
> DevTrial on Android
> 125
> OriginTrial webView last
> 132
> OriginTrial webView first
> 127
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4731248572628992?gate=5542684580380672
>
> Links to previous Intent discussions
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com
>  Ready
> for Trial:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/aVpeVRO1Sy4
>
>
> 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.o

[blink-dev] Intent to Ship: AudioContext.onerror

2024-07-10 Thread 'Ajay Rahatekar' via blink-dev 
Contact emails

hongc...@chromium.org, mjwil...@chromium.org

Explainer

None; the specification (W3C Proposed Recommendation) is already published.

Specification
https://webaudio.github.io/web-audio-api/#dom-audiocontext-onerror

Summary

Introduces an event listener on AudioContext to notify developers of audio
device or rendering system failures.

Blink component

Blink>WebAudio


Motivation

Currently, developers lack visibility into the success or failure of their
AudioContext, whether during its creation or while actively rendering
audio. In the event of failure, web applications misleadingly continue to
function as if audio playback is proceeding normally. The
AudioContext.onerror event listener allows web applications to proactively
respond to and manage device or rendering failures.

Initial public proposal

https://github.com/WebAudio/web-audio-api/issues/2567

TAG review

http://github.com/w3ctag/design-reviews/issues/950

TAG review status

Resolved

Risks
Interoperability and Compatibility

Gecko: Positive  (http://github.com/mozilla/standards-positions/issues/1016)

WebKit: Defer to Audio WG (
https://github.com/WebKit/standards-positions/issues/340)

Web developers: Positive (2020 Developer Survey

)

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, AudioContext failure scenarios cannot be tested in WPTs.
Chromium-internal tests will fully exercise this scenario.

Flag name on chrome://flags

None

Finch feature name

AudioContextOnError

Non-finch justification

N/A

Requires code in //chrome?

False

Tracking bug

https://crbug.com/41495720

Launch bug

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

Estimated milestones

M128

Note

The team has requested Privacy and Security approval on the chromestatus

entry. The same gates have already been approved on the internal launch bug
.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113439453446144

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/CAHB%2BDAggZCE0pbYMt8BD%2BNXcmuyYN-SsH2rrU%3D8cVR3JEXMsjw%40mail.gmail.com.

Re: [blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

2024-07-10 Thread Mason Freed 
I've obsoleted this chromestatus entry, and created a fresh one with the
correct (I think) feature type. I have sent a fresh I2S on that entry.
Please disregard this one.

Thanks,
Mason

On Wed, Jul 10, 2024 at 9:12 AM Mason Freed  wrote:

>
>
> On Wed, Jul 3, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Note: They can preemptively handle this change today by using
>>> position-try:flip-inline instead.
>>>
>>>
 It's tricky, because waiting could actually cause *more* breakage,
 even with a deprecation period, and the numbers look quite good right now.

>>>
>> If the app in question could switch to `position-try:flip-inline` that
>> changes things, and would indeed not require a milestone overlap, assuming
>> they can make that change.
>>
>
> I've received the contact info privately, and I'll reach out to the
> affected app. Assuming that goes well, it sounds like we might be ok
> shipping a direct rename?
>
> 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


 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-anchor-position


 Flag name on chrome://flagsNone

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/349600667

 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/5167414571696128?gate=5182169462079488

 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/cf8a8c9d-9efa-4bff-9dd5-590809fe2877n%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/CAM%3DNeDiutdqP8jNJSH_r%2BZRt85N8BfVwxY%2BzhoqJfuVjcX1ozA%40mail.gmail.com.

Re: [blink-dev] Web-Facing Change PSA: Rename inset-area to position-area

2024-07-10 Thread Mason Freed 
On Wed, Jul 10, 2024 at 1:59 PM Mason Freed  wrote:

> This is the email template you get when you use the "Web developer-facing
> change to existing code" feature type on chromestatus. I do believe that's
> the best description of this change, right? This is not a "New feature
> incubation", nor is it exactly an "Existing feature implementation". I've
> learned through painful experience never to change the title of these
> intent emails. I was assuming this still requires 3 LGTMs from owners.
>

I've obsoleted this chromestatus entry, and created a fresh one with the
correct (I think) feature type. I have sent a fresh I2S on that entry.
Please disregard this one.

Thanks,
Mason



> Thanks,
> Mason
>
>
> On Wed, Jul 10, 2024 at 8:15 PM Mason Freed  wrote:
>>
>>> Contact emailsmas...@chromium.org
>>>
>>> Specification
>>> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>>>
>>> Summary
>>>
>>> The CSSWG resolved to rename this property from `inset-area` to
>>> `position-area`. See the CSSWG discussion here:
>>> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>>> Chrome disagrees with this change, but would like to ship an interoperable
>>> implementation. We will ship the new property name, `position-area`, as a
>>> synonym for `inset-area` first. Then after a suitable amount of time, we
>>> will remove `inset-area`. The latter removal will be done under a separate
>>> Intent.
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> Search tagsanchor positioning
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is a compat risk with this rename, since the old name of
>>> `inset-area` is in use, with an 0.02% use counter:
>>> https://chromestatus.com/metrics/css/timeline/popularity/781 We will
>>> need to ship the new name, `position-area`, first, and issue deprecation
>>> warnings for the old name, `inset-area`, to give developers time to change.
>>> This intent to ship is about shipping `position-area` as a synonym for
>>> `inset-area`. We'll issue a separate I2D for removing the `inset-area`
>>> property.
>>>
>>>
>>> *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
>>> 
>>> ?Yes
>>>
>>> https://wpt.fyi/results/css/css-anchor-position
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/35293
>>>
>>> Estimated milestones
>>> Shipping on desktop 129
>>> DevTrial on desktop 129
>>> Shipping on Android 129
>>> DevTrial on Android 129
>>> Shipping on WebView 129
>>>
>>> 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/6567965055778816?gate=5360672631422976
>>>
>>> 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/CAM%3DNeDiwrPpAtU%2Byn-OAUBZoEfeYN%2Bgyjg_Vv9_RzEyMKak9Bw%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/CAM%3DNeDhWZCMqueZS2OKYGDLOwAeF3XkekyK%

[blink-dev] Intent to Ship: Rename position-try-options to position-try-fallbacks

2024-07-10 Thread Mason Freed 
{NOTE: this is a replacement of this chromestatus
, which has the wrong
feature type and cannot be changed.}
Contact emailsmas...@chromium.org, andr...@chromium.org

ExplainerNone

Specification
https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more
accurately describes what this property controls. The word "options" is a
bit deceiving, since the styles outside of `position-try` blocks will be
tested first, and if they result in a layout that fits within the
containing block, none of the "options" will get used. So "fallbacks" is a
better word to describe this behavior.
https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is a name change, which will result in the old name no longer
functioning. So there is a risk of breakage. However, the anchor
positioning feature was very recently shipped, and does not have
implementation in other browsers. So we feel the risk is quite small
currently, but will grow over time. Given that, we'd like to rename this
property ASAP to avoid the risk getting too large. The use counter is
currently quite low, around 0.01% in June:
https://chromestatus.com/metrics/css/timeline/popularity/784 An HTTP
Archive search was performed, which showed that almost all usage comes from
one Shopify CSS file (`spec-and-compare.css`), and we intend to reach out
to Shopify (or hope for a response from one very special Blink API owner)
to make sure this will not break Shopify.


*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

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestones
Shipping on desktop 128
DevTrial on desktop 128
Shipping on Android 128
DevTrial on Android 128
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/5090673808900096?gate=5938066895405056

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

[blink-dev] Intent to Ship: Rename inset-area to position-area

2024-07-10 Thread Mason Freed 
{NOTE: this is a replacement of this chromestatus
, which has the wrong
feature type and cannot be changed.}
Contact emailsmas...@chromium.org

ExplainerNone

Specification
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001

Summary

The CSSWG resolved to rename this property from `inset-area` to
`position-area`. See the CSSWG discussion here:
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
Chrome disagrees with this change, but would like to ship an interoperable
implementation. We will ship the new property name, `position-area`, as a
synonym for `inset-area` first. Then after a suitable amount of time, we
will remove `inset-area`. The latter removal will be done under a separate
Intent.


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is a compat risk with this rename, since the old name of `inset-area`
is in use, with an 0.02% use counter:
https://chromestatus.com/metrics/css/timeline/popularity/781 We will need
to ship the new name, `position-area`, first, and issue deprecation
warnings for the old name, `inset-area`, to give developers time to change.
This intent to ship is about shipping `position-area` as a synonym for
`inset-area`. We'll issue a separate I2D for removing the `inset-area`
property.


*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

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

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

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/5142143019253760?gate=5177831244693504

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/CAM%3DNeDjpLLJ-0pd%2BhJCUPnqGo63NPNV4SsXEJQh5DLucCT_2vA%40mail.gmail.com.

[blink-dev] Intent to Deprecate and Remove: Deprecation of CSS Anchor Positioning property `inset-area`

2024-07-10 Thread 'Ajay Rahatekar' via blink-dev 
Contact emailsmas...@chromium.org

ExplainerNone

Specification
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001

Summary

The CSSWG resolved to rename the `inset-area` property to `position-area`.
See the CSSWG discussion here:
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001.
The new property name, `position-area`, as a synonym for `inset-area`
shipped via https://chromestatus.com/feature/6567965055778816. This entry
is for deprecation and removal of the `inset-area` property.


Blink componentBlink>CSS


Motivation

With the CSSWG resolution on renaming the property to `position-area`, this
deprecation will clean up the implementation in Chromium for a standards
compliant feature.


Initial public proposalNone

Search tagsanchor positioning


TAG reviewNone

TAG review statusNot 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


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

Estimated milestones
Shipping on desktop 131
DevTrial on desktop 129
Shipping on Android 131
DevTrial on Android 129
Shipping on WebView 131

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5944933945704448?gate=6046273227718656

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/CAHB%2BDAhbysWX2rT2QGMiv%3D2XvxYD9pzKTy894OFP81RNoPHKMg%40mail.gmail.com.

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

2024-07-10 Thread 'Mason Freed' via blink-dev 
I'd like to check back in on this deprecation. The drop in usage from May 
continued into June and July, with current numbers hovering around 0.003%: 
https://chromestatus.com/metrics/feature/timeline/popularity/3874. I added 
deprecation messages in M127, but that's not even in stable yet. My guess 
would be that usage will continue to drop as 127 goes to stable.

Given the above, I'd like to re-request permission to remove the feature in 
M129, assuming all of the trends continue to look good.

Thanks,
Mason
 

On Tuesday, June 4, 2024 at 12:28:54 AM UTC-7 Daniel Bratell wrote:

> 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 
>  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) <
> yoav...@chromium.org> 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 
>>  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 t

Re: [blink-dev] Web-Facing Change PSA: Rename inset-area to position-area

2024-07-10 Thread Mason Freed 
On Wed, Jul 10, 2024 at 1:35 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Given the usage, I think this should be an intent rather than a PSA. Can
> you send one?
>

This is the email template you get when you use the "Web developer-facing
change to existing code" feature type on chromestatus. I do believe that's
the best description of this change, right? This is not a "New feature
incubation", nor is it exactly an "Existing feature implementation". I've
learned through painful experience never to change the title of these
intent emails. I was assuming this still requires 3 LGTMs from owners.

Thanks,
Mason


On Wed, Jul 10, 2024 at 8:15 PM Mason Freed  wrote:
>
>> Contact emailsmas...@chromium.org
>>
>> Specification
>> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>>
>> Summary
>>
>> The CSSWG resolved to rename this property from `inset-area` to
>> `position-area`. See the CSSWG discussion here:
>> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>> Chrome disagrees with this change, but would like to ship an interoperable
>> implementation. We will ship the new property name, `position-area`, as a
>> synonym for `inset-area` first. Then after a suitable amount of time, we
>> will remove `inset-area`. The latter removal will be done under a separate
>> Intent.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> Search tagsanchor positioning
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is a compat risk with this rename, since the old name of
>> `inset-area` is in use, with an 0.02% use counter:
>> https://chromestatus.com/metrics/css/timeline/popularity/781 We will
>> need to ship the new name, `position-area`, first, and issue deprecation
>> warnings for the old name, `inset-area`, to give developers time to change.
>> This intent to ship is about shipping `position-area` as a synonym for
>> `inset-area`. We'll issue a separate I2D for removing the `inset-area`
>> property.
>>
>>
>> *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
>> 
>> ?Yes
>>
>> https://wpt.fyi/results/css/css-anchor-position
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/35293
>>
>> Estimated milestones
>> Shipping on desktop 129
>> DevTrial on desktop 129
>> Shipping on Android 129
>> DevTrial on Android 129
>> Shipping on WebView 129
>>
>> 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/6567965055778816?gate=5360672631422976
>>
>> 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/CAM%3DNeDiwrPpAtU%2Byn-OAUBZoEfeYN%2Bgyjg_Vv9_RzEyMKak9Bw%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/CAM%3DNeDgbhmPKJgo1%3DCwpduQ7wM2MSEDFAL4qF3hZX1fhSgAERQ%40mail.gmail.com.

Re: [blink-dev] Web-Facing Change PSA: Rename inset-area to position-area

2024-07-10 Thread Yoav Weiss (@Shopify) 
Given the usage, I think this should be an intent rather than a PSA. Can
you send one?

On Wed, Jul 10, 2024 at 8:15 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Specification
> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>
> Summary
>
> The CSSWG resolved to rename this property from `inset-area` to
> `position-area`. See the CSSWG discussion here:
> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
> Chrome disagrees with this change, but would like to ship an interoperable
> implementation. We will ship the new property name, `position-area`, as a
> synonym for `inset-area` first. Then after a suitable amount of time, we
> will remove `inset-area`. The latter removal will be done under a separate
> Intent.
>
>
> Blink componentBlink>CSS
> 
>
> Search tagsanchor positioning
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is a compat risk with this rename, since the old name of
> `inset-area` is in use, with an 0.02% use counter:
> https://chromestatus.com/metrics/css/timeline/popularity/781 We will need
> to ship the new name, `position-area`, first, and issue deprecation
> warnings for the old name, `inset-area`, to give developers time to change.
> This intent to ship is about shipping `position-area` as a synonym for
> `inset-area`. We'll issue a separate I2D for removing the `inset-area`
> property.
>
>
> *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
> 
> ?Yes
>
> https://wpt.fyi/results/css/css-anchor-position
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/35293
>
> Estimated milestones
> Shipping on desktop 129
> DevTrial on desktop 129
> Shipping on Android 129
> DevTrial on Android 129
> Shipping on WebView 129
>
> 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/6567965055778816?gate=5360672631422976
>
> 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/CAM%3DNeDiwrPpAtU%2Byn-OAUBZoEfeYN%2Bgyjg_Vv9_RzEyMKak9Bw%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/CAOmohS%2B24jAU173F1esaAW559FY7gCD%3D6DrbxMJ1soQ9cqqozw%40mail.gmail.com.

[blink-dev] Web-Facing Change PSA: Rename inset-area to position-area

2024-07-10 Thread Mason Freed 
Contact emailsmas...@chromium.org

Specification
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001

Summary

The CSSWG resolved to rename this property from `inset-area` to
`position-area`. See the CSSWG discussion here:
https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
Chrome disagrees with this change, but would like to ship an interoperable
implementation. We will ship the new property name, `position-area`, as a
synonym for `inset-area` first. Then after a suitable amount of time, we
will remove `inset-area`. The latter removal will be done under a separate
Intent.


Blink componentBlink>CSS


Search tagsanchor positioning


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is a compat risk with this rename, since the old name of `inset-area`
is in use, with an 0.02% use counter:
https://chromestatus.com/metrics/css/timeline/popularity/781 We will need
to ship the new name, `position-area`, first, and issue deprecation
warnings for the old name, `inset-area`, to give developers time to change.
This intent to ship is about shipping `position-area` as a synonym for
`inset-area`. We'll issue a separate I2D for removing the `inset-area`
property.


*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

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/35293

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

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/6567965055778816?gate=5360672631422976

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/CAM%3DNeDiwrPpAtU%2Byn-OAUBZoEfeYN%2Bgyjg_Vv9_RzEyMKak9Bw%40mail.gmail.com.

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

2024-07-10 Thread Yoav Weiss (@Shopify) 
A few things trouble me here.

   - Dependency injection
  - The initial intent 
  

 indicated 
  dependency on Enterprise Policy, rather than IWAs.
  - I see some reasoning for the new dependency in the design doc's 
security 
  considerations 
  
,
 
  but it seems incomplete
 - e.g. why couldn't you enforce CSP and TrustedTypes as a 
 requirement for this regardless of IWA? How does bundling help when 
 allowing one app to leak information from others? Wasn't there 
controls in 
 place limiting the origins that can do that as part of the Enterprise 
 Policy?
 -  I may be missing context as a lot of the links in that doc are 
 still Google-only
  - Timelines
   - The initial trial went from 118 to 124.
  - On this thread I see you started by asking for an extension from 
  124 to 130, and then switched to asking for 129 to 132.
  - At the same time, I don't believe the OT was put on hold when 124 
  was released. 
  - *What happened between M124 and M128?*
   - Progress towards shipping
  - On top of that, no evidence of substantial progress towards 
  shipping was demonstrated. Again, the design doc still contains many 
  Google-only links, so I may be missing context here, but this section 
  

 feels 
  very much like a soft launch. The Origin Trial risks 
  

 we 
  are trying to avoid don't seem to have been carefully considered.
   

Putting all this together, I don't think we should renew the current trial.



On Wednesday, June 26, 2024 at 6:18:45 PM UTC+2 Simon Hangl wrote:

> Oops, upon friendly clarification from a colleague I realized that your 
> comment was probably about making the doc visible to everyone :) . I 
> updated the doc permissions now.
>
> On Wednesday, June 26, 2024 at 10:43:35 AM UTC+2 Simon Hangl wrote:
>
>> @Daniel, thanks for your questions / comments. We intend to make 
>> getAllScreensMedia available for everybody once isolated web apps launch 
>> (we are asking to extend the origin trial to already gain insights on the 
>> API before isolated web apps launch - see also the "Short term solution 
>> until IWAs are available" section in the design doc). This also brings me 
>> to the 2nd part of your question: we made significant progress towards 
>> isolated web apps (we are mostly code complete and the intent to launch 
>> will be submitted within the next 1-3 milestones).
>>
>>
>> On Tuesday, June 25, 2024 at 7:48:07 PM UTC+2 Daniel Bratell wrote:
>>
>>> 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 <
 blin...@chromium.org> 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/captur

Re: [blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

2024-07-10 Thread Mason Freed 
On Wed, Jul 3, 2024 at 3:02 AM Yoav Weiss (@Shopify) 
wrote:

> Note: They can preemptively handle this change today by using
>> position-try:flip-inline instead.
>>
>>
>>> It's tricky, because waiting could actually cause *more* breakage, even
>>> with a deprecation period, and the numbers look quite good right now.
>>>
>>
> If the app in question could switch to `position-try:flip-inline` that
> changes things, and would indeed not require a milestone overlap, assuming
> they can make that change.
>

I've received the contact info privately, and I'll reach out to the
affected app. Assuming that goes well, it sounds like we might be ok
shipping a direct rename?

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
>>>
>>>
>>> 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-anchor-position
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/349600667
>>>
>>> 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/5167414571696128?gate=5182169462079488
>>>
>>> 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/cf8a8c9d-9efa-4bff-9dd5-590809fe2877n%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/CAM%3DNeDhcW59r5yuE%3DEK0cXAsYsqsEut7pUw_omJX_iookEPcnw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSSImportRule.styleSheet

2024-07-10 Thread Chris Harrelson 
Hi, we are going to go ahead and close this review. Please let us know if
and when you come back to it so we can reopen.

On Wed, Mar 6, 2024 at 9:12 AM Daniel Bratell  wrote:

> (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) <
>> yoav...@chromium.org> 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 <
>>> 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&label=master&aligned
 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 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,

Re: [blink-dev] Ready for Developer Testing: Web Authentication API: JSON serialization methods

2024-07-10 Thread Mike Taylor 

Hi Martin,

Is this intended to be an Intent to Ship, or dev trial?

thanks,
Mike

On 6/26/24 2:28 PM, 'Martin Kreichgauer' via blink-dev wrote:



Contact emails

marti...@google.com


Explainer

https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods


Specification

https://w3c.github.io/webauthn/#publickeycredential


Summary

The WebAuthn PublicKeyCredential.toJSON(), 
parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() 
methods let developers serialize a WebAuthn response into a JSON 
object or deserialize a WebAuthn request object from its JSON 
representation.




Blink component

Blink>WebAuthentication 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility)


/WebKit/: No signal

/Web developers/: Positive (https://github.com/github/webauthn-json) 
webauthn-json is a widely used polyfill for this API maintained by Github.


/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

None



Debuggability

None



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

Yes

This feature is implemented in Blink renderer code and shipping on all 
platforms.




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html 
https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html 
https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html




DevTrial instructions

https://docs.google.com/document/d/e/2PACX-1vSl4jywfU4xD3fkWrC-T5hHI79xs90oOq9tVSx4M63WkcI-wuk-nnFlPlDIAttrpTEd5BbXABJnDuxT/pub


Flag name on chrome://flags

enable-experimental-web-platform-features


Finch feature name

WebAuthenticationJSONSerialization


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

DevTrial on desktop 128

DevTrial on Android 128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5141695044255744


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEbBz4a%2BEE-KbbRDkEexDON8hCfCC-saD600J7fo9J3jZg%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/CAB%3DfcEZFNdKypxjgMis0WGNVHs7hA6hw3UAXynKDs7ig0bPcgg%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/74eaa160-e5cb-46ab-b290-42b8bc8c0b1d%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

2024-07-10 Thread Mike Taylor 


On 7/8/24 4:05 PM, Alex Turner wrote:



Contact emails

ale...@chromium.org


Explainer

https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md


Specification

https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123


Summary

Modifies the Private Aggregation API to add a 'filtering ID' to the 
aggregatable reports' encrypted payloads. This ID allows histogram 
contributions with different filtering IDs to be processed separately 
on the aggregation service. A list of filtering IDs could be provided 
in an aggregation query and any contributions not matching a listed ID 
will be filtered out, not contributing to the result. To support the 
new feature, we update the report version to "1.0" (from "0.1"). By 
the time this is launched to Stable, all valid aggregation service 
releases will support the new report version, avoiding backwards 
compatibility concerns. (Old releases are deprecated on a regular 
schedule.)




Blink component

Blink>PrivateAggregation 




TAG review

https://github.com/w3ctag/design-reviews/issues/846 (We have not 
requested a signal for these changes specifically.)



TAG review status

Pending


Risks



Interoperability and Compatibility

The Aggregation Service (used to process the aggregatable reports) 
typically allows its releases to be used for up to six months. To 
reduce the compatibility impact of this change, we are waiting until 
all current Aggregation Service releases support the new version 
before rolling to Stable.


Can you say more about this? How many parties are running these 
services, and do we have any way of knowing what the uptake of new 
versions is, or said differently - can we tell if they're still on older 
versions?


Also, what happens if you send the filter ID to an older version?




/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/805) We have 
not requested a signal for this change specifically. The Gecko 
position on Shared Storage (one of the ways Private Aggregation is 
exposed) is negative.


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/189) We have not 
requested a signal for this change specifically.


/Web developers/: Positive signals for broad 
feature (https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92) 



/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

No new debug capabilities beyond the existing internals page 
(chrome://private-aggregation-internals) and temporary debug mode. 
These capabilities do support the new filtering IDs.




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

All but Webview



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

PrivateAggregationApiFilteringIds


Requires code in //chrome?

False


Tracking bug

https://crbug.com/330744610


Launch bug

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


Estimated milestones

Shipping on desktop 128

Shipping on Android 128



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4793172803977216?gate=5039125582577664

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/CAA%2BBiFk3Nz9owQQnA9XzYa43cLAoh53dXGQTEstn%2BStUuud--Q%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/e436def7-548c-463b-8ece-c394aefe9ea9%40chromium.org.