On Wed, Jun 29, 2022 at 11:24 AM Arthur Hemery <ahem...@google.com> wrote:
> > Hi! > I've run through this as a security reviewer, and my understanding is that > previous discussions led to this issue > <https://github.com/w3c/csswg-drafts/issues/7143> 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 <https://github.com/tabatkins/html/commit/16943c6e9231a4f5fab89c65ae7ddbe49f40f01b#:~:text=iframe%2C%20object%2C%20embed,%7D%3C/code%3E%3C/pre%3E> 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 <https://github.com/WICG/shared-element-transitions/blob/main/explainer.md> 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 <https://github.com/w3c/csswg-drafts/commit/a679cd100dcf479af23b33b033bbe4c959d78258> and new UA CSS <https://github.com/tabatkins/html/commit/16943c6e9231a4f5fab89c65ae7ddbe49f40f01b> . > The rest looked fine, thanks! > Arthur > On Friday, June 24, 2022 at 10:45:44 PM UTC+2 khusha...@chromium.org > wrote: > >> Contact emailskhusha...@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 >> >> Specificationhttps://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 componentBlink>CSS >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >> >> 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 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/0ynSPqb-k04/m/CEoVHLREAAAJ> >> to >> support the same functionality. The proposal has been updated based on >> feedback. >> >> Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7144 >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/750 >> >> TAG review statusPending >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> Flag nameCSSOverflowForReplacedElements >> >> Requires code in //chrome?False >> >> Tracking bughttps://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 >> <https://chromestatus.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/CAMLuWUwv7PrZJG3-5ThmmkR%3DQp5mwq3RopaLNf-pbmr0XcQq-w%40mail.gmail.com.
