Voy a confesar una cosa. Firmo este artículo como profesor de una asignatura que se llama Lenguajes y estándares web, en la que se enseña a los estudiantes del Grado en Multimedia de la UOC las mejores prácticas a la hora de crear páginas web con HTML y CSS, usando los estándares definidos para tal fin. Lo hago para completar un número de Mosaic en que entrevistamos a Bruce Lawson, “evangelista web” de la compañía noruega Opera, cuyo Currículo de Estándares Web se usa desde hace tres semestres como material base de la asignatura que les comento y al que añadimos, también en este número de Mosaic, algunos de los artículos sobre HTML5 que se han editado desde entonces en dicho currículo.
Hasta ahí, todo correcto.
El problema llega cuando alguien pregunta cuáles son esos estándares y mejores prácticas. Porque yo ya no lo sé. Y lo peor no es eso. Lo peor es que si juntas a diez personas que afirman saber cuáles son esas mejores prácticas, a no ser que trabajen codo con codo cada día, es bastante probable acabar con diez opiniones diferentes, repartidas en un abanico de sorprendente amplitud.
A día de hoy estándares, lo que se dice estándares, hay dos para el marcado de páginas —HTML 4.01 y XHTML 1.1— y en cuanto a las hojas de estilo, CSS 2.1 es un estándar desde el 7 de junio de 2011. Sí: a pesar de estar implementado desde hace años por todos los navegadores actuales y no tan actuales de todos los fabricantes (Microsoft incluido), el estándar no tiene ni dos meses de vida como tal en el momento de la publicación de este artículo. Para el marcado, muchos nos inclinamos por XHTML sobre HTML, pero son pocos, poquísimos, los que se atreven a servir su XHTML como verdadero XML, lo que es ya, en sí, una buena práctica dudosa, en el mejor de los casos. Nótese que no hemos hablado ni de HTML5 ni de su serialización XML, XHTML5, ni de CSS3, pues tardarán años en ser estándares. HTML5 es ahora mismo un ‘borrador’ en estado de ‘última llamada para revisión’ hasta el ya muy cercano 3 de agosto de 2011, pero el roadmap actual no prevé su llegada a ‘recomendación’ (el curioso nombre que da el W3C a sus estándares) hasta más allá de 2020. CSS, por su parte, es una ‘ensalada’ de documentos en diferentes estados, cuya situación actual se puede consultar en http://www.w3.org/Style/CSS/current-work para observar detalles como que el modelo básico de cajas lleva en el estado de borrador de trabajo desde agosto de 2007.
Luego no queda más remedio que ir por delante de los estándares del W3C pero por detrás de las implementaciones de los navegadores, en un difícil punto de equilibrio, inestable y en movimiento.
En mayo un compañero de trabajo me hacía llegar un artículo: Will the Next Web Platform Please Hold Still? (podríamos traducirlo como ¿Se estará quieta la próxima plataforma web, por favor?). Aunque no exento de algunas incorrecciones —imposible estar ‘libre de pecado’, la verdad— es difícil no compartir el sentimiento que se desprende del artículo: ¿me va a decir alguien qué puedo usar y qué no y cuáles son los navegadores a que debo dar soporte y qué tecnologías debería estar usando para estar actualizado y por qué narices la respuesta de hoy a todas esas preguntas no es la misma que la de la semana pasada?
La situación, desde luego, no es nueva. Me permito recomendar encarecidamente la lectura de tres artículos sobre el tema: Web Standards 2008: Three Circles of Hell, de Molly Holzschlag, How Did We Get Here, de Mark Pilgrim y Martian Headsets, de Joel Spolsky. Y que se considere este artículo como la continuación natural de La web, con estándares, que firmé con mi colega Carlos Casado hace poco más de un año en esta misma revista. Todos ellos ayudan a dar el contexto necesario para entender que, efectivamente, definir un estándar es la manera perfecta de granjearse las enemistades de muchos sin dejar satisfecho absolutamente a nadie. Quede claro, por tanto, que el objetivo no es culpar a quienes escriben los estándares: todos los implicados se emplean a fondo en intentar cuadrar el círculo y, teniéndolo todo en cuenta, lo hacen más que razonablemente bien.
HTML5 es tantas cosas…
Un primer punto que debemos tener en cuenta es que HTML5, como término descriptivo de una serie de tecnologías, está a la altura de web 2.0 y AJAX: las definiciones posibles son muchas. En el caso en que nos (¿me?) ocupa, lo que verdaderamente nos interesa es HTML5 como avance del lenguaje de marcado HTML. También nos interesa CSS3 como extensión del estándar para la definición de hojas de estilos, pero eso ya no es HTML5, de hecho.
Si consultáis Familiarízate con HTML5 (uno de los artículos del Currículo de Estándares Web que añadimos a nuestros materiales docentes) podréis ver que son muchos los aspectos tratados que tienen más que ver con aplicaciones web que con páginas web: el nuevo elemento <canvas>, los web sockets, cachés de aplicación, almacenamiento de datos estructurados y no estructurados en el cliente… Afortunadamente, podemos dejar la discusión de qué hacer con todas esas tecnologías (especialmente las concernientes a los agujeros de seguridad de los protocolos de web sockets y WebGL) y centrarnos únicamente en los aspectos del marcado.
Desde el punto de vista del marcado
Así pues, si nos limitamos a lo que afecta al marcado de documentos web, en un repaso rápido vemos que nos quedaremos con los nuevos elementos semánticos, las nuevas características para formularios y los elementos para audio y vídeo.
Comencemos por lo fácil: las características para formularios apenas han despertado controversia. ‘Sólo’ hace falta que se implementen de manera consistente entre navegadores.
En cuanto a los elementos para audio y vídeo, el principal problema, de difícil, muy difícil solución, al menos a corto y medio plazo, es el de los códecs. Si bien el mundo de los estándares web es abierto, el de los estándares de vídeo, especialmente, no lo es a día de hoy y está dominado por H.264, cuyos derechos de uso son administrados por la empresa MPEG LA, que impone unas determinadas condiciones de uso. Apple y Microsoft son licenciatarias de esas tecnologías y pueden usarlas en sus productos sin problemas, pero Mozilla y Opera, por ejemplo, no quieren depender de una tecnología cerrada en manos de una compañía privada. Hace poco más de un año Google presentó WebM, un formato libre de royalties, con el apoyo de Mozilla y Opera, y anunció que dejaría de dar soporte nativo a H.264 en Chrome. Apple, por su parte, sigue inclinándose por H.264 y no da soporte a WebM en Safari (existen motivos para ello: a Apple le interesa soportar un único códec, y ahora mismo el chipset del iPhone y el iPad es capaz de decodificar H.264 de manera muy eficiente). Microsoft, por su parte, que es especial en el hecho de crear un navegador que funciona en un único sistema operativo, delega la decodificación de vídeo en Windows y, por tanto, soportará ‘lo que le echen’, pero H.264 viene instalado por defecto… y WebM no. Además, Microsoft ha desarrollado un plug-in para Chrome para que este recupere el soporte para H.264, en un ‘más difícil todavía’ que ha dejado sorprendida a toda la industria.
En la práctica, para el desarrollador que quiere incorporar vídeo en sus páginas, todo esto significa que o bien se codifican esos vídeos en H.264 y WebM o bien que sólo se hace en H.264… y se usa Flash como reproductor en los navegadores que no lo soportan, negando las muchas ventajas del uso del vídeo de HTML5 (como los Universal Subtitles de Mozilla Drumbeat, o herramientas tan potentes como http://popcornjs.org/).
La situación del audio, por su parte, no es mucho más clara: MP3 es la tecnología ubicua en el campo desde hace años, pero aún así las exigencias económicas de la Sociedad Fraunhofer, que administra las correspondientes licencias, dificultan en gran manera el soporte para los ‘pequeños’.
Y sólo hemos hablado de problemas de propiedad intelectual. Si se desea ver cuáles son las limitaciones actuales, por ejemplo, del audio de HTML5, resulta muy recomendable la lectura de “Probably, Maybe, No”: The State of HTML5 Audio, de Scott Schiller, creador de SoundManager 2.
El audio y vídeo de HTML5 son una realidad en ciernes y plantean ventajas muy interesantes. Pero sólo el trabajo y la presión constantes de desarrolladores y usuarios puede lograr que se implemente de manera homogénea en todos los navegadores modernos (y que los desarrolladores, por tanto, no tengan que morir en el intento).
Así, quedan por tratar los nuevos elementos semánticos de HTML. La discusión sobre las (más que obvias) limitaciones de la semántica de HTML 4 son tan viejas como HTML 4. Todos los que hemos escrito en algún momento un documento web y lo hemos intentado cargar de semántica hemos añorado muchos elementos que nos parecían imprescindibles. Todos hemos dudado ante el uso de un <br />. Todos nos hemos preguntado si el nombre del autor es un <cite> o si dicho elemento debería limitarse a títulos de obra. O si HTML es un <abbr> o un <acronym>. Muchos hemos abusado de las listas de definiciones. Si se busca bien, se encontrarán muchísimos <p> en la web que marcan cosas que, de hecho, no son párrafos. Pese a lo que dice la intuición, <address> debería usarse, según el estándar, para la información de contacto del autor y no para… direcciones en general. La ensalada de niveles provocada por la acumulación de <h1>, <h2>, <h3>, <h4>… es más que notable en documentos de estructura compleja y provoca múltiples problemas cuando se sindican contenidos….
HTML5, como lenguaje de marcado, intenta resolver todos esos problemas que, a primera vista, parecen tan sencillos. Y es que cuando un comité decide qué elementos deben ‘caerse’ de HTML, cuáles deben modificar su significado y qué elementos nuevos deben aparecer y con qué significado, inevitablemente se llega a una solución de compromiso en la que nadie está plenamente satisfecho…
Como muestra de la complejidad del proceso, puede verse esta breve discusión (http://oli.jp/2011/blockquote/) de cómo atribuir el origen de la cita dentro de un blockquote. Si se desea ver elementos que han provocado disparidad de opiniones y animadas discusiones, se puede acceder al estado actual del trabajo del WHAT WG y pensar en cómo estructurar un documento complejo con los elementos article, section y aside, o comprobar que han ‘vuelto’ los elementos i, b y u (i, por ejemplo, representa una porción de texto en un tono diferenciado, a usar para designaciones taxonómicas o términos técnicos, por ejemplo),
Pero, como apunta Bruce Lawson en la entrevista que acompaña a este artículo, la sensación casi universal es que a pesar de todas las pequeñas inconsistencias del estándar y de que a nadie está completamente de acuerdo con todos y cada uno de sus puntos, el paso adelante que representa es tan importante que convivir con los puntos que a cada uno de nosotros nos chirrían un poco es una incomodidad perfectamente tolerable.
Y por tanto…
La situación es compleja, pero no más de lo que era hace un par de años. Enseñar (y aprender) lo que los anglosajones denominan ‘POSH’ (plain old semantic HTML, o el viejo HTML semántico de toda la vida) sigue siendo una buena práctica, especialmente en un curso introductorio como el que nos ocupaba al principio de este artículo. El estudiante curioso e interesado, naturalmente, querrá ir más allá. Con la publicación de los artículos que acompañan a este texto les damos, como a toda la comunidad, una buena rampa de lanzamiento para aprender y experimentar. Trabajar hoy con HTML5 y CSS3 ya es una posibilidad real y, de hecho, la tarea del diseñador web es hoy más agradecida que hace un par de años. Eso sí, como recuerda Bruce Lawson, si uno quiere vivir ‘a la última’ debe ser consciente de lo que hace y en qué espacio se mueve, y tener muy en cuenta (como siempre, por otro lado) cuál es su ‘target’ antes de lanzar nuevas funcionalidades en sus diseños: algunos públicos aún no están preparados para ellas, pero cada vez son más los que sí.
Cita recomendada: CÓRCOLES, César. HTML5 y CSS3. ¿Dónde están las buenas prácticas? Mosaic [en línea], julio 2011, no. 89. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n89.1136.