Intent to Ship: CSS Overflow for replaced elements

[Khushal Sagar]

Contact emails

khusha...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specification

https://drafts.csswg.org/css-overflow/#overflow-properties

Summary

This change allows developers to use the existing `overflow` property with replaced elements that paint outside the content-box. Paired with `object-view-box` this can be used to create an image with a custom glow or shadow applied, with proper ink-overflow behavior like a CSS shadow would have.

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on replaced elements (img, video, canvas). Currently `overflow:visible` in a developer stylesheet on such elements is ignored during paint and the content is clipped to the element's content-box. With this feature, `overflow:visible` will result in content outside the element's content-box to paint as ink overflow. We've collected use counter data to measure the number of sites which could be affected by this. The use counter data collected over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below. * The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%. * The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

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

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

Web developers: No signals

Other signals:

WebView application risks

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

Debuggability

This is a CSS property which can be debugged in the devtools style panel similar to other CSS properties.

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

CSSOverflowForReplacedElements

Note: Because of the compat risk with this feature, this flag can be controlled via Finch. This will allow us to rollback with a server-side config change if needed.

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M105

Anticipated spec changes

N/A

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5137515594383360

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specification

https://drafts.csswg.org/css-overflow/#overflow-properties

Summary

This change allows developers to use the existing `overflow` property with replaced elements that paint outside the content-box. Paired with `object-view-box` this can be used to create an image with a custom glow or shadow applied, with proper ink-overflow behavior like a CSS shadow would have.

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on replaced elements (img, video, canvas). Currently `overflow:visible` in a developer stylesheet on such elements is ignored during paint and the content is clipped to the element's content-box. With this feature, `overflow:visible` will result in content outside the element's content-box to paint as ink overflow. We've collected use counter data to measure the number of sites which could be affected by this. The use counter data collected over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below. * The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%. * The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

That's not nothing. Any idea what breakage may look like?

Can we maybe collect histograms on *how much* overflow would occur in those cases? (maybe with ClusterTelemetry initially, to get a rough idea in the lab)

 

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

[Khushal Sagar]

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specification

https://drafts.csswg.org/css-overflow/#overflow-properties

Summary

This change allows developers to use the existing `overflow` property with replaced elements that paint outside the content-box. Paired with `object-view-box` this can be used to create an image with a custom glow or shadow applied, with proper ink-overflow behavior like a CSS shadow would have.

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on replaced elements (img, video, canvas). Currently `overflow:visible` in a developer stylesheet on such elements is ignored during paint and the content is clipped to the element's content-box. With this feature, `overflow:visible` will result in content outside the element's content-box to paint as ink overflow. We've collected use counter data to measure the number of sites which could be affected by this. The use counter data collected over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below. * The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%. * The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

That's not nothing. Any idea what breakage may look like?

Can we maybe collect histograms on *how much* overflow would occur in those cases? (maybe with ClusterTelemetry initially, to get a rough idea in the lab)

I ran an analysis on CT using top 100k sites for desktop and top 10k sites on mobile. The raw numbers are here: desktop and mobile, and the rough patch to collect this data. The highlights from the analysis are below:

• The number of sites which override the default CSS to allow overflow *and* also had overflow during painting was 13 out of 10k on mobile and 39 out of 63k on desktop (only 63k sites yielded results out of 100k).
  
  
• I measured the percentage of area painted outside the content box out of the total painted area. The highest was 88% on desktop and 70% on mobile.

I manually went through ~10 sites on both desktop and mobile. For the ones which repro-ed, the breakage was losing rounded corners because border-radius doesn't clip the content if 'overflow' is 'visible'. In fact a few sites had the same code, likely coming from customerly based on class names and the UX. There was one case where an image (used in the background) had object-fit:cover and overflowed outside the content box now. I've attached screenshots for both of these.

Overall I didn't see any case where the overflow occluded any other content on the page.

[Yoav Weiss]

On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmps...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specification

https://drafts.csswg.org/css-overflow/#overflow-properties

Summary

This change allows developers to use the existing `overflow` property with replaced elements that paint outside the content-box. Paired with `object-view-box` this can be used to create an image with a custom glow or shadow applied, with proper ink-overflow behavior like a CSS shadow would have.

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on replaced elements (img, video, canvas). Currently `overflow:visible` in a developer stylesheet on such elements is ignored during paint and the content is clipped to the element's content-box. With this feature, `overflow:visible` will result in content outside the element's content-box to paint as ink overflow. We've collected use counter data to measure the number of sites which could be affected by this. The use counter data collected over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below. * The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%. * The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

That's not nothing. Any idea what breakage may look like?

Can we maybe collect histograms on *how much* overflow would occur in those cases? (maybe with ClusterTelemetry initially, to get a rough idea in the lab)

I ran an analysis on CT using top 100k sites for desktop and top 10k sites on mobile. The raw numbers are here: desktop and mobile, and the rough patch to collect this data. The highlights from the analysis are below:

• The number of sites which override the default CSS to allow overflow *and* also had overflow during painting was 13 out of 10k on mobile and 39 out of 63k on desktop (only 63k sites yielded results out of 100k).
  
  
• I measured the percentage of area painted outside the content box out of the total painted area. The highest was 88% on desktop and 70% on mobile.

I'm not sure what that means in practice. Can you elaborate? Have you looked at extreme cases to see the impact there?

 

I manually went through ~10 sites on both desktop and mobile. For the ones which repro-ed, the breakage was losing rounded corners because border-radius doesn't clip the content if 'overflow' is 'visible'. In fact a few sites had the same code, likely coming from customerly based on class names and the UX. There was one case where an image (used in the background) had object-fit:cover and overflowed outside the content box now. I've attached screenshots for both of these.

Overall I didn't see any case where the overflow occluded any other content on the page.

That's reassuring! :)

 

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Khushal Sagar]

On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specification

https://drafts.csswg.org/css-overflow/#overflow-properties

Summary

This change allows developers to use the existing `overflow` property with replaced elements that paint outside the content-box. Paired with `object-view-box` this can be used to create an image with a custom glow or shadow applied, with proper ink-overflow behavior like a CSS shadow would have.

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on replaced elements (img, video, canvas). Currently `overflow:visible` in a developer stylesheet on such elements is ignored during paint and the content is clipped to the element's content-box. With this feature, `overflow:visible` will result in content outside the element's content-box to paint as ink overflow. We've collected use counter data to measure the number of sites which could be affected by this. The use counter data collected over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below. * The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%. * The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

That's not nothing. Any idea what breakage may look like?

Can we maybe collect histograms on *how much* overflow would occur in those cases? (maybe with ClusterTelemetry initially, to get a rough idea in the lab)

I ran an analysis on CT using top 100k sites for desktop and top 10k sites on mobile. The raw numbers are here: desktop and mobile, and the rough patch to collect this data. The highlights from the analysis are below:

• The number of sites which override the default CSS to allow overflow *and* also had overflow during painting was 13 out of 10k on mobile and 39 out of 63k on desktop (only 63k sites yielded results out of 100k).
  
  
• I measured the percentage of area painted outside the content box out of the total painted area. The highest was 88% on desktop and 70% on mobile.

I'm not sure what that means in practice. Can you elaborate? Have you looked at extreme cases to see the impact there?

Sorry, I should've added more details. :) I was looking for breakages with 2 numbers: sites with the largest number of overflowing pixels (such that other content could be occluded); sites with the largest percentage of image content outside the content box. But I realize the former is probably better to identify breakages.

Looking at the top 10 sites, the worst affected is liveops.com. This has cases which use object-fit:cover so the image scales to a size bigger than its content rect and developer CSS overrides overflow to visible. Unfortunately, interacting more with this site, I did see images which are drawing above other content (screenshot attached) as you scroll down. This pattern showed up on the rest of the sites with high overflow numbers too (another example with screenshot attached).

This kind of breakage is expected with this change. I'm not sure where to put the cutoff to identify sites with significant breakage, but there are at least 30 sites (out of 63k) that have images with more than 100px of overflow. The fix for the developer is to trace down the source of the overflow override and remove it.

I'm not sure what's the recommended way to progress with a behaviour change like this given these numbers, the instances of affected sites seems low. Since the fix is simple, but hard to diagnose, one option could be to add a warning to the console: "overflow:visible now causes images to draw outside their bounds. Please make sure this style is intentional" for a few releases (credits to @Vladimir Levin for the idea). Would that suffice?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Taylor]

This feels like a fairly challenging bug to diagnose out without a DevTools issue (or similar console message that links to some useful docs, as you proposed). Would we have the ability to conditionally create these for some overflow threshold value?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com.

[Khushal Sagar]

Sure, we can do this conditionally based on the area of overflow. I'd be inclined to always do it if the UA style is overridden to allow overflow for at least a few releases. Since it's likely that existing sites are not overriding this style intentionally (because currently it's a no-op). Just to catch cases which don't show up in local testing because scaling of the image (with properties like object-fit) can depend on the form factor of the device.

[Khushal Sagar]

Hey folks,

I'm summarizing the steps to mitigate the compat risk with this feature based on the feedback:

• Add a warning to the console when a developer style would permit replaced elements to overflow. The patch to add that is here and documentation to help developers debug, which is referenced in the console warning, is here. We can pre-emptively add this warning to M105 and ship the feature in M106 to have a one release window before the behaviour changes.
  
  
• Send an email to the webmaster of sites surfaced in the CT analysis which already have the styles that trigger the warning above.

In addition to the above, the feature can be turned off with a server-side config using finch if there is any severe breakage.

Please let me know if the above suffices.

Thanks.

Khushal

[Yoav Weiss]

Thanks Khushal! :)

The breakage seems potentially significant (at worst, makes the site visually broken and unusable), and the percentage of breakage seems above the threshold we typically consider safe.

At the same time this seems like a positive change, and our friends at Mozilla consider it "worth prototyping".

Would it be possible to consider this as a deprecation of the old behavior, and run the console issue (+deprecation warnings and outreach to affected sites) for a few milestones, to try and drive the usage down before flipping this change to be on by default? Maybe also get some documentation out there and work with devrel folks to make sure folks are aware of this coming change?

Does that sound reasonable?

Cheers,

Yoav

On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:

Hey folks,

I'm summarizing the steps to mitigate the compat risk with this feature based on the feedback:

• Add a warning to the console when a developer style would permit replaced elements to overflow. The patch to add that is here and documentation to help developers debug, which is referenced in the console warning, is here. We can pre-emptively add this warning to M105 and ship the feature in M106 to have a one release window before the behaviour changes.
  
  
• Send an email to the webmaster of sites surfaced in the CT analysis which already have the styles that trigger the warning above.

In addition to the above, the feature can be turned off with a server-side config using finch if there is any severe breakage.

Please let me know if the above suffices.

Thanks.

Khushal

On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar <khusha...@chromium.org> wrote:

On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <mike...@chromium.org> wrote:

On 7/13/22 3:04 PM, Khushal Sagar wrote:

On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmps...@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%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+unsubscribe@chromium.org.

[Khushal Sagar]

On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Khushal! :)

The breakage seems potentially significant (at worst, makes the site visually broken and unusable), and the percentage of breakage seems above the threshold we typically consider safe.

At the same time this seems like a positive change, and our friends at Mozilla consider it "worth prototyping".

Would it be possible to consider this as a deprecation of the old behavior, and run the console issue (+deprecation warnings and outreach to affected sites) for a few milestones, to try and drive the usage down before flipping this change to be on by default? Maybe also get some documentation out there and work with devrel folks to make sure folks are aware of this coming change?

Does that sound reasonable?

Thanks for the suggestion Yoav. This sounds reasonable. I've reached out to the devrel folks to do more outreach about this change. I'll update this thread with the plan for it. The console issue and deprecation warnings have been added in M105.

I looked into adding a use counter for sites which have real breakage, since the current metric tracks whether the computed style *could* permit allow but not whether there is actual overflow at paint time. And unfortunately computing potential overflow is not easy to add. The CT analysis I ran earlier did this by turning the feature on and tracking actual overflow generated by the element. So a couple of questions for moving forward:

- Would it be okay to turn the feature on in beta and 1% stable (in M105) to collect metrics for the sites with real breakage and the extent of this breakage (how many pixels of overflow do we see). This should be lower than the counter of 0.017%.

- What's the number (in terms of page loads affected) we should be targeting before this would be safe?

 

Cheers,

Yoav

On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:

Hey folks,

I'm summarizing the steps to mitigate the compat risk with this feature based on the feedback:

• Add a warning to the console when a developer style would permit replaced elements to overflow. The patch to add that is here and documentation to help developers debug, which is referenced in the console warning, is here. We can pre-emptively add this warning to M105 and ship the feature in M106 to have a one release window before the behaviour changes.
  
  
• Send an email to the webmaster of sites surfaced in the CT analysis which already have the styles that trigger the warning above.

In addition to the above, the feature can be turned off with a server-side config using finch if there is any severe breakage.

Please let me know if the above suffices.

Thanks.

Khushal

On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar <khusha...@chromium.org> wrote:

On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <mike...@chromium.org> wrote:

On 7/13/22 3:04 PM, Khushal Sagar wrote:

On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khusha...@chromium.org> wrote:

Contact emails

khusha...@chromium.org, vmp...@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%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+...@chromium.org.

[jmedley via Chromestatus]

Yoav, Im putting together the beta post draft. Is the deprecation being extended? Joe

[Yoav Weiss]

On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <khusha...@chromium.org> wrote:

On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Khushal! :)

The breakage seems potentially significant (at worst, makes the site visually broken and unusable), and the percentage of breakage seems above the threshold we typically consider safe.

At the same time this seems like a positive change, and our friends at Mozilla consider it "worth prototyping".

Would it be possible to consider this as a deprecation of the old behavior, and run the console issue (+deprecation warnings and outreach to affected sites) for a few milestones, to try and drive the usage down before flipping this change to be on by default? Maybe also get some documentation out there and work with devrel folks to make sure folks are aware of this coming change?

Does that sound reasonable?

Thanks for the suggestion Yoav. This sounds reasonable. I've reached out to the devrel folks to do more outreach about this change. I'll update this thread with the plan for it. The console issue and deprecation warnings have been added in M105.

I looked into adding a use counter for sites which have real breakage, since the current metric tracks whether the computed style *could* permit allow but not whether there is actual overflow at paint time. And unfortunately computing potential overflow is not easy to add. The CT analysis I ran earlier did this by turning the feature on and tracking actual overflow generated by the element. So a couple of questions for moving forward:

- Would it be okay to turn the feature on in beta and 1% stable (in M105) to collect metrics for the sites with real breakage and the extent of this breakage (how many pixels of overflow do we see). This should be lower than the counter of 0.017%.

That sounds like a great way to gather data! (assuming the relevant Chrome processes are followed)

Would be good to gather a histogram of overflowed pixels, to get a sense of "small breakage" vs. "large breakage".

  

- What's the number (in terms of page loads affected) we should be targeting before this would be safe?

From my perspective, I'd be comfortable shipping this if we're seeing less than 0.003% of page loads in the "large breakage" bucket (say more than ~5000 overflowing pixels, assuming that number makes sense).

+Andre Bandarra - for devrel opinions on this.

  

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com.

[Khushal Sagar]

On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <khusha...@chromium.org> wrote:

On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Khushal! :)

The breakage seems potentially significant (at worst, makes the site visually broken and unusable), and the percentage of breakage seems above the threshold we typically consider safe.

At the same time this seems like a positive change, and our friends at Mozilla consider it "worth prototyping".

Would it be possible to consider this as a deprecation of the old behavior, and run the console issue (+deprecation warnings and outreach to affected sites) for a few milestones, to try and drive the usage down before flipping this change to be on by default? Maybe also get some documentation out there and work with devrel folks to make sure folks are aware of this coming change?

Does that sound reasonable?

Thanks for the suggestion Yoav. This sounds reasonable. I've reached out to the devrel folks to do more outreach about this change. I'll update this thread with the plan for it. The console issue and deprecation warnings have been added in M105.

I looked into adding a use counter for sites which have real breakage, since the current metric tracks whether the computed style *could* permit allow but not whether there is actual overflow at paint time. And unfortunately computing potential overflow is not easy to add. The CT analysis I ran earlier did this by turning the feature on and tracking actual overflow generated by the element. So a couple of questions for moving forward:

- Would it be okay to turn the feature on in beta and 1% stable (in M105) to collect metrics for the sites with real breakage and the extent of this breakage (how many pixels of overflow do we see). This should be lower than the counter of 0.017%.

That sounds like a great way to gather data! (assuming the relevant Chrome processes are followed)

Would be good to gather a histogram of overflowed pixels, to get a sense of "small breakage" vs. "large breakage".

  

- What's the number (in terms of page loads affected) we should be targeting before this would be safe?

From my perspective, I'd be comfortable shipping this if we're seeing less than 0.003% of page loads in the "large breakage" bucket (say more than ~5000 overflowing pixels, assuming that number makes sense).

+Andre Bandarra - for devrel opinions on this.

Currently we're recording a UseCounter when any breakage would happen, i.e, there is any pixel overflow. If it helps to have a UseCounter for overflow above a threshold, I'm happy to add that too.

We do have an UMA metric which measures the number of overflowing pixels when there is overflow but it's for all images rendered. I can tie it to the UseCounter so we can also know the number of affected page loads with large breakage. I'll wait till the end of the week for more feedback, otherwise assume 5k is a good threshold for large breakage.

[Khushal Sagar]

We have UseCounter data from M105 stable to quantify the large breakage for this feature. Large is a page load where any image, video or canvas drawn on the page paints over 5k CSS pixels outside its content-box. The precise numbers (with page load count) are here (sorry can't share the details externally).

In terms of percentage, Windows/Mac had ~0.006% page loads fall in the large breakage category and Android had ~0.007%.

[Yoav Weiss]

Thanks for meticulously gathering that data!!

Just to give a rough idea - 5K pixels would be 50x100 pixels, which is noticeable breakage but not necessarily an insurmountable one.

The numbers are a bit higher than I'd like, but at the same time, this enables new capabilities and we're not walking this path alone.

Given the above, LGTM1 for a careful and monitored rollout, accompanied with DevRel folks supporting y'all in communicating this change to developers.

What are the timelines you have in mind? Is there some way to use Deprecation Reporting to help us here?

[Khushal Sagar]

On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for meticulously gathering that data!!

Just to give a rough idea - 5K pixels would be 50x100 pixels, which is noticeable breakage but not necessarily an insurmountable one.

The numbers are a bit higher than I'd like, but at the same time, this enables new capabilities and we're not walking this path alone.

Given the above, LGTM1 for a careful and monitored rollout, accompanied with DevRel folks supporting y'all in communicating this change to developers.

What are the timelines you have in mind? Is there some way to use Deprecation Reporting to help us here?

I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a week before each progression in M107. The release will go to stable ~October 25th (schedule). 

In terms of outreach a console warning and a deprecation warning was added in M105 for cases where the element's computed style can cause this behaviour change. I've also reached out to the dev rel folks for a targeted email to affected sites that came up through our CT analysis.

[Mike Taylor]

LGTM2

[Khushal Sagar]

On Mon, Sep 12, 2022 at 4:59 AM Andre Bandarra <andr...@google.com> wrote:

CC @Cheney Tsai, @Una Kravets, @Kadir Topal 

From a DevRel perspective, the three questions in my mind are:

• Are affected developers aware of the change?
• I understand they were notified via a console warning / deprecation warning. It'd be great to get a sense of how effective the communication was (ie: has usage significantly decreased since the warnings?).

M105 stable rollout started around August 30th so it's been less than a couple of weeks. The UMA for tracking usage of overflow:visible on these elements is here and there hasn't been any change. Note that this is higher than the use counter since it tracks whether the element had a style that could cause overflow, not whether it actually painted with overflow.

• Have we given them enough time for developers to react to the change?
• This is less about how complex a change is and more about ensuring developers can fit the change into their planning cycle (eg: quarterly OKRs) and avoiding generating unplanned/urgent work, if possible. It does seem to me the timelines described are short.

Do you have a suggestion for an appropriate time to wait after the email notification to sites we discovered via CT? Given the use counter for significant breakage is low (~0.006%), I was hoping 6 weeks targeting M107 would suffice. But we can push it out until M108 which gives it 10 weeks if needed.

• Are developers somehow blocked in implementing the change?
• The change seems quite straightforward, but sometimes developers are blocked in surprising ways. Is there a channel developers can provide feedback on?

The email notification directs developers to the chromium issue tracker. That'll help in documenting a fix for any unforeseen issues and redirecting developers in case we receive duplicate bugs. 

•  

Andre

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzdatCQP2_iBTPDo2gScAM1PH6Zmtj87UJD4g1UfmbsxA%40mail.gmail.com.

[Andre Bandarra]

CC @Cheney Tsai, @Una Kravets, @Kadir Topal 

From a DevRel perspective, the three questions in my mind are:

• Are affected developers aware of the change?
• I understand they were notified via a console warning / deprecation warning. It'd be great to get a sense of how effective the communication was (ie: has usage significantly decreased since the warnings?).

• Have we given them enough time for developers to react to the change?
• This is less about how complex a change is and more about ensuring developers can fit the change into their planning cycle (eg: quarterly OKRs) and avoiding generating unplanned/urgent work, if possible. It does seem to me the timelines described are short.

• Are developers somehow blocked in implementing the change?
• The change seems quite straightforward, but sometimes developers are blocked in surprising ways. Is there a channel developers can provide feedback on? 

Andre

On Mon, 12 Sept 2022 at 01:54, Mike Taylor <mike...@chromium.org> wrote:

[Nic Jansma]

Hi everyone!

I've started seeing this deprecation being reported via Reporting API (through a ReportingObserver and Reporting API pings) on a few sites that are being measured for RUM.

The actual deprecation report was very hard to decode, as all that was included was the ID (4201) and a confusing message (which looks like an internal error message). e.g.:

{
  "body": {
    "anticipatedRemoval": null,
    "columnNumber": 12345,
    "id": "4201",
    "lineNumber": 1,
    "message": "Deprecation messages are stored in the devtools-frontend repo at front_end/models/issues_manager/DeprecationIssue.ts",
    "sourceFile": null
  },
  "type": "deprecation",
  "url": "https://example.com"
}

It took some help from Yoav to understand 4201 is this specific issue (I think).  With the details here, I can begin to understand (as a developer) how to address the reports.

I filed a Chromium bug to ask for more details in the deprecation report:

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

[Yoav Weiss]

Thanks so much for reporting this, Nic! :) (pun not intended)

A few generic questions:

• Do you have outreach channels to your customers where those deprecations are being reported? Are they presented as e.g. warnings in their dashboards?
• What information would you find useful in the reports that would make it easier to communicate the issue and potential solutions to your customers?

And finally, a more specific question: can you share numbers regarding the rough number of customer origins that are hitting this? Even an order of magnitude would be helpful.

Cheers,

Yoav