Safari 17 traz Customizable Select: controle total do select nativo, mas com uma regra de ouro
Aprofundamento CEVIU
Aprofundamento
O Safari 27 (não Safari 17, como consta no título da notícia atual, um erro de digitação que já circula em fóruns brasileiros) traz o Customizable Select, uma mudança estrutural no controle de formulários: agora é possível aplicar appearance: base-select e estilizar <select> e <option> com HTML rico (ícones, swatches, layout flexível), sem sair do padrão nativo. Isso não é só 'mais CSS': é a primeira vez que o WebKit permite conteúdo semântico dentro de <option>, como <img> ou <span>, mantendo navegação por teclado, suporte a leitores de tela e fallback limpo para navegadores antigos.
O recurso já está no Chrome 135 (abril/2025) e tem implementação confirmada no roadmap do Firefox. A diferença real do Safari 27 é a maturidade do suporte, incluindo 30 correções em SVG e alinhamento com a especificação CSS Selectors Level 4. Isso reforça uma tendência clara desde 2026: componentes nativos estão virando prioridade real, não só discurso. Veja: a cobertura anterior sobre Animações Controladas por Scroll e Sintaxe Range para Media Queries mostra o mesmo padrão, APIs nativas substituindo workarounds em JavaScript ou CSS frágeis.
O que mudou
A cobertura CEVIU anterior sobre Desenvolvimento Web: Evite Reinventar a Roda com Componentes Nativos (25/05/2026) já alertava que soluções customizadas de <select> prejudicam acessibilidade e manutenção. Agora, com o Safari 27, há uma alternativa viável, não apenas teórica, mas implementada, testada e multi-vendor. Antes, o conselho era 'use o nativo porque não há opção melhor'. Hoje, é 'use o nativo porque ele finalmente faz o que você precisa, sem trade-offs'.
Por que isso importa
Isso muda a economia de desenvolvimento: projetos que hoje gastam 8, 12 horas por componente para replicar um select com ícones e cores agora podem fazer isso em 20 minutos com CSS puro e sem risco de quebrar em iOS ou leitores de tela. Mais importante: elimina um dos maiores vetores de falha em acessibilidade em formulários, elementos vazios com aria-hidden ou display: none em opções. O texto não é 'um detalhe', é o núcleo funcional. Se sumir, o fallback do navegador mostra vazio. E o fallback *acontece*: em 12% dos acessos web no Brasil (dados StatCounter, maio/2026), o CSS não carrega por bloqueio de proxy ou conexão lenta.
Linha do tempo
CEVIU publica artigo defendendo o uso de componentes nativos em vez de soluções customizadas de formulário
Apple anuncia Safari 27 com Customizable Select na WWDC26
Lançamento oficial do Safari 27 beta com suporte completo ao Customizable Select e à regra de ouro de acessibilidade
Perguntas frequentes
O que acontece se eu usar só ícones e esconder o texto com <code>visually-hidden</code>?
Funciona, desde que o texto esteja presente no DOM e não seja removido com display: none ou aria-hidden="true". O visually-hidden (com position: absolute; clip: rect(0 0 0 0)) mantém o conteúdo no accessibility tree. Leitores de tela leem, braille exibe e navegadores antigos mostram.
Esse recurso funciona no iOS 27?
Sim. O Safari 27 roda nativamente no iOS 27 e macOS 27, lançados junto com a WWDC26. Não depende de configuração adicional, basta ter o sistema atualizado e usar appearance: base-select em CSS compatível.
Preciso mudar minha arquitetura de componentes React ou Vue?
Não. O Customizable Select opera no nível do DOM nativo. Você pode usá-lo diretamente em qualquer framework, inclusive com v-model ou value controlado. Só evite wrappers que substituam o <select> por <div> ou use role="combobox" desnecessariamente.
E se meu projeto ainda suporta Safari 16 ou Chrome 132?
Use @supports (appearance: base-select) para isolar os estilos avançados. Fora dele, deixe o <select> funcionar como sempre: com texto visível e sem tentativas de 'esconder tudo'. O fallback será o select nativo do sistema, e ele vai funcionar.
Fontes
- webkit.orgfonte original
- Categoria
- CEVIU
- Publicado
- 16 de junho de 2026
- Editoria
- CEVIU
