Por que o Safari 27 entrega 525 correções: notas do laboratório do WebKit

A coisa mais reveladora que a equipe do Safari disse na WWDC 2026 não foi sobre um recurso. Ao longo de uma hora no laboratório do grupo de Safari e Tecnologias Web, os engenheiros do WebKit ficaram rondando uma única pergunta: como uma equipe de navegador decide o que construir, e por que isso tantas vezes parece lento visto de fora? A resposta à qual eles voltavam, parafraseada do laboratório, era que eles genuinamente se importam, respaldada por um número que você pode conferir. O Safari 27 entrega 58 novos recursos e 525 correções, o que o WebKit chama de “a maior pilha de correções em qualquer lançamento do Safari na memória recente.”¹ Este post é sobre o raciocínio por trás desse número, extraído do laboratório e fundamentado nas próprias notas de lançamento do WebKit.

O Safari & Web Technologies Group Lab da WWDC 2026.

TL;DR

• O Safari 27 entrega 58 novos recursos e 525 correções, a maior contagem de correções em qualquer lançamento do Safari.¹ O laboratório enquadrou este ano como uma campanha contra “paper cuts”: perseguir os pequenos bugs de correção que tornam a plataforma confiável, não apenas os recursos de destaque.
• O exemplo mais claro é uma reescrita do carregador de módulos do JavaScript. As notas do WebKit descrevem a correção de “múltiplos bugs de correção de top-level await com uma reescrita do ES module loader para conformidade com os padrões”, substituindo uma implementação baseada em uma proposta abandonada de 2016 que antecedia totalmente o top-level await.¹
• O laboratório usou o seletor :has() como seu estudo de caso sobre como os padrões realmente se destravam: um recurso que os engenheiros chamaram de impossível por anos, até que a engenharia da Igalia o tornou rápido o suficiente, e agora ele está em todos os principais mecanismos.²³
• A história dos controles de formulário amadureceu: appearance: base-select limpa a estilização nativa do <select> para que você comece de uma tela em branco, com a direção mais ampla de “estilizar todo controle de formulário” ainda sendo uma especificação não resolvida sobre a qual o painel abertamente discordou.¹²
• WebKit e JavaScriptCore rodam em todo sistema operacional da Apple, incluindo o watchOS, e o SwiftUI agora tem uma WebView de primeira classe, então “o mecanismo da web” está mais perto de um serviço de sistema do que de um único aplicativo.²⁴

O número, e o que ele significa

O enquadramento do Safari 27 pelo WebKit é incomumente quantitativo. Além dos novos recursos, o lançamento carrega 525 correções, “a maior pilha de correções em qualquer lançamento do Safari.”¹ No laboratório, a equipe conectou esse número a uma postura, e não a um marco: o sentimento parafraseado era que os desenvolvedores web às vezes interpretam as escolhas de um navegador como falta de interesse pela experiência cotidiana deles, e a resposta da equipe era o oposto, que não há vantagem alguma em tornar a web pior no Safari.² Você não precisa aceitar o sentimento por fé, porque a contagem de correções é a evidência, e a própria descrição que o laboratório fez das notas de lançamento foi que elas se estendem o suficiente para você rolar por um bom tempo.²

A melhor ilustração de todas é uma peça de encanamento que a maioria dos desenvolvedores nunca vê. O WebKit reescreveu o carregador de módulos do JavaScript. As notas de lançamento são específicas: a equipe “corrigiu múltiplos bugs de correção de top-level await com uma reescrita do ES module loader para conformidade com os padrões”, porque a implementação anterior era “baseada em uma proposta abandonada do WHATWG Loader de 2016 que antecedia totalmente o top-level await” e podia permitir que importações acessassem exportações antes de elas estarem completamente inicializadas.¹ Reescrever um carregador de módulos para corrigir uma classe de bugs de ordenação de await é um esforço enorme para algo que, feito corretamente, ninguém percebe. Essa é a campanha contra “paper cuts” em um único commit.

Como um padrão realmente se destrava: a história do :has()

A narrativa mais útil do laboratório foi sobre o seletor CSS :has(), o tão desejado seletor de pai. A versão parafraseada do painel: os engenheiros de navegadores disseram não por boa parte de duas décadas, sob o argumento de que os chips não eram rápidos o suficiente para avaliá-lo sem destruir o desempenho da página, até que o trabalho para torná-lo viável finalmente aconteceu e ele foi lançado em todos os navegadores.² A espinha verificável por trás dessa história é real. O WebKit lançou :has() no Safari 15.4, o Chromium veio em seguida no Chrome 105 com a engenharia liderada pela consultoria de código aberto Igalia, e o Firefox completou o conjunto na versão 121, então o seletor que era “impossível” por anos agora funciona em todos os principais mecanismos.³

O laboratório amarrou isso a um princípio de design que vale conhecer pelo nome. A “priority of constituencies” do projeto HTML classifica de quem são as necessidades que prevalecem quando entram em conflito: usuários acima de autores, autores acima de implementadores, implementadores acima de especificadores, e todos eles acima da pureza teórica.⁵ É a regra que explica por que um navegador carregará para sempre uma feia solução de compatibilidade em vez de quebrar um site, e por que um recurso que ajuda os autores ainda pode esperar anos se implementá-lo prejudicasse os usuários por meio do desempenho. O :has() é a regra se resolvendo em câmera lenta: útil aos autores, bloqueado pelo custo para o usuário de torná-lo rápido, lançado apenas quando esse custo baixou.

O projeto de controles de formulário, e uma discordância em público

O recurso de CSS mais pedido da última década está finalmente chegando: estilizar controles de formulário nativos sem reconstruí-los a partir de <div>s. O Safari 27 entrega appearance: base-select, que, nas palavras do WebKit, permite que você “limpe a estilização nativa e comece com uma paleta limpa”, para então sobrepor seu próprio CSS mantendo a semântica real do controle, o tratamento de teclado e a acessibilidade.¹ Ele anda junto com ::picker(select), ::picker-icon, ::checkmark e um elemento <selectedcontent>, a superfície de select personalizável abordada em estilizando o elemento select de verdade.

O que o laboratório acrescentou foi a honestidade sobre quão inacabada está a visão mais ampla. Estender appearance: base a todo controle de formulário é uma direção declarada, não uma especificação lançada, e o painel discordou de si mesmo diante das câmeras sobre a pergunta mais difícil: como deveria ser o estado padrão sem estilo, afinal. Parafraseando a troca, uma posição era que um controle sem estilo deveria parecer um controle moderno e simples; a réplica era que “moderno” é um alvo de moda em movimento e não algo que uma especificação consiga fixar, então o estado base deveria herdar o máximo possível da página e, fora isso, sustentar o mínimo possível de opinião.² A restrição de engenharia com a qual eles concordaram é a parte genuinamente difícil: o recurso só funciona se a renderização padrão e a estrutura do DOM forem idênticas entre os navegadores, porque os autores vão estilizar contra ambas.² É por isso que um problema de 30 anos ainda é um trabalho em andamento, e não uma caixinha marcada.

O mecanismo da web é um serviço de sistema

Um reenquadramento útil do laboratório: o WebKit é muito mais do que o Safari. WebKit e JavaScriptCore estão presentes em todo sistema operacional da Apple, incluindo o watchOS, que não tem navegador algum, e qualquer aplicativo que execute JavaScript se apoia no JavaScriptCore.² O próprio material da WWDC do WebKit faz a mesma observação, descrevendo interfaces de aplicativos “impulsionadas pelo HTML, CSS e JavaScript que é renderizado pelo WebKit e JavaScriptCore, os mesmos mecanismos dentro do Safari”, em todas as plataformas.¹ O desdobramento prático para os desenvolvedores chegou em 2025, quando o SwiftUI ganhou uma WebView nativa e um modelo WebPage, tornando o WebKit uma view de primeira classe do SwiftUI em vez de uma WKWebView envolta em UIViewRepresentable.⁴ Quando o mecanismo da web está tão profundamente no SO, “isto deveria ser nativo ou web” deixa de ser uma escolha binária.

O que o WebKit está lançando primeiro, e construindo a seguir

Dois fios menores merecem a atenção de um desenvolvedor. Primeiro, o Safari continua a lançar recursos de CSS à frente de outros mecanismos: hanging-punctuation é exclusivo do Safari há anos, a função CSS filter() (distinta da propriedade filter, amplamente suportada) permanece exclusiva do WebKit, e o Safari lançou recentemente a função random(), com uma companheira random-item() para escolher entre valores discretos definida no rascunho do CSS Values.⁶⁷ O reflexo de “o Safari está atrasado” deixa passar com que frequência ele é o primeiro.

Segundo, a história das extensões web está se consolidando. O esforço multinavegador do WebExtensions está migrando de um grupo comunitário de vários anos rumo a um W3C Working Group formal, com um rascunho de carta de 2025 voltado a uma especificação real de interoperabilidade.⁸ E a Apple anunciou uma virada voltada ao consumidor no keynote da WWDC 2026: “Describe an Extension”, que usa a Apple Intelligence para gerar e instalar uma extensão personalizada do Safari a partir de uma descrição em linguagem simples, sem Xcode e sem a ida e volta à App Store.⁹ Trate isso como um anúncio de keynote, e não como uma API para desenvolvedores, mas a direção é clara: a superfície das extensões está se ampliando ao mesmo tempo na camada dos padrões e na camada do usuário final.

O que tirar disso

O laboratório é uma janela para um trade-off que a maioria da cobertura de recursos pula. Uma equipe de navegador pode perseguir recursos de destaque ou perseguir a correção, e o WebKit passou este lançamento escolhendo visivelmente a segunda opção: 525 correções, um carregador de módulos reescrito por causa de uma classe de bugs de await, um seletor de pai que esperou duas décadas até o hardware acompanhar. A lição para qualquer um que constrói sobre a plataforma é ler as notas de lançamento, não o keynote, quando você quer saber o que de fato melhorou. Os recursos estão em select personalizável, CSS Grid Lanes e o elemento HTML model; o raciocínio por trás do ritmo está no laboratório.

FAQ

Quantas correções há no Safari 27?

525 correções ao lado de 58 novos recursos, o que o WebKit descreve como a maior contagem de correções em qualquer lançamento do Safari.¹ O laboratório enquadrou o ano em torno da correção e dos “paper cuts”, e não dos recursos de destaque.

O que é a reescrita do carregador de módulos?

O WebKit reescreveu o ES module loader do Safari para conformidade com os padrões, corrigindo múltiplos bugs de correção de top-level await. A implementação anterior era baseada em uma proposta abandonada do WHATWG Loader de 2016 que antecedia o top-level await, e podia permitir que importações acessassem exportações antes de elas estarem completamente inicializadas.¹

O appearance: base está sendo lançado?

appearance: base-select é lançado no Safari 27 para o elemento <select>, limpando a estilização nativa para que você possa aplicar seu próprio CSS mantendo a semântica do controle.¹ Estender appearance: base a todos os controles de formulário é uma direção declarada, mas uma especificação não resolvida, e o painel do laboratório discordou abertamente sobre como o padrão sem estilo deveria ser.²

A Apple realmente adicionou extensões do Safari geradas por IA?

Sim. A Apple anunciou “Describe an Extension” no keynote da WWDC 2026: ele usa a Apple Intelligence para gerar e instalar uma extensão personalizada do Safari a partir de uma descrição em linguagem natural, sem Xcode ou a App Store.⁹ É um recurso para o consumidor, não uma API para desenvolvedores.

Os posts de recursos do Safari cobrem o o quê: estilizando o <select> de verdade, CSS Grid Lanes para masonry nativo e o elemento HTML <model>. Este aqui cobre o porquê por trás do ritmo. O hub completo da série é a Série Ecossistema Apple.

Referências