On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <miketa...@chromium.org> wrote:
> On 7/13/22 3:04 PM, Khushal Sagar wrote: > > > > On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <yoavwe...@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 <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <khushalsa...@chromium.org> >>>> wrote: >>>> >>>>> Contact emails khushalsa...@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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>> >>>>> 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 >>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0> >>> and mobile >>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>, >>> and the rough patch >>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485> 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 <vmp...@chromium.org> for the idea). > Would that suffice? > > This feels like a fairly challenging bug to diagnose out without a DevTools > issue <https://developer.chrome.com/docs/devtools/issues/> (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? > 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. > > >> >>> 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 >>> <https://www.customerly.io/> 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! :) >> >> >>> >>> >>>> >>>> >>>>> >>>>> *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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/camluwuykjweaqvzcuy15fpbnda68508mny_1z--fcbkxrtz...@mail.gmail.com> >>>>> >>>>> >>>>> 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/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > 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/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- 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/CAMLuWUyXdQajO_TRLurzMmvTP7WeFjkFnYeByN-d%2B3N-6_sFQQ%40mail.gmail.com.
