17 Formulários

17.1 Introdución aos formulários

Un formulário HTML é unha sección dun documento que contén conteúdo normal, código, elementos especiais chamados contróis (recadros de verificación, botóns de rádio, menus, etc.) e etiquetas deses contróis. Os usuários normalmente "completan" un formulário modificando os seus contróis (introducindo texto, seleccionando elementos dos menus, etc.) antes de enviar-lle o formulário a un axente para que este o procese (p.ex.: a un servidor web, a un servidor de correo, etc.).

 <FORM action="http://unsitio.com/prog/adicionarusuario" method="post">
    <P>
    <LABEL for="nome">Nome: </LABEL>
              <INPUT type="text" id="nome"><BR>
    <LABEL for="apelidos">Apelidos: </LABEL>
              <INPUT type="text" id="apelidos"><BR>
    <LABEL for="email">email: </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sexo" value="Home"> Home<BR>
    <INPUT type="radio" name="sexo" value="Muller"> Muller<BR>
    <INPUT type="submit" value="Enviar"> <INPUT type="reset">
    </P>
 </FORM>

17.2 Contróis

Os usuários interaccionan cos formulários através de contróis con nome.

O "nome de control" dun control vai definido polo seu atributo name . O rango dun atributo name para un control que estexa dentro dun elemento FORM é o elemento FORM .

Cada control ten un valor inicial e un valor actual, e ambos os dous son cadeas de caracteres. Consulte a definición de cada control se precisar de información sobre os valores iniciais e posíbeis restricións sobre os valores que o control poida impor. En xeral, o "valor inicial" dun control pode-se especificar co atributo value do elemento control. Porén, o valor inicial dun elemento TEXTAREA ven determinado polo seu conteúdo e o valor inicial dun elemento OBJECT nun formulário ven determinado pola implementación do obxecto (ou sexa, fica fóra do ámbito desta especificación).

O "valor actual" dun control asigna-se primeiro ao valor inicial. A partir de entón, o valor actual do control pode ser modificado através da interacción co usuário e con scripts.

O valor inicial dun control non varia. Asi, cando se limpa un formulário, o valor actual de cada control volve a ser o valor inicial. Se un control non ten un valor inicial, non se define o efecto dunha limpeza do formulário sobre ese control.

Cando se envia un formulário para ser procesado, alguns contróis os nomes dalguns contróis emparellan-se cos seus valores actuais e esas parellas son enviadas co formulário. Eses contróis cuxos parellas de nome/valor se envian chaman-se contróis exitosos .

17.2.1 Tipos de contróis

A HTML define os seguintes tipos de contróis:

botóns

Os autores poden crear tres tipos de botóns:

• botóns de enviar: Cando se activa, un botón de enviar envia un formulário. Un formulário pode conter máis de un botón de enviar
• botóns de limpeza : Cando se activa, un botón de limpeza limpa todos os contróis e pon-nos nos seus valores iniciais .
• botóns : Os botóns non teñen un comportamento por omisión. Cada botón pode ter scripts do lado do cliente asociados cos atributos de event do elemento. Cando ocorre un evento (p.ex.:, o usuário preme o botón, solta-o, etc.), dispara-se o script asociado.

  Os autores deberian especificar a linguaxe de script dun script de botón por meio dunha declaración do script por omisión (co elemento META ).

Os autores crean botóns co elemento BUTTON ou o elemento INPUT . Consulte as definicións destes elementos para detalles sobre como especificar os distintos tipos de botóns.

Nota. Os autores deberian saber que o elemento BUTTON oferece unhas capacidades de apresentación máis ricas que as do elemento INPUT .

recadros de verificación

Os recadros de verificación (e os botóns de rádio) son interruptores on/off que o usuário pode activar. Un interruptor está "seleccionado" ("on") cando se selecciona o atributo checked do elemento control. Cando se envia un formulário, só poden resultar exitosos os recadros de verificación "seleccionados" ("on").

Nun formulário, vários recadros de verificación poden compartillar o mesmo nome de control. Asi, por exemplo, un recadro de control permite que os usuários seleccionen vários valores da mesma propriedade. Para crear un control de recadro de verificación usa-se o elemento INPUT .

botóns de rádio

Os botóns de rádio son como recadros de verificación, exceito que cando vários deles compartillan o mesmo nome de control , son mutuamente exclusivos: cando un está "seleccionado" ("on"), todos os demáis que teñan o mesmo nome "deseleccionan-se" ("off"). Para crear un control de botón de rádio usa-se o elemento INPUT .

Se nengun botón de rádio dun conxunto que compartille o mesmo nome de control está seleccionado inicialmente, non se define o comportamento do axente de usuário para escoller que control está inicialmente seleccionado. Nota. Dado que as implementacións existentes tratan este caso de maneira diferente, a especificación actual difire de RFC 1866 ( [RFC1866] sección 8.1.2.4), que afirma:

En todos os casos, exactamente un dos botóns de rádio dun grupo está seleccionao. Se nengun dos elementos <INPUT> dun grupo de botóns de rádio especifica `CHECKED' ("seleccionado"), entón o axente de usuário debe seleccionar inicialmente o primeiro botón de rádio do grupo.

Dado que o comportamento dos axentes de usuário difire, os autores deberian-se asegurar de que en cada grupo de botóns de rádio se selecciona un deles inicialmente.

menus

Os menus oferecen-lles aos usuários opcións de entre as cais poden escoller. O elemento SELECT crea un menu, en combinación cos elementos OPTGROUP e OPTION .

entrada de texto

Os autores poden crear dous tipos de contróis que permiten que os usuários introduzan texto. O elemento INPUT crea un control de entrada de unha só liña e o elemento TEXTAREA crea un control de entrada de várias liñas. En ambos os dous casos, o texto introducido converte-se no valor actual do control.

seleccion de ficheiros

Este tipo de control permite que o usuário seleccione ficheiros para que os seus conteúdos se poidan enviar cun formulário. Para crear un control de selección de ficheiros usa-se o elemento INPUT .

contróis ocultos

Os autores poden crear contróis que non se mostran mais cuxos valores son enviados cun formulário. Os autores normalmente usan este tipo de control para armacenar información entre intercámbios cliente/servidor que se non se perderian debido à natureza (ver [RFC2616] ). Para crear un control oculto usa-se o elemento INPUT .

contróis de obxecto

Os autores poden inserir obxectos xenéricos nos formulários de tal maneira que os seus valores asociados se envian xunto cos demáis contróis. Para crear contróis de obxectos os autores poden usar o elemento OBJECT .

Os elementos usados para crear contróis normalmente aparecen dentro dun elemento FORM , mais tamén poden aparecer fora dunha declaración de elemento FORM cando se usan para construir interfaces de usuário. Isto trata-se na sección sobre acontecimentos intrínsecos. Observe-se que os contróis que aparecen fora dun formulário non poden ser contróis exitosos .

17.3 O elemento FORM

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulário interactivo -->
<!ATTLIST FORM
  %attrs;                              -- %coreattrs, %i18n, %events --
  action      %URI;          #REQUIRED -- procesador de formulários do lado do servidor --
  method      (GET|POST)     GET       -- método HTTP utilizado para enviar o formulário--
  enctype     %ContentType;  "application/x-www-form-urlencoded"
  accept      %ContentTypes; #IMPLIED  -- lista de tipos MIME para o envio de ficheiros --
  name        CDATA          #IMPLIED  -- nome do formulário para os scripts --
  onsubmit    %Script;       #IMPLIED  -- enviou-se o formulário --
  onreset     %Script;       #IMPLIED  -- limpou-se o formulário --
  accept-charset %Charsets;  #IMPLIED  -- lista de conxuntos de caracteres aceitados --
  >

Etiqueta inicial: requerida , Etiqueta final: requerida

O elemento FORM actua como contentor de contróis . Especifica:

• A composición do formulário (dada polos conteúdos do elemento).
• O programa que tratará o formulário completado e enviado (o atributo action ). O programa receptor debe ser capaz de analisar as parellas nome/valor para pode-las utilizar.
• O método polo que se enviarán ao servidor os dados do usuário (o atributo method ).
• Unha codificación de caracteres que deba ser aceitada polo servidor para poder tratar este formulário (o atributo accept-charset ). Os axentes de usuário deben-lle aconsellar ao usuário o valor do atributo accept-charset e/ou restrinxir a capacidade do usuário de introducir caracteres que non se recoñezan.

Un formulário pode conter texto e código (parágrafos, listas, etc.) ademáis dos contróis de formulário.

 <FORM action="http://unsitio.com/prog/adicionarusuario" method="post">
 ...conteúdo do formulário...
 </FORM>

Consulte a sección sobre envio de formulários para información sobre como os axentes de usuários deben preparar os dados dos formulários para os servidores e como os axentes de usuário deberian tratar as respostas esperadas.

17.4 O elemento INPUT

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

<!-- require-se o atributo name para todos exceito para os botons enviar e limpar -->
<!ELEMENT INPUT - O EMPTY              -- control de formulário -->
<!ATTLIST INPUT
  %attrs;                              -- %coreattrs, %i18n, %events --
  type        %InputType;    TEXT      -- que tipo de control se necesita --
  name        CDATA          #IMPLIED  -- enviar como parte do formulário --
  value       CDATA          #IMPLIED  -- especificar para botóns de rádio e recadros de verificación --
  checked     (checked)      #IMPLIED  -- para botóns de rádio e recadros de verificación --
  disabled    (disabled)     #IMPLIED  -- non disponíbel neste contexto --
  readonly    (readonly)     #IMPLIED  -- para texto e contrasinais --
  size        CDATA          #IMPLIED  -- especificar para cada tipo de campo --
  maxlength   NUMBER         #IMPLIED  -- número máximo de caracteres para os campos de texto --
  src         %URI;          #IMPLIED  -- para campos con imaxes --
  alt         CDATA          #IMPLIED  -- descrición corta --
  usemap      %URI;          #IMPLIED  -- usar mapa de imaxes do lado do cliente --
  ismap       (ismap)        #IMPLIED  -- usar mapa de imaxes do lado do servidor --
  tabindex    NUMBER         #IMPLIED  -- posición na orde de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter da tecla de acesibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento recebeu o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perdeu o foco --
  onselect    %Script;       #IMPLIED  -- seleccionou-se texto --
  onchange    %Script;       #IMPLIED  -- o valor do elemento mudou --
  accept      %ContentTypes; #IMPLIED  -- lista de tipos MIME para o envio de ficheiros --
  >

Etiqueta inicial: requerida, Etiqueta final: proibida

17.4.1 Tipos de control creados con INPUT

O tipo de control definido polo elemento INPUT depende do valor do atributo type :

text

Crea un control entrada de texto de unha só liña.

password

Como "text", mais o texto de entrada mostra-se de xeito que se escondan os caracteres (p.ex., unha série de asteriscos). Este tipo de control usa-se con frecuéncia para entradas sensíbeis, tais como contrasinais. Observe-se que o valor actual é o texto introducido polo usuário, non o texto mostrado polo axente de usuário.

Nota. Os deseñadores de aplicacións deberian fixar-se en que este mecanismo proporciona só unha seguranza reducida. Ainda que o contrasinal vai mascarado para observadores casuais polo axente de usuário, transmite-se ao servidor en texto simples e pode ser lido por calquer con aceso à rede de baixo nível.

checkbox

Crea un recadro de verificación.

radio

Crea un botón de rádio.

submit

Crea un botón de enviar.

image

Crea un botón de enviar gráfico. O valor do atributo src especifica o URI da imaxe que decorará o botón. Por razóns de acesibilidade, os autores deberian fornecer un texto alternativo para a imaxe através do atributo alt .

Cando se usa un dispositivo de ponteiro para facer clic na imaxe, envia-se o formulário e as coordenadas do clic pasan-se ao servidor. O valor x mide-se en pontos desde a esquerda da imaxe e o valor y en pontos desde a parte superior da imaxe. Os dados enviados incluen nome .x=valor-x e nome.y=valor-y, onde "nome" é o valor do atributo name e valor-x e valor-y son os valores das coordenadas x e y, respectivamente.

Se o servidor realiza accións diferentes dependendo do sítio no que se fixo clic, os usuários de navegadores non visuais estarán en desvantaxe. Por esta razón, os autores deberian considerar focaxes alternativas:

• Usar vários botóns de enviar (cada un coa sua própria imaxe) en lugar de un único botón gráfico de enviar. Os autores poden usar follas de estilo para controlar a posición destes botóns.
• Usar un mapa de imaxes do lado do servidor xunto cun script.

reset

Crea un botón de limpeza.

button

Crea un botón. Os axentes de usuário deberian usar o valor do atributo value como etiqueta do botón.

hidden

Crea un control oculto.

file

Crea un control de selección de ficheiro . Os axentes de usuário poden usar o valor do atributo value como nome inicial do ficheiro.

17.4.2 Exemplos de contróis que conteñen elementos INPUT

 <FORM action="http://unsitio.com/prog/adicionarusuario" method="post">
    <P>
    Nome: <INPUT type="text" name="nome"><BR>
    Apelidos: <INPUT type="text" name="apelidos"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sexo" value="Home"> Home<BR>
    <INPUT type="radio" name="sexo" value="Muller"> Muller<BR>
    <INPUT type="submit" value="Enviar"> <INPUT type="reset" value="Limpar">
    </P>
 </FORM>

<HEAD>
<META http-equiv="Content-Script-Type" content="text/javascript">
</HEAD>
<BODY>
 <FORM action="..." method="post">
    <P>
    <INPUT type="button" value="Fai clic aqui" onclick="verify()">
 </FORM>
</BODY>

<FORM action="http://servidor.dom/cgi/tratar"
    enctype="multipart/form-data"
    method="post">
 <P>
 Cal é o seu nome? <INPUT type="text" name="nome_de_quen_envia">
 Que ficheiros vai enviar? <INPUT type="file" name="nome_dos_ficheiros">
 </P>
</FORM>

17.5 O elemento BUTTON

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- botón -->
<!ATTLIST BUTTON
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED  -- remetido ao servidor ao enviar --
  type        (button|submit|reset) submit -- para usar como botón de formulário --
  disabled    (desactivado)  #IMPLIED  -- non disponíbel neste contexto --
  tabindex    NUMBER         #IMPLIED  -- posición na orde de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter da tecla de acesibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento recebeu o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perdeu o foco --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

Os botóns creados co elemento BUTTON funcionan exactamente igual que os botóns creados co elemento INPUT , mais oferecen posibilidades de apresentación máis ricas: o elemento BUTTON pode ter conteúdo. Por exemplo, un elemento BUTTON que conteña unha imaxe funciona como e pode parecer-se a un elemento INPUT cuxo type sexa "image", mais o tipo de elemento BUTTON permite conteúdo.

Os axentes de usuário visuais poden mostrar botóns BUTTON con relevo e movimento para riba e abaixo cando se fai clic neles encanto os botóns INPUT se mostran como imaxes "planas".

 <FORM action="http://unsitio.com/prog/adicionarusuario" method="post">
    <P>
    Nome: <INPUT type="text" name="nome"><BR>
    Apelidos: <INPUT type="text" name="apelidos"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sexo" value="Home"> Home<BR>
    <INPUT type="radio" name="sexo" value="Muller"> Muller<BR>
    <BUTTON name="enviar" value="enviar" type="submit">
    Send<IMG src="/icons/tremendo.gif" alt="tremendo"></BUTTON>
    <BUTTON name="limpar" type="reset">
    Limpar<IMG src="/icons/vaia-vaia.gif" alt="vaia-vaia"></BUTTON>
    </P>
 </FORM>

Lembre que os autores deben fornecer un texto alternativo para un elemento IMG .

É ilegar asociar un mapa de imaxes cun IMG que aparece como o conteúdo dun elemento BUTTON .

<BUTTON>
<IMG src="oquesexa.gif" usemap="...">
</BUTTON>

17.6 Os elementos SELECT , OPTGROUP , e OPTION

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- selector de opcións -->
<!ATTLIST SELECT
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED  -- nome do campo --
  size        NUMBER         #IMPLIED  -- filas visíbeis --
  multiple    (múltiple)     #IMPLIED  -- por omisión é selección simples --
  disabled    (desactivado)  #IMPLIED  -- non disponíbel neste contexto --
  tabindex    NUMBER         #IMPLIED  -- posición na orde de tabulación --
  onfocus     %Script;       #IMPLIED  -- o elemento recebeu o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perdeu o foco --
  onchange    %Script;       #IMPLIED  -- mudou o valor do elemento --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

O elemento SELECT crea un menu . Cada opción ofertada polo menu representa-se cun elemento OPTION . Un elemento SELECT debe conter cando menos un elemento OPTION .

O elemento OPTGROUP permite que os autores agrupen as escollas loxicamente. Isto é especialmente útil cando o usuário deba escoller dunha lista de opcións longa; os grupos de opcións relacionadas son máis fáceis de comprender e lembrar que unha lista única longa de opcións. Na HTML 4, hai que especificar todos os elementos OPTGROUP directamente cun elemento SELECT (isto é, os grupos non poden estar aniñados).

17.6.1 Opcións pré-seleccionadas

Poden-se pré-seleccionar nengunha ou máis opcións para o usuário. Os axentes de suário deberian determinar que opcións se pré-seleccionan como segue:

• Se nengun elemento OPTION tiver o atributo selected activado, non se define o comportamento do axente de usuário para escoller que opción está activada inicialmente. Nota. Dado que as implementacións existentes tratan este caso de maneira distinta, a especificación actual difire de RFC 1866 ( [RFC1866] sección 8.1.3), que afirma:

  O etado inicial ten a primeira opción seleccionada, a non ser que estexa presente un atributo SELECTED ("seleccionado") nun dos elementos <OPTION>.

  Dado que o comportamento dos axentes de usuário difire, os autores deberian-se asegurar de que cada menu inclui unha OPTION pré-seleccionada por omisión..

• Se un elemento OPTION ten o atributo selected activado, deberia ser pré-seleccionado.
• Se o elemento SELECT ten o atributo multiple activado e máis dun elemento OPTION teñen o atributo selected seleccionado, deberian todos ser pré-seleccionados.
• Considera-se un erro se máis dun elemento OPTION teñen o atributo selected activado e o elemento SELECT non ten o atributo multiple activado. Os axentes de usuário poden variar no modo como tratan este erro, mais non deberian pré-seleccionar máis dunha opción.

<!ELEMENT OPTGROUP - - (OPTION)+ -- grupo de opcións -->
<!ATTLIST OPTGROUP
  %attrs;                              -- %coreattrs, %i18n, %events --
  disabled    (disabled)     #IMPLIED  -- non disponíbel neste contexto --
  label       %Text;         #REQUIRED -- para usar con menus hierárquicos --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

<!ELEMENT OPTION - O (#PCDATA)         -- escolla seleccionábel -->
<!ATTLIST OPTION
  %attrs;                              -- %coreattrs, %i18n, %events --
  selected    (seleccionado)	#IMPLIED
  disabled    (desactivado)	#IMPLIED  -- non disponíbel neste contexto --
  label       %Text;         #IMPLIED  -- para usar con menus hierárquicos --
  value       CDATA          #IMPLIED  -- toma por omisión o valor do elemento --
  >

Ao representar unha escolla de menu, os axentes de usuário deberian usar o valor do atributo label do elemento OPTION como opción. Se non se especifica este atributo, os axentes de usuário deberian usar o conteúdo do elemento OPTION .

O atributo label do elemento OPTGROUP especifica a etiqueta dun grupo de opcións.

<FORM action="http://unsitio.com/prog/seleccionar-componentes" method="post">
   <P>
   <SELECT multiple size="4" name="seleccionar-componentes">
      <OPTION selected value="Componente_1_a">Componente_1</OPTION>
      <OPTION selected value="Componente_1_b">Componente_2</OPTION>
      <OPTION>Componente_3</OPTION>
      <OPTION>Componente_4</OPTION>
      <OPTION>Componente_5</OPTION>
      <OPTION>Componente_6</OPTION>
      <OPTION>Componente_7</OPTION>
   </SELECT>
   <INPUT type="submit" value="Enviar"><INPUT type="reset">
   </P>
</FORM>

<FORM action="http://unsitio.com/prog/unprograma" method="post">
 <P>
 <SELECT name="ComOS">
     <OPTION selected label="nengun" value="nengun">Nengun</OPTION>
     <OPTGROUP label="PortMaster 3">
       <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 con ComOS 3.7.1</OPTION>
       <OPTION label="3.7" value="pm3_3.7">PortMaster 3 con ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm3_3.5">PortMaster 3 con ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="PortMaster 2">
       <OPTION label="3.7" value="pm2_3.7">PortMaster 2 con ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm2_3.5">PortMaster 2 con ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="IRX">
       <OPTION label="3.7R" value="IRX_3.7R">IRX con ComOS 3.7R</OPTION>
       <OPTION label="3.5R" value="IRX_3.5R">IRX con ComOS 3.5R</OPTION>
     </OPTGROUP>
 </SELECT>
</FORM>

  Nengun
  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 de várias liñas -->
<!ATTLIST TEXTAREA
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  rows        NUMBER         #REQUIRED
  cols        NUMBER         #REQUIRED
  disabled    (desactivado)	#IMPLIED  -- non disponíbel neste contexto --
  readonly    (só leitura)	#IMPLIED
  tabindex    NUMBER         #IMPLIED  -- posición na orde de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter da tecla de acesibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento recebeu o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perdeu o foco --
  onselect    %Script;       #IMPLIED  -- seleccionou-se texto --
  onchange    %Script;       #IMPLIED  -- o valor do elemento mudou --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

O elemento TEXTAREA crea un control de entrada de texto de várias liñas. Os axentes de usuário deberian usar os conteúdos deste elemento como valor inicial do control e deberian mostrar este valor inicialmente.

<FORM action="http://unsitio.com/prog/ler-o-texto" method="post">
   <P>
   <TEXTAREA name="otexto" rows="20" cols="80">
   Primeira liña do texto inicial.
   Segunda liña do texto inicial.
   </TEXTAREA>
   <INPUT type="submit" value="Enviar"><INPUT type="reset">
   </P>
</FORM>

17.8 O elemento ISINDEX

ISINDEX está desaprovado . Este elemento crea un control de entrada de texto de unha única liña. Os autores deberian usar o elemento INPUT para crear contróis de entrada de texto .

Vexa-se a DTD Transicional para a sua definición formal.

O elemento ISINDEX crea un control de entrada de texto dunha única liña que permite calquer cantidade de caracteres. Os axentes de usuário poden usar o valor do atributo prompt como título da entrada ("prompt").

<ISINDEX prompt="Introduza a sua frase de pesquisa: ">

<FORM action="..." method="post">
<P>Introduza a sua frase de pesquisa: <INPUT type="text"></P>
</FORM>

17.9 Etiquetas

Alguns contróis teñen etiquetas asociadas automaticamente con eles (botóns que se premen) encanto a maioria non (campos de texto, recadros de verificación e botóns de rádio e menus).

Para eses contróis que teñen etiquetas implícitas, os axentes de usuário deberian usar o valor do atributo value como cadea da etiqueta.

O elemento LABEL usa-se para especificar etiquetas para os contróis que non teñen etiquetas específicas.

17.9.1 The LABEL element

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- texto de etiqueta de campo de formulário -->
<!ATTLIST LABEL
  %attrs;                              -- %coreattrs, %i18n, %events --
  for         IDREF          #IMPLIED  -- corresponde ao valor ID do campo --
  accesskey   %Character;    #IMPLIED  -- carácter da tecla de acesibilidade --
  onfocus     %Script;       #IMPLIED  -- o elemento recebeu o foco --
  onblur      %Script;       #IMPLIED  -- o elemento perdeu o foco --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

O elemento LABEL pode-se usar para xuntar-lle información aos contróis. Cada elemento LABEL asocia-se con exactamente un control de formulário.

O atributo for asocia explicitamente unha etiqueta con outro control: o valor do atributo for debe ser o mesmo que o valor do atributo id do elemento control asociado. Poden-se asociar máis de un LABEL co mesmo control creando várias referéncias co atributo for .

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="nomeproprio">Nome</LABEL>
    <TD><INPUT type="text" name="nome" id="nomeproprio">
  <TR>
    <TD><LABEL for="apelido">Apelidos</LABEL>
    <TD><INPUT type="text" name="apelidos" id="apelido">
</TABLE>
</FORM>

 <FORM action="http://unsitio.com/prog/adicionarusuario" method="post">
    <P>
    <LABEL for="nome">Nome: </LABEL>
              <INPUT type="text" id="nome"><BR>
    <LABEL for="apelidos">Apelidos: </LABEL>
              <INPUT type="text" id="apelidos"><BR>
    <LABEL for="email">email: </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sexo" value="Home"> Home<BR>
    <INPUT type="radio" name="sexo" value="Muller"> Muller<BR>
    <INPUT type="submit" value="Enviar"> <INPUT type="reset">
    </P>
 </FORM>

Para asociar unha etiqueta implicitamente con outro control, o elemento control debe estar entre os conteúdos do elemento LABEL . Neste caso, LABEL só pode conter un elemento control. A etiqueta mesma pode colocar-se antes ou depóis do control asociado.

<FORM action="..." method="post">
<P>
<LABEL>
   Nome 
   <INPUT type="text" name="nome">
</LABEL>
<LABEL>
   <INPUT type="text" name="apelidos">
   Apelidos
</LABEL>
</P>
</FORM>

Cando un elemento LABEL recebe o foco , pasa-lle o foco ao seu control asociado. Vexa-se máis abaixo a sección sobre teclas de aceso para exemplos.

Os axentes de usuário poden mostrar as etiquetas de moi diversas maneiras (por exemplo, visualmente , lidas por sintetizadores de voz, etc.).

17.10 Adicionar-lle estrutura aos formulários : os elementos FIELDSET e LEGEND

<!--
  #PCDATA é para resolver o problema dos conteúdos mixtos,
  pola especificación, aqui só se permite espazo en branco!
 -->
<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- grupo de contróis de formulário -->
<!ATTLIST FIELDSET
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)*       -- lexenda de fieldset -->

<!ATTLIST LEGEND
  %attrs;                              -- %coreattrs, %i18n, %events --
  accesskey   %Character;    #IMPLIED  -- carácter da tecla de acesibilidade --
  >

Etiqueta inicial: requerida, Etiqueta final: requerida

O elemento FIELDSET permite que os autores agrupen contróis e etiquetas relacionados tematicamente. Agrupar os contróis facilita que os usuários comprendan o seu obxectivo encanto que facilitan a navegación con tabular nos axentes de usuário visuais e a navegación pola voz nos axentes de usuário baseados na voz. O uso adecuado deste elemento fai que os decumentos sexan máis acesíbeis.

O elemento LEGEND permite que os autores lle asignen un título a un FIELDSET . A lexenda mellora a acesibilidade cando o FIELDSET se mostra de maneira non visual.

<FORM action="..." method="post">
 <P>
 <FIELDSET>
  <LEGEND>Información persoal</LEGEND>
  Apelidos: <INPUT name="persoal_apelidos" type="text" tabindex="1">
  First Name: <INPUT name="persoal_nome" type="text" tabindex="2">
  Enderezo: <INPUT name="persoal_enderezo" type="text" tabindex="3">
  ...máis información persoal...
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Historial médico</LEGEND>
  <INPUT name="historial_doenzas" 
         type="checkbox" 
         value="variola" tabindex="20"> Variola
  <INPUT name="historial_doenzas" 
         type="checkbox" 
         value="Papeiras" tabindex="21"> Papeiras
  <INPUT name="historial_doenzas" 
         type="checkbox" 
         value="Vertixes" tabindex="22"> Vertixes
  <INPUT name="historial_doenzas" 
         type="checkbox" 
         value="Catarros" tabindex="23"> Catarros
  ...máis historial médico...
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Medicación actual</LEGEND>
  Está a tomar algunha medicación agora? 
  <INPUT name="medicación_agora" 
         type="radio" 
         value="Si" tabindex="35">Si
  <INPUT name="medication_now" 
         type="radio" 
         value="Non" tabindex="35">Non

  Se está a tomar algunha medicación agora, indique-a
  no espazo que segue:
  <TEXTAREA name="medicacion_actual" 
            rows="20" cols="50"
            tabindex="40">
  </TEXTAREA>
 </FIELDSET>
</FORM>

17.11 Dar-lle o foco a un elemento

Nun documento HTML, un elemento debe receber o foco do usuário para activar-se e realizar as suas tarefas. Por exemplo, os usuários deben activar un vínculo especificado polo elemento A para seguir un vínculo especificado. Do mesmo xeito, os usuários deben-lle dar o foco a un TEXTAREA para introducir texto nel.

Hai várias maneiras de lle dar o foco a un elemento:

• Designar o elemento cun mecanismo de ponteiro.
• Navegar dun elemento ao seguinte co teclado. O autor do documento pode definir unha orde de tabulación que especifique a orde na que os elementos receberán o foco se o usuário navega o documento co teclado (ver navegación co tabulador ). Unha vez seleccionado, un elemento pode ser activado por outra secuéncia de teclas.
• Seleccionar un elemento mediante unha tecla de aceso (chamada às veces "atallo de teclado" ou "acelerador de teclado").

17.11.1 Navegación co tabulador

A orde de tabulación define a orde na que os elementos receberán o foco cando se navegue co teclado. A orde de tabulación pode incluir elementos aniñados dentro doutros.

Os axentes de usuário deberian navegar polos elementos que poden receber o foco segundo as regras seguintes:

1. Aqueles elementos qeu aceiten o atributo tabindex e lle asignen un valor positivo serán navegados primeiro. A navegación progrede do elemento co valor de tabindex máis baixo cara o elemento co valor máis alto. Os valores non teñen por que seren secuenciais nen teñen que comezar por un valor en concreto. Os elementos que teñen valores tabindex idénticos deberian seren navegados na orde na que aparecen no fluxo de caracteres.
2. Aqueles elementos que non aceitan o atributo tabindex ou o aceitan e lle asignan o valor de "0" van depóis. Estes elementos son navegados na orde na que aparecen no fluxo de caracteres.
3. Os elementos que están desactivados non participan na orde de tabulación.

Os elementos seguintes aceitan 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>Un documento con FORM</TITLE>
</HEAD>
<BODY>
...texto...
<P>Vaia ao 
<A tabindex="10" href="http://www.w3.org/">sítio web do W3C.</A>
...máis...
<BUTTON type="button" name="coller-base-de-dados"
           tabindex="1" onclick="coller-base-de-dados">
Coller a base de dados actual.
</BUTTON>
...máis...
<FORM action="..." method="post">
<P>
<INPUT tabindex="1" type="text" name="campo1">
<INPUT tabindex="2" type="text" name="campo2">
<INPUT tabindex="3" type="submit" name="enviar">
</P>
</FORM>
</BODY>
</HTML>

17.11.2 Teclas de aceso

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

<FORM action="..." method="post">
<P>
<LABEL for="fusuario" accesskey="U">
Nome
</LABEL>
<INPUT type="text" name="usuario" id="fusuario">
</P>
</FORM>

<P><A accesskey="C" 
      rel="índice"
      href="http://unsitio.com/especificacion/inidice.html">
    Índice</A>

A invocación de teclas de aceso depende depende do sistema sobre o que se traballe. Por exemplo, en máquinas que estexan a correr MS Windows, normalmente hai que presionar a tecla "alt" ademáis da tecla de aceso. Nos sistemas Apple, normalmente hai que presionar a tecla "cmd" ademáis da tecla de aceso.

A representación das teclas de aceso depende do axente de usuário. Recomendamos que os autores incluan a tecla de aceso en texto de etiqueta ou ondequer que se vai aplicar a tecla de aceso. Os axentes de usuário deberian mostrar o valor dunha tecla de aceso de tal xeito que se realce o seu papel e se distingua doutros caracteres (por exemplo, subliñando-a).

17.12 Contróis desactivados e de só leitura

En contextos nos que a entrada do usuário é ou non desexada ou irrelevante, é importante poder desactivar un control ou mostrá-lo como de só leitura. Por exemplo, pode-se querer desactivar un control de enviar até que o usuário teña introducido algun dado requerido. Do mesmo xeito, un autor pode querer incluir un texto de só leitura que deba ser enviado como un valor xunto co formulário. As seccións qu seguen descreben os contróis desactivados e de só leitura.

17.12.1 Contróis desactivados

Se se selecciona, o atributo disabled ten os seguintes efectos sobre un elemento:

• Os contróis desactrivados non receben o foco .
• Os contróis desactivados saltan-se na navegación con tabulador .
• Os contróis desactivados non poden ser exitosos .

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

Este atributo herda-se mais as declaracións locais poden ignorar o valor herdado.

Como se mostren os elementos desactivados depende do axente de usuário. Por exemplo, alguns axentes de usuário "poñen en gris" os elementos de menu desactivados, as etiquetas dos botóns, etc.

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

17.12.2 Contróis de só leitura

O atributo readonly especifica se o control pode ser modificado polo usuário.

Se está seleccionado, o atributo readonly ten os seguintes efectos sobre un elemento:

• Os elementos de só leitura receben o foco mais o usuário non os pode eliminar.
• Os elementos de só leitura incluen-se na navegación con tabulador .
• Os elementos de só leitura poden ser exitosos .

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

Como se mostren os elementos de só leitura depende do axente de usuário.

17.13 Envio de formulários

As seccións que seguen explican como os axentes de usuário lles envian dados de formulários aos axentes de procesamento de formulários.

17.13.1 Método de envio de formulários

O atributo method do elemento FORM especifica o método HTTP que se usará para enviar o formulário ao axente de procesamento. Este atributo pode tomar dous valores:

• get: Co método "get" do HTTP o conxunto de caracteres do formulário xunta-se ao URI indicado polo atributo action (cun interrogante ("?") como separador) e este novo URI é enviado ao axente de procesamento.
• post: Co método "post" do HTTP "post" o conxunto de caracteres do formulário inclue-se no corpo do formulário e envia-se ao axente de procesamento.

O método "get" deberia-se usar cando o formulário é (isto é, non produce efectos colaterais). Moitas pesquisas en bancos de dados non teñen efectos colaterais visíbeis e resultan aplicacións ideais para o método "get".

Se o servizo asociado ao procesamento dun formulário causa efectos colaterais (por exemplo, se os formulário modifica unha base de dados ou o asinamento a un servizo), deberia-se usar o método "post".

17.13.2 Contróis exitosos

Un control exitoso é "válido" para ser enviado. Cada control exitoso ten o seu nome de control emparellado co seu valor actual como parte do conxunto de caracteres do formulário enviado. Un control exitoso debe estar definido dentro dun elemento FORM e ter un nome de control.

Porén:

• Os contróis que están desactivados non poden ser exitosos.
• Se un formulário contén máis do que un botón de enviar , só o botón de enviar activado será exitoso.
• Todos os recadros de verificación en "on" poden ser exitosos.
• Para os botóns de rádio que compartillan o mesmo valor do atributo name , só o botón de rádio que estexa en "on" pode ser exitoso.
• Para os menus , o nome do control é fornecido por un elemento SELECT e os valores son fornecidos polos elementos OPTION . Só poden ser existosas as opcións seleccionadas. Cando non hai opcións seleccionadas, o control non é exitoso e nen o nome nen nengun valor se envian ao servidor cando se envia o formulário.
• O valor actual dunha selección de ficheiros é unha lista de un ou máis nomes de ficheiros. Unha vez enviado o formulário, os conteúdos de cada fila envian-se xunto co resto dos dados do formulário. Os conteúdos do ficheiro empacotan-se dacordo co tipo de conteúdo do formulário.
• O valor actual dun control de obxecto ven determinado pola implementación do obxecto.

Se un control non tiver un valor actual cando se envia o formulário, non se requer que os axentes de usuário o traten como un control exitoso.

Ademáis, os axentes de usuário non deberian considerar exitosos os seguintes contróis:

• Botóns de limpar.
• elementos OBJECT cuxo atributo declare fose activado.

Os contróis ocultos e os contróis que non se mostran a causa da disposición das follas de estilo poden ainda seren exitosos. Por exemplo:

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

17.13.3 Procesamento dos dados de formulários

Cando un usuário envia un formulário (por exemplo, activando un botón de enviar ), o axente de usuário procesa-o da maneira que segue:

Primeiro paso: Indentificar os contróis exitosos  

Segundo paso: Construir un conxunto de dados do formulário

Un conxunto de dados dun formulário é unha secuéncia de parellas nome do control /valor actual construída para os contróis exitosos.

Terceiro paso: Codificación do conxunto de dados do formulário

O conxunto de dados do formulário codifica-se entón dacordo co tipo de conteúdo indicado co atributo enctype do elemento FORM .

Cuarto paso: Enviar o conxunto de dados do formulário codificados

Por último, os dados codificados envian-se ao axente de procesamento designado polo atributo action mediante o protocolo designado polo atributo method .

Esta especificación non especifica todos os métodos de envio válidos ou os tipos de conteúdo que se poden usar cos formulários. Porén, os axentes de usuário HTML 4 deben aceitar as convencións estabelecidas nos casos seguintes:

• Se o method é "get" e a action é un URI do HTTP, o axente de usuário toma o valor de action , adiciona-lle un`?'e logo adiciona o conxunto de dados do formulário , codificados usando o tipo de conteúdo "application/x-www-form-urlencoded" . O axente de usuário entón segue este URI. Neste caso, os dados do formulário limitan-se aos códigos ASCII.
• Se o method é "post" e a action é un URI do HTTP, o axente de usuário dirixe unha transacción "post" do HTTP usando o valor do atributo action e unha mensaxe creada dacordo co tipo de conteúdo especificado co atributo enctype .

Para calquer outro valor de action ou method non se especifica o comportamento.

Os axentes de usuário deberian mostrar a resposta das transaccións "get" e "post" do HTTP.

17.13.4 Tipos de conteúdo de formulário

O atributo enctype do elemento FORM indica o tipo de conteúdo usado para codificar o conxunto de dados do formulário para enviar ao servidor. Os axentes de usuário deben aceitar os tipos de conteúdo listados máis abaixo. Non se especifica o comportamento doutros tipos de conteúdo.

Consulte-se tamén a sección sobre escapar o signo "&" nos valores de atributo de URI .

application/x-www-form-urlencoded  

Este é o tipo de conteúdo por omisión. Os formulários enviados con este tipo de conteúdo deben-se codificar da maneira seguinte:

1. Escapan-se os nomes de control e os valores. Os caracteres de espazo substituen-se por '+', e entón os caracteres reservados escapan-se como se descrebe en [RFC1738] , sección 2.2: Os caracteres non alfanuméricos substituen-se con `%HH', un signo de percentaxe e dous díxitos hexadecimais que representen o código ASCII do carácter. Os saltos de liña representan-se como parellas "CR LF" (ou sexa, `%0D%0A').
2. Os nomes/valores de control listan-se na orde na que aparecen no documento. O nome separa-se do valor por `=' e as parellas nome/valor separan-se un do outro por `&'.

multipart/form-data  

O tipo de conteúdo"application/x-www-form-urlencoded" non é efectivo para enviar cantidades grandes de dados binários ou texto que conteña caracteres non ASCII. O tipo de conteúdo "multipart/form-data" deberia-se usar para enviar formulários que conteñan ficheiros, dados non ASCII e dados binários.

O conteúdo "multipart/form-data" segue as regras de todos os fluxos de dados MIME en várias partes tal e como se bosquexa en [RFC2045] . A definición de "multipart/form-data" está disponíbel no rexisto da [IANA] .

Unha mensaxe "multipart/form-data" contén unha série de partes e cada unha representa un control exitoso . As partes envian-se ao axente de procesamento na mesma orde na que os contróis correspondentes aparecen no fluxo do documento. Os limites das partes non deberian aparecer en nengun dos dados; como se faga isto fica fora do ámbito desta especificación.

Como en todos os tipos MIME de várias partes, cada parte ten un cabezallo "Content-Type" opcional que ten "text/plain" por omisión. Os axentes de usuário deberian aceitar o cabezallo "Content-Type" acompañado dun "charset".

Espera-se que cada parte conteña:

1. un cabezallo "Content-Disposition" cuxo valor é "form-data".
2. un atributo de nome que especifique o nome de control do control correspondentel. Os nomes de control codificados orixinalmente en xogos de caracteres non ASCII poden-se codificar usando o método bosquexado en [RFC2045] .

Asi, por exemplo, para un control chamado "omeucontrol", a parte correspondente especificaria-se asi:

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

Como en todas as transmisións MIME, usa-se "CR LF" (ou sexa, `%0D%0A') para separar liñas de dados.

Pode-se codificar cada parte e proporcionar o cabezallo "Content-Transfer-Encoding" se o valor desa parte non é conforme coa codificación por omisión (7BIT) (ver [RFC2045] , sección 6)

Se se enviaren os conteúdos dun ficheiro cun formulário, a entrada do ficheiro deberia ser identificada co tipo de conteúdo adecuado (p.ex.:"application/octet-stream"). Se se tiveren que devolver vários ficheiros como resultado dunha entrada de formulário única, deberian-se devolver como "multipart/mixed" incluídos dentro de "multipart/form-data".

O axente de usuário deberia tentar fornecer un nome de ficheiro para cada ficheiro enviado. O nme de ficheiro pode-se especificar co parámetro "filename" do cabezallo 'Content-Disposition: form-data' ou, no caso de vários ficheiros, nun cabezallo 'Content-Disposition: file' da subparte. Se o nome do ficheiro do sistema operacional do cliente non está en US-ASCII, o nome do ficheiro pode ser aproximado ou codificado usando o método de [RFC2045] . Isto é útil nos casos nos que, por exemplo, os ficheiros enviados poderian conter referéncias mútuas (por exemplo, un ficheiro TeX e a sua descrición de estilo auxiliar ".sty").

O exemplo que segue ilustra a codificación "multipart/form-data" encoding. Supoñamos que temos o seguinte formulário:

 <FORM action="http://servidor.com/cgi/tratar"
       enctype="multipart/form-data"
       method="post">
   <P>
   Cal é o seu nome? <INPUT type="text" name="enviar-nome"><BR>
   Que ficheiros vai enviar? <INPUT type="file" name="ficheiros"><BR>
   <INPUT type="submit" value="Enviar"> <INPUT type="reset">
 </FORM>

Se o usuário introduce "Larry" na entrada de texto e seleccionar o ficheiro de texto "texto1.txt", o axente de usuário poderia enviar de volta os seguintes dados:

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

   --AaB03x
   Content-Disposition: form-data; name="enviar-nome"

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

   ... conteúdos de ficheiro1.txt ...
   --AaB03x--

Se o usuário selecciona un segundo ficheiro (de imaxe) "ficheiro2.gif", o axente de usuário poderia construir as partes como segue:

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

   --AaB03x
   Content-Disposition: form-data; name="enviar-nome"

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

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

   ... conteúdos de ficheiro1.txt ...
   --BbC04y
   Content-Disposition: file; filename="ficheiro2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...conteúdos de ficheiro2.gif...
   --BbC04y--
   --AaB03x--