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
<http://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
<mailto: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?
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/c1f075ff-0834-7c16-fb6a-4cb6f5674e14%40chromium.org.
