Apresentamos o Chrome Dev Insider

Galbraith
Ben Galbraith
Twitter

Muitas vezes, os desenvolvedores relatam 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, onde vamos compartilhar: 1) O que é interessante e relevante, (2) um insight sobre como tomamos uma decisão sobre um tema importante (por exemplo, mudança de FLOC), nossa abordagem de trabalho com o ecossistema (por exemplo, Interop 2022), e (3) itens realmente importantes que você precisa saber nas strings do agente (por exemplo, mudanças).

Vamos compartilhar nossas quatro prioridades para 2022:

  • Permitem experiências agradáveis para os usuários:torne tudo intuitivo para os usuários, seja em questões de desempenho, transações, identidade ou transições.
  • Avanço dos recursos da Web:oferecer suporte à evolução do papel da Web, que deixou de ser uma plataforma de consumo de conteúdo e oferece uma ampla variedade de experiências, incluindo aquelas que precisam de integrações avançadas no nível do hardware e do SO.
  • Desenvolvimento na Web simplificado:facilite a tomada de decisões e melhore a produtividade dos desenvolvedores.
  • Melhoria na privacidade da Web:atenda às expectativas dos usuários da Web para melhorar a proteção da privacidade de dados diante da crescente sofisticação dos desenvolvedores em rastreamento e segmentação.

Notícias: Interop 2022

À medida que planejamos nossos roteiros, ouvimos o feedback dos desenvolvedores para entender os principais pontos problemáticos e necessidades desses desenvolvedores, entre outras coisas. Um tema importante que sempre aparece é a compatibilidade de navegadores, que faz com que a experiência funcione da mesma forma em todos eles. 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 as empresas do ecossistema anunciaram o Compat 2021. Com isso, todos os mecanismos de navegador mais usados (Chromium, Gecko e Webkit) atingiram 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 avançados, como CSS Grid (12% de uso e crescendo constantemente) e CSS Flexbox (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 pelos desenvolvedores da Web e chegar a um acordo sobre um comparativo de mercado comum. O resultado é o Interop 2022 (link em inglês), um projeto que tem como objetivo trazer mais homogeneidade para a plataforma. O comparativo de mercado se concentra em 15 áreas prioritárias, identificadas pelos desenvolvedores como fundamentais para melhorar a produtividade.

Informações privilegiadas: como trabalhar com outros navegadores

Com o Interop 2022 em primeiro lugar, conversei com Robert Nyman e Philip Jägenstedt, que se envolveram nessas conversas, para ter acesso a informações privilegiadas. Confira a apresentação do editor.

Qual é o início dessa iniciativa?

Robert:Tudo começou em 2019, quando fizemos a pesquisa MDN DNA 2019. Os problemas de compatibilidade claramente se destacaram como o principal problema para os desenvolvedores que criam apps para a Web. Confira mais detalhes no Relatório de compatibilidade do navegador MDN 2020. Com isso, tivemos informações e dados úteis suficientes para iniciar a iniciativa do Compat 2021, o que, por sua vez, levou a continuar esse trabalho e expandir esse escopo com o Interop 2022.

Philip: também gostaria de mencionar web-platform-tests e State of CSS 2021. Tivemos uma forte colaboração com outros fornecedores de navegadores sobre testes com o WPT há anos e queríamos nos basear nisso. Na maioria dos casos, os testes desses recursos já foram criados, então só precisamos revisar os testes e adicionar cobertura que faltava. O Google investiu muito no wpt.fyi, mas também temos que agradecer à Mozilla por fazer da WPT o sucesso que é hoje. O Mozilla, é claro, também teve uma grande participação nas pesquisas de DNA da MDN. Além disso, temos o State of CSS 2021. Para realizar uma iniciativa 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 novas perguntas sobre problemas de compatibilidade do navegador. Isso nos ajudou muito no processo de planejamento do Interop 2022.

Algum aprendizado ou feedback da plataforma Compat 2021?

Robert:Foi muito útil avaliar 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 "Interoperabilidade" era um nome melhor para a iniciativa. Os termos compatibilidade e interoperabilidade normalmente são diferenciados pelos fornecedores de navegador, em que "compatibilidade" se refere a um site, e "interoperabilidade" se refere a dois ou mais navegadores que se comportam da mesma forma. Nessa terminologia, o esforço está relacionado à interoperabilidade. Portanto, o projeto está alinhado a 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 preço alto para nossos desenvolvedores, que precisam acompanhar os diferentes níveis de suporte para os 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 as necessidades deles e que possam se concentrar em criar as melhores experiências possíveis, em vez de gastar muito tempo solucionando problemas de interoperabilidade. E está muito claro que, para atingir esse objetivo, os recursos mais solicitados precisam ser incluídos em todos os principais mecanismos de navegador para realmente permitir que os desenvolvedores sejam bem-sucedidos na plataforma da Web.

Como podemos avançar coletivamente quando navegadores com (às vezes) metas diferentes se juntam?

Philip: Nossa abordagem tem sido procurar áreas de interesse comum para encontrar essas colaborações vantajosas em que as metas já estão quase alinhadas. Ao priorizar um número limitado de coisas em que trabalhar ao mesmo tempo, colocamos o foco nessas áreas e avançamos mais rápido e temos mais qualidade do que se trabalhássemos sozinhos. Essa é a ideia.

Acho que é importante reconhecer que há limites para essa abordagem baseada em consenso, em que as metas não estão alinhadas o suficiente, precisamos avançar de alguma outra forma. Às vezes, trazer mais evidências das necessidades de desenvolvedores da Web ou usuários pode ajudar, mas, em última análise, os fornecedores de navegadores podem entregar coisas que não precisam de um amplo acordo. Na melhor das hipóteses, o valor do recurso é demonstrado por desenvolvedores da web que testam o recurso, descobrindo que ele atende às necessidades deles e solicitando o mesmo recurso em todos os navegadores.

Voltando para o Interop 2022, vemos recursos que não são de design ou de layout entrando no pipeline em algum momento?

Philip: Com certeza! O Interop 2022 não se limitou aos recursos de estilo e layout, mas acabou usando muito o CSS. Em parte porque o State of CSS 2021 era recente, mas também porque os desenvolvedores da Web nos disseram que é nesses locais 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 realizamos alguns esforços de investigação relacionados à edição de APIs e a eventos de ponteiro e mouse. Espero que, para o Interop 2023, tenhamos mais dados atualizados sobre as necessidades dos desenvolvedores em toda a Web e incluamos mais recursos desse tipo.

Principais mudanças futuras

Um dos objetivos desta série é avisar os desenvolvedores sobre as principais mudanças que estão por vir, 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 transmitem não só informações úteis sobre o navegador e dispositivo, mas também um legado de linhagem e informações imprecisas. O mais problemático do que o fornecimento quase infinito de bugs de análise de strings do UA é o fato de que ele é enviado passivamente aos servidores para todas as solicitações de navegação e de sub-recursos. Isso representa aproximadamente 10 bits de entropia que os servidores podem usar para construir identificadores de rastreamento estáveis à medida que os usuários navegam na Web.

Nosso plano atual é reduzir a string do UA continuando a enviar a versão principal do navegador com baixa entropia, o nome da plataforma e a dispositivos móveis, congelando as informações de alta entropia. Para casos de uso que exigem informações além daquelas contidas no cabeçalho, estamos enviando a API User-Agent Client Hints desde o Chrome 89.

Fizemos um teste de origem por seis meses para fazer testes e receber feedback, e ficamos felizes por não ter recebido nenhum feedback relacionado a falhas, apesar de termos 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 dá acesso aos próprios dados de fontes. 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 vetores de técnicas 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 de usar a nova API Local Font Access.

No futuro, planejamos exigir que a mesma permissão "local-fonts" seja concedida antes de usar qualquer outra API que forneça acesso a fontes locais.

  • Cronograma:segmentar 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 para 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 TFCache se comporta em páginas veiculadas com o cabeçalho HTTP Cache-control: no-store. Temos uma proposta pública criada para evitar surpresas significativas ao monitorar vários indicadores (por exemplo, remover páginas do TFCache sempre que um cookie somente HTTP muda) e exclusões (por exemplo, política de grupo para clientes do Enterprise/Edu) para contextos únicos. Essa é uma oportunidade complexa, mas empolgante, e adoraríamos receber mais detalhes e feedback.

  • Cronograma:segmentar o Chrome 104 (julho de 2022), sem grandes surpresas.
  • Call-to-action:consulte a proposta para mais detalhes, incluindo como ativar uma implementação do trabalho em andamento e maneiras de compartilhar feedback, como cenários reais em que nossa abordagem criaria novos obstáculos.

Com essa série, espero poder dar à nossa comunidade de desenvolvedores uma sensação de foco e conexão, aproximando-os da minha equipe e do trabalho deles. Fique de olho e fique de olho neste espaço para mais atualizações.

Até lá, desejamos a você uma ótima web.

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