Principios de diseño HTML

Recursos de consulta para aprender HTML-5

HTML-5 está ya siendo apliamente usado. Los navegadores soportan gran parte de las nuevas características. Escribí hace poco un artículo llamado HTML5 ya! donde apuntaba certezas y dudas acerca de todo esto. Lo que está claro es que hay que empezar. Pero ¿por dónde?.

Cuando escribí mi glosario XHTML-1.0 y CSS-2.1 me basé en las especificaciones ya consolidadas como estándares del W3C. Sin embargo ahora no voy a hacerlo así, tal como sugiero en el artículo (de opinión) que mencioné antes. Ya he visto que debo consultar en múltiples sitios lo que uno quiere aprender. Miraré por ejemplo los siguientes recursos:

  • Las especificaciones oficiales HTML5 de W3C. Pero también las de los grupos alternativos, como HTML5 de WHATWG.
  • Un montón de sitios que hablan sobre este tema:
    • html5 Doctor Resources, un sitio titulado como Recursos para ayudarle a ponerse al día y producir el mejor HTML5.
    • DIVE INTO HTML5. Esta publicación es del autor Mark Pilgrim y estaba hasta hace poco en http://diveintohtml5.org/, pero ya lo quitaron. El enlace anterior está (por ahora) dentro del sitio html5 Doctor.
    • HTML5 ROCKS, del equipo de desarrollo Chromium que hacen, entre otras cosas, el navegador Google Chrome.
    • Y muchos sitios más...

En definitiva, se trata de buscar información por todos lados, sin conformarse con una única fuente. En algún sitio explicarán mejor un tema que en otros o le darán un enfoque diferente. E incluso intentar aprender y probar cosas que no están en las especificaciones. Pues la filosofía de HTML5 es algo más que una especificación. La idea del WHATWG de que HTML debe ser un estándar vivo [WHATWG: FAQ] significa que debe actualizarse con nuevas características de forma permanente.

Principios de diseño HTML-5

En el año 2007 el W3C publica un documento llamado W3C: HTML Design Principles, Principios de diseño HTML. Este documento describe un conjunto de principios básicos que guiarán al grupo de trabajo que desarrollará HTML-5:

  • Compatibilidad
  • Utilidad
  • Interoperabilidad
  • Acceso universal

Creo que es un buen punto de partida para hacerse una idea general sobre el tema. Intentaré traducir y resumir con mis propias palabras estos principios que, aunque no se fijan como absolutos, si nos darán una idea general de como debe evolucionar HTML.

En la introducción diferencia entre un lenguaje conforme a las especificaciones y un lenguaje soportado. La evolución de HTML deberá tener en cuenta ambos conjuntos, pues requerirá que siga soportando características de especificaciones anteriores así como otras que, sin estar en ellas, han sido y son ampliamente utilizadas.

Compatibilidad

HTML-5 debe ser compatible con versiones anteriores y posteriores, pero lo más importante es que HTML debe ser sobre todo una evolución más que una revolución:

  • Soportar contenido existente

    Los navegadores deben soportar cualquier especificación anterior de HTML, incluso en aquellas características que ya no formaban parte de las últimas especificaciones. De ninguna forma la evolución de HTML podrá dejar de lado todo el extenso contenido ya existente que fue escrito basado en especificaciones anteriores. Por ejemplo, el elemento <u> para subrayado ya fue declarado como obsoleto en HTML-4.01, pero es un elemento que existe en muchas páginas web, quizás antiguas, pero no por eso podemos ignorarlas. Así HTML-5 lo rescata de nuevo.

  • Degradado elegante.

    El término degrade gracefully se refiere en este caso a cómo deben afrontar nuevas características que no se adaptan a los navegadores y viceversa. Por ejemplo, un navegador que no soporte el elemento <canvas>Elemento no soportado</canvas> simplemente mostrará el contenido de texto interior. De la misma forma podemos usar CSS o Javascript para emular nuevas características en navegadores antiguos o actuales que aún no las soporten.

  • No reinventar la rueda.

    Si ya existe algo que se usa extensamente y funciona no hay por que cambiarlo. Un ejemplo es el atributo contenteditable="" y lo relacionado con la edición HTML de elementos en línea. Algo que ya era ampliamente usado y que no formaba parte de las especificaciones. De esta forma la evolución de HTML debe recoger lo que ya existe en uso tal cual, sin tratar de "reiventar la rueda".

  • Construyendo sobre lo que ya existe.

    El título original es Pave the Cowpaths "pavimentar el camino de vacas" en el sentido de que cuando una práctica está extendida, es mejor adoptarla que no prohibirla o sustituirla por algo nuevo: es mejor arreglar, ensanchar y asfaltar el viejo camino de tierra que hacer una nueva calle al lado. El ejemplo de la barra para cerrar un elemento vacío en XHTML como <br /> en lugar de <br> es muy ilustrativo. Si ya hay (habemos) un montón de personas que estamos cerrando con una barra los elementos vacíos, entonces la evolución de HTML debe adoptarlo como otra forma de presentar elementos vacíos.

  • Evolución y no revolución.

    Finaliza esta parte con esta idea que yo considero importante. Las revoluciones cambian el mundo muchas veces para mejor. Pero no siempre lo hacen. A veces es mejor una evolución incremental que una revolución seca y cortante, tal como se intentó con XHTML. Ahora el concepto es ir cambiando las cosas sobre lo ya construido y "no incendiar la ciudad para construir otra nueva".

Utilidad

Son principios para que el diseño de la especificación HTML consiga de forma eficaz los fines que persigue.

  • Resolver problemas reales.

    Cualquier modificación de la especificación debería resolver problemas del mundo real. Yo diría que lo que interesa de las posibles modificaciones es que realmente resuelvan los problemas, más que estén basadas en una bella teoría pero cuya aplicación práctica apenas sea demandada.

  • Prioridad de los usuarios en caso de conflicto.

    El término original de esta entrada es Priority of constituencies. Pero constituency se debe traducir como el conjunto de personas que les une una identidad y objetivo común. Así en el diseño de una especificación HTML encontramos a los usuarios de la web, los autores que escriben las páginas, los implementadores (navegadores), los que redactan las especificaciones y por último los puramente teóricos. Y es precisamente en este orden como dice este principio que debería resolverse un conflicto en la evolución de HTML. Yo me quedo satisfecho al ver que los usuarios son los primeros de la lista, algo que no siempre ha sido así. Espero que lo cumplan.

  • La seguridad será tenida en cuenta

    Titulado como Secure by design algo así como "seguro por diseño", se refiere a que se deben contemplar los aspectos del modelo de seguridad de la web.

  • Separación de contenido y presentación

    Para el título Separation of concerns se debe tener en cuenta que concern en informática es un particular conjunto de comportamientos necesarios o requeridos de un programa o sistema. Y Separation of concerns se refiere al proceso de separar un programa en sus distintas características de tal forma que su solapamiento funcional sea el mínimo posible. Aquí esta haciendo clara referencia a separar el contenido (HTML) de la presentación (CSS), algo que la especificación anterior HTML-4.01 intentó en algunos aspectos. Por ejemplo, el elemento <b> era y es empleado como un simple resaltador de letra en negrita (de ahí la "b" de bold en inglés). Estaba destinado a ser suprimido pues eso podía hacerse con estilo CSS. Aunque se considera mejor darle otro cometido que prohibirlo, esto no quita la necesidad de promover el concepto de separar contenido de presentación. Por ejemplo, el nuevo elemento <article> se define para contener algo diferenciado como un artículo, pero no se dice nada de como debe ser presentado: en toda la página, a dos columnas, etc.

  • Consistencia del DOM

    Los navegadores leen el documento HTML y cargan los elementos en el árbol de nodos, usualmente denominado DOM (Document Object Model). Este principio se refiere a que sea cual sea la forma de construir ese DOM, todos deberían tener la misma respuesta cuando un script accede a ellos. En este aspecto HTML-5 supone un cambio significativo especificando también las interfaces comunes del DOM.

Interoperabilidad

Estos principios mejoran la interoperabilidad de las implementaciones de HTML. La interoperabilidad es la capacidad de dos o más sistemas informáticos para trabajar juntos, intercambiando información. Para ello puede ser necesario que ambos entiendan sus respectivas interfaces y que no restringan accesos e implementaciones

  • Funcionamiento bien definido.

    Se buscará definir con claridad el funcionamiento de cada característica de la especificación, con el objeto de que los autores de contenido sepan a que atenerse. Así ya no tendremos que preocuparnos de cómo se verá este elemento en tal o cual navegador. Y sí todos los navegadores hacen lo mismo ¿cuál será la diferencia entre ellos?. Pues ese principio acaba diciendo que aún los implementadores tendrán campo por delante para mejorar áreas tales cómo las interfaces de usuario y la calidad en el renderizado o presentación. Suena como a disculpa ante la tendencia que se seguía, donde un navegador iba por su cuenta creando sus propias características para así diferenciarse del resto y obtener mayor cuota de mercado. Es un principio muy importante, si los implementadores lo respetan.

  • Evitar la complejidad innecesaria.

    Son preferibles las soluciones sencillas que las complejas, siempre que sea posible. Las características sencillas son más fáciles de implementar, interoperar y de entender por los autores. Pero esto no debe ser excusa para intentar afrontar otros principios que pudieran requerir soluciones más complejas.

  • Control de errores

    El control de errores deberá ser definido para lograr implementaciones interoperables. Serán preferibles las recuperaciones elegantes ante un error y no los fallos que corten de forma brusca una ejecución, de tal forma que los usuarios no queden expuestos gravemente a los errores de edición de los autores.

    Aquí no pone ningún ejemplo, pero supongo que se refiere a definir cómo debe recuperarse el navegador, por ejemplo, ante un error del autor en el anidamiento de elementos. Se mantiene entonces la idea de que el navegador tratará de corregir estos errores de la mejor forma posible para que el usuario aún pueda ver la página. Pero ahora se definirá cómo se corrigen esos errores para que todos los navegadores se comporten de forma similar.

Acceso universal

Esta categoría cubre varios principios relacionados.

  • Independencia del medio.

    Las características deberán trabajar en diferentes plataformas, dispositivos y medios (visual, impreso, auditivo, etc). Una característica no debería ser omitida sólo poque no puede ser representada en un medio. Por ejemplo, un hipervínculo no puede ser accionado en un documento impreso, pero por eso no vamos a omitir el elemento <a> en la especificación para el medio impreso.

  • Soporte a los lenguajes mundiales

    Posibilitar la publicación en todos los lenguajes del mundo. El existente soporte de UNICODE que permite texto en la mayor parte de los lenguajes es un éxito ya implementado. Pero la especificación también tiene en cuenta algunos detalles de mejora para los lenguajes no occidentales.

  • Accesibilidad.

    Se han de diseñar características para mejorar la accesibilidad de personas con discapacidades. El texto alternativo para un elemento <img> es un ejemplo ya en uso que facilita entender una imagen a las personas invidentes.