[blink-dev] Intent to extend experimentation: Permissions-Policy: unload

[Daisuke Enomoto]

API owners,

We would like to extend the origin trial for 3 additional milestones, with
the extension starting in 110 continuing through 112. The initial
experiment was approved for the OT running from 107 through 109.

Contact emails

fer...@chromium.org

Explainer

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md

Specificationhttps://github.com/whatwg/html/pull/7915
Summary

This feature allows pages to disable the running of unload event handlers.
The goal is to :

- allow sites that have removed all unload handlers to ensure they do not
accidentally add new ones

- allow sites to remove unload handlers when updating the code is infeasible


Unload event handlers are problematic for various reasons and prevent use
of BFCache on Desktop (see
https://web.dev/bfcache/#never-use-the-unload-event).

Blink componentBlink>PermissionsAPI

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/738
TAG review status

Pending

Risks

N/A


Interoperability and Compatibility



3rd-party frames that rely on unload may not work as expected when
navigating away. This is solvable by the frame authors by use of
alternatives to unload and is unlikely to impact users. See detailed
discussion.
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code

Gecko: Negative (
https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132)
FF objects to this similar to sync-xhr and document-domain providing a way
to cause cross-origin interference with script. Explainer addresses this (
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code)
At a recent TPAC meeting with Mozilla people present, no negative feedback
was received. Request for formal position is here
https://github.com/mozilla/standards-positions/issues/691
WebKit: No signal
Web developers: Positive Private discussions with devs are positive. Sites
that have made efforts to remove all unload handlers want to use this to
prevent accidental returns. Also some providers of 3rd-party iframes which
have content outside of their control (e.g. ad network) want to guarantee
themselves to be unload-free.
https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1130401722
Also positive feedback about using this to deny unload as a source of
security problems.
https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1222973324
Other signals: TAG review is here but has no feedback on the API itself.
https://github.com/w3ctag/design-reviews/issues/738


Goals for experimentation

   -

   Validate that this allows sites using it to improve their BFCache hit
   rate

Reason this experiment is being extended

We had requested this Origin Trial to be run for 3 milestones, specifically
from 107 to 109 without realizing the Origin Trial guideline

suggesting 6 milestones. We would like to extend this OT for another 3
milestones or to 112 inclusive by applying the 6 milestone guidelines we
originally missed, to give sufficient time for partners to give us feedback.


Ongoing technical constraints


Debuggability

When this header is present, attempts to add an unload event handler will
result in an error on the console (just as would happen for any other
Permissions Policy violation).

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=PermissionsPolicyUnload

or via Origin Trial Token



Tracking bughttps://crbug.com/1324111


Launch bug

https://launch.corp.google.com/launch/4200516


Estimated milestones

OriginTrial desktop last (new request)

112

OriginTrial desktop last

109

OriginTrial desktop first

107

OriginTrial desktop last (new request)

112

OriginTrial Android last

109

OriginTrial Android first

107


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


Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/ryjRQsxyo2Y/m/xOPh6glQBAAJ

Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/38Dpu-uhwFc
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/RhzscAx3qc8/m/qgBkBFmzAgAJ?utm_medium=email&utm_source=footer

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from 

Re: [blink-dev] Intent to extend experimentation: Permissions-Policy: unload

[Yoav Weiss]

LGTM to experiment M110-M112 (inclusive)

On Tue, Jan 17, 2023 at 9:54 AM Daisuke Enomoto 
wrote:

> API owners,
>
> We would like to extend the origin trial for 3 additional milestones, with
> the extension starting in 110 continuing through 112. The initial
> experiment was approved for the OT running from 107 through 109.
>
> Contact emails
>
> fer...@chromium.org
>
> Explainer
>
>
> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md
>
> Specificationhttps://github.com/whatwg/html/pull/7915
> Summary
>
> This feature allows pages to disable the running of unload event handlers.
> The goal is to :
>
> - allow sites that have removed all unload handlers to ensure they do not
> accidentally add new ones
>
> - allow sites to remove unload handlers when updating the code is
> infeasible
>
>
> Unload event handlers are problematic for various reasons and prevent use
> of BFCache on Desktop (see
> https://web.dev/bfcache/#never-use-the-unload-event).
>
> Blink componentBlink>PermissionsAPI
> 
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/738
> TAG review status
>
> Pending
>
> Risks
>
> N/A
>
>
> Interoperability and Compatibility
>
>
>
> 3rd-party frames that rely on unload may not work as expected when
> navigating away. This is solvable by the frame authors by use of
> alternatives to unload and is unlikely to impact users. See detailed
> discussion.
>
> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code
>
> Gecko: Negative (
> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132)
> FF objects to this similar to sync-xhr and document-domain providing a way
> to cause cross-origin interference with script. Explainer addresses this (
> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code)
> At a recent TPAC meeting with Mozilla people present, no negative feedback
> was received. Request for formal position is here
> https://github.com/mozilla/standards-positions/issues/691
> WebKit: No signal
> Web developers: Positive Private discussions with devs are positive.
> Sites that have made efforts to remove all unload handlers want to use this
> to prevent accidental returns. Also some providers of 3rd-party iframes
> which have content outside of their control (e.g. ad network) want to
> guarantee themselves to be unload-free.
> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1130401722
> Also positive feedback about using this to deny unload as a source of
> security problems.
> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1222973324
> Other signals: TAG review is here but has no feedback on the API itself.
> https://github.com/w3ctag/design-reviews/issues/738
>
>
> Goals for experimentation
>
>-
>
>Validate that this allows sites using it to improve their BFCache hit
>rate
>
> Reason this experiment is being extended
>
> We had requested this Origin Trial to be run for 3 milestones,
> specifically from 107 to 109 without realizing the Origin Trial guideline
> 
> suggesting 6 milestones. We would like to extend this OT for another 3
> milestones or to 112 inclusive by applying the 6 milestone guidelines we
> originally missed, to give sufficient time for partners to give us feedback.
>
>
> Ongoing technical constraints
>
>
> Debuggability
>
> When this header is present, attempts to add an unload event handler will
> result in an error on the console (just as would happen for any other
> Permissions Policy violation).
>
> 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=PermissionsPolicyUnload
>
> or via Origin Trial Token
> 
>
>
> Tracking bughttps://crbug.com/1324111
>
>
> Launch bug
>
> https://launch.corp.google.com/launch/4200516
>
>
> Estimated milestones
>
> OriginTrial desktop last (new request)
>
> 112
>
> OriginTrial desktop last
>
> 109
>
> OriginTrial desktop first
>
> 107
>
> OriginTrial desktop last (new request)
>
> 112
>
> OriginTrial Android last
>
> 109
>
> OriginTrial Android first
>
> 107
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5760325231050752
>
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/ry

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

[Yoav Weiss]

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?

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.

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.
>
>>
>>- I don't suppose there's some creative way to allow this specific
>>odd pattern while still getting the security benefit, is there?
>>
>> Unfortunately, no. While we could read the href value of  elements
> and convert the data: URL to blob: URL, we won't know if the data: URL was
> set by the site owner, or a malicious attacker (through HTML injection). So
> while we could provide such a library, it does not provide the security
> benefit that we are seeking.
>
>>
>>- Unique sites impacted
>>
>> :
>>Finding a variety of small sites is actually a lot worse than if we had
>>found only a few bigger sites. It means there's probably some common tool
>>or pattern leading different designers/developers to do this and so likely
>>a relatively large number of individuals who would need to be involved in
>>fixing the breakage. Of course our HTTP Archive list of sites is just a
>>subset of who's fully impacted, so if the problem is a long-tail one as it
>>seems, HTTP archive data shows us only the tip of that long tail.
>>- Security
>>
>> :
>>it's definitely worth taking some comapt risk to reduce XSS surface area. 
>> I
>>don't fully understand the threat model though. Is this mainly a risk for
>>sites who are programmatically putting (potentially attacker-controlled)
>>strings into SVGUseElement hrefs? Or are you more worried about cases 
>> where
>>the attacker controls the HTML and can take advantage of this oddity in 
>> the
>>platform on any normal site? I'm just trying to gauge the magnitude of the
>>security benefit here to weigh it against the comapt risk, any help is
>>appreciated.
>>
>> We are worried about both (i.e. Server-side injection and DOM XSS). The
> fact that this has led to several browser security feature bypasses (e.g.
> Sanitizer API and Trusted Types) suggests that it's not a commonly known
> XSS sink, and therefore we believe that it's common for security mechanisms
> (e.g. sanitizers, linters) to miss this odd feature.
>
>>
>>- Ease of adaptation
>>
>> :
>>seems like it should be easy to use an alternative, at least for these
>>image cases, but I guess it's hard to say without knowing why people are
>>doing this. Is there perhaps some website design tool which is generating
>>this and will need to change?
>>
>> I think it is easy to migrate by hosti

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

[Rick Byers]

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.

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 inline the selected SVG? That would save some bytes
too, right? We've found in the past that when we give developers easy tools
to trivially adapt their code, then it makes moderate-risk deprecations go
quite smoother. I.e. when we get to the point of having a deprecation
warning (and report ) for
the usage, if we can simply say "for most cases we've found you can just
run your html through this tool to adapt it automatically", then that would
help a LOT in having the comfort to make the breaking change. Someone from
the devrel or tooling teams with experience in how developers approach
images in practice (eg. +Addy Osmani ) might be able to
advise on a pragmatic and helpful path.

>
>>>- I don't suppose there's some creative way to allow this specific
>>>odd pattern while still getting the security benefit, is there?
>>>
>>> Unfortunately, no. While we could read the href value of  elements
>> and convert the data: URL to blob: URL, we won't know if the data: URL was
>> set by the site owner, or a malicious attacker (through HTML injection). So
>> while we could provide such a library, it does not provide the security
>> benefit that we are seeking.
>>
>>>
>>>- Unique sites impacted
>>>
>>> :
>>>Finding a variety of

Re: [blink-dev] Intent to ship: Font shorthand property resetting its subproperties

[Mike Taylor]

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

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

[Victor Tan]

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

https://launch.corp.google.com/launch/4225291

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177681979637760

-- 
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+unsu

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

[Daniil Sakhapov]

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

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

['Brandon Heenan' via blink-dev]

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.

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.
>
> 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 inline the selected SVG? That would save some bytes
> too, right? We've found in the past that when we give developers easy tools
> to trivially adapt their code, then it makes moderate-risk deprecations go
> quite smoother. I.e. when we get to the point of having a deprecation
> warning (and report ) for
> the usage, if we can simply say "for most cases we've found you can just
> run your html through this tool to adapt it automatically", then that would
> help a LOT in having the comfort to make the breaking change. Someone from
> the devrel or tooling teams with experience in how developers approach
> images in practice (eg. +Addy Osmani ) might be able
> to advise on a pragmatic and helpful path.
>
>>
- I don't suppose there's some creative way to allow this specific
   

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

[fantasai]

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.


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.

~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/ec2bb173-5b87-9f06-c3af-fd7271a1df0f%40inkedblade.net.

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

['Jun Kokatsu' via blink-dev]

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 inline the selected SVG? That would save some bytes
>> too, right? We've found in the past that when we give developers easy tools
>> to trivially adapt their code, then it makes moderate-risk deprecations go
>> quite smoother. I.e. when we get to the point of having a deprecation
>> warning (and report ) for
>> the usage, if we can simply say "for most cases we've found you can just
>> run your h