lunes 27 de agosto de 2007

Formularios web (II): Agrupación de los campos con HTML

En el primer artículo de esta serie, vimos como se codificaba cada uno de los elementos del formulario de contacto en HTML. Aun siendo totalmente funcional el formulario resultante, no es muy usable porque todos los elementos están apelotonados, sin orden ni sentido. Hay que dotar de estructura y semántica al conjunto y para ello veremos varias opciones de distribución y agrupación.

Distribución libre

La primera forma de ordenar los elementos del formulario podría ser esta: form_free_layout_unstyled.html

Simplemente ponemos un retorno de carro después de cada campo y listo. Como primera aproximación, no está mal pero no es la más acertada. De hecho, recuerda mucho a como construyen algunos usuarios de un conocido procesador de textos los saltos de página: a base de retornos de carro hasta pasar de página. Pero ambos casos tienen el mismo problema: simplemente, no funcionan.

En el caso del procesador de textos, si aumentamos o disminuimos el tamaño de letra o quitamos o añadimos contenido, tendremos que cambiar el número de retornos de carro que sirven para alcanzar la siguiente página.

En el caso de nuestro formulario, la etiqueta <br /> no tiene significado alguno dentro de la enumeración de campos. Sólo tiene como objetivo mejorar la presentación. Pero la presentación no debería ser objeto de la codificación HTML, para eso ya están las hojas de estilo CSS. Mediante HTML debemos escribir el contenido de las páginas y dotarlo de significado a través de los diferentes elementos. Así pues, esta primera opción queda descartada.

Distribución basada en tabla

Es la forma más sencilla de disponer los elementos en la plantilla y la que más prestaciones de presentación ofrece, pero también es la que menos semántica aporta al contenido y la que más marcado HTML necesita.

Es sencilla si se domina la codificación de las tablas (que no es nada fácil de aprender) pero, lamentablemente, debido a un mal uso de este elemento, es fácil asumir que esta es una técnica muy conocida porque en multitud de páginas se usan para lo que no fueron hechas: para maquetar las páginas en lugar de usarlas para mostrar datos tabulados.

Ejemplo: form_table_layout_unstyled.html

Con este ejemplo se puede observar que:

  • Cada etiqueta queda alineada con su campo asociado.
  • Aunque no se aprecie, la tabla se ajusta al contenido. Es decir, no tiene un ancho del 100% de la página.


Estas ventajas que nos aporta el uso de tablas sólo tienen fines de presentación pero, hemos dicho que de la presentación ya se ocuparían las hojas de estilo, ¿no? De lo que se trata en HTML es de dotar de significado al contenido mediante el marcado. Sin embargo, lo que hemos conseguido es esto:

  • El título del formulario se ha convertido en un encabezado de tabla.
  • Hacer trabajar más a los lectores de pantalla porque hemos aumentado el marcado.
  • La estructura se ha convertido en algo sin sentido por utilizar las celdas de la tabla como contenedores de los campos (¿qué sentido tiene poner un botón dentro de la celda de una tabla?).


Ante estas terribles circunstancias, será mejor valorar otras opciones.

Distribución basada en lista

Para dotar de significado a la codificación del formulario, se podría pensar que los campos constituyen una enumeración (y poder utilizar entonces como contenedor el elemento ul), que puede incluso determinarse un orden en la importancia de los campos (para usar el elemento ol). Otra posible idea sería considerar que tenemos que rellenar la definición que se nos da en la etiqueta (entonces podríamos escribir una lista de definiciones con los elementos dl, dd y dt).

Ejemplo: form_list_layout_unstyled.html

Con cualquiera de estas formas se dota de estructura al contenido y de cierto significado, si alguna de las metáforas tuviera fundamento. Todas me parecen algo sacadas de contexto, sobre todo la de la lista de definiciones (aunque no me he podido resistir a ponerla en el ejemplo por ser la más rebuscada). De todas maneras, veamos si hemos ganado algo respecto al anterior punto:

  • Hemos conseguido la ordenación de los campos.
  • Hay menos marcado HTML.
  • Se consigue dotar de semántica al contenido (aunque no sea la más adecuada).


Distribución basada en párrafos

Antes de explicar la siguiente propuesta, vamos a hacer un pequeño paréntesis para explicar 2 elementos que dotarán de significado al formulario.

El elemento fieldset sirve para agrupar lógicamente un grupo de campos dentro de un formulario. Por ejemplo, podríamos agrupar dentro de un fieldset los datos personales (nombre y apellidos) y dentro de otro, los datos postales (dirección, código postal, etc.), todo ello dentro de un mismo formulario:


<form action="http://www.example.com/store_info.php" method="post">
<fieldset>
<legend>Datos personales</legend>

<label for="first_name">Nombre:</label> <input type="text" id="first_name" name="first_name" value="" />
<label for="surname">Apellidos:</label> <input type="text" id="surname" name="surname" value="" />
...
</fieldset>

<fieldset>
<legend>Datos postales</legend>

<label for="address">Dirección:</label> <input type="text" id="address" name="address" value="" />
<label for="city">Población:</label> <input type="text" id="city" name="city" value="" />
...
</fieldset>

<fieldset>
<input type="submit" name="send" value="Enviar" />
</fieldset>
</form>


Aunque con el ejemplo ya se puede intuir el uso del elemento legend, vamos a explicarlo un poco más en detalle. Con este elemento se etiqueta a un grupo de campos, se describe la función lógica de ese conjunto de datos.

Como hemos visto, sólo con el uso de estos elementos ya se dota de cierta estructura al contenido pero todavía es necesario utilizar elementos de bloque para dar estructura a cada uno de los campos. Para ello, vamos a ver como queda utilizando párrafos: form_paragraph_layout_unstyled.html

  • Hemos cambiado el encabezado h1 por el uso del elemento legend, con lo que hemos dotado de más semántica al título del formulario. De rebote, también hemos mejorado la accesibilidad ya que los lectores de pantalla podrán describir mejor los campos del formulario.
  • Hemos conseguido ordenar los campos para que sea más fácil rellenarlos.
  • El marcado HTML no puede ser más simple ni reducido y, a la vez, no puede tener más semántica.


¿Acaso ya hemos descubierto la forma más correcta de escribir el formulario en HTML? Pues, como casi todo, es relativo y dependerá de nuestras necesidades. Hay un pequeño inconveniente en esta distribución y por eso vamos a ver un ejemplo más.

Distribución basada en divisiones lógicas

El inconveniente tiene que ver con lo que puede ir dentro de un elemento p. Existe una limitación que, en algunos casos, puede ser importante: no podemos poner otros elementos de bloque dentro (sólo es posible insertar texto y algunos elementos en línea). Esta es la razón por la que, en lugar de utilizar el elemento p, utilizaremos el elemento div.

Ejemplo: form_div_layout_unstyled.html (este será el formulario que utilizaremos en el siguiente artículo de la serie para aplicarle estilos CSS y darle una apariencia más amigable).

  • La legibilidad se mantiene a la hora de rellenar el formulario.
  • El marcado HTML es casi tan mínimo como antes e igual de sencillo.
  • Podemos añadir elementos de bloque dentro de cada agrupación lógica de cada campo. Por ejemplo, si se quiere adjuntar una pequeña ayuda en línea para algún campo.



...
<fieldset>
<legend>Datos postales</legend>

<div>
<label for="address">Dirección:</label>
<input type="text" id="address" name="address" value="" />

<p>Ejemplo: calle, número, piso, letra</p>
</div>

...
</fieldset>
...


Bibliografía recomendada

Etiquetas: , ,

domingo 19 de agosto de 2007

Formularios web (I): Elementos básicos de HTML

Los formularios en las páginas web sirven para obtener datos de los usuarios. Igual que a nadie gusta rellenar largos e interminables formularios en papel, debemos tener esto, aún más en cuenta, a la hora de diseñar para la web. Para ello, podemos seguir estas sencillas reglas:

  • Nunca se deben pedir más datos de los estrictamente necesarios. De esta forma evitaremos pesadez al usuario y nos ahorraremos espacio en nuestro sistema de almacenamiento de datos. A este consejo habría que añadir esta recomendación: nunca pedir datos al usuario hasta que no sean necesarios para la acción que está realizando. En una tienda del mundo real, a nadie nos preguntan el número de la tarjeta de crédito hasta que no vamos a pagar en la caja.
  • Proporcionar valores por defecto siempre que sea posible (para rellenar menos campos y mejorar la satisfacción del usuario: cuanto menos tenga que teclear, mejor).
  • En los campos que necesiten información específica, es buena idea proporcionar ayuda en línea que explique cómo rellenarlo, mostrando ejemplos reales o determinando rangos de entrada.
  • Si hay errores en el formulario, mostrar claramente dónde se han producido y cómo resolverlos. Para los valores que sí estén correctos, habrá que recordarlos para evitar que el usuario los tenga que volver a rellenar.
  • Si el número de campos a completar es alto, habrá que mostrar la información en grupos lógicos que tengan relación para que sea más fácil localizarla. Incluso puede ser buena idea descomponer un formulario grande en varias páginas, simulando el funcionamiento de un asistente. Si optamos por esta opción, la navegación entre las distintas páginas debe ser clara para permitir al usuario moverse de una a otra sin perder ningún dato.
  • No hay nada más frustrante para el usuario que llegar al final de un formulario y equivocarse de botón (por ejemplo, pulsar el botón Cancelar y observar que todo lo que había escrito desaparece como por arte de magia). Hay que separar (o hacer más grande, o poner en una posición predominante, ...) la opción principal (que es enviar los datos) de otras secundarias (como la de restablecer los campos o volver a otra página anterior) para evitar esta situación.


Esta lista podría seguir hasta casi el infinito. El diablo está en los detalles y la diferencia entre un sitio amigable y con un buen número de visitantes puede estar en cómo, cuándo y cuánta información pide a los usuarios. Un buen estudio sobre estos y otros consejos para el diseño de formularios, podemos encontrarlo en Best Practices For Form Design.

El objetivo de esta serie de artículos es presentar un ejemplo sencillo de formulario web y ver los diferentes pasos que hay que hacer para integrarlo en una página web. Más concretamente, los objetivos de cada uno de los artículos son los siguientes:

  • Elementos básicos de HTML (el presente artículo): breve introducción a algunos de los elementos disponibles en HTML para la construcción de los campos.
  • Agrupación de los campos con HTML: hay diferentes formas de distribuir y presentar los campos de un formulario en HTML. Veremos algunas de ellas junto con sus ventajas e inconvenientes.
  • Diseño con CSS: una vez estructurado el contenido en HTML, llega el momento de mostrar al usuario de la forma más amigable posible el formulario.
  • Programación del lado del servidor: es buena idea crear una librería de código (para PHP) para construir formularios HTML puesto que es una tarea repetitiva en cualquier proyecto web.


El ejemplo que nos va a servir para ir viendo cada una de las partes (HTML, CSS y programación), es la creación de un sencillo formulario de contacto. Contendrá 3 campos: el nombre, el correo electrónico (para que podamos responder al visitante) y un campo de texto libre en el que irá el comentario que nos quieran escribir.

Campo de texto simple

En primer lugar vamos a ver como se codificaría en HTML el campo para el correo electrónico:


Correo electrónico:

Correo electrónico: <input type="text" name="email" size="35" value="">


En principio, esta sería la forma más básica (y totalmente funcional) de construir el campo de nuestro formulario:

  • El atributo type indica que es un campo de texto simple (que sólo puede contener una línea de texto).
  • El atributo name indica el nombre de la variable que contendrá el valor del formulario.
  • size indica el ancho del control en la visualización, en este caso, para que quepan 35 caracteres. Nada tiene que ver con el máximo número de caracteres que pueden introducirse en el control.
  • Por último, el atributo value sirve para indicar el contenido por defecto que mostrará el control.


Hemos visto la forma simple, pero vamos a introducir algunas mejoras en el marcado HTML:




<label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" />


El elemento label sirve para relacionar un texto (que llamaremos etiqueta) con el campo al que hace referencia. Esto se hace en 2 fases: primero se marca en el atributo id del elemento input correspondiente el identificador del campo (que puede tener el mismo valor que el atributo name) y, después, indicar en el atributo for de label el identificador del campo al que se asocia. Con esta medida mejoramos el formulario en estos aspectos:

  • En semántica, porque dotamos de estructura lógica al texto que hace de etiqueta del campo.
  • En usabilidad, porque si se pulsa sobre el texto, el foco se situará sobre el control asociado.
  • En accesibilidad, al proporcionar la asociación implícita entre el texto y el campo. Alguien que ve el formulario en la pantalla asocia la etiqueta al campo por la cercanía de los elementos pero para quien no lo puede ver, esa pista, por sí sola, no es suficiente.


Hemos indicado, a través del atributo maxlength la cantidad máxima de caracteres que admitirá el campo. De esta forma, por más que lo intente, el usuario no podrá introducir más caracteres de los permitidos y se evita que luego halla efectos de truncado de la información (si hubiéramos permitido introducir más pero en la base de datos no caben, tendríamos que haber truncado los caracteres sobrantes).

Como último retoque, hemos cambiado la forma en la que se cierra el elemento input (<input ... />), añadiendo una barra al final. De esta forma conseguimos compatibilidad con XHTML si queremos usar un formato más riguroso, sin perder la compatibilidad con el HTML normal porque también acepta esta forma de cerrar los elementos vacíos. Por la misma razón, los elementos y atributos siempre deben ir en minúsculas y los valores de los atributos entre comillas.

Los valores de los atributos id y name no tienen por qué coincidir. Sólo hay que recordar que se puede repetir el mismo valor de name en un formulario pero no así el valor de id, que debe ser único para cada elemento en una misma página.

Otra posible forma de codificar el campo del correo electrónico en HTML sería esta:


<label>Correo electrónico: <input type="text" name="email" size="35" maxlength="35" value="" /></label>


Escribiendo el elemento input dentro del label no hace falta indicar explícitamente la relación entre ambos elementos (atributos id y for). Pero, aun siendo totalmente válida esta alternativa, no es recomendable usarla porque puede causar algún problema en ciertos navegadores y lectores de pantalla.

Campo de texto multilínea

Continuemos viendo como escribir el código del campo Comentario. La idea es que el visitante de nuestra página escriba todo lo que quiera sin problemas de espacio. Como hemos visto antes, el elemento input se nos queda un poco pequeño pues sólo permite una línea de texto. Existe otro elemento, llamado textarea, que se ajusta mucho mejor a nuestras necesidades: el usuario puede escribir en varias líneas y viendo más texto de vez, como si escribiera un correo.




<label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40"></textarea>


Hemos utilizado la asociación entre etiqueta y control a través de los atributos for e id, como en el caso anterior.

Los atributos rows y cols sirven para dar dimensiones gráficas al control dentro de la página (4 líneas de alto y 40 caracteres de ancho).

En este elemento, el valor por defecto que se mostraría al visitante, debemos escribirlo como contenido de la etiqueta textarea. Por ejemplo, si quisiéramos mostrar un texto de muestra, tendríamos que escribir algo como esto:




<label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40">Texto de ejemplo</textarea>


En cambio, si lo que queremos es que el campo esté completamente vacío, no debe haber ningún caracter extra (como un espacio o un retorno de carro) entre el cierre de <textarea ... > y el comienzo de </textarea>.

Botón de envío

Ahora necesitamos añadir un botón de envío para que el usuario pueda mandarnos sus datos a un lugar donde podamos almacenar la información.




<input type="submit" name="send" value="Enviar" />


Utilizando de nuevo el elemento input, cambiando el valor del atributo type por submit ya tenemos nuestro botón. Además, este valor indica que cuando se pulse el botón, se producirá el envío de los datos al lugar especificado por el atributo action del elemento form.

En este caso, el contenido del atributo value es lo que se mostrará como texto del botón, por lo que no es necesario añadir una etiqueta con el elemento label.

Elemento form

Todos los controles de formulario que hemos visto hasta ahora, tenemos que ponerlos dentro de otro elemento, denominado form, para indicar que todos los campos forman parte de la misma transacción de información y, también, para indicar el destino de esos datos.


<form action="http://www.example.com/store_info.php" method="post">
<label for="name">Nombre:</label> <input type="text" id="name" name="name" size="35" maxlength="35" value="" />
<label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" />
<label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40"></textarea>
<input type="submit" name="send" value="Enviar" />
</form>


El atributo action establece el lugar a donde irán a parar los datos del formulario. Generalmente, indicaremos la dirección de un script donde recoger y procesar la información pero también se puede indicar una dirección de correo de destino para que los datos se envíen mediante correo electrónico. Sólo recomiendo esta opción si no se dispone de otra forma de envío de datos porque el funcionamiento depende mucho de los programas con los que cuente el usuario en su máquina para enviar el correo.

Según el método de codificación de datos indicado en el atributo method, la información tendrá que ser decodificada de forma diferente en el lado del servidor porque se enviará de distinta forma desde el navegador cliente. Para simplificar esta cuestión, diré que el método post es algo más seguro y permite enviar más datos en la transacción.

Antes de terminar, quisiera comentar el uso del atributo title dentro de los campos para simular una sencilla ayuda contextual para rellenar el control.




<label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" title="Se requiere una dirección de correo válida" />


Aunque su uso no es totalmente eficaz, pues sólo aparece si nos posicionamos sobre el control y no es un buen sistema para textos largos, sin embargo puede servir si el mensaje no es muy largo, además de ser una solución accesible para los programas lectores de pantalla.

Para una información más detallada sobre otros elementos que se pueden agregar en los formularios (como listas despleglables o casillas de verificación), recomiendo la lectura de los siguientes enlaces:



Bibliografía recomendada

Etiquetas: , ,

miércoles 3 de enero de 2007

Los elementos perdidos de HTML

Soy una de esas personas que, cuando miran una nueva página web, no se fijan tanto en lo que se ve a simple vista como en el esqueleto que le da forma: el código fuente. Ahí es donde se puede apreciar la verdadera estructura del contenido y la semántica que se ha utilizado (la que se encontrarán los motores que indexen esa página web).

Bien es verdad que HTML tiene algunas carencias para marcar el contenido, que se están intentando solucionar con la redacción de XHTML 2.0 o HTML 5.0 (que todavía está más en pañales que XHTML 2.0). Pero también es cierto que, algunos elementos que sí posee, no son utilizados (en los casos en los que se deberían utilizar). Tal vez sea por desconocimiento o por usar algunos editores WYSIWYG (bien sean de escritorio como DreamWeaver o bien estén hechos en JavaScript como TinyMCE), pero no debemos olvidar que para darle un correcto significado al contenido, hay que marcarlo de la forma adecuada.

No debemos caer en la tentación de marcar en función de la presentación que luego los navegadores dan a esos elementos. Hay que recordar que siempre podemos cambiar la presentación gracias a las hojas de estilo en cascada (CSS).

Marcado de edición de textos

ins y del
Cuando estamos desarrollando un documento, hay cosas que no siempre se escriben bien a la primera, o bien luego hay que hacer algún ajuste o actualización. HTML nos permite marcar los cambios, ya sean añadidos o borrados, con las etiquetas ins y del. De esta forma, al igual que en otros editores de texto, de un vistazo, se pueden descubrir los cambios en el documento.

Además, estas etiquetas tienen 2 atributos que sirven para saber las razones del cambio (cite) y cuándo se realizó dicho cambio (datetime). El formato de este último atributo es un poco especial y riguroso. Está basado en esta plantilla: YYYY-MM-DDThh:mm:ssTZD
  • YYYY: año con 4 dígitos
  • MM: mes con 2 dígitos (01-12)
  • DD: día con 2 dígitos (01-31)
  • T: caracter separador entre fecha y hora
  • hh: hora con 2 dígitos (00-23)
  • mm: minutos con 2 dígitos (00-59); es información opcional
  • ss: segundos con 2 dígitos (00-59); es información opcional
  • TZD: zona horaria, Z para hora Zulú (la del meridiano de Greenwich) o desfase en horas y minutos (positivo o negativo) del huso horario correspondiente


Más información sobre la plantilla de datetime en ISO 8601 de la Wikipedia.

Ejemplo de uso de los elementos ins y del:

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit<ins cite="lorem ipsum..." datetime="2007-01-05T13:24+01:00">, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat</ins>. Ut wisi enim ad minim veniam<del cite="lorem ipsum..." datetime="2007-01-04T08:21:34-05:00">, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat</del>. Duis autem vel eum iriure dolor in hendrerit in ...</p>

bdo

Otro desconocido elemento para la edición de textos es bdo. En inglés, bdo es la abreviatura de bidirectional override, y si nos atenemos a esta definición, podemos adivinar su función: sobreescribir el tratamiento direccional del texto para el contenido que se encierre dentro del elemento.

Por si no ha quedado claro, intentaré explicarlo mejor. Uno de los atributos de la etiqueta html es dir, que sirve para indicar cómo se debe escribir (el navegador) el texto que contiene el documento, es decir, si se escribe de izquierda a derecha (ltr) o de derecha a izquierda (rtl).

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" dir="ltr" lang="es">
...

Como se puede ver en el ejemplo, con el atributo dir se define la legibilidad de todo el documento pero, ¿qué ocurre si dentro de un texto que se lee de izquierda a derecha, necesitamos incrustar algo de contenido que está en otro idioma y además se lee al revés? Para eso existe el elemento bdo. Veámoslo con otro ejemplo:

...
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" dir="ltr" lang="es">
...
<p>Contenido en idioma español. Se escribe de izquierda a derecha.</p>
<p><bdo lang="zh-TW" dir="rtl">Contenido en otro idioma (chino tradicional) que se redacta de derecha a izquierda.</bdo><p>
...

Como se puede ver en el ejemplo, se ha definido un idioma y una dirección de escritura general para el documento (en la etiqueta html) y luego se ha marcado el texto en otro idioma (que si supiera chino, estaría correctamente escrito ;-) ) gracias a la etiqueta bdo.

Etiquetas de estilo basado en contenido


cite

cite sirve para indicar que el texto que contiene es una referencia bibliográfica. Junto con el elemento para enlaces (a), puede servir para hacer referencia a otro documento donde se encuentra la fuente que hemos citado.

<blockquote lang="en-GB">You can't always get what you want; but if you try sometimes, you just might find, you get what you need.</blockquote>

<p><cite><a href="http://en.wikipedia.org/wiki/You_Can't_Always_Get_What_You_Want">Rolling Stones</a></cite></p>

code

La etiqueta code indica que el texto que encierra es código fuente de programación. Esto hace que los navegadores utilicen (por defecto y a no ser que establezcamos lo contrario con CSS) una fuente monoespaciada (todos los caracteres tienen la misma anchura) para visualizar el texto.

<pre><code lang="en-US">
/**
* string numberToAlphabet(int $number)
*
* Converts an integer in an alphabetical string (1 <= $number <= 702)
*
* @author PHP manual, user contributes notes for chr() function
* @param int $number integer to convert
* @return string alphabetical string
* @access public
*/
function numberToAlphabet($number)
{
return ($number-- > 26 ? chr(($number / 26 + 25) % 26 + ord('A')) : '') . chr($number % 26 + ord('A'));
}
</code></pre>

En el ejemplo, se ha encerrado el contenido de code dentro de la etiqueta pre por 2 razones:
  • code es una etiqueta para texto en línea (es decir, tiene [o debe] ir dentro de otra etiqueta de bloque distinta de body, que sólo debería contener otros elementos de bloque)
  • con el uso de pre se preservan los espacios y líneas en blanco del texto, necesarios para dar formato al código fuente

dfn

La etiqueta dfn se utiliza para marcar los términos (y no las definiciones) nuevos (o especiales) de un documento que necesitan la atención del lector. Como regla de buen estilo, sólo se delimita la primera aparición del término en el texto.

<p>El software libre es también llamado software de código abierto. La razón por la que se llama así es que, junto con el <dfn>programa objeto</dfn>, se distribuye el <dfn>código fuente</dfn> del mismo.</p>


Para definir los conceptos (como cuando se escribe un glosario de términos) existe otro conjunto de etiquetas:
  • dl: lista de definiciones
  • dt: término a definir
  • dd: definición del término


<dl>
<dt>Programa objeto</dt>

<dd>Instrucciones que se ejecutan directamente contra la máquina y que no son comprensibles por las personas.</dd>

<dt>Código fuente</dt>

<dd>Instrucciones escritas en un lenguaje de programación que el ser humano puede leer pero que no comprende directamente la máquina.</dd>
</dl>

kbd

kbd es la forma más indicada de indicar que un determinado texto es introducido desde el teclado (keyboard). Es muy útil para el caso de redactar manuales o cualquier otro tipo de documentación técnica.

<pre><samp>
C:\><kbd>c:\mysql\bin\mysql -uadmin -p mysql</kbd>
Enter password: <kbd>*********</kbd>
</samp></pre>

samp

Como se ha podido ver en el ejemplo anterior, en el que hemos hecho uso ya de la etiqueta samp (sample), esta sirve para mostrar la salida de algunos programas o ejemplos de código fuente (como los que estoy utilizando en este artículo).
var

La etiqueta var se utiliza para marcar texto que sirve de plantilla, es decir, para texto que no se debe introducir tal cual, sino que debe reemplazarse por otro a la hora de teclearlo. Como ejemplo, puede servir este extracto donde se combinan además otras etiquetas vistas anteriormente.

<p>Verifique su base de datos y usuario accediendo a la nueva base de datos con el nuevo usuario.</p>

<pre><samp>
C:\><kbd>C:\mysql\bin\mysql -u <var>new_user</var> -p<var>new_password</var> <var>new_database</var></kbd>
</samp></pre>

Notas finales


Para la redacción de este artículo he utilizado algunas deficiones y ejemplos que aparecen en el libro HTML y XHTML: La Guía Definitiva, original de la editorial O'Reilly pero traducido al español por Anaya Multimedia.

En los ejemplos expuestos se ha usado el punto de vista de quien codifica la página, por eso se muestra el código fuente necesario para marcar el contenido. Queda a disposición del lector la prueba de dichos ejemplos en su propio navegador para ver cómo se visualizan. Se ha optado por hacerlo de este modo porque no existen reglas fijas de presentación y estas pueden diferir entre diferentes agentes de usuario (navegadores web).

Actualización (2007-01-04):
Sólo un día después de la publicación de este artículo, me encuentro con esta guía de marcado semántico. Para quienes deseen completar esta lectura, se lo recomiendo encarecidamente: se habla también del correcto uso de los elementos más habituales (encabezados, párrafos, listas, ...) y hay más ejemplos sobre la adecuada utilización de las etiquetas de HTML.

Etiquetas: , ,

domingo 3 de diciembre de 2006

Comentarios condicionales de HTML

Las guerras entre navegadores fueron cruentas en su día y sólo han dejado vencidos a su paso: los pobres desarrolladores web que tienen que usar todo su ingenio para conseguir que una página se vea igual en todos los navegadores (actuales, antiguos y futuros).

Afortunadamente, el futuro pinta bastante bien en este aspecto. Los nuevos clientes web que salen al mercado (Firefox, Opera, Safari, Konqueror, etc...) tienen entre sus objetivos seguir y cumplir los estándares que se discuten y aprueban en el W3C.

Pero, ¿qué hacer con los navegadores que a día de hoy se usan aunque sean auténticas reliquias del pasado? Existen varias opciones:


  • Hacer varias hojas de estilos, cada una para cada navegador.

  • Hacer una única hoja de estilos, mezclando código válido (que es lo que el W3C recomienda) con selectores específicos que sacan partido de los errores de interpretación de las CSS de cada navegador.

  • Como variación de la primera opción (varias CSS), podemos hacer una CSS general para todos, y alguna más específica para aquellos navegadores en los que haya algún problemilla que resolver.



La primera opción requiere de 2 cosas: tener una manera de poder identificar a cada uno de los navegadores (a través de un lenguaje de programación del lado del servidor como PHP, por ejemplo), y mucho trabajo por nuestra parte, ya que deberemos repetir muchísimo código en cada una de las hojas de estilos. El trabajo de hacer CSS, en principio, dependerá de nuestra paciencia, pero identificar navegadores web no es una tarea fácil y no siempre será posible llevarlo a cabo (si sólo disponemos de HTML para hacer nuestras páginas).

La segunda opción (una sóla CSS), ha sido durante los últimos años la más usada (e incluso recomendada). Requiere de una gran curva de aprendizaje puesto que navegadores ha habido (y hay) muchos y cada uno tiene unos bugs distintos para explotar.

Tal y como va el artículo, todo parece indicar que la tercera opción es la más recomendable. Si hubiera escrito estas líneas hace un año, mi respuesta hubiera sido que la mejor era la segunda (aunque implique muchas búsquedas en Internet y muchas horas de pruebas y más pruebas), pero el mundillo web tiene estas cosas: lo que hasta ayer era el estándar de facto, mañana mismo se convierte en una tecnología obsoleta. Más o menos es lo que ha pasado. Microsoft ha sacado (después de 6 años de sequía) su nuevo navegador (el flamante y renovado IE 7) y como siempre, para bien o para mal, las reglas del juego han cambiado.

La forma de implantar la tercera opción es hacer una CSS general (que se aplicará a todos los navegadores) desarrollándola en algún cliente web que respete lo más posible los estándares de hojas de estilos (como Opera, Safari o Firefox), y luego hacer otras CSS más reducidas (que servirán para sobrescribir algunas reglas generales) para los (en realidad el) navegadores que no siguen las reglas del juego en algún aspecto. ¿Y cómo se consigue esto? Pues con alguna de las herramientas que la misma Microsoft desarrolló en su momento para competir con la casi desaparecida NetScape: los comentarios condicionales en HTML.

Veamos esto con un ejemplo:

...
<head>
...

<link rel="stylesheet" type="text/css" href="./css/all_nav.css" media="screen" title="Hoja de estilos general" />

<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="./css/ie_fix.css" media="screen" title="Hoja de estilos específica para IE 6" />
<![endif]-->

<!--[if IE 7]>
<link rel="stylesheet" type="text/css" href="./css/ie7_fix.css" media="screen" title="Hoja de estilos específica para IE 7" />
<![endif]-->

...
</head>
...


Esta técnica (apoyada por la mismísima Microsoft para que los desarrolladores web lleven a cabo la migración de sitios para que funcionen con su nuevo explorador), nos permite tener una CSS general acorde a los estándares promulgados por el W3C que nos servirá para los navegadores actuales y para los que vengan después, y por otro lado, tener localizados, en pequeños archivos, las excepciones a las reglas, sin tener que utilizar molestos y complicados hacks. Así, el código de nuestras páginas validará y a la vez, los contenidos (que es lo que realmente importa), se verán de una forma bastante similar en todos los navegadores que se usan hoy en día.

Etiquetas: , ,