Pero además, como quiero profundizar en este enfoque, que me parece sumamente interesante, he decidido crear un sitio ficticio que realmente muestre este concepto a fondo. El proyecto también me ha servido para experimentar más con HTML5 (y sacar mis conclusiones, que escribiré en este artículo). Las animaciones en CSS3 vienen de yapa con este artículo.

Este artículo es largo, y además de hablar sobre el Diseño Adaptable (una traducción gentilmente sugerida por José Kusunoki), también explica sobre el proceso de construcción de un sitio desde cero: desde bocetos en papel, pasando por conceptos en Fireworks, hasta el maquetado en HTML5 y CSS 3.

Espero poder escribir también sobre ciertos conceptos que andan dando vueltas en la web en inglés y casi nadie habla en español: Responsive Design, Design in the Browser, Progressive Enhancement, tipografías embebidas utilizando Typekit, grillas, etc.

Pero más allá de introducir las tecnologías y metodologías, reflexionaremos sobre lo que significan para nosotros en el día a día. De nada sirve leer un cómo, si no se entiende el porque.

Breve introducción al diseño adaptable

No es trivial reflexionar en que cada día mas y mas personas acceden la web desde dispositivos móviles. Hablamos de handhelds (un iPhone, un Android), o tablets (iPads, por ejemplo). Si pensamos que una visita puede generar una venta o conversión, es imprescindible entonces poder ofrecer una versión del sitio aunque sea mínimamente adaptada para pantallas pequeñas.

Hay varios enfoques para resolver este problema. El mas conocido tal vez sea diseñar el sitio con un layout líquido (o sea, que sus columnas estén definidas en porcentajes, y éstas se adapten al ancho de la ventana del navegador). Esto funciona hasta cierto punto, pero se complica cuando el tamaño de la ventana es extremadamente chico o muy ancho: algunos elementos se pueden cortar, o las proporciones pueden deformarlos.

El otro enfoque, con gran auge estos días y del que hablaremos en este artículo, es el diseño adaptable: optimizar el sitio, utilizando media queries, para ofrecer la mejor versión para el tamaño de la pantalla del usuario. Parece un tanto complejo, pero en la práctica no lo es.

En mi opinión, el diseño adaptable no se trata de una metodología de desarrollo: es un error pensar que todo se resume a sacar los float de los elementos y mostrar el contenido en una sola columna. En realidad, estamos hablando de optimizar los elementos de una página para el tamaño de la pantalla del dispositivo, pero sobre todo para las condiciones de uso de móviles.

Esto quiere decir que, si tenemos un sitio con un gran uso de imágenes, tal vez en un iPad éstas deban mostrarse mas prominentemente, y por lo tanto deban ser mas grandes que en su version desktop. O, que en un iPhone, el area para hacer clic deba ser mas grande para adecuarse al tamaño del dedo humano (una aplicación de la ley de Fitts, claramente).

No hay que olvidarse de las condiciones de los usuarios móviles: apurados, con muchas distracciones, generalmente requieren lo fundamental. Esto conlleva a hacer un serio análisis de lo que realmente importa en el sitio: ¿En el subte, apretado, con poca movilidad y tiempo, si el usuario está viendo mi sitio en un iPhone, que es lo imprescindible que debo ofrecer?

Como tantas cosas en la web, el diseño adaptable entonces es una mezcla de usabilidad, diseño de experiencia y algo de metodología de desarrollo.

Sobre el proyecto de ejemplo

El proyecto que vamos a diseñar servirá para mostrar trabajos de un negocio o un artista. Debe ser algo bastante general, que pueda adaptarse, con cambios mínimos, a diferentes tipos de mercados: de Negocios, Personal, de Fotografía, etc. Por lo tanto el énfasis, visualmente hablando, estará en las imágenes, aunque el diseño deberá ser lo suficientemente invisible como para dejar que el contenido sea lo mas importante.

Utilizaremos tipografías provistas por Typekit (en su momento hablaremos sobre esto también). Las imagenes de ejemplo serán de productos de Braun diseñados en la época de Dieter Rams. Rams es tal vez uno de los mejores diseñadores industriales de la historia, y comparto plenamente muchas de sus observaciones sobre lo que el diseño debe ser: funcional, simple, práctico, al punto.

El sitio estará fuertemente basado en grillas, que permitirán construir los templates mas rápidamente en forma modular: diseñaremos un sistema, no un sitio. Un sistema que funcionará tanto en un ambiente desktop, como en móviles o tablets.

Bocetos en papel y en el browser

Los bocetos en papel son importantísimos, porque permiten pensar ideas y desecharlas rápidamente, con costo prácticamente cero.

En diseño adaptable son indispensables: nos permiten pensar en los problemas que tendremos en las pantallas chicas, y por lo tanto, dibujar posibles esquemas de layouts que podríamos ofrecer. Yo personalmente trato de forzarme a bocetar mas y mas en papel y no pasar directamente al browser o Fireworks/Photoshop.

¿Pero cómo? ¿Bocetar en el browser?

Bocetar en el browser es mi adaptación a otro término en inglés con bastante hype el año pasado: Designing in the browser. Se trata ni mas ni menos de olvidarse de Fireworks/Photoshop y pasar a crear directamente las interfaces utilizando código, y un navegador para mostrar los cambios.

Aunque esto funciona para sitios relativamente simples, pequeños y poco funcionales, en la realidad es poco práctico: si hay un cambio drástico de diseño de experiencia, el trabajo puede ser frustante y duplicarse, al rehacer todo de nuevo.

Tal vez un ejemplo pueda aclarar esto. Imaginemos que tenemos un template en HTML, con los label de un formulario ubicados arriba de cada input. Pero por un análisis de usabilidad posterior, se deciden cambiar al costado de cada input, y esa será la versión final del sitio. Este cambio drástico generará un costo de maquetación muy superior al que se generaría al simplemente bocetar esto en papel desde el principio o en un mockup estático en Fireworks/Photoshop.

También limitan la creatividad: nos estaremos enfocando solamente en producir templates limitando el proceso de experimentación para “contar la historia”, o resolver el problema.

En cambio, parece ser que la única justificación para diseñar en el browser esté en el diseño de prototipos rápidos. Utilizando un buen framework de grillas y un set de módulos con componentes fácilmente reutilizables, podemos construir en pocas horas una aplicación para que posibles usuarios puedan testear rápidamente.

Esto es todo por ahora. En la próxima parte de este artículo hablaremos sobre frameworks de grillas (y explicaré el mío, que se usó para crear este sitio que están viendo), tipografía, prototipos y más diseño adaptable.

This post is written in Spanish: It covers the redesign of the HTML and CSS code for Taringa.net, a site with over 13 million page views daily. In this article, I explain how to save thousands of dollars a day by using simple web standards techniques to reduce the size of the homepage by 50%. A version of this article will be published in English in the coming days.

Luego de leer este artículo en Alt Tab, en donde se entrevista a Alberto Nakayama sobre el funcionamiento de Taringa.net, quedé bastante impresionado con la red de servidores y recursos que el sitio consume actualmente. Para un sitio como Taringa, con más de 13 millones de páginas vistas por mes, mantenerse optimizado es crucial, en el sentido en que esto implica una reducción en el ancho de banda que se consume, y por ende, en los gastos mensuales en servidores y su mantenimiento.

La gran pregunta es, ¿pueden los estándares web ayudar a minimizar los costos de funcionamiento de Taringa? En este post explico como optimizé la página principal, utilizando técnicas simples de estándares web, logrando reducir su tamaño en aproximadamente un 50%, de esta manera, ahorrando miles de dólares mensuales en servidores y su mantenimiento.

El problema

Una rápida inspección al código HTML de la página principal muestra que el sitio no parece tan optimizado como uno quisiera. Algunos puntos que pude identificar:

• H1, el elemento más importante de una página no está siendo usado. Este elemento se encarga de describir el título de la página, además de proveer valiosos keywords a los buscadores. Tampoco hay una jerarquía de cabeceras (H1, H2, H3) coherente.
• Semántica pobre. No se usan los elementos de HTML para describir el contenido correspondiente. Una lista de ítems, que lógicamente se marcaría con el elemento UL, en Taringa se reemplaza por una serie de DIVs. DIV se usa para describir una sección de una página —como una cabecera, por ejemplo, o un conjunto de elementos. UL, en cambio, se usa para describir una lista no ordenada de elementos, en el caso de Taringa, podríamos usar UL para describir los últimos posts enviados.
• Poca optimización para buscadores (SEO). Esto es claramente una consecuencia del punto anterior. Los buscadores aman el contenido, pero también un contenido bien marcado y elementos de HTML bien usados. Mientras más limpio sea el código de una página, mayor indexabilidad tendrá.

En promedio, la página principal de Taringa pesa 50KB. El sitio sirve más de 13 millones de páginas vistas por día, en un cálculo rápido, más de 600GB son transferidos por día (50KB x 13M = 620GB). Haciendo un cálculo rústico de 1GB = 1 dólar, nos revela que Taringa gastaría 600 dólares por día solamente en servir HTML.

Es bueno aclarar que en este artículo no voy a rediseñar la parte visual de Taringa. Hace un tiempo trabajé en Trade2Win.com, un sitio con alrededor de 2 millones de impresiones al mes, y aprendí que en sitios similares con mucho tráfico, las decisiones visuales deben hacerse con muchísimo cuidado porque repercuten directamente en los hábitos de uso de millones de usuarios.

Un retoque pequeño, y al parecer inofensivo, como cambiar el ícono de búsqueda por otro que al parecer funcionaría mejor, puede traer consecuencias desastrosas. Por lo tanto, solo me voy a enfocar en rediseñar el código HTML y CSS de la página principal del sitio, tratando de ser fiel al estilo visual del sitio lo más posible.

Optimización para buscadores

Una de las ventajas de diseñar con estándares viene de regalo: la optimización del sitio en buscadores. Los estándares (en este artículo hablamos solamente de HTML, CSS y JS) fomentan la semántica, y los buscadores en general valoran a las páginas semánticas sobre aquellas que no lo son.

La semántica, en pocas palabras, trata sobre el uso de un elemento determinado de HTML para describir el contenido para el que fue creado: por ejemplo, es lógico que el título de una página se marque con el elemento H1, ya que es el elemento más importante, pero en Taringa se lo reemplaza por una combinación de DIVs y As. Google, en todo caso, no podría encontrar el título de la página ya que no hay un H1 disponible, penalizando su posición en los resultados.

Ahora bien, el listado de últimos posts en la página principal es tal vez lo más interesante del sitio. Cada ítem se describe con un título y uno o dos íconos para una mejor identificación visual de la categoría. Éste es el código que se usa actualmente en Taringa para mostrar los últimos posts:

<div class="link">
<div class="link_titulo">
<span class="categoria arte" alt="Arte" title="Arte"></span>
<a href="" target="_self" title="Firmas A Pedido" alt="
Firmas A Pedido" class="box_link">Firmas A Pedido</a>
</div>
</div>

Claramente, es demasiado. Se usa un serie de SPANs para cada ícono, todo agrupado en un conjunto de DIVs, resultando en código no optimizado. Una propuesta, utilizando estándares web y marcado semántico, podría ser de la siguiente manera:

<li class="icon-art" title="arte">
<a href="">Firmas A Pedido</a>
</li>

Como vemos, cada ítem es marcado con su elemento correspondiente, LI. Luego, el atributo class se encargará de mostrar los íconos correspondientes para cada ítem, salvando preciosos bits y eliminando DIVs sin función.

Este enfoque semántico, del ejemplo, se extiende a toda la página, desde la lista de posts nuevos, hasta los posts más votados e incluso los avisos de Taringa.

De ahora en más, Google no interpretará la página principal de Taringa como una serie de contenido tirado sin descripción, ya que cada elemento ahora describe perfectamente su contenido, proveyendo mejor información para su clasificación e indexación.

Reduciendo la cantidad de pedidos al servidor

Alberto inteligentemente implementa CSS Sprites para mostrar los íconos en cada post. La idea es utilizar un archivo GIF con todos los íconos, en vez de 50 o más archivos separados, de esta manera reduciendo la cantidad de pedidos al servidor y disminuyendo la carga.

En este ejemplo, fuí un poco más allá y extendí el concepto para todas las imágenes del sitio, incluyendo los logos de Taringa/Google en la caja del buscador y los logos del pie de página. Los íconos de los sponsors también fueron optimizados.

Una propuesta de organización de íconos para Taringa

En total, contando íconos, logos y otras imágenes, Taringa usa 14 archivos GIF. Esta optimización de imágenes me permitió reducirlos a solamente 2. En números fríos, una reducción de más del 85% en pedidos al servidor.

Flexibilidad a prueba de balas

Una mención aparte se merecen las imágenes con bordes redondeados, por ejemplo, el marco contenedor de la página, y muy especialmente, las secciones o módulos de Taringa. Es demasiado frustante para un diseñador no tener otra alternativa que aplicar artilugios varios para poder mostrar un simple borde redondeado.

CSS es un lenguaje con muchas fallas, pero en mi opinión, esta es la más grave. Sin embargo, siempre se puede optimizar y simplificar.

A modo de ejemplo, para mostrar el marco contenedor del sitio, en azul, Taringa usa 2 imágenes diferentes (rtopbg.gif y maincontainerbg.gif), además de código no semántico en el HTML para mostrarlas. Aunque este enfoque es totalmente válido, todavía se puede utilizar una sola imágen, y eliminar los DIVs extra en el HTML para una mejor interpretación del documento. Con un poco de CSS luego nos encargaremos de mostrar los bordes de la imágen, ya sea superiores o inferiores, reduciendo los pedidos al servidor en un 50%.

Otros criterios de optimización se aplicaron para otras partes de la página. La clave, siempre, es simplificar.

Las secciones, o módulos de Taringa, requiren una explicación aparte. En el sitio actual, se usan 4 imágenes para mostrar los bordes redondeados: 2 para cada esquina, uno para el fondo del título del módulo, y una imágen para los bordes inferiores (que tiene bordes inferiores para los diferentes anchos de las cajas). Además, claro, de código HTML extra para mostrarlas.

En el ejemplo, aplique lo que se conoce como Progressive Enhacement para reducir el uso de imágenes para módulos de 4 a 1. De hecho, simplificando más aún, podríamos incluso no necesitar imágenes.

La idea básicamente es proveer una mejor versión del sitio para aquellos navegadores avanzados. En este caso, los bordes redondeados para los módulos utilizan una propiedad específica de Safari y Firefox (-webkit-border-radius y -moz-border-radius, respectivamente); sin embargo, los usuarios que naveguen con Internet Explorer igualmente podrán disfrutar del contenido y la funcionalidad del sitio.

La página principal de Taringa con zoom x4.

Especial atención se puso para que la página y su contenido luzca mínimamente bien (sobre todo legible) al aumentar el tamaño de texto, como pueden ver en la captura siguiente:

El ejemplo de este artículo con zoom x4.

El rediseño de Taringa es ahora indestructible y soporta cambios en el tamaño de texto para aquellos usuarios que lo necesiten, aumentando su accesibilidad.

Si en el futuro se necesita agregar más opciones en la barra de navegación, llegando a las dos lineas de texto, podemos ver que la caja contenedora no se romperá, aguantando cambios en el texto.

Conclusiones

Este es un ejemplo rápido sobre como se podría optimizar el HTML y CSS de Taringa para minimizar los costos en servidores. Como extra, se recodificó la página para una mejor semántica y optimización en buscadores. El resultado es una optimización de 50KB a 26KB en el tamaño del archivo HTML, es decir una reducción del 50%.

Por cuestiones de tiempo, el ejemplo solamente está probado y funcionando en Safari y Firefox. Pero a los fines prácticos, una implementación para las diferentes versiones de Internet Explorer no agregaría demasiados bytes al resultado final.

En números:

Los valores son estimativos.

Este enfoque de optimización se puede aplicar a sitios con mucha demanda de servidor. Por ejemplo, Meneame, Fayerwayer, Clarín y La Nación y demás.

Pueden ver el ejemplo funcionando aquí.

A continuación, contribuyo con un análisis visual y de código sobre el sitio, esperando que Cadena 3 tome estas sugerencias para mejorar.

El amor entra por los ojos

Visualmente, el sitio es pobre. Como no hay muchos espacios en blanco es dificil que a alguien le de placer leer el sitio. El contenido está muy junto, el diseño no respira y se extraña una buena grilla que dé más orden y separación entre los elementos.

Pero, el diseño no es terrible —como muchos piensan—; solamente faltan un par de toques y tal vez ampliar un poco más la paleta de colores. Me imagino que ese azul es un color institucional, por lo cual a los diseñadores no les quedó otra que usarlo en todas partes.

Los degradados están mal logrados: Parecen un descarte de algun sitio Web 2.0 hecho por un amateur. Me da la impresión de que usando degradados Cadena 3 quiere ser cool o ser Web 2.0 —si es así les faltó el reflejo en el logo—. Un poco más de sutileza y contraste ayudaría mucho a mejorar el diseño. No hay que inventar nada nuevo ni engancharse en ninguna moda estúpida, solamente seguir principios básicos del diseño gráfico.

Por otro lado, no hay una jerarquía de la información. Para mí, el Ranking de Radio Popular es tan o más importante que las noticias del día. El banner de Creativos Unidos tiene tanta o más importancia que el inmenso logo de Cadena 3. Miren por ejemplo la sección Bitácora de Audios: Yo, que solo escucho la radio cuando me subo a un taxi, no diferencio el El Chiki Chiki de Juntos.

Al igual que en el sitio de La Voz del Interior, el clima no es accesible a simple vista, el usuario tiene que hacer click y esperar a que se cargue otra página para saber un dato tán básico. Hubiera sido mejor ubicar un par de íconos y su descripción dentro del encabezado. Al menos, el enlace para consultar el clima está en la parte superior del sitio, en La Voz del Interior es inevitable presionar Cmd + F y luego tipear «clima» para que el navegador busque y resalte el enlace —que está en la última sección derecha del sitio!—.

Si todo es importante, entonces nada es importante

A simple vista, Cadena 3 tiene más contenido en la página principal que el New York Times. Y realmente no creo que produzcan más notas que la Gray Lady; el problema aquí es la pésima maquetación, el uso poco inventivo de la grilla —si es que hay alguna— y la política de encajar todo en la homepage. Está bien, para muchos cordobeses el cuartetero Damián Córdoba puede ser muy importante, pero dedicar más de 800 pixels de alto a una sección de rankings musicales —de dudosa calidad, o no— es demasiado.

En este sentido, separar casi 900 pixels de alto para las posiciones del campeonato futbolero es también curioso, y de hecho, me sugiere el tipo de audiencia de la cadena, más preocupado por saber como salió Instituto y por las ventas de La Fiesta, que de las noticias del país. Pero mejor evitemos las críticas tendenciosas y nos dediquemos a lo que realmente sabemos hacer: diseñar.

Podemos imaginar un mejor uso de la grilla para maquetar y disponer los elementos. Por ejemplo, para ahorrar los casi 600 pixels de alto de la columna Boletines Informativos, reemplazamos la lista de corresponsalías y redacciones por una lista desplegable. De esta manera reducimos el alto de esa sección a 150 pixels como mucho, 1/4 parte de la actual.

Fig. 1. Una propuesta para las secciones con mucho contenido.

Es más, con una pequeña cookie podemos recordar la opción que eligió el usuario y mostrar por defecto la corresponsalía que le interesa cada vez que entra al sitio. Las posibilidades son muchas y sólo observando como actúan los usuarios se pueden sacar grandes ventajas.

Por otro lado, podemos repetir el mismo enfoque en El Campo Hoy y otras secciones largas, de esta manera estandarizando muchos de los bloques de información del sitio y reduciendo la altura total.

Sería bueno también agrupar algunas secciones para que se muestren horizontalmente —al mejor estilo The Onion, fijensé la sección Features—. En este caso, por ejemplo, El Espectáculo, Estrenos y Ranking de la TV, podría agruparse en una sola sección Espectáculos y mostrarse horizontalmente. Clickeando en las flechas de izquierda o derecha, el usuario puede hacer aparecer el contenido que desee a gusto.

Tipografía

El uso de una buena fuente es primordial para un diario o publicaciones con mucho contenido. Fuentes bien escogidas permite evitar gastos innecesarios en papel, meter más caracteres en espacios reducidos y aumentar la legibilidad de las notas.

Generalmente se considera que las fuentes con buen ojo medio —la altura de la x minúscula— son mas legibles. Por otro lado, como el ojo no analiza cada letra individualmente, sino la palabra entera, se cree que las letras con serif —las terminaciones de cada letra— aumentan la legibilidad de un texto, ya que cada serif produce la ilusión de continuidad en el texto. «Así como yo puedo leer tu letra, vos también vas a poder leer la mía» diría Spiekermann en la película Helvetica, refiriéndose a la continuidad de los trazos al escribir con la mano.

Cadena 3 usa una tipografía sans-serif, Tahoma, en todo el sitio. En cualquier caso, el sitio está tan mal maquetado que si uno no tiene Tahoma instalada en el sistema —como en mi caso—, ve la tipografía por defecto del navegador, generalmente Times New Roman. Si Cadena 3 quería usar una tipo sans-serif, tendría que, al menos, haber dado otra alternativa sans-serif a Tahoma. Esto se puede hacer muy fácilmente en CSS usando algo similar a font-family: Tahoma, Arial, sans-serif. En este caso, el navegador buscará Tahoma, si no está instalada probará con Arial, y por último, en el peor de los casos, con cualquier tipografía sans-serif.

Aunque Times es una fuente probada y que funciona, la mancha de gris que produce en pantalla y en cuerpos muy pequeños —como lo hace Cadena 3— es poco homogénea. Mejor hubiera sido usar una tipografía especialmente creada para la web, como Georgia, con poco contraste —el contraste es la diferencia entre los trazos verticales y horizontales de una letra— y mancha más homogénea, aún en cuerpos pequeños. Mejor aún hubiera sido aumentar aunque sea un punto el cuerpo de las notas, ya que realmente son ilegibles.

Pero nos limitemos a tipos sans-serif. Todavía me sigo preguntando porque usaron Tahoma en vez de algo universal como Helvetica, para Mac, y Arial, en Windows.

Optimizado para IE 4.0

A mí, que navego con Safari y vivo en 2008, me parece sumamente graciosa y hasta inocente la afirmación de arriba. Más allá de lo visual, me llamó muchísimo la atención que un sitio lanzado en éstos días no haya sido maquetado siguiendo estándares web, aunque sea mínimamente. Y no me refiero solamente a no usar tablas —de hecho el «no uses tablas!» suena más a un argumento de alguien que toca de oído más que al de alguien que realmente sabe usarlas en algun contexto determinado de la vida real, como en formularios—, sino, a un pobre entendimiento de CSS y HTML para maquetar.

El código del sitio abusa de estilos en linea y prácticamente no reusa ninguna clase de CSS. No hay una clase noticia para mostrar cada post, entonces, estilizar una nota es un proceso individual y repetitivo que incluye hacer encajar la nota dentro de una celda de una tabla y luego jugar con elementos hiperdeprecados como font.

Todo esto, claro, se repite para cada nota.

En el futuro, cuando Cadena 3 quiera cambiar el estilo de las notas —digamos, aumentar en 1px el cuerpo de la tipografía— va a tener un problema grande.

Éste es el código que se usa en el sitio para mostrar una nota:

<table width="30%">
<tr>
	<td>
		<p style="margin-top: 0; margin-bottom: 0"><a href="post_ampliado.asp?post=480"><font color="#001242" style="FONT-SIZE: 20px" face="Tahoma">Sismo en Catamarca</font></a></p>
		</td>
</tr>
<tr>
	<td>
		<p class="destacado" style="margin: 5px"><font color="#800000" face="Tahoma"><b>17:54</b></font>
		<font face="Tahoma" color="#333333">Según datos del Inpres, el movimiento telúrico se registró a las 16.26 y tuvo epicentro a 40 km de la capital de Catamarca. El temblor tuvo una intensidad de 3 a 4 gradosº  en la escala Mercalli y una magnitud de 4,5 en la escala de Richter.</font>
	</td>
</tr>

<tr>
	<td width="100%">
		<table border="0" width="100%" id="table1280" bgcolor="#F4F4F4">
			<tr>
				<td width="16">
					<a href="javascript:popup('enviar',480)"><img alt="Recomendar por mail" border="0" src="http://www.cadena3.com/images/iconomail.gif" width="16" height="17"></a>
				</td>
				<td width="30">
					<a href="javascript:popup('enviar',480)"><font face="Tahoma" style="FONT-SIZE: 11px" color="#737173">Enviar</font></a>
				</td>
				<td width="16">
					<a href="post_ampliado.asp?post=480"><img alt="Comentar la nota" border="0" src="http://www.cadena3.com/images/iconocomentar.gif" width="16" height="17"></a>
				</td>
				<td width="47">
					<a href="post_ampliado.asp?post=480"><font face="Tahoma" style="FONT-SIZE: 11px" color="#737173">Comentar</font></a>
				</td>
				<td>
					<p align="right"><font face="Tahoma" style="FONT-SIZE: 11px" color="#151672"><a href="comunidad.asp?comunidad=6">Sociedad</a>   </font>
				</td>
			</tr>
		</table>
	</td>
</tr>
<tr>
	<td background="http://www.cadena3.com/images/lineagris.jpg" height="15"></td>
</tr>
<table>
 

Como pueden ver, no hay una separación clara del contenido (la nota) y la presentación (lo visual). Tampoco hay semántica: Google entiende que Sismo en Catamarca es un párrafo, cuando debería ser un título y la lista de enlaces «Enviar», «Comentar», «Sociedad», no es una lista, es simplemente contenido tirado en una celda que dificilmente será leído por un lector de pantalla.

Más allá de eso, este pedazo de código ocupa 4KB y se repite muchas veces en la página. Ahora imaginen la cantidad de dinero mensual en hosting que está perdiendo Cadena 3 por no optimizar un poco su código.

Éste es un mejor enfoque para maquetar una nota:

<div class="post">
	<h3><a href="">Sismo en Catamarca</a></h3>
	<p><span class="hora">17:54</span> Según datos del Inpres, el movimiento telúrico se registró a las 16.26 y tuvo epicentro a 40 km de la capital de Catamarca. El temblor tuvo una intensidad de 3 a 4 gradosº  en la escala Mercalli y una magnitud de 4,5 en la escala de Richter.</p>

	<ul>
		<li class="enviar"><a href="">Enviar</a></li>
		<li class="comentar"><a href="">Comentar</a></li>
		<li class="categoria"><a href="">Sociedad</a></li>
	</ul>
</div>

El título de la nota es un título en HTML, H3, el contenido, un párrafo P, y la lista de enlaces, bueno, una lista de enlaces, LI. Cada nota es un DIV con clase post. En el archivo CSS se estila la nota a gusto.

En el hipotético caso de que Cadena 3 decida aumentar 1px de cuerpo para las notas, solo tendrá que cambiar 1 sola línea en este archivo y no miles en cada noticia. Ni hablar de la reducción en el peso del sitio, que contribuirá a todo cargue mucho más rápido que los 40 segundos actuales —en algunas conexiones—. Pueden ver cómo se estiliza la nota original y cómo quedaría la nueva propuesta funcionando.

Conclusión

Realmente hay mucho que mejorar en el nuevo Cadena3.com. Desde la gráfica, que en mi opinión es solamente correcta, hasta la maquetación, que ya vimos que es pésima.

Espero que a la gente de Cadena 3 le haya servido este post para poder mejorar el sitio en un futuro. No es una crítica infundada y con mala leche hacia los desarrolladores y diseñadores, después de todo, las decisiones son tomadas por otros y uno es un simple diseñador —y todos estamos bien conscientes de qué tan difícil es remar con un cliente necio—, pero solo en la diversidad de opiniones se puede construir algo mejor.

Hay hacks de todo tipo y para todos los navegadores, buscando un poco en Position Is Everything tal vez puedas encontrar la solución a tu problema. Pero si no la has encontrado, todavía puedes usar el último recurso: * html.

Vamos por partes. El selector universal, representado por el caracter asterisco (*) selecciona todos los elementos del árbol del documento. Esto quiere decir que la siguiente regla:

* { color: red; }

Le asignaría el color rojo a todos los elementos del árbol del documento, sobreescribiendo así su herencia (Eric tiene un excelente artículo sobre el poder de los selectores universales). Así, cualquier elemento de un documento HTML tendría el color rojo asignado.

Ahora bien, volviendo a nuestro hack:

* html { }

Esta regla en CSS, quiere decir “aplica esta regla a todos los HTML hijos del elemento universal”, o lo que es lo mismo, “aplica esta regla a todos los HTML descendientes de *“, o “selecciona todos los HTML hijos/descendientes de todos los elementos”. Ahora bien, como HTML es el elemento root por defecto (es decir, es el elemento por el cual comienza el árbol del documento ), no selecionariamos nada, ya que HTML no puede ser hijo de ningún otro elemento. La regla entonces no tiene sentido, pero es válida en CSS y nos servirá para ocultar reglas a navegadores buenos y mostrarlas al navegador malo (IE), ya que cualquier regla empezando por * html, es interpretada por IE (lo veremos más adelante) y puede ser usada a nuestro beneficio.

Esta regla, aunque sencilla, puede prestarse a confusión. ¿Por qué decimos “selecciona todos los HTML hijos de *” y no “selecciona todos los HTML”, o en todo caso, “selecciona EL HTML”? Si estamos pensando en “selecciona todos los HTML”, estamos pensando en D.O.S., en donde poner un dir *.txt quiere decir “muestra todos los archivos .txt”. Aquí, el espacio en blanco hace la diferencia. Al tener el espacio en blanco, estamos aplicando selectores descendentes y el elemento universal se toma simplemente como eso, como el elemento que quiere decir “todos los elementos”. La clave es esa, el elemento * significa “todos los elementos”, y no “todos los elementos X”.

Volviendo al hack, Firefox y Opera simplemente ignoran cualquier regla que empiece con * html, sin embargo, IE la interpreta. Entonces, el siguiente código:

* html body h1 { color:blue; }

Es interpretado por Internet Explorer como html body h1 { color:blue; } (noten que no interpreta el asterisco) y el resultado sería que todos los H1 (hijos de BODY y obviamente de HTML) tendrían color azul. En Firefox y Opera, no pasaría nada.

El hack funciona siempre poniendo a BODY como elemento hijo de HTML y luego poniendo el elemento que queremos estilizar, es decir, poniendo siempre * html body mi-elemento, lo cual es lógico, pues según el árbol del documento, no hay elementos para dar estilo entre HTML y BODY, es decir, no podríamos poner algo como * html h1 (nos estaríamos salteando a BODY, lo cual es incorrecto, pero sin embargo valida perfectamente).. Funciona si se pone * html h1, no hace falta ser tan estrictos con el árbol del documento siempre y cuando respetemos qué elemento contiene a quién (gracias Fede).

Nota: No lo piensen mucho ni se descerebren como yo, según el blog de IE, este hack ya está deprecado. Pero quien sabe, hasta que salga IE7 todavía puede serles útil :)

Qué necesitas saber/tener para aprovechar al máximo estos artículos:

• Tener una copia de Wordpress 1.5 instalado en tu servidor personal o en tu hosting. Lo recomendable es hacer todas las pruebas en tu servidor web personal.
• Mínimos conocimientos de XHTML, CSS y PHP.
• Curiosidad por ver como funcionan las cosas y muchas ganas de sacar los vestigios de Kubrick de tu blog :)

Vá a ser un artículo realmente introductorio, apto para que cualquier persona curiosa —y con ganas de modificar su theme actual— pueda echar mano en el código y armar su propio theme para Wordpress. Sin más, empecemos entonces por ver lo primero: La anatomía de Wordpress.

La estructura de Wordpress

Wordpress tiene una forma bastante lógica de manejar las “caras” de los blogs. De hecho, ésta forma de armar un blog les será conocida a los que vienen programando sitios dinámicos. La idea es básicamente separar cada sección del blog en archivos independientes, de manera que cada archivo pueda modificarse como deseemos. Luego, cada archivo o sección del blog, podrá llamarse desde un archivo maestro para armar cada tema.

Este archivo maestro en Wordpress se llama index.php. Como veremos más adelante, este template (para no confundirnos, llamaremos así a los archivos de Wordpress que se usan para crear un tema) incluirá llamadas a los otros templates de cabecera, contenido, barra lateral y pie de página que conformarán el blog.

Además de estos templates fundamentales, Wordpress también tiene templates especiales para los comentarios, las categorías, los enlaces, los autores, los archivos del blog, la página de búsqueda y hasta para la página 404 (error que devuelve el servidor cuando no se encuentra una página determinada). Por otro lado, este CMS es también capaz de manejar páginas individuales para el blog. Esto nos permitirá, por ejemplo, manejar secciones (digamos, “acerca de”, “portfolio”, “contacto”, etc.). Si me estuvieron siguiendo, entonces ya se van dando una idea de donde radica el potencial de este sistema de publicación: Wordpress también puede ser usado como un perfecto CMS para sitios de propósito general, y de hecho, no tiene nada de que envidiar a sus primos más grandes como Drupal o Mambo.

Veamos gráficamente el árbol de directorios de una instalación clásica de Wordpress:

/
wp-admin
  	wp-content
		plugins
		themes
			classic
			default
	wp-images
		smilies
	wp-includes
…
…

En la raíz de una instalación de Wordpress encontramos los archivos de configuración del sistema de publicación, además de carpetas con funciones que luego serán usadas por el CMS (agrupadas en archivos con extensión PHP). La carpeta wp-admin contiene todas las funciones que se usarán en el panel de administración de Wordpress. En wp-images residen las imágenes que vienen con el CMS, (como ser los emoticones) y las imágenes que se usarán en el panel de administración (el logo del sistema, las imágenes de fondo). En wp-includes encontraremos las funciones que manejan los comentarios, los enlaces, y algo muy importante, las funciones que definen las etiquetas (tags) para armar los templates (veremos que son más adelante).

Dejamos para el último la carpeta wp-content, puesto que es la que más nos interesa. En ella deberemos incluir los templates que conformarán nuestro tema de Wordpress. Los templates de cada tema se agrupan en carpetas (fíjense que la instalación básica de Wordpress trae 2 temas por defecto, classic y default). Como no somos originales, nuestro nuevo tema será bautizado como “mitema”, por lo que crearemos una carpeta con ese nombre dentro del directorio themes.

Además, dentro de la carpeta wp-content, hay una sub-carpeta llamada plugins, que servirá como repositorio para la instalación de plugins para Wordpress. Un plugin permite personalizar el sistema agregando funcionalidades extra de una manera sencilla (basta copiar y pegar el plugin y activarlo desde el panel de administración).

En resúmen: Para crear un nuevo tema para Wordpress, el único directorio que nos interesa es /wp-content/themes/. En el estarán los templates que conformarán nuestro nuevo tema. Cada tema, tendrá su propia carpeta.

Esta fue la primer entrega. Mañana seguiremos explicando más sobre la creación de un tema nuevo para Wordpress. Cualquier duda, en los comentarios :)

Siguiendo con nuestra serie de artículos sobre desarrollo web orientado a estándares, en esta ocasión les explicaremos en que consiste XHTML, explicando paso por paso la estructura de un documento en este lenguaje.

El Extensible Hypertext Markup Language, o simplemente XHTML para los amigos, es una reformulación de HTML 4.01 pensada como una aplicación del lenguaje XML. Es decir, XHTML es una versión de HTML, con los mismos elementos y atributos, pero basada en la sintaxis y estructura de XML.

Al principio, HTML fue creado para el intercambio de documentos científicos a través Internet. Sin embargo, a medida que la web evolucionaba y se expandía más allá del campo científico/universitario, los requisitos de los desarrolladores web también crecían. La necesidad de un lenguaje de marcado para páginas web, que sea fácilmente extensible por medio de módulos y además interoperable con otras aplicaciones de XML, dio como resultado a la creación de la especificación XHTML 1.0.

Usar XHTML por sobre HTML tiene muchas ventajas importantes. El World Wide Web Consortium, entidad que se encarga de desarrollar especificaciones sobre las tecnologías que construyen la WWW, afirma que:

• XHTML es extensible. Esta es la principal ventaja sobre HTML. XHTML permite agregar nuevos elementos y atributos a través de la modularización, lo cual nos da la posibilidad de aprovechar las ventajas de otras tecnologías de desarrollo web, como MathML, y de las que se vayan a desarrollar en el futuro, como XForms.
• XHTML es accesible. Debido a su énfasis en la estructura de un documento y no en su presentación, XHTML es un lenguaje que tiene como objetivo el poder ser interpretado por cualquier dispositivo capaz de leer XML, ya sea un navegador o un teléfono celular.

Luego de esta breve introducción, pasemos entonces a ver el esqueleto de un documento XHTML, explicado en detalle paso por paso.

Anatomía de un documento XHTML

Si tenemos presente la estructura de un documento HTML, nos daremos cuenta que son muy similares a los documentos XHTML; de hecho, en XHTML no se han agregado elementos adicionales. Sin embargo existen un par de requisitos, que aunque no son complicados de entender ni de aplicar para el que está empezando en el diseño de sitios web, tal vez impliquen un cambio de mentalidad drástico para aquel que viene maquetando en HTML.

A continuación mostraremos la mínima expresión de un documento XHTML, para luego enfocarnos en aquellas diferencias propias de este nuevo lenguaje de marcado.


1. <?xml version="1.0" encoding="ISO-8859-1"?>
2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
4. <head>
5. <title>Documento simple en XHTML</title>
6. <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
7. </head>
8. <body>
9. <h1>Documento simple en XHTML</h1>
10.<hr />
11.<p>Este es nuestro <em>primer documento</em> en <acronym title="Extensible Hypertext Markup Language">XHTML</acronym>.</p>
12.</body>
13.</html>


Línea 1: La declaración XML. La primera línea indica al navegador que el documento que sigue está desarrollado conforme a la versión 1.0 de XML y que se basa en el juego de caracteres especificado en la norma ISO-8859-1. Es importante detenernos sobre este punto y aclarar que el World Wide Web Consortium recomienda, pero no obliga incluir ésta línea de código en todos nuestros documentos XHTML, puesto que está demostrado que muchos navegadores tienen problemas al momento de leer esta declaración, resultando en páginas que se muestran incorrectamente. Estos navegadores incluyen algunas versiones de los populares Internet Explorer y Netscape Navigator.

Es por esto que recomendamos no incluir esta declaración XML en nuestras páginas, por lo menos hasta que las versiones futuras de los navegadores más usados solucionen este problema. Un cuadro con información sobre los navegadores soportan esta declaración XML puede encontrarse en http://www.webstandards.org/learn/reference/prolog_problems.html.

Los lectores más despiertos se preguntarán entonces como especificaremos el tipo de contenido que estamos sirviendo y el juego de caracteres que usamos en nuestro documento XHTML. Para ello, agregamos la línea 6, la cual explicamos en detalle más adelante.

Línea 2: El DTD a usar. Un DTD o Document Type Definition, es simplemente una especificación de todos los elementos, atributos y entidades permitidos para un determinado tipo de documento XHTML o HTML. Esto significa que, según el DTD que estemos usando, tendremos a nuestra disposición un conjunto de elementos para usar al momento de codificar nuestras páginas web. Por ejemplo, el DTD de XHTML 1.0 en su versión estricta, elimina todos los elementos de presentación de un documento HTML. Esto quiere decir que sería inválido usar el elemento <center> en nuestros documentos XHTML con DTD estricto.

Esta declaración del DTD a usar en una página web, no es específica de XHTML; con HTML también debíamos especificar uno. Existen varias versiones de DTDs para XHTML, e incluso también podríamos crear un DTD propio para luego utilizar en nuestros documentos. El World Wide Web Consortium, define 3 tipos de DTDs, los cuales son:

• Strict. Es el DTD más rígido que podemos usar. En este DTD, todos los elementos de presentación , como <font> o <center>, son eliminados y por consiguiente no es posible utilizarlos en nuestros documentos. Por lo tanto, para controlar los elementos de presentación de nuestro documento, como la asignación de colores y el posicionamiento de elementos, deberemos utilizar CSS. La línea que especifica que un documento XHTML es estricto, es la siguiente:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

• Transitional. Es un DTD un poco más flexible que el anterior. Contiene algunos elementos de presentación, por ejemplo, el elemento <center>. Está pensando para aquellos desarrolladores que están haciendo el cambio hacia un DTD estricto, pero que todavía no tienen suficiente experiencia con CSS. Si deseamos especificar que nuestro documento XHTML es del tipo transicional, deberemos introducir la siguiente línea:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

• Frameset. Es el DTD que debemos incluir cuando estamos creando sitios web que incluirán frames o marcos. Para ello, la declaración DOCTYPE es la siguiente:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">


Ahora bien, ya vimos que tenemos varios sabores de DTDs en XHTML. La pregunta del millón es, ¿Cuál deberíamos usar para nuestros sitios web? Aquel que nos asegure en un 100% la premisa de separación del contenido de un sitio de su presentación. Recordemos: El concepto clave detrás de todas estas nuevas tecnologías de desarrollo web es la separación del contenido de su presentación. Es por esto que el único DTD que nos garantiza alcanzar esta premisa, es el de XHTML estricto, el cual no incluye ningún elemento de presentación en su especificación, obligando a que todo el aspecto visual de nuestra web sea necesariamente controlable utilizando CSS.

Volviendo a nuestro ejemplo, a través de la declaración DOCTYPE en la línea 2, especificamos que el documento usará los elementos, atributos y entidades declarados en el DTD de XHTML 1.0 estricto. Recordemos que esta declaración DOCTYPE es sensible a mayúsculas y minúsculas y que además debe ir en la primera línea de nuestro documento, después de la declaración XML (si es que la estamos usando).

Línea 3: El elemento . En XHTML, ahora el elemento raíz requiere que especifiquemos obligatoriamente de:

• El espacio nominal de los elementos. En XML, evitamos la ambigüedad en los nombres de los elementos usados agrupándolos en espacios nominales. Al especificar el atributo xmlns apuntando al espacio nominal de XHTML le decimos al navegador que los elementos que siguen son de XHTML y no de otro lenguaje basado en XML, como por ejemplo MathML.
• El idioma. A través de la combinación de atributos xml:lang (propio de XML) y lang (propio de HTML), definiremos el idioma en el cual está escrito el texto de nuestro documento, en nuestro caso, español.

Línea 6: El tipo de documento y el conjunto de caracteres usado. Como habíamos nombrado anteriormente, la declaración XML nos servía para especificar el conjunto de caracteres usado por un documento. Pero recordemos que al incluir esta línea de código, también llamada el XML prolog, nos llevaba a tener problemas con la mayoría de los navegadores, por lo que decidimos omitirla. Ahora bien, ¿cómo le decimos entonces al navegador el juego de caracteres que estamos usando en nuestro documento? Es aquí en donde entra en escena el meta tag http-equiv, el cual especifica el tipo de contenido que estamos sirviendo (en nuestro caso text/html) y además el juego de caracteres usado (ISO-8859-1). Es importante recordar que si no vamos a poner la declaración XML de la línea 1, deberemos especificar obligatoriamente el tipo de contenido del documento y el juego de caracteres del mismo a través de este meta tag.

Líneas 9, 10 y 11: Diferencias con HTML. XHTML heredó de XML dos características interesantes, que a simple vista lo hacen parecer más estricto que HTML:

• El documento XHTML debe ser válido. Incluyendo la declaración DTD que deseemos, y limitándonos a sólo los elementos especificados en ese DTD, cumpliremos fácilmente con este requisito. De cualquier manera, podemos comprobar si nuestro documento es válido con la herramienta de validación provista por el World Wide Web Consortium, explicada en detalle mas adelante.
• El documento XHTML debe estar bien formado. Esto quiere decir que debemos abrir y cerrar los elementos de manera correcta y en orden. Un ejemplo de dos líneas de código XHTML mal formadas:
  <p>Este es nuestro <em>primer documento.</p></em>
<p>Este es nuestro <em>primer documento.</em>
  Y a continuación, la misma línea de código respetando esta restricción de XHTML (Noten que el primer elemento en abrirse es siempre el último en cerrarse):
  <p>Este es nuestro <em>primer documento.</em></p>

  Por otro lado, XHTML requiere que todos aquellos elementos que no tienen contenido, como <img /> o <hr />, deben cerrarse agregando una barra invertida al final. Por ejemplo, a continuación pueden ver el elemento <img /> en XHTML (noten el espacio obligatorio entre el nombre del elemento y la barra invertida):

  <img src="mi-imagen.png" alt="Mi imagen" />

Además de lo nombrado anteriormente, un documento XHTML:

• Tiene sus elementos y atributos escritos en minúsculas. Recordemos, XHTML es una aplicación de XML, el cual es sensible a las mayúsculas y minúsculas, por lo tanto, el elemento <p> no es lo mismo que el elemento <P>.
• Encierra los atributos de sus elementos entre comillas. Todos los atributos necesariamente deben ir entre comillas, incluso aquellos que son numéricos. Ejemplo:

  <acronym title="Extensible Hypertext Markup Language">XHTML</acronym>
<td colspan="2">

• No soporta minimización de atributos. En HTML, el siguiente código es válido:
  <option selected>
  En cambio, en XHTML, los atributos de un elemento deben ser escritos completamente, por lo cual, la línea anterior en XHTML quedaría como:
  <option selected="selected">

Como vemos, la estructura de un documento XHTML puede parecer, al principio, más estricta que la de un documento HTML. Esto es debido a que XHTML, al ser una aplicación de XML, hereda de este lenguaje su énfasis en la estructura del documento. La idea detrás de estas restricciones es que, una vez que tenemos la estructura de un documento bien formada, ya sea XML o XHTML, cualquier parser o navegador podrá entender el significado del mismo.

Validando nuestro código XHTML

Por validación entendemos la acción de verificar que nuestro documento XHTML cumpla con la sintaxis estándar especificada en un DTD. Ahora bien, si al parecer, una página web se muestra correctamente en un navegador, incluso sin especificar un DTD, ¿porqué entonces debemos validar nuestros documentos? Daremos dos razones que pueden ayudar a entender la necesidad de la validación:

• Lo que uno está viendo no es lo que otros ven. Tal vez nuestro sitio web puede estar mostrándose correctamente cuando lo probamos con nuestro navegador preferido, pero en la práctica, muchos navegadores interpretan un sitio de maneras diferentes. El único modo de asegurarnos que nuestro sitio web será mostrado de la forma en que deseamos en todos los agentes de usuario disponibles, es a través de la validación de nuestro código XHTML.
• Evitar el Quirks Mode. Por definición, cuando el navegador no encuentra una línea de código especificando un DTD a usar en el documento, entra en un estado que se llama Quirks Mode. En este estado, el navegador interpreta que la página web puede contener cualquier conjunto de elementos HTML y XHTML, desde elementos correctos hasta incorrectos, y por lo tanto, cambia su motor de renderizado de páginas al de corrección de errores. Este modo a “prueba de fallos” tiene varias deficiencias, una de ellas, es que hace más lento el proceso de carga de una página web, debido a que el navegador tiene que ir corrigiendo el código a medida que lee la página.

La validación de nuestros documentos XHTML se realiza a través de una herramienta de libre acceso, provista por el W3C, y disponible en http://validator.w3.org/. Simplemente ingresaremos la URL del sitio a verificar en un formulario, o bien, subiremos el archivo XHTML desde nuestra PC. Una vez especificada la fuente, la herramienta procesa el documento y devuelve la cantidad de errores encontrados, junto con una pequeña explicación de los mismos y la forma de corregirlos.

Conclusión

Aunque XHTML puede resultar un tanto estricto al principio, el proceso de conversión de HTML a XHTML no es complicado. Existen herramientas de libre uso, como HTML Tidy (ver recuadro “Herramientas útiles”) que “limpian” el código HTML, simplificando la conversión de grandes sitios y páginas web.

El mundo actual de desarrollo de soluciones pensadas para la web, nos muestra una clara tendencia hacia la estandarización y hacia al uso de XML como lenguaje universal de definición de datos. El lenguaje por defecto de marcado para páginas web, HTML, fue repensando con miras hacia XML. En nosotros radica aprovechar todo su potencial.

XHTML, CSS, DOM; siglas muy populares en weblogs y que empiezan a resonar en portales y grandes sitios: Juntas forman lo que se conoce como Estándares Web. En esta nota, veremos de qué se trata este nuevo concepto que está revolucionando Internet y delineando la forma de desarrollo web del futuro.

Es 1997. Estamos en medio de una loca guerra de navegadores, una carrera sin límites en la cual Internet Explorer y Netscape Navigator compiten arduamente por dominar el creciente mercado de internautas.
En un movimiento poco inteligente por sacar ventaja a la competencia, y en un intento de brindar mas herramientas para mejorar e innovar la gráfica en los web sites de esa época, ambas compañías anuncian que ofrecerán características especiales a los desarrolladores web: Elementos HTML propietarios que sólo serán interpretados por un navegador u otro, exclusivamente, desobedeciendo así a cualquier intento de estandarización de código que existiera en la fecha.
Entonces empiezan a surgir sitios con textos en marquesina que en Internet Explorer andan perfectamente, pero que en Netscape Navigator no se ven. Al revisar el código HTML de un sitio vemos etiquetas <font> que parecen renderizarse bien en un navegador, pero que no se interpretan correctamente en el otro.
Y así comienza el caos, con una enredada trama de tags y elementos propietarios que se comportan de una manera determinada en el navegador para el cual fueron hechos, pero que no sirven en el otro.
Conclusión: La tarea del desarrollador web se hace compleja, laboriosa, y muchos se inclinan por el navegador que más elementos HTML “atractivos” le ofrece al desarrollar. El mercado se fragmenta, la web se fragmenta y la interoperabilidad entre diferentes tecnologías y navegadores desaparece.
Pero pasan los meses y nos vamos dando cuenta que esta manera de desarrollar la web no es la adecuada. Vemos que mantener 2 versiones de un sitio, una para cada navegador no es rentable. Que nuestros costos en desarrollo web aumentan a medida que queremos introducir mejoras en sitios con base poco firme y con código que es imposible de mantener.
Y aquí aparece el antídoto, la bala de plata que promete unificar la web, a través de un modelo abierto de conectividad entre tecnologías de desarrollo: Los estándares web.

¿Pero qué son los estándares web?

Básicamente son un conjunto de tecnologías, impulsadas por el World Wide Web Consortium (W3C) y otros organismos, que tratan sobre la manera en que se debe –o debería- crear el contenido basado en la web. El W3C (http://www.w3.org/) es el principal comité internacional que se encarga de reglamentarlos, a través de especificaciones, guías y recomendaciones, pero hay grupos en todo el mundo, como el Web Standards Project (http://www.webstandards.org/), que se encargan de promover y fomentar su uso.

Específicamente, los estándares web se pueden clasificar en 4 categorías, cada categoría agrupa una o más tecnologías de desarrollo:

1. Lenguajes estructurales o contenido:
   • XHTML (Extensible Hypertext Markup Language)
   • XML (Extensible Markup Language)
2. Lenguajes de presentación:
   • CSS (Cascading Style Sheets)
   • XSLT (Extensible Stylesheet Language Transformations)
   • SVG (Scalable Vector Graphics)
   • MathML (Mathematical Markup Language)
3. Modelos de objetos:
   • DOM (Document Object Model)
4. Lenguajes de scripting:
   • ECMAScript 262 (la versión estándar de JavaScript)

En la práctica se suele decir que los estándares dividen un sitio en 3 partes: Su estructura (XHTML), su presentación (CSS) y su comportamiento (JavaScript).

¿Para qué nos sirven?

Llegas cansado del trabajo, y te decides por ver una buena película. Alquilaste un DVD excelente; por lo que te contaron, la última joya del cine, algo imperdible. Lo introduces en tu DVD-Player, y de repente, tu equipo muestra un “Lo siento, para ver este DVD necesitas una pantalla de 30 pulgadas wide-screen” en tu televisión. ¿Decepcionante, verdad?

En la web, la escena anterior también se repite. Ocurre cuando entramos a un sitio y se nos pide un determinado navegador para continuar. O peor aún, cuando nos recomiendan navegar con determinada resolución de pantalla, pues a la gente que desarrolló el sitio les pareció que se veía mejor en 1280×960px.

Es aquí en donde entran en escena los estándares web. Los estándares nos garantizan la compatibilidad con todas las plataformas y todos los agentes de usuario (navegadores, lectores de pantalla para gente ciega, celulares, etc.) que existan. Esto quiere decir que al menos el contenido del sitio, será igualmente accesible por alguien que esté usando la última versión de Mozilla Firefox, como por alguien que esté usando Lynx.

Desarrollar con estándares tiene muchas ventajas

En general, la mayoría de los beneficios de usar estándares web parten de la premisa de separación de contenido, en XHTML, y presentación, en CSS. Entre algunas, de las muchas ventajas, podemos nombrar que los estándares:

• Optimizan un sitio para motores de búsqueda (SEO). Desarrollar con estándares produce código XHTML limpio y semántico. Puesto que la mayoría de los buscadores trabajan indexando el contenido de un sitio, éstos tienden a priorizar a aquellos sitios con menor cantidad de código basura o no estándar en el sitio.
• Producen un sitio fácil de mantener. El código resultante de un sitio con estándares es simple y se puede dividir en secciones, reduciendo la dependencia de un solo desarrollador y facilitando la comunicación entre varios grupos de trabajo en una empresa de desarrollo web (programación, maquetado, diseño, etc.).
• Reducen el tamaño del sitio. Debido a la eliminación de elementos HTML que formatean visualmente una página, agrupando toda la parte visual en CSS, el tamaño de un sitio se reduce drásticamente. Esto nos garantiza que el sitio será cargado rápidamente aún en conexiones lentas, como celulares.
• Son un paso necesario para la accesibilidad. A nivel dispositivo, los estándares aseguran que el contenido de nuestro sitio estará disponible para cualquier dispositivo con conexión a Internet. A nivel personas, implica tener en cuenta que nuestro sitio puede estar siendo accedido por personas con discapacidades, ya sean físicas (discapacidad visual, motriz, etc.) o de entorno o (sin mouse, con pantallas demasiado chicas, etc.).
• Otorgan mayor flexibilidad al desarrollador web. Esto permite a los desarrolladores, por un lado, ocuparse solamente de la parte estructural del sitio (XHTML) y por otro lado, a los diseñadores nos da la versatilidad suficiente como para cambiar cualquier aspecto del diseño de un sitio. Como ejemplo, Wired Magazine (http://www.wired.com) cambia el esquema de colores de su sitio todas las semanas, y para hacerlo modifica solamente una línea de código en su XHTML.

Y también tiene un par de implicaciones

Lamentablemente el desarrollar sitios con estándares conlleva un precio. La interpretación de CSS como lenguaje de presentación en muchos navegadores, todavía es bastante mala y lleva a que cada uno tenga sus propios quirks o caprichos, que el desarrollador web debe conocer al realizar un sitio.

El caso más conocido es de Internet Explorer, el navegador usado por el 90% de los internautas del mundo, y el cual es totalmente deficiente en su interpretación del modelo de cajas de CSS (por citar uno de los cientos de bugs encontrados).

Por otro lado, la curva de aprendizaje de XHTML y sobre todo, de CSS, puede llegar a ser muy empinada para algunos diseñadores web de la “vieja escuela”, aquellos que todavía siguen maquetando sus sitios con tablas y llenando su código HTML con elementos de presentación (el elemento <font>, por citar uno).

Podemos resolver el primer problema consultando blogs y listas de correo con información sobre los últimos hacks encontrados para cada navegador. Por ejemplo, Ovillo es una lista de correo en español en donde se discuten acaloradamente temas sobre CSS y estándares web.

Para el segundo problema, lo única solución es capacitarnos. Enseñar a los profesores de universidades, que hay un nuevo y mejor método de construir la web. Y enseñar a nuestros colegas, que el mercado demanda sitios hechos con estándares web.

La repercusión de los estándares en el mundo

En el mundo, la proliferación del uso de los estándares para el desarrollo web, a nivel masivo, ciertamente empezó con el rediseño del sitio de la revista norteamericana Wired, en Octubre de 2002. El “caso Wired”, fue la prueba definitiva para los estándares web. Aquella que los llevaría a convertir su teoría en aplicaciones concretas del mundo real.

Luego, el mundo de los blogs, o la blogósfera, se encargó de diseminar la semilla. Jeffrey Zeldman, pionero, escribió largo y tendido sobre las ventajas de usar estándares web para la separación de contenido y presentación. Zeldman también fue el primero en escribir un libro orientado específicamente en el diseño web con estándares, camino que luego seguirían otros autores, como Dan Cederholm, con “Web Standards Solutions” y Dave Shea, creador de CSS Zen Garden, con “The Zen of CSS Design”.

Y la lista de sitios que migran hacia los estándares, continúa creciendo: Fast Company (http://www.fastcompany.com), ESPN (http://www.espn.com), Macromedia (http://www.macromedia.com), son solo algunos de los peces grandes que entienden el beneficio de los estándares web.

En Latinoamérica tampoco nos quedamos atrás

El uso de los estándares está muy difundido entre las empresas de desarrollo web del primer mundo, y en Latinoamérica también están pisando fuerte. Rediseños orientados a estándares y enfocados en la accesibilidad para personas discapacitadas, como el del diario La Nación (http://www.lanacion.com) iluminan el camino de los desarrolladores web hispanoparlantes y son un ejemplo a mostrar a posibles clientes.

Los blogs en español también se encargan de apoyar el movimiento por los estándares. Por citar un ejemplo, Juan Hurtado, en Armonía (http://armonia.spiral-static.org), escribe diariamente sobre desarrollo web, enfocándose en temas como los estándares web, la semántica y la accesibilidad.

En el futuro

En el futuro, los hacks y quirks propios de cada navegador serán cosa del pasado. Microsoft ha escuchado las plegarias de los desarrolladores web y con la nueva versión de Internet Explorer, es decir, la versión 7, promete ampliar enormemente su interpretación de CSS.

Por otro lado, Macromedia ha mejorado su soporte para CSS en Dreamweaver, y de esta manera está logrando posicionarse en la mente de los desarrolladores que buscan una suite enfocada en los estándares web.

Hoy en día, hay una clara tendencia al desarrollo web “responsable”, aquel que se basa en las premisas de compatibilidad futura y accesibilidad para todos los usuarios y dispositivos, esto es, las bases del desarrollo web con estándares.

Y dentro de muy poco tiempo, aquellas empresas de desarrollo web que no se den cuenta que los estándares llegaron para quedarse, y que no son solo una opción mas, no serán rentables y competitivas en un mercado que cambia día a día.