Google Chrome 98 lançado com COLRv1 para arquivos Emoji menores

Google Chrome recebe correção de emergência para evitar ataques de dia zero
Google Chrome recebe correção de emergência para evitar ataques de dia zero

Mais uma versão do Google Chrome acaba de sair para os usuários que já podem baixar a versão 98 do navegador que foi lançado com COLRv1 para arquivos Emoji menores. Esta é, portanto, uma grande segunda atualização do navegador da Web do Google em 2022. As alterações do Chrome 98 dizem respeito principalmente a melhorias para o desenvolvedor. No entanto, algumas alterações serão perceptíveis pelos usuários comuns.

O COLRv1 nada mais é que uma evolução da COLRv0. Eles trazem recursos visuais mais expressivos na forma de gradientes, composições, transformações, letras multicoloridas. Isso ocorre mesmo que as fontes sejam de tamanhos muito pequenos. O Google afirma ter sido capaz de renderizar o Noto Color Emoji usando o formato de fonte COLRv1. Segundo a equipe, o tamanho chegou a 1,85 MB após a compactação WOFF2. Como comparação, a fonte bitmap padrão ocupa 9 MB para o mesmo emoji. Portanto, esta é uma melhora importante com essa redução expressiva de tamanho.

Críticas da Apple

Embora a Mozilla e os desenvolvedores da web tenham dado apoio à nova fonte vetorial, a equipe WebKit e Core Text da Apple deram um sinal negativo para a proposta. A Aplle alega que o COLRv1:

  • Não é um novo formato tão expressivo e poderoso quanto qualquer formato de serialização de gráficos 2D de uso geral. Existem outras opções.
  • Ele ainda não existe (fora de uma configuração de desenvolvimento do Chrome). O OT-SVG, que é tão expressivo, existe e tem implementações de envio em DirectWrite, Core Text, Firefox e muitos aplicativos de criação da Adobe. Muitas fontes OT-SVG já existem.
  • Como essa proposta ainda não existe fora do Chrome, não há ecossistema nas ferramentas de autoria existentes. Por outro lado, muitas ferramentas de criação de design já exportam SVG.
  • O suporte tanto para OT-SVG quanto para esta nova proposta é o dobro (-ish) da carga de manutenção, para um formato que não é mais expressivo do que o formato que já suportamos.
  • O suporte tanto para OT-SVG quanto para esta nova proposta aumenta nosso tamanho binário. Esperamos que o aumento de tamanho binário adicional seja aproximadamente equivalente ao aumento de tamanho binário que observamos após a implementação do OT-SVG. (OT-SVG envolve um analisador XML, mas o WebKit já está vinculado a um analisador XML, portanto, esperamos que o tamanho desta nova proposta seja aproximadamente igual ao aumento de tamanho que vimos após a implementação do OT-SVG. Esta proposta exigiria seu próprio novo código de análise / detecção de estouro / interpretação.)
  • O suporte ao OT-SVG e a esta nova proposta praticamente dobra a área de superfície para ataques de segurança para fontes coloridas baseadas em vetor.
  • Mesmo considerando um mecanismo que suporta apenas esta proposta e não SVG, não vimos nenhuma evidência de que evitar o XML reduzirá os bugs de segurança em comparação com um novo formato binário. Historicamente, no WebKit, observamos que formatos binários opacos (como formatos de imagem) têm muitos bugs de segurança.
  • A especificação tem mais de 2.500 linhas, e o diretório images/ da especificação tem 77 figuras, existindo apenas uma implementação desta proposta. É complicado o suficiente para que não tenhamos certeza de que possa ser implementado de forma interoperável. Estamos preocupados que o comportamento das operações de desenho possa ser específico do Skia e difícil/impossível de implementar no Core Graphics. Por exemplo, à primeira vista, não temos certeza de que os gradientes radiais nesta proposta possam ser implementados no Core Graphics. Até onde sabemos, esta proposta não passou por um rigoroso processo de padronização de muitos interessados independentes.
  • A incorporação de dados de imagens raster dentro de tabelas de fontes coloridas é comum hoje em dia, mas essa nova proposta não tem recursos para permitir isso, apesar de suas facilidades de vetor serem tão expressivas quanto qualquer formato de serialização de gráficos 2D de uso geral. Portanto, na verdade, ele não melhora a situação de fragmentação da tabela de fontes de cores, que é amplamente considerada uma das maiores desvantagens das fontes coloridas atualmente.

Entre as principais mudanças no Chrome 98 estável podemos destacar o seguinte:

  • Suporte a fontes vetoriais de gradiente de cores COLRv1 para deixar arquivos emoji menores para a Web, oferecendo melhor qualidade. As fontes COLRv1 são bem compactadas, baseadas em vetores e funcionam bem com gradientes. As equipes do Google Chrome e do Google Fonts consideram a especificação COLRv1 como seu formato sucessor da fonte emoji do Google Noto. O tamanho da fonte emoji é cerca de 20% do tamanho anterior, além de ter maior fidelidade de renderização. Mais detalhes sobre COLRv1 em developer.chrome.com.

E tem mais

Google Chrome 98 lançado com COLRv1 para arquivos Emoji menores
Google Chrome 98 lançado com COLRv1 para arquivos Emoji menores
  • O Chrome 98 finalmente possui recursos de captura de tela integrados para páginas da web;
  • Uma nova consulta de mídia CSS para detectar os recursos de exibição HDR (High Dynamic Range) de um dispositivo. A nova consulta é “intervalo dinâmico”;
  • Manipulação aprimorada de windows.open() com um novo argumento para controlar se o comportamento desejado é abrir uma nova janela pop-up versus uma nova guia/janela;
  • Promete suporte para blobs no objeto ClipboardItem;
  • Várias outras mudanças de desenvolvedor.

Mais detalhes sobre o Chrome 98 por meio do Chrome Release Blog e ChromeStatus.com.

Via Neowin