Nota do tradutor: Este documento é a tradução da seção sobre formulários das Recomendações do W3C para o HTML 4.01. Os códigos exemplo mostrados estão de acordo com o HTML 4.01 onde é válido grafia de tags em letras maiúsculas, bem como é opcional o fechamento de algumas tags, tal como a tag P que não foi fechada em alguns exemplos.

17 Formulários

17.1 Introdução aos formulários

Um formulário HTML é uma seção do documento contento texto normal, marcação, elementos especiais chamados de controles (checkboxes, radio buttons, menus, etc.), e rótulos para aqueles controles. Geralmente os usuários "preenchem" um formulário modificando seus controles (entrando textos, selecionando itens de menu, etc.), antes de enviar o formulário a um agente para processamento (p.ex.:, para um servidor Web, para um servidor de email, etc.)

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>
    <LABEL for="firstname">First name: </LABEL>

              <INPUT type="text" id="firstname"><BR>
    <LABEL for="lastname">Last name: </LABEL>
              <INPUT type="text" id="lastname"><BR>
    <LABEL for="email">email: </LABEL>

              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>
    <INPUT type="submit" value="Send"> <INPUT type="reset">

    </P>
 </FORM>

17.2 Controles

Os usuários interagem com os formulários através seus controles.

O "nome do controle" é definido no atributo name. O escopo do atributo name para um controle de um elemento FORM é o elemento FORM.

Cada controle tem um valor inicial e um valor corrente, sendo ambos uma string de caracteres. Para informações sobre o valor inicial e possíveis restrições impostas aos valores dos controles consultar a definição de cada controle. Em geral o "valor inicial " de um controle deve ser definido no atribubo value do elemento controle. Contudo, o valor inicial de um elemento de controle TEXTAREA é definido pelo seu conteúdo e o valor inicial de um elemento OBJECT em um formulário é definido na implementação do objeto (isto é, está fora do escopo desta especificação).

O"Valor corrente" de um controle é definido pelo primeiro conjunto de valor inicial. Adiante o valor corrente de um controle poderá ser modificado por ação do usuário e de scripts.

O valor inicial de um controle não se altera . Assim, quando o formulário é resetado o valor corrente de cada controle é resetado para seu valor inicial. Se um controle não tem um valor inicial, quando o formulário for resetado o efeito sobre este controle será indefinido.

Quando um formulário é enviado para processamento alguns controles enviam para processamento um par de valores constituido pelo nome do controle e seu valor corrente. Os controles que enviam o par nome/valor para processamento são chamados de controles bem sucedidos.

17.2.1 Tipos de controle

HTML define os seguintes tipos de controle:

botões

Autores podem criar três tipos de botão:

• botão submit: Quando ativado, envia o formulário. Um formulário pode conter mais de um botão submit.
• botão reset: Quando ativado, reseta todos os valores do formulério para seus valores iniciais.
• botão push: Não possui um comportamento padrão. Todo botão push deve ter um script do lado do cliente associado aos atributos event do elemento. Quando um evento ocorre (p.ex.:, o usuário pressiona ou solta um botão, etc), o script é acionado.

  Autores devem definir a linguagem do script para um botão push na declaração padrão para scripts (no elemento META).

Autores criam botões com o elemento BUTTON ou com o elemento INPUT . Consultar a definição destes elementos para detalhes de como especificar diferentes tipos de botão.

Nota. Autores devem notar que elementos BUTTON oferecem possibilidades de renderização bem mais sofisticadas que o elemento INPUT .

checkboxes

Checkboxes (e botões rádio) são chaves tipo ligada/desligada (NT: ou marcada/desmarcada) a serem acionadas pelo usuário. A chave estará "ligada" quando o atributo checked do elemento estiver marcado. Quando um formulário é enviado para processamento somente os controles checkbox "ligados" são controles bem sucedidos.

Vários checkboxes em formulário podem ter o mesmo nome do controle. Assim, por exemplo, checkboxes permitem a seleção de vários valores para uma mesma propriedade. O elementoINPUT é usado para criar um controle checkbox.

botões radio

Botões rádio são como checkboxes exceto pelo fato de que quando vários deles têm o mesmo nome do controle, serão mutuamente exclusives: quando um deles for "ligado" todos os demais que têm o mesmo nome serão "desligados". Usa-se o elemento INPUT para criar um controle botão rádio.

Se em um conjunto de botões rádio que têm o mesmo nome, não houver um deles com valor inicial definido como "ligado" será indefinido o comportamento do agente de usuário na escolha de qual deles tem o valor inicial "ligado". Nota. Uma vez que diferentes implementações tratam deste caso de modo diverso, esta especificação difere do que prevê as RFC 1866 ([RFC1866] na sua seção 8.1.2.4), que diz o seguinte:

Em qualquer situação um e somente um botão rádio deverá ser definido como "ligado" ou marcado. Se nenhum dos elementos <INPUT> de um conjunto de botões rádio for especificado como 'MARCADO', o agente de usuário deve considerar o primeiro botão rádio do conjunto como inicialmente marcado.

Face a esta diferença de comportamento dos agentes de usuários os autores devem assegurar que para cada conjunto de botões rádio um deles tenha seu valor inicial especificado para "ligado".

menus

Menus destinam-se a oferecer uma opção de escolha ao usuário. O elemento SELECT em combinação com os elementos OPTGROUP e OPTION cria um menu.

text input

Autores podem criar dois tipos de controle para que o usuário entre um texto. O elemento INPUT cria um campo para entrada de uma linha simples de texto e o elemento TEXTAREA cria um campo para entrada de uma múltiplas linha de texto. Em ambos os casos o texto digitado pelo usuário constitue-se no valor corrente.

file select

Este controle permite ao usuário selecionar um arquivo cujo conteúdo deva ser enviado para processamento pelo formulário. Cria-se um controle de seleção de arquivo (file select control) com o elemento INPUT .

hidden controls

Autores podem criar controles que não serão renderizados, mas cujos valores serão enviados para processamento pelo formulário. Normalmente este tipo de controle é usado para armazenar troca de informações entre o cliente e o servidor que naturalmente seriam perdidas dado a natureza do HTTP (ver [RFC2616]). Cria-se um controle oculto (hidden control) com o elemento INPUT.

object controls

Autores podem inserir objetos genéricos em formulários de modo que os valores a eles associados sejam enviados para processamento. Cria-se controles de objeto (object controls) com o elemento OBJECT .

Os elementos usados para criar controles, geralmente aparecem colocados dentro do elemento FORM , mas podem aparecer fora do elemento FORM quando usados para criar interfaces de usuário. Isto é discutido na seção eventos intrínsecos. Notar que controles fora do elemento FORM não podem ser controles bem sucedidos.

17.3 O elemento FORM

<!ELEMENTO FORM - - (%block;|SCRIPT)+ -(FORM) -- formulários interativos --> 

<!ATTLIST FORM
  %attrs;                              -- %coreattrs, %i18n, %events --
  action      %URI;          #REQUIRED -- arquivo server-side para processamento --
  method      (GET|POST)     GET       -- Método HTTP usado para envio --
  enctype     %ContentType;  "application/x-www-form-urlencoded"
  accept      %ContentTypes; #IMPLIED  -- lista dos MIME types para upload --
  name        CDATA          #IMPLIED  -- nome do formúlario para scripts --
  onsubmit    %Script;       #IMPLIED  -- formulário foi enviado --
  onreset     %Script;       #IMPLIED  -- formulário foi resetado --
  accept-charset %Charsets;  #IMPLIED  -- lista de caracteres suportados --
  >

O elemento FORM atua como um container para os controles. Ele define:

• O layout do formulário (determinado pelos conteúdos do formulário ).
• O programa que irá processar o formulário enviado (atributo action). O programa deve ser capaz de parsear os pares de nome/valor recebidos e saber fazer uso deles.
• O método de envio dos dados ao servidor ( atributo method ).
• A codificação de caracteres a ser aceita pelo servidor para correto processamento (atributo accept-charset ). Os agentes de usuário devem informar o usuário sobre os valores para o atributo accept-charset e/ou não permitir a entrada de caracteres não reconhecidos.

Um formulário pode pode conter texto e marcação (parágrafos, listas, etc.) em complemento aos controles de formulário.

 <FORM action="http://somesite.com/prog/adduser" method="post">
 ...form contents...
 </FORM>

Consulte a seção envio do formulário para informações de como os agentes de usuário devem preparar e enviar os dados para o servidor bem como a maneira como devem tratar as respostas recebidas.

17.4 O elemento INPUT

<!ENTITY % InputType
  "(TEXT | PASSWORD | CHECKBOX |
    RADIO | SUBMIT | RESET |
    FILE | HIDDEN | IMAGE | BUTTON)"
   >

<!-- o atributo name é requerido para todos exceto para submit e reset -->
<!ELEMENTO INPUT - VAZIO              --  controle de formulário -->

<!ATTLIST INPUT
  %attrs;                              -- %coreattrs, %i18n, %events --
  type        %InputType;    TEXT      -- tipo de entrada --
  name        CDATA          #IMPLIED  -- enviado como parte do formulário --
  value       CDATA          #IMPLIED  -- para botões rádio e checkboxes --
  checked     (checked)      #IMPLIED  -- para botões rádio e checkboxes --
  disabled    (disabled)     #IMPLIED  -- indisponível no contexto --
  readonly    (readonly)     #IMPLIED  -- para texto e senha --
  size        CDATA          #IMPLIED  -- especifica para cada tipo de campo --
  maxlength   NUMBER         #IMPLIED  -- máximo de caracteres em um campo de texto --
  src         %URI;          #IMPLIED  -- para campos com imagens --
  alt         CDATA          #IMPLIED  -- descrição curta --
  usemap      %URI;          #IMPLIED  -- mapa de imagem lado do cliente --
  ismap       (ismap)        #IMPLIED  -- mapa de imagem lado do servidor --
  tabindex    NUMBER         #IMPLIED  -- posição na ordem de tabulação --
  accesskey   %Character;    #IMPLIED  -- caracter para atalho em acessibilidade --
  onfocus     %Script;       #IMPLIED  -- elemento tem o foco --
  onblur      %Script;       #IMPLIED  -- elemento perde o foco --
  onselect    %Script;       #IMPLIED  -- algum texto foi selecionado --
  onchange    %Script;       #IMPLIED  -- mudou o valor do elemento --
  accept      %ContentTypes; #IMPLIED  -- lista dos MIME types para upload --
  >

Tag inicial: requerida, Tag final: proibida

17.4.1 Tipos de controle criados com INPUT

O tipo de controle definido pelo elemento INPUT depende do valor do atributo type:

text

Cria um controle do tipo text input com uma linha simples para texto.

password

É semelhante ao tipo "text" acima, com a diferença que o texto de entrada é renderizado de uma tal forma que não mostra os caracteres digitados (p.ex:., uma série de asteriscos). Este tipo de controle é frequentemente usado para entradas sensíveis tais como senhas. Notar que o valor corrente é o texto que foi entrado pelo usuário e não o texto renderizado pelo agente de usuário.

Nota. Desenvolvedores de aplicações devem estar atentos para o fato de que este mecanismo oferece um nível baixo de segurança. Embora a senha seja mascarada pelo agente de usuário a observadores casuais, ela é transmitida ao servidor como texto e poderá ser lida por qualquer um com um nível baixo de acesso a uma rede.

checkbox

Cria checkbox.

radio

Cria radio button.

submit

Cria submit button.

image

Cria um submit button. gráfico. O valor do atributo src especifica a URI da imagem a ser usada na decoração do botão. Por questões de acessibilidade os autores devem fornecer um texto alternativo para a imagem via o uso do atributo alt.

Quando um dispositivo apontador for usado para clicar na imagem o formulério será enviado e as coordenadas do ponto de clicagem passadas ao servidor. O valor x é medido em pixels a contar dfa esquerda da image e o valor y também em pixelsa contar do topo da imagem . Os dados de envio incluem name.x=x-value e name.y=y-value onde "name" é o valor do atributo name e x-value e y-value são os valores das coordenadas x e y respectivamente.

Se o servidor proceder de maneiras diferentes em função da região clicada, os usuários de agentes não gráficos serã prejudicados. Por esta razão os autores devem considerar fornecer meios alternativos:

• Uso de múltiplos botões de envio, (cada um com sua imagem) no lugar de um único botão. Os autores devem usar folhas de estilo para posicionar os botões.
• Uso de mapa de imagem no lado do cliente juntamente com script.

reset

Cria reset button.

button

Cria push button. Agentes de usuário devem usar o valor do atributo value como um rótulo para o botão.

hidden

Cria hidden control.

file

Cria um controle file select. Agentes de usuário devem usar o valor do atributo value como valor inicial para o nome do arquivo.

17.4.2 Exemplos de formulários contendo controles INPUT

 <FORM action="http://somesite.com/prog/adduser" method="post">

    <P>
    First name: <INPUT type="text" name="firstname"><BR>
    Last name: <INPUT type="text" name="lastname"><BR>
    email: <INPUT type="text" name="email"><BR>

    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>
    <INPUT type="submit" value="Send"> <INPUT type="reset">

    </P>
 </FORM>

<HEAD>
<META http-equiv="Content-Script-Type" content="text/javascript">
</HEAD>
<BODY>

 <FORM action="..." method="post">
    <P>
    <INPUT type="button" value="Click Me" onclick="verify()">
 </FORM>
</BODY>

<FORM action="http://server.dom/cgi/handle"
    enctype="multipart/form-data"
    method="post">
 <P>
 What is your name? <INPUT type="text" name="name_of_sender">

 What files are you sending? <INPUT type="file" name="name_of_files">
 </P>
</FORM>

17.5 O elemento BUTTON

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- push button -->
<!ATTLIST BUTTON
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED  -- enviado ao servidor quando submetido --
  type        (button|submit|reset) submit -- para uso como botão de formulário --
  disabled    (disabled)     #IMPLIED  -- indisponível neste contexto --
  tabindex    NUMBER         #IMPLIED  -- posição na ordem de tabulação --
  accesskey   %Character;    #IMPLIED  -- caracter para atalho em acessibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento tem o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perde o foco --
  >

Tag inicial: requerida, Tag final: requerida

Botões criados com o elemento BUTTON tem funções idênticas aos botões criados com o elemento INPUT, mas oferecem maiores possibilidades de renderização: o elemento BUTTON deve ter um conteúdo. Por exemplo: o elemento BUTTON que contém uma imagem atua como e pode se parecer com um elemento INPUT cujo type é definido como "image", mas o elemento tipo BUTTON permite conteúdo.

Agentes de usuário podem renderizar botões BUTTON com efeito em relêvo e que se mova acima/abaixo quando clicado, enquanto para botões INPUT a renderização deve ser como imagens "planas".

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>
    First name: <INPUT type="text" name="firstname"><BR>

    Last name: <INPUT type="text" name="lastname"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>

    <BUTTON name="submit" value="submit" type="submit">
    Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
    <BUTTON name="reset" type="reset">
    Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
    </P>

 </FORM>

Lembrar que os autores devem fornecer um texto alternativo para o elemento IMG.

É ilegal associar um mapa de imagem com uma IMG que sirva de conteúdo para um elemento BUTTON.

<BUTTON>
<IMG src="foo.gif" usemap="...">

</BUTTON>

17.6 Os elementos SELECT, OPTGROUP e OPTION

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector -->
<!ATTLIST SELECT
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED  -- nome do campo --
  size        NUMBER         #IMPLIED  -- linhas visíveis --
  multiple    (multiple)     #IMPLIED  -- default é seleção única --
  disabled    (disabled)     #IMPLIED  -- indisponível neste contexto --
  tabindex    NUMBER         #IMPLIED  -- posição na ordem de tabulação --
  onfocus     %Script;       #IMPLIED  -- o elemento tem o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perde o foco --
  onchange    %Script;       #IMPLIED  -- o valor do elemento mudou --
  >

Tag inicial: requerida, Tag final: requerida

O elemenmto SELECT cria um menu. Cada item do menu é representado por um elemento OPTION. Um elemento SELECT deve conter pelo menos um elemento OPTION.

O elemento OPTGROUP permite aos autores agrupar logicamente opções do menu. Isto é muito útil quando o usuário tem que fazer escolhas em uma lista muito extensa de opções; ao agrupar opções de natureza idêntica o usuário terá facilitada a tarefa de localizar e lembrar das opções escolhidas, o que não ocorreria em uma simples e longa lista de opções corridas. No HTML 4, todos os elementos OPTGROUP devem ser especificados diretamente dentro do elemento SELECT (isto é, agrupamentos não podem ser aninhados).

17.6.1 Pré-seleção de opções

Zero ou mais escolhas podem ser pre-selecionadas pelo usuáriou. Os agentes de usuário devem determinar a pré-seleção conforme a seguir:

• Se não houver um elemento OPTION com o atributo selected definido, o comportamento do agente de usuário para escolha da opção pré-selecionada é indefinido. Nota. Uma vez que diferentes implementações tratam deste caso de modo diverso, esta especificação difere do que prevê as RFC 1866 ([RFC1866] em sua seção 8.1.3), que diz o seguinte:

  O valor inicial é o da primeira opção, exceto quando um atributo SELECTED for definido para qualquer um dos elementos <OPTION>.

  Uma vez que há esta diferença de interpretação por parte dos agentes de usuário, os autores deve assegurar-se de que cada menu possui um elemento OPTION pré-selecionado.

• Se um elemento OPTION tem o atributo selected definido, ele deve ser pré-selecionado.
• Se um elemento SELECT tem o atributo multiple definido e mais do que um elemento OPTION tem o atributo selected definidot, eles todos devem ser pré-selecionados.
• É considerado um erro, se mais de um elemento OPTION tem o atributo selected definido e o elemento SELECT não tem o atributo multiple definido. Os agentes de usuário tratam diferentemente este erro, mas não devem pré-selecionar mais de uma opção.

<!ELEMENT OPTGROUP - - (OPTION)+ -- grupamento de opções -->
<!ATTLIST OPTGROUP
  %attrs;                              -- %coreattrs, %i18n, %events --
  disabled    (desabilitado)     #IMPLIED  -- indisponível neste contexto --
  label       %Text;         #REQUIRED -- para uso em menus hierárquicos --
  >

Tag inicial: requerida, Tag final: requerida

<!ELEMENT OPTION - O (#PCDATA)         -- escolha selecionável -->
<!ATTLIST OPTION
  %attrs;                              -- %coreattrs, %i18n, %events --
  selected    (selecionada)     #IMPLIED
  disabled    (desabilitada)     #IMPLIED  -- indisponível neste contexto --
  label       %Text;         #IMPLIED  -- para uso em menus hierárquicos --
  value       CDATA          #IMPLIED  -- valor default para o conteúdo do elemento --
  >

Tag inicial: requerida, Tag final: optional

Quando renderizar um menu de escolhas o agente de usuário devem usar o valor do atributo label do elemento OPTION como opção de escolha. Se este atributo não for especificado, o agente de usuário deve usar o conteúdo do elemento OPTION.

O atributo label para o elemento OPTGROUP especifica um rótulo para um grupamento de escolhas.

<FORM action="http://somesite.com/prog/component-select" method="post">

   <P>
   <SELECT multiple size="4" name="component-select">
      <OPTION selected value="Component_1_a">Component_1</OPTION>
      <OPTION selected value="Component_1_b">Component_2</OPTION>
      <OPTION>Component_3</OPTION>

      <OPTION>Component_4</OPTION>
      <OPTION>Component_5</OPTION>
      <OPTION>Component_6</OPTION>
      <OPTION>Component_7</OPTION>

   </SELECT>
   <INPUT type="submit" value="Send"><INPUT type="reset">
   </P>
</FORM>

<FORM action="http://somesite.com/prog/someprog" method="post">
 <P>
 <SELECT name="ComOS">
     <OPTION selected label="none" value="none">None</OPTION>
     <OPTGROUP label="PortMaster 3">

       <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1</OPTION>
       <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5</OPTION>
     </OPTGROUP>

     <OPTGROUP label="PortMaster 2">
       <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="IRX">

       <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R</OPTION>
       <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R</OPTION>
     </OPTGROUP>
 </SELECT>
</FORM>

  None
  PortMaster 3
      3.7.1
      3.7
      3.5
  PortMaster 2
      3.7
      3.5
  IRX
      3.7R
      3.5R

17.7 O elemento TEXTAREA

<!ELEMENT TEXTAREA - - (#PCDATA)       -- campo de texto multi linhas -->
<!ATTLIST TEXTAREA
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  rows        NUMBER         #REQUIRED
  cols        NUMBER         #REQUIRED
  disabled    (disabled)     #IMPLIED  -- indisponível neste contexto --
  readonly    (readonly)     #IMPLIED
  tabindex    NUMBER         #IMPLIED  -- posição na ordem de tabulação --
  accesskey   %Character;    #IMPLIED  -- caracter para atalho em acessibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento tem o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perde o foco --
  onselect    %Script;       #IMPLIED  -- um texto foi selecionado --
  onchange    %Script;       #IMPLIED  -- o valor do elemento mudou --
  >

Tag inicial: requerida, Tag final: requerida

O elemento TEXTAREA cria um controle multi-linha text input. Agentes de usuário devem usar o conteúdo deste elemento com o valor inicial do controle e devem ainda renderizar inicialmente este texto.

<FORM action="http://somesite.com/prog/text-read" method="post">
   <P>

   <TEXTAREA name="thetext" rows="20" cols="80">
   First line of initial text.
   Second line of initial text.
   </TEXTAREA>
   <INPUT type="submit" value="Send"><INPUT type="reset">
   </P>
</FORM>

17.8 O elemento ISINDEX

ISINDEX está em desuso. Este elemento cria um controle text input de uma linha de texto simples. Autores devem usar o elemento INPUT para criar controles text input.

Ver Transitional DTD para definição formal deste elemento.

O elemento ISINDEX cria um controle text input de uma linha de texto simples que permite entrar um número qualquer de caracteres. Agentes de usuário podem usar o valor do atributo prompt como um título para o prompt.

<ISINDEX prompt="Enter your search phrase: ">

<FORM action="..." method="post">
<P>Enter your search phrase: <INPUT type="text"></P>
</FORM>

17.9 Rótulos

Alguns controles de formulárioe têm rótulos a eles associados automaticamente (botões para serem clicados) enquanto a maioria não os tem (campos de texto, checkboxes, botões rádio e menus).

Para os controles que têm rótulos implícitos os agentes de usuário devem usar o valor do atributo value como a string para o rótulo.

O elemento LABEL é usado para especificar rótulos para controles que não os tenham implicitamente.

17.9.1 O elemento LABEL

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- texto de rótulo para campo de formulário -->
<!ATTLIST LABEL
  %attrs;                              -- %coreattrs, %i18n, %events --
  for         IDREF          #IMPLIED  -- casa com o campo de valor ID  --
  accesskey   %Character;    #IMPLIED  -- caracter para atalho em acessibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento tem o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perde o foco --
  >

Tag inicial: requerida, Tag final: requerida

O elemento LABEL deve ser usado para agregar informação a controles. Cada elemento LABEL é associado a um e somente um controle no formulário.

O atributo for associa explicitamente um rótulo com outro controle: o valor do atributo for deve ser o mesmo valor do atributo id do elemento controle a ele associado. Mais de um LABEL podem ser associados com o mesmo controle criando múltipla referências via o atributo for.

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="fname">First Name</LABEL>
    <TD><INPUT type="text" name="firstname" id="fname">

  <TR>
    <TD><LABEL for="lname">Last Name</LABEL>
    <TD><INPUT type="text" name="lastname" id="lname">
</TABLE>
</FORM>

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>

    <LABEL for="firstname">First name: </LABEL>
              <INPUT type="text" id="firstname"><BR>
    <LABEL for="lastname">Last name: </LABEL>
              <INPUT type="text" id="lastname"><BR>

    <LABEL for="email">email: </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>

    <INPUT type="submit" value="Send"> <INPUT type="reset">
    </P>
 </FORM>

Para associar implicitamente um rótulo com outro controle, o elemento controle deve estar contido no elemento LABEL. Neste caso o elemento LABEL deve conter apenas um elemento controle. O rótulo em si pode ser posicionado tanto antes quanto depois do controle a ele associado.

<FORM action="..." method="post">
<P>

<LABEL>
   First Name
   <INPUT type="text" name="firstname">
</LABEL>
<LABEL>
   <INPUT type="text" name="lastname">
   Last Name
</LABEL>

</P>
</FORM>

Quanto o elemento LABEL recebe o foco, ele passa o foco para seu controle associado. Ver a seção access keys para exemplos.

Os rótulos devem ser renderizados por todos os tipos de agentes de usuários (isto é, visualmente, lidos por sintetizadores de voz, etc.)

17.10 Adicionando estrutura aos formulários: os elementos FIELDSET e LEGEND

<!--
  #PCDATA para casos de conteúdos mixtos,
  pelas especificações são permitidos somente espaços em branco!
 -->
<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- controle de grupamentos -->
<!ATTLIST FIELDSET
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)*       -- legenda de campo -->

<!ATTLIST LEGEND
  %attrs;                              -- %coreattrs, %i18n, %events --
  accesskey   %Character;    #IMPLIED  -- caracter para atalho em acessibilidade --
  >

Tag inicial: requerida, Tag final: requerida

O elemento FIELDSET possibilita aos autores agrupar tematicamente controle e seus respectivos que guardem alguma relação entre si. Agrupar controles facilita o entendimento para os usuários ao mesmo tempo que facilita a ordem de tabulação tanto para agentes de usuário visuais como para tecnologias baseadas em navegação por voz. Um criterioso uso deste elemento incrementa a acessibilidade ao documento.

O elemento LEGEND possibilita aos autores definir um caption (uma legenda) ao FIELDSET. A legenda incrementa a acessibilidade quando o FIELDSET é renderizado em agentes de usuário não visuais.

<FORM action="..." method="post">
 <P>

 <FIELDSET>
  <LEGEND>Personal Information</LEGEND>
  Last Name: <INPUT name="personal_lastname" type="text" tabindex="1">
  First Name: <INPUT name="personal_firstname" type="text" tabindex="2">
  Address: <INPUT name="personal_address" type="text" tabindex="3">

  ...more personal information...
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Medical History</LEGEND>
  <INPUT name="history_illness" 
         type="checkbox" 
         value="Smallpox" tabindex="20"> Smallpox
  <INPUT name="history_illness" 
         type="checkbox" 
         value="Mumps" tabindex="21"> Mumps
  <INPUT name="history_illness" 
         type="checkbox" 
         value="Dizziness" tabindex="22"> Dizziness
  <INPUT name="history_illness" 
         type="checkbox" 
         value="Sneezing" tabindex="23"> Sneezing
  ...more medical history...

 </FIELDSET>
 <FIELDSET>
  <LEGEND>Current Medication</LEGEND>
  Are you currently taking any medication? 
  <INPUT name="medication_now" 
         type="radio" 
         value="Yes" tabindex="35">Yes
  <INPUT name="medication_now" 
         type="radio" 
         value="No" tabindex="35">No

  If you are currently taking medication, please indicate
  it in the space below:
  <TEXTAREA name="current_medication" 
            rows="20" cols="50"
            tabindex="40">

  </TEXTAREA>
 </FIELDSET>
</FORM>

17.11 Dando foco a um elemento

Em um documento HTML um elemento deve receber o foco do usuário com a finalidade de torn´-lo ativo e cumprir suas tarefas. Por exemplo: usuários devem ativar um lenk especificado pelo elemento A para seguir ao destino especificado pelo link. De modo similar, usuários devem dar o foco a uma TEXTAREA para entrar um texto.

Existem várias maneiras de dar o foco a um elemento:

• Designar o elemento com um dispositivo apontador.
• Navegar de um elemento a outro com uso do teclado. O autor do documento deve definir uma ordem de tabulação que defina a ordem em que os elementos recebem o foco quando o usuário navega com o teclado (ver ordem de tabulação). Uma vez selecionado (pelo foco) o elemento deve ser ativado por uma outra sequência de teclas.
• Selecionar o elemento através de access key (as vezes chamado de "tecla de atalho" ou " tecla aceleradorar").

17.11.1 Navegação por tabulação

A ordem de tabulação define a ordem em que os elementos receberão o foco quando navegados com uso do teclado. A ordem de tabulação deve contemplar elementos aninhados em outros elementos.

Elementos que devem receber o foco podem ser navegados nos agentes de usuário de acordo com as seguintes regras:

1. Elementos que suportam o atributo tabindex e tenham um valor positivo definido são navegados em primeiro. A navegação procede do elemento com o menor para o maior valor de tabindex. Os valores não precisam ser sequêncial e nem começar com um valor específico. Os elementos que tenham o mesmo valor para tabindex devem ser navegados na ordem em que aparecem no fluxo da codificação.
2. Para elementos que não suportam o atributo tabindex ou suportam e tem definido para eles um valor "0" serão navegados a por último na ordem em que aparecem no fluxo da codificação.
3. Elementos (desabilitados) disabled não participam da ordem de tabulação.

Os seguintes elementos suportam o atributo tabindex: A, AREA, BUTTON, INPUT, OBJECT, SELECT, e TEXTAREA.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>

<HEAD>
<TITLE>A document with FORM</TITLE>
</HEAD>
<BODY>
...some text...
<P>Go to the 
<A tabindex="10" href="http://www.w3.org/">W3C Web site.</A>

...some more...
<BUTTON type="button" name="get-database"
           tabindex="1" onclick="get-database">
Get the current database.
</BUTTON>
...some more...
<FORM action="..." method="post">
<P>
<INPUT tabindex="1" type="text" name="field1">
<INPUT tabindex="2" type="text" name="field2">

<INPUT tabindex="3" type="submit" name="submit">
</P>
</FORM>
</BODY>
</HTML>

17.11.2 Access keys (Teclas de atalho)

A ação de pressionar uma tecla de atalho faz com que o foco seja dado ao elemento ao qual foi definida a tecla. O que ocorre quando um elemento recebe o foco depende do elemento. Por exemplo: quando o usuário ativa um link definido pelo elemento A o agente de usuário em geral segue o link. Quando o usuário ativa um botão rádio o agente de usuário faz com que o valor do botão rádio troque. Quando o usuário ativa um campo de texto, ele permite entrada de texto pelo usuário, etc.

Os seguintes elementos suportam o atributo accesskey: A, AREA, BUTTON, INPUT, LABEL, e LEGEND, e TEXTAREA.

<FORM action="..." method="post">
<P>
<LABEL for="fuser" accesskey="U">
User Name
</LABEL>
<INPUT type="text" name="user" id="fuser">
</P>
</FORM>

<P><A accesskey="C" 
      rel="contents"
      href="http://someplace.com/specification/contents.html">
    Tabela de conteúdos</A>

A ativação de uma tecla de atalho depende do sistema usado. Por exemplo: em máquinas rodando MS Windows, geralmente a ativação se dará quando for pressionada a tecla "alt" juntamente com a tecla de atalho. Em sistemas Apple, geralmente a ativação se dará quando for pressionada a tecla "cmd" juntamente com a tecla de atalho.

A renderização indicativa das teclas de atalho depende do agente de usuário. Nós recomendamos que os autores indiquem a tecla de atalho em rótulos de texto nos lugares onde elas se aplicam. Os agentes de usuário deverão renderizar as teclas de atalho de modo a destacá-las e diferenciá-las dos demais caracteres do documento (p.ex.: com um sublinhado)

17.12 Controles desabilitados e somente leitura

Em contextos onde entradas de usuário sejam irrelevantes ou indesejadas é importante desabilitar o controle ou colocá-lo no modo somente leitura. Por exemplo: pode haver a necessidade de desabilitar um botão de envio at´q o momento em que o usuário entre algum dado requerido. Semelhantemente, um autor poderá ter a necessidade de incluir um texto somente para leitura e que deva ser enviado para processamento com o formulário. As seções a seguir descrevem os controles desabilitados e os controles somente para leitura.

17.12.1 Controles desabilitados

Quando definido, o atributo disabled produz os seguintes efeitos em um elemento:

• Desabilita o controle para receber foco.
• Desabilita o controle na navegação por tabulação.
• Desabilita o controle para ser bem sucedido .

Os seguintes elementos suportam o atributo disabled: BUTTON, INPUT, OPTGROUP, OPTION, SELECT, e TEXTAREA.

Este atributo é herdado, contudo uma declaração local sobrescreve o valor herdado.

A maneira como são renderizados os elementos desabilitados depende do agente de usuário. Por exemplo: alguns agentes de usuário renderizam em uma cor "cinza esmaecida" os itens de menu, botões e rótulos desabilitados, etc.

<INPUT disabled name="fred" value="stone">

17.12.2 Controles somente leitura

O atributo readonly especifica se o controle pode ser modificado pelo usuário.

Quando definido, o atributo readonly tem os seguintes efeitos sobre o elemento:

• Elementos read-only recebem o foco mas não podem ser modificados pelo usuário.
• Elementos read-only são incluidos na navegação por tabulação.
• Elementos read-only podem ser bem sucedidos .

Os seguintes elementos suportam o atributo readonly: INPUT e TEXTAREA.

A renderização de elementos read-only depende do agente de usuário.

17.13 Envio do formulário

As seções a seguir explicam como os agentes de usuário enviam os dados do formulário para os agentes de processamento.

17.13.1 Os métodos de envio do formulário

O atributo method do elemento FORM especifica o método HTTP usado para enviar o formulário para o agente de processamento. Este atributo pode assumir dois valores:

• get: com o método HTTP "get" o conjunto dos dados do formulário é colocado como apêndice na URI especificada no atributo action (com um ponto de intorrogação ("?") como um separador) e esta nova URI é enviada ao agente processador.
• post: com o método HTTP "post" o conjunto dos dados do formulário é incluido no corpo do formulário e enviada ao agente processador.

O método "get" deve ser usado quando o formulário for isopotente (isto é., não causa efeitos laterais). Muitas das buscas em banco de dados não causa efeitos laterais visíveis e são ideais para aplicações pelo método "get".

Se o serviço associado com o processamento de um formulário causa efeitos laterais ( poe exemplo: se o formulério modifica um banco de dados ou a subcrição a um serviço), o método "post" deve ser usado.

17.13.2 Controles bem sucedidos

A controle bem sucedido é "valido" para envio e processamento. Cada controle bem sucedido tem seu nome do controle formando um par com o seu valor corrente como parte do conjunto de dados do formulário a ser enviado. Um controle bem sucedido deve ser definido por um elemento FORM e deve ter um nome do controle.

Contudo:

• Controls that are disabled cannot be successful.
• If a form contains more than one submit button, only the activated submit button is successful.
• All "on" checkboxes may be successful.
• For radio buttons that share the same value of the name attribute, only the "on" radio button may be successful.
• For menus, the control name is provided by a SELECT element and values are provided by OPTION elements. Only selected options may be successful. When no options are selected, the control is not successful and neither the name nor any values are submitted to the server when the form is submitted.
• The current value of a file select is a list of one or more file names. Upon submission of the form, the contents of each file are submitted with the rest of the form data. The file contents are packaged according to the form's content type.
• The current value of an object control is determined by the object's implementation.

If a control doesn't have a current value when the form is submitted, user agents are not requerida to treat it as a successful control.

Furthermore, user agents should not consider the following controls successful:

• Reset buttons.
• OBJECT elements whose declare attribute has been set.

Hidden controls and controls that are not rendered because of style sheet settings may still be successful. For example:

<FORM action="..." method="post">
<P>
<INPUT type="password" style="display:none"  
          name="invisible-password"
          value="mypassword">
</FORM>

17.13.3 Processing form data

Quando o usuário envia um formulário (por exemplo; ativando o botão submit), o agente de usuário procedo como descrito a seguir .

Etapa um: Identica os controles bem sucedidos  

Etapa dois: Constrói um conjunto de dados do formulário 

Um conjunto de dados do formulário é uma sequência de pares nome do controle/valor corrente construida de controles bem sucedidos

Etapa três: Codificar o conjunto de dados do formulário 

O conjunto de dados do formulário é então codificado de acordo com o content type especificado pelo atributo enctype do elemento FORM.

Etapa quatro: Enviar o conjunto de dados do formulário codificado  

Finalmente, os dados codificados são enviados para o agente de processamento designado no atributo action usando o protocolo especificado no atributo method.

Estas especificações não contemplam todos os métodos de submissão válidos e nem os content types que podem ser usados em formulários. Contudo os agentes de usuário para HTML 4 devem suportar as convenções estabelecidas para os seguintes casos:

• Se o method é "get" e a action é uma URI HTTP, o agente de usuário adiciona um sinal "?" ao valor de action, e depois adiciona a codificação do conjunto de dados do formulário, usando o content type "application/x-www-form-urlencoded". O agente de usuário então segue o link para a URI. Neste cenário os dados do formulário estão restritos a codificação ASCII.
• Se o method é"post" e a action é uma URI HTTP, o agente de usuário conduz uma transação HTTP "post" usando o valor do atributo action e uma mensagem criada de acordo com o content type especificado no atributo enctype.

Para qualquer outro valor de action ou method, o comportamento não é especificado.

Os agentes de usuário devem renderizar a resposta de uma transação HTTP "get" e "post" transactions.

17.13.4 Content types para formulários

O atributo enctype de um elemento FORM especifica o content type usado para codificar o conjunto de dados do formulário a ser enviado para o servidor. Os agentes de usuários deverão dar suporte para os content types listados a seguir. O comportamento para content types não listados não é especificado.

Consultar também a seção escaping ampersands in URI attribute values. (escapando ampersands em valores de atributos para URI)

application/x-www-form-urlencoded  

Este é o content type default. Formulários enviados com este content type devem ser codificados como descrito a seguir:

1. Nomes e valores de controles são escapados. Caracteres de espaços são substituidos por '+', e então caracteres reservados são escapados como descrito na [RFC1738], seção 2.2: Caracteres não alfa-numéricos são substituidos por '%HH', o símbolo de porcentagem e dois dígitos hexadecimais representando o código ASCII do caracter. Quebras de linha são representadas como pares "CR LF" (isto é, '%0D%0A').
2. Os nome/valor dos controles são listados na ordem que eles aparecem no documento. O nome é separado do valor por um sinal '=' e os pares nome/valor são separados por um sinal '&'.

multipart/form-data  

O content type "application/x-www-form-urlencoded" é ineficiente para envio de grande quantidade de dados binários ou textos contendo caracteres não-ASCII. O content type "multipart/form-data" deve ser usado para enviar formulários contendo arquivos com dados não-ASCII e com dados binários.

O content "multipart/form-data" segue as regras para todos os fluxos de dados para MIME multi- parte como mostrado nas [RFC2045]. A definição de "multipart/form-data" está disponível nos registros de [IANA].

Uma menssagem "multipart/form-data" contém uma série de partes, cada uma delas representando um controle bem sucedido. As partes são enviadas para processamento na mesma ordem em que aparecem no fluxo do documento. Indefinição nas fronteiras das partes não deve ocorrer em nenhum dos dados; como isto é feito está fora dos escopo desta especificação.

Como ocorre com todos os tipos de MIME multi-partes, cada parte tem um header "Content-Type" opcional, que por default é "text/plain". Os agentes de usuário devem fornecer o header "Content-Type" acompanhado pelo parâmetro "charset".

Espera-se que cada par contenha :

1. Um header "Content-Disposition" cujo valor é "form-data".
2. Um atributo name especificado no nome do controle do controle correspondente. Nomes de controle codificados originariamente em conjunto de caracteres não-ASCII devem ser codificados usando o método previsto nas [RFC2045].

Assim, por exemplo, para um controle chamado "mycontrol", a parte correspondente deve ser especificada assim:

Content-Disposition: form-data; name="mycontrol"

Tal como para todas as transmissões MIME, "CR LF" (isto é, '%0D%0A') é usado para separar linhas de dados.

Cada parte deve ser codificada e o header "Content-Transfer-Encoding" fornecido se o valor da parte não for conforme a codificação default (7BIT) (ver [RFC2045], seção 6)

Se o conteúdo de um arquivo é submetido com o formulário, a entrada do arquivo deve ser identificada com o content type apropriado (p.ex.: "application/octet-stream"). Se múltiplos arquivos devem retornar como resultado de uma entrada única, devem ser retornados como "multipart/mixed" incorporados dentro de "multipart/form-data".

O agente de usuário deve fornecer um nome de arquivo para cada arquivo enviado para processamento. O nome de arquivo deve ser especificado no parâmetro "filename" do header 'Content-Disposition: form-data' ou, no caso de múltiplos arquivos, em um header 'Content-Disposition: file' da sub-parte. Se o nome do arquivo do sistema operacional do cliente não for em US-ASCII, o nome deve ser aproximado ou codificado usando o método previsto nas [RFC2045]. Isto é conveniente para os casos, onde por exemplo, os arquivos a enviar devem conter referências uns aos outros (isto é, um arquivo TeX e seus ".sty" arquivos descritivos auxiliares).

O exemplo a seguir mostra uma codificação "multipart/form-data". Suponha que tenhamos o seguinte formulário:

 <FORM action="http://server.com/cgi/handle"
       enctype="multipart/form-data"
       method="post">
   <P>
   What is your name? <INPUT type="text" name="submit-name"><BR>
   What files are you sending? <INPUT type="file" name="files"><BR>

   <INPUT type="submit" value="Send"> <INPUT type="reset">
 </FORM>

Se o usuário entrar com "Larry" no campo de texto, e selecionar o arquivo "file1.txt", o agente de usuário deve enviar o seguinte:

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --AaB03x--

Se o usuário selecionar um segundo arquivo (imagem) "file2.gif", o agente de usuário deve construir as partes como mostrado a seguir:

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --BbC04y
   Content-Disposition: file; filename="file2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contents of file2.gif...
   --BbC04y--
   --AaB03x--