Apresentamos o Chrome Dev Insider

Ben Galbraith
Ben Galbraith
X

Muitas vezes, os desenvolvedores nos dizem que é difícil acompanhar as mudanças na Web e entender por que essas mudanças estão acontecendo. Hoje, estamos lançando uma nova série chamada Chrome Dev Insider. Nela, vamos compartilhar (1) novidades interessantes, (2) insights sobre como decidimos um assunto importante (por exemplo, como mudar o FLOC) ou como abordamos nosso trabalho com o ecossistema (por exemplo, Interop 2022) e (3) mudanças importantes nas strings do usuário que você precisa saber.

Conforme compartilhamos nosso trabalho, será no contexto das nossas quatro prioridades para 2022:

  • Permitir experiências agradáveis para o usuário:torne as coisas intuitivas para os usuários. seja no desempenho, nas transações, na identidade ou nas transições.
  • Avanço dos recursos da Web:permita que a Web deixe de ser apenas uma plataforma de consumo de conteúdo para oferecer uma ampla variedade de experiências, incluindo aquelas que precisam de integrações avançadas no nível do SO e do hardware.
  • Simplificar o desenvolvimento na Web:facilite a tomada de decisões e melhore a produtividade dos desenvolvedores.
  • Melhorar a privacidade da Web: atender aos usuários na expectativa por melhores proteções de privacidade de dados diante da sofisticação cada vez maior dos desenvolvedores no rastreamento e na segmentação.

Notícias: Interop 2022

À medida que planejamos nossos roteiros, analisamos o feedback dos desenvolvedores para entender as principais dificuldades e necessidades dos desenvolvedores da Web, entre outras coisas. Um tema importante que aparece repetidamente é a compatibilidade do navegador, fazendo com que uma experiência funcione da mesma forma em todos os navegadores. Ao longo do último ano, 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 as empresas do ecossistema anunciaram o Compat 2021, que fez com que todos os mecanismos de navegador conhecidos (Chromium, Gecko e Webkit) alcançassem uma pontuação de mais de 90% nas cinco principais áreas de foco identificadas para o ano. Entre outras coisas, a Compat 2021 levou à criação de uma base sólida para recursos avançados, como CSS Grid (uso de 12% e crescimento contínuo) e CSS Flexbox (77% de uso).

No mês passado, Apple, Bocoup, Google, Igalia, Microsoft e Mozilla se uniram para apoiar os principais problemas de compatibilidade de navegadores identificados por desenvolvedores da Web e chegar a um acordo sobre um comparativo de mercado comum. O resultado é o Interop 2022, um projeto com o objetivo de trazer mais homogeneidade à plataforma. O comparativo de mercado se concentra em 15 áreas prioritárias, identificadas pelos desenvolvedores como essenciais para melhorar a produtividade.

Informações privilegiadas: como trabalhar com nossos colegas do navegador

Com o Interop 2022 em mente, juntei-me a Robert Nyman e Philip Jägenstedt, que se envolveram nessas conversas para saber um pouco mais sobre o assunto. Confira a versão do editor de como tudo ficou.

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 conteúdo para a Web, e trazemos mais detalhes sobre isso no Relatório de compatibilidade de navegadores da MDN 2020. Isso nos deu informações e dados úteis suficientes para iniciar o esforço da biblioteca Compat 2021, o que, por sua vez, levou a dar continuidade a esse trabalho e também expandir esse escopo com o Interop 2022.

Philip: Eu também gostaria de mencionar web-platform-tests e o State of CSS 2021. Tivemos uma forte colaboração com outros fornecedores de navegadores nos testes usando o WPT há anos e queríamos nos apoiar nisso. Na maioria dos casos, os testes para esses recursos já foram criados. Portanto, precisávamos revisá-los e adicionar um pouco da cobertura que faltava. O Google investiu muito no wpt.fyi, mas também temos ao Mozilla a agradecer por tornar o WPT o sucesso que é hoje. É claro que o Mozilla também teve um papel importante nas pesquisas de DNA da MDN. Além disso, temos o relatório "State of CSS 2021". Para criar um esforço como o Interop 2022, precisamos de novas informações sobre as necessidades dos desenvolvedores da Web. Por isso, trabalhamos com o administrador da pesquisa, Sacha, para incluir algumas novas perguntas sobre problemas de compatibilidade do navegador. Isso realmente nos ajudou no processo de planejamento da Interop 2022.

Algum aprendizado ou feedback do 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 abordar questões que não estavam claras ou precisavam ser priorizadas. Também percebemos rapidamente que a interoperabilidade era um nome melhor para a iniciativa. Os termos compatibilidade e interoperabilidade normalmente são diferenciados para os fornecedores de navegadores, em que "compatibilidade" se refere à compatibilidade do site, e "interoperabilidade" se refere a dois ou mais navegadores que se comportam da mesma forma. Nessa terminologia, esse esforço é sobre interoperabilidade. Portanto, o projeto está alinhado a essa nomenclatura.

Qual é nossa visão?

Robert: Para manter a Web aberta, a diversidade do navegador e dos mecanismos de renderização é fundamental. No momento, esse recurso tem um preço alto para nossos desenvolvedores, que precisam acompanhar os diferentes níveis de suporte a recursos em cada mecanismo. Nossa visão é que os desenvolvedores vejam a plataforma da Web como a opção mais viável e atrativa para suas necessidades, e que eles possam se concentrar em criar as melhores experiências possíveis em vez de gastar muito tempo resolvendo problemas de interoperabilidade. E fica muito claro que, para atingir essa meta, os recursos mais solicitados precisam estar presentes em todos os principais mecanismos de navegador para realmente permitir que os desenvolvedores tenham sucesso na plataforma da Web.

Como podemos coletivamente avançar quando os navegadores com objetivos diferentes (às vezes) se unem?

Philip: Nossa abordagem tem sido procurar áreas de interesse comum para encontrar colaborações em que as metas já estão aproximadamente 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 simplesmente separadamente. Essa é a ideia.

Acho que é importante reconhecer que há limites para essa abordagem baseada em consenso, em que as metas não estão suficientemente alinhadas, precisamos seguir em frente de alguma outra forma. Às vezes, trazer mais evidências de que o desenvolvedor da web ou as necessidades do usuário pode ajudar, mas, em última instância, os fornecedores de navegadores podem entregar produtos que não têm um amplo acordo. Na melhor das hipóteses, o valor do recurso é demonstrado pelos desenvolvedores Web que testam o recurso, descobrem que ele atende às necessidades deles e pedem o mesmo recurso em todos os navegadores.

Voltando à ferramenta Interop 2022, podemos ver recursos que não são de design ou de layout surgindo no pipeline em algum momento?

Philip: Com certeza. O Interop 2022 não se limitou aos recursos de estilo e layout, mas acabou se concentrando muito no CSS. Em parte porque o "State of CSS 2021" era recente, mas também porque os desenvolvedores Web disseram que é nesse momento que eles têm mais problemas com as diferenças entre os navegadores. Várias áreas de foco, como elementos de formulário e caixa de diálogo, vão além do CSS, e também temos alguns esforços de investigação sobre a edição de APIs e eventos de ponteiro e mouse. Espero que, em 2023, tenhamos mais dados atualizados sobre as necessidades dos desenvolvedores na Web e incluamos mais recursos desse tipo na iniciativa.

Principais mudanças futuras

Uma das intenções desta série é avisar os desenvolvedores sobre as próximas mudanças importantes; coisas que são importantes para melhorar a experiência do usuário e os recursos da plataforma.

Os cronogramas mencionados abaixo indicam quando esperamos que essas mudanças aconteçam. No entanto, é possível que as versões de lançamento dos recursos mudem.

Redução de user agent

O cabeçalho User-Agent e as interfaces JS associadas a ele transmitem não apenas 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 strings do UA é o fato de que ela é enviada passivamente aos servidores para todas as solicitações de navegação e sub-recursos. Isso representa aproximadamente 10 bits de entropia que os servidores podem usar para construir identificadores de acompanhamento estáveis enquanto os usuários navegam na Web.

Nosso plano atual é reduzir a string UA existente continuando a enviar versões principais de navegadores, nome da plataforma e dispositivos móveis com baixa entropia, congelando as informações de alta entropia. Para casos de uso que exigem outras informações além das incluídas no cabeçalho, estamos lançando a API User-Agent Client Hints desde o Chrome 89.

Realizamos um teste de origem de seis meses para fins de experimentação e feedback, e ficamos felizes em não receber nenhum feedback relacionado a falhas, apesar de ter mais de 200 participantes.

API Local Fonts Access

O Chrome está lançando a API Local Font Access. Embora os sites possam usar fontes locais há muito tempo, essa API enumera a lista de fontes locais e fornece acesso aos próprios dados da fonte. Essa funcionalidade oferece aos usuários a capacidade de usar todas as suas 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 técnicas de impressão digital, o Chrome exige que o usuário conceda uma nova permissão "local-fonts" para um site antes que ele possa usar a nova API Local Font Access.

Futuramente, planejamos exigir que as mesmas "fontes locais" seja concedida antes de usar qualquer outra API que forneça acesso a fontes locais.

  • Cronograma:segmentando o Chrome 103 (junho de 2022)
  • Call-to-action:saiba mais sobre a API e como usá-la para começar a implementação.

Como fazer o BFCache funcionar com Cache-control: no-store

Identificamos uma oportunidade significativa de melhorar a frequência com que o cache de avanço e retorno pode oferecer navegações de avanço e retorno instantâneas. Isso exige uma mudança na forma como o BFCache se comporta em páginas exibidas com o cabeçalho HTTP Cache-control: no-store. Temos uma proposta pública criada para evitar surpresas significativas com o monitoramento de vários indicadores (por exemplo, removendo páginas do BFCache sempre que um cookie somente HTTP mudar) e de cortes (por exemplo, política de grupo para clientes do Enterprise/Edu) para contextos exclusivos. Essa é uma oportunidade complexa, mas empolgante, e que gostaríamos de receber mais análises e feedback.

  • Cronograma:segmentar o Chrome 104 (julho de 2022), supondo que não haja grandes surpresas.
  • Call-to-action: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 conseguir dar à nossa comunidade de desenvolvedores um senso de foco e conexão, aproximando-os da minha equipe e do seu trabalho. Fique de olho neste espaço para mais atualizações.

Até lá, boa sorte na Internet.

O que você achou da primeira edição do Chrome Dev Insider? Envie seu feedback.