Safari 27 beta: o select customizável finalmente sai do modo gambiarra

Desenvolvimento Web · "Loop"

Customizar um <select> sempre foi uma negociação meio ingrata. Você conseguia deixar o contorno menos triste, remover uma seta, talvez ajustar a fonte. Mas, se o design exigisse opções com ícone, layout mais elaborado ou um menu que parecesse pertencer à interface, a rota habitual era reconstruir o controle com divs, JavaScript e uma boa dose de atenção a teclado, foco e leitores de tela.

O Safari 27 beta passou a suportar customizable select, parte de uma iniciativa multi-vendor para dar mais controle visual ao elemento nativo. A promessa é atraente: manter o comportamento de um formulário de verdade, com navegação por teclado, validação e envio, enquanto o CSS ganha acesso a peças antes escondidas pelo navegador.

O opt-in começa com base-select

O ponto de entrada é appearance: base-select, aplicado ao select e ao seu picker. Em navegadores que entendem o recurso, isso ativa a renderização base que pode ser estilizada. Elementos e pseudo-elementos como ::picker(select), ::picker-icon e ::checkmark entram em cena para controlar menu, indicador e marca da opção selecionada.

select,
::picker(select) {
  appearance: base-select;
}

select::picker-icon {
  transition: rotate 160ms ease;
}

select:open::picker-icon {
  rotate: 180deg;
}

A API também permite um <button> como primeiro filho do select, com <selectedcontent> para representar o valor atual. Isso abre espaço para uma aparência mais rica no estado fechado, sem abandonar o controle nativo. É uma diferença importante em relação ao antigo appearance: none, que removia a aparência do sistema, mas não transformava o interior do picker em uma área CSS realmente utilizável.

Acessibilidade não vira detalhe de implementação

O benefício mais prático não é colocar um ícone simpático na lista de países. É continuar usando um select real. A versão beta do Safari preserva a navegação por teclado, a integração com leitor de tela, os eventos change, a validação e o envio de formulário. Quem já corrigiu um combobox feito à mão depois de uma revisão de acessibilidade sabe que essa lista não é cosmética.

Isso não libera ninguém para inserir controles interativos aleatórios dentro das opções. O elemento precisa continuar cumprindo o trabalho semântico que carrega há décadas. A customização reduz a necessidade de recriar o componente; ela não torna qualquer estrutura dentro de um menu automaticamente uma boa ideia para quem usa teclado ou tecnologia assistiva.

Ainda é progressive enhancement

Este é o trecho que evita uma migração animada demais. A própria MDN classifica a funcionalidade como de disponibilidade limitada, e a documentação do Firefox descreve suporte parcial em seus canais experimentais. Portanto, a estratégia correta hoje é ter um select clássico que já funcione e aprimorá-lo onde houver suporte.

select {
  border: 1px solid #64748b;
  border-radius: .5rem;
  padding: .625rem .75rem;
}

@supports (appearance: base-select) {
  select,
  ::picker(select) {
    appearance: base-select;
  }
}

Para um design system, vale experimentar em um componente isolado, validar a matriz de navegadores que o produto atende e conferir SSR/hydration caso o framework manipule a árvore de opções. Para uma interface com uma exigência visual que simplesmente não cabe no modelo de select, um combobox dedicado continua fazendo sentido. A novidade é que agora a escolha pode ser técnica, e não apenas consequência de um limite histórico do navegador.

Fontes