17 Formularios

17.1 Introducción a los formularios

Un formulario HTML es una sección de un documento que contiene contenido normal, código, elementos especiales llamados controles (casillas de verificación (checkboxes), radiobotones (radio buttons), menúes, etc.), y rótulos (labels) en esos controles. Los usuarios normalmente "completan" un formulario modificando sus controles (introduciendo texto, seleccionando objetos de un menú, etc.), antes de enviar el formulario a un agente para que lo procese (p.ej., a un servidor web, a un servidor de correo, etc.)

 <FORM action="http://algunsitio.com/prog/usuarionuevo" method="post">
    <P>
    <LABEL for="nombre">Nombre: </LABEL>
              <INPUT type="text" id="nombre"><BR>
    <LABEL for="apellido">Apellido: </LABEL>
              <INPUT type="text" id="apellido"><BR>
    <LABEL for="email">email: </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sexo" value="Varón"> Varón<BR>
    <INPUT type="radio" name="sexo" value="Mujer"> Mujer<BR>
    <INPUT type="submit" value="Enviar"> <INPUT type="reset">
    </P>
 </FORM>

17.2 Controles

Los usuarios interaccionan con los formularios a través de los llamados controles.

El "nombre de control" de un control viene dado por su atributo name. El "campo de acción" o alcance del atributo name de un control contenido en un elemento FORM es el elemento FORM.

Cada control tiene tanto un valor inicial como un valor actual, que son ambos cadenas de caracteres. Consulte la definición de cada control para obtener información sobre los valores iniciales y las posibles restricciones que puede imponer cada control sobre sus valores. En general, el "valor inicial" de un control puede especificarse con el atributo value del elemento de control. Sin embargo, el valor inicial de un elemento TEXTAREA viene dado por sus contenidos, y el valor inicial de un elemento OBJECT de un formulario está determinado por la implementación del objeto (es decir, se sale fuera del alcance de esta especificación).

El "valor actual" del control se hace en primer lugar igual al valor inicial. A partir de ese momento, el valor actual del control puede ser modificado a través de la interacción con el usuario y mediante scripts.

El valor inicial de un control no cambia. Así, cuando se reinicializa el formulario, el valor actual de cada control se reinicializa a su valor inicial. Si el control no tiene un valor inicial, el efecto de una reinicialización del formulario sobre ese control es indefinido.

Cuando se envía un formulario para su procesamiento, para algunos controles se empareja su nombre con su valor actual, y estas parejas se envían con el formulario. Aquellos controles cuyas parejas nombre/valor se envían se llaman controles con éxito.

17.2.1 Tipos de controles

HTML define los siguientes tipos de controles:

botones

Los autores pueden crear tres tipos de botones:

• botones de envío (submit buttons): Cuando se activa, un botón de envío envía un formulario. Un formulario puede contener más de un botón de envío.
• botones de reinicialización (reset buttons): Cuando se activa, un botón de reinicialización reinicializa todos los controles a sus valores iniciales.
• botones pulsadores (push buttons): Los botones pulsadores no tienen un comportamiento por defecto. Cada botón pulsador puede tener asociados scripts en el lado del cliente a través del atributo event del elemento. Cuando ocurre un evento (p.ej., el usuario aprieta el botón, lo suelta, etc.), se acciona el script asociado.

  Los autores deberían especificar el lenguaje de programación del script de un botón pulsador a través de una declaración de scripts por defecto (con el elemento META).

Los autores crean botones con el elemento BUTTON o el elemento INPUT. Consulte las definiciones de estos elementos para más detalles sobre cómo especificar diferentes tipos de botones.

Nota. Los autores deberían observar que el elemento BUTTON ofrece posibilidades más ricas de representación que el elemento INPUT.

casillas de verificación (checkboxes)

Las casillas de verificación (y los radiobotones) son interruptores de encendido/apagado que pueden ser conmutados por el usuario. Una casilla de verificación está "marcada" cuando se establece el atributo checked del elemento de control. Cuando se envía un formulario, solamente pueden tener éxito los controles de casillas de verificación que estén marcadas.

Varias casillas de verificación de un formulario pueden compartir el mismo nombre de control. Así, por ejemplo, las casillas de verificación permiten a los usuarios elegir varios valores para la misma propiedad. Para crear un control de casilla de verificación se utiliza el elemento INPUT .

radiobotones (radio buttons)

Los radiobotones son como las casillas de verificación, excepto en que cuando varios comparten el mismo nombre de control, son mutuamente exclusivos: cuando uno está "encendido", todos los demás con el mismo nombre se "apagan". Para crear un control de radiobotón se usa el elemento INPUT.

Si ninguno de los radiobotones de un conjunto que comparten el mismo nombre tiene un valor inicial de "encendido", el comportamiento del agente de usuario al elegir cuál es el control que está inicialmente "encendido" queda sin definir. Nota. Debido a que las implementaciones existentes tratan este caso de formas diferentes, la especificación actual difiere de RFC 1866 ([RFC1866] sección 8.1.2.4), que dice:

En cualquier momento, exactamente uno de los radiobotones de un conjunto está marcado. Si ninguno de los elementos <INPUT> de un conjunto de radiobotones especifica 'CHECKED', entonces el agente de usuario debe marcar el primer radiobotón del conjunto inicialmente.

Al diferir los comportamientos de los agentes de usuario, los autores deberían asegurarse de que en cada conjunto de radiobotones hay uno que inicialmente está "encendido".

menúes (menus)

Los menúes ofrecen al usuario opciones entre las cuales elegir. El elemento SELECT crea un menú, en combinación con los elementos OPTGROUP y OPTION.

entrada de texto (text input)

Los autores pueden crear dos tipos de controles que permiten a los usuarios introducir textos. El elemento INPUT crea un control de entrada de una sola línea, y el elemento TEXTAREA crea una control de entrada de varias líneas. En ambos casos, el texto introducido se convierte en el valor actual del control.

selección de ficheros (file select)

Este tipo de control permite al usuario elegir ficheros de modo que sus contenidos puedan ser enviados con un formulario. Se usa el elemento INPUT para crear un control de selección de ficheros.

controles ocultos (hidden controls)

Los autores pueden crear controles que no se muestran pero cuyos valores se envían con un formulario. Los autores usan normalmente este tipo de controles para almacenar información entre intercambios cliente/servidor que de otro modo se perdería debido a la naturaleza no persistente del protocolo HTTP (ver [RFC2616]). Para crear un control oculto se usa el elemento INPUT.

controles tipo objeto (object controls)

Los autores pueden insertar objetos genéricos en los formularios de modo que los valores asociados se envíen junto con los demás controles. Los autores crean controles tipo objeto con el elemento OBJECT.

Los elementos utilizados para crear controles aparecen normalmente dentro de un elemento FORM, pero también pueden aparecer fuera de la declaración de un elemento FORM cuando se utilizan para construir interfaces de usuario. Sobre esto se habla en la sección sobre eventos intrínsecos. Obsérvese que los controles que estén fuera de un formulario no pueden ser controles con éxito.

17.3 El elemento FORM

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulario interactivo -->
<!ATTLIST FORM
  %attrs;                              -- %coreattrs, %i18n, %events --
  action      %URI;          #REQUIRED -- procesador del formulario en el servidor --
  method      (GET|POST)     GET       -- método HTTP usado para enviar formulario --
  enctype     %ContentType;  "application/x-www-form-urlencoded"
  accept      %ContentTypes; #IMPLIED  -- lista de tipos MIME para subir ficheros --
  name        CDATA          #IMPLIED  -- nombre del formulario para los scripts --
  onsubmit    %Script;       #IMPLIED  -- el formulario fue enviado --
  onreset     %Script;       #IMPLIED  -- el formulario fue reinicializado --
  accept-charset %Charsets;  #IMPLIED  -- lista de codif. de caracteres soportadas --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

El elemento FORM actúa como contenedor de controles. Especifica:

• La disposición ("layout") del formulario (dada por los contenidos del elemento).
• El programa que manejará el formulario completado y enviado (el atributo action). El programa receptor debe ser capaz de interpretar las parejas nombre/valor para poder hacer uso de ellas.
• El método por el cual se enviarán los datos del usuario al servidor (el atributo method).
• Una codificación de caracteres que debe ser aceptada por el servidor para poder manejar este formulario (el atributo accept-charset). Los agentes de usuario pueden avisar al usuario del valor del atributo accept-charset y/o restringir al usuario la posibilidad de introducir caracteres no reconocidos.

Un formulario puede contener texto y código (párrafos, listas, etc.) además de controles de formulario.

 <FORM action="http://algunsitio.com/prog/usuarionuevo" method="post">
 ...contenidos del formulario...
 </FORM>

Consulte la sección sobre envío de formularios para información sobre cómo deben preparar los agentes de usuario los datos del formulario para los servidores y cómo deberían tratar los agentes de usuario las respuestas esperadas.

17.4 El elemento INPUT

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

<!-- se requiere el atributo name para todos excepto para submit y reset -->
<!ELEMENT INPUT - O EMPTY              -- control de formulario -->
<!ATTLIST INPUT
  %attrs;                              -- %coreattrs, %i18n, %events --
  type        %InputType;    TEXT      -- qué tipo de control se necesita --
  name        CDATA          #IMPLIED  -- enviar como parte del formulario --
  value       CDATA          #IMPLIED  -- especificar para radiobotones
                                          y casillas de verificación --
  checked     (checked)      #IMPLIED  -- para radiobotones y casillas de verif. --
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  readonly    (readonly)     #IMPLIED  -- para texto y contraseñas --
  size        CDATA          #IMPLIED  -- específico de cada tipo de campo --
  maxlength   NUMBER         #IMPLIED  -- máximo de caracteres para campos de texto --
  src         %URI;          #IMPLIED  -- para campos con imágenes --
  alt         CDATA          #IMPLIED  -- descripción corta --
  usemap      %URI;          #IMPLIED  -- usar mapa de imágenes en el cliente --
  ismap       (ismap)        #IMPLIED  -- usar mapa de imágenes en el servidor --
  tabindex    NUMBER         #IMPLIED  -- posición en el orden de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter de la tecla de accesibilidad --
  onfocus     %Script;       #IMPLIED  -- el foco se dirigió hacia el elemento --
  onblur      %Script;       #IMPLIED  -- el elemento perdió el foco --
  onselect    %Script;       #IMPLIED  -- se seleccionó parte del texto --
  onchange    %Script;       #IMPLIED  -- el valor del elemento fue modificado --
  accept      %ContentTypes; #IMPLIED  -- lista de tipos MIME para subir ficheros --
  >

Etiqueta inicial: obligatoria, Etiqueta final: prohibida

17.4.1 Tipos de controles creados con INPUT

El tipo de control definido por el elemento INPUT depende del valor del atributo type:

text

Crea un control de entrada de texto de una línea.

password

Igual que "text", pero el texto introducido se presentan de tal modo que se oculten los caracteres (p.ej., mediante un serie de asteriscos). Este tipo de control suele utilizarse para datos importantes tales como contraseñas. Obsérvese que el valor actual es el texto introducido por el usuario, no el texto representado por el agente de usuario.

Nota. Los diseñadores de aplicaciones deberían tener en cuenta que este mecanismo ofrece en realidad un nivel muy bajo de seguridad. Aunque la contraseña se oculte a las personas que puedan estar mirando, se transmite al servidor como texto sin enmascarar, y puede ser leído por cualquiera que tenga acceso de bajo nivel a la red.

checkbox

Crea una casilla de verificación o "checkbox".

radio

Crea un radiobotón o "radio button".

submit

Crea un botón de envío o "submit button".

image

Crea un botón de envío gráfico. El valor del atributo src especifica el URI de la imagen que decorará el botón. Por razones de accesibilidad, los autores deberían proporcionar un texto alternativo para la imagen por medio del atributo alt.

Cuando se utiliza un dispositivo apuntador para hacer clic sobre la imagen, se envían al servidor el formulario y la coordenadas en que se pulsó el dispositivo. El valor x se mide en píxeles desde la izquierda de la imagen, y el valor y en píxeles desde la parte superior de la imagen. Los datos enviados incluyen name.x=x-value y name.y=y-value donde "name" es el valor del atributo name, y x-value e y-value son las coordenadas x e y, respectivamente.

Si el servidor realiza acciones diferentes dependiendo del lugar en que se pulsó el dispositivo, los usuarios de navegadores no gráficos estarán en desventaja. Por esta razón, los autores deberían considerar otras alternativas:

• Usar varios botones de envío (cada uno con su imagen) en lugar de un solo botón gráfico de envío. Los autores pueden usar hojas de estilo para controlar la posición de estos botones.
• Usar un mapa de imágenes en el lado del cliente junto con scripts.

reset

Crea un botón de reinicialización o "reset button".

button

Crea un botón pulsador o "push button". Los agentes de usuario deberían usar el valor del atributo value como rótulo del botón.

hidden

Crea un control oculto o "hidden control".

file

Crea un control de selección de fichero o "file select". Los agentes de usuario pueden usar el valor del atributo value para el nombre de fichero inicial.

17.4.2 Ejemplos de formularios con controles INPUT

 <FORM action="http://algunsitio.com/prog/usuarionuevo" method="post">
    <P>
    Nombre: <INPUT type="text" name="nombre"><BR>
    Apellido: <INPUT type="text" name="apellido"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sexo" value="Varón"> Varón<BR>
    <INPUT type="radio" name="sexo" value="Mujer"> Mujer<BR>
    <INPUT type="submit" value="Enviar"> <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="Pínchame" onclick="verificar()">
 </FORM>
</BODY>

<FORM action="http://servidor.com/cgi/procesar"
    enctype="multipart/form-data"
    method="post">
 <P>
 ¿Cómo se llama usted? <INPUT type="text" name="nombre_del_remitente">
 ¿Qué ficheros desea enviar? <INPUT type="file" name="nombre_de_los_ficheros">
 </P>
</FORM>

17.5 El elemento BUTTON

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- botón pulsador -->
<!ATTLIST BUTTON
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED  -- se envía al servidor junto al formulario --
  type        (button|submit|reset) submit -- para usar como botón de formulario --
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  tabindex    NUMBER         #IMPLIED  -- posición en el orden de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter de la tecla de accesibilidad --
  onfocus     %Script;       #IMPLIED  -- el foco se dirigió hacia el elemento --
  onblur      %Script;       #IMPLIED  -- el elemento perdió el foco --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

Los botones creados con el elemento BUTTON funcionan exactamente igual que los botones creados con el elemento INPUT, pero ofrecen posibilidades más ricas de representación: el elemento BUTTON puede tener contenido. Por ejemplo, un elemento BUTTON que contenga una imagen se parece y funciona como un elemento INPUT cuyo atributo type sea igual a "image", pero el tipo de elemento BUTTON permite un contenido.

Los agentes de usuario visuales pueden representar los botones BUTTON con un relieve y un movimiento arriba/abajo al pulsarlos, mientras que pueden representar los botones INPUT como imágenes "planas".

 <FORM action="http://algunsitio.com/prog/usuarionuevo" method="post">
    <P>
    Nombre: <INPUT type="text" name="nombre"><BR>
    Apellido: <INPUT type="text" name="apellido"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sexo" value="Varón"> Varón<BR>
    <INPUT type="radio" name="sexo" value="Mujer"> Mujer<BR>
    <BUTTON name="enviar" value="enviar" type="submit">
    Enviar<IMG src="/iconos/ahivaeso.gif" alt="¡Ahí va eso!"></BUTTON>
    <BUTTON name="reiniciar" type="reset">
    Reinicializar<IMG src="/iconos/ayno.gif" alt="¡Ay, no!"></BUTTON>
    </P>
 </FORM>

Recuérdese que los autores deben proporcionar texto alternativo para los elementos IMG.

Es ilegal asociar un mapa de imágenes con un IMG que aparezca como el contenido de un elemento BUTTON.

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

17.6 Los elementos SELECT, OPTGROUP y OPTION

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- selector de opciones -->
<!ATTLIST SELECT
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED  -- nombre del campo --
  size        NUMBER         #IMPLIED  -- filas visibles --
  multiple    (multiple)     #IMPLIED  -- por defecto es selección simple --
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  tabindex    NUMBER         #IMPLIED  -- posición en el orden de tabulación --
  onfocus     %Script;       #IMPLIED  -- el foco se dirigió hacia el elemento --
  onblur      %Script;       #IMPLIED  -- el elemento perdió el foco --
  onchange    %Script;       #IMPLIED  -- el valor del elemento fue modificado --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

El elemento SELECT crea un menú. Cada opción ofrecida por el menú se representa por un elemento OPTION. Un elemento SELECT debe contener al menos un elemento OPTION.

El elemento OPTGROUP permite a los autores agrupar opciones lógicamente. Esto es particularmente útil cuando el usuario debe elegir de entre una larga lista de opciones; es más fácil apreciar y recordar grupos de opciones relacionadas que una larga lista de opciones sueltas. En HTML 4, todos los elementos OPTGROUP deben especificarse directamente dentro de un elemento SELECT (es decir, no pueden anidarse unos grupos dentro de otros).

17.6.1 Opciones preseleccionadas

Pueden preseleccionarse para el usuario cero o más opciones. Los agentes de usuario deberían determinar qué opciones son preseleccionadas de acuerdo con lo siguiente:

• Si no hay ningún elemento OPTION con el atributo selected establecido, el comportamiento del agente de usuario en cuanto a la elección de la opción seleccionada inicialmente queda sin especificar. Nota. Debido a que las implementaciones existentes tratan de manera diferente este caso, la especificación actual difiere de RFC 1866 ([RFC1866] sección 8.1.3), que dice:

  El estado inicial tiene la primera opción seleccionada, a menos que el atributo SELECTED esté presente en alguno de los elementos <OPTION>.

  Al diferir los comportamientos de los agentes de usuario, los autores deberían asegurarse de que todos los menúes incluyen una OPTION preseleccionada por defecto.

• Si un elemento OPTION tiene el atributo selected activado, debería estar preseleccionado.
• Si el elemento SELECT tiene el atributo multiple activado y hay más de un elemento OPTION que tenga el atributo selected activado, deberían estar todos preseleccionados.
• Se considera un error que haya más de un elemento OPTION con el atributo selected activado y que el elemento SELECT no tenga el atributo multiple establecido. Los agentes de usuario pueden tratar este caso de maneras diferentes, pero no deberían preseleccionar más de una opción.

<!ELEMENT OPTGROUP - - (OPTION)+ -- grupo de opciones -->
<!ATTLIST OPTGROUP
  %attrs;                              -- %coreattrs, %i18n, %events --
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  label       %Text;         #REQUIRED -- para usar en menúes jerárquicos --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

<!ELEMENT OPTION - O (#PCDATA)         -- opción seleccionable -->
<!ATTLIST OPTION
  %attrs;                              -- %coreattrs, %i18n, %events --
  selected    (selected)     #IMPLIED  -- opción preseleccionada --
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  label       %Text;         #IMPLIED  -- para usar en menúes jerárquicos --
  value       CDATA          #IMPLIED  -- por defecto es el contenido del elemento --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

Cuando se represente una opción de un menú, los agentes de usuario deberían usar como opción el valor del atributo label del elemento OPTION. Si este atributo no está especificado, los agentes de usuario deberían usar los contenidos del elemento OPTION.

El atributo label del elemento OPTGROUP especifica el rótulo de un grupo de opciones.

<FORM action="http://algunsitio.com/prog/elegir-componente" method="post">
   <P>
   <SELECT multiple size="4" name="elegir-componente">
      <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://algunsitio.com/prog/algunprograma" method="post">
 <P>
 <SELECT name="ComOS">
     <OPTION selected label="ninguno" value="ninguno">Ninguno</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>

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

17.7 El elemento TEXTAREA

<!ELEMENT TEXTAREA - - (#PCDATA)       -- campo de texto multilínea -->
<!ATTLIST TEXTAREA
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  rows        NUMBER         #REQUIRED
  cols        NUMBER         #REQUIRED
  disabled    (disabled)     #IMPLIED  -- no disponible en este contexto --
  readonly    (readonly)     #IMPLIED
  tabindex    NUMBER         #IMPLIED  -- posición en el orden de tabulación --
  accesskey   %Character;    #IMPLIED  -- carácter de la tecla de accessibilidad --
  onfocus     %Script;       #IMPLIED  -- el foco se dirigió hacia el elemento --
  onblur      %Script;       #IMPLIED  -- el elemento perdió el foco --
  onselect    %Script;       #IMPLIED  -- se seleccionó parte del texto --
  onchange    %Script;       #IMPLIED  -- el valor del elemento fue modificado --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

El elemento TEXTAREA crea un control de entrada de texto multilínea. Los agentes de usuario deberían usar los contenidos de este elemento como valor inicial del control y representar este texto inicialmente.

<FORM action="http://algunsitio.com/prog/leer-texto" method="post">
   <P>
   <TEXTAREA name="eltexto" rows="20" cols="80">
   Primera línea del texto inicial.
   Segunda línea del texto inicial.
   </TEXTAREA>
   <INPUT type="submit" value="Enviar"><INPUT type="reset">
   </P>
</FORM>

17.8 El elemento ISINDEX

ISINDEX está desaprobado. Este elemento crea un control de entrada de texto de una línea. Los autores debería usar el elemento INPUT para crear controles de entrada de texto.

Véase el DTD Transicional para la definición formal.

El elemento ISINDEX crea un control de entrada de texto de una línea que permite cualquier número de caracteres. Los agentes de usuario pueden usar el valor del atributo prompt como cadena indicadora ("prompt").

<ISINDEX prompt="Escriba la frase a buscar: ">

<FORM action="..." method="post">
<P>Entre la frase a buscar: <INPUT type="text"></P>
</FORM>

17.9 Rótulos

A algunos controles de formulario se les asocian rótulos automáticamente (botones pulsadores) aunque a la mayoría no (campos de texto, casillas de verificación y radiobotones, y menúes).

Para aquellos controles que tengan rótulos implícitos, los agentes de usuario deberían utilizar el valor del atributo value como texto del rótulo.

El elemento LABEL se utiliza para especificar rótulos de controles que no tienen rótulos implícitos.

17.9.1 El elemento LABEL

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- texto del rótulo de un
                                            campo de formulario -->
<!ATTLIST LABEL
  %attrs;                              -- %coreattrs, %i18n, %events --
  for         IDREF          #IMPLIED  -- concuerda con el valor ID del campo --
  accesskey   %Character;    #IMPLIED  -- carácter de tecla de accesibilidad --
  onfocus     %Script;       #IMPLIED  -- el foco se dirigió hacia el elemento --
  onblur      %Script;       #IMPLIED  -- el elemento perdió el foco --
  >

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

El elemento LABEL puede utilizarse para adjuntar información a los controles. Cada elemento LABEL se asocia exactamente con un control de formulario.

El atributo for asocia explícitamente un rótulo con otro control: el valor del atributo for debe ser el mismo que el valor del atributo id del elemento de control asociado. Se puede asociar más de un LABEL con el mismo control creando múltiples referencias a través del atributo for.

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="nombre">Nombre</LABEL>
    <TD><INPUT type="text" name="nombre" id="nombre">
  <TR>
    <TD><LABEL for="apellido">Apellido</LABEL>
    <TD><INPUT type="text" name="apellido" id="apellido">
</TABLE>
</FORM>

 <FORM action="http://algunsitio.com/prog/usuarionuevo" method="post">
    <P>
    <LABEL for="nombre">Nombre: </LABEL>
              <INPUT type="text" id="nombre"><BR>
    <LABEL for="apellido">Last name: </LABEL>
              <INPUT type="text" id="apellido"><BR>
    <LABEL for="email">email: </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="sexo" value="Varón"> Varón<BR>
    <INPUT type="radio" name="sexo" value="Mujer"> Mujer<BR>
    <INPUT type="submit" value="Enviar"> <INPUT type="reset">
    </P>
 </FORM>

Para asociar implícitamente un rótulo con otro control, el elemento de control debe estar dentro de los contenidos del elemento LABEL. En este caso, el LABEL sólo puede contener un elemento de control. El rótulo en sí puede colocarse antes o después del control asociado.

<FORM action="..." method="post">
<P>
<LABEL>
   Nombre
   <INPUT type="text" name="nombre">
</LABEL>
<LABEL>
   <INPUT type="text" name="apellido">
   Apellido
</LABEL>
</P>
</FORM>

Cuando el foco se dirige hacia un elemento LABEL, éste pasa el foco a su control asociado. Véanse más adelante en la sección sobre teclas de acceso algunos ejemplos.

Los rótulos pueden ser representados por los agentes de usuario de diferentes maneras (p.ej., visualmente, leídos por sintetizadores de voz, etc.)

17.10 Añadir estructura a los formularios: los elementos FIELDSET y LEGEND

<!--
  #PCDATA es para resolver el problema del contenido mixto,
  de acuerdo con la especificación aquí sólo se permite espacio en blanco!
-->
<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- grupo de controles
                                                     de formulario -->
<!ATTLIST FIELDSET
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)*       -- leyenda del grupo de campos -->

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

Etiqueta inicial: obligatoria, Etiqueta final: obligatoria

El elemento FIELDSET (grupo de campos) permite a los autores agrupar temáticamente controles y rótulos relacionados. Gracias al agrupamiento de controles es más fácil para los usuarios entender su propósito y al mismo tiempo se facilita la navegación con agentes de usuario visuales y la navegación por voz para agentes de usuario basados en voz. El uso correcto de este elemento hace los documentos más accesibles.

El elemento LEGEND permite a los autores asignar un título a un FIELDSET. La leyenda mejora la accesibilidad cuando el FIELDSET no se representa visualmente.

<FORM action="..." method="post">
 <P>
 <FIELDSET>
  <LEGEND>Información Personal</LEGEND>
  Apellido: <INPUT name="personal_apellido" type="text" tabindex="1">
  Nombre: <INPUT name="personal_nombre" type="text" tabindex="2">
  Dirección: <INPUT name="personal_dirección" type="text" tabindex="3">
  ...más información personal...
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Historial Médico</LEGEND>
  <INPUT name="historial_enfermedades" 
         type="checkbox" 
         value="Viruela" tabindex="20"> Viruela
  <INPUT name="historial_enfermedades" 
         type="checkbox" 
         value="Paperas" tabindex="21"> Paperas
  <INPUT name="historial_enfermedades" 
         type="checkbox" 
         value="Mareos" tabindex="22"> Mareos
  <INPUT name="historial_enfermedades" 
         type="checkbox" 
         value="Resfriado" tabindex="23"> Resfriado
  ...más historial médico...
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Medicación Actual</LEGEND>
  ¿Está tomando actualmente algún tipo de medicación? 
  <INPUT name="medicacion_ahora" 
         type="radio" 
         value="Sí" tabindex="35">Sí
  <INPUT name="medicacion_ahora" 
         type="radio" 
         value="No" tabindex="35">No

  Si está tomando actualmente algún tipo de medicación, indíquela
  en el espacio proporcionado a continuación:
  <TEXTAREA name="medicacion_actual" 
            rows="20" cols="50"
            tabindex="40">
  </TEXTAREA>
 </FIELDSET>
</FORM>

17.11 Dirigir el foco hacia un elemento

En un documento HTML, el usuario debe dirigir el foco hacia un elemento para que éste se active y realice sus funciones. Por ejemplo, los usuarios deben activar un vínculo especificado con el elemento A para seguir el vínculo específicado. Análogamente, los usuarios deben dirigir el foco hacia un TEXTAREA para poder introducir texto en su interior.

Hay varias maneras de dirigir el foco hacia un elemento:

• Designar el elemento con un dispositivo apuntador.
• Navegar de un elemento a otro con el teclado. El autor del documento puede definir un orden de tabulación que especifique el orden en que se dirige el foco hacia los elementos si el usuario navega por el documento usando el teclado (ver navegación con tabulador). Una vez seleccionado, el elemento puede activarse con alguna otra secuencia de teclas.
• Seleccionar un elemento por medio de una tecla de acceso (a veces llamada "acelerador de teclado").

17.11.1 Navegación con tabulador

El orden de tabulación define el orden en que el foco se dirige hacia los elementos cuando se navega por medio del teclado. El orden de tabulación puede incluir elementos anidados en otros elementos.

Los agentes de usuario deberían navegar por los elementos a los que puede dirigirse el foco de acuerdo con las siguientes reglas:

1. Navegar en primer lugar por aquellos elementos que soporten el atributo tabindex y tengan asignado para éste un valor positivo. La navegación se produce desde el elemento con menor valor de tabindex hasta el elemento con el valor más alto. Los valores no necesitan ser secuenciales ni deben comenzar por un valor en particular. Si hay elementos que tengan valores idénticos de tabindex debería navegarse por ellos según el orden en que aparezcan en el flujo de caracteres.
2. A continuación se navega por aquellos elementos que no soporten el atributo tabindex o por los que soportándolo tengan asignado para él un valor "0". Se navega por estos elementos según el orden en que aparezcan en el flujo de caracteres.
3. Los elementos que estén deshabilitados no participan en el orden de tabulación.

Los siguientes elementos soportan el atributo tabindex: A, AREA, BUTTON, INPUT, OBJECT, SELECT y 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>Ir al 
<A tabindex="10" href="http://www.w3.org/">sitio web del W3C.</A>
...más texto...
<BUTTON type="button" name="obtener-base-de-datos"
           tabindex="1" onclick="obtener-base-de-datos">
Obtener la base de datos acutal.
</BUTTON>
...más texto...
<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 acceso

Al pulsar la tecla de acceso asignada a un elemento, el foco se dirige hacia el elemento. La acción que tiene lugar cuando el foco se dirige hacia un elemento depende del elemento. Por ejemplo, cuando un usuario activa un vínculo definido por el elemento A, el agente de usuario normalmente sigue el vínculo. Cuando un usuario activa un radiobotón, el agente de usuario cambia el valor del radiobotón. Cuando el usuario activa un campo de texto, éste permite la entrada de texto, etc.

Los siguientes elementos soportan el atributo accesskey: A, AREA, BUTTON, INPUT, LABEL, LEGEND y TEXTAREA.

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

<P><A accesskey="C" 
      rel="contents"
      href="http://algunsitio.com/especificacion/contenidos.html">
    Tabla de Contenidos</A>

La invocación de teclas de acceso depende del sistema subyacente. Por ejemplo, en máquinas que ejecuten MS Windows, normalmente hay que pulsar la tecla "alt" además de la tecla de acceso. En sistemas Apple, normalmente hay que pulsar la tecla "cmd" además de la tecla de acceso.

La representación de teclas de acceso depende del agente de usuario. Recomendamos a los autores que incluyan la tecla de acceso en el texto del rótulo o dondequiera que se aplique la tecla de acceso. Los agentes de usuario deberían representar las teclas de acceso de tal modo que se enfatice su papel y se distinga de otros caracteres (p.ej., subrayándola).

17.12 Controles deshabilitados y de sólo lectura

En aquellos contextos en los que la entrada de datos por parte del usuario sea indeseable o irrelevante, es importante poder deshabilitar un control o convertirlo en un control de sólo lectura. Por ejemplo, podríamos querer deshabilitar el botón de envío de un formulario mientras que el usuario no haya introducido ciertos datos obligatorios. Análogamente, un autor podría querer incluir una sección de texto de sólo lectura que debería ser enviada como un valor junto con el formulario. Las siguientes secciones describen los controles deshabilitados y de sólo lectura.

17.12.1 Controles deshabilitados

Cuando está establecido, el atributo disabled tiene los siguientes efectos sobre un elemento:

• No se puede dirigir el foco hacia controles deshabilitados.
• En el orden de tabulación, se salta por encima de los controles deshabilitados.
• Los controles deshabilitados no pueden tener éxito.

Los siguientes elementos soportan el atributo disabled: BUTTON, INPUT, OPTGROUP, OPTION, SELECT y TEXTAREA.

Este atributo se hereda, pero las declaraciones locales prevalecen sobre el valor heredado.

El modo en que se representan los elementos deshabilitados depende del agente de usuario. Por ejemplo, algunos agentes de usuario dibujan en gris los objetos de menú deshabilitados, los rótulos de los botones, etc.

<INPUT disabled name="pedro" value="piedra">

17.12.2 Controles de sólo lectura

El atributo readonly especifica si el control puede ser modificado por el usuario.

Cuando está establecido, el atributo readonly tiene los siguientes efectos sobre un elemento:

• El foco puede dirigirse hacia elementos de sólo lectura, pero éstos no pueden ser modificados por el usuario.
• Los elementos de sólo lectura están incluidos en la navegación con tabulador.
• Los elementos de sólo lectura pueden tener éxito.

Los siguientes elementos soportan el atributo readonly: INPUT y TEXTAREA.

El modo en que se representan los elementos de sólo lectura depende del agente de usuario.

17.13 Envío de formularios

Las siguientes secciones explican cómo envían los agentes de usuario los datos de los formularios a los agentes procesadores de formularios.

17.13.1 Método de envío del formulario

El atributo method del elemento FORM especifica el método HTTP usado para enviar el formulario al agente procesador. Este atributo puede tener dos valores:

• get: Con el método HTTP "get", el conjunto de datos del formulario se agrega al URI especificado por el atributo action (con un signo de interrogación ("?") como separador) y este nuevo URI se envía al agente procesador.
• post: Con el método HTTP "post", el conjunto de datos del formulario se incluye en el cuerpo del formulario y se envía al agente procesador.

El método "get" debería usarse cuando el formulario es idempotente (es decir, cuando no tiene efectos secundarios). Muchas búsquedas en bases de datos no tienen efectos secundarios visibles y constituyen aplicaciones ideales del método "get".

Si el servicio asociado con el procesamiento de un formulario causa efectos secundario (por ejemplo, si el formulario modifica una base de datos o la subscripción a un servicio), debería usarse el método "post".

17.13.2 Controles con éxito

Un control con éxito es "válido" para su envío. Todos los controles con éxito tienen su nombre de control emparejado con su valor actual como parte del conjunto de datos del formulario enviado. Un control con éxito debe estar definido dentro de un elemento FORM y debe tener un nombre de control.

Sin embargo:

• Los controles que están deshabilitados no pueden tener éxito.
• Si un formulario contiene más de un botón de envío, solamente el botón de envío activado tiene éxito.
• Todas las casillas de verificación (checkboxes) marcadas pueden tener éxito.
• Para los radiobotones (radio buttons) que compartan el mismo valor del atributo name, solamente el radiobotón marcado puede tener éxito.
• Para los menúes, el nombre de control viene dado por un elemento SELECT y los valores son proporcionados por elementos OPTION. Solamente las opciones seleccionadas pueden tener éxito. Cuando no haya opciones seleccionadas, el control no tiene éxito, y ni el nombre ni los valores se envían al servidor cuando se envía el formulario.
• El valor actual de un selector de ficheros es una lista de uno o más nombres de ficheros. Al enviar el formulario, los contenidos de cada fichero se envían con el resto de los datos del formulario. Los contenidos de los ficheros se empaquetan de acuerdo con el tipo de contenido del formulario.
• El valor actual de un control tipo objeto está determinado por la implementación del objeto.

Si un control no tiene valor actual cuando se envía el formulario, los agentes de usuario no están obligados a tratarlo como un control con éxito.

Además de esto, los agentes de usuario no deberían considerar a los siguientes como controles con éxito:

• Botones de reinicialización (reset buttons).
• Elementos OBJECT cuyo atributo declare haya sido establecido.

Los controles ocultos y los controles que no sean representados debido a la configuración de una hoja de estilo pueden tener éxito. Por ejemplo:

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

17.13.3 Procesamiento de los datos del formulario

Cuando el usuario envía un formulario (p.ej., activando un botón de envío), el agente de usuario lo procesa del siguiente modo.

Paso uno: Identificar los controles con éxito 

Paso dos: Construir el conjunto de datos del formulario 

Un conjunto de datos del formulario es una secuencia de parejas nombre de control/valor actual construida a partir de los elementos con éxito.

Paso tres: Codificar el conjunto de datos del formulario  

El conjunto de datos del formulario se codifica a continuación de acuerdo con el tipo de contenido especificado por el atributo enctype del elemento FORM.

Paso cuatro: Enviar el conjunto de datos del formulario codificado 

Finalmente, los datos codificados se envían al agente procesador designado por el atributo action usando el protocolo especificado por el atributo method.

Esta especificación no especifica todos los métodos válidos de envío ni los tipos de contenido que pueden utilizarse con los formularios. Sin embargo, los agentes de usuario HTML 4 deben soportar las convenciones establecidas en los siguientes casos:

• Si method es "get" y action es un URI HTTP, el agente de usuario toma el valor de action, le agrega un '?', y a continuación agrega el conjunto de datos del formulario, codificado según el tipo de contenido "application/x-www-form-urlencoded". A continuación el agente de usuario sigue este URI. En este escenario, los datos del formulario se restringen a códigos ASCII.
• Si method es "post" y action es un URI HTTP, el agente de usuario conduce una transacción HTTP "post" usando el valor del atributo action y un mensaje creado de acuerdo con el tipo de contenido especificado por el atributo enctype.

Para cualquier otro valor de action o method, el comportamiento queda sin especificar.

Los agentes de usuario deberían representar la respuesta de las transacciones HTTP "get" y "post".

17.13.4 Tipos de contenido de formularios

El atributo enctype del elemento FORM especifica el tipo de contenido usado para codificar el conjunto de datos del formulario para su envío al servidor. Los agentes de usuario deben soportar los tipos de contenido enumerados más adelante. El comportamiento para otros tipos de contenido queda sin especificar.

Consulte también la sección sobre transformación del signo & en secuencias de escape para valores de atributos URI.

application/x-www-form-urlencoded  

Este es el tipo de contenido por defecto. Los formularios enviados con este tipo de contenido deben codificarse como sigue:

1. Los nombres de control y los valores se transforman en secuencias de escape. Los caracteres de espacio se sustituyen por '+', y los caracteres reservados se transforman en secuencias de escape según se describe en [RFC1738], sección 2.2: Los caracteres no alfanuméricos se reemplazan por '%HH', un signo de porcentaje y dos dígitos hexadecimales que representan el código ASCII del carácter. Los saltos de línea se representan como parejas "CR LF" (es decir, '%0D%0A').
2. Las parejas nombre de control/valor se enumeran según el orden en que aparecen en el documento. El nombre se separa del valor con un signo '=' y las parejas nombre/valor se separan entre sí con un signo '&'.

multipart/form-data  

El tipo de contenido "application/x-www-form-urlencoded" no es eficiente para enviar grandes cantidades de datos binarios o textos que contenga caracteres no ASCII. Para enviar formularios que contengan ficheros, datos no ASCII, y datos binarios debería utilizarse el tipo de contenido "multipart/form-data".

El contenido "multipart/form-data" sigue las reglas de todos los flujos de datos MIME multiparte, como se esboza en [RFC2045]. La definición de "multipart/form-data" puede encontrarse en el registro [IANA].

Un mensaje "multipart/form-data" contiene una serie de partes, cada una de las cuales representa un control con éxito. Las partes se envían al agente procesador en el mismo orden en que aparecen los controles correspondientes en el flujo del documento. No deberían aparecer límites entre partes en ninguno de los datos; el modo en que se consigue esto queda fuera del alcance de esta especificación.

Como con todos los tipos MIME multiparte, cada parte tiene un encabezado opcional "Content-Type" cuyo valor por defecto es "text/plain". Los agentes de usuario deberían proveer el encabezado "Content-Type", acompañado por un parámetro "charset".

Se espera que cada parte contenga:

1. un encabezado "Content-Disposition" cuyo valor es "form-data".
2. un nombre de atributo que especifique el nombre de control del control correspondiente. Los nombres de control codificados originalmente con conjuntos de caracteres no ASCII pueden codificarse usando el método explicado en [RFC2045].

Así, por ejemplo, para un control llamado "micontrol", la parte correspondiente se especificaría así:

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

Como con todas las transmisiones MIME, se utiliza "CR LF" (es decir, '%0D%0A') para separar líneas de datos.

Se puede codificar cada parte, pudiéndose proporcionar el encabezado "Content-Transfer-Encoding" si el valor de esa parte no es conforme con la codificación por defecto (7BIT) (ver [RFC2045], sección 6)

Si se envían los contenidos de un fichero con un formulario, el fichero introducido debería identificarse con el tipo de contenido apropiado (p.ej., "application/octet-stream"). Si deben enviarse varios ficheros como resultado de la entrada de un solo formulario, deberían ser enviados como "multipart/mixed" incluidos dentro del "multipart/form-data".

El agente de usuario debería intentar proporcionar un nombre de fichero para cada fichero enviado. El nombre del fichero puede especificarse con el parámetro "filename" del encabezado 'Content-Disposition: form-data', o, en el caso de múltiples ficheros, en un encabezado 'Content-Disposition: attachment' de la subparte. Si el nombre del fichero del sistema operativo del cliente no está en US-ASCII, el nombre del fichero podría aproximarse o codificarse usando el método de [RFC2045]. Esto es conveniente, por ejemplo, en aquellos casos en que los ficheros subidos pudieran contener referencias cruzadas (p.ej., un fichero TeX y su descripción de estilo auxiliar ".sty").

El siguiente ejemplo ilustra la codificación "multipart/form-data". Supongamos que tenemos el siguiente formulario:

 <FORM action="http://servidor.com/cgi/procesar"
       enctype="multipart/form-data"
       method="post">
   <P>
   ¿Cómo se llama? <INPUT type="text" name="nombre-envio"><BR>
   ¿Qué ficheros va a enviar? <INPUT type="file" name="ficheros"><BR>
   <INPUT type="submit" value="Enviar"> <INPUT type="reset">
 </FORM>

Si el usuario introduce "Alfredo" en la entrada de texto, y selecciona el fichero de texto "fichero1.txt", el agente de usuario podría enviar los datos siguientes:

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

   --AaB03x
   Content-Disposition: form-data; name="nombre-envio"

   Alfredo
   --AaB03x
   Content-Disposition: form-data; name="ficheros"; filename="fichero1.txt"
   Content-Type: text/plain

   ... contenidos de fichero1.txt ...
   --AaB03x--

Si el usuario eligió un segundo fichero (una imagen) "fichero2.gif", el agente de usuario podría construir las partes de este modo:

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

   --AaB03x
   Content-Disposition: form-data; name="nombre-envio"

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

   --BbC04y
   Content-Disposition: attachment; filename="fichero1.txt"
   Content-Type: text/plain

   ... contenidos de fichero1.txt ...
   --BbC04y
   Content-Disposition: attachment; filename="fichero2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contenidos de fichero2.gif...
   --BbC04y--
   --AaB03x--