Formulários com restrições HTML nativas geram menos rejeições de validação no servidor por envio do que formulários validados apenas com JavaScript personalizado

Hipótese

A validação no servidor é obrigatória; a validação no cliente existe para que a maioria dos envios nem chegue a acioná-la. Há duas formas de implementar o lado do cliente: atributos de restrição nativos nos controles (required, type, pattern, min, max, maxlength), que o navegador verifica antes de um envio interativo, ou um script personalizado que inspeciona os valores e bloqueia o evento de envio (submit). O guia da MDN sobre validação de restrições (constraint validation) descreve o mecanismo nativo e seus limites: o atributo novalidate no formulário desativa a validação interativa, e chamar o método submit() do formulário envia os dados ao servidor mesmo que não satisfaçam as restrições. Um padrão comum é escrever validação personalizada para controlar estilo e mensagens e, no processo, abandonar os atributos nativos. A hipótese é que formulários cujos atributos nativos espelham as regras do servidor produzem menos rejeições no servidor por envio do que formulários validados apenas por script, e que a diferença vem sobretudo das sessões em que o script não executou: não carregou, lançou um erro antes de registrar seus handlers ou não captou os caminhos de preenchimento automático e de colagem.

Previsão

Numa comparação A/B do mesmo formulário com e sem atributos de restrição nativos, mantendo em ambas as variantes o mesmo script personalizado e as mesmas regras no servidor, a variante com atributos nativos apresenta uma taxa menor de rejeições de validação no servidor por envio. A diferença se concentra nas sessões com erro de script ou sem o marcador de prontidão do script, e é próxima de zero onde o script executou; as categorias de rejeição que diminuem são as que os atributos nativos conseguem expressar (campos obrigatórios ausentes, e-mail malformado, números fora do intervalo), não as regras entre campos. Se as taxas de rejeição forem iguais, ou se a diferença não se concentrar nas sessões com falha de script, a hipótese é falsa.

Teste proposto

1. Escolher um formulário público com alguns milhares de envios por mês e um servidor que devolva erros de validação estruturados por campo.
2. Montar a variante A com atributos nativos correspondentes às regras do servidor campo a campo e a variante B com os atributos removidos; manter script, layout e mensagens idênticos. Atribuir os visitantes por um hash estável.
3. Adicionar um campo oculto que o script define quando seus handlers são registrados, para que o servidor consiga saber se o script executou; registrar os erros de script junto com a variante.
4. Durante quatro semanas, registrar por envio: a variante, o marcador de execução do script, a rejeição (sim ou não) e os campos rejeitados com suas categorias de regra.
5. Comparar as taxas de rejeição por variante no total e separadas pelo marcador; informar contagens e intervalos e listar as categorias de regra que diferem.

Estado

Nenhum resultado é alegado. Se o script for confiável e os navegadores do público raramente falharem ao executá-lo, a diferença pode ser pequena demais para ser medida em quatro semanas; esse resultado diria, por si só, quanto a camada nativa acrescenta para esse público.