Además de las numerosas mejoras en la semántica de nuestro código, HTML5 trae bajo el brazo una serie de APIs que forman una gran parte de esta nueva especificación. Muchos de estos APIs llevaban tiempo dando vueltas por ahí, sin apenas documentarse y otras son totalmente nuevas.
EN .NetMagazine hacen un repaso a las APIs mantenidas en la especificación oficial del W3C y también a aquellas que todavía están sólo en la especificación del WHATWG. Además, recopilan otros APIs que se consideran incorrectamente parte de HTML5 y enlaces a demos y muestras del soporte actual de los navegadores de estas APIs e incluso ejemplos de polyfills con los que empezar a utilizar algunas de estas funcionalidades sin perder la compatibilidad entre navegadores.
No te lo pierdas en .netMagazine: The Developer’s Guide to the HTML5 APIs
Uno de los “problemas” que ha enfrentado el diseño web desde sus comienzos es el de adaptarse al dispositivo desde el que se visualizan las páginas.
No hace tanto era suficiente contar con la resolución de pantalla más típica para asegurarnos, hasta cierto punto, de que nuestros diseños se mostrarían correctamente en todos los ordenadores. Pero ahora, que ya no se accede a ellas desde un solo tipo de dispositivo y las resoluciones son cada vez más dispares, esta labor se hace realmente compleja. Puedes optar por hacer diferentes versiones de tus sitios pero el gasto de tiempo y esfuerzo no es realmente práctico y rompe un poco con la siempre apreciada adaptabilidad de la web.
Initializr es una plantilla con la que te será más cómodo crear diseños responsivos, es decir, adaptables al dispositivo en que se visualizan. Una suma de diseño líquido basado en porcentajes y media-queries será todo lo que necesites.
Con Initializr dispondrás de una base para crear sitios que se verán bien en móviles, tablets, ordenadores con pantallas “normales” y ordenadores con pantallas enormes.
Puedes descargarlo desde la web del autor, donde además podrás leer una explicación exhaustiva del tema. Y, si el inglés no es tu fuerte, podrás leer una traducción cortesía de Diego Ante.
Vía Think Vitamin
Cada vez es más común que, en lugar de diseñar para páginas estáticas que sólo nosotros o alguien con conocimientos actualizará, diseñemos para CMS que nuestro cliente podrá editar y utilizar a su antojo.
Una parte importante del diseño y la maquetación de una plantilla para un CMS es la de tener en cuenta todos esos elementos que podrían aparecer en un sitio, dependiendo del uso que den nuestros usuarios, por ejemplo, al editor de entradas. No sería la primera vez que nos olvidamos de dar estilo a los encabezados más allá del h3 o que nos dejamos atrás cosas tan prácticas como los blockquotes o las listas de definición, pensando que nadie las va a usar.
Esta página HTML de prueba nos permitirá aplicar nuestros estilos a una página con todos los elementos que podrían aparecer en una página, de forma que es muy simple comprobar si hemos dado estilo a todo lo que deberíamos.
Obviamente, hay algunas combinaciones de etiquetas, como por ejemplo las listas anidadas, que no están contempladas en este documento pero nos puede servir como base para crear nuestra propia guia de estilo.
Ya sabemos que lo mejor para ahorrar peso y tiempo de carga es usar “sprites” en los casos que vayamos a usar imágenes para adornar nuestros enlaces ¿verdad?
A pesar de los claros beneficios, como mejorar el tiempo de carga o conseguir un efecto rollover más limpio y sin saltos, crear una barra de navegación basada en gráficos mediante sprites puede ser un poco aburrido.
Navigation Bar Code Generator es un proyecto de Matt Varone que nos ayudará en la tarea. Sólo tendremos que subir nuestra imagen que se compondrá de los 3 estados básicos de la barra de navegación en un sólo fichero, seleccionar el aspecto de nuestro estado normal y seleccionar los diferentes botones de los que está compuesta.
Una vez hayamos dividido nuestra imágen, sólo tendremos que introducir el nombre de los diversos enlaces que la compondrán y recoger nuestro código xHTML y CSS, perfectamente válido y en unos segundos.
Para que os hagáis una idea más clara de cómo funciona lo mejor es que veáis un video explicativo o hagáis vuestras pruebas con la imágen de ejemplo.
CSS Navigation Bar Code Generator: http://lab.mattvarone.com/navbar/
A la hora de copiar y pegar texto de relleno para nuestros trabajos contamos con un montón de alternativas, tanto en el web como en muchos programas y widgets.
No obstante, HTML-Ipsum ha conseguido en poco tiempo superar a todas y convertirse en un sitio de referencia. En primer lugar porque no nos ofrece simplemente el texto sin formatear. Podemos copiar listas ordenadas, desordenadas, parrafos largos, cortos, estructuras de tabla etc.
Pero, por si fuera poco Chris Coyier nos sorprende, con la ayuda de algunos de sus lectores, y nos ofrece una nueva gama de aplicaciones y archivos para incorporar HTML-Ipsum a nuestro flujo de trabajo:
Sin lugar a dudas un recurso importante para ahorrarnos tiempo a la hora de introducir texto de muestra.
Tenéis más información sobre estas nuevas características en CSS Tricks.
HTML-Ipsum: http://html-ipsum.com/
De un tiempo a esta parte me he encontrado varias veces con sitios maquetados de forma poco accesible y mucho menos semántica y desarrolladores que se ofenden al apuntarles lo incorrecto de ciertas prácticas ya que “el validador del w3c no arroja ningún fallo”.
Es una suerte que, por lo menos, se haya extendido la buena costumbre de validar nuestro marcado pero parece que con la excusa de que un código es válido nos olvidamos de que ningún software puede poner en contexto un sitio web, ni comprobar si hemos empleado la etiqueta más adecuada para la tarea que pretendemos desempeñar.
Por poner un ejemplo, una página maquetada con tablas, con el estilo totalmente definido mediante etiquetas obsoletas puede validar perfectamente empleando el doctype adecuado. Si, porque creo que todos hemos aprendido a engañar al validador con un doctype transicional cuando no nos apetece comernos la cabeza ¿verdad?.
Que una herramienta de validación no arroje fallos no implica necesariamente que hayamos hecho un buen trabajo, sólo quiere decir que no hemos cometido ningún error grave. Maquetar un sitio web es comparable a escribir un texto, podríamos escribir un texto carente de todo sentido pero que no provocase ningún error visible para el corrector de nuestro programa de edición de textos.
Por eso, porque las máquinas tienen sus limitaciones, debemos siempre complementar la verificación automática con la manual. Y no sólo con el W3C, si empleamos TAW o Hera o cualquier otro software para verificar la accesibilidad de una página web nos encontraremos con multitud de puntos que deben comprobarse manualmente.
No hay nada que pueda sustituir a un buen planteamiento a la hora de maquetar ni a un buen uso y entendimiento de las etiquetas HTML.
Siempre viene bien tener a mano una referencia donde consultar nuestras dudas, para todos los que ya habéis convertido al Firefox en la navaja suiza del desarrollo web os traigo hoy DevBoi.
DevBoi es un plugin que instalará una completa referencia de HTML, CSS, el DOM y Javascript en el sidebar de vuestro navegador.
Además de las referencias incluídas en la instalación estándard podréis ampliar su soporte a otros lenguajes como PHP o Ruby on Rails
No hace demasiado veía por ahí una oferta de trabajo (por cierto, busco trabajo por si alguien me quiere contratar) en la que pedían un desarrollador de front-end que fuera un fiera y que ya estuviera interesándose en CSS3 y HTML5.
La nueva especificación parecía haber despertado un nuevo interés por nuestro querido lenguaje de marcado y la gente empezaba ya a frotarse las manos con las novedades y ventajas de su quinta versión.
Ahora, viendo que hasta 2022 nada de nada, supongo que los de la oferta de arriba querrán a ese desarrollador super moderno para que vaya educando a sus hijos para que, dentro de ni más ni menos que 14 años sean los que lo disfruten.
¿No es deprimente? Algunos habremos muerto para entonces (vale, exagero un poco), si de verdad los plazos son tan largos a mi me va a coger con la friolera de 43 años y no quiero ni pensar las edades de los que sois algo mayores que yo (sin ánimo de deprimiros ¿eh?)
Y yo entiendo que un nuevo estándar no nace de la nada y que, si el HTML 4.01 está implementado desigualmente en los diversos navegadores meterles novedades puede ser labor de años pero ¿tantos?
Vale, se supone que mucho antes (entre 2009 y 2012) ya habrá una especificación lo suficientemente madura como para empezar a trabajar con ella, incluso vemos a los desarrolladores de navegadores empezar a jugar con algunas partes de lo que está por venir. Aún así, dejando las cosas en el limbo tantos años ¿no corremos el riesgo de que proliferen las interpretaciones propietarias del estándar?
Con cosas así uno entiende que aparezcan fundaciones y organismos paralelos ¿verdad?
Vía Wisdump
En nuestra ardua y ya larga lucha contra la maquetación con tablas, hemos sido muchos los que hemos descubierto las bondades del marcado semántico. Aún así todavía parece que no terminamos de comprender lo que realmente significa y cometemos errores de fondo.
Durante mucho tiempo se ha venido hablando de la versatilidad de las listas (ordenadas, desordenadas o de definición) para diversos menesteres como la creación de barras de menú e incluso hemos visto arriesgadas propuestas de estructuración de páginas mediante listas.
El problema es obvio, ¿una página web puede ser entendida en su totalidad como una lista? ¿Es realmente una lista, por ejemplo, el menú lateral (sidebar) de un blog?
En nuestro intento por renunciar a las tablas mientras mantenemos una estructura limpia sin elementos innecesarios hemos “pervertido” otro elemento para adaptarlo a nuestra conveniencia. Incluso hacemos experimentos y “evangelizamos” sobre las bondades de las listas sin pararnos a pensar lo que realmente significan.
El tema promete volverse controvertido, a fin de cuentas son muchos los “gurús” que nos sorprenden diariamente con aproximaciones realmente creativas basadas en listas, a pesar de que afrontan situaciones en las que otros elementos serían más adecuados.
Al final, la conclusión es la de siempre, debemos emplear el elemento más semántico a nuestra disposición o, en algunos casos, elementos neutros como los divs y spans que, a pesar de estar algo estigmatizados por su abuso, son elementos útiles para finalidades ajenas a la transmisión del contenido (véase, por ejemplo, para crear estructuras visuales).
Sin duda, el tema da para mucho, no sólo para leer si no para pensar y debatir; por eso os dejo unos cuantos artículos en inglés (lo siento, si hay interés podríamos traducir alguno) para profundizar un poco más en el tema y os invito a que aportéis vuestra opinión en los comentarios.
Hace ya mucho tiempo traduje un artículo que hablaba de las ventajas de utilizar “texto oculto” específico para usuarios de lectores de pantalla. Sin duda, cuando traducía aquello podía verle uso para ocultar los labels de los formularios, sustituir texto por imágenes y poco más. Pero hoy, gracias a la pequeña selección de enlaces de CSS Tricks he descubierto una forma inteligente de añadir una capa más de atención para los usuarios discapacitados.
David Walsh comparte con nosotros una gran idea. Incluye un párrafo de texto oculto con css al principio de la página, que contiene un mensaje para usuarios de lectores de pantalla, algo así (obviamente, traducción libre libre):
<p class="oculto">Bienvenido a mi sitio.
Este sitio ha sido creado para todo tipo de usuarios.
Por favor contacta conmigo en xx@xx.xx si encuentras alguna
dificultad al navegar por él.</p>Por supuesto no sirve de nada si nuestra página es un infierno de tablas y código inaccesible pero es un pequeño detalle agradable y práctico al llamar la atención de todos aquellos usuarios que hayan encontrado dificultades para navegar el sitio, con lo que podremos mejorarlo.
Eso si, no abuséis del texto oculto. Puede llegar a ser molesto, en los comentarios del artículo de David alguien apunta a colocarlo tras un enlace de “saltar al contenido” para no forzar a nuestros usuarios a escuchar una y otra vez el “utilísimo aviso accesible” y me parece la solución ideal.
Ademas, aún albergo dudas sobre si Google podría penalizarte al ofrecer una versión “distinta” de la página para usuarios y arañas. Mi opinión es que no debería si no lo usamos para meter con calzador oncemil palabras clave pero visto lo puntilloso que se nos está volviendo…
Lo que lamento es que no cuento con el testimonio de ningún usuario de lectores de pantalla para saber de primera mano lo útil o molesto de un aviso de este tipo. Si conocéis alguien que pueda probar, por favor, compartid la experiencia.
Alojado en RedCoruna Hosting
¿Quieres hasta 6 meses de hosting gratis? Utiliza el cupón RCwebmasterlibre al contratar cualquier plan con RedCoruna - más información
Seguir @webmasterlibre
