Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

The track and stream removal experiment is at 50% Stable for M109. On
January 23rd it went from 10% to 50%. The intent is to ramp up to 100%.
Which experiment group you end up with (have or not have the deprecated
stats) are chosen with a dice roll every time the user restarts their
browser.

In M111 (which is currently Canary) the removal is enabled-by-default so in
that version there is no dependency on getting finch configs pushed anymore.

On Thu, Jan 26, 2023 at 12:52 AM Sudheer Boynapally 
wrote:

> Was there any change on January 23rd corresponding to this? like rolling
> out this deprecation?
>
> Thanks,
> On Wednesday, January 25, 2023 at 2:57:16 PM UTC-8 Sudheer Boynapally
> wrote:
>
>> Hi,
>>
>> Is the deprecation of 'track' and 'stream' objects completed 100% on all
>> the versions of chrome v109 or any specific sub version of 109?
>>
>> Thanks,
>>
>>
>> On Tuesday, January 10, 2023 at 5:56:04 AM UTC-8 Henrik Boström wrote:
>>
>>> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:
>>>
 +Henrik Boström - was there an intent sent for this removal? Any form
 of developer communication?

>>>
>>> There was developer communication dating as far back as July but I admit
>>> I had forgotten to send out a formal blink-dev intent to deprecate!
>>>
>>> - I should have done that.
>>>
>>> The getStats() API in question is not being deprecated, but the
>>> RTCStatsReport (an id-to-stats-object map) report will stop containing the
>>> stats object which were made obsolete in the spec several years ago due to
>>> the contents of these stats objects having been moved to other stats
>>> objects that are still being returned. Same values, different location. In
>>> other words, the report is being trimmed down by removing duplicate
>>> information. Stats processing code in an application is gated on stats type
>>> for knowing which metrics to look for on an individual stats object which
>>> should make this lower risk compared to other depracations. The motivation
>>> for this is performance optimizations (~40% report size reduction),
>>> technical debt reduction (-1400 LOC) and web compat ("track" does not
>>> exist in Firefox ).
>>>
>>> The communication channel used was WebRTC's official google group,
>>> discuss-webrtc . History:
>>>
>>>- July 25, 2022 PSA
>>> announced
>>>the plan to deprecate at a milestone TBD. This was also the time where 
>>> the
>>>"DEPRECATED_" prefix was added to the JavaScript-exposed stats object 
>>> IDs,
>>>which made it into M106. The deprecation prefix is also visible in the
>>>chrome://webrtc-internals/ developer page when a page uses WebRTC.
>>>- There was another PSA on September 6, 2022
>>> about
>>>other stats news with a reminder of the imminent stats deprecation.
>>>- The October 19, 2022 PSA
>>> announced
>>>"track" stats being removed at 50% Canary.
>>>- The follow-up October 27, 2022 PSA
>>> announced
>>>it would also be removed at 50% Beta (where M109 Beta was released on
>>>December 1st). This PSA also clarifies that "The goal is to continue
>>>ramping it up on Stable when M109 is released".
>>>- Lastly we have yesterday's PSA
>>> announcing
>>>that the removal was advanced to 1% Stable which this conversation is a
>>>response to.
>>>
>>>
 On Mon, Jan 9, 2023 at 9:42 PM Alex Russell 
 wrote:

> Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this
> seems related to a pattern of breaking changes without Blink intents that
> we've been informed of by customers.
>
> Do I understand correctly that this deprecation is being managed via
> Finch for 109 Stable?
>

>>> Yes, as to minimize risk of breakage the deprecation is managed via a
>>> Finch flag, which is currently 1% Stable + 50% Canary/Beta.
>>> To my knowledge, no issues have been reported since the rollout started
>>> in Canary in November, 2022 or "DEPRECATED_" prefix was added in July, 2022.
>>> This, combined with the fact that apps usually gate on type, is why I
>>> thought it would be safe to gently roll out further to Stable.
>>>
>>>

> Best,
>
> Alex
>
>
>>> On Tue, Jan 10, 2023 at 12:34 AM 'Aaron Boushley' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Can you help me understand exactly which objects are being removed
 here? We rely on `RTCPeerConnection.getStats()` although we pass in a
 stream selector. We then iterate over the returned stats reports looking
 for ones containing the values we need.

>>>
>>> The selector (be it an 

Re: [blink-dev] Intent to Ship: CSS Nesting

[Yoav Weiss]

LGTM4, with the same criteria!

On Wed, Jan 25, 2023 at 8:23 PM Mike Taylor  wrote:

> LGTM3 with same conditions outlined by Rick and Philip.
>
> On 1/25/23 12:30 PM, Rick Byers wrote:
>
> We discussed this in the API owner meeting today (Philip, Rego, Daniel,
> Chris, Yoav, Mike Taylor and myself). We appreciate that there's not yet
> full consensus on the API syntax, but also that we've been in this state
> for several months and we've heard pretty clearly from web developers that
> as a whole they want us to ship something and overwhelmingly support
> option 3
> .
> It seems to me we're in real danger of a priority of constituencies
> 
> inversion here with authors continuing to lose out as a result of
> indecision from the implementer and standards community.
>
> Therefore, since option 3 seems to have the bulk of support from web
> developers and browser implementers, I agree with Philip that, absent any
> stronger consensus emerging, we should proceed with shipping it for M112
> (not M111 which is branching this week). *LGTM2* (with the same criteria
> as Philip).
>
> However, if the CSSWG resolves to materially change the design or the TAG
> completes their review
>  and requests
> specific breaking changes prior to Chrome 112 going to Beta around *March
> 1st*, then I'd retract my LGTM and ask us to flag it back off and circle
> back here to allow for a new attempt at building more consensus. As always,
> some breaking changes may be possible after that point too, but it'll
> depend on the realities of web compat.
>
> API owners also agreed that we'd look for 4 LGTMs in this case instead of
> the usual 3.
>
> Thanks,
>   Rick
>
> On Wed, Jan 25, 2023 at 11:24 AM Philip Jägenstedt 
> wrote:
>
>> LGTM1
>>
>> I had a chat with Steinar today to answer my questions. Out of the open
>> issues, the important ones to resolve before shipping are:
>> https://github.com/w3c/csswg-drafts/issues/7850
>> https://github.com/w3c/csswg-drafts/issues/7971
>> https://github.com/w3c/csswg-drafts/issues/7972
>>
>> Those don't seem controversial. My LGTM is assuming spec and tests are
>> updated and that we pass those tests before the feature reaches stable.
>>
>> The final test failure is related to #7850 and is an easy fix.
>>
>> Regarding the syntax, there's still disagreement in the CSSWG.
>> Unanimous consensus among all WG members doesn't seem possible here, for
>> any proposal. Crucially, other browser vendors appear to be OK with "option
>> 3". I would definitely reconsider my LGTM if there were signs that other
>> browser vendors are not keen on shipping option 3, since that would create
>> an interop problem, and eventually site compat problems as well.
>>
>> As always, we should be receptive to new information even after an intent
>> has been approved and the flag has been flipped.
>>
>> On Wed, Jan 25, 2023 at 11:20 AM Manuel Rego Casasnovas 
>> wrote:
>>
>>> Adding to Philip questions, there seems to be quite a lot of ongoing
>>> discussions around this topic on the CSSWG, for example today there's a
>>> special meeting only for CSS Nesting topics:
>>> https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html
>>>
>>> What's their impact on the current implementation?
>>>
>>> Thanks,
>>>   Rego
>>>
>>> On 23/01/2023 18:00, Philip Jägenstedt wrote:
>>> > I think that we should ship this. It's a high profile and in-demand new
>>> > feature
>>> > ,
>>> so
>>> > I have a few questions and comments first.
>>> >
>>> > Taking a look at the open spec issues
>>> > (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
>>> > ) some are
>>> > explicitly ideas for future changes, but are there any where shipping
>>> > amounts to a decision that isn't easily changed? I'm thinking
>>> especially
>>> > of the CSSOM issues.
>>> >
>>> > In https://wpt.fyi/results/css/css-nesting
>>> >  there's a single subtest
>>> > failure, related to how a rule serializes. Is that implemented per
>>> spec,
>>> > or is it tied up with the open CSSOM issues?
>>> >
>>> > Regarding the threat of a formal objection, there doesn't appear to be
>>> > any solution that would fully satisfy everyone, but I trust your
>>> > judgment that this is the best option. Additionally, we should not
>>> > pre-commit Blink to shipping parser changes, and accept the possibility
>>> > that what we ship now is the final shape of the feature.
>>> >
>>> > On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev
>>> > mailto:blink-dev@chromium.org>> wrote:
>>> >
>>> > Contact emails: se...@chromium.org ,
>>> > futh...@chromium.org 

Re: [blink-dev] Chrome://resources

[Giovanni Ortuño]

A bit more detail would be helpful here.

What mojom files are you trying to use? Where are you trying to use those
files? In another chrome:// URL or from a regular website?

Gio

On Wed, Jan 25, 2023 at 9:24 PM jeffplays  wrote:

> How would we use blink mojom files on a chrome://resources URL?
>
> --
> 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/CAONRv5%3Do%3DAYpv6eOrnVFD5vUDJKqUVbCwEw8SBJ-0QPjHrESeA%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/CAMDKGBXLaE5iCKnWLhz1BN9TgsMduxGV9_qPkYjrwdV51x4cpg%40mail.gmail.com.

[blink-dev] Chrome://resources

[jeffplays]

How would we use blink mojom files on a chrome://resources URL?

-- 
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/CAONRv5%3Do%3DAYpv6eOrnVFD5vUDJKqUVbCwEw8SBJ-0QPjHrESeA%40mail.gmail.com.

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

[Sudheer Boynapally]

Was there any change on January 23rd corresponding to this? like rolling 
out this deprecation?

Thanks,
On Wednesday, January 25, 2023 at 2:57:16 PM UTC-8 Sudheer Boynapally wrote:

> Hi,
>
> Is the deprecation of 'track' and 'stream' objects completed 100% on all 
> the versions of chrome v109 or any specific sub version of 109? 
>
> Thanks,
>
>
> On Tuesday, January 10, 2023 at 5:56:04 AM UTC-8 Henrik Boström wrote:
>
>> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:
>>
>>> +Henrik Boström - was there an intent sent for this removal? Any form 
>>> of developer communication?
>>>
>>
>> There was developer communication dating as far back as July but I admit 
>> I had forgotten to send out a formal blink-dev intent to deprecate!
>>
>> - I should have done that.
>>
>> The getStats() API in question is not being deprecated, but the 
>> RTCStatsReport (an id-to-stats-object map) report will stop containing the 
>> stats object which were made obsolete in the spec several years ago due to 
>> the contents of these stats objects having been moved to other stats 
>> objects that are still being returned. Same values, different location. In 
>> other words, the report is being trimmed down by removing duplicate 
>> information. Stats processing code in an application is gated on stats type 
>> for knowing which metrics to look for on an individual stats object which 
>> should make this lower risk compared to other depracations. The motivation 
>> for this is performance optimizations (~40% report size reduction), 
>> technical debt reduction (-1400 LOC) and web compat ("track" does not 
>> exist in Firefox ).
>>
>> The communication channel used was WebRTC's official google group, 
>> discuss-webrtc . History:
>>
>>- July 25, 2022 PSA 
>> announced 
>>the plan to deprecate at a milestone TBD. This was also the time where 
>> the 
>>"DEPRECATED_" prefix was added to the JavaScript-exposed stats object 
>> IDs, 
>>which made it into M106. The deprecation prefix is also visible in the 
>>chrome://webrtc-internals/ developer page when a page uses WebRTC.
>>- There was another PSA on September 6, 2022 
>> about 
>>other stats news with a reminder of the imminent stats deprecation.
>>- The October 19, 2022 PSA 
>> announced 
>>"track" stats being removed at 50% Canary.
>>- The follow-up October 27, 2022 PSA 
>> announced 
>>it would also be removed at 50% Beta (where M109 Beta was released on 
>>December 1st). This PSA also clarifies that "The goal is to continue 
>>ramping it up on Stable when M109 is released".
>>- Lastly we have yesterday's PSA 
>> announcing 
>>that the removal was advanced to 1% Stable which this conversation is a 
>>response to.
>>
>>
>>> On Mon, Jan 9, 2023 at 9:42 PM Alex Russell  
>>> wrote:
>>>
 Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this 
 seems related to a pattern of breaking changes without Blink intents that 
 we've been informed of by customers.

 Do I understand correctly that this deprecation is being managed via 
 Finch for 109 Stable?

>>>
>> Yes, as to minimize risk of breakage the deprecation is managed via a 
>> Finch flag, which is currently 1% Stable + 50% Canary/Beta.
>> To my knowledge, no issues have been reported since the rollout started 
>> in Canary in November, 2022 or "DEPRECATED_" prefix was added in July, 2022.
>> This, combined with the fact that apps usually gate on type, is why I 
>> thought it would be safe to gently roll out further to Stable.
>>  
>>
>>>
 Best,

 Alex


>> On Tue, Jan 10, 2023 at 12:34 AM 'Aaron Boushley' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Can you help me understand exactly which objects are being removed here? 
>>> We rely on `RTCPeerConnection.getStats()` although we pass in a stream 
>>> selector. We then iterate over the returned stats reports looking for ones 
>>> containing the values we need.
>>>
>>
>> The selector (be it an RTCRtpSender, RTCRtpReceiver or MediaStreamTrack) 
>> continues to work, it's just that the report no longer contains the removed 
>> stats objects.
>>  
>>
>>>
>>> Is this a removal of the stats objects that have the fixed ID of "track" 
>>> and "stream"?
>>>
>>
>> It is the removal of the stats objects where .type == "track" or .type == 
>> "stream".
>> In the spec this refers to dictionaries RTCMediaStreamTrackStats 
>>  and 
>> RTCMediaStreamStats 
>> 

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

[Sudheer Boynapally]

Hi,

Is the deprecation of 'track' and 'stream' objects completed 100% on all 
the versions of chrome v109 or any specific sub version of 109? 

Thanks,


On Tuesday, January 10, 2023 at 5:56:04 AM UTC-8 Henrik Boström wrote:

> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:
>
>> +Henrik Boström - was there an intent sent for this removal? Any form of 
>> developer communication?
>>
>
> There was developer communication dating as far back as July but I admit I 
> had forgotten to send out a formal blink-dev intent to deprecate!
>
> - I should have done that.
>
> The getStats() API in question is not being deprecated, but the 
> RTCStatsReport (an id-to-stats-object map) report will stop containing the 
> stats object which were made obsolete in the spec several years ago due to 
> the contents of these stats objects having been moved to other stats 
> objects that are still being returned. Same values, different location. In 
> other words, the report is being trimmed down by removing duplicate 
> information. Stats processing code in an application is gated on stats type 
> for knowing which metrics to look for on an individual stats object which 
> should make this lower risk compared to other depracations. The motivation 
> for this is performance optimizations (~40% report size reduction), 
> technical debt reduction (-1400 LOC) and web compat ("track" does not 
> exist in Firefox ).
>
> The communication channel used was WebRTC's official google group, 
> discuss-webrtc . History:
>
>- July 25, 2022 PSA 
> announced 
>the plan to deprecate at a milestone TBD. This was also the time where the 
>"DEPRECATED_" prefix was added to the JavaScript-exposed stats object IDs, 
>which made it into M106. The deprecation prefix is also visible in the 
>chrome://webrtc-internals/ developer page when a page uses WebRTC.
>- There was another PSA on September 6, 2022 
> about other 
>stats news with a reminder of the imminent stats deprecation.
>- The October 19, 2022 PSA 
> announced 
>"track" stats being removed at 50% Canary.
>- The follow-up October 27, 2022 PSA 
> announced 
>it would also be removed at 50% Beta (where M109 Beta was released on 
>December 1st). This PSA also clarifies that "The goal is to continue 
>ramping it up on Stable when M109 is released".
>- Lastly we have yesterday's PSA 
> announcing 
>that the removal was advanced to 1% Stable which this conversation is a 
>response to.
>
>
>> On Mon, Jan 9, 2023 at 9:42 PM Alex Russell  
>> wrote:
>>
>>> Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this 
>>> seems related to a pattern of breaking changes without Blink intents that 
>>> we've been informed of by customers.
>>>
>>> Do I understand correctly that this deprecation is being managed via 
>>> Finch for 109 Stable?
>>>
>>
> Yes, as to minimize risk of breakage the deprecation is managed via a 
> Finch flag, which is currently 1% Stable + 50% Canary/Beta.
> To my knowledge, no issues have been reported since the rollout started in 
> Canary in November, 2022 or "DEPRECATED_" prefix was added in July, 2022.
> This, combined with the fact that apps usually gate on type, is why I 
> thought it would be safe to gently roll out further to Stable.
>  
>
>>
>>> Best,
>>>
>>> Alex
>>>
>>>
> On Tue, Jan 10, 2023 at 12:34 AM 'Aaron Boushley' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Can you help me understand exactly which objects are being removed here? 
>> We rely on `RTCPeerConnection.getStats()` although we pass in a stream 
>> selector. We then iterate over the returned stats reports looking for ones 
>> containing the values we need.
>>
>
> The selector (be it an RTCRtpSender, RTCRtpReceiver or MediaStreamTrack) 
> continues to work, it's just that the report no longer contains the removed 
> stats objects.
>  
>
>>
>> Is this a removal of the stats objects that have the fixed ID of "track" 
>> and "stream"?
>>
>
> It is the removal of the stats objects where .type == "track" or .type == 
> "stream".
> In the spec this refers to dictionaries RTCMediaStreamTrackStats 
>  and 
> RTCMediaStreamStats 
>  which are 
> part of the "Obsolete" section of the spec. See RTCStatsType 
>  for complete list 
> of stats object types.
>
> Regarding the track stats dictionary, the same metrics are still 
> available, but you have to look at the 

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Philipp Hancke' via blink-dev]

Am Di., 10. Jan. 2023 um 14:55 Uhr schrieb Henrik Boström :

>
>
> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:
>
>> +Henrik Boström  - was there an intent sent for this
>> removal? Any form of developer communication?
>>
>
> There was developer communication dating as far back as July but I admit I
> had forgotten to send out a formal blink-dev intent to deprecate!
>
> - I should have done that.
>

> The getStats() API in question is not being deprecated, but the
> RTCStatsReport (an id-to-stats-object map) report will stop containing the
> stats object which were made obsolete in the spec several years ago due to
> the contents of these stats objects having been moved to other stats
> objects that are still being returned. Same values, different location. In
> other words, the report is being trimmed down by removing duplicate
> information. Stats processing code in an application is gated on stats type
> for knowing which metrics to look for on an individual stats object which
> should make this lower risk compared to other depracations. The motivation
> for this is performance optimizations (~40% report size reduction),
> technical debt reduction (-1400 LOC) and web compat ("track" does not
> exist in Firefox ).
>

This apparently breaks users of Twilio's Video SDK:
https://github.com/twilio/twilio-video.js/issues/1968#issuecomment-1404316610

WRT web-compat thanks for pointing out to Safari that they missed adding at
least trackIdentifier  to
inbound-rtp.

The communication channel used was WebRTC's official google group,
> discuss-webrtc . History:
>

Given the moderation status of discuss-webrtc that qualifies as a disused
lavatory with a sign on the door saying ‘Beware of the Leopard.” :-)
I am in favor of using that list as much as possible in terms of process
since it is still read by some "WebRTC developers" but I do not think this
is a substitute for talking to developers using WebRTC.


>- July 25, 2022 PSA
> announced
>the plan to deprecate at a milestone TBD. This was also the time where the
>"DEPRECATED_" prefix was added to the JavaScript-exposed stats object IDs,
>which made it into M106. The deprecation prefix is also visible in the
>chrome://webrtc-internals/ developer page when a page uses WebRTC.
>- There was another PSA on September 6, 2022
> about other
>stats news with a reminder of the imminent stats deprecation.
>- The October 19, 2022 PSA
> announced
>"track" stats being removed at 50% Canary.
>- The follow-up October 27, 2022 PSA
> announced
>it would also be removed at 50% Beta (where M109 Beta was released on
>December 1st). This PSA also clarifies that "The goal is to continue
>ramping it up on Stable when M109 is released".
>
> Oh I missed that that the goal was stated there too -- otherwise we would
have the "it is a bad idea to do this during a time of code freezes"
discussion back then.

>
>- Lastly we have yesterday's PSA
> announcing
>that the removal was advanced to 1% Stable which this conversation is a
>response to.
>
>
>> On Mon, Jan 9, 2023 at 9:42 PM Alex Russell 
>> wrote:
>>
>>> Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this
>>> seems related to a pattern of breaking changes without Blink intents that
>>> we've been informed of by customers.
>>>
>>> Do I understand correctly that this deprecation is being managed via
>>> Finch for 109 Stable?
>>>
>>
> Yes, as to minimize risk of breakage the deprecation is managed via a
> Finch flag, which is currently 1% Stable + 50% Canary/Beta.
> To my knowledge, no issues have been reported since the rollout started in
> Canary in November, 2022 or "DEPRECATED_" prefix was added in July, 2022.
> This, combined with the fact that apps usually gate on type, is why I
> thought it would be safe to gently roll out further to Stable.
>

Rolling out the removal via finch as opt-in has quite nasty implications
for CI testing that might(*) be in place, no?
Selenium et al typically starts browsers from fresh profiles and hence does
not know the finch trial seed? (**)
I haven't seen documentation showing how CI should pre-seed the profiles
used with the finch trial seed (and for deprecations it might be better to
recommended a command line for the CI).

I'm still in favor of the removal but removing by default (possibly guarded
by a killswitch) seems like a less error-prone process.

Philipp
(*) I am somewhat pessimistic about the actual state of the "webrtc
industry" wrt to automated tests
(**) at least 

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
  is also
 added to extend the availablility of Event.path until M115.

 Despite the usage number
 
 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
 ,
 which appears resolved by the enterprise policy
 - HTTPArchive source analysis
 
 (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
> 
>
> 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 bug
> https://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 

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Harald Alvestrand' via blink-dev]

Checking the spec is always wise:

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 says that only the
4-digit form of IPv4 address should be supported (4 numbers from 0-255).
There is no trailing dot, so that one is illegal.

The RFC goes on to say ( https://www.rfc-editor.org/rfc/rfc3986#section-7.4
) about the non-4-number form:

"These additional IP address formats are not allowed in the URI syntax

   due to differences between platform implementations.  However, they
   can become a security concern if an application attempts to filter
   access to resources based on the IP address in string literal format.
   If this filtering is performed, literals should be converted to
   numeric form and filtered based on the numeric value, and not on a
   prefix or suffix of the string form."


So we've been inconsistent with the IETF URI spec since at least 2005,
and it may be time to fix the bug.

But properly!



On Wed, Jan 25, 2023 at 11:22 PM Harald Alvestrand  wrote:

> The two addresses here are IPv6 addresses, not IPv4 addresses, as
> evidenced by the :: marker.
> The first form is an IPv6 with embedded IPv4, and it has a trailing dot
> that I do not understand at all, I think it's not legal syntax.
> The second form is two numbers in hex, so the byte value of the last 4
> bytes should be 0x01020003. Which would be equivalent to the first one if
> there was no trailing dot, because that's the shape of an IPv4 Class B
> address, where the last number represents a 16-bit number, not an 8-bit
> number.
>
> I'm not sure what you mean by "shortened IPv4 address" - if you mean IPv4
> addresses with less than 3 dots (class B and class A addresses, when
> classes existed) -  I think that they are indeed rarely used, since modern
> IPv4 networks aren't allocated in classes any more.
>
> I would want to check with other browser vendors on whether they think
> it's worth deprecating this syntax - it's been standardized since IPv4 was
> introduced, so it's a LONG tradition that you are breaking, and unless we
> agree with the others first, we're breaking compatibility.
>
> Harald
>
>
> On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi everyone
>>
>> I plan to remove the shortened IPv4 address support in the URLs such as
>> 127.1 and 192.168.1.
>> WPT failures are reported because of this:
>> : Setting .host = '[::1.2.3.]'!EQ("
>> http://example.net/;, "http://[::102:3]/;)
>>
>> I've added an UMA to collect data about whether people are inputting such
>> kinds of addresses in the omnibox.
>> Data in beta showed that only 0.04% of IPv4 addresses input in the
>> omnibox URL are in this form.
>> We'd like to remove the support as a part of the URL interop.
>>
>> Jiacheng Guo
>>
>> --
>> 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%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/CAOqqYVFvZe97aGdvtWr82eUWXsNS%3DRGsq5tuK7D8bWH%2Bx36v8w%40mail.gmail.com.

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Harald Alvestrand' via blink-dev]

The two addresses here are IPv6 addresses, not IPv4 addresses, as evidenced
by the :: marker.
The first form is an IPv6 with embedded IPv4, and it has a trailing dot
that I do not understand at all, I think it's not legal syntax.
The second form is two numbers in hex, so the byte value of the last 4
bytes should be 0x01020003. Which would be equivalent to the first one if
there was no trailing dot, because that's the shape of an IPv4 Class B
address, where the last number represents a 16-bit number, not an 8-bit
number.

I'm not sure what you mean by "shortened IPv4 address" - if you mean IPv4
addresses with less than 3 dots (class B and class A addresses, when
classes existed) -  I think that they are indeed rarely used, since modern
IPv4 networks aren't allocated in classes any more.

I would want to check with other browser vendors on whether they think it's
worth deprecating this syntax - it's been standardized since IPv4 was
introduced, so it's a LONG tradition that you are breaking, and unless we
agree with the others first, we're breaking compatibility.

Harald


On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi everyone
>
> I plan to remove the shortened IPv4 address support in the URLs such as
> 127.1 and 192.168.1.
> WPT failures are reported because of this:
> : Setting .host = '[::1.2.3.]'!EQ("
> http://example.net/;, "http://[::102:3]/;)
>
> I've added an UMA to collect data about whether people are inputting such
> kinds of addresses in the omnibox.
> Data in beta showed that only 0.04% of IPv4 addresses input in the omnibox
> URL are in this form.
> We'd like to remove the support as a part of the URL interop.
>
> Jiacheng Guo
>
> --
> 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%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/CAOqqYVFYUBVc8-nJQN%3DXMLeM3_x%3DKAiqtq_hOo-U4uEX%3DkyoMw%40mail.gmail.com.

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Avi Drissman' via blink-dev]

Are you talking about IPv4 alone? Or only IPv4 in IPv6, like your examples
that have brackets?

On Wed, Jan 25, 2023 at 4:34 PM 'Matt Menke' via blink-dev <
blink-dev@chromium.org> wrote:

> Is that the only test removing this behavior breaks?  I'm not seeing test
> cases for simple IPv4 expansion cases, like just "http://127.1/;.  I also
> notice that in Firefox, http://127.1 is mapped to http://127.0.0.1/, but
> http://[::1.2.3.] is not treated as a URL, so it's unclear to me if the
> provided test case is suggesting browsers should standardize on not
> supporting shortened URLs at all, or only in the case of IPv4 addresses
> embedded in IPv6 addresses.
>
> The URL standard (https://url.spec.whatwg.org/) in fact explicitly says
> that the host parser should map "0" to "0.0.0.0" and "0x" should be
> mapped to "255.255.255.255" (for "special" schemes, which includes http and
> https).  The IPv4 parser in that doc also continues to support strings with
> fewer than 4 components.
>
> While I'm all for removing support for these, I think there's spec work to
> be done here first.
> On Wednesday, January 25, 2023 at 11:43:06 AM UTC-5 cshar...@chromium.org
> wrote:
>
>> Hey Jiacheng,
>> Did you mean for this to be an official intent? If so, I think it should
>> have a chromestatus.com entry as per the guidelines here
>> 
>> .
>>
>> One more question: I assume from the mention of WPTs that you plan on
>> changing this across the whole web platform, not just for top level
>> navigations. Why do you think measuring just the omnibox metrics is
>> sufficient for measuring the breakage from this change? Should we try to
>> measure this at a lower level like in //url?
>>
>> On Wed, Jan 25, 2023 at 9:52 AM 'Jiacheng Guo' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi everyone
>>>
>>> I plan to remove the shortened IPv4 address support in the URLs such as
>>> 127.1 and 192.168.1.
>>> WPT failures are reported because of this:
>>> : Setting .host = '[::1.2.3.]'!EQ("
>>> http://example.net/;, "http://[::102:3]/;)
>>>
>>> I've added an UMA to collect data about whether people are inputting
>>> such kinds of addresses in the omnibox.
>>> Data in beta showed that only 0.04% of IPv4 addresses input in the
>>> omnibox URL are in this form.
>>> We'd like to remove the support as a part of the URL interop.
>>>
>>> Jiacheng Guo
>>>
>>> --
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%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/cb33ba97-8088-409e-9c26-ccb1a9ca10b9n%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Matt Menke' via blink-dev]

Is that the only test removing this behavior breaks?  I'm not seeing test 
cases for simple IPv4 expansion cases, like just "http://127.1/;.  I also 
notice that in Firefox, http://127.1 is mapped to http://127.0.0.1/, but 
http://[::1.2.3.] is not treated as a URL, so it's unclear to me if the 
provided test case is suggesting browsers should standardize on not 
supporting shortened URLs at all, or only in the case of IPv4 addresses 
embedded in IPv6 addresses.

The URL standard (https://url.spec.whatwg.org/) in fact explicitly says 
that the host parser should map "0" to "0.0.0.0" and "0x" should be 
mapped to "255.255.255.255" (for "special" schemes, which includes http and 
https).  The IPv4 parser in that doc also continues to support strings with 
fewer than 4 components.

While I'm all for removing support for these, I think there's spec work to 
be done here first.
On Wednesday, January 25, 2023 at 11:43:06 AM UTC-5 cshar...@chromium.org 
wrote:

> Hey Jiacheng,
> Did you mean for this to be an official intent? If so, I think it should 
> have a chromestatus.com entry as per the guidelines here 
> 
> .
>
> One more question: I assume from the mention of WPTs that you plan on 
> changing this across the whole web platform, not just for top level 
> navigations. Why do you think measuring just the omnibox metrics is 
> sufficient for measuring the breakage from this change? Should we try to 
> measure this at a lower level like in //url?
>
> On Wed, Jan 25, 2023 at 9:52 AM 'Jiacheng Guo' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi everyone
>>
>> I plan to remove the shortened IPv4 address support in the URLs such as 
>> 127.1 and 192.168.1.
>> WPT failures are reported because of this:
>> : Setting .host = '[::1.2.3.]'!EQ("
>> http://example.net/;, "http://[::102:3]/;)
>>
>> I've added an UMA to collect data about whether people are inputting such 
>> kinds of addresses in the omnibox.
>> Data in beta showed that only 0.04% of IPv4 addresses input in the 
>> omnibox URL are in this form.
>> We'd like to remove the support as a part of the URL interop.
>>
>> Jiacheng Guo
>>
>> -- 
>> 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+...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%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/cb33ba97-8088-409e-9c26-ccb1a9ca10b9n%40chromium.org.

Re: [blink-dev] Intent to implement and ship: Allow as=fetch in navigation early hints preload

[Mike Taylor]

LGTM3

On 1/25/23 12:36 PM, Rick Byers wrote:

LGTM2

On Tue, Jan 24, 2023 at 2:44 AM Kenichi Ishibashi  
wrote:


Thank you Yoav for the suggestions! I'll add more words and
context next time.

On Mon, Jan 23, 2023 at 2:18 PM Yoav Weiss
 wrote:

LGTM1

On Mon, Jan 23, 2023 at 2:57 AM Kenichi Ishibashi
 wrote:


Contact emails

ba...@chromium.org


Explainer

None. This feature is standardized.


It's typically helpful to write a few words that explain the
feature and the addition to it, even if there's no need for a
full fledged explainer document for this specific addition.
For example, you could have linked to the feature's broader
explainer
,
and then explain that this adds a new `as` value of "fetch"
that would enable developers to use Early Hints for resources
with that potential destination (e.g. `fetch()`ed resources).



Specification

https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as

https://html.spec.whatwg.org/#early-hints


Summary

Support  in navigation early
hints. This allows web developers to preload resources
that are fetched by the fetch() API.



Blink component

Blink>Loader>Preload




TAG review



TAG review status

Not applicable


I agree that a TAG review is not needed here, but it's
typically better to outline the reason.
In this case, we're adding support for an extra type of
resource without changing the API's shape or its integration
with the rest of the platform.



Risks



Interoperability and Compatibility

Low. The feature is already specified in the HTML and the
Fetch standard.



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

/WebKit/: No signal Previously asked in
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html

/Web developers/: No signals. We got this feature request
from one of our partners.


I would count a feature request as a slightly positive signal.


/Other signals/:


WebView application risks

N/A



Debuggability

We have a tracking bug

to improve debuggability.


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

?

We will submit a Web Platform Test along with the
implementation (Ongoing CL

).


Flag name

N/A


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

M112



Anticipated spec changes

None



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6195487999262720

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/CAPLXX--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%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 

Re: [blink-dev] Intent to Ship: CSS Nesting

[Mike Taylor]

LGTM3 with same conditions outlined by Rick and Philip.

On 1/25/23 12:30 PM, Rick Byers wrote:
We discussed this in the API owner meeting today (Philip, Rego, 
Daniel, Chris, Yoav, Mike Taylor and myself). We appreciate that 
there's not yet full consensus on the API syntax, but also that we've 
been in this state for several months and we've heard pretty clearly 
from web developers that as a whole they want us to ship something and 
overwhelmingly support option 3 
. 
It seems to me we're in real danger of a priority of constituencies 
 
inversion here with authors continuing to lose out as a result of 
indecision from the implementer and standards community.


Therefore, since option 3 seems to have the bulk of support from web 
developers and browser implementers, I agree with Philip that, absent 
any stronger consensus emerging, we should proceed with shipping it 
for M112 (not M111 which is branching this week). *LGTM2* (with the 
same criteria as Philip).


However, if the CSSWG resolves to materially change the design or the 
TAG completes their review 
 and requests 
specific breaking changes prior to Chrome 112 going to Beta around 
*March 1st*, then I'd retract my LGTM and ask us to flag it back off 
and circle back here to allow for a new attempt at building more 
consensus. As always, some breaking changes may be possible after that 
point too, but it'll depend on the realities of web compat.


API owners also agreed that we'd look for 4 LGTMs in this case instead 
of the usual 3.


Thanks,
  Rick

On Wed, Jan 25, 2023 at 11:24 AM Philip Jägenstedt 
 wrote:


LGTM1

I had a chat with Steinar today to answer my questions. Out of the
open issues, the important ones to resolve before shipping are:
https://github.com/w3c/csswg-drafts/issues/7850
https://github.com/w3c/csswg-drafts/issues/7971
https://github.com/w3c/csswg-drafts/issues/7972

Those don't seem controversial. My LGTM is assuming spec and tests
are updated and that we pass those tests before the
feature reaches stable.

The final test failure is related to #7850 and is an easy fix.

Regarding the syntax, there's still disagreement in the CSSWG.
Unanimous consensus among all WG members doesn't seem possible
here, for any proposal. Crucially, other browser vendors appear to
be OK with "option 3". I would definitely reconsider my LGTM if
there were signs that other browser vendors are not keen on
shipping option 3, since that would create an interop problem, and
eventually site compat problems as well.

As always, we should be receptive to new information even after an
intent has been approved and the flag has been flipped.

On Wed, Jan 25, 2023 at 11:20 AM Manuel Rego Casasnovas
 wrote:

Adding to Philip questions, there seems to be quite a lot of
ongoing
discussions around this topic on the CSSWG, for example today
there's a
special meeting only for CSS Nesting topics:
https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html

What's their impact on the current implementation?

Thanks,
  Rego

On 23/01/2023 18:00, Philip Jägenstedt wrote:
> I think that we should ship this. It's a high profile and
in-demand new
> feature
>
,
so
> I have a few questions and comments first.
>
> Taking a look at the open spec issues
> (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
> )
some are
> explicitly ideas for future changes, but are there any where
shipping
> amounts to a decision that isn't easily changed? I'm
thinking especially
> of the CSSOM issues.
>
> In https://wpt.fyi/results/css/css-nesting
>  there's a single
subtest
> failure, related to how a rule serializes. Is that
implemented per spec,
> or is it tied up with the open CSSOM issues?
>
> Regarding the threat of a formal objection, there doesn't
appear to be
> any solution that would fully satisfy everyone, but I trust your
> judgment that this is the best option. Additionally, we
should not
> pre-commit Blink to shipping parser changes, and accept the
possibility
> that what we ship now is the final shape of the feature.
>
> On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via
blink-dev
> mailto:blink-dev@chromium.org>> wrote:
>
> 

Re: [blink-dev] Intent to Ship: Network State Partitioning

['Brianna Goldstein' via blink-dev]

This is now enabled on 100% of clients.


On Wed, Jan 25, 2023 at 1:57 PM Brianna Goldstein 
wrote:

> This is now enabled on 100% of clients.
>
> On Thu, Jan 12, 2023 at 3:39 PM Brianna Goldstein 
> wrote:
>
>> Updating this thread to track that this was ramped up to 10% stable this
>> week. Estimated milestones remain:
>>
>> Estimated milestones
>>
>> Ship at 1% on December 13th - M108
>>
>> Ship at 10% on January 9th - M109
>>
>> Ship at 100% on January 23rd - M109
>>
>>
>>
>>
>>
>> On Mon, Dec 12, 2022 at 2:37 PM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> Thanks for your close collaboration with the security team here; I think
>>> the compromise you landed on is both reasonable and good.
>>>
>>> -mike
>>>
>>>
>>> On Mon, Dec 12, 2022 at 8:13 PM Chris Harrelson 
>>> wrote:
>>>
 LGTM2

 On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss 
 wrote:

> LGTM1
>
> Thanks for working on this compromise between our security/privacy
> needs and our performance goals!!
>
> On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> brgoldst...@chromium.org, mme...@chromium.org, a...@google.com,
>> miketa...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
>>
>> Specification
>>
>> https://fetch.spec.whatwg.org/#connections
>>
>> Summary
>>
>> Partition network state by the network partition key to protect
>> against cross-site tracking through the use of side channels. The network
>> partition key consists of the schemeful site of the top level frame and a
>> boolean indicating if the request is coming from a cross-site iframe.
>> "Network State" here includes connections (H1, H2, H3, websocket), the 
>> DNS
>> cache, ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL
>> configuration and uploads.
>>
>> Unpartitioned network state allows for side-channel timing attacks,
>> where one site can figure out if another has been visited recently. For
>> example, if the connection is made quickly, it may be assumed that a
>> connected socket exists. It also allows for third parties to track users
>> across first party contexts they are loaded in using a variety of
>> techniques (tracking socket reuse, using per-user alternative service
>> advertisements, etc).
>>
>> Our initial attempt to partition the network state re-used the triple
>> key partition scheme that was shipped for the HTTP cache
>> . This included
>> the schemeful sites of the top-level frame and the iframe. However, in an
>> attempt to land a favorable balance between (1) the performance benefits 
>> of
>> shared resources, and (2) the privacy promises of ensuring sites are 
>> safely
>> prevented from gaining information about a user’s browsing habits, this 
>> new
>> partition key consists of the top level site and a boolean indicating if
>> the request is coming from a cross-site iframe.
>>
>> Partitioning may reduce Chromium’s ability to reuse network
>> resources.  We’ve enabled network state partitioning in a 1% experiment 
>> on
>> Stable. From our experiments, Android navigation times to first
>> contentful paint are increased by around 0.35% at the 50th percentile and
>> 0.17% at the 99th percentile. Cross-site iframe navigation time to first
>> contentful paints is increased by 2.85% at the 50th percentile and 1.35% 
>> at
>> the 99th percentile. This represents about a 40 ms increase at the 50th
>> percentile. On desktop, navigation times to first contentful paint are
>> increased by around 1.00% at the 50th percentile (approximately a 10 ms
>> increase) and have no impact on the 99th percentile. For cross-site
>> iframes, the navigation times to first contentful paint are increased by
>> 1.84% at the 50th percentile and 2.05% at the 99th percentile.
>>
>
> The numbers still don't make me leap of joy, but they are
> significantly more reasonable than the previous iteration.
> I'm curious about the p75 numbers, but assuming they are somewhere in
> between, that probably won't change the outcome.
>
> I wonder if speculative preconnection using the right key could have
> bought back some of this. I similarly wonder if it could've been safe to
> somehow publish speculative congestion windows to get rid of slow start in
> those cases.
> But obviously, none of this is a blocker to shipping this. Just ideas
> for winning back some of the losses (that may enable stricter partitioning
> if they actually work)
>
> +Kenji Baheux  - FYI
>
>
>>
>> Explainer:
>> 

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

Sounds good, I'm adding a UseCounter here:
https://chromium-review.googlesource.com/c/chromium/src/+/4193560

On Tue, Jan 24, 2023 at 8:05 AM Rick Byers  wrote:

> Hey Joey,
> Thanks for working to remove a quirk! Although we haven't written it into
> our compat principles , I'm personally
> willing to accept greater compat risk for removing quirks as they're
> by-definition legacy behavior of the web which create an ongoing complexity
> burden for the platform which we should seek to eventually eliminate.
>
> Reading through the history
>  of
> WebKit not being able to make this change due to severe breakage in
> bugzilla and seeing that we still load 12% of pages in quirks mode
> , I
> don't think I can support proceeding without UseCounter data. Personally I
> would be happy to approve if we had a UseCounter with less than our small
> but non-trivial risk threshold
> 
> of 0.001% of page loads. Based on Simon's previous HTTP Archive analysis
>  you'll
> want to exclude the case where the strings match in your calculation. I
> think ignoring cases where the child text is empty is also fine as it'll
> avoid false positives with script updated DOM that Simon described and
> because replacing empty with non-empty string is almost certainly an
> improvement. WDYT?
>
> Rick
>
>
> On Thu, Jan 19, 2023 at 3:54 PM Joey Arhar  wrote:
>
>> > It's reassuring that this ships in Gecko, but do we have any sense of
>> how common it is to encounter an option w/ a label in quirks mode?
>>
>> I could add a use counter but I'm not sure what results would be
>> considered acceptable.
>> Apparently firefox only had one regression bug when they shipped this
>> behavior:
>> https://github.com/whatwg/html/issues/2988#issuecomment-1378794167
>>
>> On Thu, Jan 19, 2023 at 12:18 PM Mike Taylor 
>> wrote:
>>
>>> On 1/19/23 12:54 PM, Joey Arhar wrote:
>>>
>>> Contact emails jar...@chromium.org
>>>
>>> Specification https://github.com/whatwg/html/issues/2988
>>>
>>> Summary
>>>
>>> Option elements support a "label" attribute which will cause the option
>>> to render with the text inside the attribute rather than the child text of
>>> the option element itself. This functionality is disabled in quirks mode,
>>> where the label attribute is ignored and the child text is always rendered.
>>> This change will always use the label attribute in both standards mode and
>>> quirks mode.
>>>
>>>
>>> Blink component Blink>Forms>Select
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> If websites rely on this quirks mode behavior despite firefox already
>>> shipping this behavior for years, then select elements won't render with
>>> the expected text. If too many websites are broken, I will disable this
>>> change via finch and try to change the HTML spec to align with chrome.
>>>
>>> It's reassuring that this ships in Gecko, but do we have any sense of
>>> how common it is to encounter an option w/ a label in quirks mode?
>>>
>>>
>>>
>>> *Gecko*: Shipped/Shipping (
>>> https://wpt.fyi/results/html/rendering/widgets/the-select-element/option-add-label-quirks.html
>>> )
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> There are no other platform APIs that this change will be used in tandem
>>> with.
>>>
>>>
>>> Activation
>>>
>>> This will not be challenging for developers to take advantage of.
>>>
>>>
>>> Security
>>>
>>> There are no security risks/considerations for this feature.
>>>
>>>
>>> WebView application risks
>>>
>>> This change does not have particularly high risk to WebView.
>>>
>>>
>>> Debuggability
>>>
>>> No DevTools changes are needed for this change.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> Flag name --enable-features=OptionElementAlwaysUseLabel
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1403735
>>>
>>> Estimated milestones
>>>
>>> 111
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web 

Re: [blink-dev] Intent to implement and ship: Allow as=fetch in navigation early hints preload

[Rick Byers]

LGTM2

On Tue, Jan 24, 2023 at 2:44 AM Kenichi Ishibashi 
wrote:

> Thank you Yoav for the suggestions! I'll add more words and context next
> time.
>
> On Mon, Jan 23, 2023 at 2:18 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Mon, Jan 23, 2023 at 2:57 AM Kenichi Ishibashi 
>> wrote:
>>
>>> Contact emailsba...@chromium.org
>>>
>>> ExplainerNone. This feature is standardized.
>>>
>>
>> It's typically helpful to write a few words that explain the feature and
>> the addition to it, even if there's no need for a full fledged explainer
>> document for this specific addition.
>> For example, you could have linked to the feature's broader explainer
>> ,
>> and then explain that this adds a new `as` value of "fetch" that would
>> enable developers to use Early Hints for resources with that potential
>> destination (e.g. `fetch()`ed resources).
>>
>>
>>>
>>> Specification
>>> https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as
>>> https://html.spec.whatwg.org/#early-hints
>>>
>>> Summary
>>>
>>> Support  in navigation early hints. This
>>> allows web developers to preload resources that are fetched by the fetch()
>>> API.
>>>
>>>
>>> Blink componentBlink>Loader>Preload
>>> 
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>
>> I agree that a TAG review is not needed here, but it's typically better
>> to outline the reason.
>> In this case, we're adding support for an extra type of resource without
>> changing the API's shape or its integration with the rest of the platform.
>>
>>
>>>
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Low. The feature is already specified in the HTML and the Fetch standard.
>>>
>>>
>>> *Gecko*: In development (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1407355)
>>>
>>> *WebKit*: No signal Previously asked in
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html
>>>
>>> *Web developers*: No signals. We got this feature request from one of
>>> our partners.
>>>
>>
>> I would count a feature request as a slightly positive signal.
>>
>>
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> N/A
>>>
>>>
>>>
>>> Debuggability
>>>
>>> We have a tracking bug
>>>  to
>>> improve debuggability.
>>>
>>> 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
>>> 
>>> ?We will submit a Web Platform Test along with the implementation (Ongoing
>>> CL ).
>>>
>>> Flag nameN/A
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1408649
>>>
>>> Estimated milestones
>>>
>>> M112
>>>
>>>
>>> Anticipated spec changes
>>>
>>> None
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6195487999262720
>>>
>>> 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/CAPLXX--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%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/CAPLXX-_O7%2Buvu8VbMox69M7f0E7BeEeZ1BC4frEkoXbytaLbdQ%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/CAFUtAY9-xG%2BKWcNSVkhh-%3DRQ8na7J%2BcNN85VGc7cefuUi8Hn4w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Rick Byers]

We discussed this in the API owner meeting today (Philip, Rego, Daniel,
Chris, Yoav, Mike Taylor and myself). We appreciate that there's not yet
full consensus on the API syntax, but also that we've been in this state
for several months and we've heard pretty clearly from web developers that
as a whole they want us to ship something and overwhelmingly support option
3
.
It seems to me we're in real danger of a priority of constituencies

inversion here with authors continuing to lose out as a result of
indecision from the implementer and standards community.

Therefore, since option 3 seems to have the bulk of support from web
developers and browser implementers, I agree with Philip that, absent any
stronger consensus emerging, we should proceed with shipping it for M112
(not M111 which is branching this week). *LGTM2* (with the same criteria as
Philip).

However, if the CSSWG resolves to materially change the design or the TAG
completes their review
 and
requests specific breaking changes prior to Chrome 112 going to Beta
around *March
1st*, then I'd retract my LGTM and ask us to flag it back off and circle
back here to allow for a new attempt at building more consensus. As always,
some breaking changes may be possible after that point too, but it'll
depend on the realities of web compat.

API owners also agreed that we'd look for 4 LGTMs in this case instead of
the usual 3.

Thanks,
  Rick

On Wed, Jan 25, 2023 at 11:24 AM Philip Jägenstedt 
wrote:

> LGTM1
>
> I had a chat with Steinar today to answer my questions. Out of the open
> issues, the important ones to resolve before shipping are:
> https://github.com/w3c/csswg-drafts/issues/7850
> https://github.com/w3c/csswg-drafts/issues/7971
> https://github.com/w3c/csswg-drafts/issues/7972
>
> Those don't seem controversial. My LGTM is assuming spec and tests are
> updated and that we pass those tests before the feature reaches stable.
>
> The final test failure is related to #7850 and is an easy fix.
>
> Regarding the syntax, there's still disagreement in the CSSWG.
> Unanimous consensus among all WG members doesn't seem possible here, for
> any proposal. Crucially, other browser vendors appear to be OK with "option
> 3". I would definitely reconsider my LGTM if there were signs that other
> browser vendors are not keen on shipping option 3, since that would create
> an interop problem, and eventually site compat problems as well.
>
> As always, we should be receptive to new information even after an intent
> has been approved and the flag has been flipped.
>
> On Wed, Jan 25, 2023 at 11:20 AM Manuel Rego Casasnovas 
> wrote:
>
>> Adding to Philip questions, there seems to be quite a lot of ongoing
>> discussions around this topic on the CSSWG, for example today there's a
>> special meeting only for CSS Nesting topics:
>> https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html
>>
>> What's their impact on the current implementation?
>>
>> Thanks,
>>   Rego
>>
>> On 23/01/2023 18:00, Philip Jägenstedt wrote:
>> > I think that we should ship this. It's a high profile and in-demand new
>> > feature
>> > ,
>> so
>> > I have a few questions and comments first.
>> >
>> > Taking a look at the open spec issues
>> > (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
>> > ) some are
>> > explicitly ideas for future changes, but are there any where shipping
>> > amounts to a decision that isn't easily changed? I'm thinking especially
>> > of the CSSOM issues.
>> >
>> > In https://wpt.fyi/results/css/css-nesting
>> >  there's a single subtest
>> > failure, related to how a rule serializes. Is that implemented per spec,
>> > or is it tied up with the open CSSOM issues?
>> >
>> > Regarding the threat of a formal objection, there doesn't appear to be
>> > any solution that would fully satisfy everyone, but I trust your
>> > judgment that this is the best option. Additionally, we should not
>> > pre-commit Blink to shipping parser changes, and accept the possibility
>> > that what we ship now is the final shape of the feature.
>> >
>> > On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev
>> > mailto:blink-dev@chromium.org>> wrote:
>> >
>> > Contact emails: se...@chromium.org ,
>> > futh...@chromium.org 
>> > Explainer: None
>> >
>> > Specification: https://drafts.csswg.org/css-nesting
>> > 
>> >
>> > Summary: Add the ability to nest CSS style rules inside other style
>> > rules,
>> > combining selectors from the outer with the inner rule for
>> 

Re: [blink-dev] Intent to Ship: RegExp v flag with set notation + properties of strings

[Chris Harrelson]

LGTM1

On Wed, Jan 25, 2023 at 7:52 AM 'Patrick Thier' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailspth...@chromium.org, math...@chromium.org
>
> Explainerhttps://github.com/tc39/proposal-regexp-v-flag
> https://v8.dev/features/regexp-v-flag
>
> Specificationhttps://github.com/tc39/proposal-regexp-v-flag
>
> Summary
>
> Add set operations, string literals, nested classes and unicode properties
> of strings to regular expression character classes. Set operations and
> unicode properties of strings allow developers to create regular
> expressions matching strings with certain unicode characters with ease.
> E.g. /[\p{Script_Extensions=Greek}&&\p{Letter}]/v matches all greek letters.
>
>
> Blink componentBlink>JavaScript>Regexp
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Covered by TC39 process: https://github.com/tc39/proposal-regexp-v-flag
>
>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1713657)
> Assumed positive because this proposal is Stage 3 in TC39.
>
> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=241593)
> Assumed positive because this proposal is Stage 3 in TC39.
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Activation
>
> The new features are gated behind a new regular expression flag (/v). See
> https://github.com/tc39/proposal-regexp-v-flag#is-the-new-syntax-backwards-compatible-do-we-need-another-regular-expression-flag
>
>
> 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
>
> Uses existing debugging support for regular expressions. No additions
> required.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> The feature is enabled for all platforms when compiled with
> internalization support.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Covered by test262:
> https://github.com/tc39/test262/tree/main/test/built-ins/RegExp/unicodeSets/generated
>
> Flag name--harmony-regexp-unicode-sets
>
> Requires code in //chrome?False
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> no
>
> Sample links
> https://v8.dev/features/regexp-v-flag
>
> Estimated milestones
> DevTrial on desktop 110
> DevTrial on Android 110
> Planned to ship in M112
>
>
> 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).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5144156542861312
>
> 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/CAKhjTa_NMAR5FF5zkWDa0msVJk3gHA%3DgnzMndyv-_atBNr%3DQnQ%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%2Bw9MP-QiDWt5wHO6KsTWrZ1vy_NUcNZz-Nb%3DviKdnV%3D-TQ%40mail.gmail.com.

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

[Charles Harrison]

Hey Jiacheng,
Did you mean for this to be an official intent? If so, I think it should
have a chromestatus.com entry as per the guidelines here

.

One more question: I assume from the mention of WPTs that you plan on
changing this across the whole web platform, not just for top level
navigations. Why do you think measuring just the omnibox metrics is
sufficient for measuring the breakage from this change? Should we try to
measure this at a lower level like in //url?

On Wed, Jan 25, 2023 at 9:52 AM 'Jiacheng Guo' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi everyone
>
> I plan to remove the shortened IPv4 address support in the URLs such as
> 127.1 and 192.168.1.
> WPT failures are reported because of this:
> : Setting .host = '[::1.2.3.]'!EQ("
> http://example.net/;, "http://[::102:3]/;)
>
> I've added an UMA to collect data about whether people are inputting such
> kinds of addresses in the omnibox.
> Data in beta showed that only 0.04% of IPv4 addresses input in the omnibox
> URL are in this form.
> We'd like to remove the support as a part of the URL interop.
>
> Jiacheng Guo
>
> --
> 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%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/CADjAqN4PLoDxZ6b_xWYQwT3AQNTyvkAGvAstThj1Lym4tvvpuA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Philip Jägenstedt]

LGTM1

I had a chat with Steinar today to answer my questions. Out of the open
issues, the important ones to resolve before shipping are:
https://github.com/w3c/csswg-drafts/issues/7850
https://github.com/w3c/csswg-drafts/issues/7971
https://github.com/w3c/csswg-drafts/issues/7972

Those don't seem controversial. My LGTM is assuming spec and tests are
updated and that we pass those tests before the feature reaches stable.

The final test failure is related to #7850 and is an easy fix.

Regarding the syntax, there's still disagreement in the CSSWG.
Unanimous consensus among all WG members doesn't seem possible here, for
any proposal. Crucially, other browser vendors appear to be OK with "option
3". I would definitely reconsider my LGTM if there were signs that other
browser vendors are not keen on shipping option 3, since that would create
an interop problem, and eventually site compat problems as well.

As always, we should be receptive to new information even after an intent
has been approved and the flag has been flipped.

On Wed, Jan 25, 2023 at 11:20 AM Manuel Rego Casasnovas 
wrote:

> Adding to Philip questions, there seems to be quite a lot of ongoing
> discussions around this topic on the CSSWG, for example today there's a
> special meeting only for CSS Nesting topics:
> https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html
>
> What's their impact on the current implementation?
>
> Thanks,
>   Rego
>
> On 23/01/2023 18:00, Philip Jägenstedt wrote:
> > I think that we should ship this. It's a high profile and in-demand new
> > feature
> > , so
> > I have a few questions and comments first.
> >
> > Taking a look at the open spec issues
> > (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
> > ) some are
> > explicitly ideas for future changes, but are there any where shipping
> > amounts to a decision that isn't easily changed? I'm thinking especially
> > of the CSSOM issues.
> >
> > In https://wpt.fyi/results/css/css-nesting
> >  there's a single subtest
> > failure, related to how a rule serializes. Is that implemented per spec,
> > or is it tied up with the open CSSOM issues?
> >
> > Regarding the threat of a formal objection, there doesn't appear to be
> > any solution that would fully satisfy everyone, but I trust your
> > judgment that this is the best option. Additionally, we should not
> > pre-commit Blink to shipping parser changes, and accept the possibility
> > that what we ship now is the final shape of the feature.
> >
> > On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev
> > mailto:blink-dev@chromium.org>> wrote:
> >
> > Contact emails: se...@chromium.org ,
> > futh...@chromium.org 
> > Explainer: None
> >
> > Specification: https://drafts.csswg.org/css-nesting
> > 
> >
> > Summary: Add the ability to nest CSS style rules inside other style
> > rules,
> > combining selectors from the outer with the inner rule for increasing
> > modularity and maintainability of style sheets.
> >
> > Blink component: Blink>CSS
> >
> > TAG review: https://github.com/w3ctag/design-reviews/issues/791
> > 
> >
> > TAG review status: Pending
> >
> > Risks: There is a threat of a formal objection in CSSWG.
> >
> > Interoperability and Compatibility:
> >
> > Gecko: Positive
> > (https://github.com/mozilla/standards-positions/issues/695
> > )
> > WebKit: Positive
> > (https://github.com/WebKit/standards-positions/issues/69
> > )
> >
> > Debuggability
> > Nesting style rules will be a big change for editing and displaying
> > style rules in the inspector:
> >
> > - Showing displaying nested rules for matching declarations
> > - Editing selectors
> > - Inserting nested rules
> > - etc...
> >
> > Tracking issue for devtools support: https://crbug.com/1172985
> > 
> > Devtools says they're on track for shipping in M111.
> >
> > Will this feature be supported on all six Blink platforms (Windows,
> > Mac, Linux,
> > Chrome OS, Android, and Android WebView)? Yes
> >
> > Is this feature fully tested by web-platform-tests? Yes
> >
> > Flag name: CSSNesting
> >
> > Requires code in //chrome? False
> >
> > Tracking bug: https://crbug.com/1095675 
> >
> > Estimated milestones
> > DevTrial on desktop 109
> > DevTrial on Android 109
> > Shipping112
> >
> >
> > Anticipated spec changes: See above.
> >
> > Link to 

[blink-dev] Intent to Ship: RegExp v flag with set notation + properties of strings

['Patrick Thier' via blink-dev]

Contact emailspth...@chromium.org, math...@chromium.org

Explainerhttps://github.com/tc39/proposal-regexp-v-flag
https://v8.dev/features/regexp-v-flag

Specificationhttps://github.com/tc39/proposal-regexp-v-flag

Summary

Add set operations, string literals, nested classes and unicode properties
of strings to regular expression character classes. Set operations and
unicode properties of strings allow developers to create regular
expressions matching strings with certain unicode characters with ease.
E.g. /[\p{Script_Extensions=Greek}&&\p{Letter}]/v matches all greek letters.


Blink componentBlink>JavaScript>Regexp


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Covered by TC39 process: https://github.com/tc39/proposal-regexp-v-flag


*Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1713657)
Assumed positive because this proposal is Stage 3 in TC39.

*WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=241593) Assumed
positive because this proposal is Stage 3 in TC39.

*Web developers*: No signals

*Other signals*:

Activation

The new features are gated behind a new regular expression flag (/v). See
https://github.com/tc39/proposal-regexp-v-flag#is-the-new-syntax-backwards-compatible-do-we-need-another-regular-expression-flag


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

Uses existing debugging support for regular expressions. No additions
required.


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

The feature is enabled for all platforms when compiled with internalization
support.


Is this feature fully tested by web-platform-tests

?Covered by test262:
https://github.com/tc39/test262/tree/main/test/built-ins/RegExp/unicodeSets/generated

Flag name--harmony-regexp-unicode-sets

Requires code in //chrome?False

Non-OSS dependencies

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

Sample links
https://v8.dev/features/regexp-v-flag

Estimated milestones
DevTrial on desktop 110
DevTrial on Android 110
Planned to ship in M112


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


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

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/CAKhjTa_NMAR5FF5zkWDa0msVJk3gHA%3DgnzMndyv-_atBNr%3DQnQ%40mail.gmail.com.

[blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Jiacheng Guo' via blink-dev]

Hi everyone

I plan to remove the shortened IPv4 address support in the URLs such as
127.1 and 192.168.1.
WPT failures are reported because of this:
: Setting .host = '[::1.2.3.]'!EQ("
http://example.net/;, "http://[::102:3]/;)

I've added an UMA to collect data about whether people are inputting such
kinds of addresses in the omnibox.
Data in beta showed that only 0.04% of IPv4 addresses input in the omnibox
URL are in this form.
We'd like to remove the support as a part of the URL interop.

Jiacheng Guo

-- 
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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Streaming declarative shadow DOM

[Mason Freed]

Thanks everyone!


On Wed, Jan 25, 2023 at 7:33 AM Philip Jägenstedt 
wrote:

> LGTM3, that this is already enabled in WebKit makes it a pretty simple
> case.
>
> On Wed, Jan 25, 2023 at 8:34 AM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> On Tue, Jan 24, 2023 at 9:27 PM Rick Byers  wrote:
>>
>>> Thanks Mason. LGTM1
>>>
>>> On Tue, Jan 24, 2023 at 2:59 PM Mason Freed  wrote:
>>>


 On Tue, Jan 24, 2023 at 8:41 AM Rick Byers  wrote:

>
>> *Gecko*: Positive (
>> https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065
>> )
>>
>
> Per our process, Mozilla has asked that we only consider positive
> signals from their standards-position repo. I see they currently have
> 
> a 'neutral' for declarative shadow DOM with concerns about the 
> cost/benefit
> tradeoff of the feature.
>
> Also this is a link to a comment by a (now) Apple employee. Did you
> have a different link in mind perhaps?
>

 Good catch - that was a link copy/paste mistake on my part. I've
 updated Chromestatus, but the link I was intending to use was this one
 for Mozilla
 .
 Having said that, it isn't obviously supportive, so I've also asked to
 have the position issue re-opened and hopefully updated
 
 .


> *WebKit*: Positive (
>> https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065
>> )
>>
>
> Based on your link
> 
> above we can now call this "shipping", right? That's a very strong signal
> IMHO.
>

 Thanks - also updated. It is indeed shipping, and WebKit's official
 position is now also "support"
 .


> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>
> I see the test link
> ,
> but are tests written somewhere for this change in particular? In
> particular do latest WebKit and chromium with this flag enabled pass the
> exact same set of tests for declarative shadow DOM or are there still
> notable behavior differences?
>

 So I've already updated the tests on WPT to use the new
 `shadowrootmode` attribute, and they also now check for streaming behavior.
 (For Chromium, I have a virtual suite
 
 that also tests the old behavior, which I'll keep running until I'm able to
 deprecate and remove it.)

 WebKit (reportedly
 )
 passes all of those tests except the ones related to the serialization
 behavior which was pulled out
  of
 the current PR. There is still ongoing discussion around enabling
 imperative parsing (via DOMParser
 ) of DSD content, and if
 they end up removing that functionality, they'll fail more tests.

 Thanks,
 Mason




> Flag nameStreamingDeclarativeShadowDOM
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1379513
>>
>> Estimated milestones
>>
>> M111
>>
>>
>> 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).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5161240576393216
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhGHqD6du83UKvRpX-P7ftaG_R8j1pXE-ofqwHGf-sysA%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship: Streaming declarative shadow DOM

[Philip Jägenstedt]

LGTM3, that this is already enabled in WebKit makes it a pretty simple case.

On Wed, Jan 25, 2023 at 8:34 AM Yoav Weiss  wrote:

> LGTM2
>
> On Tue, Jan 24, 2023 at 9:27 PM Rick Byers  wrote:
>
>> Thanks Mason. LGTM1
>>
>> On Tue, Jan 24, 2023 at 2:59 PM Mason Freed  wrote:
>>
>>>
>>>
>>> On Tue, Jan 24, 2023 at 8:41 AM Rick Byers  wrote:
>>>

> *Gecko*: Positive (
> https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065)
>

 Per our process, Mozilla has asked that we only consider positive
 signals from their standards-position repo. I see they currently have
 
 a 'neutral' for declarative shadow DOM with concerns about the cost/benefit
 tradeoff of the feature.

 Also this is a link to a comment by a (now) Apple employee. Did you
 have a different link in mind perhaps?

>>>
>>> Good catch - that was a link copy/paste mistake on my part. I've updated
>>> Chromestatus, but the link I was intending to use was this one for
>>> Mozilla
>>> .
>>> Having said that, it isn't obviously supportive, so I've also asked to
>>> have the position issue re-opened and hopefully updated
>>> 
>>> .
>>>
>>>
 *WebKit*: Positive (
> https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065)
>

 Based on your link
 
 above we can now call this "shipping", right? That's a very strong signal
 IMHO.

>>>
>>> Thanks - also updated. It is indeed shipping, and WebKit's official
>>> position is now also "support"
>>> .
>>>
>>>
 Is this feature fully tested by web-platform-tests
> 
> ?Yes
>

 I see the test link
 ,
 but are tests written somewhere for this change in particular? In
 particular do latest WebKit and chromium with this flag enabled pass the
 exact same set of tests for declarative shadow DOM or are there still
 notable behavior differences?

>>>
>>> So I've already updated the tests on WPT to use the new `shadowrootmode`
>>> attribute, and they also now check for streaming behavior. (For Chromium, I
>>> have a virtual suite
>>> 
>>> that also tests the old behavior, which I'll keep running until I'm able to
>>> deprecate and remove it.)
>>>
>>> WebKit (reportedly
>>> )
>>> passes all of those tests except the ones related to the serialization
>>> behavior which was pulled out
>>>  of
>>> the current PR. There is still ongoing discussion around enabling
>>> imperative parsing (via DOMParser
>>> ) of DSD content, and if
>>> they end up removing that functionality, they'll fail more tests.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>>
>>>
 Flag nameStreamingDeclarativeShadowDOM
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1379513
>
> Estimated milestones
>
> M111
>
>
> 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).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5161240576393216
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhGHqD6du83UKvRpX-P7ftaG_R8j1pXE-ofqwHGf-sysA%40mail.gmail.com
> 
> .
>
 --
>> You received this message because you are subscribed 

Re: [blink-dev] Intent to Prototype: CSS Sign Related Functions

[Yoav Weiss]

Sounds great! Thanks for working on this!

On Sun, Jan 22, 2023 at 12:42 PM Seokho Song  wrote:

>
>
> On Tuesday, January 17, 2023 at 1:38:13 AM UTC+9 Yoav Weiss wrote:
> On Sun, Jan 15, 2023 at 9:10 AM Seokho Song  wrote:
> Contact emailsseo...@chromium.org
>
> ExplainerNone
>
> Can you explain in a few lines what this feature does and how are
> developers supposed to use it?
>
> Web developers can handle sign-related values via abs(), and sign()
> functions. And the developer can handle complex math expressions on CSS by
> css-values-4 functions.
>
>
>
>
> Specificationhttps://drafts.csswg.org/css-values/#sign-funcs
>
> Summary
>
> Add css sign-related functions abs(), sign() to css math expressions.
>
>
> Blink componentBlink>CSS
> 
>
> MotivationThis feature improves conformance with the spec.
>
> Is there motivation beyond that? Does the feature have benefits to users
> or developers?
>
>
> abs(A) returns the absolute value of A  for example, abs(-1) will be 1.
> sign(A) returns +1 if A numeric value is positive, and -1 if A numeric
> value is negative.
> It returns negative zero if A is negative zero, on the other hand,
> positive zero if A is positive zero.
>
>
>
>
> Initial public proposal
>
> Search tagscss , math
> functions , abs
> , abs()
> , sign
> , sign()
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1810342)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229786
> )
>
> *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
>
> Why not?
>
>
> Sure. This is tested by:
>
> https://wpt.fyi/results/css/css-values/signs-abs-computed.html
> https://wpt.fyi/results/css/css-values/signs-abs-invalid.html
> https://wpt.fyi/results/css/css-values/signs-abs-serialize.html
>
> I updated on feature entry.
> Thanks!
>
>
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1407476
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5170177098907648
>
> 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/CAPzLR4%2Ba8S6bJHOsy3jAv5GN_Z70%
> 3DOE4pBuBhE6A5nFbvf-m2g%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/CAL5BFfVwh7UcXdXmqoXkkTTXitUfcurRbOe6RBUqTnatUHtKeg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Updated dialog initial focus algorithm

[Yoav Weiss]

LGTM2 for the reasons Rick pointed out. 
On Wednesday, January 25, 2023 at 6:42:39 AM UTC+1 Joey Arhar wrote:
> Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer 
interest?

Yes it looks that way

> Do other browsers exactly match the behavior before this spec change, or 
is it more complicated than that? What I'm getting at is whether we have 
confidence that we'll have eventual interop on the new behavior.

Yes, we currently have interop.
People from the other browsers discussed changing the initial focus 
behavior quite a bit in this issue 
, so I feel confident that they 
will also implement the new behavior assuming they approve of the new spec.

It won't be hard for us to change course if the discussion with other 
vendors would cause the spec change to land as slightly different, right?
 

On Tue, Jan 24, 2023 at 8:52 AM Philip Jägenstedt  
wrote:
Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer 
interest?

Do other browsers exactly match the behavior before this spec change, or is 
it more complicated than that? What I'm getting at is whether we have 
confidence that we'll have eventual interop on the new behavior.

On Tue, Jan 24, 2023 at 4:41 PM Rick Byers  wrote:
Looks like showing dialog elements is at around 0.04% 
 of 
 page 
loads, so that's an upper bound of the compat risk here, right? The 
severity of breakage for focus not being what the developer wanted seems 
quite low, and ease of adaptability seems high. Also it seems clear there 
will be a significant net accessibility benefit to this change. Thanks for 
adding the finch kill-switch just in case we're wrong about all this.

LGTM1

On Wed, Jan 18, 2023 at 6:00 PM Joey Arhar  wrote:
Contact emailsjar...@chromium.org

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

Summary

Some changes are being made to which element is selected to get focus when 
a dialog element is opened: 1. Make the dialog focusing steps look at 
keyboard focusable elements instead of any focusable element. 2. Make the 
dialog element itself get focus if it has the autofocus attribute set. 3. 
Make the dialog element itself get focus as a fallback instead of focus 
being "reset" to the body element.


Blink componentBlink>HTML>Dialog 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

If a website affected by this change absolutely needs the old element to be 
focused, they would likely need to add the autofocus attribute to it. If by 
some chance this causes a really bad breakage, I can disable it via finch. 
I don't believe negative effects are likely since this new behavior was 
thoroughly thought out over the last year by accessibility experts.


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

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

*Web developers*: No signals

*Other signals*:

Ergonomics

This change will not be used in tandem with other platform APIs.


Activation

It will not be challenging for developers to take advantage of this change, 
and no polyfills/outreach is needed.


Security

This change has no security considerations/risks.


WebView application risks

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



Debuggability

Dialog initial focus doesn't have any special DevTools support and I don't 
think it needs any.


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

Is this feature fully tested by web-platform-tests 

?Yes

Flag name--enable-features=DialogNewFocusBehavior

Requires code in //chrome?False

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

Estimated milestones

111


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


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

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.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Manuel Rego Casasnovas]

Adding to Philip questions, there seems to be quite a lot of ongoing
discussions around this topic on the CSSWG, for example today there's a
special meeting only for CSS Nesting topics:
https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html

What's their impact on the current implementation?

Thanks,
  Rego

On 23/01/2023 18:00, Philip Jägenstedt wrote:
> I think that we should ship this. It's a high profile and in-demand new
> feature
> , so
> I have a few questions and comments first.
> 
> Taking a look at the open spec issues
> (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
> ) some are
> explicitly ideas for future changes, but are there any where shipping
> amounts to a decision that isn't easily changed? I'm thinking especially
> of the CSSOM issues.
> 
> In https://wpt.fyi/results/css/css-nesting
>  there's a single subtest
> failure, related to how a rule serializes. Is that implemented per spec,
> or is it tied up with the open CSSOM issues?
> 
> Regarding the threat of a formal objection, there doesn't appear to be
> any solution that would fully satisfy everyone, but I trust your
> judgment that this is the best option. Additionally, we should not
> pre-commit Blink to shipping parser changes, and accept the possibility
> that what we ship now is the final shape of the feature.
> 
> On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> Contact emails: se...@chromium.org ,
> futh...@chromium.org 
> Explainer: None
> 
> Specification: https://drafts.csswg.org/css-nesting
> 
> 
> Summary: Add the ability to nest CSS style rules inside other style
> rules,
> combining selectors from the outer with the inner rule for increasing
> modularity and maintainability of style sheets.
> 
> Blink component: Blink>CSS
> 
> TAG review: https://github.com/w3ctag/design-reviews/issues/791
> 
> 
> TAG review status: Pending
> 
> Risks: There is a threat of a formal objection in CSSWG.
> 
> Interoperability and Compatibility:
> 
> Gecko: Positive
> (https://github.com/mozilla/standards-positions/issues/695
> )
> WebKit: Positive
> (https://github.com/WebKit/standards-positions/issues/69
> )
> 
> Debuggability
> Nesting style rules will be a big change for editing and displaying
> style rules in the inspector:
> 
> - Showing displaying nested rules for matching declarations
> - Editing selectors
> - Inserting nested rules
> - etc...
> 
> Tracking issue for devtools support: https://crbug.com/1172985
> 
> Devtools says they're on track for shipping in M111.
> 
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux,
> Chrome OS, Android, and Android WebView)? Yes
> 
> Is this feature fully tested by web-platform-tests? Yes
> 
> Flag name: CSSNesting
> 
> Requires code in //chrome? False
> 
> Tracking bug: https://crbug.com/1095675 
> 
> Estimated milestones
> DevTrial on desktop     109
> DevTrial on Android     109
> Shipping                112
> 
> 
> Anticipated spec changes: See above.
> 
> Link to entry on the Chrome Platform Status:
> https://chromestatus.com/feature/5800613594529792
> 
> 
> Links to previous Intent discussions:
> Intent to prototype:
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com
>  
> 
> 
> -- 
> Software Engineer, Google Norway
> 
> -- 
> 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/Y8ph9gk50U2D92f3%40google.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
>