O Chrome 152 chegou ao canal estável em 25 de agosto com uma lista grande o bastante para alimentar vários changelogs. Para quem desenvolve para a web, porém, quatro grupos merecem atenção: pseudo-elementos acessíveis por JavaScript, novos recursos de cor e acessibilidade, uma API para medir pressão de CPU e controles mais finos sobre conexões.
Não é uma versão que pede refatoração imediata. É uma versão de radar: algumas APIs resolvem buracos antigos da plataforma, mas precisam entrar com detecção de suporte e sem transformar um recurso recém-estável num requisito universal.
Pseudo-elementos deixam de ser invisíveis para o JavaScript
A interface CSSPseudoElement agora cobre ::backdrop, ::scroll-marker e os pseudo-elementos usados em View Transitions. Até aqui, essas partes renderizadas pelo CSS eram difíceis de observar ou animar a partir de APIs JavaScript sem criar elementos auxiliares no DOM.
O ganho não é licença para levar toda animação ao script. CSS continua sendo a primeira opção para estados visuais. A novidade interessa quando uma biblioteca precisa coordenar uma animação, inspecionar um pseudo-elemento ou ligá-lo a uma linha do tempo que não cabe apenas em seletores e propriedades.
Na mesma área, a função CSS alpha() permite derivar uma cor ajustando seu canal alfa. Isso reduz a necessidade de manter versões RGB ou hexadecimais duplicadas só para obter transparências diferentes. É especialmente útil em sistemas de design baseados em variáveis, desde que o fallback continue presente para navegadores sem suporte.
Shadow DOM ganha uma ponte de acessibilidade
Reference Target é uma das mudanças menos chamativas e mais importantes da versão. Ela permite que referências ARIA atravessem a fronteira de uma shadow root. Componentes encapsulados passam a ter um caminho melhor para relacionar controles e rótulos que vivem em árvores diferentes.
Isso ataca uma limitação real de Web Components: o encapsulamento que organiza CSS e DOM também pode impedir relações como as expressas por aria-labelledby e aria-describedby. A chegada no Chrome não elimina a necessidade de testar com leitores de tela nem resolve compatibilidade nos outros engines. Ela cria uma peça da plataforma que bibliotecas de componentes podem começar a experimentar com melhoria progressiva.
CPU Performance API mede pressão, não um placar absoluto
A CPU Performance API expõe informações sobre desempenho de CPU para ajudar aplicações a adaptar sua carga. Pense em reduzir qualidade visual, frequência de processamento ou trabalho em segundo plano quando o dispositivo está sob pressão.
O uso interessante não é mostrar “CPU em 73%” numa tela. É fechar um ciclo de adaptação: medir uma condição, mudar um comportamento e verificar se a experiência melhora. Como qualquer API ligada ao ambiente do dispositivo, ela também pede cuidado com privacidade, disponibilidade por contexto e diferenças entre máquinas. Use como sinal complementar, não como substituta de métricas de interação, long tasks e dados reais de usuários.
Connection Allowlists levam política de rede para a resposta HTTP
Connection Allowlists permitem que uma origem declare, por cabeçalho HTTP, quais destinos podem receber conexões iniciadas pela página. É uma camada de controle voltada a reduzir comunicações inesperadas e limitar a superfície de saída.
A semelhança com políticas de segurança existentes exige leitura cuidadosa antes de adotar. Inventariar analytics, fontes, APIs, CDNs, WebSockets e integrações de terceiros vem antes de apertar qualquer lista. Uma política incompleta pode quebrar o produto; uma lista ampla demais vira decoração. O melhor começo é observar o tráfego real e testar em ambiente controlado.
Outras mudanças que podem aparecer no backlog
- o atributo global
autocorrectdá ao HTML um controle explícito sobre correção automática; OpaqueRangerepresenta seleções dentro de controles de formulário;getDisplayMedia()ganha preferência de áudio para fluxos de compartilhamento de tela;- PWAs no macOS recebem melhorias de atribuição de notificações;
- o Chrome abre um novo período de teste de descontinuação para XSLT.
Para equipes, a ação prática é curta: rodar a suíte no Chrome 152, revisar componentes com Shadow DOM e colocar as APIs novas atrás de feature detection. Uma versão estável do Chrome é sinal para começar a integrar, não prova de que toda a web já chegou ao mesmo lugar.