Resumo

  • O W3C aprovou a nova carta do Web Performance Working Group em 10 de agosto de 2026; a vigência termina em 1º de agosto de 2028.
  • Uma funcionalidade nova deve ter manifestações de interesse de pelo menos dois implementadores antes de entrar em especificações mantidas como Candidate Recommendations.
  • Sem as duas manifestações, ela ainda pode aparecer num Candidate Recommendation Draft, desde que seja marcada como at risk.
  • Para avançar além de Candidate Recommendation, esperam-se duas implementações independentes e interoperáveis por funcionalidade, comprovadas por testes abertos; o Process do W3C mantém uma exceção pública e fundamentada.
  • Um comprovante de estado por funcionalidade deve separar interesse, adoção pelo grupo, risco, identidade das implementações, versão dos testes e decisão de transição.

Uma palavra mais precisa para o começo da jornada

O Web Performance Working Group cuida de APIs e métodos ligados a carregamento, renderização, resposta a interações, uso de recursos e outros aspectos da experiência de aplicações. Em 10 de agosto, o W3C anunciou a aprovação da nova carta e abriu a participação. O mandato vai até 1º de agosto de 2028.

Na passagem da proposta de junho para o texto final, o critério sobre novos recursos mudou. Em vez de falar em apoio de pelo menos dois implementadores, a carta aprovada fala em manifestações de interesse. A nova formulação não diminui a relevância da indústria. Ela evita atribuir a uma declaração inicial o valor de um compromisso de produto.

Interesse pode significar disposição para revisar, construir um protótipo, enviar experiência ou preservar uma alternativa técnica. Nada disso exige, por si só, equipe alocada, data de lançamento, ativação padrão ou manutenção prometida. A declaração orienta o grupo sobre relevância e possibilidade de adoção. Não demonstra comportamento interoperável.

Esse segundo fato aparece num estágio posterior. Para ultrapassar Candidate Recommendation, a carta espera pelo menos duas implementações independentes e interoperáveis de cada funcionalidade, com verificação por suites abertas. Também exige que cada funcionalidade tenha uma suite de testes aberta. A pergunta passa de “há mais de um ator disposto a olhar?” para “sistemas independentes se comportam de maneira compatível diante do mesmo ensaio?”.

Somar as duas respostas numa coluna chamada suporte apaga a diferença mais útil da carta.

Quatro posições no caminho

Uma proposta pode começar no Web Platform Incubator Community Group. Nessa incubação, casos de uso, objeções e código surgem sem que o Web Performance Working Group tenha assumido o trabalho.

Depois pode ocorrer a adoção pelo WG. A carta diz que uma proposta incubada no WICG, implementada e disponível em pelo menos um navegador importante e com apoio de mais um, pode ser adotada pelo WebPerf. Essa decisão muda o local institucional da especificação. Não fabrica a segunda implementação nem certifica a cobertura dos testes.

A terceira posição é a entrada em um Candidate Recommendation Draft. Uma funcionalidade sem duas manifestações de interesse pode constar ali se receber anotação at risk. Trata-se de uma condição visível: o trabalho pode atrair implementação e revisão, mas sua permanência numa transição seguinte ainda não está resolvida.

Por fim vem a experiência de implementação usada na transição. O Process do W3C trata Candidate Recommendation como período para reunir essa evidência e diferencia CR Draft de CR Snapshot. O Draft pode expor mudanças pretendidas; o Snapshot tem outro papel processual e de revisão de patentes. A sigla CR não informa sozinha a situação de cada recurso.

É por isso que “suportado” pode ser enganoso. O termo às vezes descreve uma posição favorável, um experimento atrás de uma flag, uma decisão de adoção, um conjunto parcial de testes ou duas implementações completas. A origem da afirmação define o que ela vale.

O exemplo público de Mozilla

Mozilla informou na consulta que apoiava a proposta mesmo que suas mudanças não fossem aceitas. A organização também apoiou a revisão da redação sobre apoio de dois implementadores e indicou intenção de revisar rascunhos, desenvolver implementações experimentais, enviar relatos de experiência e criar produtos baseados no trabalho.

O campo público sobre calendário de implementação ficou sem data.

Isso mantém a declaração honesta. Ela mostra interesse amplo na atividade do grupo, não um compromisso por funcionalidade. Não identifica duas partes para um recurso específico, uma versão de navegador ou quando algo seria habilitado. Contá-la como implementação concluída seria alterar o conteúdo do documento.

A relação de participantes também não preenche a lacuna. Uma organização pode contribuir com conhecimento e revisão sem apoiar cada decisão ou expor seu planejamento comercial.

At risk preserva a incerteza

Fora do contexto de padrões, “em risco” parece uma previsão de fracasso. No Process, a anotação cumpre função delimitada: avisa que a funcionalidade pode ser removida numa transição posterior pelas regras aplicáveis. Ela impede que a maturidade geral do documento seja herdada automaticamente por cada item.

Para ser auditável, a anotação precisa estar ligada a uma funcionalidade e uma revisão. Se desaparecer, o histórico deve mostrar se houve nova manifestação de interesse, implementação suficiente, redução do escopo, exclusão completa ou apenas uma edição estrutural.

Os testes também exigem identidade. A afirmação de que dois navegadores passam precisa vir acompanhada de versão do produto e do motor, configuração padrão, revisão do Web Platform Tests, cobertura e falhas. Dois nomes comerciais podem compartilhar a mesma linhagem de código. Independência precisa de justificativa técnica, não apenas contagem.

A exceção não deve ficar fora da tabela

A carta diz que duas implementações são esperadas. O Process geral permite ao W3C Team aprovar, diante de razão convincente, uma transição com experiência mínima de implementação. A decisão e a justificativa devem ser públicas.

Uma exceção assim não faz o critério desaparecer. Ela cria outro registro: autoridade, Process aplicável, escopo, evidência e fundamento. Em certas situações, é mais transparente publicar a exceção do que apresentar como independentes duas implementações muito próximas.

A distinção de Heng Lu entre publicação e adoção ajuda a testar a realidade: declaração institucional não substitui implementação, validação e uso. Mas o limite funciona nos dois sentidos. Código em execução não se concede sozinho o status de W3C Recommendation. A autoridade do estado formal e a evidência operacional devem aparecer lado a lado.

Um comprovante mínimo por funcionalidade

O W3C já publica cartas, especificações, issues, decisões, testes e páginas de status. Um comprovante versionado ligaria:

  • identificador estável e revisão imutável da funcionalidade;
  • versões da carta e do Process;
  • cada manifestação pública de interesse, com implementador, data, escopo e fonte;
  • natureza exploratória, planejada, implementada, retirada ou sem data da declaração;
  • decisão de adoção do Working Group e revisão escolhida;
  • URI e histórico da marcação at risk;
  • produto, motor e versão de cada implementação, com razão de independência;
  • revisão da suite aberta, cobertura e resultados datados;
  • transição, objeções e qualquer exceção pública;
  • próxima revisão, correção e substituição.

O comprovante não obriga a divulgação de roadmap, código proprietário ou infraestrutura sensível. Sua finalidade é deixar “interessado, sem cronograma” continuar significando exatamente isso.

A carta já oferece uma linguagem melhor. O desafio agora é impedir que compras, notícias e matrizes de compatibilidade convertam interesse em interoperabilidade por conveniência.

Fontes

  1. W3C — aprovação da carta e chamada à participação
  2. W3C — carta aprovada do Web Performance Working Group
  3. W3C — diferenças entre proposta e texto aprovado
  4. W3C — aviso público da consulta sobre a proposta
  5. Arquivo público do W3C — resposta de Mozilla
  6. W3C — Process Document
  7. W3C — publicações do Web Performance Working Group
  8. W3C — página do Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption