Uno de los aspectos más importantes de la separación de contenido y presentación mediante el uso correcto de HTML, es la descripción semántica del contenido mediante elementos con valor propio. De este modo el contenido gana una nueva dimensión.

El uso apropiado de HTML para marcar los contenidos nos permite asignarle un valor especial a cada elemento, que lo contextualiza, le asigna jerarquía y lo describe. Un ejemplo típico es el de los títulos: el apropiado uso de h1 nos indica explícitamente que lo que está contenido en este elemento es un título de primer nivel, que la página trata sobre este tema. Luego, un h2 nos dirá que este contenido es importante, aunque no tanto como el h1. Así, prácticamente todos los elementos presentes ya en XHTML tienen un valor semántico específico.

En este contexto, CSS nos permite modificar la apariencia de cada elemento, sin necesidad de contaminar el contenido con elementos presentacionales. Esto lo hacemos mediante una serie de recursos, aunque los más comunes por el soporte existente actualmente son los siguientes:

• Selectores de elementos
• Selectores contextuales
• Selectores de ID
• Selectores de clases

La forma más pura de modificar la presentación sin alterar en lo más mínimo el HTML es a través de los selectores de elementos. Para especificar reglas para el cuerpo del documento, por ejemplo los márgenes, usaremos body { margin: 10px; }.

Los selectores contextuales nos permitirán referirnos a elementos según su ubicación o contexto. Por ejemplo, para modificar el color a los vínculos que se encuentren exclusivamente dentro de un párrafo, usaremos:p a { color: #0000FF; }

Un elemento que declare el atributo id podrá ser referenciado mediante el valor de éste. Por ejemplo, un div id="menu" será afectado por una regla como #menu { display: block; }.

Es común que utilicemos el atributo id para identificar de modo único a un elemento dentro de un documento y esto es totalmente legítimo. Pero cuando comenzamos a hablar del último recurso que mencionamos antes, el atributo class, nos acercamos a tres de los problemas más comunes al trabajar con CSS. Me refiero primero a su uso para reemplazar la función de elementos legítimos de HTML. Un ejemplo clásico es usar engendros como <p class="titulo">. Esto es un error serio porque al reemplazar la función de un elemento perfectamente legítimo, como h1, por p class="titulo", estamos perdiendo la calidad semántica inherente al elemento h1: p class="titulo" no significa nada más que esto es un párrafo, no se entiende de ningún modo que tratamos de crear un título, en consecuencia, esto afectará a los robots y a los indexadores de los buscadores como Google que no podrán comprender la supuesta estructura que acabamos de crear. Esto finalmente nos creará problemas de indexación y malos resultados en los buscadores.

El segundo problema común que se comete al usar CSS es usar clases con un valor descriptivo visual específico, como class="izquierda", class="verde" o class="grande". El error aquí se produce porque aún no se logra generar la separación mental entre contenido y presentación. Las clases deberían llamarse según la función o contenido que describen. Si por class="izquierda" nos referimos a un grupo de vínculos que mostraremos como una columna a la izquierda, como un menú de navegación contextual o secundario, entonces usemos class="menu-navegacion". El problema práctico fundamental que ocurre en estos casos es que cuando nos enfrentemos a un rediseño de la presentación del sitio, es muy posible que el elemento con class="izquierda" termine arriba, abajo o a la derecha y la clase no tenga ninguna relación con el nuevo diseño.

Finalmente, el otro problema común es la clasitis, o la utilización en exceso de clases. En muchos casos se recurre a un uso exagerado de clases cuando es perfectamente posible utilizar selectores contextuales, de elementos o una combinación de selectores que no alteren el HTML. Nuevamente es necesario recordar que CSS debería utilizarse para separar la presentación del contenido. Con el soporte actual de selectores en los browsers más utilizados (si aún no queda claro, me refiero a IE), tarde o temprano recurriremos al uso de alguna clase que con un soporte completo de CSS sería innecesario usar. Pero la idea es reducir al mínimo la intervención del HTML. Para esto, una buena planificación de la estructura de nuestros documentos es esencial.

Hemos cubierto algunos de los problemas más comunes en el uso de CSS que de un modo u otro afectan al HTML de un documento y con esto al valor semántico de sus elementos. Para quienes ya han dado el paso de asumir el uso de estándares con la combinación de HTML y CSS, espero que estos detalles contribuyan a mejorar la estructuración de los documentos con todos los beneficios que esto conlleva. Para quienes están comenzando el camino, bienvenidos, espero que esto les ayude a evitar algunos de los problemas más frecuentes.

En una nota anterior comenté sobre las unidades de medida para fuentes en CSS. En esta oportunidad profundizaremos el tema refiriéndonos particularmente a una unidad, tal vez la menos conocida del grupo: ems.

Cuando se plantea el tema de cómo definir los tamaños del texto usando CSS varias cosas entran en juego. En primer lugar las consideraciones de usabilidad, en relación a la legibilidad del texto y la posibilidad de los usuarios de controlar el tamaño de despliegue para ajustarlo a sus necesidades. Por otro lado, el control sobre el diseño y presentación del sitio, normalmente defendido a dentelladas por los diseñadores.

Poniendo las cosas en perspectiva, lo primero que debemos entender, es que las necesidades del usuario son un requerimiento y no un elemento optativo en el desarrollo de un sitio. La usabilidad y accesibilidad son demandas del usuario y nosotros debemos oirlas.

El diseño debe estar al servicio de estos requerimientos. Punto.

Estas dos perspectivas no son necesariamente contradictorias, y es posible crear sitios accesibles, usables y estéticamente agradables. En esto el control y conocimiento de las herramientas disponibles ayuda mucho, y CSS juega una parte importante.

Con CSS podemos lograr textos con tamaños relativos, es decir, no fijos, modificables por los usuarios utilizando los controles normales del browser (las opciones Text Zoom o Text Size dependiendo del browser). Para ello contamos con tres unidades de medida definidas como relativas:

em

En la práctica, el tamaño por omisión definido en las preferencias del browser. La definición real de un em es el ancho del caracter m según el tamaño de texto actualmente en uso (activo). Esto normalmente se refiere al tamaño del elemento padre, el que contiene a aquél al que nos estamos refiriendo.

ex

ex se refiere a la altura del caracter x respecto al tamaño de texto activo.

px

Para sorpresa de muchos, se considera al píxel como una unidad de medida relativa, esto respecto a diversos dispositivos de visualización. Por ejemplo, un píxel en un PC de escritorio no será del mismo tamaño que en una Palm. Incluso será de tamaño diverso en distintos tipos de monitores.

%

Pese a no estar directamente asociado a los elementos anteriores como unidad de medida, el porcentaje se relaciona siempre con otros valores, como por ejemplo, píxeles. Al definir un porcentaje, se necesita conocer un valor de referencia, por ejemplo, el 10% de 125 píxeles.

Lo que hace especial a em lo podemos resumir en la siguiente lista:

• se trata de una unidad relativa, que se escala proporcionalmente
• que no depende directamente de otros elementos, como los porcentajes
• que no es exclusivo para uso en un medio particular, como pt o px
• que permite un total control al usuario

El problema sobre el control del diseño persistirá si insistimos en desarrollar diseños que requieran de precisión absoluta. La solución es diseñar tomando en cuenta estos factores, y teniendo consciencia de que finalmente y en condiciones más o menos extremas, para un usuario (y para nosotros como responsables de un sitio) es preferible ser capaces de acceder a un contenido, que de ver un diseño agradable, pero quedar impedido de leer la información a la que supuestamente sirve.

Juan Carlos escribe una nota bien documentada, como es usual, sobre tipografía en el web. Su objetivo es tratar de entender las razones detrás del uso de fuentes con o sin serif, pero un comentario secundario capturó mi atención y no puedo evitar el entrar en detalles sobre esto.

De momento, aunque con poca base científica detrás, yo sigo recomendando escribir el cuerpo de los textos más o menos largos en letra sans serif, preferiblemente Verdana o Arial, y en un tamaño de 12 puntos (mejor puntos que pixels, pues los puntos permiten al usuario modificar fácilmente el tamaño del texto).

Evidentemente lo que ha hecho que mis alarmas suenen es la recomendación de usar puntos por sobre otras unidades de medida. Desde hace bastante tiempo que el tema de las unidades de medida para textos se viene discutiendo con bastante pasión en los círculos de die-hards de CSS. En resumen este asunto se puede resumir en lo siguiente, al menos desde mi perspectiva:

• pt (puntos) es una unidad de medida eminentemente (tipo)gráfica, sin embargo no es apropiada para la pantalla, por varias razones, entre ellas el hecho de que no es proporcional, pese a que browsers modernos realicen un escalamiento proporcional (Mozilla, Opera). Adicionalmente, un punto no siempre es exactamente equivalente a un píxel: en Windows un punto se traduce a 1.3 píxeles y en Mac el equivalente es uno a uno, por lo que los resultados en diversas plataformas son imprecisos. En conclusión, es mejor utilizar esta unidad de medida para especificar hojas de estilo especiales para impresión.
• px (píxeles) es una unidad de medida absoluta y mapeada directamente a la resolución del monitor. Si bien es posible (y aconsejable) escalarla, IE no es capaz de hacerlo, al menos hasta la versión 6.
• em es una medida inherentemente tipográfica y proporcional, y es la más apropiada para la pantalla.
• % (porcentaje) es una unidad de medida relativa que se ajusta perfectamente al uso en monitor, pero que puede llevar a ciertas impresiciones conceptuales. Prefiero utilizar porcentajes para especificar bloques en lugar de textos.

Para sostener estos argumentos y comprobar cómo se tratan las distintas unidades de medida de texto he publicado una página de prueba con texto en puntos, píxeles, ems y porcentajes. Para nadie será sorpresa que Mozilla maneja las unidades de medida de manera formidable, escalando cada una de ellas de modo apropiado. En IE, en cambio, puntos y pixeles no son escalables.

Indefectiblemente cada vez que estoy concentrado editando o generando contenido en alguna aplicación web como el CMS que soporta este sitio, WordPress,o cualquier otro, tengo el reflejo natural de presionarControl+S para guardar los contenidos. Naturalmente esto activa la función Guardar Página del navegador (Mozilla en mi caso) en lugar de guardar aquéllo que estoy elaborando. Este es un condicionamiento producto de años de trabajo digital, en que he aprendido por la fuerza a proteger mi trabajo de potenciales problemas que terminen en la pérdida de horas de dedicación. Creo que a todos nos ha pasado.

El problema es que el modelo mental que formamos para trabajar en las aplicaciones tradicionales de escritorio, con interfaces bastante estandarizadas, no se aplican al entorno web. Sin embargo, necesitamos guardar o registrar nuestro trabajo o las selecciones que hayamos realizado, la configuración que hemos modificado, etc. Aquí, no obstante, el modelo es otro: debo recordar que estoy trabajando en un formulario web y que cualquier acción debe ser procesada por un script en el servidor, llamado mediante botones más o menos reconocibles, dependiendo del diseño único de cada aplicación web.

Aquí quedan expuestos claramente dos problemas que debemos tener muy claros al desarrollar interacciones en la plataforma que nos ofrece el web:

1. Necesitamos dejar muy en claro, de modo explícito, que este es un medio diferente, con reglas propias.
2. Debemos ser claros, consistentes y establecer un modelo que resulte en un aprendizaje rápido y fácil para el usuario: no debemos inducir a errores al usuario.

Esto que acabo de plantear no es algo nuevo, pero me comenzó a dar vueltas en la cabeza desde que comencé a publicar este weblog y me ha hecho replantear o repensar algunas cosas que daba por sentado. Y si me sucede a mí, de seguro que no soy el único. El asunto de fondo es, en consecuencia, cómo resolver la ambigüedad y partucularidad del formato que nos ofrece el web para realizar tareas que en el contexto familiar de las aplicaciones de escritorio nos resulta a esta altura natural.

No pretendo tener una respuesta, pero tengo la pregunta. Volveré al tema en la medida que lo elabore un poco más.

Desde hace un par de meses que estaba en la lista de espera de mis lecturas el libro de Donald Norman The Design of Everyday Things. Finalmente comencé a leerlo y la espera no ha sido en vano. Ya desde el principio me encontré con una anécdota que vale mencionar.

Cuenta Norman que originalmente el libro se llamó La Psicología de las Cosas Cotidianas, pero su editor le hizo notar que la palabra psicología hacía que en las librerías y bibliotecas éste se catalogara junto a los libros de psicología en lugar de aquéllos relacionados con interacción humano/máquina. Norman se dedicó a conversar con bibliotecarios y personal de librerías y comprobó la situación.

La anécdota de esto es que incluso él, que había escrito un libro sobre el diseño centrado en el usuario, había cometido un error considerable: no pensar en sus lectores, sino en sus colegas académicos, a quienes el título evidentemente complacía. Fue entonces que decidió cambiar el nombre en futuras ediciones a El Diseño de las Cosas Cotidianas.

Para sumar a la anécdota, es posible encontrar copias de ambas ediciones en Amazon: la primera versión, La Psicología de las Cosas Cotidianas y la segunda, El Diseño de las Cosas Cotidianas.

Cito la anécdota de Norman no como un acto de autoindulgencia sino, por el contrario, como algo a tener en cuenta, un recordatorio de que hasta en las cosas más simples, no debemos olvidar al usuario o destinatario final.

Más comentarios sobre el libro en cuanto avance la lectura.

HTML provee de un conjunto de elementos estructurales para definir citas. Una cita, según su acepción como mención es:

Recuerdo o memoria que se hace de una persona o cosa, nombrándola, contándola o refiriéndola.

Estructuralmente podemos definir tres tipos de citas:

• Un bloque extenso de texto referido desde algún texto, publicación o cualquier otra fuente externa
• Una referencia breve de un contenido de una fuente externa
• Una referencia a otras fuentes, sin citar necesariamente contenidos específicos

Estos tres tipos de referencia tienen su representación en HTML en los elementos blockquote, q y cite respectivamente.

Uno de los aspectos interesantes de estos elementos es el hecho de que el contenido que definen gana un valor semántico importante: cualquier procesador automatizado o cualquier persona que lea el código reconoce que estas estructuras se refieren a un contenido que está siendo referenciado. Es decir, reconoce el sentido y relación de este contenido respecto al documento.

Más aún, podemos utilizar el atributo cite para blockquote y q para indicar la fuente de destino en la forma de una URI. Es importante no confundir el atributo cite, propio de los elementos blockquote y q, con el elemento cite.

El ejemplo de la definición de la palabra cita que aparece poco más arriba, utiliza blockquote junto con el atributo cite para indicar la definición en el sitio de la RAE.

Una distinción más sutil es la que marca la diferencia entre los elementos q y cite. q, así como blockquote definen un contenido extraído de una fuente externa, sólo que en el primero se trata de un texto breve, contenido dentro de un párrafo u otro elemento de bloque. cite, en tanto, tiene como objetivo el definir una referencia, o más bien la fuente de una referencia. Un ejemplo de esto es:

El elemento cite está definido en la sección de Texto Estructurado de la Especificación de HTML 4.01.

Estos elementos permiten enriquecer el valor semántico de los contenidos, en tanto que al identificarlos según su estructura podemos presentarlos apropiadamente usando CSS.

¿Cuál es el objetivo de validar un documento (X)HTML? ¿Es acaso el comprobar que cumplimos 100% con la sintaxis del tipo de decumento, independientemente de la estructura de contenidos que éste tenga? ¿Vale la pena tener un documento que pase las pruebas automatizadas de validación independientemente de la estructura interna?

Yo creo que no . No creo que el espíritu de un estándar sea el que los documentos cumplan sólo formalmente con su sintaxis. En un post anterior planteé algunos aspectos de mi forma de enfrentar los temas de estándares y validación. Lo importante no es cumplir formalmente, sino utilizar la estructura que HTML o XHTML nos proveen para organizar y dar cuerpo a los contenidos.

Progresivamente podemos observar una proliferación de sitios utilizando correctamente DOCTYPE para definir los tipos de documentos, e incluso muchos utilizando XHTML. Esto es en parte debido al soporte de las herramientas de desarrollo así como también porque el tema está en el aire. Pero muchos de esos documentos que se declaran como XHTML utilizan una diagramación basada en tablas. Técnicamente es posible y el (X)HTML puede validar pero la estructura de los documentos es pobre y no describe realmente la jerarquía y relaciones internas del contenido.

¿A qué me refiero? El validador de HTML del W3 genera un outline que utiliza los encabezados del documento (los elementos h1 al h6) para representar la estructura de contenidos. Este tipo de análisis se basa en el reconocimiento de la estructura de los contenidos, que es relativamente fácil de extraer de un documento bien organizado.

Los elementos h1, h2, h3, h4 , h5 y h6 deben representar la estructura de un documento mediante la jerarquización de los contenidos. h1 es el título principal, por lo tanto su contenido es relevante para determinar de qué trata un documento. Por lo mismo, h2 determinará un contenido secundario, pero de mayor relevancia o peso que el contenido de h3. Evidentemente ningún analizador automatizado podrá extraer la estructura real de un documento que no use apropiadamente los encabezados.

Otros beneficiados del uso de elementos estructurales de XHTML son los buscadores. Para un robot indexador tiene mucho sentido reconocer la estructura de un documento mediante sus encabezados y otorgará un mejor ranking a aquellos contenidos que declaren su estructura explícitamente.

Tampoco es muy razonable utilizar recursos como <div id="titulo"> porque no representan realmente a la estructura.

Del mismo modo otros elementos determinan estructura dentro de un documento, un p es un párrafo, es decir, un conjunto ordenado de ideas relacionadas que termina en un punto aparte. Los contenidos de una tabla utilizada para contenidos tabulares reflejan una relación basada en los cruces de filas y columnas: una celda pertenece a una fila y una columna, esta relación le confiere un sentido especial.

Así, formalmente un documento puede pasar una validación automatizada, pero eso no significa que la sintaxis esté utilizada de modo apropiado para reflejar la estructura de los contenidos.

Desde hace ya varios años que me dedico a promover el uso de buenas prácticas en el Web y a incentivar el uso de estándares como XHTML y CSS. Los beneficios de utilizar los estándares son muchos y seguramente escribiré más adelante acerca de ellos. No obstante, mencionaré algunas ideas al rspecto. Estándares como CSS y XHTML además establecer un lenguaje común en el que todos nos podemos comunicar, en el que podemos confiar (poco más o menos) que los navegadores modernos respetarán de un modo razonable y que de paso facilita el trabajo a agentes de indexación (los robots) y otros procedimientos automatizados, nos permiten separar eficientemente el contenido y la presentación, el diseño visual.

Pero estas herramientas, que nos deberían simplificar la vida están implementadas y adoptadas de modo direferente y no somos nosotros (normalmente) los que controlamos el amplio universo en el que publicamos nuestros productos, léase contenidos, sitios, documentos, etc.

Es por esto que en momentos, en la vida real, aunque tengamos un compromiso grande con el respeto a los estándares, tenemos que tomar decisones que bajo cierta óptica pueden ser cuestionables. En efh yo puedo darme el lujo de ser estricto y controlar muchos aspectos, tomar desiciones autónomas y determinar qué técnicas utilizo, pero la vida no simepre es así. La idea es tener en el horizonte y como objetivo que el estándar es tal y las cosas deben ser así, y lo haremos en la medida que esto sea factible.

Cito un ejemplo: en una de las CSS de la Guía Web hay una propiedad, white-space a la que agregamos el valor pre-wrap, que es una definición propia de Microsoft para Explorer, por lo tanto no valida, para asegurar que este navegador desplegara correctamente lo que nosotros necesitábamos. El valor real, estándar es pre y lo agregamos mediante un hack sólo para los browsers estándar.

p.code {
white-space: pre-wrap;
}

h t m l >body p.code {
white-space: pre;
}

Todo el mundo recibe lo que quiere, sin que eso signifique un perjuicio muy grande. Ese es el único error de validación, es conciente y por razones concretas. Los browsers estándar reciben una versión estándar, Explorer recibe lo que necesita.

Podría citar otros ejemplos, pero creo que esto ilustra mi punto: lo importante es hacer el mejor esfuerzo de lograr la conformidad con los estándares, pero hasta que los navegadores sean 100% compatibles, tendremos que recurrir a trucos como esos. La idea es que sean los menos.

No quiero ser malinterpretado, yo soy tremendamente exigente respecto a estos temas, este sitio valida 100% sin errores y además es WAI-AAA (tengo algunos ajustes que hacer a este respecto, pero están en la lista de to-dos). Quienes me conocen lo saben, pero no soy integrista.

Moraleja: construye tus sitios considerando y respetando los estándares, pero no creas que el objetivo final es el estándar. Éste es sólo un medio, y en tanto el soporte real de los navegadores no sea el apropiado, habrá que procurar soluciones que se ajusten a la realidad.

Desde hace ya algún tiempo está al aire la Guía para el Desarrollo de Sitios Web de Gobierno. La iniciativa del Gobierno de Chile fue un esfuerzo que se basó en las conclusiones y experiencias de la primera versión del Premio Web. Su objetivo es el reunir una serie de buenas prácticas y recomendaciones que los sitios del Estado deben cumplir para asegurar un óptimo servicio a los ciudadanos.

Pese a que aún no ha sido presentada oficialmente, la Guía está disponibla para consulta y su recepción ha sido importante.

El Coordinador del proyecto fue Paulo Saavedra y el responsable de la edición Juan Carlos Camus. Mi papel en este proyecto fue construir el sitio de la Guía, que por su naturaleza debía cumplir con todas las recomendaciones del documento y ser muy respetuoso de los estándares, considerando entre otras cosas, accesibilidad. En este aspecto el sitio cumple con todas las guías de verificación automáticas y con una serie de los puntos de chequeo manual.

Nota: actualmente el sitio presenta un problema de validación en la portada producto del código de certificación de Certifica, que es un elemento ajeno al sitio. Esto se solucionaría próximamante.

Uno de los aspectos más interesantes de la construcción del sitio, al menos para mí que soy un maniático declarado de los estándares, es el uso meditado y cuidadoso de cada elemento o tag de XHTML. Los invito a anlaizar la estructura de los documentos que, naturalmente, confían la presentación a CSS. Una página en particular que me dió mucha satisfacción es el Glosario. Observen el cuidadoso uso de las listas de definición DL y de la lista de navegación alfabética al principio de la página.

Quedan otras cosas por revisar del sitio, pero la verdad es que necesitaré otro post completo para eso. Por ahora los dejo con la presentación, prometo una visita más detallada de los detalles de la construcción y las decisiones que fue necesario tomar respecto a estructura, presentación, estándares, etc.