APRENDER. PRATICAR. EVOLUIR.Restrições expressas no HTML
O tipo do controlo define parte do contrato local. No exemplo, email verifica um formato e required exige um valor. Required é booleano: a sua presença mantém a exigência, mesmo quando o texto do atributo é false.
Para a retirar, remove o atributo. A forma como o browser apresenta a mensagem pode variar. O resultado continua limitado às restrições locais e não confirma a existência da caixa de correio ou a autorização para pedir capacidade.
Intervalo e alinhamento
O input numérico admite uma grelha: começa em 2 e avança de 2 em 2 até 10. O valor 3 não está fora dos limites, mas falha o alinhamento de step. São diagnósticos diferentes, com correções diferentes.
Se a regra de negócio permitir qualquer número no intervalo, a configuração deve refletir essa política; não se deve retirar uma restrição apenas porque um exemplo falhou. O servidor deve aplicar o mesmo contrato relevante.
Uma mensagem personalizada tem estado
setCustomValidity permite representar uma regra adicional através de uma mensagem não vazia. Essa mensagem conserva o erro até ser limpa. Quando a condição deixa de falhar, chama setCustomValidity com string vazia; escrever OK ou válido mantém precisamente um erro personalizado.
Numa relação entre dois campos, volta a avaliar a regra quando qualquer dependência relevante muda. Limpar esse erro não dispensa as restantes restrições do controlo ou as regras do servidor.
O percurso de validação importa
checkValidity devolve um resultado sobre as restrições aplicáveis; reportValidity também apresenta as falhas ao utilizador. Uma submissão normal pode desencadear validação interativa, mas novalidate e certos percursos alteram esse comportamento.
Um valor atribuído por código não recebe necessariamente as mesmas verificações de edição humana: minlength e maxlength não são verificados para atribuições programáticas nesse percurso, mesmo chamando estas APIs. Valida importações explicitamente segundo o contrato.
Iniciar submissão por código
requestSubmit segue o percurso de um submitter, respeitando as condições de validação e o evento submit. submit direto omite a validação de restrições e não dispara esse evento. Se um atalho de teclado tem de conservar o comportamento do botão visível, a diferença é decisiva.
Construir FormData apenas prepara dados; não prova que houve envio. Na interpretação de um excerto, identifica a chamada concreta antes de concluir que todas as etapas foram percorridas.
Erro localizável e corrigível
Uma mensagem útil identifica o campo e explica o que deve mudar. Depois de uma submissão com falhas, um resumo com ligações aos controlos pode ajudar a recuperar o contexto. Associa descrições aos campos e considera colocar foco no primeiro erro, sem o deslocar repetidamente enquanto a pessoa corrige outro campo. aria-invalid comunica um estado de erro às tecnologias de apoio; não substitui a regra que decide aceitar ou recusar a operação.
Aceitação completa da operação
Uma indicação visual de válido pode significar apenas que as restrições conhecidas do browser passaram. A API ainda pode recusar o pedido por falta de capacidade ou conflito com dados atuais. Preserva a distinção no feedback: não mostres uma operação como concluída antes de receber evidência desse resultado.
Ao responder aos casos, explica a regra, o percurso e a observação disponível. A avaliação exige interpretar essas relações; não executar código ou contactar um servidor.
<form action="/pedidos/capacidade" method="post">
<label for="contacto">Email de contacto</label>
<input id="contacto" name="contacto" type="email" required
aria-describedby="contacto-ajuda">
<p id="contacto-ajuda">Indica o email para receber a decisão.</p>
<label for="unidades">Unidades</label>
<input id="unidades" name="unidades" type="number"
min="2" max="10" step="2" required aria-describedby="unidades-ajuda">
<p id="unidades-ajuda">Escolhe 2, 4, 6, 8 ou 10 unidades.</p>
<button type="submit">Pedir capacidade</button>
</form>O form fictício exige email e um número de unidades. Três unidades estão entre 2 e 10, mas violam step. A aceitação do formato de email não prova a existência da caixa.
A marcação fornece ajuda associada; não inclui o servidor, resposta de erro nem persistência. A regra de capacidade real teria de ser confirmada no endpoint.
Armadilhas comuns
Usar required="false" como desativação; tratar formato de email como prova de identidade; deixar setCustomValidity com texto positivo; confiar em maxlength numa atribuição programática; esperar que aria-invalid impeça o envio; substituir mensagens por cor.
Tópicos relacionados: Formulários, controlos e submissão · Foco, estados, movimento e preferências · Diagnóstico de estilos e entrega
Cada verificação tem um âmbito. A validação nativa ajuda durante a interação, o feedback explica como corrigir e o servidor decide a aceitação real. Mantém os três ligados ao mesmo contrato e identifica explicitamente os caminhos que omitem etapas.
Referência: Client validation and server acceptance · HTML Living Standard; modular CSS