Validação nativa de formulários em HTML: required, pattern, type e a Constraint Validation API

O que é

O HTML verifica os controles de um formulário antes do envio, sem nenhum script. required, minlength e maxlength, min, max e step, pattern e os tipos de input email, url, number e date declaram, cada um, uma restrição. Quando um controle viola alguma delas, o navegador se recusa a enviar o formulário e mostra uma mensagem própria no primeiro controle inválido. O guia da MDN descreve o lado do CSS: um controle inválido corresponde a :invalid e, depois que o usuário interagiu com ele, também a :user-invalid. A Constraint Validation API (checkValidity(), reportValidity(), setCustomValidity() e o objeto validity) expõe o mesmo estado a scripts; novalidate no formulário desativa os balões do navegador, mas mantém a API funcionando.

Por que importa

A validação nativa funciona antes de qualquer JavaScript ter chegado, sido executado ou falhado; as mensagens aparecem no idioma do próprio navegador, sem trabalho de tradução; e as restrições ficam num único lugar, a marcação, onde scripts, testes e crawlers podem lê-las. Não é uma medida de segurança: o guia da MDN deixa claro que o servidor deve validar todo envio, de qualquer forma.

Como aplicar

• Escolha primeiro o type: email, url e number já trazem a própria restrição e o próprio teclado. Use inputmode para texto livre que só precisa de um teclado numérico.
• Adicione required, minlength, min/max e pattern para regras de formato. O padrão é compilado como expressão regular do JavaScript e precisa corresponder ao valor inteiro. Descreva o formato esperado em texto visível e no atributo title; a página citada observa que os navegadores podem usar o título na mensagem de validação.
• Estilize :user-invalid em vez de :invalid, para que campos obrigatórios vazios não fiquem vermelhos antes de o usuário tocá-los.
• Use setCustomValidity() para regras entre campos, como a confirmação de senha, e restaure-o com uma string vazia; caso contrário, o controle continua inválido.
• Se você renderizar a sua própria lista de erros com novalidate, ainda assim chame reportValidity(), para que usuários de teclado e de leitor de tela sejam levados ao primeiro erro.
• Teste o caminho do servidor enviando o formulário com novalidate ou com curl; as verificações do navegador são uma cortesia, não um contrato.

Armadilhas

Os balões de erro nativos não podem ser estilizados, desaparecem quando o foco muda e mostram um erro por vez. Um pattern em type="email" se soma à verificação embutida, então ambas precisam ser satisfeitas. Controles desabilitados nunca são validados. Um controle obrigatório oculto com display: none continua bloqueando o envio, mas o navegador não tem onde mostrar a mensagem, o que costuma ser relatado como o bug do "formulário que não faz nada". Inputs de data e de número exibem widgets que dependem da localidade e são difíceis de reestilizar.