Ya vimos que la estructura nos proporcionaba una base sólida, flexible y liviana para diseñar nuestras páginas. Mediante metáforas intenté explicar ese concepto que es generar “código estructural“. En resumidas cuentas no es más que una idea, un método de trabajo. Estructuramos nuestos contenidos mediante marcado puro, no contaminado por estilos. Algo así:
<div id="cabecera">
<ul id="menu">
<li><a href="#">apartado1</a></li>
<li><a href="#">apartado2</a></li>
<li><a href="#">apartado3</a></li>
</ul>
</div>
<div id="contenido">
<h1>Título</H1>
<p>Contenidos...</p>
</div>
<div id="pie">soy el pie</div>

Este otro código también sería estructural:
<table width="200" border="1">
<tr id="cabecera">
<td><a href="#">apartado1</a></td>
<td><a href="#">apartado2</a></td>
<td><a href="#">apartado3</a></td>
</tr>
<tr id="contenido">
<td colspan="3">
<strong class="título">Soy un titulo</strong>
Mi contenido
</td>
</tr>
<tr id="pie">
<td colspan="3">
Yo soy el pie
</td>
</tr>
</table>

Como veréis no usamos marcado de presentación, todos los estilos se aplicarían a través de los id en una hoja de estilos. Eso implica que tengamos sólo estructura. Sin embargo, hay una diferencia considerable con el otro código. Carece totalmente de carga semántica.

La estructura es el método, la semántica “el Fin”, nuestra meta. La idea no es validar el código para demostrar lo bien que sabemos maquetar. La idea es alcanzar niveles mínimos de accesibilidad (tema del que también hablaremos en este blog). Para ello es imprescindible que los tags que engloban nuestro código tengan implícito un valor semántico que dé significado específico a nuestros contenidos. Y ese es básicamente “el concepto”.

Si nos fijamos en el menú, veremos que en nuestro primer código está definido como una lista de enlaces mientras que en el segundo está ubicado como contenido tabular, cosa que no es. Y lo mismo sucede con el título. Al aplicarle el tag <h1> le estamos diciendo que ese contenido es el título principal de la página.

El motivo de todo esto es que lectores de pantalla y otros dispositivos específicos para usuarios discapacitados o incluso muchos navegadores para dispositivos de pantalla pequeña, hacen uso de esa información para renderizar o sintetizar mediante voz cada contenido. Por no hablar del uso que hace el propio Google, así como el resto de buscadores, para indexar nuestros contenidos.

Dicho esto creo que queda clara la importancia de generar código semántico y el significado del propio concepto. Sin embargo, sentiros libres de preguntar cualquier duda que tengáis al respecto.

Un saludo y espero leeros por aquí.

Pensemos en el escultor, concentrado en la forma, en la belleza, en los detalles de su magnífica obra de 30MB de peso, orgulloso de su creación, una creación que nunca podrá sacar del taller porque no le cabe por la puerta. Bien, pues no pensemos más en ello, porque es una imagen bastante deprimente, pensemos cómo evitar eso.

Qué haría el ingeniero para evitarlo?

1. Pues lo primero separar estructura de estilo en la producción.
2. Contratar especialistas para cada una de las tareas, nada de chapuzillas multiusos (frontpage, fireworks…).
3. Contratar a un buen capataz para que dirija la construcción de la pieza.
4. Conseguir los mejores materiales y si los que hay en mercado no se adaptan, diseñarlos para ésta y próximas piezas.

Aclaremos esto un poco. Si nuestra obra fuese una gran escultura de dimensiones desproporcionadas, no es que no nos sirva el escultor, él nos hará el boceto, una reproducción en miniatura de lo que debe ser la obra una vez finalizada. En Web ese sería el trabajo del diseñador.

Ahora ya tenemos el diseño. Si fuésemos una empresa es posible que tuviésemos un diseñador, un maquetador y un programador. Pero como es muy posible que nosotros mismos tengamos que hacer todo, dividamos nuestras conciencias. Ya hemos terminado el diseño, bien dejemos nuestro lado artístico que descanse y se tome unas piñas coladas. Y saquemos nuestro capataz para que dirija la obra, extraigamos el maquetador que hay en nosotros, que es quien conseguirá que la obra sea tal como la concebimos al mismo tiempo que sigue los planos del ingeniero y dirige a los trabajadores. Cuales serán nuestros albañiles y alicatadores? bien aquí es donde entran XHTML y CSS. Obreros especializados cada uno en su disciplina.

Cómo crear código estructural?

Para crear código estructural deberemos olvidarnos del aspecto final de la obra. Sí, habéis oído bien. Olvidar los colores, los tamaños de los marcos de las puertas e incluso del tamaño de nuestras estancias. Porque nuestra estructura tiene que ser flexible para poder ser no una sino muchas obras artísticas. Os acordáis del cubo de Rubik y la serpiente que convertíamos en una esfera, en una cobra, en un perro… Bien pues más o menos esa es la idea, que podamos girar nuestras piezas y cambiarles el color y la disposición en el espacio para que el año que viene podamos modificarla y siga las tendencias del momento sin que eso implique hacer una obra nueva.

XHTML es un gran albañil, dispone de las mejores herramientas para crear los cimientos y el esqueleto de nuestra Estatua de la Libertad. A diferencia de HTML4, que permite mezclar ambas cosas, XHTML sólo crea estructura dejando a CSS que termine la obra una vez él ha finalizado su parte.

Os preguntaréis a qué corresponden los materiales en maquetación. La respuesta a esto está en la semántica y las clases css. La combinación de elementos y atributos CSS, así como las nuevas técnicas serán nuestros materiales y herramientas.

Después de tanto símil, metáfora y comparación, imagino que todos estaréis pensando y quién o qué es el ingeniero en Web, qué hace? cuales son los planos? La respuesta a esto os la daré en un próximo artículo.

En próximos artículos también definiremos prácticas y metodologías del código estructural y entraremos en el concepto de semántica.

Que ustedes lo estructuren bien