Formularios Web

Bueno, esto es un artículo relacionado con los formularios, los formularios webs, hechos con HTML o XHTML, vamos a desglosar cada parte de los elementos que lo componen.

Nota sobre el artículo:

Este es un artículo, escrito con un fin comunicativo y didáctico para ayudar a aquellos que lo requieran sin pagar un centavo, y es sólo una opinión personal, cualquier coincidencia de código, ejemplos que se asemejen con terceros es pura coincidencia y está fuera de mi alcance.

Toda la información que se maneja en todos los artículos de minid.net son de carácter público y abierto a todo aquel que desea informarse, cualquier duda o consulta puedes enviar un mensaje utilizando el formulario de contacto.

¿Qué requisitos debo tener para comprender este artículo?

Dado que este curso toca muchos temas relacionados al código XHTML, recomiendo que dejes Frontpage, Dreamweaver, y coge un editor de texto como EditPad Lite o UltraEdit, también requiere de cierta compresión de código XHTML y jerga web.

¿En qué mejoramos haciendo los formularios web?

En general cuando uno hace los formularios de forma correcta se está asegurando que el usuario menos experto pueda llenar un formulario sin tener que hacerse preguntas así mismo y quedándose tranquilo de que todo ha marchado viento en popa.

Una regla de oro para los desarrolladores sobre el uso de Javascript con los formularios es que Javascript puede ser una herramienta perfecta para comprobar que se cumplan ciertas reglas de llenado de datos en un formulario, pero… debéis ir con cuidado, no todo el mundo tiene la versión exacta del navegador, y debéis contemplar la opción de que en caso de no haber javascript que el formulario pueda ser procesado de todas formas, esto para los que no entiendan mi castellano, significa que me refiero al uso de Javascript como algo práctico para no sobrecargar un servidor con comprobaciones (algo realmente insignificante) y poder hacer el primer filtro de información.

Otro factor importante para las personas que se inician en esto es que, siempre el 100% de los casos la comprobación de los datos cuando se realizan dentro del servidor tienen más ventajas que las que se realizan del lado del cliente, para demostrarles esto:

El usuario Diego llena un formulario de 10 campos, el cual un número de promoción, en el servidor hay una base de datos de todos los números de promoción de la empresa, si el formulario llena mal ese campo, se le puede devolver una página que contiene solamente ese campo “número de promoción” y una explicación muy amigable comentandole que un error existió a la hora de escribir el formulario.

Otra regla de oro en lo que refiere la utilización de Javascript en los formularios es que por nada del mundo, debe impedir Javascript la utilización del mismo, me refiero a que, si Javascript es motivo de uso del formulario, sin éste el formulario nunca procesara, entonces entramos en un problema de accesibilidad, considerar esto como una traba a mucha gente que quiere utilizar el formulario y no tiene el navegador correcto o el ordenador en las mismas condiciones que los desarrolladores.

Es solo una humilde sugerencia, no una obligación.

Adam Kalsey autor de Simplified Form Errors, escribió un artículo interesante explicando cómo mejorar la usabilidad en a la hora de mostrar errores en los formularios, con código de ejemplo y todo… imperdible.

Sobre los formularios web

Los elementos de un formulario XHTML le dan significado a la colección de datos que se recogen de un sitio web. Todos los datos que se ingresen en un formulario serán enviados y procesados por un programa alojado en el servidor
Los formularios son elementos de bloque que están delimitados por las etiquetas <form> y </form>. Dentro de los formularios se alojan una variedad de elementos en línea, llamados controles.

Los controles son mecanismos individuales de interface por el cual los datos son recogidos, y consisten en campos de ingreso de texto (text entry fields), cajas de verificación (checkboxes), botones de radio (radio buttons), menús (menus), selectores de archivos (file selectors), y botones (buttons).

Cada control en un formulario se le da un nombre utilizando el atributo name="nombre". El nombre de un control actúa como una variable, el valor (value) value="…" que se ingrese será enviado y procesador por alguna aplicación de servidor. Todos los controles se definen como “tipo”, de esta forma podemos diferenciar los tipos de controles uno de otros.
Comencemos con un ejemplo sumamente básico:

<input type="text" name="provincia" value="" />

Asumiendo que un usuario ingresara un dato en este control, por ejemplo la provincia “Coruña” la variable “provincia” tendrá como valor (value) “Coruña”. Si ambos son recibidos, juntos con todos los nombres de controles restantes y sus valores forman lo que se conoce por un set de datos del formulario (form’s data set).

Cuando un usuario envía el formulario, el set de datos es re-codificado y enviado a alguna aplicación de servidor para ser procesado.

El elemento <form>

Los formularios en XHTML se especifican con el elemento <form> sin este elemento el formulario no procesa de forma correcta. Hay tres elementos fundamentables en el elemento <form>:

  1. El atributo action es requerido para que el formulario envíe los datos a la dirección web de la aplicación web que procese el set de datos del formulario.
  2. El atributo meted determina que método http será utilizado para enviar los hacia la aplicación de servidor que procesará el set de datos. Hay dos posibles valores para usar:

    • “get” por defecto
    • “post”
  3. El atributo enctype especifica como el set de datos será re-codificado para el envío.

<form action= "www.dominio.com/cgi-bin/form.cgi" method="post"
enctype=”application/x-www-form-urlencoded”>
<br />
<!– elementos de bloque conteniendo controles en linea –>
<br />
</form>

El elemento <form> es un elemento de bloque como había explicado, el cual no solamente puede contener controles, sino también puede contener otros elementos de XHTML.

De todas formas, solamente elementos de bloque pueden ser un elemento hijo del elemento <form>, donde todos los controles (que son elementos en línea) deben ir insertados dentro de algún elemento en bloque intermediario como por ejemplo (<fieldset>, <table>, <div>, etc.).

El elemento fieldset

Elemento <fieldset> es un elemento de bloque, que sirve para agrupar controles de un formulario, la etiqueta <fieldset> requiere de otra etiqueta necesaria para su correcto funcionamiento y es la etiqueta <legend>.

Ejemplo:

<fieldset title="Datos personales del usuario"><br />
<legend>Datos personales</legend><br />… Aqu&iacute; va una tabla con los controles del formulario…<br /></fielset>

Por ejemplo cuando existen 20 controles es bueno tener la oportunidad de separarlos o diferenciar un grupo de controles de otros.

Agregando el atributo title="…" estamos asegurando una ayuda extra a la hora de reconocer ese <fieldset>, en muchas formas, una es para los lectores de pantalla y las otras son en el caso más común cuando el puntero del ratón está posado sobre el área del <fieldset>.

Como recomendación de usabilidad extra y una total accesibilidad para quien está llenando el formulario haciendo uso del teclado es ponerle un atributo accesskey="…" el cual hace que una persona pueda saltar de un fieldset a otro.

El elemento legend

Es el complemento ideal y necesario para que aparezca la leyenda en el <fieldset>, va ubicado como en el ejemplo anterior, dentro del <fieldset>.

El elemento input

El elemento <input> es un elemento en línea, también conocido como control, sirve para definir controles que aceptarán el ingreso de datos en un formulario, para ver un ejemplo de un input, mostraremos todos los <input> posibles en un formulario:

type="text"
type="password"
type="hidden"
type="image"


type="checkbox"


type="radio"
type="file"
type="button"
type="submit"
type="reset"

Para ver un ejemplo verifica el código fuente de esta página.

Mientras más atributos especifiques a un input más posibilidades de que un formulario sea llenado de forma más fácil. Uno de los atributos más importantes es el tabindex.

Tabindex es la forma en que el cursor de escritura recorrerá un formulario, moviendo el foco, aunque muchas veces no hace falta por que el curso natural es de arriba hacia abajo y de izquierda a derecha, pueden existir casos que deba ir primero de izquierda a derecha y luego hacia abajo.

Para poder entender esta funcionalidad, haced esto, pongan 3 campos de texto en un formulario, a cada input deben ponerle un tabindex="numero", por ejemplo:

Ejemplo:

<input id="Provincia" tabindex="1" /><br /><input id="N&uacute;mero" tabindex="3" /><br /><input id="Ciudad" tabindex="2" />

Luego presionando la tecla Tab podrán observar como el foco o el cursor se sigue el orden de campos que has indicado.

Esto nos permite de cierta forma llenar formularios de una forma más didáctica.

Cada elemento input tiene que tener un identificador un id="…" así aparecen nuevas funcionalidades, que son aprovechadas por las etiquetas “label”.

Las etiquetas label

Uno se pregunta, para qué funciona esta etiqueta en un formulario. Muchas veces, seleccionar un campo para empezar a escribir, basta con hacer clic en el campo, pero si asignamos etiquetas con un nombre descriptivo a cada campo es otro pequeño granito de arena que agregamos al formulario.

Lo hacemos de una forma fácil, por ejemplo, vamos a hacer una etiqueta “Provincia” para el campo “Provincia” esto hará que cuando alguien realice un clic el foco cambie directamente hacia el mismo campo.

Ejemplo:

<td><label for="direccionweb">Direcci&oacute;n Web:</label></td><br />
<td><input maxlength=”30″ value=”" type=”text” id=”direccionweb” name=”url” title=”URL de la p&aacute;gina” lang=”es” /></td>

Esto sin dudas mejora la forma en que actuan los formularios, si tienes un sitio web que aprovecha mucho los formularios web, sin dudas debes aplicar estas pocas reglas sobre los mismos.

Las etiquetas group

El elemento <select> es un control de formulario, sirve para listar opciones de datos <options> y también <optgroup>.

<optgroup>

El elemento <optgroup> es un elemento que permite a los autores agrupar opciones <option>
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. Este elemento va anidado dentro del elemento <select> y dentro del mismo van elementos <option>. Etiqueta inicial: obligatoria, Etiqueta final: obligatoria.

Ejemplo:

…<br /><select name="comos"><br />

&nbsp;&nbsp;&nbsp;&nbsp;<option selected label=”ninguno” value=”ninguno”>ninguno</option><br />
&nbsp;&nbsp;&nbsp;&nbsp;<optgroup label=”portmaster 3″><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<option label=”3.7.1″ value=”pm3_3.7.1″>portmaster 3 con comos 3.7.1</option><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<option label=”3.7″ value=”pm3_3.7″>portmaster 3 con comos 3.7</option><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<option label=”3.5″ value=”pm3_3.5″>portmaster 3 con comos 3.5</option><br />

&nbsp;&nbsp;&nbsp;&nbsp;</optgroup><br />…

Recuerda algo importante: No es bueno para la lectura sintetizada, o la comprensión natural de estos componentes no es bueno utilizar caracteres raros para trazar líneas y separar grupos de datos, hacerlo con los elementos que HTML les da si es correcto, más fácil, menos problemas.

No hagáis estas cosas por favor:

<option>Cosmo</option><br /><option label="----">==============</option><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<option label=”3.5″ value=”pm3_3.5″>portmaster 3 con comos 3.5</option>

<option>

El elemento <option> es un control, cada opción ofrecida por el menú <select> se representa por un elemento <option>. Un elemento <select> debe contener al menos un elemento <option>. Etiqueta inicial: obligatoria, Etiqueta final: obligatoria.

Espero que esta pequeña lección de simple HTML te aclare dudas sobre el funcionamiento de los formularios. Continua agregando dudas, consultas y sugerencias utilizando los comentarios, cualquier error en el artículo, puedes enviar la corrección o la sugerencias utilizando el formulario de contacto.

20 Respuestas a la entrada “Formularios Web”

Muy buena exposición. Enhorabuena :)

Como me daría mucha rabia no añadir algo (aunque lo has puesto dificil ;) señalar que el elemento [label] permite dos sintaxis alternativas. La primera es la que has mostrado, con el atributo for y la id del elemento referenciado y la segunda es anidando dentro del [label] el elemento, de esta forma:

[label]Nombre:[input type="text" /][/label]

Sip, genial ambos ejemplos son correctos y usables.

Muy weno. Lo de la etiqueta optgroup no la conocía, gracias por la info. Y me viene de perlas

Por mi experiencia, he descartado validar formularios en el cliente con JS y siempre lo hago en el servidor. Tiene la pega de hacer trabajar un poco más al servidor y como ventajas que “siempre” funciona (aunque te conectes con Lynx) y que la validación no se la salta nadie desactivando el JS de su navegador.
Además, usando este sistema es sencillo indicar dónde se han cometido los errores cambiando el fondo de la fila, poniendo [*] o lo que se le ocurra al diseñador.
Sobre la etiqueta label, es mi preferida, especialmente cuando se tienen que seleccionar opciones en un radio button y todos estamos acostumbrados a pulsar sobre el texto y no sobre el círculo.

Yo también estaba en contra del uso de JS(JavaScript), pero no solamente existe la @funcion alert();@ para avisar que falta algún campo por completar.

Lo digo por:

bq. [...] Además, usando este sistema es sencillo indicar dónde se han cometido los errores cambiando el fondo de la fila, poniendo [*] o lo que se le ocurra al diseñador. [...]

Ya que *SI* que se puede hacer, identificando etiquetas como <td> ó <span> con una id y usando:

@id.innerText = “texto”;@

O si queremos que ese texto sea interpretado como HTML, entonces:

@id.innerHTML = “<strong>texto</strong>”;.@

y lo de cambiar el color de fondo…

@id.style.backgroundColor = “#ffffff”;@

Yo creo que eso ya depende de cada uno, y, aunque ya se que comprobar en el servidor es mas seguro, hay que difenrenciar cual/es y/o que fallo/s pertenece/n a uno u otro lado, no?

Por otro lado, decir que el artículo esta genial, y muy _instructivo_, como todos los demas. un saludo.

Escrito por Anónimo
Marzo 26th, 2004 at 9:44 pm

ougp4ikho4khjo7kp4lj74254

Escrito por marcel
Abril 25th, 2004 at 8:44 pm

jdslkfj

Muy bueno este artículo. Varias etiquetas como label y optiongroup no las conocía. Asi que vino como anillo al dedo.

Vengo aprendiendo esto de XHTML y modelar páginas de acuerdo a este estandar. Es complicado abandonar el viejo modelo, que tanto costó aprender a prueba y error.

Pero bueno, de a poco, con un buen editor (HTMLkit) probando y probando se va aprendiendo cosas múy útiles. Ni hablar cuándo uno cuenta con sitios como este llenos de artículos espectaculares.

Saludos

Pablo

Escrito por addad dadad
Noviembre 29th, 2004 at 7:49 pm

Ahhhhhhhhhhh si

Escrito por Jose Lomeli
Diciembre 8th, 2004 at 6:50 pm

Hola tengo una pregunta, es acerca de

Lo que pasa es que tengo lo anterior pero lo que deseo es que cuando elija un archivo jpg me lo miestre en un de manera automatica al seleccionarlo, y he estado buscandole y no puedo hacerlo talves no es la manera adecuada la que estoy utilizando, podrian ayudarme por favor…

No está mal el articulo!.

Pero un par de aclaraciones:
En xhtml es obligatorio, dentro de etiquetas “option”, poner el atributo selected con su valor. Es decir selected=”selected”.
Y lo mismo pasa con todos los atributos de todas las etiquetas; todos tienen que tener valor.

Respecto a JS si o no, yo soy partidario de que en el cliente se realicen casi el 100% de las comprobaciones ya que con ello estamos liberando al servidor de tener que procesar cada página comprobando tal o pascual cosa.

Gracias a que vamos avanzando en nuevas tecnologías, los programadores contamos con herramientas que nos dan mucho más control sobre lo que queremos hacer y como. Así que ¿por qué demonios seguir utilizando navegadores de sólo texto?. No lo entiendo… es un atraso.

Agregando el atributo title=”…” estamos asegurando una ayuda extra a la hora de reconocer ese

, en muchas formas, una es para los lectores de pantalla y las otras son en el caso más común cuando el puntero del ratón está posado sobre el área del
.

Tengo una duda respecto a ello: ¿es realmente necesario el atributo “title” dentro de la etiqueta “fieldset”? ¿Los lectores de pantalla ignoran la etiqueta “legend”? Si no es así (y efectivamente el lector lée lo que hay entre en este caso sobrara, a menos que mediante el se diera otro tipo de información, ¿no?

Otra dudad: la especificación de XHTML 1.1 no dice nada sobre “name” o “id” en los formularios. Entonces, ¿se reemplaza “name” por “id” en formularios, o es esta la ecepción?

Gracias de ante mano.

esta ueno el hilo

Eleniel,

En XHTML 1.1 el name es reemplazado en favor del ID, o sea que no hace falta escribir name=”..” y id=”…”. Eso es útil nada más cuando usas otro DTD como por ejemplo, frame o transitional.

Escrito por giuseppe
Enero 15th, 2005 at 6:04 am

fnadklfnmsdkaldmaskl

Por fin me he enterad de como se hace un formulario gracias.

Hay un nuevo servicio gratuito para crear formularios web de manera sencilla que les podría interesar en phantomezform.com

Escrito por laura
Abril 11th, 2006 at 4:24 am

Hola! Necesito ayuda! Al fin funciona mi formulario! pero tgo un PROBLEMA, en los campos obligatorios necesito que cdo oel usuario no los complete me salga el mensaje, por favor llenar nombre por ejemplo, en cambio lo que me sucede a mi es que me sale esta leyenda……………the following error ocurred: Name is required…….
Y la idea es que salga en español.
Les re agradezco si pueden ayudarme porque estoy atrasadisima con este laburo q ya deberia hcer entregado.
Gracias!!

[...] Cada input debe tener un id, pero además podemos agrupar mediante classes para modificar mas fácilmente los estilos de las cajas. Minid.net - Formularios Web Intenta - Agrupar campos con CSS Armonía - Formularios y mensajes de error « Anterior: [Meme] Estadístico [...]