Publicado em: 12 de novembro de 2026
Peça a um agente de programação de IA para criar uma dica ou uma caixa de diálogo modal e observe atentamente o código que ele escreve. Na maioria das vezes, o agente usa o JavaScript para recriar recursos integrados ao navegador. Se você pedir ao agente para usar recursos mais recentes de CSS ou HTML, ele geralmente vai pular a detecção de recursos e os substitutos. Essa omissão deixa os usuários em navegadores não compatíveis com uma página corrompida.
O Modern Web Guidance inclui compatibilidade com navegadores em todas as recomendações. Cada guia combina recursos modernos da Web com dados de suporte do Baseline e padrões de substituição verificados. Nesta postagem, vamos analisar como o agente usa esses dados para escrever um código moderno e compatível com vários navegadores.
Por que os agentes de programação erram no suporte ao navegador sem orientação
Sem orientação, os agentes de programação raramente verificam quais navegadores seu projeto precisa aceitar antes de escrever o código. Em vez disso, elas tendem a se enquadrar em um de dois extremos:
- Uso de código legado como padrão: os dados de treinamento do modelo estão cheios de padrões legados, e as avaliações do Modern Web Guidance mostram que os modelos ainda recomendam muitos desses padrões. Os agentes costumam escrever JavaScript complexo ou adicionar bibliotecas externas quando um recurso HTML ou CSS integrado pode fazer o trabalho.
- Uso de novos recursos sem uma rede de segurança: quando você pede que um agente use um recurso da Web mais recente, ele geralmente escreve o código para navegadores compatíveis e para por aí. Ele ignora a detecção de recursos e deixa de fora os substitutos, o que quebra a página em navegadores que não são compatíveis com o recurso.
Os dados do conjunto de avaliação do Modern Web Guidance mostram como essa lacuna é comum. Para recursos que ainda não funcionam em todos os principais navegadores, o conjunto de avaliação testa a detecção de recursos, regras @supports, substitutos ou polyfills condicionais. Os modelos sem orientação passam nessas verificações apenas 43% das vezes. Com o Modern Web Guidance ativado, a taxa de aprovação salta para 87%.
Como os dados de referência orientam cada recomendação
Para decidir quando um recurso da Web precisa de um substituto, o Modern Web Guidance usa o Baseline. O Baseline monitora o suporte em todo o conjunto principal de navegadores (Chrome, Edge, Firefox e Safari em computadores e dispositivos móveis) com três status:
- Baseline amplamente disponível: o recurso funciona em todos os navegadores principais há pelo menos 30 meses.
- Baseline recém-disponível: o recurso funciona em todos os navegadores principais, a partir da data em que o último navegador adicionou suporte.
- Disponibilidade limitada: o recurso ainda não é compatível com todos os navegadores principais.
Cada guia do Modern Web Guidance inclui o status do Baseline integrado e dados de versão do navegador do pacote web-features. Quando o agente de programação carrega um guia, ele recebe o status exato de suporte do recurso, as datas de lançamento e as versões do navegador, além das instruções de implementação. Exemplo:
Browser support for <dialog closedby>: Limited availability.
Supported by: Chrome 134 (Mar 2025), Edge 134 (Mar 2025), and Firefox 141 (Jul 2025).
Unsupported in: Safari.
Por padrão, o Modern Web Guidance segue duas regras com base nesses dados:
- Recursos amplamente disponíveis do Baseline: seu agente usa esses recursos diretamente, sem detecção extra de recursos ou código substituto. Essa regra mantém sua base de código enxuta e evita soluções alternativas desnecessárias.
- Recursos de disponibilidade limitada e recém-disponíveis do Baseline: os guias desses recursos incluem uma estratégia de substituição verificada. Seu agente usa o recurso moderno quando há suporte e oferece um substituto limpo para outros navegadores.
Quatro padrões de substituição que o Modern Web Guidance usa na prática
Nem todo recurso da Web precisa do mesmo tipo de substituto. O Modern Web Guidance associa cada recurso a uma das quatro abordagens de fallback com base no comportamento do recurso em navegadores incompatíveis:
| Padrão substituto | Quando o Modern Web Guidance usa esse recurso |
|---|---|
| Aprimoramento progressivo sem código substituto | Recursos decorativos ou aditivos que os navegadores não compatíveis ignoram com segurança sem quebrar o layout ou o comportamento. |
Detecção de recursos CSS com a regra @supports |
Estilos visuais ou de layout que dependem de um recurso CSS mais recente e podem parecer corrompidos se aplicados parcialmente. |
| JavaScript personalizado leve | Atributos HTML interativos ou APIs que precisam de um script pequeno e sem dependências para replicar o comportamento em navegadores mais antigos. |
| Polyfills carregados condicionalmente | Recursos maiores de CSS ou JavaScript que exigem um polyfill verificado carregado dinamicamente apenas quando não há suporte nativo. |
Aprimoramento progressivo sem código substituto
Alguns recursos modernos melhoram a tipografia, as animações ou a velocidade de carregamento de página sem mudar o funcionamento dela. Se um navegador não reconhecer esses recursos, ele vai ignorá-los e renderizar o restante da página normalmente.
Por exemplo, a declaração CSS text-wrap: balance (recém-disponível no Baseline) uniformiza o comprimento das linhas nos títulos.
.balanced {
text-wrap: balance;
}
A API Speculation Rules (disponibilidade limitada) pré-busca ou pré-renderiza as próximas páginas. Os navegadores incompatíveis ignoram com segurança os blocos <script type="speculationrules"> e as declarações CSS não reconhecidas.
<script type="speculationrules">
{
"prefetch": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Devido a esse comportamento, seu agente pode adicionar esses recursos diretamente, sem código de fallback extra.
Detecção de recursos CSS com a regra @supports
Outros recursos de CSS mudam a forma como um elemento é posicionado ou estilizado na tela. Se você aplicar parte do estilo incondicionalmente, os navegadores incompatíveis poderão renderizar o elemento no lugar errado.
Por exemplo, as consultas de contêiner fixas (container-type: anchored, disponibilidade limitada) em uma dica posicionada permitem inverter a seta da dica quando ela se aproxima da borda da janela de visualização. Em navegadores sem suporte para consultas de contêiner ancoradas, a seta não consegue detectar a inversão e pode apontar para o lado errado. O Modern Web Guidance instrui o agente a envolver os estilos de seta em uma regra @supports (container-type: anchored) para que a seta padrão apareça apenas em navegadores que também oferecem suporte à regra de inversão @container anchored().
@supports (container-type: anchored) {
.tooltip-content::before {
content: "▼";
position: absolute;
inset-block-end: 0;
}
}
@container anchored(fallback: flip-block) {
.tooltip-content::before {
content: "▲";
inset-block-start: 0;
inset-block-end: auto;
}
}
JavaScript personalizado leve
Quando um recurso HTML interativo não é compatível com todos os navegadores principais, pode ser desnecessário usar uma biblioteca de terceiros. Para interações independentes, o Modern Web Guidance oferece um substituto curto em JavaScript sem dependências, protegido por uma verificação de recursos.
Por exemplo, o atributo closedby="any" em um elemento <dialog> (disponibilidade limitada) permite que os usuários fechem uma caixa de diálogo modal clicando no plano de fundo. Para navegadores que não são compatíveis com o atributo closedby, o guia inclui um pequeno listener de cliques que verifica o objeto HTMLDialogElement.prototype primeiro:
const dialog = document.querySelector('dialog');
if (!('closedBy' in HTMLDialogElement.prototype)) {
dialog.addEventListener('click', (event) => {
if (event.target !== dialog) return;
const rect = dialog.getBoundingClientRect();
const clickedInDialog =
rect.top <= event.clientY &&
event.clientY <= rect.top + rect.height &&
rect.left <= event.clientX &&
event.clientX <= rect.left + rect.width;
if (!clickedInDialog) {
dialog.close();
}
});
}
Polyfills carregados condicionalmente
Para recursos maiores da plataforma, como o posicionamento de âncoras CSS (disponibilidade limitada) ou a API Temporal (disponibilidade limitada), não é prático escrever um substituto personalizado manualmente. Ao mesmo tempo, agrupar um polyfill para cada usuário adiciona um custo extra de download para navegadores que já oferecem suporte ao recurso.
Nesses casos, o Modern Web Guidance orienta o agente a verificar primeiro se há suporte e carregar um polyfill aprovado de forma dinâmica com a expressão import() do seu bundler ou de uma CDN. Os navegadores compatíveis não fazem o download de nenhum código extra, enquanto os navegadores mais antigos buscam o polyfill sob demanda.
if (!CSS.supports('anchor-name: --a')) {
await import('@oddbird/css-anchor-positioning');
}
Personalizar o destino de suporte do navegador do seu projeto
Por padrão, o Modern Web Guidance trata os recursos amplamente disponíveis do Baseline como seguros para uso sem substitutos. Ele exige substitutos para os recursos recém-disponíveis e de disponibilidade limitada do Baseline.
Seu projeto pode ter requisitos de navegador diferentes. Por exemplo, você pode segmentar um ano específico do Baseline, criar um app Electron ou excluir polyfills para manter os pacotes pequenos.
É possível definir uma política personalizada de suporte ao navegador no arquivo AGENTS.md ou CLAUDE.md do projeto:
## Browser support policy
- Target **Baseline 2024** or earlier. Omit fallbacks and `@supports` blocks for features that reached Baseline in or before 2024.
- Allow **Baseline Newly available** features when paired with a custom fallback of 20 lines or fewer.
- Don't add polyfill dependencies. Prefer CSS `@supports` rules or built-in HTML fallbacks instead.
Cada guia inclui o status do Baseline, a data de lançamento e as versões mínimas do navegador para cada recurso. O agente compara sua política com esses dados de compatibilidade antes de escrever o código. Quando um recurso já atende ao seu destino, o agente escreve o código moderno e ignora o código substituto.
Testar o caminho moderno e o de fallback
Escrever código para vários navegadores é apenas metade do trabalho. Você também precisa testar o caminho de código moderno e o de substituição em navegadores reais.
Quando você testa em um único navegador, verifica apenas uma ramificação do código. Por exemplo, o Chrome e o Firefox executam o atributo closedby="any" nativo em um elemento <dialog>, enquanto o Safari executa o substituto de clique fora do JavaScript. Se você inspecionar a caixa de diálogo apenas no Chrome, esse listener substituto nunca será executado durante o teste.
Para verificar os dois caminhos de código, conecte o agente de programação a vários mecanismos de navegador ao mesmo tempo:
- Chrome DevTools para agentes: conecte seu agente ao Chrome para inspecionar o layout, os registros do console e o comportamento do ambiente de execução.
- MCP do Firefox DevTools: conecte seu agente a uma instância ativa do Firefox pelo WebDriver BiDi.
- Servidor MCP do Safari: conecte seu agente ao Safari usando o comando
safaridriver --mcpintegrado.
Com as três ferramentas conectadas, seu agente pode abrir sua página no Chrome, Firefox e Safari em um único fluxo de trabalho. Em seguida, ele pode confirmar se o recurso nativo e a experiência de substituição funcionam conforme o esperado.
Começar a usar o Modern Web Guidance
Para adicionar o Modern Web Guidance ao seu projeto, execute o instalador interativo no diretório do projeto:
npx modern-web-guidance@latest install
Se você tiver uma versão anterior instalada, execute o comando de atualização para fazer upgrade para a versão 1.0:
npx modern-web-guidance@latest update
Você também pode instalar o Modern Web Guidance pelos marketplaces de plug-ins do Claude Code, Codex, Cursor, Antigravity, GitHub Copilot, WebStorm, Kimi Code e Grok.
Para saber mais, acesse estes recursos: