Et par endringer kommer i Chrome 108

"En endring til overflyt på erstattede elementer i CSS":

Fra Chrome 108 respekterer følgende erstattede elementer overløpsegenskapen: img, video og canvas. I tidligere versjoner av Chrome ble denne egenskapen ignorert på disse elementene.

Dette betyr at et bilde som tidligere ble klippet til innholdsboksen nå kan tegne utenfor disse grensene hvis det er spesifisert for å gjøre det i et stilark.

Så bilde-, video- og lerretselementer som en gang ble klippet, kan vise overløpet når Chrome 108 sendes. De angitte situasjonene der dette kan påvirke ditt eksisterende arbeid:

• De object-fit egenskapen brukes til å skalere bildet og fylle boksen. Hvis sideforholdet ikke samsvarer med boksen, vil bildet tegnes utenfor grensene.
• De border-radius egenskap får et kvadratisk bilde til å se ut som en sirkel, men fordi overflow er synlig skjer ikke klippingen lenger.
• Stille inherit: all og få alle eiendommer til å arve, inkludert overflow.

Verdt å lese hele artikkelen for kodeeksempler, men løsningen for uønsket synlig overløp overstyrer UA sin standard overflow: visible med overflow: clip:

img {
  overflow: clip;
}

"Forbered deg på endringer i visningsportendring som kommer til Chrome på Android":

I november, med utgivelsen av Chrome 108, vil Chrome gjøre noen endringer i hvordan Layout Viewport oppfører seg når skjermtastaturet (OSK) vises. Med denne endringen vil Chrome på Android ikke lenger endre størrelsen på layoutvisningsporten, og i stedet endre størrelsen på bare den visuelle visningsporten. Dette vil bringe Chrome på Androids oppførsel på nivå med Chrome på iOS og Safari på iOS.

Dette er en endring knyttet til den vanlige hodepinen ved å jobbe med viewport-enheter og fast posisjonering på mobile berøringsenheter. Vi har dekket (og prøvd å løse) det gjennom årene:

Endringen betyr at Chrome på Android ikke lenger vil endre størrelsen på Layout Viewport når skjermtastaturet vises. Så de beregnede verdiene til viewport-enheter vil ikke lenger krympe når en enhets tastatur vises. Det samme gjelder elementer som er designet for å ta opp hele visningsporten som ikke lenger krymper for å romme tastaturet. Og ikke lenger vil et element med fast posisjon havne som vet hvor når tastaturet dukker opp.

Dette gir mer konsistent oppførsel på tvers av nettlesere som er på linje med Chrome, Safari og Edge på iOS og iPadOS. Det er flott, selv om den oppdaterte oppførselen er mindre enn ideell fordi tastaturets brukergrensesnitt fortsatt kan dekke og skjule elementer som kommer i veien.

Hvis du foretrekker at elementer forblir synlige når det skjer, er det verdt å se på en løsning Chris delte for lenge siden som bruker prefikset webkit-fill-available eiendom:

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

Det bruker den tilgjengelige plassen i visningsporten i stedet for det som dekkes av brukergrensesnittet ... men Chrome ignorerer for øyeblikket egenskapen, og jeg vil satse på at det er lite sannsynlig at det vil begynne å respektere det i 108-utgivelsen. Det kan være et problem, skjønt, som Chrome 108 introduserer også støtte for små, store og dynamiske visningsportenheter, som allerede støttes i Safari og Firefox.