Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Hi Joe,

We are aiming for version 106!

Sara

From: Joe Medley 
Sent: Wednesday, June 22, 2022 10:19 AM
To: Mike Taylor 
Cc: Chris Harrelson ; Daniel Bratell 
; saraztang ; blink-dev 
; Danny Holly ; Sara Tang 
; Alison Maher 
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: forced-color-adjust: 
preserve-parent-color

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | 
jmed...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


On Wed, Jun 22, 2022 at 9:54 AM Mike Taylor 
mailto:miketa...@chromium.org>> wrote:
LGTM3

On 6/22/22 12:10 PM, Chris Harrelson wrote:
LGTM2

On Wed, Jun 22, 2022 at 9:05 AM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote:

LGTM1

/Daniel

On 2022-06-15 23:33, Sara Tang wrote:
Hi, reviving this thread as the CSSWG resolution at [css-color] 
[css-color-adjust] Make system colors fully resolve (but flag they were system 
colors) thus reversing the resolution of #3847 · Issue #6773 · w3c/csswg-drafts 
(github.com)
  has been reached (though the standards posiiton for this particular feature 
hasn't been updated yet).  preserve-parent-color value for forced-color-adjust 
CSS property · Issue #591 · mozilla/standards-positions 
(github.com).

To summarize,
  - If both system colors and forced colors were resolved at compute time, 
`preserve-parent-color` would not be needed. This is similar to Mozilla, which 
gets the behavior of `preserve-parent-color` "for free".
  - The resolution of #6773 is to resolve system colors at compute time. Forced 
color are still resolved at used value time.
  - Thus, `preserve-parent-color` is still needed.

I believe we should now be unblocked to ship `preserve-parent-color` :)

Sara


On Sunday, November 21, 2021 at 1:10:54 PM UTC-8 Danny Holly wrote:
cause no harm

On Thursday, October 28, 2021 at 4:45:04 PM UTC-5 Sara Tang wrote:
Contact emails
sar...@microsoft.com, alison...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sar...@microsoft.com, alison...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Re: [blink-dev] Intent to Deprecate and Remove: Expect-CT

[Emily Stark]

Update: this will likely now be deprecated in M106 and removed in M107;
using the Deprecation Reporting mechanism is proving to be significantly
more complicated than I expected.

On Tue, Jul 12, 2022 at 1:52 PM Emily Stark  wrote:

> Hi Joe -- I'm planning to deprecate in M105 and remove in M106.
>
> On Mon, Jul 11, 2022 at 9:09 AM Joe Medley  wrote:
>
>> Emily,
>>
>> In which milestone will this be removed?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Fri, Jul 8, 2022 at 9:31 AM Emily Stark  wrote:
>>
>>> Contact emailsest...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://datatracker.ietf.org/doc/rfc9163
>>>
>>> Summary
>>>
>>> Expect-CT is an HTTP header that allowed websites to opt in to
>>> Certificate Transparency enforcement before it was enforced by default. It
>>> also has reporting functionality to help developers discover CT
>>> misconfigurations.
>>>
>>>
>>> Blink componentInternals>Network>DomainSecurityPolicy
>>> 
>>>
>>> Motivation
>>>
>>> Expect-CT was designed to help transition to universal Certificate
>>> Transparency (CT) enforcement, by allowing high-value websites to opt in to
>>> CT enforcement/reporting for better security before CT enforcement was
>>> required (by Chrome) on all public websites. However, Expect-CT has now
>>> outlived its usefulness. Chrome requires CT on all public websites now, so
>>> there is no security value to Expect-CT anymore. Expect-CT was also
>>> designed to help site owners discover CT-related misconfigurations;
>>> however, now that CT is universally required, CT is generally configured in
>>> websites' certificates by certificate authorities and virtually never
>>> configured by individual site owners, thus Expect-CT has very limited value
>>> as a misconfiguration/debugging tool anymore either. No other browser has
>>> implemented Expect-CT so removing it is not an interoperability concern.
>>>
>>>
>>> Initial public proposal
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/tgn5R-58iek/m/Q6YCnu0RFQAJ
>>>
>>> TAG reviewn/a
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>> No other browser has implemented Expect-CT or given signals that they
>>> intend to (to my knowledge). Expect-CT is not user-visible so removing the
>>> feature has no compatibility risk. Developers who are currently sending the
>>> header should stop doing so just to save the bytes on the wire.
>>>
>>> While the header is served on a large percent of requests (~6%), this is
>>> likely due to a small number of large providers that can be informed of the
>>> deprecation via 1:1 outreach. As described above, the header serves no
>>> security value any longer, removing it will have no user-visible effects,
>>> and the header provides extremely minimal debugging value to developers
>>> since developers are no longer responsible for serving their own CT
>>> information (100.00% of requests serve CT information directly embedded in
>>> the certificate, which developers are not responsible for configuring).
>>>
>>> *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?
>>>
>>>
>>>
>>> Debuggability
>>>
>>> We'll add a console message informing developers that the header
>>> will/has no effect and they should remove it.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6244547273687040
>>>
>>> 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/CAPP_2SbFjjX-AEv7bUEqOcgp8JTy5t9CoYHproGe0WkJGSY3Pg%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 receiv

Re: [blink-dev] Intent to extend Origin Trial: WebGPU

[Mike Taylor]

LGTM2. I think this meets the bar of "substantial progress".

On 7/19/22 1:19 PM, Yoav Weiss wrote:

Since this goes beyond the 12 milestones timeline, this requires 3 LGTMs.

LGTM1 to experiment till M105-M109, with a 2 weeks break in the OT to 
reduce burn-in risk.


On Mon, Jul 18, 2022 at 11:50 PM Ken Russell  wrote:

Hi Blink developers and owners,

Hoping for positive feedback from the Blink API OWNERS. The
specification discussions among browser vendors are converging
well. This request for Origin Trial extension - the last one our
team plans to make - is needed at this critical juncture to allow
the most developers to provide feedback on some crucial API and
semantic changes.

Thanks,

-Ken



On Mon, Jul 18, 2022 at 7:54 AM Corentin Wallez
 wrote:


Hey Blink API owners,



The origin trial for WebGPU was started in M94 and was
extended multiple times until M105. We are asking to
extend for 4 additional releases to M109 so that we
can keep experimenting and gathering feedback from
developers. Note however that this will make the
WebGPU Origin Trial past the 12 milestone mark so it
will need special approval. We are ready to pause the
OT for some time (2 weeks was mentioned) to prevent
the risk of burn-in.


Particularly important pieces of feedback that we are
currently investigating are:

  * WGSL has a novel "uniformity analysis" type system that is
taking some time to bake. The group has addressed multiple
pieces of feedback from developers and continued
experimentation will help make sure developers can use
WGSL even with these added constraints.
  * The WebGPU API recently gained an API for the browser to
optionally surface information about the GPU being used
(vendor / architecture). It has been implemented in
Chromium only recently and we are seeking feedback from
developers.
  * We are continuing experimentation of WebGPU-based video
processing. The optimizations require quite some complex
work on the GPU stack and there are still gains to be
expected so we'd like to let some developers test in the wild.

A signal of note is that the group is already planning the
transition to Candidate Recommendation for the WebGPU API and
WGSL specifications.


Contact emails

cwal...@chromium.org, bclay...@chromium.org, kain...@chromium.org


Explainer

https://gpuweb.github.io/gpuweb/explainer/


Specification

https://gpuweb.github.io/gpuweb/


Design docs


https://gpuweb.github.io/gpuweb/
https://gpuweb.github.io/gpuweb/wgsl/
https://gpuweb.github.io/gpuweb/explainer/


Summary

The WebGPU API is the successor to the WebGL and WebGL 2
graphics APIs for the Web. It will provide modern features
such as “GPU compute” as well as lower overhead access to GPU
hardware and better, more predictable performance. WebGPU is
being developed by the “GPU for the Web” W3C community group.



The origin trial for WebGPU was started in M94 and was
extended multiple times until M105. We are asking to
extend for 4 additional releases to M109 so that we
can keep experimenting and gathering feedback from
developers. Note however that this will make the
WebGPU Origin Trial past the 12 milestone mark so it
will need special approval. We are ready to pause the
OT for some time (2 weeks was mentioned) to prevent
the risk of burn-in.


Particularly important pieces of feedback that we are
currently investigating are:

  * WGSL has a novel "uniformity analysis" type system that is
taking some time to bake. The group has addressed multiple
pieces of feedback from developers and continued
experimentation will help make sure developers can use
WGSL even with these added constraints.
  * The WebGPU API recently gained an API for the browser to
optionally surface information about the GPU being used
(vendor / architecture). It has been implemented in
Chromium only recently and we are seeking feedback from
developers.
  * We are continuing experimentation of WebGPU-based video
processing. The optimizations require quite some complex
work on the GPU stack and there are still gains to be
expected so we'd like to let some developers test in the wild.

A signa

Re: [blink-dev] Intent to extend Origin Trial: WebGPU

[Yoav Weiss]

Since this goes beyond the 12 milestones timeline, this requires 3 LGTMs.

LGTM1 to experiment till M105-M109, with a 2 weeks break in the OT to
reduce burn-in risk.

On Mon, Jul 18, 2022 at 11:50 PM Ken Russell  wrote:

> Hi Blink developers and owners,
>
> Hoping for positive feedback from the Blink API OWNERS. The specification
> discussions among browser vendors are converging well. This request for
> Origin Trial extension - the last one our team plans to make - is needed at
> this critical juncture to allow the most developers to provide feedback on
> some crucial API and semantic changes.
>
> Thanks,
>
> -Ken
>
>
>
> On Mon, Jul 18, 2022 at 7:54 AM Corentin Wallez 
> wrote:
>
>> Hey Blink API owners,
>> The origin trial for WebGPU was started in M94 and was extended
>> multiple times until M105. We are asking to extend for 4 additional
>> releases to M109 so that we can keep experimenting and gathering feedback
>> from developers. Note however that this will make the WebGPU Origin Trial
>> past the 12 milestone mark so it will need special approval. We are ready
>> to pause the OT for some time (2 weeks was mentioned) to prevent the risk
>> of burn-in.
>>
>> Particularly important pieces of feedback that we are currently
>> investigating are:
>>
>>- WGSL has a novel "uniformity analysis" type system that is taking
>>some time to bake. The group has addressed multiple pieces of feedback 
>> from
>>developers and continued experimentation will help make sure developers 
>> can
>>use WGSL even with these added constraints.
>>- The WebGPU API recently gained an API for the browser to optionally
>>surface information about the GPU being used (vendor / architecture). It
>>has been implemented in Chromium only recently and we are seeking feedback
>>from developers.
>>- We are continuing experimentation of WebGPU-based video processing.
>>The optimizations require quite some complex work on the GPU stack and
>>there are still gains to be expected so we'd like to let some developers
>>test in the wild.
>>
>> A signal of note is that the group is already planning the transition to
>> Candidate Recommendation for the WebGPU API and WGSL specifications.
>>
>> Contact emails
>> cwal...@chromium.org, bclay...@chromium.org, kain...@chromium.org
>>
>> Explainerhttps://gpuweb.github.io/gpuweb/explainer/
>>
>> Specificationhttps://gpuweb.github.io/gpuweb/
>>
>> Design docs
>> https://gpuweb.github.io/gpuweb/
>> https://gpuweb.github.io/gpuweb/wgsl/
>> https://gpuweb.github.io/gpuweb/explainer/
>>
>> Summary
>>
>> The WebGPU API is the successor to the WebGL and WebGL 2 graphics APIs
>> for the Web. It will provide modern features such as “GPU compute” as well
>> as lower overhead access to GPU hardware and better, more predictable
>> performance. WebGPU is being developed by the “GPU for the Web” W3C
>> community group.
>>
>> The origin trial for WebGPU was started in M94 and was extended
>> multiple times until M105. We are asking to extend for 4 additional
>> releases to M109 so that we can keep experimenting and gathering feedback
>> from developers. Note however that this will make the WebGPU Origin Trial
>> past the 12 milestone mark so it will need special approval. We are ready
>> to pause the OT for some time (2 weeks was mentioned) to prevent the risk
>> of burn-in.
>>
>> Particularly important pieces of feedback that we are currently
>> investigating are:
>>
>>- WGSL has a novel "uniformity analysis" type system that is taking
>>some time to bake. The group has addressed multiple pieces of feedback 
>> from
>>developers and continued experimentation will help make sure developers 
>> can
>>use WGSL even with these added constraints.
>>- The WebGPU API recently gained an API for the browser to optionally
>>surface information about the GPU being used (vendor / architecture). It
>>has been implemented in Chromium only recently and we are seeking feedback
>>from developers.
>>- We are continuing experimentation of WebGPU-based video processing.
>>The optimizations require quite some complex work on the GPU stack and
>>there are still gains to be expected so we'd like to let some developers
>>test in the wild.
>>
>> A signal of note is that the group is already planning the transition to
>> Candidate Recommendation for the WebGPU API and WGSL specifications.
>>
>> Blink componentBlink>WebGPU
>> 
>>
>> Search tagsgpu , webgl
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/626
>>
>> TAG review statusComplete (with LGTM)!
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> With positive signals (and at least WIP implementations) from all
>> browsers, the biggest interoperability risk is the surface of the API which
>> is quite

Re: [blink-dev] Intent to Ship: navigateEvent.scroll()

[Mike Taylor]

LGTM3

On 7/19/22 9:11 AM, Yoav Weiss wrote:

LGTM2

Process note: I think it'd be easier if we had an "intent to change" 
that would enable you to send a single intent for this.


On Tue, Jul 19, 2022 at 5:05 AM Chris Harrelson 
 wrote:


LGTM1

On Mon, Jul 18, 2022 at 5:06 PM Nate Chapin 
wrote:


Contact emails

jap...@chromium.org, dome...@chromium.org


Specification

https://github.com/WICG/navigation-api/pull/239


https://wicg.github.io/navigation-api/#dom-navigateevent-scroll


Summary

scroll() works very similarly to the existing restoreScroll()
except that it can be called when the navigation is not a
traversal. It also allows manually performing the scroll even
when not in manual scroll mode.



Blink component

Blink>History




TAG review

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



TAG review status

Issues open


Risks



Interoperability and Compatibility

Most of the compatibility risk comes from the removal of
restoreScroll(), and will be discussed in that separate
Intent. For those migrating to scroll(), all existing use
cases should just work by changing the function name.



Gecko: No signal
https://github.com/mozilla/standards-positions/issues/543
remains
open as the positions request for the original API.


WebKit: No signal
https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html

remains
open as the positions request for the original API.
https://github.com/WebKit/standards-positions/issues/34
was
recently opened by web developers and also remains open.


Web developers: Positive.
https://github.com/WICG/navigation-api/issues/237
came out of
discussions with web developers.


Activation

This is a slightly more featureful restoreScroll().



Security

None different than restoreScroll()



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, this should work identically on all platforms.



Debuggability

Debugging should be no different than debugging restoreScroll().



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

?

The navigation-api/ directory makes extensive use of
restoreScroll(), and we're updating it to use scroll()
alongside the implementation.


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

M105



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



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/CACf%3D2LJEWKt97W%3Db-PEvt6FZfhEhnw%3D1v1hdYL-1kPMZ2FGRSg%40mail.gmail.com

Re: [blink-dev] Intent to Deprecate and Remove: navigateEvent.restoreScroll()

[Mike Taylor]

LGTM3

On 7/19/22 9:09 AM, Yoav Weiss wrote:

LGTM2

On Tue, Jul 19, 2022 at 2:06 AM Nate Chapin  wrote:


Contact emails

jap...@chromium.org, dome...@chromium.org


Explainer

None


I think that a short (even inline) explainer can be useful to explain 
what scroll does differently than restoreScroll and how developers 
would use it. The PR's explanation 
 
(once I actually found it) is a good one.



Specification

https://github.com/WICG/navigation-api/pull/23
9


This seems like the right PR, but the link is pointing at the wrong 
one. It should be https://github.com/WICG/navigation-api/pull/239



Summary

restoreScroll() is being replaced by navigateEvent.scroll().
scroll() works identically except that it allows the developer to
control scroll timing for non-traverse navigations (i.e., scroll()
works when the scroll is not a restore, hence the name change
along with the behavior change).



Blink component

Blink>History




Motivation

We want to support developer-controlled timing of a
navigation-associated scroll in non-traverse cases (e.g.,
scrolling to a fragment). It makes sense to have the same method
drive navigation-related scrolling in both traverse and
non-traverse cases, but the name "restoreScroll" is nonsense for
push/replace navigations.



Initial public proposal

https://github.com/WICG/navigation-api/pull/23
9


Same here. Wrong link.. Should be 
https://github.com/WICG/navigation-api/pull/239



TAG review

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



TAG review status

Issues open


Risks



Interoperability and Compatibility

scroll(), which we plan to ship in the same milestone as this
deprecation, is in development and works identically in all cases
that restoreScroll() can be used.


Also, restoreScroll() only recently shipped (M102). There are few
consumers of the API, and we are in contact with most of them
already, so we believe we can guide them on any migration
challenges they might have.


The overall use counter for the navigation API
(https://chromestatus.com/metrics/feature/timeline/popularity/4056
)
shows 0.000301% of pages on the web using any portion of the API,
which provides an upper bound on the potential breakage here.
(That use counter also counts various other entry points to the
API, which are not being changed.)


Usage seems low enough and we're close enough to when we shipped this 
that changing course now seems reasonable.



We plan to support both scroll() and restoreScroll() for 3
releases to provide a migration period (adding scroll() in M105,
removing restoreScroll() in M108).We are bundling this change with
a similar migration from navigateEvent.transitionWhile() to
navigateEvent.intercept() on the same timeline to minimize the
developer pain.



Gecko: No signal
https://github.com/mozilla/standards-positions/issues/543
remains
open as the positions request for the original API.


WebKit: No signal
https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html

remains
open as the positions request for the original API.
https://github.com/WebKit/standards-positions/issues/34
was
recently opened by web developers and also remains open.


Web developers: Positive
https://github.com/WICG/navigation-api/issues/237
came out of
discussions with web developers.


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?The deprecation risk here is not especially high for
WebView applications.



Debuggability

N/A



Is this feature fully tested by web-platform-tests

?

Official web platform tests support will switch over to scroll()
when it lands. We will retain restoreScroll() tests in
wpt_internal/navigation-api/ until restoreScroll() is removed.


Requires code in //chrome?

   

Re: [blink-dev] Intent to Ship: navigateEvent.scroll()

[Yoav Weiss]

LGTM2

Process note: I think it'd be easier if we had an "intent to change" that
would enable you to send a single intent for this.

On Tue, Jul 19, 2022 at 5:05 AM Chris Harrelson 
wrote:

> LGTM1
>
> On Mon, Jul 18, 2022 at 5:06 PM Nate Chapin  wrote:
>
>> Contact emails
>>
>> jap...@chromium.org, dome...@chromium.org
>>
>> Specification
>>
>> https://github.com/WICG/navigation-api/pull/239
>>
>> https://wicg.github.io/navigation-api/#dom-navigateevent-scroll
>>
>> Summary
>>
>> scroll() works very similarly to the existing restoreScroll() except that
>> it can be called when the navigation is not a traversal. It also allows
>> manually performing the scroll even when not in manual scroll mode.
>>
>>
>> Blink component
>>
>> Blink>History
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/717
>>
>> TAG review status
>>
>> Issues open
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Most of the compatibility risk comes from the removal of restoreScroll(),
>> and will be discussed in that separate Intent. For those migrating to
>> scroll(), all existing use cases should just work by changing the function
>> name.
>>
>>
>> Gecko: No signal
>> https://github.com/mozilla/standards-positions/issues/543 remains open
>> as the positions request for the original API.
>>
>> WebKit: No signal
>> https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html
>> remains open as the positions request for the original API.
>> https://github.com/WebKit/standards-positions/issues/34 was recently
>> opened by web developers and also remains open.
>>
>> Web developers: Positive.
>> https://github.com/WICG/navigation-api/issues/237 came out of
>> discussions with web developers.
>>
>> Activation
>>
>> This is a slightly more featureful restoreScroll().
>>
>>
>> Security
>>
>> None different than restoreScroll()
>>
>>
>> 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, this should work identically on all platforms.
>>
>>
>> Debuggability
>>
>> Debugging should be no different than debugging restoreScroll().
>>
>>
>> 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
>> 
>> ?
>>
>> The navigation-api/ directory makes extensive use of restoreScroll(), and
>> we're updating it to use scroll() alongside the implementation.
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1345507
>>
>> Estimated milestones
>>
>> M105
>>
>>
>> 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/5194856243134464
>>
>> 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/CACf%3D2LJEWKt97W%3Db-PEvt6FZfhEhnw%3D1v1hdYL-1kPMZ2FGRSg%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%2Bw9tPmzPPRBOjUTCSgTFnhKO4ecxP2cd3RsdmaZ%2BkcTufQ%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/CA

Re: [blink-dev] Intent to Deprecate and Remove: navigateEvent.restoreScroll()

[Yoav Weiss]

LGTM2

On Tue, Jul 19, 2022 at 2:06 AM Nate Chapin  wrote:

> Contact emails
>
> jap...@chromium.org, dome...@chromium.org
>
> Explainer
>
> None
>

I think that a short (even inline) explainer can be useful to explain what
scroll does differently than restoreScroll and how developers would use it.
The PR's explanation
 (once I
actually found it) is a good one.


>
> Specification
>
> https://github.com/WICG/navigation-api/pull/23
> 9
>

This seems like the right PR, but the link is pointing at the wrong one. It
should be https://github.com/WICG/navigation-api/pull/239


> Summary
>
> restoreScroll() is being replaced by navigateEvent.scroll(). scroll()
> works identically except that it allows the developer to control scroll
> timing for non-traverse navigations (i.e., scroll() works when the scroll
> is not a restore, hence the name change along with the behavior change).
>

>
> Blink component
>
> Blink>History
> 
>
> Motivation
>
> We want to support developer-controlled timing of a navigation-associated
> scroll in non-traverse cases (e.g., scrolling to a fragment). It makes
> sense to have the same method drive navigation-related scrolling in both
> traverse and non-traverse cases, but the name "restoreScroll" is nonsense
> for push/replace navigations.
>
>
> Initial public proposal
>
> https://github.com/WICG/navigation-api/pull/23
> 9
>

Same here. Wrong link.. Should be
https://github.com/WICG/navigation-api/pull/239


>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/717
>
> TAG review status
>
> Issues open
>
> Risks
>
> Interoperability and Compatibility
>
> scroll(), which we plan to ship in the same milestone as this deprecation,
> is in development and works identically in all cases that restoreScroll()
> can be used.
>
> Also, restoreScroll() only recently shipped (M102). There are few
> consumers of the API, and we are in contact with most of them already, so
> we believe we can guide them on any migration challenges they might have.
>

> The overall use counter for the navigation API (
> https://chromestatus.com/metrics/feature/timeline/popularity/4056) shows
> 0.000301% of pages on the web using any portion of the API, which provides
> an upper bound on the potential breakage here. (That use counter also
> counts various other entry points to the API, which are not being changed.)
>

Usage seems low enough and we're close enough to when we shipped this that
changing course now seems reasonable.


>
> We plan to support both scroll() and restoreScroll() for 3 releases to
> provide a migration period (adding scroll() in M105, removing
> restoreScroll() in M108).
>
> We are bundling this change with a similar migration from
> navigateEvent.transitionWhile() to navigateEvent.intercept() on the same
> timeline to minimize the developer pain.
>
>
> Gecko: No signal https://github.com/mozilla/standards-positions/issues/543
> remains open as the positions request for the original API.
>
> WebKit: No signal
> https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html
> remains open as the positions request for the original API.
> https://github.com/WebKit/standards-positions/issues/34 was recently
> opened by web developers and also remains open.
>
> Web developers: Positive https://github.com/WICG/navigation-api/issues/237
> came out of discussions with web developers.
>

> 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?
> The deprecation risk here is not especially high for WebView applications.
>
>
> Debuggability
>
> N/A
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Official web platform tests support will switch over to scroll() when it
> lands. We will retain restoreScroll() tests in wpt_internal/navigation-api/
> until restoreScroll() is removed.
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1345507
>
> Estimated milestones
>
> Deprecate: M105. Remove: M108.
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5029730789621760
>
> 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/CACf%3D2L%2BJqMivnC8NVq2

Re: [blink-dev] Intent to Extend Experiment: Dark mode support for web apps

[Yoav Weiss]

LGTM to extend experimentation till M107 inclusive.

OT extensions beyond 6 milestones requiring demonstration of progress
towards meeting the shipping bars, and I believe the PR draft below shows
such progress. Thanks! :)

On Tue, Jul 19, 2022 at 7:49 AM 'Louise Brett' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsloubr...@google.com, glen...@chromium.org,
> mgi...@chromium.org
>
> Explainer
> https://github.com/WICG/manifest-incubations/blob/gh-pages/user-preferences-explainer.md
>
> SpecificationIn progress:
> https://github.com/WICG/manifest-incubations/pull/57
>
> Summary
>
> Add a field to the web app manifest which allows apps to specify a
> different theme color and background color for dark mode.
>
>
> Blink componentBlink>AppManifest
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/696
>
> TAG review statusClosed. Requested changes were made.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/630)
>
> *WebKit*: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2022-April/032187.html)
>
> *Web developers*: Positive (https://github.com/w3c/manifest/issues/975)
>

Any more specific pointers towards developer signals? It's a long thread,
with many browser folks.


>
> *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?
>
>
>
> Goals for experimentation
>
> Allow web developers to use this field and provide feedback.
>
>
> Reason this experiment is being extended
>
> The manifest format will be changing again - there are ongoing discussions
> as to what this should look like.
>
>
>
> Ongoing technical constraints
>
>
>
> Debuggability
>
> chrome://web-app-internals can be used for debugging, and this has been
> added to the DevTools Application pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Not supported on Android
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag namechrome://flags/#enable-experimental-web-platform-features
>
> Requires code in //chrome?True
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1271804
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1279284
>
> Estimated milestones
> OriginTrial desktop last 104
> OriginTrial desktop first 99
>
> Requesting a 3 milestone extension to 107 (inclusive).
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5714780426862592
>
> Links to previous Intent discussionsIntent to prototype
> 
> Intent to Experiment
> 
> Intent to Extend Experiment
> 
>  -
> Gave the experiment a 6 milestone duration
>
> 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/CABeVxY3DM03k_09hUFONFfOrzDAvr1JPPYgXywRvLCOieUaKjA%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/CAL5BFfV9NxmioM%2BQ%2BjYQyG1cGfjg7tWRpPhsdHUVkKaVv_OFWQ%40mail.gmail.com.