Ett par ändringar kommer i Chrome 108

"En förändring till överflöd på ersatta element i CSS":

Från Chrome 108 respekterar följande ersatta element överflödesegenskapen: img, video och canvas. I tidigare versioner av Chrome ignorerades den här egenskapen för dessa element.

Detta innebär att en bild som tidigare klippts till innehållsrutan nu kan rita utanför dessa gränser om det anges att göra det i en stilmall.

Så bild-, video- och canvaselement som en gång klipptes kan visa överflödet när Chrome 108 skickas. De noterade situationerna där detta kan påverka ditt befintliga arbete:

• Smakämnen object-fit egenskapen används för att skala bilden och fylla rutan. Om bildförhållandet inte matchar rutan kommer bilden att ritas utanför gränserna.
• Smakämnen border-radius egenskap får en kvadratisk bild att se ut som en cirkel, men därför overflow är synlig sker klippningen inte längre.
• Att lägga plattor inherit: all och få alla egendomar att ärva, inklusive overflow.

Värt att läsa hela artikeln för kodexempel, men lösningen för oönskat synligt spill åsidosätter UA:s standard overflow: visible med overflow: clip:

img {
  overflow: clip;
}

"Förbered dig på förändringar av visningsportens beteendeförändringar som kommer till Chrome på Android":

I november, med lanseringen av Chrome 108, kommer Chrome att göra några ändringar i hur Layout Viewport beter sig när tangentbordet på skärmen (OSK) visas. Med den här ändringen kommer Chrome på Android inte längre att ändra storleken på layoutvisningsporten, och istället ändra storleken på endast den visuella visningsporten. Detta kommer att få Chrome på Androids beteende i nivå med det för Chrome på iOS och Safari på iOS.

Detta är en förändring relaterad till den vanliga huvudvärken med att arbeta med viewport-enheter och fast positionering på mobila pekenheter. Vi har täckt (och försökt lösa) det genom åren:

Ändringen innebär att Chrome på Android inte längre kommer att ändra storlek på layoutvyporten när tangentbordet på skärmen visas. Så de beräknade värdena för viewport-enheter kommer inte längre att krympa när en enhets tangentbord visas. Detsamma gäller för element som är designade för att ta upp hela visningsporten som inte längre krymper för att rymma tangentbordet. Och inte längre kommer ett element med fast position att hamna som vet var när tangentbordet dyker upp.

Detta ger ett mer konsekvent beteende över webbläsare som är i linje med Chrome, Safari och Edge på iOS och iPadOS. Det är bra, även om det uppdaterade beteendet är mindre än idealiskt eftersom tangentbordsgränssnittet fortfarande kan täcka och skymma element som kommer i vägen.

Om du föredrar att element förblir synliga när det händer, är det värt att titta på en lösning Chris delade för länge sedan som använder prefixet webkit-fill-available fast egendom:

body {
  min-height: 100vh;
  min-height: -webkit-fill-available;
}
html {
  height: -webkit-fill-available;
}

Det använder det tillgängliga utrymmet i visningsporten snarare än vad som täcks av användargränssnittet ... men Chrome ignorerar för närvarande egenskapen, och jag skulle satsa på att det är osannolikt att det kommer att börja respektera det i 108-utgåvan. Det kan dock vara en omtvistad fråga, som Chrome 108 introduceras också stöd för små, stora och dynamiska visningsportenheter, som redan stöds i Safari och Firefox.