Re: [blink-dev] Intent to Ship: baseline-source

[TAMURA, Kent]

LGTM3.

I don't think the issue of vertical-align shorthand isn't a blocker.

On Thu, Jan 12, 2023 at 2:20 AM Rick Byers  wrote:

> On Wed, Jan 11, 2023 at 12:13 PM Ian Kilpatrick 
> wrote:
>
>>
>>
>> On Wed, Jan 11, 2023 at 8:58 AM Rick Byers  wrote:
>>
>>> On Wed, Jan 11, 2023 at 11:14 AM Ian Kilpatrick 
>>> wrote:
>>>

 On Wed, Jan 11, 2023 at 7:28 AM Rick Byers  wrote:

> Given the lack of signals from other implementers, any other
> indication on the maturity of the spec? I searched for open bugs and found
> only this one  which
> sounds fairly minor to me - likely resolvable without major compat
> implications.
>

 We got a positive signal from the Firefox folks here:
 https://github.com/mozilla/standards-positions/issues/727

>>>
>>> Yep, that's great. But what I was asking was that you're not aware of
>>> any outstanding design debates or bugs which might cause future compat
>>> issues, right?
>>>
>>
>> Oh sorry - missed that part of your question. No not particularly - the
>> open issue which we raised (
>> https://github.com/w3c/csswg-drafts/issues/8214) is surrounding a
>> clarification to the spec for a somewhat edge case. We've implemented what
>> we think is the best behaviour but wanted to double check with the broader
>> group. We'll be able to change this specific behaviour safely after we ship
>> if needed as it is a relative edge case.
>>
>> (The case in question is that the "inline-block" baseline algorithm
>> contains a lot of quirks and counter intuitive behaviour, e.g. tables get
>> skipped in some cases, and for things with "overflow: hidden" the baseline
>> is ignored, the behavour we've implemented uses the baseline behaviour from
>> flex/grid - see
>> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11177 for
>> an explicit example).
>>
>
> Makes sense, thanks, LGTM2.
>
>
>>> Regardless, I agree this is quite minor, seems reasonable to ship absent
> any known objections or significant outstanding issues.
>

 Yeah this is a very minor feature all things considered.


>
> Thanks,
>Rick
>
> On Tue, Jan 10, 2023 at 11:13 PM 一丝  wrote:
>
>> We can use
>> https://w3c.github.io/csswg-drafts/css-inline-3/#baseline-source
>>
>> 以上
>> 一丝
>>
>>
>> Ian Kilpatrick  于2023年1月11日周三 08:19写道：
>>
>>>
>>>
>>> On Tue, Jan 10, 2023 at 4:48 AM Yoav Weiss 
>>> wrote:
>>>


 On Mon, Jan 9, 2023 at 7:24 PM Ian Kilpatrick <
 ikilpatr...@chromium.org> wrote:

> Contact emailsikilpatr...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.csswg.org/css-inline-3/#baseline-source
>

 link seems down :/

>>>
>>>  Yeah the csswg server is a little sporadic at the moment. Up at the
>>> moment.
>>>

>
> Summary
>
> The "baseline-source" properties allows web developers to specify
> if an inline-level box should use the "first" or "last" baseline for
> alignment within an linebox. Today the default behaviour is confusing 
> for
> web developers. Consider: test line1line2 test line1line2 The "inline-block" will align to 
> the
> last baseline, and the "inline-flex" will align to the first baseline.
> "baseline-source: auto" is the existing (confusing) behaviour. Web
> developers can specify "baseline-source: first" or "baseline-source: 
> last"
> to directly determine how they want these boxes to align within a 
> line-box.
>
>
> Blink componentBlink>Layout>Inline
> 
>
> TAG reviewHappy to file one if desired.
>
 Will we be the first to ship this? If so, I believe one is
 required.

>>>
>>> Done - It's a very small improvement to an existing API set so
>>> unclear but filed one anyway.
>>> https://github.com/w3ctag/design-reviews/issues/801
>>>
>>>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
> https://bugzilla.mozilla.org/show_bug.cgi?id=1805273
>
> *WebKit*: No signal https://bugs.webkit.org/show_bug.cgi?id=249094
>

 Can you file for https://bit.ly/blink-signals?


>>>
>>> Done
>>> https://github.com/mozilla/standards-positions/issues/727
>>> https://github.com/WebKit/standards-positions/issues/118
>>>

>
> *Web developers*: Positive from my discussions. This has been a
> 

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

[Joey Arhar]

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 Status
https://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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVyLctXm%2B7UNenRyKsRNpY%2BrxWF_4LuYn6rJdYbu_bQQ%40mail.gmail.com.

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi Torne,
Thanks for the clarification. Sorry, I misread that we are going to ship
the UA-CH in android webview.
I agree we need to meet to discuss the plan for UA-CH and UA reduction on
Webview sometime in the near future.

Best,
Victor

On Wed, Jan 18, 2023 at 12:49 PM Torne (Richard Coles) 
wrote:

> On Wed, 18 Jan 2023 at 12:29, Victor Tan  wrote:
>
>> Hi Torne,
>> Thanks for your information. We understand your concern.
>> UA-CH in WebView will be shipping in Chrome M110
>> .
>>
>
> UA-CH is entirely disabled in WebView at present and shipping CH
> persistence as covered in that bug is *not* supposed to be enabling it,
> because we haven't yet done any of the design work to figure out what the
> APIs exposed to apps for controlling it should be, how it should interact
> with custom UA strings, whether there should be a way to distinguish
> WebView from Chrome in the UA-CH values and whether that needs to be
> standardized, etc.
>
> The referenced bug *should* just be about making all the non-UA client
> hints work properly in WebView (currently they're mostly useless as
> Accept-CH isn't being persisted across requests).
>
> UA reduction in WebView is also in our future plan list, we will see how
>> the UA-CH works in Webview.
>>
>
> We need a plan for how to ship UA-CH for WebView and what it should
> include first :)
>
>
>> For now, I don't think what we did in this phase on Android will impact
>> Webview much since we already did the UA reduction phase 4 on
>> Android platform.
>> For the future plan, we will work out a plan (if UA-CH works as expected)
>> to do the UA reduction in Webview to match what we did in Chrome.
>> Also, we are glad to discuss with Webview for all other possibilities and
>> impacts.  Thanks.
>>
>
> Understood, but if we ultimately want to change WebView's UA in a way that
> doesn't pass the current CDD/CTS requirements then the work to change those
> requirements needs to happen at *least* an entire Android release ahead of
> time, and ideally would have been done several years ago if we want it to
> have the most impact :(
>
>
>>
>> Best,
>> Victor
>>
>> On Wed, Jan 18, 2023 at 12:20 PM Rick Byers  wrote:
>>
>>> Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
>>> having a unified plan for WebView. I assume the format (eg. not omitting
>>> the device model completely) is being driven by web compat concerns which
>>> would matter for WebView as well, right?
>>>
>>
> It's not really directly about web compat concerns. See
> https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/web-platform-compatibility.md#Android_s-Compatibility-Test-Suite-tests-some-WebView-behaviours
> for more on this, but briefly: CTS/CDD are about *application*
> compatibility - they are requirements the Android OS must satisfy to be
> considered compatible with existing Android applications. Anything that's
> tested by CTS is something that app developers are expected to be able to
> rely on.
>
> It's likely that *most* consideration of WebView's UA string is happening
> on the web side (by JS or by server side logic), but the UA string is also
> exposed directly to apps via Java APIs and so the actual code of the app
> might *also* be parsing this information (and the Java API currently does
> *not* provide any way to access client hints, other than loading a page and
> injecting JS into it to access the JS APIs). Web content that's designed
> only to be loaded in a specific WebView application might potentially rely
> much more heavily on the specific format of the UA string than content
> that's intended to be used by multiple browsers, and may not ever be loaded
> in Chrome or ever show up in web crawler data.
>
>
>> Do we have any data on the web compatibility of removing the model string
>>> entirely?
>>>
>>
> The model string is currently omitted automatically on prerelease versions
> of the Android OS as a basic precaution to not leak model names of
> unreleased devices. This doesn't get a lot of production usage, but we do
> regularly get bugs filed against us every single android release by device
> vendors or other developers complaining that the useragent is "wrong" (even
> though omitting the model entirely has been explicitly allowed by CTS for
> quite a few releases now). We've also previously discussed removing the
> model with various parties who had very strong objections on the grounds
> that they use it for targeting downloads/support info/etc to particular
> devices; if this information instead becomes available in UA-CH that may be
> an acceptable migration path but this will likely be some amount of new
> impact to developers/sites who are *not* affected by the changes to
> Chrome's UA (because their content is only loaded inside WebViews).
>
> So, I don't have any concrete data on the impact and we've not run any
> experiments here, but it's likely to involve at least some new 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Mike Taylor]

Hi Torne,

Yep, I agree we should come up with a plan to understand the WebView 
context and how we can make progress on removing passive entropy in the 
future.


thanks,
Mike

On 1/18/23 12:05 PM, Torne (Richard Coles) wrote:
I have some concerns that we won't be able to use this format for 
Android WebView. I realise we're not currently shipping UA reduction 
for WebView, but AFAIK we are still hoping to do so at some point in 
the future.


WebView's UA format is mandated by Android's CTS compatibility tests. 
I relaxed the test criteria some time ago to allow the device model 
and Android build ID to be omitted (though WebView currently still 
includes this information), but the test currently requires these 
fields to either be entirely absent, or to exactly match the 
underlying OS properties. It also does not allow the less-granular OS 
version to be omitted or spoofed.


It'd be good to have a long term plan for what we're going to do with 
the UA and with UA-CH in WebView that matches Chrome as closely as 
possible.


On Tue, 17 Jan 2023 at 11:02, Victor Tan  wrote:


Contact emails

victor...@chromium.org ,
miketa...@chromium.org 


Explainer


https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity




Specification

https://www.chromium.org/updates/ua-reduction
is the closest
thing that specifies Chrome’s UA Reduction plans today. As these
changes land in Chromium and ship to 100% stable, the Compat
Standard will be updated in the
UA String section
, like
we did for the Phase 4 and plan to do for Phase 5 changes.


Summary

As previously detailed on the Chromium Blog

,
we intend to proceed with Phase 6 of the User-Agent Reduction plan
.
In Phase 6, we change the deviceModeltoken to “K” and change the
androidVersiontoken to a static “10” string in Android User-Agent
string. The navigator.platformwill be a “Linux armv81” constant on
the Android platform.


Blink component

Blink>Network>ClientHints


TAG review

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



TAG review status

Closed satisfied with concerns.


Risks


Interoperability and Compatibility

Any time you modify the User-Agent string there is a risk of
breaking existing patterns, like some content somewhere depending
on the previous format.


We do not expect interoperability risks, as each browser sends its
own User-Agent string format. However there is a risk that - on
the Android platform - content may rely  on User-Agents to parse
deviceModel and androidVersion information. To mitigate the risk
of this change, we intend to slowly roll out the format via Finch
on the Android platform and observe health metrics and bug
reports. See timeline below on our slow roll out plan. This gives
us the option to roll this back for the Android platform if major
issues arise.


Displaying a static androidVersion and a deviceModel token for
Android clients will not create a problem syntactically. But the
web can get pretty weird in ways we don't anticipate. For example,
sites can rely on the deviceModel in the User-Agent string to
determine whether the device is a mobile, laptop or desktop.
Currently, we change the deviceModel to a static string, sites
need to use client hints as the alternative to determine the right
behavior.  Hence the slow roll-out and incremental path towards
User-Agent Reduction.


Here is our proposed rollout plan in Chrome Stable channel
(Canary/Dev/Beta has been enabled 50%), with the understanding
that if we discover concerning breakage or regressions via health
metrics or bug reports we will pause the rollout or roll back the
feature entirely (and update this thread if so):


Stage



Duration



Date

Stable 1% (M110+)



M110 stable release is shipping to 100% (a best guess)



Feb 14, 2023

Stable 10% (M110/M111)



~4 weeks after previous stage



Mar 14, 2023

Stable 50%

(M110/M111)



~2 weeks



Mar 28, 2023

TOT Default (M114)



~2 weeks after previous stage



Apr 11, 2023

Stable 100% (M110=>M114)



~ Same business day as 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Torne (Richard Coles)]

On Wed, 18 Jan 2023 at 12:29, Victor Tan  wrote:

> Hi Torne,
> Thanks for your information. We understand your concern.
> UA-CH in WebView will be shipping in Chrome M110
> .
>

UA-CH is entirely disabled in WebView at present and shipping CH
persistence as covered in that bug is *not* supposed to be enabling it,
because we haven't yet done any of the design work to figure out what the
APIs exposed to apps for controlling it should be, how it should interact
with custom UA strings, whether there should be a way to distinguish
WebView from Chrome in the UA-CH values and whether that needs to be
standardized, etc.

The referenced bug *should* just be about making all the non-UA client
hints work properly in WebView (currently they're mostly useless as
Accept-CH isn't being persisted across requests).

UA reduction in WebView is also in our future plan list, we will see how
> the UA-CH works in Webview.
>

We need a plan for how to ship UA-CH for WebView and what it should include
first :)


> For now, I don't think what we did in this phase on Android will impact
> Webview much since we already did the UA reduction phase 4 on
> Android platform.
> For the future plan, we will work out a plan (if UA-CH works as expected)
> to do the UA reduction in Webview to match what we did in Chrome.
> Also, we are glad to discuss with Webview for all other possibilities and
> impacts.  Thanks.
>

Understood, but if we ultimately want to change WebView's UA in a way that
doesn't pass the current CDD/CTS requirements then the work to change those
requirements needs to happen at *least* an entire Android release ahead of
time, and ideally would have been done several years ago if we want it to
have the most impact :(


>
> Best,
> Victor
>
> On Wed, Jan 18, 2023 at 12:20 PM Rick Byers  wrote:
>
>> Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
>> having a unified plan for WebView. I assume the format (eg. not omitting
>> the device model completely) is being driven by web compat concerns which
>> would matter for WebView as well, right?
>>
>
It's not really directly about web compat concerns. See
https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/web-platform-compatibility.md#Android_s-Compatibility-Test-Suite-tests-some-WebView-behaviours
for more on this, but briefly: CTS/CDD are about *application*
compatibility - they are requirements the Android OS must satisfy to be
considered compatible with existing Android applications. Anything that's
tested by CTS is something that app developers are expected to be able to
rely on.

It's likely that *most* consideration of WebView's UA string is happening
on the web side (by JS or by server side logic), but the UA string is also
exposed directly to apps via Java APIs and so the actual code of the app
might *also* be parsing this information (and the Java API currently does
*not* provide any way to access client hints, other than loading a page and
injecting JS into it to access the JS APIs). Web content that's designed
only to be loaded in a specific WebView application might potentially rely
much more heavily on the specific format of the UA string than content
that's intended to be used by multiple browsers, and may not ever be loaded
in Chrome or ever show up in web crawler data.


> Do we have any data on the web compatibility of removing the model string
>> entirely?
>>
>
The model string is currently omitted automatically on prerelease versions
of the Android OS as a basic precaution to not leak model names of
unreleased devices. This doesn't get a lot of production usage, but we do
regularly get bugs filed against us every single android release by device
vendors or other developers complaining that the useragent is "wrong" (even
though omitting the model entirely has been explicitly allowed by CTS for
quite a few releases now). We've also previously discussed removing the
model with various parties who had very strong objections on the grounds
that they use it for targeting downloads/support info/etc to particular
devices; if this information instead becomes available in UA-CH that may be
an acceptable migration path but this will likely be some amount of new
impact to developers/sites who are *not* affected by the changes to
Chrome's UA (because their content is only loaded inside WebViews).

So, I don't have any concrete data on the impact and we've not run any
experiments here, but it's likely to involve at least some new issues
distinct from Chrome's.


> My assumption is that it would be too breaking, but that's just an
>> assumption. Victor, can you or your team meet with Torne and figure out
>> whether a long-term plan for WebView would impact what we do for Chrome now?
>>
>> Thanks,
>>Rick
>>
>> On Wed, Jan 18, 2023 at 12:06 PM Torne (Richard Coles) <
>> to...@chromium.org> wrote:
>>
>>> I have some concerns that we won't be able to use this format for
>>> 

Re: [blink-dev] Intent to Ship: baseline-source

['Ian Kilpatrick' via blink-dev]

On Tue, Jan 17, 2023 at 3:48 PM fantasai 
wrote:

> On 1/12/23 22:55, Ian Kilpatrick wrote:
> > Ah true! I didn't consider the  values here.
> >
> > To mitigate this forward compat concern we can apply a partial mapping,
> e.g.
> > if the current `vertical-align` property is set, it'll set the
> > `baseline-source` to `auto`.
>
> I think that helps, yeah.
>
> > This should mitigate any forward compat concern here. I'll send a patch
> to do
> > this tomorrow. This will allow us to perform the larger (complex, and
> risky)
> > vertical-align changes in one shot later
>
> One concern I'd have here is that *if* we cannot ship the
> currently-specced
> shorthanding relationship among these properties, we might have to change
> that
> relationship, which could change how vertical-align and baseline-source
> interact as well.
>

I'm not concerned about this compared to the other compat risks with the
expanded vertical-align mapping (for other folks listed above).
This only becomes an issue if we are unable to ship the vertical-align
mapping at a later date, and we decide that baseline-source shouldn't be
attached to vertical-align at all.


> So it would be good to know if we can actually ship the
>vertical-align -> alignment-baseline + baseline-shift ( +
> baseline-source)
> mapping or not, even if the additional values are not yet supported.
>

I would actually be worried more about as a forward compat risk supporting
additional values later vs. the risk removing the mitigation above for
example.


> ~fantasai
>
> > On Thu, Jan 12, 2023 at 6:20 PM fantasai  > > wrote:
> >
> > On 1/12/23 17:21, Ian Kilpatrick wrote:
> >  > Some additional context for folks:
> >  >
> >  >   - Shipping the `baseline-source` property separately (this
> intent)
> > doesn't
> >  > increase/decrease forwards compat risk in a material way -
> specifying
> > it would
> >  > "win" over anything specified in `vertical-align` once we support
> that
> >  > mapping, and addresses a large web developer concern.
> >
> > This is incorrect. In an implementation that implements the
> shorthanding
> > relationship vs an implementation that doesn't, the following two
> > declarations
> > will have different effects:
> >
> > .x {
> > baseline-source: first;
> > vertical-align: 10px; /* resets baseline-source to auto, or not
> */
> > }
> >
> > ~fantasai
> >
>

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi Torne,
Thanks for your information. We understand your concern.
UA-CH in WebView will be shipping in Chrome M110
. UA reduction in
WebView is also in our future plan list, we will see how the UA-CH works in
Webview.
For now, I don't think what we did in this phase on Android will impact
Webview much since we already did the UA reduction phase 4 on
Android platform.
For the future plan, we will work out a plan (if UA-CH works as expected)
to do the UA reduction in Webview to match what we did in Chrome.
Also, we are glad to discuss with Webview for all other possibilities and
impacts.  Thanks.

Best,
Victor

On Wed, Jan 18, 2023 at 12:20 PM Rick Byers  wrote:

> Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
> having a unified plan for WebView. I assume the format (eg. not omitting
> the device model completely) is being driven by web compat concerns which
> would matter for WebView as well, right? Do we have any data on the web
> compatibility of removing the model string entirely? My assumption is that
> it would be too breaking, but that's just an assumption. Victor, can you or
> your team meet with Torne and figure out whether a long-term plan for
> WebView would impact what we do for Chrome now?
>
> Thanks,
>Rick
>
> On Wed, Jan 18, 2023 at 12:06 PM Torne (Richard Coles) 
> wrote:
>
>> I have some concerns that we won't be able to use this format for Android
>> WebView. I realise we're not currently shipping UA reduction for WebView,
>> but AFAIK we are still hoping to do so at some point in the future.
>>
>> WebView's UA format is mandated by Android's CTS compatibility tests. I
>> relaxed the test criteria some time ago to allow the device model and
>> Android build ID to be omitted (though WebView currently still includes
>> this information), but the test currently requires these fields to either
>> be entirely absent, or to exactly match the underlying OS properties. It
>> also does not allow the less-granular OS version to be omitted or spoofed.
>>
>> It'd be good to have a long term plan for what we're going to do with the
>> UA and with UA-CH in WebView that matches Chrome as closely as possible.
>>
>> On Tue, 17 Jan 2023 at 11:02, Victor Tan  wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>
>>> Specification
>>>
>>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>>> specifies Chrome’s UA Reduction plans today. As these changes land in
>>> Chromium and ship to 100% stable, the Compat Standard
>>>  will be updated in the UA String
>>> section ,
>>> like we did for the Phase 4 and plan to do for Phase 5 changes.
>>>
>>> Summary
>>>
>>> As previously detailed on the Chromium Blog
>>> ,
>>> we intend to proceed with Phase 6 of the User-Agent Reduction plan
>>> .
>>> In Phase 6, we change the deviceModel token to “K” and change the
>>> androidVersion token to a static “10” string in Android User-Agent
>>> string. The navigator.platform will be a “Linux armv81” constant on the
>>> Android platform.
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/640
>>>
>>> TAG review status
>>>
>>> Closed satisfied with concerns.
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Any time you modify the User-Agent string there is a risk of breaking
>>> existing patterns, like some content somewhere depending on the previous
>>> format.
>>>
>>> We do not expect interoperability risks, as each browser sends its own
>>> User-Agent string format. However there is a risk that - on the Android
>>> platform - content may rely  on User-Agents to parse deviceModel and
>>> androidVersion information. To mitigate the risk of this change, we intend
>>> to slowly roll out the format via Finch on the Android platform and observe
>>> health metrics and bug reports. See timeline below on our slow roll out
>>> plan. This gives us the option to roll this back for the Android platform
>>> if major issues arise.
>>>
>>> Displaying a static androidVersion and a deviceModel token for Android
>>> clients will not create a problem syntactically. But the web can get pretty
>>> weird in ways we don't anticipate. For example, sites can rely on the
>>> deviceModel in the User-Agent string to determine whether the device is a
>>> mobile, laptop or desktop. Currently, we change the deviceModel to a static
>>> string, sites need to use client hints as the alternative to determine the
>>> right behavior.  Hence the slow roll-out and incremental path 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Rick Byers]

Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
having a unified plan for WebView. I assume the format (eg. not omitting
the device model completely) is being driven by web compat concerns which
would matter for WebView as well, right? Do we have any data on the web
compatibility of removing the model string entirely? My assumption is that
it would be too breaking, but that's just an assumption. Victor, can you or
your team meet with Torne and figure out whether a long-term plan for
WebView would impact what we do for Chrome now?

Thanks,
   Rick

On Wed, Jan 18, 2023 at 12:06 PM Torne (Richard Coles) 
wrote:

> I have some concerns that we won't be able to use this format for Android
> WebView. I realise we're not currently shipping UA reduction for WebView,
> but AFAIK we are still hoping to do so at some point in the future.
>
> WebView's UA format is mandated by Android's CTS compatibility tests. I
> relaxed the test criteria some time ago to allow the device model and
> Android build ID to be omitted (though WebView currently still includes
> this information), but the test currently requires these fields to either
> be entirely absent, or to exactly match the underlying OS properties. It
> also does not allow the less-granular OS version to be omitted or spoofed.
>
> It'd be good to have a long term plan for what we're going to do with the
> UA and with UA-CH in WebView that matches Chrome as closely as possible.
>
> On Tue, 17 Jan 2023 at 11:02, Victor Tan  wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>
>> Specification
>>
>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>> specifies Chrome’s UA Reduction plans today. As these changes land in
>> Chromium and ship to 100% stable, the Compat Standard
>>  will be updated in the UA String
>> section , like
>> we did for the Phase 4 and plan to do for Phase 5 changes.
>>
>> Summary
>>
>> As previously detailed on the Chromium Blog
>> ,
>> we intend to proceed with Phase 6 of the User-Agent Reduction plan
>> .
>> In Phase 6, we change the deviceModel token to “K” and change the
>> androidVersion token to a static “10” string in Android User-Agent
>> string. The navigator.platform will be a “Linux armv81” constant on the
>> Android platform.
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/640
>>
>> TAG review status
>>
>> Closed satisfied with concerns.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Any time you modify the User-Agent string there is a risk of breaking
>> existing patterns, like some content somewhere depending on the previous
>> format.
>>
>> We do not expect interoperability risks, as each browser sends its own
>> User-Agent string format. However there is a risk that - on the Android
>> platform - content may rely  on User-Agents to parse deviceModel and
>> androidVersion information. To mitigate the risk of this change, we intend
>> to slowly roll out the format via Finch on the Android platform and observe
>> health metrics and bug reports. See timeline below on our slow roll out
>> plan. This gives us the option to roll this back for the Android platform
>> if major issues arise.
>>
>> Displaying a static androidVersion and a deviceModel token for Android
>> clients will not create a problem syntactically. But the web can get pretty
>> weird in ways we don't anticipate. For example, sites can rely on the
>> deviceModel in the User-Agent string to determine whether the device is a
>> mobile, laptop or desktop. Currently, we change the deviceModel to a static
>> string, sites need to use client hints as the alternative to determine the
>> right behavior.  Hence the slow roll-out and incremental path towards
>> User-Agent Reduction.
>>
>> Here is our proposed rollout plan in Chrome Stable channel
>> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we
>> discover concerning breakage or regressions via health metrics or bug
>> reports we will pause the rollout or roll back the feature entirely (and
>> update this thread if so):
>>
>> Stage
>>
>> Duration
>>
>> Date
>>
>> Stable 1% (M110+)
>>
>> M110 stable release is shipping to 100% (a best guess)
>>
>> Feb 14, 2023
>>
>> Stable 10% (M110/M111)
>>
>> ~4 weeks after previous stage
>>
>> Mar 14, 2023
>>
>> Stable 50%
>>
>> (M110/M111)
>>
>> ~2 weeks
>>
>> Mar 28, 2023
>>
>> TOT Default (M114)
>>
>> ~2 weeks after previous stage
>>
>> Apr 11, 2023
>>
>> Stable 100% (M110=>M114)
>>
>> ~ Same business day as previous stage
>>
>> Apr 11, 2023
>>
>> Web 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Rick Byers]

LGTM3*.

Thank you for your continued careful and cautious approach to this breaking
change, I'm excited to see it nearing the final goal. I expect that we'll
see an increase in client hints usage (eg. for important anti-fraud use
cases) as a result of this change. Given all the advance warning and
support you've provided the ecosystem on moving to client hints, I don't
personally see that anything would be gained by delaying any further.

*slightlyoff@ LGTM2'd in chromestatus, I haven't seen the e-mail yet but I
presume it's coming.



On Wed, Jan 18, 2023 at 11:53 AM Chris Harrelson 
wrote:

> LGTM1
>
> On Tue, Jan 17, 2023 at 8:02 AM Victor Tan  wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>
>> Specification
>>
>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>> specifies Chrome’s UA Reduction plans today. As these changes land in
>> Chromium and ship to 100% stable, the Compat Standard
>>  will be updated in the UA String
>> section , like
>> we did for the Phase 4 and plan to do for Phase 5 changes.
>>
>> Summary
>>
>> As previously detailed on the Chromium Blog
>> ,
>> we intend to proceed with Phase 6 of the User-Agent Reduction plan
>> .
>> In Phase 6, we change the deviceModel token to “K” and change the
>> androidVersion token to a static “10” string in Android User-Agent
>> string. The navigator.platform will be a “Linux armv81” constant on the
>> Android platform.
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/640
>>
>> TAG review status
>>
>> Closed satisfied with concerns.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Any time you modify the User-Agent string there is a risk of breaking
>> existing patterns, like some content somewhere depending on the previous
>> format.
>>
>> We do not expect interoperability risks, as each browser sends its own
>> User-Agent string format. However there is a risk that - on the Android
>> platform - content may rely  on User-Agents to parse deviceModel and
>> androidVersion information. To mitigate the risk of this change, we intend
>> to slowly roll out the format via Finch on the Android platform and observe
>> health metrics and bug reports. See timeline below on our slow roll out
>> plan. This gives us the option to roll this back for the Android platform
>> if major issues arise.
>>
>> Displaying a static androidVersion and a deviceModel token for Android
>> clients will not create a problem syntactically. But the web can get pretty
>> weird in ways we don't anticipate. For example, sites can rely on the
>> deviceModel in the User-Agent string to determine whether the device is a
>> mobile, laptop or desktop. Currently, we change the deviceModel to a static
>> string, sites need to use client hints as the alternative to determine the
>> right behavior.  Hence the slow roll-out and incremental path towards
>> User-Agent Reduction.
>>
>> Here is our proposed rollout plan in Chrome Stable channel
>> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we
>> discover concerning breakage or regressions via health metrics or bug
>> reports we will pause the rollout or roll back the feature entirely (and
>> update this thread if so):
>>
>> Stage
>>
>> Duration
>>
>> Date
>>
>> Stable 1% (M110+)
>>
>> M110 stable release is shipping to 100% (a best guess)
>>
>> Feb 14, 2023
>>
>> Stable 10% (M110/M111)
>>
>> ~4 weeks after previous stage
>>
>> Mar 14, 2023
>>
>> Stable 50%
>>
>> (M110/M111)
>>
>> ~2 weeks
>>
>> Mar 28, 2023
>>
>> TOT Default (M114)
>>
>> ~2 weeks after previous stage
>>
>> Apr 11, 2023
>>
>> Stable 100% (M110=>M114)
>>
>> ~ Same business day as previous stage
>>
>> Apr 11, 2023
>>
>> Web stakeholders can still test with the user agent reduction
>> deprecation origin trial
>> 
>> until M113 (late May) if they need more time to adapt to the coming
>> changes. The UA-RD OT allows web stakeholders to request the legacy
>> user-agent string values (i.e. non-reduced values).
>>
>> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
>> string already.
>>
>> WebKit: Shipped/Shipping. Safari has already frozen everything in their
>> desktop UA string except for Safari and WebKit versions. Also, UA reduction
>> phase 6 will only apply to the Android platform.
>>
>> Web developers: Mixed signals. Various channels have different
>> reactions. It’s similar for the UA reduction phase 4 and phase 5.
>>
>>
>> Debuggability
>>
>> No special DevTools 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Torne (Richard Coles)]

I have some concerns that we won't be able to use this format for Android
WebView. I realise we're not currently shipping UA reduction for WebView,
but AFAIK we are still hoping to do so at some point in the future.

WebView's UA format is mandated by Android's CTS compatibility tests. I
relaxed the test criteria some time ago to allow the device model and
Android build ID to be omitted (though WebView currently still includes
this information), but the test currently requires these fields to either
be entirely absent, or to exactly match the underlying OS properties. It
also does not allow the less-granular OS version to be omitted or spoofed.

It'd be good to have a long term plan for what we're going to do with the
UA and with UA-CH in WebView that matches Chrome as closely as possible.

On Tue, 17 Jan 2023 at 11:02, Victor Tan  wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>
> Specification
>
> https://www.chromium.org/updates/ua-reduction is the closest thing that
> specifies Chrome’s UA Reduction plans today. As these changes land in
> Chromium and ship to 100% stable, the Compat Standard
>  will be updated in the UA String section
> , like we did
> for the Phase 4 and plan to do for Phase 5 changes.
>
> Summary
>
> As previously detailed on the Chromium Blog
> ,
> we intend to proceed with Phase 6 of the User-Agent Reduction plan
> .
> In Phase 6, we change the deviceModel token to “K” and change the
> androidVersion token to a static “10” string in Android User-Agent
> string. The navigator.platform will be a “Linux armv81” constant on the
> Android platform.
>
> Blink component
>
> Blink>Network>ClientHints
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
> TAG review status
>
> Closed satisfied with concerns.
>
> Risks
> Interoperability and Compatibility
>
> Any time you modify the User-Agent string there is a risk of breaking
> existing patterns, like some content somewhere depending on the previous
> format.
>
> We do not expect interoperability risks, as each browser sends its own
> User-Agent string format. However there is a risk that - on the Android
> platform - content may rely  on User-Agents to parse deviceModel and
> androidVersion information. To mitigate the risk of this change, we intend
> to slowly roll out the format via Finch on the Android platform and observe
> health metrics and bug reports. See timeline below on our slow roll out
> plan. This gives us the option to roll this back for the Android platform
> if major issues arise.
>
> Displaying a static androidVersion and a deviceModel token for Android
> clients will not create a problem syntactically. But the web can get pretty
> weird in ways we don't anticipate. For example, sites can rely on the
> deviceModel in the User-Agent string to determine whether the device is a
> mobile, laptop or desktop. Currently, we change the deviceModel to a static
> string, sites need to use client hints as the alternative to determine the
> right behavior.  Hence the slow roll-out and incremental path towards
> User-Agent Reduction.
>
> Here is our proposed rollout plan in Chrome Stable channel
> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we
> discover concerning breakage or regressions via health metrics or bug
> reports we will pause the rollout or roll back the feature entirely (and
> update this thread if so):
>
> Stage
>
> Duration
>
> Date
>
> Stable 1% (M110+)
>
> M110 stable release is shipping to 100% (a best guess)
>
> Feb 14, 2023
>
> Stable 10% (M110/M111)
>
> ~4 weeks after previous stage
>
> Mar 14, 2023
>
> Stable 50%
>
> (M110/M111)
>
> ~2 weeks
>
> Mar 28, 2023
>
> TOT Default (M114)
>
> ~2 weeks after previous stage
>
> Apr 11, 2023
>
> Stable 100% (M110=>M114)
>
> ~ Same business day as previous stage
>
> Apr 11, 2023
>
> Web stakeholders can still test with the user agent reduction deprecation
> origin trial
> 
> until M113 (late May) if they need more time to adapt to the coming
> changes. The UA-RD OT allows web stakeholders to request the legacy
> user-agent string values (i.e. non-reduced values).
>
> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
> string already.
>
> WebKit: Shipped/Shipping. Safari has already frozen everything in their
> desktop UA string except for Safari and WebKit versions. Also, UA reduction
> phase 6 will only apply to the Android platform.
>
> Web developers: Mixed signals. Various channels have different reactions.
> It’s similar for the UA reduction phase 4 

[blink-dev] Re: Intent to Ship: Add containerName and containerQuery, update conditionText

[Alex Russell]

Hey Daniil:

Thanks for filing for this change while the feature is still low-use; it'll 
be much more challenging to make this switch later.

Something that wasn't clear from the use counters you linked was the use of 
the IDL properties vs. the CSS names. Given that it seems like we have 
use-counters for the latter but not the former, it seems reasonable to 
consider CSS usage to be a hard cap on potential use of the JS interface.

Would you be willing to manually inspect some content (say 10-20 sites) 
that use the CSS `container-name` and `container-query` attributes to look 
for script access? Presumably it's a fraction that population, but 
verifying would be helpful.

Thanks

On Tuesday, January 17, 2023 at 8:31:42 AM UTC-8 Daniil Sakhapov wrote:

> Contact emailssakha...@chromium.org
>
> Specification
> https://w3c.github.io/csswg-drafts/css-contain-3/#the-csscontainerrule-interface
>
> Summary
>
> Updates the CSSContainerRule interface to match the specs. Implements 
> containerName and containerQuery, updates conditionText for @container to 
> be up-to-date with specs.
>
> Blink componentBlink>CSS 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/592
>
> TAG review statusIssues addressed
>
> Risks
>
> Activation
>
> Previous conditionText attribute contained only container-query part, but 
> now it's both container-name and container-query. But it should not break a 
> lot of sites due to low current usage as per: 
> https://chromestatus.com/metrics/css/timeline/popularity/697 
> https://chromestatus.com/metrics/css/timeline/popularity/699 The real 
> breakage is hard to measure, as it's not possible to track the how result 
> of conditionText is used and the usage of container-name is low compared to 
> the container-type usage. Also, conditionText is readonly, so there are no 
> round-trip issues
>
> 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
>
> https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
>
> https://wpt.fyi/css/css-contain/container-queries/at-container-serialization.html
> https://wpt.fyi/css/css-contain/container-queries/idlharness.html
> https://wpt.fyi/css/cssom/CSSContainerRule.tentative.html
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1393577
>
> Estimated milestones
> DevTrial on desktop 112
> DevTrial on Android 112
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5159369837117440
>
> 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/bc554b3e-0666-4e70-a0de-83a49887d70fn%40chromium.org.

[blink-dev] Re: Intent to Ship: User-Agent Reduction Phase 6

[slightlyoff via Chromestatus]

LGTM2

-- 
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/d9d43905f28cb093%40google.com.

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Chris Harrelson]

LGTM1

On Tue, Jan 17, 2023 at 8:02 AM Victor Tan  wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>
> Specification
>
> https://www.chromium.org/updates/ua-reduction is the closest thing that
> specifies Chrome’s UA Reduction plans today. As these changes land in
> Chromium and ship to 100% stable, the Compat Standard
>  will be updated in the UA String section
> , like we did
> for the Phase 4 and plan to do for Phase 5 changes.
>
> Summary
>
> As previously detailed on the Chromium Blog
> ,
> we intend to proceed with Phase 6 of the User-Agent Reduction plan
> .
> In Phase 6, we change the deviceModel token to “K” and change the
> androidVersion token to a static “10” string in Android User-Agent
> string. The navigator.platform will be a “Linux armv81” constant on the
> Android platform.
>
> Blink component
>
> Blink>Network>ClientHints
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
> TAG review status
>
> Closed satisfied with concerns.
>
> Risks
> Interoperability and Compatibility
>
> Any time you modify the User-Agent string there is a risk of breaking
> existing patterns, like some content somewhere depending on the previous
> format.
>
> We do not expect interoperability risks, as each browser sends its own
> User-Agent string format. However there is a risk that - on the Android
> platform - content may rely  on User-Agents to parse deviceModel and
> androidVersion information. To mitigate the risk of this change, we intend
> to slowly roll out the format via Finch on the Android platform and observe
> health metrics and bug reports. See timeline below on our slow roll out
> plan. This gives us the option to roll this back for the Android platform
> if major issues arise.
>
> Displaying a static androidVersion and a deviceModel token for Android
> clients will not create a problem syntactically. But the web can get pretty
> weird in ways we don't anticipate. For example, sites can rely on the
> deviceModel in the User-Agent string to determine whether the device is a
> mobile, laptop or desktop. Currently, we change the deviceModel to a static
> string, sites need to use client hints as the alternative to determine the
> right behavior.  Hence the slow roll-out and incremental path towards
> User-Agent Reduction.
>
> Here is our proposed rollout plan in Chrome Stable channel
> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we
> discover concerning breakage or regressions via health metrics or bug
> reports we will pause the rollout or roll back the feature entirely (and
> update this thread if so):
>
> Stage
>
> Duration
>
> Date
>
> Stable 1% (M110+)
>
> M110 stable release is shipping to 100% (a best guess)
>
> Feb 14, 2023
>
> Stable 10% (M110/M111)
>
> ~4 weeks after previous stage
>
> Mar 14, 2023
>
> Stable 50%
>
> (M110/M111)
>
> ~2 weeks
>
> Mar 28, 2023
>
> TOT Default (M114)
>
> ~2 weeks after previous stage
>
> Apr 11, 2023
>
> Stable 100% (M110=>M114)
>
> ~ Same business day as previous stage
>
> Apr 11, 2023
>
> Web stakeholders can still test with the user agent reduction deprecation
> origin trial
> 
> until M113 (late May) if they need more time to adapt to the coming
> changes. The UA-RD OT allows web stakeholders to request the legacy
> user-agent string values (i.e. non-reduced values).
>
> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
> string already.
>
> WebKit: Shipped/Shipping. Safari has already frozen everything in their
> desktop UA string except for Safari and WebKit versions. Also, UA reduction
> phase 6 will only apply to the Android platform.
>
> Web developers: Mixed signals. Various channels have different reactions.
> It’s similar for the UA reduction phase 4 and phase 5.
>
>
> Debuggability
>
> No special DevTools support needed.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No (Only for Android)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No, because User-Agents vary across browsers.
>
> Flag name
>
> #reduce-user-agent-android-version-device-model
>
> Notes: The existing flag #reduce-user-agent will provide the same format
> User-Agent string on the Android platform since this is the last phase for
> User-Agent reduction.
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1394819
>
> Launch bug
>
> 

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

[Alex Russell]

Per today's API OWNERs meeting, a dumb question: is the XSS risk here 
largely down to script execution triggered by this pattern? Or non-script 
content in the inline'd SVG?

Thanks

On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:

> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan  
> wrote:
>
>> Thanks for adding me. Yes, this definitely seems like the pattern where 
>> we'd want a temporary enterprise policy to re-enable support for ~3 
>> milestones after we remove support by default.  
>> go/chrome-enterprise-friendly 
>>  gets into the 
>> details of the why, 
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>  
>> is the step-by-step, and the enterprise team is always happy to advise as 
>> well.
>>
>  
> Thank you for the details on enterprise policy! I'll make sure to follow 
> those steps when I plan to remove the feature by default! 
>
>> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers  wrote:
>>
>>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss  
>>> wrote:
>>>
 Would it be possible to turn 
 
  
 the usecounter into a UKM to get a better view of the number of impacted 
 origins, beyond just the homepage?

>>>
>>> Yeah that could be useful. But we've also got some leads already so 
>>> getting more leads may not be critical until we follow up on the ones we 
>>> have. Can we find a developer for one of those sites who will talk to us 
>>> about where that pattern is coming from in their toolchain and how they'd 
>>> migrate off it? Having the UKM data will also help in selecting the sites 
>>> that will have the most impact on our users (and hence our UseCounter 
>>> stats). Maybe we'll get lucky and find that, despite the long tail, 90% of 
>>> the usage is from just a few sites we can work with.
>>>
>>  
> Added UKM at https://crrev.com/c/4171733.
>
>>
>>> I wonder if this would be a good candidate for a deprecation trial + 
 enterprise policy. That would solve this injection vector for the broader 
 web, while giving impacted folks some more time to move away from this 
 pattern.

>>>
>>> Good idea. Impacting a large number of small sites is still problematic 
>>> for a deprecation trial. Just reaching enough to make any change at all is 
>>> the hard part. Perhaps we can make replacing the usage easier than the 
>>> overhead of getting an applying an OT token? Still a deprecation trial 
>>> would probably be useful. Enterprise policy, certainly. +Brandon Heenan 
>>>  can help advise on that. I'd also advise leaving 
>>> this enabled for WebView (at least to start), it feels like the sort of 
>>> chromium rendering quirk we've found Android apps to rely on 
>>> disproportionately in the past.
>>>
>>> On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev <
 blink-dev@chromium.org> wrote:

> Thank you Rick for the detailed explanation!
>
> On Fri, Jan 13, 2023 at 10:30 AM Rick Byers  
> wrote:
>
>> Eliminating this makes sense to me given the security benefit. Thank 
>> you for pushing it! But it does seem somewhat risky from a web compat 
>> perspective. 0.005% is above our "small but non-trivial risk 
>> "
>>  
>> rule of thumb. Here's a bit of an analysis according to our other compat 
>> principles :
>>
>>- Severity of breakage 
>>
>> :
>>  
>>lower given this is likely only about some visualis, but this site 
>> is a good example of non-trivial UI 
>>breakage. This pattern of putting a base64-encoded SVG into an SVG 
>>  
>>element with nothing else in the  is weird, isn't it? Why would 
>>someone do that rather than just put the SVG in directly, or put the 
>> data 
>>URL into an img tag?
>>
>> I've looked into that site. And it seems like they are reusing a 
> single SVG image (i.e. data: URL SVG image) which contains several 
> images, 
> and changing which image should be rendered by combination of symbol 
>  + 
> id (which is only possible in use element, and not in img tag). Migration 
> can be done by hosting the same image in the same-origin endpoint, 
> converting it to blob: URL and assigning that to the  element, or 
> inlining each SVG image.
>

>>> Interesting. So could we write a tool which, given the source html, 
>>> transforms it to simply 

[blink-dev] Re: Intent to Ship: Secure Payment Confirmation - Opt-Out Support

[slightlyoff via Chromestatus]

LGTM3

-- 
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/deeed805f28c7126%40google.com.

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

[Daniel Bratell]

LGTM3

/Daniel

On 2023-01-14 05:11, Noam Rosenthal wrote:



On Fri, Jan 13, 2023 at 7:19 PM Yoav Weiss  wrote:

LGTM2 to launch this as a Finch experiment.

On Fri, Jan 13, 2023 at 5:55 PM Rick Byers 
wrote:

LGTM1 from an API owners perspective. It's arguable whether
this is "web-exposed" at all, or just a browser performance
heuristic you're tweaking.

From a performance perspective, your argument and UMA analysis
is compelling to me. But I've learned the hard way not to
trust predictions of performance impact and instead rely on
experiments :-). Were you planning on launching this with
finch and validating the CWV impact?


I think launching this as a Finch experiment makes a lot of sense.
This is extremely unlikely to break content, but can result in a
performance regression, so slow rollout seems like the best way to
go here


Sounds good, will proceed with finching this.
Thanks!
--
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/CAJn%3DMYZn7wV35v8W8ZwQN9oGSgVXcNsG030E8-WEftWRkTz4zw%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/1d26ac7f-f2b1-29ec-6657-ff6e5017e585%40gmail.com.

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation - Opt-Out Support

[Daniel Bratell]

LGTM2

/Daniel

On 2023-01-16 16:35, Rick Byers wrote:
LGTM1. Tiny partner-requested addition to a shipped API. Spec and 
tests look fine. Thanks!


Rick

On Wed, Jan 11, 2023 at 5:06 PM Nick Burris  wrote:


Contact emails

smcgr...@chromium.org, rous...@chromium.org, nbur...@chromium.org


Explainer

https://github.com/w3c/secure-payment-confirmation/issues/172


Specification

https://w3c.github.io/secure-payment-confirmation


Design docs

https://github.com/w3c/secure-payment-confirmation/issues/172


Summary

Adds an 'opt-out' flow to Secure Payment Confirmation. When the
(optional) input flag is set, the SPC UXes will render an
'opt-out' link of some sort that the user can interact with to
indicate to the relying party that they wish to be opted out. See
https://github.com/w3c/secure-payment-confirmation/issues/172



Blink component

Blink>Payments




TAG review status

Not applicable


Risks


Interoperability and Compatibility

/Gecko/: No signal
/WebKit/: No signal
/Web developers/: Positive
(https://github.com/w3c/secure-payment-confirmation/issues/172)
This feature is proposed by web developers.


Ergonomics

SPC feature is a combination of WebAuthn and PaymentRequest APIs.


Activation

To take advantage of this feature, developers have to specify a
new optional API parameter `showOptOut: true`.


Debuggability

Normal devtools javascript debugging capabilities should suffice.


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

No

SPC is currently launched only on Mac, Windows, and Android. This
opt-out feature also exists only on Mac, Windows, and Android.


Is this feature fully tested by web-platform-tests

?

Yes




Flag name

--enable-blink-features=SecurePaymentConfirmationOptOut


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1325854


Launch bug

https://crbug.com/1329512


Sample links

https://rsolomakhin.github.io/pr/spc-opt-out


Estimated milestones

OriginTrial desktop last109
OriginTrial desktop first   104
DevTrial on desktop 104

OriginTrial Android last109

OriginTrial webView last109



Spec changes

https://github.com/w3c/secure-payment-confirmation/pull/215


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133415903920128


Links to previous Intent discussions

Intent to prototype


Intent to Experiment




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/CADvKJHPAjmf0aea06MgrjYwq-YrcHzsM4pTqpg%3Dt4jQiT%3DRyjA%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/CAFUtAY8ZagJZFn-yxz6sAvrt%3Da65wtWr0Z1uVmLzLr3chWcYRA%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 ship: Font shorthand property resetting its subproperties

['Munira Tursunova' via blink-dev]

Thank you! Added a devtools issue: crbug.com/1408422

On Tue, Jan 17, 2023 at 4:58 PM Mike Taylor  wrote:

> LGTM3
>
> On 1/16/23 3:44 PM, Rick Byers wrote:
>
> Thanks for the careful compat analysis! LGTM2 - feels like a bugfix-level
> change to me, because:
>
>- Severity of breakage
>
> 
>  seems
>likely to always be very low, minor tweaks to rendered text
>- Ease of adaptation
>
> 
>seems high - just do the obvious thing and update the 'font' style
>- Important for interoperability
>
> 
>- I can imagine no reason why enterprises
>
> 
>or webview would be any more likely to rely on this little rendering quirk
>than random websites
>
> But in case we're wrong about any of these things, please keep an eye on
> bug reports during the dev and beta channel phases
> 
> and circle back here if you get even a single report of non-trivial
> breakage (as such reports in beta tend to indicate there's an order of
> magnitude more like it waiting to be hit at stable).
>
> Rick
>
> On Mon, Jan 16, 2023 at 11:51 AM Yoav Weiss 
> wrote:
>
>> LGTM1
>>
>> On Mon, Jan 16, 2023 at 10:19 AM 'Munira Tursunova' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>>
>>> * moon...@google.com , dr...@google.com
>>>  * Explainer
>>>
>>>
>>> *
>>> https://github.com/w3c/csswg-drafts/issues/7832#issuecomment-1338671264
>>> 
>>> https://github.com/w3c/csswg-drafts/issues/1636
>>> 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1379236
>>>  *
>>> Specification
>>>
>>>
>>> * https://www.w3.org/TR/css-fonts-4/#font-prop
>>>  * Summary
>>>
>>> * When the font shorthand is specified all of its subproperties
>>> including font-size-adjust, font-kerning, font-feature-settings,
>>> font-optical-sizing and font-variation-settings should be reset to their
>>> initial values. Since Chrome wasn’t resetting some font subproperties
>>> before, there is a risk that content would rely on this bug. Therefore the
>>> ClusterTelemetry analysis was done for the top 10K webpages. Analysis of
>>> the ClusterTelemetry results can be found here
>>> .
>>> The results show it only affects 3 out of ~10K webpages and the changes in
>>> these 3 webpages can be considered minor. Furthermore, Firefox has already
>>> shipped this feature and it was also shipped in Safari Technology preview,
>>> so it will be soon shipped in Safari as well. This suggests the change can
>>> be safely landed on Chrome. *
>>>
>>
>> Thanks for the detailed investigation. 3/10K is 0.03% which is an order
>> of magnitude more than we are typically comfortable with breaking changes.
>> But at the same time, looking at the examples, it's very hard to notice
>> the "brokenness", so I think it's reasonable to assume that many users
>> won't notice it.
>>
>> It may be hard for developers to figure out the source of the difference.
>> Would you consider adding a devtools issue that can make that easier?
>>
>> Motivation
>>>
>>>
>>>
>>>
>>> * When font shorthand is specified, then it means that the font has
>>> changed, so there is no point to apply the same set of settings for the new
>>> font (for example, the new font might not have features that were specified
>>> before or they may look completely different in the new font). Thus if the
>>> properties font-size-adjust, font-kerning, font-feature-settings,
>>> font-optical-sizing and font-variation-settings were set to non-initial
>>> value before, they should be reset. Chrome was already resetting some of
>>> it’s subproperties, like font-variant-*. In CSS WG issue #7832
>>> 
>>> it was recently resolved which of the font subproperties should be reset to
>>> their initial values. So this change adds resetting for font-size-adjust,
>>> font-kerning, font-feature-settings, font-optical-sizing and
>>> font-variation-settings.  Firefox and Safari have already implemented this
>>> feature. * Blink component
>>>
>>>
>>> * Blink>Fonts
>>>