Et par ændringer kommer i Chrome 108

"En ændring til overløb på udskiftede elementer i CSS":

Fra Chrome 108 respekterer følgende erstattede elementer overløbsegenskaben: img, video , canvas. I tidligere versioner af Chrome blev denne egenskab ignoreret på disse elementer.

Det betyder, at et billede, som tidligere blev klippet til dets indholdsfelt, nu kan tegne uden for disse grænser, hvis det er angivet til at gøre det i et typografiark.

Så billed-, video- og lærredselementer, der engang blev klippet, kan vise overløbet, når Chrome 108 sendes. De nævnte situationer, hvor dette kan påvirke dit eksisterende arbejde:

•  object-fit egenskaben bruges til at skalere billedet og fylde boksen. Hvis billedformatet ikke stemmer overens med boksen, tegnes billedet uden for grænserne.
•  border-radius egenskab får et kvadratisk billede til at ligne en cirkel, men fordi overflow er synlig, sker klipningen ikke længere.
• Lokal område inherit: all og får alle ejendomme til at arve, herunder overflow.

Værd at læse hele artiklen for kodeeksempler, men løsningen for uønsket synligt overløb tilsidesætter UA's standard overflow: visible med overflow: clip:

img {
  overflow: clip;
}

"Forbered dig på ændringer i visningsportens adfærdsændringer, der kommer til Chrome på Android":

I november, med udgivelsen af ​​Chrome 108, vil Chrome foretage nogle ændringer i, hvordan Layout Viewport opfører sig, når skærmtastaturet (OSK) vises. Med denne ændring vil Chrome på Android ikke længere ændre størrelsen på layoutvisningsporten, og i stedet ændre størrelsen på kun den visuelle visningsport. Dette vil bringe Chrome på Androids adfærd op på niveau med Chrome på iOS og Safari på iOS.

Dette er en ændring relateret til den almindelige hovedpine ved at arbejde med viewport-enheder og fast positionering på mobile touch-enheder. Vi har dækket (og prøvet at løse) det gennem årene:

Ændringen betyder, at Chrome på Android ikke længere vil ændre størrelsen på layoutvisningen, når tastaturet på skærmen vises. Så de beregnede værdier af viewport-enheder vil ikke længere krympe, når en enheds tastatur vises. Det samme gælder for elementer, der er designet til at optage hele visningsporten, der ikke længere krymper for at rumme tastaturet. Og ikke længere vil et element med fast position vinde op, som ved hvor, når tastaturet dukker op.

Dette giver en mere ensartet adfærd på tværs af browsere, der er på linje med Chrome, Safari og Edge på iOS og iPadOS. Det er fantastisk, selvom den opdaterede adfærd er mindre end ideel, fordi tastaturets brugergrænseflade stadig kan dække og skjule elementer, der kommer i vejen.

Hvis du foretrækker, at elementer forbliver synlige, når det sker, er det værd at se på en løsning Chris delte for lang tid siden der bruger præfikset webkit-fill-available ejendom:

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

Det bruger den tilgængelige plads i viewporten i stedet for det, der er dækket af brugergrænsefladen... men Chrome ignorerer i øjeblikket egenskaben, og jeg vil vædde på, at det er usandsynligt, at det begynder at respektere det i 108-udgivelsen. Det kan dog være et problem, som Chrome 108 introducerer også understøttelse af små, store og dynamiske viewport-enheder, som allerede understøttes i Safari og Firefox.