Capítulo 2. Los materiales

A riesgo de enseñar a la abuela a chupar huevos 19, quiero que pienses sobre qué pasa cuando un navegador analiza gramaticalmente un elemento HTML. Toma, por ejemplo, un elemento de párrafo con algún texto dentro. Hay una etiqueta de inicio P, una etiqueta de finalización P, y entre ambas, está el texto.

<p>Texto</p>

Los materiales

Un navegador web que se encuentre este elemento mostrará el texto entre las etiquetas de inicio y de final. Ahora considera qué pasa cuando el mismo navegador web encuentra un elemento que no reconoce.

<marklar>Otro texto</marklar>

Otra vez, el navegador muestra el texto entre las etiquetas de inicio y de final. Lo que resulta interesante aquí es lo que el navegador ‘no hace’. El navegador no lanza un error. El navegador no para de analizar gramaticalmente el HTML en este punto, negándose a seguir. En su lugar, simplemente ignora las etiquetas y muestra el contenido interior.

Esta actitud liberal ante los errores permitió al vocabulario HTML crecer desde los 21 elementos originales a los 121 elementos que tiene HTML5 20. Cuando se introduce un nuevo elemento HTML, sabemos exactamente cómo lo tratarán los navegadores antiguos; ignorarán las etiquetas y mostrarán el contenido.

Es una característica muy potente. Permite a los navegadores implementar nuevas características HTML a diferentes ritmos. No tenemos que esperar a que cada navegador reconozca un elemento nuevo. En su lugar, podemos empezar a utilizar el nuevo elemento en cualquier momento, seguros de que los navegadores que no lo soporten no entrarán en conflicto con él.

<main>Este texto se mostrará en cualquier navegador</main>

Si los navegadores web tratan todas las etiquetas de la misma forma – mostrando sus contenidos – entonces, ¿cuál es el motivo de tener un vocabulario de elementos en HTML?

 

El significado del marcado

Algunos elementos HTML carecen literalmente de significado. El elemento SPAN no dice nada acerca de su contenido. Tan lejos como concierne al navegador web, podrías utilizar en su lugar un elemento MARKLAR inexistente. Pero esa es la excepción. Algunos elementos HTML existen por una razón. Han sido creados y acordados para que sean tenidos en cuenta en situaciones específicas en las que autores como tú y yo queremos encontrar.

Obviamente, hay elementos especiales, como el elemento A, que están provistos de superpoderes. En el caso del elemento A, su superpoder reside en el atributo HREF que nos permite vincular con cualquier fuente de la web. Otros elementos como INPUT, SELECT, TEXTAREA, y BUTTON tiene sus propios superpoderes, permitiendo a la gente introducir datos y enviarlos a un servidor web.

Entonces, hay elementos que describen el tipo de contenido que contienen. Los contenidos de un elemento P se suelen considerar un párrafo de texto. Los contenidos de un elemento LI se suele considerar un item de una lista. Por otro lado, los navegadores muestran los contenidos de dichos elementos con algunas insinuaciones visuales según su significado. Los párrafos se muestran con espacio antes y después de su contenido. Los items de una lista se muestran con puntos de marcado o números antes de su contenido.

Las primeras expansiones del vocabulario HTML se realizaron con nuevos elementos que proveían instrucciones visuales a los navegadores web: BIG, SMALL, CENTER, FONT. De hecho, las instrucciones visuales eran las únicas razones de existir para dichos elementos – no proporcionaban ninguna pista sobre el significado del contenido que contenían. HTML estaba en peligro de convertirse en un lenguaje de instrucciones visuales, en lugar de un vocabulario de significado.

 

Una cuestión de estilo

Hakon Wium Lie 21 coincidió con Tim Berners-Lee trabajando en el CERN. Inmediatamente reconoció el potencial de la World Wide Web y su lenguaje, HTML. También se dio cuenta de que el poder expresivo del lenguaje estaba en peligro de llenarse de características visuales. Lie propuso un nuevo formato para describir la presentación de los documentos HTML: Las hojas de estilos en cascada ( Cascading Style Sheets, CSS 22 ).

Rápidamente fue secundado por el programador holandés Bert Bos 23. Juntos, emprendieron la creación de una sintaxis que fuera suficientemente capaz de responder a las necesidades de los diseñadores, a la vez que suficientemente sencilla para aprenderla rápidamente. Lo consiguieron.

Piensa por un momento todos los sitios que existen en la web. Hay una enorme variación de estilos visuales: esquemas de color, tratamientos tipográficos, texturas y diseños. Toda esta variedad es posible por un simple patrón que describe todos los CSS escritos:

selector { propiedad: valor; }

Eso es.

CSS comparte la actitud de HTML de perdonar los errores. Si un navegador web encuentra un selector que no entiende, simplemente salta lo que haya entre las llaves ( { … } ) de dicho selector. Si un navegador se encuentra con una propiedad o un valor que no entiende, ignora la declaración. No muestra un error. No deja de interpretar el CSS en ese punto, sino que sigue adelante.

marklar { marklar: marklar; }

Así como con HTML, este tratamiento de los errores ha permitido a CSS crecer con el tiempo. Nuevos selectores, nuevas propiedades, y nuevos valores se han añadido al vocabulario del lenguaje a través de los años. Cuando aparece una nueva característica en CSS, los diseñadores y desarrolladores saben que la pueden usar tranquilamente, incluso aunque todavía no la soporten los navegadores. Pueden estar seguros que los navegadores antiguos reaccionarán a las nuevas características con completa indiferencia.

Justo porque un lenguaje sea elegante y esté bien diseñado, no significa que la gente lo utilice. CSS llegó después de HTML. Los diseñadores no perdieron los años intermedios esperando pacientemente una manera de estilizar sus documentos. Utilizaron lo que estaba a su alcance.

 

Matándolo

En 1996, David Siegel publicó un libro titulado Creating Killer Websites 24 ( Creando sitios web asesinos ). En él esbozó una serie de técnicas ingeniosas para crear diseños llamativos fuera del rudo material HTML.

Una técnica implicaba el uso de un GIF transparente, justo pixel a pixel. Estaba insertado en una página como un elemento IMG, pero asignándole valores precisos a sus atributos WIDTH y HEIGHT, los diseñadores podían controlar el espacio blanco en sus diseños.

Otra técnica utilizaba el elemento TABLE. Este elemento – conjuntamente con sus hijos TR y TD – se empleaba para tabular los datos. Pero aplicando los valores correctos a los anchos y altos de las celdas de la tabla, se podía utilizar para recrear casi cualquier diseño.

Soluciones ingeniosas para problemas difíciles. Pero tenían consecuencias desafortunadas. Los diseñadores trataban el HTML como una herramienta para la apariencia de contenido en lugar de como un lenguaje para describir el significado del contenido. CSS era la solución a este problema, sólo si se conseguía convencer a los diseñadores a utilizarlo.

 

Guerras de navegadores

Una de las razones por la que los diseñadores web no utilizaban CSS era la ausencia de soporte del navegador. En aquel momento había dos navegadores principales compitiendo por el espíritu de la web: Microsoft Internet Explorer 25 (IE) y Netscape Navigator 26. Eran incompatibles en el diseño. Cada uno tenía su elemento o atributo particular para hacer exactamente lo mismo.

Quizá la idea detrás de esta estrategia era que los diseñadores web debían escoger qué características particulares iban a escoger, como hijos obligados a escoger entre sus padres. En realidad los diseñadores web tenían poca elección, salvo escribir para ambos navegadores, lo que significa hacer el trabajo dos veces.

Un grupo de diseñadores web decidió que ya había bastante. Se juntaron bajo la bandera del Web Standards Project 27 y empezaron obligando a Microsoft y Netscape a abandonar sus individualidades y adoptar estándares tales como CSS.

La marea comenzó a girar con el lanzamiento de IE5 para Mac, un navegador que inició un increible soporte a CSS. Si esto era el futuro del diseño web, la vida estaba a punto de ser mucho más productiva y creativa.

Algunos diseñadores web avanzados adoptaron pronto CSS. Rediseñaron sus sitios web utilizando CSS para el diseño, en lugar de TABLES y GIFS espaciadores. Fieles al espíritu fundador de la web, compartieron los que estaban aprendiendo y animaron a otros a hacer el cambio a CSS.

Quizá la mejor demostración del poder de CSS era un sitio web llamado CSS Zen Garden 28, creado por Dave Shea 29. Era un escaparate de diseños bonitos y variados, todos según las reglas CSS. El HTML era el mismo siempre.

Siendo el mismo documento HTML, se podía estilizar de muchas formas diferentes, lo que destacaba uno de los beneficios de CSS: separación de intereses.

 

Acoplamiento

En cualquier sistema, desde una infraestructura urbana hasta un programa de ordenador, los diseñadores de dicho sistema pueden elegir el grado por el cual las piezas del sistema dependen de otras. En un sistema estrechamente acoplado, cada pieza depende de cada pieza. Sin embargo, en un sistema débilmente acoplado, todas las piezas son independientes, con poco a nada conocimiento de las otras piezas.

En un sistema estrechamente acoplado, cada parte del sistema puede realizar suposiciones acerca de las otras partes. Estos sistemas se pueden diseñar muy rápidamente, pero con un precio. La ausencia de flexibilidad. Si una pieza falla, arrastrará todo el sistema con ella.

Diseñar un sistema débilmente acoplado lleva más trabajo. Sin embargo, el resultado final es más flexible al fallo. Las partes individuales del sistema se pueden intercambiar con mínimos efectos secundarios.

Los hacks iniciados por David Siegel consistían en una estructura estrechamente acoplada y presentación en un único archivo HTML monolítico. La adopción de CSS facilitó esta dependencia, llevando la web más cerca al enfoque modular de la filosofía UNIX. La información de visualización puede estar en un fichero separado: una hoja de estilos. Así es como un sencillo documento en CSS Zen Garden puede tener tantos diseños aplicados.

La hoja de estilo necesita tener algunos datos acerca de la estructura del documento HTML. Con frecuencia, se añaden “ganchos” al marcado HTML para hacer más facil la estilización: valores específicos de atributos CLASS o ID, por ejemplo. Luego HTML y CSS no están totalmente desacoplados. Forman una asociación pero también tienen un arreglo. El documento de marcado puede decidir qué quiere a veces mostrar otras hojas de estilo. Mientras tanto, la hoja de estilos puede aplicarse a otros documentos. Están débilmente acoplados.

 

Bailando sobre la arquitectura

A una disciplina le lleva tiempo desarrollar sus propios valores de diseño. El diseño web es todavía una disciplina joven. Mientras empezamos lentamente a formar nuestro conjunto de principios de guía, podemos inspirarnos en otras disciplinas.

El mundo de la arquitectura ha acumulado su propio juego de valores de diseño con el paso de los años. Uno de esos valores es el principio de honestidad material. Un material no se puede utilizar como sustituto de otro. De otra manera el resultado final es decepcionante.

Utilizar TABLES para diseñar es materialmente deshonesto. El elemento TABLE está destinado a marcar la estructura de datos tabulados. El resultado final del uso de TABLES, elementos FONT y espaciados GIF es una fachada. En un primer vistazo se ve bien, pero no resistirá el escrutinio. Tan pronto como un sitio web es testeado por el uso actual sobre varios navegadores, la fachada se desmorona.

Utilizar CSS para la presentación es materialmente honesto – es el uso destinado de CSS. Esto permite a HTML se materialmente honesto. En lugar de intentar cumplir dos roles – estructura y presentación – HTML puede volver a cumplir su verdadero propósito, marcar el significado del contenido.

También es posible usar ( o abusar ) CSS de forma materialmente deshonesta. Durante mucho tiempo, no había un forma fácil de añadir bordes redondeados a un elemento mediante CSS. En su lugar, los diseñadores web encontraron maneras de saltarse el problema, insertando imágenes de fondo en el elemento, simulando el mismo efecto final. Ello funcionó hasta un punto, pero de la misma manera que el espaciado GIF, sólo era fachada. Entonces apareció la propiedad border-radius. Ahora los diseñadores pueden conseguir sus esquinas redondeadas de una forma materialmente honesta.

Crucialmente, los diseñadores eran capaces de utilizar nuevas propiedades como border-radius antes de que cada navegador las soportara. Esto es gracias al modelo de gestión de errores liberal de CSS. Los nuevos navegadores mostrarán las esquinas redondeadas. Los viejos no mostrarán error. Los viejos no pararán de interpretar el CSS. Simplemente, ignorarán las instrucciones que no entiendan y seguirán adelante. Sin daño, sin falta.

Por supuesto, esto significa que el sitio web resultante se mostrará diferentes en navegadores distintos. Algunas personas verán las esquinas redondeadas. Otras no.

Y eso está bien.

 

Referencias

 


Notas de traducción

(19) ‘Enseñar a la abuela a chupar huevos’. Después de mucho buscar, he descubierto que significa ‘dar consejos a una persona sobre algo que dicha persona ya sabrá’. Entre nosotros, la respuesta de dicha persona será: ‘Pero qué me estás contando…’.

(20) HTML5 es la quinta revisión importante de HTML. Sitio del W3C ( World Wide Web Consortium ).

(21) Hakon Wium Lie, pionero web, que propuso el concepto de las hojas de estilo en cascada.

(22) CSS3 es la última revisión del lenguaje de hojas de estilo en cascada.

(23) Bert Bos, uno de los autores de la primera especificación de CSS.

(24) Creating Killer Websites.

(25) Microsoft Internet Explorer. Navegador web desarrollado por Microsoft. Bajo mi punto de vista, el peor navegador web.

(26) Netscape Navigator, navegador web creado por Netscape Communications en 1994. Canceló el soporte en 2008 en la versión 9, pasando a ser Mozilla Firefox.

(27) Web Standards Project (WaSP).

(28) CSS Zen Garden.

(29) Dave Shea, diseñador web, creador de CSS Zen Garden y co-autor de The Zen of CSS Design.

 

Derechos

Este libro ( Resilient Web Design ) ha sido escrito y producido por Jeremy Keith. Bajo licencia Creative Commons Attribution-ShareAlike 4.0 International License. Yo me he limitado a traducirlo, y, en todo caso, añadirle unas notas de traducción para enriquecerlo ( aunque no fuera necesario enriquecerlo ). Esta traducción, a su vez, también está bajo la licencia Creative Commons Attribution-ShareAlike 4.0 International License.

2 opiniones en “Capítulo 2. Los materiales”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *