A web só melhora com o Interop 2024

Artigo original ↗ Discussão no Hacker News ↗

A iniciativa Interop 2024 dos fornecedores de navegadores busca reforçar a consistência entre browsers, com forte ênfase em recursos CSS como nesting, scrollbars, tipografia e comportamento de popover, que muitos veem como melhorias práticas para o layout e o design web do dia a dia. Os comentaristas estão divididos sobre prioridades: alguns acolhem essas melhorias de qualidade de vida, enquanto outros argumentam que capacidades mais transformadoras para Progressive Web Apps — como acesso confiável a arquivos locais, persistência de armazenamento e suporte mais amplo à instalação de PWAs — estão sendo negligenciadas, muitas vezes culpando as objeções de segurança e privacidade da Apple e da Mozilla a propostas lideradas pelo Google. A discussão destaca tensões mais profundas sobre a complexidade da web, a política de padronização e o quanto a web deve evoluir em direção a capacidades semelhantes às de aplicativos nativos versus preservar a privacidade do usuário e o controle da plataforma.

Foco e seleção do Interop 2024

  • O Interop é visto como uma coordenação útil, mas alguns acham que muitos itens escolhidos (CSS, popover, correções de QoL) são coisas que os navegadores já estavam implementando de qualquer forma, e não as lacunas de interoperabilidade mais difíceis.
  • Outros respondem que essas áreas (CSS nesting, scroll snap, popover, IndexedDB, acessibilidade, workers) têm amplo impacto no desenvolvimento do dia a dia e são exatamente o que muitos desenvolvedores querem.
  • Em termos de processo, isso é descrito como um pequeno grupo entre navegadores alinhando o que conseguem realisticamente trabalhar junto com os roadmaps normais, mais sobre harmonizar comportamentos do que forçar novos recursos.

PWAs, capacidades e política dos navegadores

  • Vários comentaristas perguntam por que não há uma área dedicada a PWA; as respostas dizem que partes relevantes para PWA (IndexedDB, service workers, mobile, modules) já estão incluídas.
  • Debate sobre APIs ausentes ou implementadas de forma desigual: OPFS, acesso ao sistema de arquivos, Trusted Types, URLPattern, módulos JSON, import attributes.
  • Forte discordância sobre as motivações da Apple: alguns a acusam de proteger a App Store ao desacelerar capacidades de PWA; outros dizem que Apple e Firefox estão bloqueando propostas inseguras e fora do padrão da Chrome (WebUSB/WebHID/WebSerial, algumas “capacidades” de PWA) por motivos de privacidade/segurança.
  • Confusão e discordância sobre o que “abandonar o suporte a PWA” significa para o Firefox (APIs vs PWAs de desktop instaláveis).

Armazenamento, sistema de arquivos e persistência

  • OPFS e APIs mais amplas de acesso ao sistema de arquivos são vistos por alguns como cruciais para fazer das PWAs verdadeiras concorrentes nativas (edição local de arquivos, sem armazenamento no backend).
  • Contra-argumento: APIs de armazenamento poderosas são vetores potenciais de rastreamento de longo prazo; o comportamento de armazenamento precisa se alinhar às políticas anti-rastreamento.
  • A exclusão de dados após 14 dias no Safari para sites raramente visitados e a expulsão de armazenamento não persistente frustram autores de apps offline-first. O armazenamento “persistente” via navigator.storage.persist() é criticado por ser opaco e pouco confiável na prática.
  • Alguns argumentam que Apple e Mozilla rejeitaram corretamente a especificação de acesso ao sistema de arquivos do Chrome por ser insegura; outros os criticam por não proporem alternativas aceitáveis.

CSS, interface e barras de rolagem

  • CSS nesting, popover, scroll snap, subgrid, funções de cor, filtros etc. são amplamente elogiados por reduzirem boilerplate em JS e fazerem a web parecer mais “nativa”.
  • A inclusão de estilização de scrollbar divide opiniões: alguns a veem como vital para interfaces complexas e como um compromisso para evitar scrollbars em JS; outros como uma personalização desnecessária, orientada por designers, que prejudica usabilidade e acessibilidade.
  • Tensão mais ampla entre consistência de plataforma nativa vs design web “igual em todo lugar” entre plataformas; custo e negligência de toolkits nativos são citados como fatores que empurram para interfaces web.

Imagens, cor, tipografia e ícones

  • A ausência do JPEG XL desaponta defensores que o veem como um formato de imagem tecnicamente superior; os defensores dizem que o AVIF já tem mais adoção e é “bom o suficiente”.
  • O suporte a cores de ampla gama/P3 é apontado como desigual (Firefox limitando ao sRGB). Debate sobre o quanto telas de alta gama realmente importam hoje.
  • Alguns querem que mais recursos de tipografia CSS (por exemplo, leading/text-box-trim, margin-trim) sejam priorizados entre navegadores.
  • Pedem favicons SVG e um tratamento simplificado de ícones; as soluções parciais do Safari e os requisitos de ícones específicos da Apple são vistos como atrito para desenvolvedores casuais.

Modelos de navegador, testes e áreas em falta

  • O fato de o Safari vincular atualizações do engine a versões do sistema operacional (especialmente no iOS) é criticado por deixar hardware mais antigo preso a recursos/bugs desatualizados; defensores argumentam que as taxas de atualização do iOS são altas e que patches de segurança são retroportados.
  • Alguns criticam as métricas do Interop/WPT por incluírem APIs não padronizadas do Chrome e fazerem Safari/Firefox parecerem piores.
  • Preocupações com áreas ausentes ou pouco enfatizadas: WebGPU, WebAssembly GC/múltiplas memórias, WebXR, controles de formulário, qualidade de hifenização, Cookie Store API.
  • Meta-discussão: alguns lamentam a complexidade da web e o domínio de poucos engines; outros argumentam que as capacidades ricas de aplicativos e a entrega lucrativa de software são agora o papel de fato da web. Protocolos alternativos simples (Gemini, Spartan, Scorpion) são mencionados como experimentos fora da web mainstream.