Re: [blink-dev] Re: Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Here's an update as the target milestone M109 has reached stable for quite
a while.

On all platforms, other than Android WebView, the feature has been removed
as planned. So far we haven't received any complaints.

For WebView, the original plan was to gradually roll out a removal via
Finch. However, due to a Chromium-side implementation error, Finch was
unable to change the feature status, which means it's still enabled at 100%
in M109 stable. This has been fixed in M111. (See more details at
https://chromium-review.googlesource.com/c/chromium/src/+/4188673)

To ensure a smooth removal, we will postpone the removal on WebView to M111.

On Sun, Oct 16, 2022 at 3:58 PM TAMURA, Kent  wrote:

> LGTM3
>
>
> On Fri, Oct 14, 2022 at 10:52 AM Yoav Weiss 
> wrote:
>
>> LGTM2. Thanks for the thorough analysis. Please roll this out carefully.
>>
>> On Thu, Oct 13, 2022 at 8:07 PM Chris Harrelson 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Thu, Oct 13, 2022 at 11:06 AM Xiaocheng Hu 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Here's an update as now the trunk has reached M109, the target
>>>> milestone for the removal.
>>>>
>>>> Event.path has been fully disabled on Canary & Dev, 50% on Beta and 1%
>>>> on Stable. To help migration, an enterprise policy
>>>> <https://chromeenterprise.google/policies/#EventPathEnabled> is also
>>>> added to extend the availablility of Event.path until M115.
>>>>
>>>> Despite the usage number
>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/345>
>>>> still being high, I think the actual compat risks of the removal is low
>>>> because:
>>>> - The feature is never supported by WebKit or Gecko, yet there's no bug
>>>> reports for them
>>>> - Since the partial disabling, we have received only one complaint
>>>> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/xt4XJYpoHXo/m/yBW13BXvAAAJ>,
>>>> which appears resolved by the enterprise policy
>>>> - HTTPArchive source analysis
>>>> <https://docs.google.com/document/d/1JUeNc-ZxxWTn2tz9M_DJ4cV-M8lBdp40xlnfQ2-Mhgg/edit>
>>>> (done in June) shows that very few (<0.1%) pages actually have a usage that
>>>> will fail after the removal; Many other pages are using the feature with
>>>> Event.composedPath() or some ad hoc code as a fallback, or are not real
>>>> usage (e.g., cloning every attribute of an Event object, hence triggering
>>>> the use counter without actually using it)
>>>>
>>>>
>>>>
>>>> On Tuesday, February 8, 2022 at 4:25:57 PM UTC-8 Xiaocheng Hu wrote:
>>>>
>>>>> Contact emailsxiaoche...@chromium.org
>>>>>
>>>>> ExplainerNone
>>>>>
>>>>> SpecificationNone. Not a standard feature.
>>>>>
>>>>> Summary
>>>>>
>>>>> Event.path is a non-standard API that returns the event's path, which
>>>>> is an array of the objects on which listeners will be invoked. It is
>>>>> supported by Blink only, causing web compatibility issues. Web developers
>>>>> should switch to the equivalent standard API Event.composedPath(), which
>>>>> returns the same result.
>>>>>
>>>>>
>>>>> Blink componentBlink>DOM
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>
>>>>>
>>>>> TAG review
>>>>>
>>>>> TAG review statusNot applicable
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> The removal of this API should improve interoperability, as it's
>>>>> supported by Blink only. It still has 18% usage as of Feb 2022 (
>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/345), so
>>>>> we will only deprecate it for now, and will not remove it before the usage
>>>>> drops low enough. We expect low compatibility risks, since there is an
>>>>> equivalent standard API (Event.composedPath()) by all browsers, and the
>>>>> following polyfill should also keep existing sites functioning with 
>>>>> minimum
>>>>> changes: if (!Event.prototype.path) {
>>>>> Object.defineProperty(Event.prototype, 'path', { get() { return
>>>>> this.

[blink-dev] Re: Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Hi all,

Here's an update as now the trunk has reached M109, the target milestone 
for the removal.

Event.path has been fully disabled on Canary & Dev, 50% on Beta and 1% on 
Stable. To help migration, an enterprise policy 
<https://chromeenterprise.google/policies/#EventPathEnabled> is also added 
to extend the availablility of Event.path until M115.

Despite the usage number 
<https://chromestatus.com/metrics/feature/timeline/popularity/345> still 
being high, I think the actual compat risks of the removal is low because:
- The feature is never supported by WebKit or Gecko, yet there's no bug 
reports for them
- Since the partial disabling, we have received only one complaint 
<https://groups.google.com/a/chromium.org/g/chromium-dev/c/xt4XJYpoHXo/m/yBW13BXvAAAJ>,
 
which appears resolved by the enterprise policy
- HTTPArchive source analysis 
<https://docs.google.com/document/d/1JUeNc-ZxxWTn2tz9M_DJ4cV-M8lBdp40xlnfQ2-Mhgg/edit>
 
(done in June) shows that very few (<0.1%) pages actually have a usage that 
will fail after the removal; Many other pages are using the feature with 
Event.composedPath() or some ad hoc code as a fallback, or are not real 
usage (e.g., cloning every attribute of an Event object, hence triggering 
the use counter without actually using it)


 
On Tuesday, February 8, 2022 at 4:25:57 PM UTC-8 Xiaocheng Hu wrote:

> Contact emailsxiaoche...@chromium.org
>
> ExplainerNone
>
> SpecificationNone. Not a standard feature.
>
> Summary
>
> Event.path is a non-standard API that returns the event's path, which is 
> an array of the objects on which listeners will be invoked. It is supported 
> by Blink only, causing web compatibility issues. Web developers should 
> switch to the equivalent standard API Event.composedPath(), which returns 
> the same result.
>
>
> Blink componentBlink>DOM 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The removal of this API should improve interoperability, as it's supported 
> by Blink only. It still has 18% usage as of Feb 2022 (
> https://chromestatus.com/metrics/feature/timeline/popularity/345), so we 
> will only deprecate it for now, and will not remove it before the usage 
> drops low enough. We expect low compatibility risks, since there is an 
> equivalent standard API (Event.composedPath()) by all browsers, and the 
> following polyfill should also keep existing sites functioning with minimum 
> changes: if (!Event.prototype.path) { 
> Object.defineProperty(Event.prototype, 'path', { get() { return 
> this.composedPath(); } }); }
>
>
> Gecko: No signal Firefox does not support Event.path
>
> WebKit: No signal Safari does not support Event.path
>
> Web developers: Positive (
> https://github.com/web-platform-tests/interop-2022/issues/26)
>
> Other signals:
>
>
> Debuggability
>
> Usage of this deprecated feature will be reported to the DevTools Issues 
> Tab.
>
>
> Is this feature fully tested by web-platform-tests 
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1277431
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5726124632965120
>
> This intent message was generated by Chrome Platform Status 
> <https://chromestatus.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/9547aff7-15ad-420e-8574-d5bfc06b67c3n%40chromium.org.

[blink-dev] Re: Intent to Prototype: Scoped Custom Element Registry

[Xiaocheng Hu]

Hi Lea,

No TAG review has been requested yet. "Pending" is just the default value
(which might also be confusing though...)

On Fri, Aug 26, 2022 at 3:19 AM Lea Verou  wrote:

> Hi there,
> I see it says "Pending" for the TAG review, but I cannot find any TAG
> review request in
> https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
> Could you please point me to it?
> Thanks!
>
> On Thursday, August 25, 2022 at 1:06:33 AM UTC+3 xiaoc...@chromium.org
> wrote:
>
>> Contact emailsxiaoc...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md#overview
>>
>> Specification
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>>
>> Summary
>>
>> This feature allows for multiple custom element definitions for a single
>> tag name to exist within a page to prevent custom element name conflicts
>> when a web app uses libraries from multiple sources. This is achieved by
>> allowing user code to create multiple custom element registries and
>> associate them with shadow roots that function as scopes for element
>> creation and custom element definitions.
>>
>>
>> Blink componentBlink>HTML>CustomElements
>> 
>>
>> Motivation
>>
>> It's quite common for web applications to contain libraries from multiple
>> sources, whether from different teams, vendors, package managers, etc.
>> These libraries must currently contend for the global shared resource that
>> is the CustomElementRegistry. If more than one library (or more than one
>> instance of a library) tries to define the same tag name, the application
>> will fail. This feature solves the problem by using ShadowRoots, which
>> already function as encapsulation boundaries, to also function as scopes
>> for custom element definitions.
>>
>>
>> Initial public proposal
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>>
>> TAG review
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *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
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1304439
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5090435261792256
>>
>> 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/CAFqEGhbLNaN9zvp5msuHm-BhG0Gs1LOTJUPMCG1ELyvJr_cc8w%40mail.gmail.com.

[blink-dev] Intent to Prototype: Scoped Custom Element Registry

[Xiaocheng Hu]

Contact emailsxiaoche...@chromium.org

Explainer
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md#overview

Specification
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md

Summary

This feature allows for multiple custom element definitions for a single
tag name to exist within a page to prevent custom element name conflicts
when a web app uses libraries from multiple sources. This is achieved by
allowing user code to create multiple custom element registries and
associate them with shadow roots that function as scopes for element
creation and custom element definitions.


Blink componentBlink>HTML>CustomElements


Motivation

It's quite common for web applications to contain libraries from multiple
sources, whether from different teams, vendors, package managers, etc.
These libraries must currently contend for the global shared resource that
is the CustomElementRegistry. If more than one library (or more than one
instance of a library) tries to define the same tag name, the application
will fail. This feature solves the problem by using ShadowRoots, which
already function as encapsulation boundaries, to also function as scopes
for custom element definitions.


Initial public proposal
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



*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



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAFqEGhaAi0t1ffJoE8Du9bB2Wwxt6CewJjxz2Y_m9qWuoAa-Ug%40mail.gmail.com.

Re: [blink-dev] Is "Keyboard-focusable scroll containers" still in development?

[Xiaocheng Hu]

Hi Benjamin,

Last time it was unshipped due to breaking Web UI.

This is currently tracked by crbug.com/1040141 and owned by the DOM team.

I'll update the chromestatus.com entry accordingly.

On Wed, Jun 15, 2022 at 2:46 PM 'Benjamin Beaudry' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi all,
>
> Is this feature still in development? Keyboard-focusable scroll
> containers - Chrome Platform Status (chromestatus.com)
> 
> It's currently sitting behind the runtime flag KeyboardFocusableScrollers,
> and it looks like it hasn't been modified in the last 4 years. I think the
> owner of that feature is not around anymore, so I'm wondering if someone
> picked it up or if it's just abandoned.
>
> Thanks,
> Ben
>
> --
> 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/CH2PR00MB08280D0E4086BCB206E809649BAD9%40CH2PR00MB0828.namprd00.prod.outlook.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/CAFqEGhbaQNc9SW%2BWrm3ST2qENu4Sdg29sRRkc39t9DazhPKEeA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: 'blocking=rendering' attribute on scripts and style sheets

[Xiaocheng Hu]

Thanks for the approval! I'll enable it in M105, after the M104 branch this
week.

On Wed, Jun 8, 2022 at 7:58 AM Mike Taylor  wrote:

> LGTM3
>
> On 6/8/22 2:56 AM, Yoav Weiss wrote:
>
> LGTM2
>
> On Wed, Jun 1, 2022 at 5:50 PM Daniel Bratell  wrote:
>
>> LGTM1
>>
>> /Daniel
>> On 2022-05-25 11:03, Yoav Weiss wrote:
>>
>> Thanks for working on this!! :)
>>
>> On Mon, May 23, 2022 at 9:21 PM Xiaocheng Hu 
>> wrote:
>>
>>> (Note: The feature no longer works on preloads, compared to the original
>>> I2P. See explainer for details.)
>>>
>>> Contact emails xiaoche...@chromium.org
>>>
>>> Explainer
>>> https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d#file-proposal-v3-md
>>>
>>> Specification https://github.com/whatwg/html/pull/7474
>>>
>>> Summary
>>>
>>> Allows putting 'blocking=render' as an attribute and value to a
>>> 

[blink-dev] PSA: Event.path has been disabled in pre-Beta channels

[Xiaocheng Hu]

Hi,

As part of the deprecation process, we have disabled the non-standard API
Event.path by default on Canary and Dev channels, as well as developer
builds. It will remain enabled by default in Beta and Stable channels until
the final removal (in M109 as currently planned).

The change is made in Chromium source code, so it may also affect embedders.

See also:
- Code change: crrev.com/c/3662186
- Intent to deprecate:
https://groups.google.com/a/chromium.org/g/blink-dev/c/UYY2TRSL8_k/m/rbgamivQBgAJ

Regards,
Xiaocheng

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

[blink-dev] Intent to Ship: 'blocking=rendering' attribute on scripts and style sheets

[Xiaocheng Hu]

(Note: The feature no longer works on preloads, compared to the original
I2P. See explainer for details.)

Contact emailsxiaoche...@chromium.org

Explainer
https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d#file-proposal-v3-md

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

Summary

Allows putting 'blocking=render' as an attribute and value to a 

[blink-dev] Intent to Prototype: CSS Anchor Positioning

[Xiaocheng Hu]

Contact emailsikilpatr...@chromium.org, ko...@chromium.org,
xiaoche...@chromium.org

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

Specificationhttps://tabatkins.github.io/specs/css-anchor-position

Summary

Anchor positioning allows a positioned element to size and position itself
relative to one or more "anchor elements" elsewhere on the page, possibly
constrained by the container or viewport. A typical use case is to "pin" a
popup to the button that opens it.


Blink componentBlink>Layout


Motivation

When building interactive components or applications, authors frequently
want to leverage UI elements that can render in a "top-layer", and wish to
"pin" or "anchor" such top-layer UI to a point on another element, referred
to here as an "anchor element". How the top-layer UI is positioned with
respect to its anchor element is further influenced or constrained by the
edges of the container. CSS Anchor Positioning provides native support for
such use cases.


Initial public proposal
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md

Search tagscss , anchor
, position


TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



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?

No.


Debuggability

In addition to the standard CSS & Layout support, DevTools should be able
to show which fallback positioning an anchor-positioned element is using.


Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAFqEGhZguUu55CqSUTJ5gUpMG0%2B_yyMFMTFMs5tW%3D7dpquYdtA%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Thanks for all the comments! I'll do a revisit later.

On Wed, Mar 30, 2022 at 5:53 AM Philip Jägenstedt 
wrote:

> Hi Xiaocheng,
>
> Thanks for doing this analysis, I think it's the first time I've seen
> categorization done this thoroughly using BigQuery, and I'm impressed :)
>
> While one could also look at "e.path", I think what you have should be
> enough to get a good idea of the risk. Having identified a bunch of sites
> that might be broken, I think the next step is to take a random sample of
> them, say 10 sites. For each site, understand when that code path is
> reached in current Chrome, and then take a locally built version of Chrome
> with the API removed and reach that code path. What happens?
>
> It sounds a lot that we have ~2500 site in the "hard fail" category, but I
> would bet that on closer inspection you will find:
>
>- Code that you can't figure out how to even reach, which might be
>dead code
>- Code that throws errors but everything works fine from the user's
>point of view
>- Broken tracking or ads that the user could notice, but wouldn't
>really care about
>
> And then finally, you might find cases that really are broken, but which
> are already broken in Firefox and Safari. If that is most of the remaining
> cases, then we have to weigh breaking those sites in Chrome and likely
> pushing them to be fixed (in all browsers) soonish, vs. them remaining
> broken in some browsers for what is very likely a longer time. In this
> case, I would say LGTM to minimizing overall breakage, for users of all
> browsers, by breaking the sites in Chrome after a reasonable deprecation
> period.
>
> Best regards,
> Philip
>
> On Wed, Mar 9, 2022 at 4:04 PM Yoav Weiss  wrote:
>
>> Thanks for the analysis! :) I think it may make sense to do a bit of a deeper
>> dive
>> <https://docs.google.com/document/d/1JUeNc-ZxxWTn2tz9M_DJ4cV-M8lBdp40xlnfQ2-Mhgg/edit?disco=VgAWwQ8>
>> into HA data to get a tighter bound on usage before coming up with a date.
>>
>> On Thursday, March 3, 2022 at 9:23:50 PM UTC+1 Xiaocheng Hu wrote:
>>
>>> Hi blink-dev,
>>>
>>> I've done an analysis on HTTP Archive (https://bit.ly/3uHALsd), and
>>> found that at least 0.2% pages will break if Event.path is removed. The
>>> actual number should be higher (maybe 1%?) since the analysis is based on
>>> searching the regex r'(ev|event)\.path' in JavaScript code, so the analysis
>>> couldn't find a usage if the code has been aggressively minified with
>>> variables renamed.
>>>
>>> My current plan is that we'll target M109, the first release in 2023.
>>> Before its removal, we'll:
>>> - Use on a deprecation message in DevTools to decrease the usage
>>> - Do outreach if needed
>>> - Starting from September 2022, or if the known breakage number drops
>>> below a threshold (mabye 0.05%?), disable it on all non-Stable channels
>>> (via finch) to further speed up decreasing the usage.
>>>
>>> On Wed, Feb 9, 2022 at 9:59 AM Xiaocheng Hu 
>>> wrote:
>>>
>>>> I'm still working on HTTP Archive to see the actual usage patterns of
>>>> Event.path. I also suspect that many won't really break with Event.path
>>>> removed, since I'm not aware of any Apple bugs, either.
>>>>
>>>> I'll update this thread when I'm done.
>>>>
>>>> On Wed, Feb 9, 2022 at 9:28 AM Mike Taylor 
>>>> wrote:
>>>>
>>>>> Thanks for digging into this Philip! Agree that HTTPArchive analysis
>>>>> will be pretty helpful to help us make a decision.
>>>>>
>>>>> Thinking again about the lack of (many) Firefox and Safari bugs - that
>>>>> gives me some hope that it might be safe to remove from Chromium (assuming
>>>>> we don't find that sites are UA-sniffing to only use event.path for
>>>>> Chromium browsers).
>>>>>
>>>>> On 2/9/22 11:46 AM, Philip Jägenstedt wrote:
>>>>>
>>>>> Here's a first cut at httparchive analysis:
>>>>>
>>>>> SELECT page, url
>>>>> FROM `httparchive.latest.response_bodies_desktop`
>>>>> WHERE STRPOS(body, 'event.path') > 0
>>>>>   AND STRPOS(body, 'event.composedPath()') = 0;
>>>>>
>>>>> That finds over 32k cases. Categorizing these based on context and
>>>>> analyzing how each case would break would really help here.
>>>>>
>>>>> The very first case I l

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Hi blink-dev,

I've done an analysis on HTTP Archive (https://bit.ly/3uHALsd), and found
that at least 0.2% pages will break if Event.path is removed. The actual
number should be higher (maybe 1%?) since the analysis is based on
searching the regex r'(ev|event)\.path' in JavaScript code, so the analysis
couldn't find a usage if the code has been aggressively minified with
variables renamed.

My current plan is that we'll target M109, the first release in 2023.
Before its removal, we'll:
- Use on a deprecation message in DevTools to decrease the usage
- Do outreach if needed
- Starting from September 2022, or if the known breakage number drops below
a threshold (mabye 0.05%?), disable it on all non-Stable channels (via
finch) to further speed up decreasing the usage.

On Wed, Feb 9, 2022 at 9:59 AM Xiaocheng Hu  wrote:

> I'm still working on HTTP Archive to see the actual usage patterns of
> Event.path. I also suspect that many won't really break with Event.path
> removed, since I'm not aware of any Apple bugs, either.
>
> I'll update this thread when I'm done.
>
> On Wed, Feb 9, 2022 at 9:28 AM Mike Taylor  wrote:
>
>> Thanks for digging into this Philip! Agree that HTTPArchive analysis will
>> be pretty helpful to help us make a decision.
>>
>> Thinking again about the lack of (many) Firefox and Safari bugs - that
>> gives me some hope that it might be safe to remove from Chromium (assuming
>> we don't find that sites are UA-sniffing to only use event.path for
>> Chromium browsers).
>>
>> On 2/9/22 11:46 AM, Philip Jägenstedt wrote:
>>
>> Here's a first cut at httparchive analysis:
>>
>> SELECT page, url
>> FROM `httparchive.latest.response_bodies_desktop`
>> WHERE STRPOS(body, 'event.path') > 0
>>   AND STRPOS(body, 'event.composedPath()') = 0;
>>
>> That finds over 32k cases. Categorizing these based on context and
>> analyzing how each case would break would really help here.
>>
>> The very first case I looked at was like this:
>>
>> function getRealEventTarget(event, ELEMENT) {
>> var path = []
>> if (event.path) {
>> path = event.path
>> }
>> if (event.originalEvent && event.originalEvent.path) {
>> path = event.originalEvent.path
>> }
>> if (path && path.length > 0) {
>> if (ELEMENT && path.indexOf(ELEMENT) >= 0) {
>> return ELEMENT
>> } else {
>> return path[0]
>> }
>> }
>> return event.target
>> }
>>
>> At first glance this seems like a problem and that things could break,
>> but then we need to look at if it's already broken in Firefox and Safari.
>> It may well turn out that as actually used, it's harmless.
>>
>> Best regards,
>> Philip
>>
>> On Wed, Feb 9, 2022 at 5:37 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, February 9, 2022 at 2:49:55 AM UTC+1 Mike Taylor wrote:
>>>>
>>>>> Hey Xiaocheng,
>>>>>
>>>>> Thanks for working on improving interop! A few thoughts and questions
>>>>> below.
>>>>>
>>>>> On 2/8/22 7:25 PM, Xiaocheng Hu wrote:
>>>>>
>>>>> Contact emails xiaoche...@chromium.org
>>>>>
>>>>> Explainer None
>>>>>
>>>>> Specification None. Not a standard feature.
>>>>>
>>>>> Summary
>>>>>
>>>>> Event.path is a non-standard API that returns the event's path, which
>>>>> is an array of the objects on which listeners will be invoked. It is
>>>>> supported by Blink only, causing web compatibility issues. Web developers
>>>>> should switch to the equivalent standard API Event.composedPath(), which
>>>>> returns the same result.
>>>>>
>>>>>
>>>>> Blink component Blink>DOM
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>
>>>>>
>>>>> TAG review
>>>>>
>>>>> TAG review status Not applicable
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> The removal of this API should improve interoperability, as it's
>>>>> supported by Blink only. It still has 18% usage as of Feb 2022 (
>>>&g

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

I'm still working on HTTP Archive to see the actual usage patterns of
Event.path. I also suspect that many won't really break with Event.path
removed, since I'm not aware of any Apple bugs, either.

I'll update this thread when I'm done.

On Wed, Feb 9, 2022 at 9:28 AM Mike Taylor  wrote:

> Thanks for digging into this Philip! Agree that HTTPArchive analysis will
> be pretty helpful to help us make a decision.
>
> Thinking again about the lack of (many) Firefox and Safari bugs - that
> gives me some hope that it might be safe to remove from Chromium (assuming
> we don't find that sites are UA-sniffing to only use event.path for
> Chromium browsers).
>
> On 2/9/22 11:46 AM, Philip Jägenstedt wrote:
>
> Here's a first cut at httparchive analysis:
>
> SELECT page, url
> FROM `httparchive.latest.response_bodies_desktop`
> WHERE STRPOS(body, 'event.path') > 0
>   AND STRPOS(body, 'event.composedPath()') = 0;
>
> That finds over 32k cases. Categorizing these based on context and
> analyzing how each case would break would really help here.
>
> The very first case I looked at was like this:
>
> function getRealEventTarget(event, ELEMENT) {
> var path = []
> if (event.path) {
> path = event.path
> }
> if (event.originalEvent && event.originalEvent.path) {
> path = event.originalEvent.path
> }
> if (path && path.length > 0) {
> if (ELEMENT && path.indexOf(ELEMENT) >= 0) {
> return ELEMENT
> } else {
> return path[0]
> }
> }
> return event.target
> }
>
> At first glance this seems like a problem and that things could break, but
> then we need to look at if it's already broken in Firefox and Safari. It
> may well turn out that as actually used, it's harmless.
>
> Best regards,
> Philip
>
> On Wed, Feb 9, 2022 at 5:37 PM Philip Jägenstedt 
> wrote:
>
>> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, February 9, 2022 at 2:49:55 AM UTC+1 Mike Taylor wrote:
>>>
>>>> Hey Xiaocheng,
>>>>
>>>> Thanks for working on improving interop! A few thoughts and questions
>>>> below.
>>>>
>>>> On 2/8/22 7:25 PM, Xiaocheng Hu wrote:
>>>>
>>>> Contact emails xiaoche...@chromium.org
>>>>
>>>> Explainer None
>>>>
>>>> Specification None. Not a standard feature.
>>>>
>>>> Summary
>>>>
>>>> Event.path is a non-standard API that returns the event's path, which
>>>> is an array of the objects on which listeners will be invoked. It is
>>>> supported by Blink only, causing web compatibility issues. Web developers
>>>> should switch to the equivalent standard API Event.composedPath(), which
>>>> returns the same result.
>>>>
>>>>
>>>> Blink component Blink>DOM
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>
>>>>
>>>> TAG review
>>>>
>>>> TAG review status Not applicable
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> The removal of this API should improve interoperability, as it's
>>>> supported by Blink only. It still has 18% usage as of Feb 2022 (
>>>> https://chromestatus.com/metrics/feature/timeline/popularity/345), so
>>>> we will only deprecate it for now, and will not remove it before the usage
>>>> drops low enough. We expect low compatibility risks, since there is an
>>>> equivalent standard API (Event.composedPath()) by all browsers, and the
>>>> following polyfill should also keep existing sites functioning with minimum
>>>> changes:
>>>>
>>>> 18% is a _lot_ of usage. So much that I'm surprised there aren't dozens
>>>> of compat bugs reported against Firefox. In
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1697590#c0 there are only
>>>> 2 linked site bugs. And there's only 3 in
>>>> https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+composedPath
>>>> (the last one being from 2019).
>>>>
>>>> I wonder how much of that 18% is feature detection and fallback
>>>> codepaths
>>>> <https://github.com/search?l=JavaScript=composedPath+event.path=Code>
>>>> .
>>>>
>>>
>>> Yeah, that 18% is unreasonably high...
>>> I 

[blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Contact emailsxiaoche...@chromium.org

ExplainerNone

SpecificationNone. Not a standard feature.

Summary

Event.path is a non-standard API that returns the event's path, which is an
array of the objects on which listeners will be invoked. It is supported by
Blink only, causing web compatibility issues. Web developers should switch
to the equivalent standard API Event.composedPath(), which returns the same
result.


Blink componentBlink>DOM


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The removal of this API should improve interoperability, as it's supported
by Blink only. It still has 18% usage as of Feb 2022 (
https://chromestatus.com/metrics/feature/timeline/popularity/345), so we
will only deprecate it for now, and will not remove it before the usage
drops low enough. We expect low compatibility risks, since there is an
equivalent standard API (Event.composedPath()) by all browsers, and the
following polyfill should also keep existing sites functioning with minimum
changes: if (!Event.prototype.path) {
Object.defineProperty(Event.prototype, 'path', { get() { return
this.composedPath(); } }); }


Gecko: No signal Firefox does not support Event.path

WebKit: No signal Safari does not support Event.path

Web developers: Positive (
https://github.com/web-platform-tests/interop-2022/issues/26)

Other signals:


Debuggability

Usage of this deprecated feature will be reported to the DevTools Issues
Tab.


Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAFqEGha_iNax9r8%2BXVQK%2Bf3hEdu5z-MDAh44FbKMOuAnrHL2Ew%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

Thanks to everyone for reviewing!

The feature has been enabled by default in M99:
https://chromium-review.googlesource.com/c/chromium/src/+/3335171

On Mon, Dec 13, 2021 at 9:55 AM Mike Taylor  wrote:

> LGTM3 - I'm excited for this addition to CSS.
>
> On 12/13/21 12:45 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Sun, Dec 12, 2021 at 10:47 PM Yoav Weiss 
> wrote:
>
>> *LGTM1*
>>
>> Thanks for fixing the related CSSPreloadScanner issues! :)
>>
>> On Sat, Dec 11, 2021 at 5:58 AM Xiaocheng Hu 
>> wrote:
>>
>>> It's flipped to "experimental" in 99.0.4759.0. We should see all the
>>> tests (except crbug.com/1277637) turn green soon.
>>>
>>> It also appears that the test failures are properly tracked at Gecko and
>>> WebKit, detailed as below:
>>>
>>> For Gecko, the failures are already tracked by:
>>> - CSSOM API-related:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1745233
>>> - 'revert-layer' keyword:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1699220
>>> - Remaing failures already have tracking bugs as shown by wpt.fyi
>>>
>>> For WebKit, their failing tests are:
>>> - Those testing interactions with certain at-rules (@counter-style,
>>> @property, @scroll-timeline) that they don't support yet.
>>> - CSSOM API-related, which they fixed recently (
>>> https://trac.webkit.org/changeset/286657/webkit). Should turn green in
>>> wpt.fyi soon
>>> - The remaining failures are already tracked by
>>> https://bugs.webkit.org/show_bug.cgi?id=233937,
>>> https://bugs.webkit.org/show_bug.cgi?id=233944 and
>>> https://bugs.webkit.org/show_bug.cgi?id=234158
>>>
>>>
>>> On Thu, Dec 9, 2021 at 2:59 PM Manuel Rego Casasnovas 
>>> wrote:
>>>
>>>>
>>>>
>>>> On 08/12/2021 18:48, Xiaocheng Hu wrote:
>>>> > They are failing on wpt.fyi because the feature is not enabled there.
>>>> > The feature is not behind the "experimental web platform features"
>>>> flag.
>>>>
>>>> Isn't a bit strange to move a runtime feature from "test" to "stable",
>>>> without having been in "experimental" for a while?
>>>> Maybe it'd be nice to maybe mark it as "experimental" and see lots of
>>>> green tests in wpt.fyi.
>>>>
>>>> It looks interoperability is not great yet, as Firefox and Safari fail a
>>>> bunch of tests here and there. It would be nice if we could fill bugs
>>>> (if they haven't been filled yet) for some of the biggest interop issues
>>>> we think web authors will find.
>>>>
>>>> Cheers,
>>>>   Rego
>>>>
>>> --
>>> 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/CAFqEGhZ%2BbXqgPQsSOc%2B4vEhTm1Rck%2BZ5CQ8n2nJXzeKUOKsTxA%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhZ%2BbXqgPQsSOc%2B4vEhTm1Rck%2BZ5CQ8n2nJXzeKUOKsTxA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CAL5BFfUrsF%2Bvs2VZwtLXcJaZZQ8F8ek%3DJZ5k3srv_U5CF9q05w%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUrsF%2Bvs2VZwtLXcJaZZQ8F8ek%3DJZ5k3srv_U5CF9q05w%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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%2Bw-nwOMNLQsCVOeNUO1tSC_pYHAJkZDtGsBZVFCLO9gUKg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-nwOMNLQsCVOeNUO1tSC_pYHAJkZDtGsBZVFCLO9gUKg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
>

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

Re: [blink-dev] Re: Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

It's flipped to "experimental" in 99.0.4759.0. We should see all the tests
(except crbug.com/1277637) turn green soon.

It also appears that the test failures are properly tracked at Gecko and
WebKit, detailed as below:

For Gecko, the failures are already tracked by:
- CSSOM API-related: https://bugzilla.mozilla.org/show_bug.cgi?id=1745233
- 'revert-layer' keyword:
https://bugzilla.mozilla.org/show_bug.cgi?id=1699220
- Remaing failures already have tracking bugs as shown by wpt.fyi

For WebKit, their failing tests are:
- Those testing interactions with certain at-rules (@counter-style,
@property, @scroll-timeline) that they don't support yet.
- CSSOM API-related, which they fixed recently (
https://trac.webkit.org/changeset/286657/webkit). Should turn green in
wpt.fyi soon
- The remaining failures are already tracked by
https://bugs.webkit.org/show_bug.cgi?id=233937,
https://bugs.webkit.org/show_bug.cgi?id=233944 and
https://bugs.webkit.org/show_bug.cgi?id=234158


On Thu, Dec 9, 2021 at 2:59 PM Manuel Rego Casasnovas 
wrote:

>
>
> On 08/12/2021 18:48, Xiaocheng Hu wrote:
> > They are failing on wpt.fyi because the feature is not enabled there.
> > The feature is not behind the "experimental web platform features" flag.
>
> Isn't a bit strange to move a runtime feature from "test" to "stable",
> without having been in "experimental" for a while?
> Maybe it'd be nice to maybe mark it as "experimental" and see lots of
> green tests in wpt.fyi.
>
> It looks interoperability is not great yet, as Firefox and Safari fail a
> bunch of tests here and there. It would be nice if we could fill bugs
> (if they haven't been filled yet) for some of the biggest interop issues
> we think web authors will find.
>
> Cheers,
>   Rego
>

-- 
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/CAFqEGhZ%2BbXqgPQsSOc%2B4vEhTm1Rck%2BZ5CQ8n2nJXzeKUOKsTxA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

Updates:
- Ensured that preload scanner picks up layered @import rules in 

Re: [blink-dev] Re: Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

The relevant tests are css/css-cascade/layer-*.html and
css/css-cascade/revert-layer-*.html

They are failing on wpt.fyi because the feature is not enabled there. The
feature is not behind the "experimental web platform features" flag.

All tests (except https://crbug.com/1277637) are currently passing on CQ
(for example,
https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/873658/).

On Wed, Dec 8, 2021 at 8:44 AM Philip Jägenstedt 
wrote:

> Hi Xiaocheng,
>
> Can you identify the tests in
> https://wpt.fyi/results/css/css-cascade?label=master=experimental=chrome=firefox=safari
> that are for cascade layers? I think revert-layer-*.html are relevant to
> this intent, but is failing in Chrome Dev. Is this because it was fixed so
> recently? Do you expect all of the tests to be passing in Chrome Dev once
> it's updated?
>
> Best regards,
> Philip
>
> On Tue, Dec 7, 2021 at 11:53 PM Xiaocheng Hu 
> wrote:
>
>>
>>
>> On Tue, Dec 7, 2021 at 2:33 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Tuesday, December 7, 2021 at 9:49:42 PM UTC+1 Xiaocheng Hu wrote:
>>>
>>>> Also some updates since the I2P:
>>>>
>>>> 1. The 'revert-layer' keyword is now supported
>>>>
>>>> 2. Regarding concerns of loading performance when importing external
>>>> stylesheets into a layer, it's recommended to inline the @import rule in a
>>>> 

[blink-dev] Re: Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

On Tue, Dec 7, 2021 at 2:33 PM Yoav Weiss  wrote:

>
>
> On Tuesday, December 7, 2021 at 9:49:42 PM UTC+1 Xiaocheng Hu wrote:
>
>> Also some updates since the I2P:
>>
>> 1. The 'revert-layer' keyword is now supported
>>
>> 2. Regarding concerns of loading performance when importing external
>> stylesheets into a layer, it's recommended to inline the @import rule in a
>> 

[blink-dev] Re: Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

Also some updates since the I2P:

1. The 'revert-layer' keyword is now supported

2. Regarding concerns of loading performance when importing external
stylesheets into a layer, it's recommended to inline the @import rule in a

[blink-dev] Intent to Ship: CSS cascade layers

[Xiaocheng Hu]

Contact emailsxiaoche...@chromium.org

Explainerhttps://gist.github.com/xiaochengh/58c793e3bf06a1bb0f7d472ebb170feb

Specificationhttps://drafts.csswg.org/css-cascade-5/#layering

Design docs
https://bit.ly/2SGjPlu

Summary

CSS cascade layers (@layer rule and layered @import syntax) provide a
structured way to organize and balance concerns within a single origin.
Rules within a single cascade layer cascade together without interleaving
with style rules outside the layer. This allows authors to achieve a
certain cascade ordering for same-origin rules in a proper way.


Blink componentBlink>CSS


Search tagscss , cascade
, layer
, cascade-layer


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

As a new feature, there is no compatibility risk. Interoperability risk is
very low as WebKit and Gecko are also actively developing this new feature.


Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1699215)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=220779)

Web developers: Strongly positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=1095765)

Other signals:


Debuggability

@layer rules will be surfaced to DevTools in the Style panel to indicate
which layer the style rules are in. See crbug.com/1240596


Is this feature fully tested by web-platform-tests

?Yes

Flag namechrome://flags/#enable-cascade-layers

Requires code in //chrome?False

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

Estimated milestones

99


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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/chiJ2GIECPc/m/sIF9pfsdAAAJ


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/CAFqEGha5qBJvcSa%2Bzs525XU8HBdpHhH1W3%3D9x%3DNrHnaSP6XTvg%40mail.gmail.com.

[blink-dev] Intent to Prototype: 'blocking=rendering' attribute on scripts and link resources

[Xiaocheng Hu]

Contact emails
xiaoche...@chromium.org

Explainer
https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd#explainer

Specification
https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd

Summary

This feature allows putting 'blocking=render' as an attribute and value to
a 

Re: [blink-dev] Re: Intent to Ship: CSS @counter-style descriptor 'speak-as'

[Xiaocheng Hu]

Hi everyone,

I'm withdrawing this intent.

With a discussion with the accessibility team, we found this approach
(based on alternative text) problematic.

We'll try a different approach via CSS AAM
<https://w3c.github.io/css-aam/>. This
will allow us to pass the original marker text + accessibility attributes
(to be specified) to the platform AT and let them decide how to interpret
it.

On Thu, Sep 30, 2021 at 1:36 AM Yoav Weiss  wrote:

> Hey Xiaocheng! Should we consider this intent on hold until Tab's points
> are addressed?
>
> On Friday, September 17, 2021 at 11:57:28 PM UTC+2 Xiaocheng Hu wrote:
>
>> On Fri, Sep 17, 2021 at 2:31 PM Tab Atkins Jr. 
>> wrote:
>>
>>> On Fri, Sep 17, 2021 at 1:36 PM Mike Taylor 
>>> wrote:
>>> > On Friday, September 17, 2021 at 4:16:26 PM UTC-4 Xiaocheng Hu wrote:
>>> >> Update since I2P: The 'spell-out' value is not implemented because it
>>> is currently unimplementable (crbug.com/1247764). As the spec requires
>>> alphabetic counter styles with 'speak-as: auto' to use the 'spell-out'
>>> value, we use 'words' instead. This aligns with what Firefox currently does.
>>> >
>>> > With 2 engines shipping (as soon as this ships, anyways) speak-as:
>>> auto => speak-as: words, have you passed that feedback to the spec editors,
>>> as the de-facto interoperable (and implementable) behavior?
>>>
>>> This feedback was provided in
>>> <https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-799868468
>>> >,
>>> but I answered it in
>>> <https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-840874164>
>>> with what should be an acceptable interim solution. There wasn't a
>>> further reply from Xiaocheng, so I figured my suggestion was
>>> acceptable; I guess that wasn't the case?
>>>
>>
>> I somehow missed that... Let me discuss with our accessibility team to
>> see how it works.
>>
>>
>>> "words" will give a *broken* behavior to alphabetic lists; it would
>>> mean that the 27th list item in an alphabetic list (with counter "aa")
>>> would be pronounced as a single long a sound (as you can hear in
>>> `speechSynthesis.speak(new SpeechSynthesisUtterance("aa"))`; the 28th
>>> would be the word "ab", etc. I don't think this is acceptable for
>>> screen-reader users. The interim solution I gave would read them out
>>> correctly, as you can hear in `speechSynthesis.speak(new
>>> SpeechSynthesisUtterance("a a"))`.
>>>
>>> ~TJ
>>>
>>

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

Re: [blink-dev] Re: Intent to Ship: CSS @counter-style descriptor 'speak-as'

[Xiaocheng Hu]

On Fri, Sep 17, 2021 at 2:31 PM Tab Atkins Jr.  wrote:

> On Fri, Sep 17, 2021 at 1:36 PM Mike Taylor 
> wrote:
> > On Friday, September 17, 2021 at 4:16:26 PM UTC-4 Xiaocheng Hu wrote:
> >> Update since I2P: The 'spell-out' value is not implemented because it
> is currently unimplementable (crbug.com/1247764). As the spec requires
> alphabetic counter styles with 'speak-as: auto' to use the 'spell-out'
> value, we use 'words' instead. This aligns with what Firefox currently does.
> >
> > With 2 engines shipping (as soon as this ships, anyways) speak-as: auto
> => speak-as: words, have you passed that feedback to the spec editors, as
> the de-facto interoperable (and implementable) behavior?
>
> This feedback was provided in
> <https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-799868468>,
> but I answered it in
> <https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-840874164>
> with what should be an acceptable interim solution. There wasn't a
> further reply from Xiaocheng, so I figured my suggestion was
> acceptable; I guess that wasn't the case?
>

I somehow missed that... Let me discuss with our accessibility team to see
how it works.


> "words" will give a *broken* behavior to alphabetic lists; it would
> mean that the 27th list item in an alphabetic list (with counter "aa")
> would be pronounced as a single long a sound (as you can hear in
> `speechSynthesis.speak(new SpeechSynthesisUtterance("aa"))`; the 28th
> would be the word "ab", etc. I don't think this is acceptable for
> screen-reader users. The interim solution I gave would read them out
> correctly, as you can hear in `speechSynthesis.speak(new
> SpeechSynthesisUtterance("a a"))`.
>
> ~TJ
>

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

[blink-dev] Intent to Ship: CSS @counter-style descriptor 'speak-as'

[Xiaocheng Hu]

(Though the I2P thread

already has 3 LGTMs, there are some updates. Hence requesting another
review)
Contact emailsxiaoche...@chromium.org

Explainerhttps://drafts.csswg.org/css-counter-styles/#example-cce4b0db

Specification
https://www.w3.org/TR/css-counter-styles-3/#counter-style-speak-as

Design docs
https://bit.ly/3kEHluz

Summary

A custom counter style can be constructed with a meaning that is obvious
visually, but impossible to meaningfully represent via a speech synthesizer
or other non-visual means, or possible but nonsensical when naively read
out loud. The 'speak-as' descriptor describes how to synthesize the spoken
form of a counter formatted with the given counter style.


*Update since I2P:* The 'spell-out' value is not implemented because it is
currently unimplementable (crbug.com/1247764). As the spec requires
alphabetic counter styles with 'speak-as: auto' to use the 'spell-out'
value, we use 'words' instead. This aligns with what Firefox currently does.

Blink componentBlink>CSS


Search tagscss , counter
, counter-style
, speak
, speak-as


TAG reviewN/A; Firefox already shipped it years ago.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Interoperability risks are very low, as we are implementing a CR feature
that Firefox already shipped years ago, and Safari is positive on. *Update
since I2P:* There is a low compatibility risk. Accessible names of a lot of
predefined counter styles are changed from the counter text to the counter
number. For example, if we have a list marker "IV. " using 'upper-roman'
counter style, its accessible name is changed from "IV. " to "4. ". This
change matches the spec and aligns with Firefox, but may shave backward
compatibility risks.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=966166)
Firefox didn't implement the 'spell-out' value, and uses the 'words' value
instead.

WebKit: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2021-February/031719.html)
Safari is positive on the @counter-style rule as a whole, including this
descriptor.

Web developers: Strongly positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=687225) Developers
are positive on the @counter-style rule as a whole, including this
descriptor.


Debuggability

N/A; it's an extension to an already shipped feature, @counter-style. Note
that we don't have DevTools support for @counter-style yet, as the
requirement was imposed after @counter-style was shipped.


Is this feature fully tested by web-platform-tests

?Yes

Flag name--enable-blink-features=CSSAtRuleCounterStyleSpeakAsDescriptor

Requires code in //chrome?False

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

Estimated milestones

96


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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9e9q5WAepGk/m/uw_XP5zuFAAJ


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/CAFqEGhaNDEdFEVu-Bop%2B0W5eaMZNM%2BT8dqADwUEQ_2iD_R0gTQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS @counter-style rules in shadow trees

[Xiaocheng Hu]

 Thanks for reviewing! Enabled
<https://chromium-review.googlesource.com/c/chromium/src/+/3123731> in M95.

On Thu, Aug 26, 2021 at 5:51 AM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2021-08-26 08:57, Yoav Weiss wrote:
>
> LGTM2
>
> On Wed, Aug 25, 2021 at 11:30 PM Chris Harrelson 
> wrote:
>
>> LGTM1
>>
>> On Wed, Aug 25, 2021 at 2:14 PM Xiaocheng Hu 
>> wrote:
>>
>>> Here's an update that the TAG review has finished.
>>>
>>> Is there a chance that we can meet the feature freeze deadline tomorrow
>>> and ship it with M95?
>>>
>>> On Sat, Jul 31, 2021 at 1:00 PM Yoav Weiss 
>>> wrote:
>>>
>>>> Overall, aligning browsers on a single behavior for at rule inheritance
>>>> seems like the right direction.
>>>> I think it makes sense to let the TAG review run its course, as well as
>>>> give positions from other vendors a bit more time.
>>>>
>>>> On Fri, Jul 23, 2021 at 2:32 AM Xiaocheng Hu 
>>>> wrote:
>>>>
>>>>> Contact emails xiaoche...@chromium.org
>>>>>
>>>>> Explainer https://drafts.csswg.org/css-scoping/#example-f1503361
>>>>> https://drafts.csswg.org/css-scoping/#example-ee72cb37
>>>>> (While the examples use @font-face, @counter-style works in the same
>>>>> way)
>>>>> <https://chromestatus.com/admin/features/launch/5716198446596096/(While%20the%20examples%20use%20@font-face,%20@counter-style%20works%20in%20the%20same%20way)>
>>>>>
>>>>> Specification https://drafts.csswg.org/css-scoping/#shadow-names
>>>>>
>>>>> Design docs
>>>>> https://bit.ly/2Gm1oMC
>>>>>
>>>>> Summary
>>>>>
>>>>> Allows custom counter styles (@counter-style rules) to be defined with
>>>>> shadow trees, and properly referenced within shadow trees or across shadow
>>>>> boundaries.
>>>>>
>>>>>
>>>>> Blink component Blink>CSS
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>
>>>>> Search tags css <https://chromestatus.com/features#tags:css>, counter
>>>>> <https://chromestatus.com/features#tags:counter>, counter-style
>>>>> <https://chromestatus.com/features#tags:counter-style>, shadow
>>>>> <https://chromestatus.com/features#tags:shadow>
>>>>>
>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/659
>>>>>
>>>>> TAG review status Pending
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> Low. Currently, browsers already have non-interoperable behaviors on
>>>>> how to handle name-defining at-rules in shadow DOM. This change should
>>>>> improve interoperability if other browsers agree to implement the spec.
>>>>>
>>>>>
>>>>> Gecko: No signal (
>>>>> https://github.com/mozilla/standards-positions/issues/556)
>>>>>
>>>>> WebKit: No signal (
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-July/031926.html)
>>>>>
>>>>> Web developers: Strongly positive (
>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=336876) While
>>>>> the crbug is only for @font-face, we are aiming at consistent handling of
>>>>> all the name-defining at-rules, including @counter-style.
>>>>>
>>>>>
>>>>> Debuggability
>>>>>
>>>>> N/A; it's an extension to an already shipped feature, @counter-style.
>>>>> Note that we don't have DevTools support for @counter-style yet, as the
>>>>> requirement was imposed after @counter-style was shipped.
>>>>>
>>>>>
>>>>> Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>> ? Yes
>>>>>
>>>>> Flag name --enable-blink-features=CSSAtRuleCounterStyleInShadowDOM
>>>>>
>>>>> Requires code in //chrome? No
>>>>>
>>>>> Tracking bug
>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1225033
&

Re: [blink-dev] Intent to Ship: CSS @counter-style rules in shadow trees

[Xiaocheng Hu]

Here's an update that the TAG review has finished.

Is there a chance that we can meet the feature freeze deadline tomorrow and
ship it with M95?

On Sat, Jul 31, 2021 at 1:00 PM Yoav Weiss  wrote:

> Overall, aligning browsers on a single behavior for at rule inheritance
> seems like the right direction.
> I think it makes sense to let the TAG review run its course, as well as
> give positions from other vendors a bit more time.
>
> On Fri, Jul 23, 2021 at 2:32 AM Xiaocheng Hu 
> wrote:
>
>> Contact emailsxiaoche...@chromium.org
>>
>> Explainerhttps://drafts.csswg.org/css-scoping/#example-f1503361
>> https://drafts.csswg.org/css-scoping/#example-ee72cb37
>> (While the examples use @font-face, @counter-style works in the same way)
>> <https://chromestatus.com/admin/features/launch/5716198446596096/(While%20the%20examples%20use%20@font-face,%20@counter-style%20works%20in%20the%20same%20way)>
>>
>> Specificationhttps://drafts.csswg.org/css-scoping/#shadow-names
>>
>> Design docs
>> https://bit.ly/2Gm1oMC
>>
>> Summary
>>
>> Allows custom counter styles (@counter-style rules) to be defined with
>> shadow trees, and properly referenced within shadow trees or across shadow
>> boundaries.
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> Search tagscss <https://chromestatus.com/features#tags:css>, counter
>> <https://chromestatus.com/features#tags:counter>, counter-style
>> <https://chromestatus.com/features#tags:counter-style>, shadow
>> <https://chromestatus.com/features#tags:shadow>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/659
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low. Currently, browsers already have non-interoperable behaviors on how
>> to handle name-defining at-rules in shadow DOM. This change should improve
>> interoperability if other browsers agree to implement the spec.
>>
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/556)
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-July/031926.html)
>>
>> Web developers: Strongly positive (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=336876) While the
>> crbug is only for @font-face, we are aiming at consistent handling of all
>> the name-defining at-rules, including @counter-style.
>>
>>
>> Debuggability
>>
>> N/A; it's an extension to an already shipped feature, @counter-style.
>> Note that we don't have DevTools support for @counter-style yet, as the
>> requirement was imposed after @counter-style was shipped.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Flag name--enable-blink-features=CSSAtRuleCounterStyleInShadowDOM
>>
>> Requires code in //chrome?No
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1225033
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5716198446596096
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vSPTU15iL9Y/m/jNYWijNmAgAJ
>>
>>
>> This intent message was generated by Chrome Platform Status
>> <https://www.chromestatus.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/CAFqEGhbX3YhbNHMd4DBaf%3DsK5pk9H88O5zf%2BR4fv6KJsrLdxMQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhbX3YhbNHMd4DBaf%3DsK5pk9H88O5zf%2BR4fv6KJsrLdxMQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAFqEGha5GaYxbhcwrhAfCp1n2-BX3UEVOqVYAJ5Nv8MpbBSExA%40mail.gmail.com.