Formulários HTML: rótulos, campos e envio compreensível

Um formulário coleta dados com controles que precisam ter nome, propósito e regra. Nesta aula, você vai criar um contato que o navegador consegue validar e que um programa consegue transformar em pares de chave e valor.

Imagine uma ficha de atendimento em papel. Ao lado de cada espaço existe um rótulo: nome, e-mail, mensagem. Se o rótulo aparece apenas dentro do espaço e some quando você começa a escrever, fica difícil revisar a ficha. No HTML, label é o rótulo persistente, input e textarea são controles, e name é a chave enviada. A comparação tem limite: o navegador pode oferecer teclado, preenchimento automático e validação conforme o tipo do controle, recursos que uma folha de papel não possui.

Comece pela pergunta que cada campo responde

O formulário abaixo coleta três informações:

<form action="/contatos" method="post">
  <div>
    <label for="nome">Nome</label>
    <input id="nome" name="nome" autocomplete="name" required>
  </div>

  <div>
    <label for="email">E-mail</label>
    <input
      id="email"
      name="email"
      type="email"
      autocomplete="email"
      required
    >
  </div>

  <div>
    <label for="mensagem">Mensagem</label>
    <textarea id="mensagem" name="mensagem" minlength="10" required></textarea>
  </div>

  <button type="submit">Enviar mensagem</button>
</form>

O valor de for no label é igual ao id do controle. Clique no texto “E-mail”: o foco deve ir para o campo. Essa é uma prova observável da associação. id identifica o elemento no documento; name identifica o dado no envio. Eles podem ter o mesmo texto, mas realizam trabalhos diferentes.

Tipo informa comportamento, não apenas aparência

type="email" diz ao navegador qual dado é esperado. Em celulares, isso pode adaptar o teclado; no envio, o navegador recusa formatos evidentemente incompatíveis. autocomplete="email" permite sugerir um valor conhecido pelo usuário. O atributo required impede o envio vazio, e minlength estabelece um comprimento mínimo.

Essas regras formam a validação do cliente. Elas melhoram a experiência, mas não protegem o servidor. Uma requisição pode ser enviada sem passar por essa página. Tecnicamente, o servidor precisa validar tudo novamente, aplicar regras de autorização e escapar dados conforme o destino.

Placeholder não substitui label. Ele desaparece durante a digitação, pode ter contraste baixo e costuma mostrar exemplo, não o nome permanente do campo. Use algo como placeholder="bia@exemplo.com" apenas se o exemplo realmente ajudar.

Botão precisa declarar a ação

Dentro de form, o padrão de button é enviar. Mesmo assim, escrever type="submit" deixa a intenção explícita. Um botão que apenas abre uma ajuda deve usar type="button", para não enviar a ficha por acidente.

action informa o destino e method="post" envia os dados no corpo da requisição. O laboratório intercepta o envio com JavaScript porque não existe servidor nesta aula. Ele cria FormData e lê pelo name, mostrando uma confirmação local sem colocar valores na URL nem enviar informações para fora.

Experimente remover name="email" e enviar. O campo continua visível, mas deixa de aparecer em FormData. Esse erro ensina a diferença entre interface e contrato de envio. Recoloque o atributo, provoque um e-mail inválido e observe a mensagem do navegador.

Seu formulário está pronto para o laboratório quando todos os campos possuem rótulo clicável, os dados têm name, o tipo combina com a informação e o botão descreve a ação. Na próxima aula, vamos reunir formulário, navegação, imagem e regiões semânticas numa página de perfil completa.