Intent to Prototype: 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

Motivation

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. Note that the svg spec already respects this property and shared element transitions introduces a replaced element which also needs this functionality. One of the motivations of this feature is to apply this property and related properties (like `overflow-clip-margin`) consistently to all replaced elements.

Note: This is a follow up to this previous intent to support the same functionality. The proposal has been updated based on feedback.

Initial public proposal

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

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.

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

Yes

Flag name

CSSOverflowForReplacedElements

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5137515594383360

This intent message was generated by Chrome Platform Status.

[Arthur Hemery]

Hi!
I've run through this as a security reviewer, and my understanding is that previous discussions led to this issue being filed, to restrict iframe overflow.
I see this is in the CSS working group so is this restriction planned for all embedded content in general and not only shared elements? Also has this been spec'd yet or was there any progress?
The rest looked fine, thanks!
Arthur

[Khushal Sagar]

On Wed, Jun 29, 2022 at 11:24 AM Arthur Hemery <ahe...@google.com> wrote:

Hi!
I've run through this as a security reviewer, and my understanding is that previous discussions led to this issue being filed, to restrict iframe overflow.
I see this is in the CSS working group so is this restriction planned for all embedded content in general and not only shared elements? Also has this been spec'd yet or was there any progress?

The restriction is planned for all embedded content. This change includes the UA CSS to enforce the restriction and has the specific elements that it will be applied to (iframe, object, embed). There is no such restriction on shared elements in the context of Shared Element Transitions or the new pseudo elements introduced for that feature.

This has been spec'd. The specific edits are in these 2 changes: define overflow on replaced elements and new UA CSS.

[Arthur Hemery]

Thanks for the reply!
Let me rephrase to see if my understanding is correct:
"To handle elements generated by shared element transition (images - replaced elements), CSS overflow needs to be extended to replaced elements that are usually not supported. Since iframes, embed, etc. are also replaced elements, they need to be explicitly excluded from the extension. This has been spec'd already".

If that's the case then it's all good, sorry for the trouble :)
Cheers,
Arthur

[Arthur Hemery]

Hey Khushal,
Just a friendly ping on that since I see you've sent the I2S already.
Cheers,
Arthur

[Khushal Sagar]

Your conclusion above is correct.

Apologies for not replying earlier. I assumed we were already on the same page. :)

[Arthur Hemery]

No problem, thanks!