A Couple Changes Coming in Chrome 108 | CSS-Tricks

0
12

“A change to overflow on replaced elements in CSS”:

From Chrome 108, the following replaced elements respect the overflow property: img, video and canvas. In earlier versions of Chrome, this property was ignored on these elements.

This means that an image which was earlier clipped to its content box can now draw outside those bounds if specified to do so in a style sheet.

So, image, video, and canvas elements that were once clipped might display the overflow when Chrome 108 ships. The noted situations where this might affect your existing work:

  • The object-fit property is used to scale the image and fill the box. If the aspect ratio does not match the box, the image will draw outside of the bounds.
  • The border-radius property makes a square image look like a circle, but because overflow is visible the clipping no longer occurs.
  • Settings inherit: all and causing all properties to inherit, including overflow.

Worth reading the full article for code examples, but the solution for unwanted visible overflow is overriding the UA’s default overflow: visible with overflow: clip:

img 
  overflow: clip;

“Prepare for viewport resize behavior changes coming to Chrome on Android”:

In November, with the release of Chrome 108, Chrome will make some changes to how the Layout Viewport behaves when the on-screen keyboard (OSK) gets shown. With this change, Chrome on Android will no longer resize the Layout Viewport, and instead resize only the Visual Viewport. This will bring Chrome on Android’s behavior up to par with that of Chrome on iOS and Safari on iOS.

This is a change related to the common headaches of working with viewport units and fixed positioning on mobile touch devices. We’ve covered (and tried solving) it over the years:

The change means that Chrome on Android will no longer resize the Layout Viewport when the on-screen keyboard is shown. So, the computed values ​​of viewport units will no longer shrink when a device’s keyboard is displayed. Same goes for elements that are designed to take up the full viewport no longer shrinking to accommodate the keyboard. And no longer will a fixed-position element wind up who knows where when the keyboard pops up.

This brings more consistent cross-browser behavior that is in line with Chrome, Safari, and Edge on iOS and iPadOS. That’s great, even if the updated behavior is less than ideal because the keyboard UI can still cover and obscure elements that get in its way.

If you prefer elements to remain visible when that happens, it’s worth looking at a solution Chris shared a long while back that uses the prefixed webkit-fill-available properties:

body 
  min-height: 100vh;
  min-height: -webkit-fill-available;

html 
  height: -webkit-fill-available;

That uses the available space in the viewport rather than what’s covered by the UI… but Chrome currently ignores the property, and I’d bet the nickel in my pocket that it is unlikely to start respecting it in the 108 release. That may be a moot point, though, as Chrome 108 also introduces support for small, large, and dynamic viewport units, which are already supported in Safari and Firefox.

Desktop

Chrome Firefox IE Edge Safari
108 101 no no 15.4

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
no 106 no 15.4

Source

LEAVE A REPLY

Please enter your comment!
Please enter your name here