17 Formularios

Nota: Este documento es parte de una traducción al castellano de la Recomendación del W3C "HTML 4.01 Specification" (más información). Puede consultar la versión original del mismo. Para cualquier comentario o corrección acerca de la traducción póngase en contacto con el traductor en jrpozo@conclase.net. Gracias por su colaboración.

Véase el Aviso de copyright de la traducción.

Contenidos

  1. Introducción a los formularios
  2. Controles
    1. Tipos de controles
  3. El elemento FORM
  4. El elemento INPUT
    1. Tipos de controles creados con INPUT
    2. Ejemplos de formularios con controles INPUT
  5. El elemento BUTTON
  6. Los elementos SELECT, OPTGROUP y OPTION
    1. Opciones preseleccionadas
  7. El elemento TEXTAREA
  8. El elemento ISINDEX
  9. Rótulos
    1. El elemento LABEL
  10. Añadir estructura a los formularios: los elementos FIELDSET y LEGEND
  11. Dirigir el foco hacia un elemento
    1. Navegación con tabulador
    2. Teclas de acceso
  12. Controles deshabilitados y de sólo lectura
    1. Controles deshabilitados
    2. Controles de sólo lectura
  13. Envío de formularios
    1. Método de envío del formulario
    2. Controles con éxito
    3. Procesamiento de los datos del formulario
    4. Tipos de contenido de 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.)

Aquí se muestra un ejemplo de un formulario simple que incluye rótulos, radiobotones y botones para reinicializar el formulario o para enviarlo:

 <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>

Nota. Esta especificación incluye información más detallada sobre formularios en las subsecciones sobre representación de formularios.

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:

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

Definiciones de atributos

action = uri [CT]
Este atributo especifica un agente procesador de formularios. El comportamiento del agente de usuario frente a un valor diferente de un URI HTTP es indefinido.
method = get|post [CI]
Este atributo especifica qué método HTTP se usará para enviar el conjunto de datos del formulario. Los valores posibles (que no distinguen entre mayúsculas y minúsculas) son "get" (valor por defecto) y "post". Véase la sección sobre envío de formularios para información sobre su uso.
enctype = tipo de contenido [CI]
Este atributo especifica el tipo de contenido usado para enviar el formulario al servidor (cuando el valor del atributo method sea "post"). El valor por defecto de este atributo es "application/x-www-form-urlencoded". El valor "multipart/form-data" debería usarse en combinación con el elemento INPUT, type="file".
accept-charset = lista de codificaciones de caracteres [CI]
Este atributo especifica la lista de codificaciones de caracteres para los datos introducidos que son aceptadas por el servidor que procesa este formulario. El valor es una lista de valores de codificaciones de caracteres separadas por espacios y/o comas. El cliente debe interpretar esta lista como una lista o-exclusiva, es decir, el servidor es capaz de aceptar cualquier codificación de caracteres individual por entidad recibida.

El valor por defecto de este atributo es la cadena reservada "UNKNOWN" ("desconocido"). Los agentes de usuario pueden interpretar este valor como la codificación de caracteres que fue usada para transmitir el documento que contiene este elemento FORM.

accept = lista de tipos de contenido [CI]
Este atributo especifica una lista de tipos de contenido separados por comas que un servidor procesador de formularios manejará correctamente. Los agentes de usuario pueden utilizar esta información para filtrar ficheros no conformes cuando pidan al usuario seleccionar ficheros para enviar al servidor (véase el elemento INPUT cuando type="file").
name = cdata [CI]
Este atributo da nombre al elemento de modo que se pueda hacer referencia a él desde hojas de estilo o scripts. Nota. Este atributo ha sido incluido por motivos de compatibilidad con versiones anteriores. Las aplicaciones deberían usar el atributo id para identificar elementos.

Atributos definidos en otros lugares

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

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

El siguiente ejemplo muestra un formulario que va a ser procesado por el programa "usuarionuevo" cuando sea enviado. El formulario será enviado al programa usando el método HTTP "post".

 <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.

Nota. Quedan fuera del alcance de esta especificación las cuestiones sobre el comportamiento de los servidores que reciben datos de formularios.

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

Definiciones de atributos

type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI]
Este atributo especifica el tipo de control a crear. El valor por defecto para este atributo es "text".
name = cdata [CI]
Este atributo asigna el nombre de control.
value = cdata [CA]
Este atributo especifica el valor inicial del control. Es opcional excepto cuando el atributo type tenga el valor "radio" o "checkbox".
size = cdata [CN]
Este atributo le dice al agente de usuario la anchura inicial del control. La anchura viene dada en píxeles excepto cuando el atributo type tenga el valor "text" o "password". En estos casos, el valor se refiere al número (entero) de caracteres.
maxlength = number [CN]
Cuando el atributo type tiene el valor "text" o "password", este atributo especifica el número máximo de caracteres que puede introducir el usuario. Este número puede exceder del especificado por size, en cuyo caso el agente de usuario debería ofrecer un mecanismo de desplazamiento. El valor por defecto para este atributo es un número ilimitado.
checked [CI]
Cuando el atributo type tiene el valor "radio" o "checkbox", este atributo booleano especifica que el botón está marcado ("on"). Los agentes de usuario no deben tener en cuenta este atributo para otros tipos de control.
src = uri [CT]
Cuando el atributo type tiene el valor "image", este atributo especifica la localización de la imagen que debe usarse para decorar el botón gráfico de envío.

Atributos definidos en otros lugares

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:

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

El siguiente fragmento HTML de ejemplo define un formulario simple que permite al usuario introducir su nombre, apellido, dirección de correo electrónico y sexo. Cuando se active el botón de envío, el formulario será enviado al programa especificado por el atributo action.

 <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>

Este formulario podría ser representado de la siguiente manera:

Ejemplo de representación de un formulario.

En la sección sobre el elemento LABEL, se habla sobre la codificación de rótulos tales como "Nombre".

En el ejemplo que sigue, se ejecuta la función Javascript llamada verificar cuando se da el evento "onclick":

<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>

Consulte la sección sobre eventos intrínsecos para más información sobre scripts y eventos.

El siguiente ejemplo muestra cómo pueden enviarse los contenidos de un fichero especificado por el usuario con un formulario. Se le pide al usuario su nombre y una lista de nombres de ficheros cuyos contenidos deberían enviarse con el formulario. Al especificar para enctype el valor "multipart/form-data", los contenidos de cada fichero se empaquetarán para su envío en una sección separada de un documento multiparte.

<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

Definiciones de atributos

name = cdata [CI]
Este atributo asigna el nombre de control.
value = cdata [CS]
Este atributo asigna al botón su valor inicial.
type = submit|button|reset [CI]
Este atributo declara el tipo del botón. Valores posibles:

Atributos definidos en otros lugares

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".

El siguiente ejemplo extiende un ejemplo previo, pero creando los botones de envío y de reinicialización con BUTTON en lugar de con INPUT. Los botones contienen imágenes sacadas de elementos IMG.

 <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.

EJEMPLO ILEGAL:
Lo siguiente no es HTML legal.

<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

Definiciones de atributos de SELECT

name = cdata [CI]
Este atributo asigna el nombre de control.
size = número [CN]
Si un elemento SELECT se presenta como una lista con desplazamiento ("scrolled list box"), este atributo especifica el número de filas de la lista que deberían ser visibles al mismo tiempo. No es preciso que los agentes visuales presenten un elemento SELECT como una lista ("list box"); pueden usar cualquier otro mecanismo, como por ejemplo un menú desplegable ("drop-down menu").
multiple [CI]
Si está activado, este atributo booleano permite selecciones múltiples. Si no está activado, el elemento SELECT sólo permite selecciones simples.

Atributos definidos en otros lugares

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:

<!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

Definiciones de atributos de OPTGROUP

label = texto [CS]
Este atributo especifica el rótulo del grupo de opciones.

Atributos definidos en otros lugares

Nota. Se avisa a los implementadores de que las versiones futuras de HTML pueden extender el mecanismo de agrupamiento para permitir grupos anidados (es decir, para que los elementos OPTGROUP puedan anidarse). Esto permitirá a los autores representar una jerarquía de opciones más rica.

<!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

Definiciones de atributos de OPTION

selected [CI]
Si está establecido, este atributo booleano especifica que esta opción está preseleccionada.
value = cdata [CS]
Este atributo especifica el valor inicial del control. Si este atributo no está establecido, el valor inicial es igual a los contenidos del elemento OPTION.
label = texto [CS]
Este atributo permite a los autores especificar un rótulo para la opción más corto que el contenido del elemento OPTION. Cuando esté especificado, los agentes de usuario deberían usar como rótulo de la opción el valor de este atributo en lugar del contenido del elemento OPTION.

Atributos definidos en otros lugares

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.

En este ejemplo, creamos un menú que permite al usuario seleccionar cuál de los siete componentes de un programa instalar. Los dos primeros componentes están preseleccionados pero pueden ser deseleccionados por el usuario. El resto de los componentes no están preseleccionados. El atributo size dice que el menú sólo debería tener cuatro filas, aunque el usuario pueda elegir ente siete opciones. Las otras opciones deberían estar disponibles a través de un mecanismo de desplazamiento.

El elemento SELECT va seguido de botones de envío y de reinicialización.

<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>

Solamente las opciones seleccionadas tendrán éxito (usando el nombre de control "elegir-componente"). Cuando no haya opciones seleccionadas, el control no tendrá éxito, y ni el nombre ni ninguno de los valores se enviarán al servidor cuando se envíe el formulario. Obsérvese que el atributo value, cuando está establecido, determina el valor inicial del control, que de otro modo es el contenido del elemento.

En este ejemplo usamos el elemento OPTGROUP para agrupar opciones. El siguiente código:

<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>

representa el siguiente agrupamiento:

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

Los agentes de usuario visuales pueden permitir a los usuarios seleccionar de entre grupos de opciones a través de un menú jerárquico o de algún otro mecanismo que refleje la estructura de las opciones.

Un agente de usuario gráfico podría representarlo así::

Una posible representación de OPTGROUP

Esta imagen muestra un elemento SELECT representado mediante menúes en cascada. El rótulo superior del menú muestra el valor seleccionado actualmente (PortMaster 3, 3.7.1). El usuario ha desplegado dos menúes en cascada, pero aún no ha seleccionado el nuevo valor (PortMaster 2, 3.7). Obsérvese que cada menú en cascada muestra el rótulo de un elemento OPTGROUP u OPTION.

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

Definiciones de atributos

name = cdata [CI]
Este atributo asigna el nombre de control.
rows = número [CN]
Este atributo especifica el número de líneas de texto visibles. Los usuarios deberían poder introducir un número mayor de líneas, por lo que los agentes de usuario deberían proporcionar medios para desplazar los contenidos del control cuando los contenidos se extiendan más allá del área visible.
cols = número [CN]
Este atributo especifica la anchura visible en caracteres de anchura media. Los usuarios deberían poder introducir líneas de mayor longitud, por lo que los agentes de usuario deberían proporcionar medios para desplazar los contenidos del control cuando los contenidos se extiendan más allá del área visible. Los agentes del usuario pueden partir las líneas de texto visible para que las líneas largas puedan verse sin necesidad de desplazarlas.

Atributos definidos en otros lugares

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.

Este ejemplo crea un control TEXTAREA de 20 filas por 80 columnas que contiene inicialmente dos líneas de texto. El elemento TEXTAREA va seguido de botones de envío y reinicialización.

<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>

Estableciendo el atributo readonly los autores pueden mostrar texto no modificable en un elemento TEXTAREA. Esto no es lo mismo que usar código de texto estándar, ya que el valor del TEXTAREA se envía con el formulario.

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.

Definiciones de atributos

prompt = texto [CS]
Desaprobado. Este atributo especifica una cadena indicadora ("prompt") para el campo de entrada.

Atributos definidos en otros lugares

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").

EJEMPLO DESAPROBADO:
La siguiente declaración ISINDEX:

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

podría reescribirse con INPUT del siguiente modo:

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

Semántica de ISINDEX. Actualmente, la semántica de ISINDEX sólo está bien definida cuando el URI base del documento que lo contiene es un URI HTTP. En la práctica, la cadena introducida está restringida a Latin-1 ya que no hay ningún mecanismo con el que el URI pueda especificar un juego de caracteres diferente.

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

Definiciones de atributos

for = idref [CS]
Este atributo asocia explícitamente el rótulo definido con otro control. Cuando está presente, el valor de este atributo debe ser el mismo que el valor del atributo id de algún otro control del mismo documento. Cuando no está presente, el rótulo definido se asocia con los contenidos del elemento.

Atributos definidos en otros lugares

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.

Este ejemplo crea una tabla que se utiliza para alinear dos controles de entrada de texto y sus rótulos asociados. Cada rótulo está explícitamente asociado a un control de entrada de texto:

<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>

Este ejemplo extiende el formulario de un ejemplo previo haciendo que incluya elementos LABEL.

 <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.

En este ejemplo, asociamos implícitamente dos rótulos a dos controles de entrada de texto:

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

Obsérvese que esta técnica no puede utilizarse cuando se usa una tabla para fijar la disposición de los elementos, con el rótulo en una celda y su control asociado en otra celda.

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

Definiciones de atributos de LEGEND

align = top|bottom|left|right [CI]
Desaprobado. Este atributo especifica la posición de la leyenda con respecto al grupo de campos (fieldset). Valores posibles:
  • top: La leyenda está en la parte superior del grupo de campos. Este es el valor por defecto.
  • bottom: La leyenda está en la parte inferior del grupo de campos.
  • left: La leyenda está a la izquierda del grupo de campos.
  • right: La leyenda está a la derecha del grupo de campos.

Atributos definidos en otros lugares

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.

En este ejemplo, creamos un formulario que podría rellenarse en una consulta médica. Se divide en tres secciones: información personal, historial médico, y medicación actual. Cada sección contiene controles para introducir la información apropiada.

<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>

Obsérvese que en este ejemplo podríamos mejorar la presentación visual del formulario alineando los elementos dentro de cada FIELDSET (con hojas de estilo), añadiendo información de fuentes y colores (con hojas de estilo), añadiendo scripts (por ejemplo, para abrir el área de texto de "medicación actual" sólo si el usuario indica que actualmente está tomando medicación), etc.

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:

17.11.1 Navegación con tabulador

Definiciones de atributos

tabindex = número [CN]
Este atributo especifica la posición del elemento actual dentro del orden de tabulación del documento actual. Este valor debe ser un número entre 0 y 32767. Los agentes de usuario no deberían tener en cuenta los ceros a la izquierda.

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.

En este ejemplo, el orden de tabulación será el BUTTON, los elementos INPUT en orden (obsérvese que "campo1" y el botón comparten el mismo tabindex, pero "campo1" aparece después en el flujo de caracteres), y por último el vínculo creado por el elemento A.

<!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>

Teclas de tabulación. La secuencia real de teclas que permiten la navegación con tabulador o la activación de los elementos depende de la configuración del agente de usuario (p.ej., la tecla "tab" se usa para la navegación y la tecla "intro" se usa para activar el elemento seleccionado).

Los agentes de usuario pueden también definir secuencias de teclas para navegar en orden inverso al de tabulación. Cuando se alcanza el final (o el principio) del orden de tabulación, los agentes de usuario puede volver al principio (o al final).

17.11.2 Teclas de acceso

Definiciones de atributos

accesskey = carácter [CN]
Este atributo asigna una tecla de acceso a un elemento. Una tecla de acceso es un carácter único del conjunto de caracteres del documento. Nota. Los autores deberían considerar la forma que tienen los usuarios potenciales de interaccionar a la hora de especificar la tecla 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.

Este ejemplo asigna la tecla de acceso "U" a un rótulo asociado con un control INPUT. Al pulsar la tecla de acceso, el foco se dirige hacia el rótulo, el cual a su vez lo dirige al control asociado. El usuario puede entonces introducir texto en el área INPUT.

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

En este ejemplo, asignamos una tecla de acceso a un vínculo definido por el elemento A. Al pulsar esta tecla de acceso, el usuario es llevado a otro documento, en este caso una tabla de contenidos.

<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

Definiciones de atributos

disabled [CI]
Cuando se establece para un control de formulario, este atributo booleano deshabilita el control para la entrada de datos por parte del usuario.

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

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.

En este ejemplo, el elemento INPUT está deshabilitado. Por tanto, no puede recibir datos del usuario, y su valor no se enviará con el formulario.

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

Nota. El único modo de modificar dinámicamente el valor del atributo disabled es por medio de un script.

17.12.2 Controles de sólo lectura

Definiciones de atributos

readonly [CI]
Cuando está establecido para un control de formulario, este atributo booleano impide que haya cambios en el control.

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:

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.

Nota. La única manera de modificar dinámicamente el valor del atributo readonly es mediante un script.

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:

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".

Nota. El método "get" restringe los valores del conjunto de datos del formulario a caracteres ASCII. Sólo el método "post" (con enctype="multipart/form-data") cubre el conjunto de caracteres [ISO10646] completo.

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:

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:

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>

En este ejemplo, seguirá habiendo un valor emparejado con el nombre "password-invisible" que será enviado con el formulario.

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:

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  

Nota. Consulte [RFC2388] para información adicional sobre carga de ficheros, incluyendo cuestiones de compatibilidad con versiones anteriores, la relación entre "multipart/form-data" y otros tipos de contenido, cuestiones de rendimiento, etc.

Consulte el apéndice para información sobre cuestiones de seguridad relacionadas con los formularios.

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--