Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

Thank you for the reply!

To address the issues, I've added a comment based on the latest 
communication in this thread.
-  https://github.com/w3c/csswg-drafts/issues/7211#issuecomment-1132432496

Hope this helps to solve the issues.

2022년 5월 19일 목요일 오전 7시 50분 52초 UTC+9에 Chris Harrelson님이 작성:

> Hi Byungwoo,
>
> I think it would be better to resolve the referenced issues at the CSSWG, 
> including aspects Antti mentioned here, before shipping.
>
>
> On Wed, May 18, 2022 at 6:05 AM Byungwoo Lee  wrote:
>
>>
>> On 5/18/22 17:33, Antti Koivisto wrote:
>>
>>
>>
>> On Tuesday, May 17, 2022 at 9:19:03 AM UTC+3 bl...@igalia.com wrote:
>>
>>>
>>> On 5/17/22 03:17, Emilio Cobos Álvarez wrote:
>>>
>>> On 5/16/22 11:05, Byungwoo Lee wrote: 
>>>
>>> Anticipated spec changes 
>>>
>>> There are 4 open issues posted on the csswg draft. 
>>>
>>>   * Remove scope dependency from relative selectors definition: 
>>> https://github.com/w3c/csswg-drafts/issues/6399 
>>>   * Disallowing logical combination pseudo classes inside ':has()': 
>>> https://github.com/w3c/csswg-drafts/issues/6952 
>>>   * Disallowing ':scope' inside ':has()': 
>>> https://github.com/w3c/csswg-drafts/issues/7211 
>>>   * Disallowing ':host', ':host()', ':host-context()' inside ':has()': 
>>> https://github.com/w3c/csswg-drafts/issues/7212 
>>>
>>>
>>> It'd be great to get resolution on these issues before shipping, IMO. 
>>>
>>> In general, given how the usefulness of this feature relies on browser 
>>> engines having predictable performance (the feature is useless if WebKit or 
>>> Firefox get cases fast that Chrome gets slow or vice-versa), it'd be great 
>>> to document in the spec some of these limitations and the reasoning for 
>>> them. 
>>>
>>> All the above 4 issues are essentially related to the case of ':is()' 
>>> inside ':has()'.
>>>
>>> The dependency between the 4 issues can be summarized as follows:
>>>
>>>- To avoid increasing invalidation complexity, disallow ':is()' or 
>>>':where()' inside ':has()' (#6952) 
>>>   - ':scope' inside ':has()' has the same (or worse) problem as 
>>>   ':is()' inside ':has()', so disallow ':scope' inside ':has()' (#7211) 
>>>  - After ':scope' is disallowed inside ':has()', we can keep 
>>>  the current definition of absolutizing with ':scope' because 
>>> ':scope' will 
>>>  not be used explicitly inside the ':has()' (#6399) 
>>>  - ':host', ':host()', ':host-context()' is meaningless unless 
>>>  it is used with ':scope' inside ':has()' (#7212)
>>>  
>>>
>>> The ':is()' inside ':has()' case is the start of the 4 issues, and most 
>>> engines seems to agree to disallow the ':is()' inside ':has()' case now.
>>>
>>> If so, I think it would be OK to ship to Chrome with explicit 
>>> limitations for the above cases even if those issues are not yet addressed 
>>> in the spec. How do you think about this?
>>>
>> WebKit does not disallow :is() inside :has() and I don't see a particular 
>> reason to. While not very useful it does not increase complexity over 
>> :not() inside :has() (which is supported and people have found useful). The 
>> only current limitation with logical combinator pseudo-classes is 
>> disallowing :has() nested inside :has() (which increases complexity a lot 
>> without enabling anything useful).
>>
>>   antti
>>
>> I think I misunderstood that the option of disallowing ':is()' inside 
>> ':has()' is still alive. Also I overlooked that ':not()' inside ':has()' 
>> has the same problem as ':is()' inside ':has()'.
>>
>> I communicated with Antti about the above limitations, and we both agreed 
>> these:
>>
>>- Positive on disallowing explicit ':scope' inside ':has()' since 
>>':has()' has an implicit scope. 
>>- Positive on disallowing ':has()' inside ':has()' since it can 
>>increase complexity a lot. 
>>- Should allow ':is()'/':where()' inside ':has() since: 
>>   - we should consider ':is()', ':where()', ':not()' as a whole in 
>>   terms of complexity, 
>>   - those cases (especially ':not()') enables useful cases 
>>   - invalidation performance will not be great but also it will not 
>>   be different compared to some other worst cases 
>>   - both WebKit and Chrome haven't considered some invalidation 
>>   cases, (https://codepen.io/byung-woo/pen/vYdxPMa) but fixing the 
>>   bug will not be very complex or difficult.
>>   
>> Based on this consensus, I'm going to allow ':is()' and ':where()' inside 
>> ':has()' before shipping.
>>
>> The bug pointed at above will *not* be fixed before shipping.
>>
>> Since it is positive to disallow explicit ':scope' inside ':has()', I 
>> think disallowing ':host()' inside ':has()' is still reasonable.
>>
>> How about this?
>>
>>
>> Byungwoo.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving 

Re: [blink-dev] Intent to Prototype: User Agent Launch Type in PerformanceNavigationTiming

[Yoav Weiss]

Hey Ben! Thanks for working on this! This seems like an important dimension
to potentially split metrics on.

On Thu, May 19, 2022 at 10:36 PM 'Ben Mathwig' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> bemat...@microsoft.com
>
>
> Explainer
>
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PerformanceNavigationTiming%20for%20User%20Agent%20Launch/explainer.md
>
>
> Specification
>
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PerformanceNavigationTiming%20for%20User%20Agent%20Launch/explainer.md
>
>
> Summary
>
> Adds a new value for PerformanceNavigationTiming.type, 'useragent_launch',
> to help measure the cold start scenario during page load. This allows a web
> developer to measure the performance of their application code compared to
> the cost of browser initialization tasks. This is a pain point for pinned
> PWAs or WebView apps that will often require a cold start of the user agent.
>
>
>
>
> Blink component
>
> Blink>PerformanceAPIs>NavigationTiming
> 
>
>
> Motivation
>
> Despite the variety of performance measurements available through the
> current API, it's difficult to discern from the NavigationType whether the
> measurements reflect those of a regular navigation under normal browsing or
> of one where the browser is in a non-optimal performance state, such as a
> cold start. A browser launch is one of the most expensive performance
> scenarios commonly encountered in typical PWA and WebView patterns. Our
> proposal seeks to create a new value for the NavigationType enum to
> differentiate this condition from others in measurements of web application
> performance. Modifying the NavigationType to include state for a user agent
> launch (i.e. useragent_launch) will enable engineers to determine whether a
> given measurement is taken from a launch scenario, enabling greater
> differentiation of application performance from browser performance in
> scenarios where the browser engine is launched and terminated frequently.
> Examples include: Electron apps, system WebViews, or other application
> scenarios where the browser is relatively short-lived or commonly launched
> from a terminated state.
>
>
>
>
> Initial public proposal
>
>
> https://discourse.wicg.io/t/proposal-user-agent-launch-type-in-performancenavigationtiming/5875
>

Might be worthwhile to also file an issue on
https://github.com/w3c/navigation-timing/issues
With my WebPerfWG chair hat on, I'd love to have you over to discuss this :)


>
>
> TAG review
>
>
>
>
> TAG review status
>
> Pending
>
>
> Risks
>
>
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
>
> WebView application risks
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
>
>
>
>
> Debuggability
>
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
>
> Flag name
>
> MsUserAgentLaunchNavType
>
>
> Requires code in //chrome?
>
> False
>
>
> Estimated milestones
>
> M105
>
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5186950448283648
>
> --
> 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/DM6PR00MB0751A324F65D9544C2028ED09%40DM6PR00MB0751.namprd00.prod.outlook.com
> 
> .
>

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

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Dave Tapuska]

So how does this method work for iframes that have their visibility hidden?
Is it intended to work for that?


 


div's isVisible will always be true. Perhaps isVisible needs a caveat that
it only works for the current document. Oh that is what was debated here
.

dave.

On Thu, May 19, 2022 at 6:52 PM Mike Taylor  wrote:

> Given the CSSWG resolution in
> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>
> Thanks for addressing Mozilla's feedback.
>
> On 5/5/22 4:26 PM, Joey Arhar wrote:
>
> > Can you ask for signals?
>
> https://github.com/mozilla/standards-positions/issues/634
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>
> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>>
>>> Contact emails jar...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>>>
>>> Specification https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>>>
>>> Summary
>>>
>>> Element.isVisible() returns true if the element is visible, and false if
>>> it is not. It checks a variety of factors that would make an element
>>> invisible, including display:none, visibility, content-visibility, and
>>> opacity.
>>>
>>>
>>> Blink component Blink>DOM
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/734
>>>
>>> TAG review status Pending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature is not particularly contentious or complicated, but is
>>> mostly useful in the presence of content-visibility.
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>
>> Can you ask for signals?
>>
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Would be good to gather signals here as well.
>>
>>
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> This feature could be used in tandem with content-visibility or details
>>> elements. Usage of this API will not make it hard for Chrome to maintain
>>> good performance.
>>>
>>>
>>> Activation
>>>
>>> This feature is easy to feature detect and polyfill.
>>>
>>>
>>> Security
>>>
>>> I have no security risks/considerations for this feature.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> This does not deprecate or change any existing APIs and does not have
>>> any risk for WebView.
>>>
>>>
>>> Debuggability
>>>
>>> This feature does not need any new debugging features.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> Flag name --enable-blink-features=isVisible
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1309533
>>>
>>> Estimated milestones
>>>
>>> 103
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> https://github.com/w3c/csswg-drafts/issues/7232
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5163102852087808
>>>
>>> Links to previous Intent discussions Intent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%40mail.gmail.com
>>> 
>>>
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Mike Taylor]

Given the CSSWG resolution in 
https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343, 
LGTM1 to ship assuming we're not shipping `checkInert` with the rest.


Thanks for addressing Mozilla's feedback.

On 5/5/22 4:26 PM, Joey Arhar wrote:

> Can you ask for signals?

https://github.com/mozilla/standards-positions/issues/634
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html

On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  wrote:



On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:


Contact emails

jar...@chromium.org


Explainer


https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md


Specification

https://drafts.csswg.org/cssom-view/#dom-element-isvisible


Summary

Element.isVisible() returns true if the element is visible,
and false if it is not. It checks a variety of factors that
would make an element invisible, including display:none,
visibility, content-visibility, and opacity.



Blink component

Blink>DOM




TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility

This feature is not particularly contentious or complicated,
but is mostly useful in the presence of content-visibility.



Gecko: No signal

WebKit: No signal


Can you ask for signals?


Web developers: No signals


Would be good to gather signals here as well.


Other signals:


Ergonomics

This feature could be used in tandem with content-visibility
or details elements. Usage of this API will not make it hard
for Chrome to maintain good performance.



Activation

This feature is easy to feature detect and polyfill.



Security

I have no security risks/considerations for this feature.



WebView application risks

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

This does not deprecate or change any existing APIs and does
not have any risk for WebView.



Debuggability

This feature does not need any new debugging features.



Is this feature fully tested by web-platform-tests

?

Yes


Flag name

--enable-blink-features=isVisible


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

103



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for the feature
specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

https://github.com/w3c/csswg-drafts/issues/7232


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5163102852087808


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%40mail.gmail.com




This intent message was generated by Chrome Platform Status
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%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 

Re: [blink-dev] Intent to Experiment: Reverse Origin Trial for WebRTC's Plan B SDP semantics

[Eric Liao]

Hi,

Continue V Chang's Problem.
Our video system still uses Plan B SDP, and we find that if we use 
chrome(M89), the video still can work normally now
So, if we don't upgrade the browser, will it be affected after May 25th? 
It's very important for us, I am looking forward to your reply, thank you!

V Chang 在 2022年5月13日 星期五上午12:59:28 [UTC+8] 的信中寫道：

> Hi Henrik,
>
> Yes. We have an big issue on fixing the problem to run without this trial, 
> which will cause our end users not be able to make video call to call 
> center for banking service. 
> We are still working on fixing the problem. However, we cannot make it 
> before May 25th. Is there any alternative? Thanks!
>
>
> Henrik Boström 在 2022年5月12日 星期四下午2:26:43 [UTC+8] 的信中寫道：
>
>> UMAs show Plan B usage is down to 0.0473% and we already extended 
>> the deprecation trial by 6 months for those who did not notice the 1 year 
>> warning/canary exception prior to that. Because of this, support for Plan B 
>> including the Plan B deprecation trial flag was removed in M102 which is 
>> currently Beta and soon getting its Stable cut.
>>
>> Big issue? Are you not able to migrate in time?
>>
>> On Thu, 12 May 2022 at 04:47, V Chang  wrote:
>>
>>> [Urgent Support]
>>> Hi, 
>>> Is there any possibility to extend the Trial for RTCPeerConnection Plan 
>>> B SDP Semantics?
>>> We are helping our client on the call center video solution. However, we 
>>> have a big issue regarding this trial support end on May 25th 2022.  Please 
>>> advise. Thank you for your support in advance.
>>>
>>>
>>>
>>> Web Development 在 2021年12月17日 星期五上午12:22:55 [UTC+8] 的信中寫道：
>>>
 I registered for  RTCPeerConnection Plan B SDP Semantics   and 
 everything working fine in windows and android chrome browser.
 But  in android webView it showing Origin trial "UNKNOWN 
 ValidTokenNotProvided"
 Does it support in android system webview?

 On Friday, July 30, 2021 at 2:25:18 AM UTC+5:30 mike...@chromium.org 
 wrote:

> Hi Abhi,
>
> Assuming you're looking for the deprecation trial ("reverse origin 
> trial") for Plan B SDP semantics, 
> https://developer.chrome.com/origintrials/#/view_trial/3892235977954951169
>  
> should be the right link.
>
> (there's no visual differentiation between regular and deprecation 
> trials in the UI, but maybe that would be a nice feature to add)
>
> later,
> Mike
>
> On 7/29/21 3:44 AM, 'Abhi Shanmu' via blink-dev wrote:
>
> Hi, 
>
> I am unable to find reverse origin trial listed in this page for me to 
> register. 
> https://developer.chrome.com/origintrials/#/trials/active
> How can I register my domains for the reverse origin trial?
> Thanks,
> Abhi
> On Thursday, July 8, 2021 at 5:00:06 PM UTC+1 Yash Gogia wrote:
>
>> Hi,
>>
>> The guide that talks about origin trials, mentions that there is a 
>> built-in safeguard that automatically disables an experimental feature 
>> globally if its usage exceeds 0.5% of all Chrome page loads. 
>>
>> Source: 
>> https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#3-what-happens-if-a-large-site-such-as-a-google-service-starts-depending-on-an-experimental-feature
>>
>> I would like to understand if this applies to reverse origin trials 
>> as well. From chrome status, it looks like the usage is hovering around 
>> 0.2% already and I am sure many more websites would add the trial as the 
>> August date for Chrome 93 approaches. A confirmation that this automatic 
>> cutoff would not apply to the reverse origin trial would give us a lot 
>> more 
>> confidence.
>>
>> Thanks,
>> Yash 
>> On Friday, 5 March 2021 at 23:18:03 UTC+5:30 Joe Medley wrote:
>>
>>> Thank you!
>>>
>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Fri, Mar 5, 2021 at 6:47 AM Henrik Boström  
>>> wrote:
>>>
 OK, I filed https://www.chromestatus.com/feature/5823036655665152

 On Tuesday, March 2, 2021 at 3:45:06 PM UTC+1 Joe Medley wrote:

> To be clear, Chrome Status isn't extra. It's a tool for creating 
> intents and it tries to help you get everything needed for that. The 
> option 
> for Feature deprecation contains a stage for a reverse origin trial. 
>
> [image: image.png]
>
> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>  816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Tue, Mar 2, 2021 at 6:40 AM Joe Medley  
> wrote:
>
>> "Should I create an entry even for the Reverse Origin Trial?" 
>>
>> Yes, you 

[blink-dev] Intent to Prototype: User Agent Launch Type in PerformanceNavigationTiming

['Ben Mathwig' via blink-dev]

Contact emails
bemat...@microsoft.com


Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PerformanceNavigationTiming%20for%20User%20Agent%20Launch/explainer.md


Specification
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PerformanceNavigationTiming%20for%20User%20Agent%20Launch/explainer.md


Summary

Adds a new value for PerformanceNavigationTiming.type, 'useragent_launch', to 
help measure the cold start scenario during page load. This allows a web 
developer to measure the performance of their application code compared to the 
cost of browser initialization tasks. This is a pain point for pinned PWAs or 
WebView apps that will often require a cold start of the user agent.


Blink component
Blink>PerformanceAPIs>NavigationTiming


Motivation

Despite the variety of performance measurements available through the current 
API, it's difficult to discern from the NavigationType whether the measurements 
reflect those of a regular navigation under normal browsing or of one where the 
browser is in a non-optimal performance state, such as a cold start. A browser 
launch is one of the most expensive performance scenarios commonly encountered 
in typical PWA and WebView patterns. Our proposal seeks to create a new value 
for the NavigationType enum to differentiate this condition from others in 
measurements of web application performance. Modifying the NavigationType to 
include state for a user agent launch (i.e. useragent_launch) will enable 
engineers to determine whether a given measurement is taken from a launch 
scenario, enabling greater differentiation of application performance from 
browser performance in scenarios where the browser engine is launched and 
terminated frequently. Examples include: Electron apps, system WebViews, or 
other application scenarios where the browser is relatively short-lived or 
commonly launched from a terminated state.


Initial public proposal
https://discourse.wicg.io/t/proposal-user-agent-launch-type-in-performancenavigationtiming/5875


TAG review



TAG review status
Pending


Risks



Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:


WebView application risks

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



Debuggability



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


Flag name
MsUserAgentLaunchNavType


Requires code in //chrome?
False


Estimated milestones

M105



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

-- 
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/DM6PR00MB0751A324F65D9544C2028ED09%40DM6PR00MB0751.namprd00.prod.outlook.com.

[blink-dev] Intent to Ship: CSS object-view-box

[Khushal Sagar]

Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org,
vmp...@chromium.org

Explainerhttps://github.com/w3c/csswg-drafts/issues/7058

Specificationhttps://drafts.csswg.org/css-images-4/#the-object-view-box

Summary

object-view-box allows the author to specify a subset within an image that
should draw within the content box of the target replaced element. This
enables an author to create an image with a custom glow or shadow applied,
with proper ink-overflow behavior like a CSS shadow would have.

Blink componentBlink


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

TAG review statusPending

Risks

Interoperability and Compatibility


Gecko: Worth prototyping (
https://github.com/mozilla/standards-positions/issues/626)

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-March/032166.html)

Web developers: Positive
This property is a pre-requisite for Shared Element Transitions () which
has positive feedback from developers (source
).
Multiple
customers who are excited about SET need this feature to achieve their
desired UX, since their designs have visual overflows such as shadows.

Other signals:

WebView application risks

None



Debuggability

The property can be debugged in the devtools style panel similar to other
CSS properties.


Is this feature fully tested by web-platform-tests

?Yes

Flag nameCSSObjectViewBox

Requires code in //chrome?False

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

Estimated milestones

M104

Anticipated spec changesNone

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz11QzapF4BEX_QTu2FKsT2CEhphkyq%2BnorFgWA_G4qQw%40mail.gmail.com



This intent message was generated by Chrome Platform Status
.

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

[blink-dev] Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

Contact emails

victor...@chromium.org, abe...@chromium.org

Explainer


https://github.com/Tanych/accept-language
Specification

Variants header:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

Summary

Support the HTTP Variants header and implement the reduction of information
that could be used for fingerprinting in the Accept-Language header, so
that Chrome only sends the user’s most preferred language in the
Accept-Language header on the initial request.
Blink component

Privacy>Fingerprinting


Motivation


The Accept-Language header is a source of passive fingerprinting
information about users, as it can contain a high degree of entropy,
particularly if the user has many accepted languages.

Chrome (and other browsers) send a full list of the user's accepted
languages on every HTTP request via the Accept-Language header. While some
sites use this information for content negotiation, servers can also
passively capture this information without the user's awareness, to
fingerprint a user.

We propose to only send a single language—one of the user’s preferred
languages determined by the language negotiation process—in the
Accept-Language request header by default. Here’s what that would look like
when a user tries to access https://example.com:

Get / HTTP/1.1

Host: example.com

Accept-Language: en

HTTP/1.1 200 OK

Content-Language: en

Vary: Accept-Language

Variants: Accept-Language=(en)

As the response shows, in addition to the Content-Language in the response
header, sites will respond with a Variants

header (support for which will be prototyped as part of this intent), the
value of which includes all the languages the site supports. Browsers can
use the Variants header to do language negotiation if sites offer a page in
a language that doesn’t match the user's preferred languages. Initial
public proposal

https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835



TAG review

To be filed.

RisksInteroperability and Compatibility

We are reducing the number of languages sent in the Accept-Language header
to protect user privacy. The main source of risk is that sites rely on all
or part of a user’s preferred languages instead of the most preferred
language. We feel it’s important to minimize the breakage of the features
depending on Accept-Language as much as possible, to maintain stability of
the web ecosystem. To mitigate the risk of this change, we intend to
gradually roll it out via Finch configuration and keep monitoring health
metrics and bug reports from the community.

Gecko: No signals

WebKit: No signals

Web developers:  See the explainer for details.
Debuggability

No special DevTools support needed.

Is this feature fully tested by web-platform-tests

?

It will be.

Flag name

reduce-accept-language


Requires code in //chrome?

False

Tracking bug

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


*Launch bug*
https://bugs.chromium.org/p/chromium/issues/detail?id=1307484

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


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

Re: [blink-dev] Intent to Ship: WebGL canvas color management

[Mike Taylor]

LGTM3

On 5/19/22 10:08 AM, Yoav Weiss wrote:

LGTM2

On Thursday, May 19, 2022 at 1:41:32 AM UTC+2 Chris Harrelson wrote:

I've updated bit.ly/blink-signals  to
include an exception for Khronos (see the document for details).

Thanks for the developer signal.

LGTM1 for this intent!

On Wed, May 18, 2022 at 4:19 PM Chris Harrelson
 wrote:



On Wed, May 18, 2022 at 4:18 PM Chris Harrelson
 wrote:



On Wed, May 18, 2022 at 4:04 PM Ken Russell
 wrote:

On Wed, May 18, 2022 at 3:40 PM Chris Harrelson
 wrote:

Hi, comments below.

On Wed, May 18, 2022 at 11:48 AM Ken Russell
 wrote:


On Tue, May 17, 2022 at 3:40 PM
'Christopher Cameron' via blink-dev
 wrote:



TAG review status

N/A. Canvas 2D color managment API
already TAG reviewed at

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




Should this intent reuse issue 646 then? Are the
considerations and API almost exactly the same as
in 2D canvas? Another option is to comment on that
issue describing the WebGL variant of the same
feature, and calling out the notable differences
the TAG needs to be aware of to provide useful
feedback.

This specification change was
developed in Khronos and followed
the processes there.


Risks



Interoperability and
Compatibility



Gecko: Positive Developed in close
collaboration with Mozilla, spec
changes reviewed by Mozilla.

WebKit: Positive Discussed in
ColorWeb CG with WebKit
representatives


Please file for official signals. Participating in
discussions is not the same as officially supporting.


I'd like to respectfully point out that this API was
agreed upon by all major browser implementers in
Khronos' WebGL working group, whose processes have
been well established over the last decade. The WebGL
working group owns the responsibility for evolving
this portion of this web API, and the requirement in
Blink's processes to fetch signals is causing
duplicate work to be done in this context.

I would like to respectfully request that Blink's
processes be changed to not require implementation
signals for WebGL specification changes. Any such
changes are already only made with full agreement
among Gecko, WebKit and Blink engineers.


Got it, ok. We already have an exception in two cases,
let's work together on adding it to bit.ly/blink-intents
.


...make that bit.ly/blink-signals .



Web developers: Strongly positive


Could you give examples of developer support?


Not to speak for Chris Cameron, but this support was
requested, with urgency, by Adobe.

-Ken

-- 
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/CAMYvS2dk0%2B1MM8pG6kfLEVQSx_yNEoh6-cF80mmOuv_JenxQeA%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 

Re: [blink-dev] Intent to Ship: WebGL canvas color management

[Yoav Weiss]

LGTM2

On Thursday, May 19, 2022 at 1:41:32 AM UTC+2 Chris Harrelson wrote:

> I've updated bit.ly/blink-signals to include an exception for Khronos 
> (see the document for details).
>
> Thanks for the developer signal.
>
> LGTM1 for this intent!
>
> On Wed, May 18, 2022 at 4:19 PM Chris Harrelson  
> wrote:
>
>>
>>
>> On Wed, May 18, 2022 at 4:18 PM Chris Harrelson  
>> wrote:
>>
>>>
>>>
>>> On Wed, May 18, 2022 at 4:04 PM Ken Russell  wrote:
>>>
 On Wed, May 18, 2022 at 3:40 PM Chris Harrelson  
 wrote:

> Hi, comments below.
>
> On Wed, May 18, 2022 at 11:48 AM Ken Russell  wrote:
>
>>
 On Tue, May 17, 2022 at 3:40 PM 'Christopher Cameron' via blink-dev 
  wrote:

>
> TAG review status
> N/A. Canvas 2D color managment API already TAG reviewed at
> https://github.com/w3ctag/design-reviews/issues/646
>

> Should this intent reuse issue 646 then? Are the considerations and 
> API almost exactly the same as in 2D canvas? Another option is to comment 
> on that issue describing the WebGL variant of the same feature, and 
> calling 
> out the notable differences the TAG needs to be aware of to provide 
> useful 
> feedback.
>  
>
>> This specification change was developed in Khronos and followed the 
> processes there.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Positive Developed in close collaboration with Mozilla, 
> spec changes reviewed by Mozilla.
>
> WebKit: Positive Discussed in ColorWeb CG with WebKit 
> representatives
>

> Please file for official signals. Participating in discussions is not 
> the same as officially supporting.
>

 I'd like to respectfully point out that this API was agreed upon by all 
 major browser implementers in Khronos' WebGL working group, whose 
 processes 
 have been well established over the last decade. The WebGL working group 
 owns the responsibility for evolving this portion of this web API, and the 
 requirement in Blink's processes to fetch signals is causing duplicate 
 work 
 to be done in this context.

 I would like to respectfully request that Blink's processes be changed 
 to not require implementation signals for WebGL specification changes. Any 
 such changes are already only made with full agreement among Gecko, WebKit 
 and Blink engineers.

>>>
>>> Got it, ok. We already have an exception in two cases, let's work 
>>> together on adding it to bit.ly/blink-intents.
>>>
>>
>> ...make that bit.ly/blink-signals.
>>
>>>  
>>>


 Web developers: Strongly positive
>

> Could you give examples of developer support?
>

 Not to speak for Chris Cameron, but this support was requested, with 
 urgency, by Adobe.

 -Ken

 -- 
 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/CAMYvS2dk0%2B1MM8pG6kfLEVQSx_yNEoh6-cF80mmOuv_JenxQeA%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/dc570756-2c4d-49f0-8a4a-05b11fd235e3n%40chromium.org.

Re: [blink-dev] Re: Intent to Deprecate and Remove: U2F API (Cryptotoken)

[Mike West]

I think that's what Martin's email suggests ("We would still like to close
new trial registrations on July 26, and grant renewals beyond July 26 only
to existing participants that contact us directly."). Assuming that's the
case, a two milestone extension doesn't seem overly burdensome from a
burn-in perspective.

If y'all can communicate that deadline to your partners in a way that they
can accept, this extension LGTM.

-mike


On Thu, May 19, 2022 at 1:47 PM Yoav Weiss  wrote:

> Is it possible to keep the trial alive for 2 more milestones, but disable
> new registrations?
>
> On Thu, May 19, 2022 at 1:21 AM Martin Kreichgauer 
> wrote:
>
>> Greetings blink-dev,
>>
>> I would like to request a second extension of the U2FSecurityKeyAPI
>> deprecation trial. We are continuously gathering direct user feedback about
>> this deprecation, and virtually all trial participants we have been in
>> contact with have either migrated off of U2F already or are expecting to do
>> so ahead of the current July 26 deadline. However, one enterprise user with
>> a very sizable security key deployment across its workforce has told us
>> that they might not be able to fully migrate a number of stragglers by that
>> time, and asked whether we could extend the deadline by 8 weeks in order to
>> minimize disruptions for them.
>>
>> We're therefore asking to push back removal of the U2F API by two
>> milestones (M106 instead M104), and extend the deprecation trial until
>> September 20, 2022. We would still like to close new trial registrations on
>> July 26, and grant renewals beyond July 26 only to existing participants
>> that contact us directly.
>>
>> Since the upcoming removal of extensions manifest V2 from Chrome presents
>> a hard technical deadline for removing Cryptotoken, further extensions of
>> this trial would be extremely unlikely.
>>
>> Cheers,
>> Martin
>>
>> On Thursday, September 23, 2021 at 11:50:12 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> Thanks for clarifying!
>>>
>>> On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer 
>>> wrote:
>>>
 Thanks! Just to be clear, the deprecation trial is beginning with M95,
 but it would only be *required* by M98 when we disable the U2F API by
 default. M104 is where we plan to delete the API, so M103 would be the last
 release where the deprecation trial is functional.

 On Thu, Sep 23, 2021 at 5:18 AM Yoav Weiss 
 wrote:

> So IIUC, the deprecation trial would run from M98-M104. That seems
> like a reasonable time period to give to folks and enable them to adjust.
> Still LGTM.
>
> On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Dear blink-dev,
>>
>> I wanted to provide an update on our progress with the U2F API
>> deprecation effort and request a short extension for removal of the API 
>> and
>> the end date of the Reverse Origin Trial.
>>
>> First, the changes originally announced for Chrome 94 are now
>> scheduled to ship instead with Chrome 95. These changes include gating of
>> U2F API requests behind a permission prompt, deprecation warnings logged 
>> to
>> the developer console, and  a Reverse Origin Trial
>> 
>> .
>>
>> We still plan to disable the U2F API by default with Chrome 98.
>>
>> We also have been in close contact about this deprecation with
>> partners who still rely on the U2F API. In some of these conversations,
>> partners asked us to allow a little more time for them to migrate their
>> websites to the WebAuthn. We therefore would like to push back removal of
>> the U2F API to Chrome 104, and to extend the Reverse Origin Trial to the
>> same time period.
>>
>> Thanks,
>> Martin
>>
>>
>> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer
>> wrote:
>>
>>> Primary eng (and PM) emails
>>>
>>> mart...@google.com, a...@chromium.org
>>>
>>> Summary
>>>
>>> We want to deprecate and remove the legacy U2F API for interacting
>>> with security keys. (But not U2F security keys themselves, which will
>>> continue to work.)
>>>
>>> Affected sites should migrate to the Web Authentication API
>>> (WebAuthn). Credentials that were originally registered via the U2F API 
>>> can
>>> be challenged via WebAuthn. USB security keys that are supported by the 
>>> U2F
>>> API are also supported by the WebAuthn API.
>>>
>>> Motivation
>>>
>>> U2F is Chrome’s original security key API. It allows sites to
>>> register public key credentials on USB security keys and challenge them 
>>> for
>>> building phishing-resistant two-factor authentication systems. U2F never
>>> became an Open Web standard and was subsumed by WebAuthn (launched
>>> in M67 

Re: [blink-dev] Re: Intent to Deprecate and Remove: U2F API (Cryptotoken)

[Yoav Weiss]

Is it possible to keep the trial alive for 2 more milestones, but disable
new registrations?

On Thu, May 19, 2022 at 1:21 AM Martin Kreichgauer 
wrote:

> Greetings blink-dev,
>
> I would like to request a second extension of the U2FSecurityKeyAPI
> deprecation trial. We are continuously gathering direct user feedback about
> this deprecation, and virtually all trial participants we have been in
> contact with have either migrated off of U2F already or are expecting to do
> so ahead of the current July 26 deadline. However, one enterprise user with
> a very sizable security key deployment across its workforce has told us
> that they might not be able to fully migrate a number of stragglers by that
> time, and asked whether we could extend the deadline by 8 weeks in order to
> minimize disruptions for them.
>
> We're therefore asking to push back removal of the U2F API by two
> milestones (M106 instead M104), and extend the deprecation trial until
> September 20, 2022. We would still like to close new trial registrations on
> July 26, and grant renewals beyond July 26 only to existing participants
> that contact us directly.
>
> Since the upcoming removal of extensions manifest V2 from Chrome presents
> a hard technical deadline for removing Cryptotoken, further extensions of
> this trial would be extremely unlikely.
>
> Cheers,
> Martin
>
> On Thursday, September 23, 2021 at 11:50:12 AM UTC-7 yoav...@chromium.org
> wrote:
>
>> Thanks for clarifying!
>>
>> On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer 
>> wrote:
>>
>>> Thanks! Just to be clear, the deprecation trial is beginning with M95,
>>> but it would only be *required* by M98 when we disable the U2F API by
>>> default. M104 is where we plan to delete the API, so M103 would be the last
>>> release where the deprecation trial is functional.
>>>
>>> On Thu, Sep 23, 2021 at 5:18 AM Yoav Weiss  wrote:
>>>
 So IIUC, the deprecation trial would run from M98-M104. That seems like
 a reasonable time period to give to folks and enable them to adjust.
 Still LGTM.

 On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
 blin...@chromium.org> wrote:

> Dear blink-dev,
>
> I wanted to provide an update on our progress with the U2F API
> deprecation effort and request a short extension for removal of the API 
> and
> the end date of the Reverse Origin Trial.
>
> First, the changes originally announced for Chrome 94 are now
> scheduled to ship instead with Chrome 95. These changes include gating of
> U2F API requests behind a permission prompt, deprecation warnings logged 
> to
> the developer console, and  a Reverse Origin Trial
> 
> .
>
> We still plan to disable the U2F API by default with Chrome 98.
>
> We also have been in close contact about this deprecation with
> partners who still rely on the U2F API. In some of these conversations,
> partners asked us to allow a little more time for them to migrate their
> websites to the WebAuthn. We therefore would like to push back removal of
> the U2F API to Chrome 104, and to extend the Reverse Origin Trial to the
> same time period.
>
> Thanks,
> Martin
>
>
> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote:
>
>> Primary eng (and PM) emails
>>
>> mart...@google.com, a...@chromium.org
>>
>> Summary
>>
>> We want to deprecate and remove the legacy U2F API for interacting
>> with security keys. (But not U2F security keys themselves, which will
>> continue to work.)
>>
>> Affected sites should migrate to the Web Authentication API
>> (WebAuthn). Credentials that were originally registered via the U2F API 
>> can
>> be challenged via WebAuthn. USB security keys that are supported by the 
>> U2F
>> API are also supported by the WebAuthn API.
>>
>> Motivation
>>
>> U2F is Chrome’s original security key API. It allows sites to
>> register public key credentials on USB security keys and challenge them 
>> for
>> building phishing-resistant two-factor authentication systems. U2F never
>> became an Open Web standard and was subsumed by WebAuthn (launched
>> in M67 ).
>> Chrome never directly supported the FIDO U2F JavaScript API in Blink, but
>> rather shipped a component extension called cryptotoken, which exposes an
>> equivalent chrome.runtime.sendMessage API. U2F and Cryptotoken are firmly
>> in maintenance mode and we encouraged sites to migrate to WebAuthn
>> 
>> two years ago.
>>
>> U2F’s continued existence presents several issues:
>>
>>-
>>
>>Cryptotoken requests 

Re: [blink-dev] Intent to Prototype: HTTP/3 protocol upgrade for HTTPS DNS records with h3 alpn parameter

[Yoav Weiss]

That's great! Thanks for working on this!!

On Thu, May 19, 2022 at 8:33 AM Tsuyoshi Horo  wrote:

> Contact emails
>
> h...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https
>
> Summary
>
> HTTPS DNS resource records can provide information about supported
> protocols such as HTTP/3 with "alpn" parameter. If Chrome receives a HTTPS
> DNS record indicating HTTP/3 support, Chrome will connect to the server
> using the HTTP/3 protocol.
>
>
> Blink component
>
> Internals>Network>DNS
> 
>
> Motivation
>
> Currently Chrome can use the HTTP/3 protocol only after receiving an
> Alt-Svc header from the server using a non-HTTP/3 protocol.  With this new
> feature, Chrome can connect to the server using HTTP/3 protocol without
> receiving the Alt-Svc header. This can reduce 1 RTT of handshaking of TCP
> which is required for non-HTTP/3 protocol while connecting to the server.
>
>
> Initial public proposal
>
> https://github.com/MikeBishop/dns-alt-svc
>
> TAG review
>
> Not applicable. No direct changes to web platform APIs. Change is to the
> underlying DNS infrastructure.
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Shipped/Shipping (
> https://www.mozilla.org/en-US/firefox/92.0/releasenotes)
>
> WebKit: In development (
> https://mailarchive.ietf.org/arch/msg/dnsop/eeP4H9fli712JPWnEMvDg1sLEfg)
> Implemented behind "HTTP/3" Experimental Features
>
> Web developers: Strongly positive (
> https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns
> )
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> No.
>
>
> Debuggability
>
> This feature will be debuggable using chrome://net-export/ and
> https://netlog-viewer.appspot.com/.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No. We need an HTTP/3 server and a DNS server to test the feature, and we
> have neither in WPT.
>
> Flag name
>
> TBD
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1317943
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5154357283651584
>
> 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/CADk0S-WpP9TTnd__MA2Dktz%3DumjQJJAAPsmWcZn0Or5Ws31Ltw%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/CAL5BFfU%2BUjS0cD2%3D%3Dd-vrJCA6d9J9mzcMOr6jgtN1EZPO9qhjA%40mail.gmail.com.

[blink-dev] Intent to Prototype: HTTP/3 protocol upgrade for HTTPS DNS records with h3 alpn parameter

[Tsuyoshi Horo]

Contact emails

h...@chromium.org

Explainer

None

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https

Summary

HTTPS DNS resource records can provide information about supported
protocols such as HTTP/3 with "alpn" parameter. If Chrome receives a HTTPS
DNS record indicating HTTP/3 support, Chrome will connect to the server
using the HTTP/3 protocol.


Blink component

Internals>Network>DNS


Motivation

Currently Chrome can use the HTTP/3 protocol only after receiving an
Alt-Svc header from the server using a non-HTTP/3 protocol.  With this new
feature, Chrome can connect to the server using HTTP/3 protocol without
receiving the Alt-Svc header. This can reduce 1 RTT of handshaking of TCP
which is required for non-HTTP/3 protocol while connecting to the server.


Initial public proposal

https://github.com/MikeBishop/dns-alt-svc

TAG review

Not applicable. No direct changes to web platform APIs. Change is to the
underlying DNS infrastructure.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

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

WebKit: In development (
https://mailarchive.ietf.org/arch/msg/dnsop/eeP4H9fli712JPWnEMvDg1sLEfg)
Implemented behind "HTTP/3" Experimental Features

Web developers: Strongly positive (
https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns
)

Other signals:

WebView application risks

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

No.


Debuggability

This feature will be debuggable using chrome://net-export/ and
https://netlog-viewer.appspot.com/.


Is this feature fully tested by web-platform-tests

?

No. We need an HTTP/3 server and a DNS server to test the feature, and we
have neither in WPT.

Flag name

TBD

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1317943

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5154357283651584

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/CADk0S-WpP9TTnd__MA2Dktz%3DumjQJJAAPsmWcZn0Or5Ws31Ltw%40mail.gmail.com.