Quando os engenheiros querem fazer uma mudança no motor de renderização do Blink, eles postam na lista de discussão blink-dev para receber a aprovação para prosseguir. Essas postagens de lista de e-mails são chamadas de intenções do Blink.
Os navegadores da Web baseados no Chromium usam o motor de renderização Blink para transformar códigos e recursos em páginas da Web que podem ser visualizadas e com as quais é possível interagir.
Descubra como as Intenções do Blink funcionam, por que elas são importantes e como os novos recursos são incluídos no Blink.
Chromium e Blink
O Chromium é o projeto de navegador de código aberto em que o Chrome e alguns outros navegadores e frameworks são criados. O Blink é o mecanismo de renderização usado pelo Chromium.
Para que um novo recurso seja lançado no Blink, ele precisa passar pelo processo de desenvolvimento aberto do projeto Chromium. Um "novo recurso" é qualquer mudança ou adição no código ou na arquitetura do navegador. Pode ser uma nova API JavaScript, uma melhoria significativa no desempenho do código do Blink ou alguma outra mudança na aparência ou no funcionamento do navegador.
Um processo aberto e colaborativo
O Chromium é um projeto enorme e complexo com milhares de colaboradores. Quando há mudanças no Chromium, cada marco é uma oportunidade de convidar o ecossistema da Web para comentar sobre o design e a implementação.
Sempre que possível, os novos recursos precisam ser interoperáveis em toda a plataforma da Web, e não implementados apenas em um navegador. Os desenvolvedores da Web não querem surpresas: quando os navegadores não funcionam como esperado ou quando você precisa escrever códigos diferentes para navegadores e plataformas. As Blink Intents ajudam a estruturar e regular o processo de mudança para tornar as mudanças mais previsíveis e menos surpreendentes, o que é bom para desenvolvedores da Web.
Para os usuários, os fornecedores de navegadores precisam ter cuidado para que as mudanças não causem a interrupção dos sites. Os proprietários de sites costumam parar de fazer a manutenção dos sites. Alguns sites não são atualizados há décadas. Os fornecedores de navegadores precisam considerar isso ao fazer mudanças que possam causar falhas.
Da ideia à proposta
As propostas de mudanças e atualizações na plataforma da Web vêm de pesquisas: consultas com usuários, empresas, engenheiros de navegadores, desenvolvedores da Web e outras partes interessadas. Essa pesquisa permite que a equipe do Chrome descubra o que está faltando na plataforma ou o que precisa mudar. Inicialmente, uma proposta de mudança ou um novo recurso na plataforma da Web é apenas palavras em uma página. Os engenheiros compartilham documentos para receber feedback e discutir com os colegas.
Exemplo: FedCM
O gerenciamento de credenciais federadas (FedCM) é uma API para fornecer mecanismos novos e melhores para plataformas que gerenciam a inscrição e o login do usuário, conhecidos como identidade federada, por exemplo, quando você seleciona "Fazer login com o Google" ou "Fazer login com o GitHub".
Quando uma proposta como a FedCM estiver pronta para discussão pública, ela será publicada no GitHub como uma explicação. Nesse ponto, qualquer pessoa pode fazer uma pergunta ou comentar sobre o design de um recurso, criando um problema no repositório de explicações no GitHub. O feedback pode descrever outros casos de uso ou limitações, dar ideias para melhorias ou simplesmente mostrar apoio.
Quando uma proposta é adotada por um órgão de padronização, como o W3C, as partes interessadas podem participar de discussões e assistir a apresentações em grupos de padrões da Web, como os Grupos de trabalho do W3C.
Intenções do Blink: marcos e progresso
Para cada marco, quando os engenheiros estão trabalhando em um novo recurso ou em uma mudança no motor de renderização do Blink, eles publicam uma postagem no grupo de discussão blink-dev, explicando que pretendem passar para a próxima fase de implementação de um recurso. Essas postagens são chamadas de "intenções". Qualquer pessoa pode se inscrever no grupo blink-dev para receber notificações quando houver progresso com novos recursos no Blink ou se inscrever em um recurso individual para atualizações.
Intent to Prototype: o primeiro ponto de verificação
Nesse ponto, os engenheiros do Chromium podem começar a implementar um recurso. Isso significa que a funcionalidade do protótipo do recurso pode ser disponibilizada para testes de desenvolvedor por meio de uma flag de recurso, inicialmente no Chrome Canary e depois em outros canais de lançamento. Qualquer usuário pode definir uma flag na página chrome://flags para ativar e testar um recurso no navegador.
No entanto, nem todas as flags podem ser definidas na página chrome://flags. Para ter um controle mais refinado, execute o Chrome em um terminal usando flags de linha de comando. Alguns recursos novos não estão disponíveis até que sejam enviados para testes no Chrome Canary, mas isso é bastante raro. Alguns recursos não têm uma flag própria, mas são disponibilizados se a flag experimental-web-platform-features estiver ativada. Isso geralmente acontece com recursos "menores" que levam no máximo de três a seis meses para serem implementados.
Como coletar feedback sobre protótipos
Quando o protótipo de um novo recurso é iniciado, os engenheiros do Chromium convidam para discussões e experimentos iniciais. O feedback neste ponto é fundamental para validar e iterar as propostas. Bugs do Chromium é o lugar para comentar sobre a implementação no Chrome.
Intenção de testar: testes no mundo real
Uma postagem de Intent to Experiment no blink-dev é uma próxima etapa opcional, se os engenheiros do Chrome quiserem solicitar a execução de um teste de origem.
Os testes de origem são uma maneira de testar um recurso novo ou experimental da plataforma da Web. Você se inscreve no teste de origem de um recurso e recebe um token para o teste. O recurso será ativado em qualquer página que forneça o token.
Aprovação dos proprietários da API Blink
Para que a implementação de um recurso continue, os proprietários da API Blink precisam dar a aprovação respondendo a uma intent com uma postagem "looks good to me", conhecida como LGTM.
Os proprietários da API Blink são um pequeno grupo de colaboradores do Chromium, com muita experiência na plataforma da Web e nas APIs, e que a comunidade do Blink considera que estão em boa situação, com um compromisso com a missão e os valores do Blink. Além de dar aprovação (ou não) para que os recursos prossigam na implementação, os proprietários da API supervisionam o processo de intent do Blink.
Uma Intent to Experiment precisa receber pelo menos uma LGTM dos proprietários da API.
O valor dos testes de origem
Os desenvolvedores podem se inscrever no teste de origem de um recurso e, em seguida, testar o recurso na produção em ambientes reais, com usuários reais, sem que os usuários precisem realizar nenhuma ação para que o recurso seja ativado. Os desenvolvedores podem compartilhar os resultados dos testes, e isso fornece insights e dados valiosos para ajudar a iterar e evoluir o recurso.
Intent to ship: o marco final
A Intent to Ship indica que um recurso está completo e pronto para ser implementado para disponibilidade geral, para todos os usuários no Chrome Stable sem precisar de uma flag ou um token de teste. Uma Intent to Ship precisa receber três LGTMs dos proprietários da API antes que a implementação possa prosseguir.
Lançamento de novos recursos
Depois de aprovado, um recurso é mesclado a uma versão futura e progride pelos canais de lançamento do Chrome. O teste e a implementação de novos recursos geralmente são tratados com cuidado especial. Alguns recursos são lançados gradualmente para uma proporção cada vez maior de usuários. Os recursos também podem ser revertidos e retrabalhados, se houver efeitos colaterais inesperados.
Gerenciamento do ciclo de vida do recurso: descontinuação e remoção
Há dois outros tipos de intent do Blink:
- Intent para desativar
- Intent de remoção
Isso pode parecer um pouco triste, mas é fundamental para o sucesso do desenvolvimento do Blink.
Uma Intent to Deprecate é postada pelos engenheiros quando eles querem começar a alertar os desenvolvedores de que um recurso está programado para ser descontinuado. Por exemplo, oferecendo suporte e informações sobre a descontinuação no console do Chrome DevTools.
Uma Intent to Remove é postada quando os engenheiros pretendem desativar o código por padrão.
A importância da descontinuação e da remoção
A descontinuação e a remoção são essenciais para a integridade da plataforma da Web. Elas garantem que o Chrome possa remover recursos que não funcionam bem para usuários finais ou desenvolvedores da Web e ajudam a reduzir a complexidade da base de código. Por exemplo, problemas com o design do AppCache foram descobertos quando ele foi usado em sites de produção em navegadores estáveis, e a API acabou sendo removida. A descontinuação e a remoção também ajudam a manter o Chrome seguro, reduzindo possíveis vetores de ataque.
Como em todas as intents do Blink, a equipe do Chrome faz o possível para tomar decisões com cuidado. Eles analisam as taxas de uso dos recursos e outros dados antes de continuar. A barra para remover recursos é muito alta, e um recurso só será removido se for usado por uma parcela muito pequena de usuários e se houver alternativas melhores disponíveis.
Fique por dentro das novidades das Blink Intents
É possível acompanhar o progresso dos recursos no Status do Chrome, onde você pode se inscrever para receber atualizações, registrar bugs e encontrar outros recursos.
Para acompanhar os novos recursos, siga o Blog do Chromium. Para acompanhar todas as Intents do Blink, participe do grupo de discussão blink-dev. Isso pode resultar em muitos e-mails. Outra opção é assinar uma única intent. Confira uma planilha de intents do Blink em bit.ly/blinkintents. Se você realmente gosta de intents do Blink, é possível até mesmo criar com base nos serviços automatizados do Blink Intent Tracker.