Algumas mudanças chegando no Chrome 108

“Uma mudança para estouro em elementos substituídos em CSS”:

No Chrome 108, os seguintes elementos substituídos respeitam a propriedade de estouro: img, video e canvas. Nas versões anteriores do Chrome, essa propriedade era ignorada nesses elementos.

Isso significa que uma imagem que foi recortada anteriormente em sua caixa de conteúdo agora pode ser desenhada fora desses limites, se especificado para fazê-lo em uma folha de estilo.

Portanto, os elementos de imagem, vídeo e tela que foram recortados podem exibir o estouro quando o Chrome 108 for lançado. As situações observadas em que isso pode afetar seu trabalho existente:

• A object-fit é usada para dimensionar a imagem e preencher a caixa. Se a proporção não corresponder à caixa, a imagem será desenhada fora dos limites.
• A border-radius faz uma imagem quadrada parecer um círculo, mas porque overflow é visível, o recorte não ocorre mais.
• Configuração inherit: all e fazendo com que todas as propriedades sejam herdadas, incluindo overflow.

Vale a pena ler o artigo completo para exemplos de código, mas a solução para estouro visível indesejado é substituir o padrão do UA overflow: visible de overflow: clip:

img {
  overflow: clip;
}

“Prepare-se para mudanças de comportamento de redimensionamento da janela de visualização que chegam ao Chrome no Android”:

Em novembro, com o lançamento do Chrome 108, o Chrome fará algumas alterações na forma como o Layout Viewport se comporta quando o teclado na tela (OSK) é exibido. Com essa alteração, o Chrome no Android não redimensionará mais o Layout Viewport e, em vez disso, redimensionará apenas o Visual Viewport. Isso fará com que o comportamento do Chrome no Android fique igual ao do Chrome no iOS e do Safari no iOS.

Esta é uma mudança relacionada às dores de cabeça comuns de trabalhar com unidades de viewport e posicionamento fixo em dispositivos móveis de toque. Nós cobrimos (e tentamos resolvê-lo) ao longo dos anos:

A alteração significa que o Chrome no Android não redimensionará mais a janela de visualização de layout quando o teclado na tela for exibido. Portanto, os valores calculados das unidades de viewport não serão mais reduzidos quando o teclado de um dispositivo for exibido. O mesmo vale para elementos projetados para ocupar toda a janela de visualização, não diminuindo mais para acomodar o teclado. E não mais um elemento de posição fixa acabará quem sabe onde quando o teclado aparecer.

Isso traz um comportamento entre navegadores mais consistente que está alinhado com Chrome, Safari e Edge no iOS e iPadOS. Isso é ótimo, mesmo que o comportamento atualizado não seja o ideal, porque a interface do usuário do teclado ainda pode cobrir e ocultar elementos que atrapalham.

Se você preferir que os elementos permaneçam visíveis quando isso acontecer, vale a pena dar uma olhada em um solução que Chris compartilhou há muito tempo que usa o prefixo webkit-fill-available propriedade:

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

Isso usa o espaço disponível na janela de visualização em vez do que é coberto pela interface do usuário... mas o Chrome atualmente ignora a propriedade, e eu aposto que é improvável que comece a respeitá-la na versão 108. Isso pode ser um ponto discutível, no entanto, como O Chrome 108 também apresenta suporte para unidades de viewport pequenas, grandes e dinâmicas, que já são suportadas no Safari e Firefox.