Os desenvolvedores costumam dizer que é difícil acompanhar as mudanças na Web e entender por que elas estão acontecendo. Hoje, estamos lançando uma nova série chamada Chrome Dev Insider, em que vamos compartilhar (1) o que é legal e interessante, (2) um insight sobre como tomamos uma decisão em um tópico importante (por exemplo, mudanças no FLOC) ou abordamos nosso trabalho com o ecossistema (por exemplo, Interop 2022) e (3) qualquer coisa realmente importante que você precise saber (por exemplo, mudanças nas strings de user agent).
Ao compartilharmos o que estamos fazendo, será no contexto das nossas quatro prioridades para 2022:
- Ativar experiências do usuário incríveis:torne as coisas intuitivas para os usuários, seja desempenho, transações, identidade ou transições.
- Melhoria dos recursos da Web:apoie a evolução da Web de uma plataforma de consumo de conteúdo para uma plataforma de uma ampla gama de experiências, incluindo aquelas que precisam de integrações profundas no nível do SO e do hardware.
- Simplificar o desenvolvimento da Web:facilite a tomada de decisões e melhore a produtividade dos desenvolvedores.
- Melhorar a privacidade da Web:atenda às expectativas dos usuários da Web em relação a uma melhor proteção de privacidade de dados, mesmo com a crescente sofisticação dos desenvolvedores em relação ao rastreamento e à segmentação.
Nas notícias: Interop 2022
Ao planejar nossos cronogramas, analisamos o feedback dos desenvolvedores para entender os principais problemas e necessidades dos desenvolvedores da Web, entre outras coisas. Um tema importante que aparece repetidamente é a compatibilidade com navegadores, que faz com que uma experiência funcione da mesma forma em todos os navegadores. No ano passado, trabalhamos com o ecossistema para abordar esse tema como parte da nossa prioridade de "simplificar o desenvolvimento da Web".
No ano passado, a Microsoft, o Chrome e os participantes do ecossistema anunciaram a Compatibilidade 2021, que resultou em todos os mecanismos de navegadores mais conhecidos (Chromium, Gecko e Webkit) alcançando uma pontuação de mais de 90% nas cinco principais áreas de foco identificadas para o ano. Entre outras coisas, o Compat 2021 levou à criação de uma base sólida para recursos poderosos, como a grade CSS (12% de uso e crescimento constante) e o flexbox do CSS (77% de uso).
No mês passado, Apple, Bocoup, Google, Igalia, Microsoft e Mozilla se uniram como apoiadores para resolver os principais problemas de compatibilidade de navegadores identificados por desenvolvedores da Web e chegar a um padrão comum. O resultado é o Interop 2022, um projeto com o objetivo de trazer mais homogeneidade à plataforma. O comparativo se concentra em 15 áreas prioritárias identificadas pelos desenvolvedores como essenciais para melhorar a produtividade.
Informações privilegiadas: como trabalhar com nossos colegas de navegador
Com a Interop 2022 em mente, conversei com Robert Nyman e Philip Jägenstedt, que estiveram envolvidos nessas conversas, para saber mais sobre o assunto. Confira como o editor fez a montagem.
Qual é a origem dessa iniciativa?
Robert:Tudo começou em 2019, quando fizemos a pesquisa MDN DNA 2019. Os problemas de compatibilidade se destacaram claramente como o principal problema para os desenvolvedores que criam para a Web. E demos mais detalhes no Relatório de compatibilidade de navegadores do MDN de 2020. Isso nos deu informações e dados úteis suficientes para iniciar o esforço de Compat 2021, que por sua vez levou à continuidade desse trabalho e também à expansão desse escopo com a Interop 2022.
Philip:também gostaria de mencionar web-platform-tests e State of CSS 2021. Temos uma forte colaboração com outros fornecedores de navegadores em testes usando o WPT há anos, e realmente queríamos nos apoiar nisso. Os testes para esses recursos já foram criados, então só precisamos revisar os testes e adicionar a cobertura que faltava. O Google investiu muito no wpt.fyi, mas também agradecemos à Mozilla por fazer do WPT o sucesso que ele é hoje. A Mozilla também teve uma grande participação nas pesquisas de DNA do MDN. Além disso, há também o State of CSS 2021. Para realizar um esforço como o Interop 2022, precisamos de novas informações sobre as necessidades dos desenvolvedores da Web. Por isso, trabalhamos com o mantenedor da pesquisa, Sacha, para incluir algumas perguntas novas sobre problemas de compatibilidade do navegador. Isso nos ajudou muito no processo de planejamento da Interop 2022.
Você aprendeu algo ou tem feedback sobre a Compat 2021?
Robert:Foi muito útil medir e ter pontuações e insights sobre o desempenho de cada mecanismo de navegador. Assim, pudemos acompanhar o progresso e discutir e resolver problemas que não estavam claros ou precisavam ser priorizados. Também percebemos rapidamente que "Interop" era um nome melhor para a iniciativa. Os termos compatibilidade e interoperabilidade geralmente são diferenciados pelos fornecedores de navegadores, em que "compat" se refere à compatibilidade do site e "interop" se refere a dois ou mais navegadores com o mesmo comportamento. Nesse contexto, o esforço é sobre interoperabilidade, e o projeto está alinhado com essa nomenclatura.
Qual é nossa visão aqui?
Robert:para manter a Web aberta, a diversidade de navegadores e mecanismos de renderização é fundamental. Infelizmente, isso tem um custo alto para nossos desenvolvedores, que precisam acompanhar os diferentes níveis de suporte a recursos em cada mecanismo. Nossa visão é que os desenvolvedores considerem a plataforma da Web como a opção mais viável e atraente para atender às necessidades deles e que possam se concentrar em criar as melhores experiências possíveis, em vez de passar muito tempo resolvendo problemas de interoperabilidade. E é muito claro que, para alcançar esse objetivo, os recursos mais solicitados precisam ser lançados em todos os principais mecanismos de navegador para que os desenvolvedores tenham sucesso na plataforma da Web.
Como podemos avançar coletivamente quando usuários com objetivos diferentes se reúnem?
Philip:Nossa abordagem tem sido procurar áreas de interesse mútuo para encontrar colaborações vantajosas para ambas as partes, em que as metas já estão alinhadas. Ao priorizar um número limitado de coisas para trabalhar ao mesmo tempo, focamos nessas áreas, avançamos mais rápido e temos uma qualidade maior do que se trabalhássemos separadamente. Essa é a ideia.
É importante reconhecer que há limites para essa abordagem baseada em consenso. Quando as metas não estão suficientemente alinhadas, precisamos seguir em frente de outra maneira. Às vezes, trazer mais evidências das necessidades dos desenvolvedores da Web ou dos usuários pode ajudar, mas, no final das contas, os fornecedores de navegadores podem enviar coisas que não têm um acordo amplo. Na melhor das hipóteses, o valor do recurso é demonstrado por desenvolvedores da Web que testam o recurso, descobrem que ele atende às necessidades deles e pedem o mesmo recurso em todos os navegadores.
Voltando à Interop 2022, será que os recursos que não são de design ou layout vão entrar no pipeline em algum momento?
Philip:Com certeza. A interoperabilidade 2022 não se limitou aos recursos de estilo e layout, mas acabou se inclinando muito para o CSS. Em parte porque o State of CSS 2021 era novo, mas também porque os desenvolvedores da Web nos disseram que é aqui que eles têm mais problemas com as diferenças entre os navegadores. Várias áreas de foco, como elementos de formulário e de diálogo, vão além do CSS. Também temos alguns esforços de investigação relacionados à edição de APIs e eventos de ponteiro e mouse. Espero que, para a Interop 2023, tenhamos mais dados atualizados sobre as necessidades dos desenvolvedores na Web e possamos incluir mais recursos nesse esforço.
Principais mudanças futuras
Uma das intenções desta série é avisar os desenvolvedores sobre as próximas mudanças importantes, coisas importantes para melhorar a experiência do usuário e os recursos da plataforma.
As datas mencionadas abaixo são quando esperamos que essas mudanças aconteçam. No entanto, as versões de lançamento dos recursos podem mudar.
Redução do user agent
O cabeçalho User-Agent e as interfaces JS associadas transmitem informações úteis sobre o navegador e o dispositivo, mas também carregam um legado de linhagem e informações imprecisas. Mais problemático do que o fornecimento quase infinito de bugs de análise de string do UA é o fato de que ele é enviado passivamente aos servidores para todas as solicitações de navegação e subrecursos. Isso representa aproximadamente 10 bits de entropia que os servidores podem usar para criar identificadores de rastreamento estáveis à medida que os usuários navegam na Web.
Nosso plano atual é reduzir a string do UA atual, continuando a enviar a versão principal do navegador de baixa entropia, o nome da plataforma e a mobileness, congelando as informações de alta entropia. Para casos de uso que exigem mais informações do que as contidas no cabeçalho, enviamos a API Dicas de cliente do user agent desde o Chrome 89.
Realizamos um teste de origem por seis meses para experimentar e receber feedback. Ficamos felizes em não receber nenhum feedback relacionado a quebras, apesar de ter mais de 200 participantes.
- Cronograma: no Chrome 101, estamos avançando para a fase 4, reduzindo as informações
MINOR.BUILD.PATCHna string UA para0.0.0. E continuaremos a avisar os sites e dar-lhes tempo para se se prepararem para as fases 5 e posteriores. Também criamos políticas corporativas para desativar essas mudanças e vamos realizar um teste de descontinuação até o Chrome 113 para dar mais tempo aos sites. - Call-to-action:migre seu site para as Client Hints do UA ou participe do teste de descontinuação.
API Local Fonts Access
O Chrome está lançando a API Local Fonts Access. Embora os sites já pudessem usar fontes locais há muito tempo, essa API enumera a lista de fontes locais e dá acesso aos dados de fonte. Essa funcionalidade permite que os usuários usem todas as fontes com design baseado na Web e outros aplicativos.
As fontes locais são conhecidas há muito tempo como um vetor de impressão digital. Embora essa nova API não aumente a capacidade de usar fontes para impressão digital, o Chrome exige que um usuário conceda uma nova permissão "local-fonts" para um site antes de usar a nova API Local Font Access.
No futuro, vamos exigir que a mesma permissão "fontes-locais" seja concedida antes do uso de qualquer outra API que ofereça acesso a fontes locais.
- Cronograma:segmentação do Chrome 103 (junho de 2022)
- Call-to-action:saiba mais sobre a API e como usá-la para começar a implementação.
Fazer o BFCache funcionar com Cache-control: no-store
Identificamos uma oportunidade significativa para melhorar a frequência com que o cache de avanço e retorno pode oferecer navegações instantâneas de avanço e retorno. Isso requer uma mudança no comportamento do BFCache nas páginas veiculadas com o Cache-control: cabeçalho HTTP sem armazenamento. Temos uma proposta pública projetada para evitar surpresas significativas monitorando vários indicadores (por exemplo, removendo páginas do BFCache sempre que um cookie somente HTTP muda) e exceções (por exemplo, política de grupo para clientes Enterprise/Edu) para contextos exclusivos. Essa é uma oportunidade complexa, mas empolgante, e gostaríamos de receber mais análises e feedback.
- Cronograma:segmentação para o Chrome 104 (julho de 2022), sem surpresas.
- Chamada para ação:consulte a proposta para mais detalhes, incluindo como ativar uma implementação em andamento e maneiras de compartilhar feedback, como cenários reais em que nossa abordagem criaria novos obstáculos.
Com essa série, espero que a comunidade de desenvolvedores tenha um senso de foco e conexão, se aproximando da minha equipe e do trabalho dela. Fique de olho aqui para receber mais atualizações.
Até lá, boas navegações.
O que você achou da primeira edição do The Chrome Dev Insider? Envie seu feedback.