Bruce Lawson

Comencemos: ¿quién eres y qué haces en relación con los estándares web?

Soy Bruce Lawson, un inglés de 44 años de edad y comencé a interesarme por los estándares web en el año 2001 o 2002, cuando trabajaba para una editorial de Birmingham, en el Reino Unido dirigiendo el equipo que escribía libros sobre Microsoft Visual Studio y las tecnologías .net. Me interesé en cosas de la web, la editorial publicó algunos libros sobre temas web y de ahí mi interés. Y, por supuesto, me pareció que los estándares web eran obviamente la metodología correcta para el desarrollo de una web robusta. Así que empecé un blog sobre el tema, comencé a dar charlas en mi tiempo libre y algo más tarde unos noruegos muy majos sugirieron que quizá me gustaría convertir mi hobby en mi trabajo, por lo que me uní a Opera en 2008, hace unos tres años… que se cumplen hoy, casi exactamente, de hecho.

Estoy muy interesado en el proceso de escritura de los estándares. Tratar de hacer feliz a todo el mundo no puede ser fácil.

He estado en la periferia, si se quiere, de la creación de los estándares. Es un trabajo para personas con cuatro veces más cerebro del que tengo yo y 355 veces mi paciencia. Algo como HTML5, que lleva, de una u otra forma en ebullición desde el año 2004… Hay mucha gente que dice, “Oh, dios mío, esto está tardando demasiado” y un montón de gente diciendo “el estándar, va demasiado rápido”, y lleva así 7 años.

Si sólo te estás inventando algo completamente nuevo, como XHTML 2, por ejemplo, es, me imagino, más fácil, porque sinceramente inventas lo que quieres inventar, te rodeas de un grupo de personas afines, y ya está. Pero con algo como HTML5, o como CSS, cosas que usamos todos y… En el grupo de trabajo de CSS, lo que han estado haciendo con CSS 2.1 es estandarizar a posteriori las cosas que realmente funcionan ya. Y HTML5 es eso amplificado muchísimo: la estandarización a posteriori de todos los comportamientos de navegador que ya existían, incluso si contradecían la norma anterior, la estandarización a posteriori  de todos los comportamientos interoperables que nunca habían sido estandarizados. Cosas como XMLHttpRequest, por lo que a mí me consta, nadie había escrito nunca cómo funciona, una y otra vez se aplicaba ingeniería inversa.

Por lo que este tipo de cosas es… No me puedo imaginar la paciencia y la capacidad intelectual que necesita la gente que se ocupa de ello. Es un proceso muy sucio, creo. Surge del optimismo y de las ganas de hacer del mundo un lugar mejor, pero imagino que en su mayoría es sucio y político, pero eso es sólo mi perspectiva de outsider, y no represento Opera de ninguna forma, sólo me represento a mí mismo y a los  desarrolladores web como yo, como yo era.

Una de las cosas que resultan de ese sucio proceso es que nadie va a estar encantado con la totalidad del estándar, aunque la mayoría estamos de acuerdo en que HTML5 es un gran paso adelante. Va a haber cosas como que Opera estudia los identificadores y clases que se utilizan en la web y Google hace lo mismo pero obtiene resultados diferentes, y eso lleva a un desacuerdo, por ejemplo, sobre algunos de los nuevos elementos semánticos en HTML5, ¿no? (Ed: Para los curiosos, el análisis de Opera está en http://dev.opera.com/articles/view/mama/, mientras que el de Google reside en https://code.google.com/webstats/.)

El punto fuerte de algo como HTML5 es que a todos les gusta una gran parte de él, debido a que es lo que ya funciona en los navegadores. Significa, por otro lado, que todo el mundo tiene que ceder un poco. Hay ciertas cosas en el lenguaje que me parecen horribles. Para mí, cosas como la forma en que se especifica el elemento time, la forma en que se especifica el elemento cite… Remy Sharp, mi coautor en Introducing HTML5, sé que piensa que la forma en que se especifica la API de ‘drag and drop’ es terrible… Pero la cuestión es que se puede vivir con todas las cosas que no te gustan, porque todos sabemos que todo el mundo tiene cosas que no le gustan. El potencial, si todo el mundo se aguanta y sigue dando pasos hacia adelante es enorme.

Así que sí, en cualquier gran empresa, con cinco fabricantes de navegadores trabajando juntos, cuando históricamente, digamos, esa no es necesariamente la forma en que se ha trabajado siempre, va a haber cosas raras, pero esas cosas raras se ven compensadas ​​por las enormes ventajas que supone.

Hay algo de exceso de publicidad, de ‘hype’ alrededor de HTML5, con un montón de gente diciendo cosas muy extrañas, como cuando Microsoft comenzó a hablar de “HTML5 nativo” para promover Internet Explorer, o bien unas cuantas demos que corren por ahí y funcionan sólo en un navegador, o un cierto motor… Creo que lo que estamos viendo es, en un grado mucho menor, muchos de los errores que estábamos haciendo en el año 2001, e incluso algunos de los que se cometieron con Flash …

Sí, estoy de acuerdo. Hay una sensación de contradicción. No es una contradicción, pero la gente puede ver como contradicción el hecho de que los fabricantes de navegadores trabajen juntos en una especificación interoperable. Así, por ejemplo, mi esposa: creo que en el trabajo usa IE6, utiliza Safari en el iPhone y usa Opera en el ordenador de casa. Es ridículo, en 2011, que un sitio web funcione en uno o dos de esos navegadores, pero no en los demás. Así que todos estamos trabajando juntos para hacer que todos los navegadores corran todos los sitios web. Pero, por supuesto, para los departamentos de marketing de esas organizaciones es una contradicción, porque si todo funciona en todas partes, ¿cuál es la diferencia entre navegadores? Y por eso, creo yo, estamos viendo tonterías como demos de HTML perfectamente válido que buscan la cadena de agente de usuario de un determinado navegador y te echan si no es el que estás utilizando, incluso cuando, con una detección de características inteligente, se podría hacer que funcionase en todas partes.

Contradicciones como que la gente de marketing use cosas como “HTML5 nativo”, por eso las estamos viendo, creo que hay una sensación de pánico, “¿cómo podemos diferenciar nuestro navegador”. La respuesta obvia es, por supuesto, como con cualquier otro software, que se compite en características. Por lo tanto, si te gusta especialmente el hecho de que Opera consume muy poca memoria, funciona en muchos dispositivos diferentes y tiene un montón de cosas incorporadas, utilizas Opera. Si te gusta mucho el hecho de poder usar tropecientos millones de extensiones, utilizas Firefox. Así que, volviendo a la pregunta, existen esos errores, pero diría que son errores cometidos por ingenuos departamentos de marketing. Y, por supuesto, hay gente nada ingenua que ve un carro al que subirse, y cuando ven ese carro ven una oportunidad para, o bien hacer algo de dinero con el SEO o hacer  dinero con páginas web para atraer tráfico, y de repente cualquier cosa remotamente novedosa que se puede hacer con un navegador se convierte en HTML5. Veo un montón de gente que me tuitea o me escibe correos y me dice “por favor, habla de mi sitio web HTML 5” y miro que han hecho y quizás, y sólo quizás, hay un doctype HTML5, pero a menudo es un doctype XHTML 1, y puede que un canvas, pero muy a menudo se trata tan solo de DHTML salido directamente de 1999 y Javascript que mueve divs por ahí, con algo de animación… Siempre habrá gente que no entiende los nombres y las tecnologías y su uso. Es una de esas cosas que pasan y no creo que debamos hacer nada más grave que eliminarlos de la órbita.

Tengo entendido que tienes un fuerte interés por la accesibilidad. Para ilustrar lo mucho que queda por hacer en ese campo, leí el otro día un artículo sobre cómo algunas tecnologías asistivas todavía no saben que en HTML5 puede haber múltiples h1 en diferentes niveles y que, por tanto, leen todos los encabezados al mismo nivel cuando no deberían.

La accesibilidad es vital, y así es como comencé mi carrera en los estándares web. La cosa con las tecnologías asisitivas es que la mayoría de ellas, cosas como los lectores de pantalla, o los magnificadores de pantalla, para personas que no son ciegas, pero necesitan la pantalla ampliada a tamaño gigante, la mayoría de estas cosas viven sobre los navegadores, como plug-ins para navegadores. Así que la razón por que la mayoría de los lectores de pantalla no saben que se pueden tener múltiples h1 con una jerarquía lógica en función del anidamiento es que los navegadores sobre los que funcionan no lo saben. Por lo que no necesariamente se puede culpar a las tecnologías asistivas. Sin embargo, el caso es que en el año 2008, creo, escribí al W3C y les pedí que invitasen a los proveedores de tecnologías asistivas a participar en el grupo de trabajo de HTML. El W3C me respondió diciendo: ‘de hecho, ya sabes, todo el mundo puede participar ya”, y yo contesté “sí, lo sé, pero esta gente representa a una comunidad especialmente vulnerable, o sea que escribámosles y invitémosles explícitamente”, y lo hicieron y… la mayoría de los proveedores de tecnologías asistivas declinó la invitación.

Hay un muy buen lector de la pantalla, llamado NDVA, en ndva-project.org que, hasta donde yo llego, está hecho, literalmente, por dos tipos ciegos en Australia, a partir de donaciones de grandes empresas, y comprenden muy bien las últimas tecnologías. Y, por supuesto desde RNIB (la ONCE británica) son muy activos en el grupo de trabajo de HTML5, y naturalmente Apple tiene el lector de pantalla VoiceOver, que viene de serie en todos los Mac y iDispositivos. Así que no es que todos los proveedores de tecnología tengan la cabeza escondida en la arena. Y, por supuesto, en algún momento, los clientes de esas tecnologías van a juzgar los productos que utilizan, y cuando dos de ellos están actualizados a las últimas tecnologías y los otros no, sólo puedo imaginar a dónde van a ir los usuarios conocedores de la tecnología, donde pondrán su dinero. Así es como el mercado resuelve estas cosas, no hay una solución tecnológica, diría.

Por lo general HTML5 es un paso adelante respecto a versiones anteriores por lo que respecta a la accesibilidad, ya que ha sido construido pensando en la accesibilidad desde el principio, de la misma manera que ha sido construido pensando en la seguridad desde el principio. Yo siempre digo que, dado que la mayoría de desarrolladores, o muchos, no la mayoría, no llegan a poner texto alternativo a las imágenes, las formas más complejas de marcar las cosas no llegan a usarse, y por eso HTML5 trata de incorporarlo todo al lenguaje, por decirlo de alguna forma. Además, lo que viene por defecto siempre es mejor que los accesorios puestos más tarde, porque si confías en que alguien vaya a añadir los accesorios más tarde, es casi seguro que no lo hará, mientras que si viene de serie se acostumbrarán a usarlo.

Y luego está el hecho de que AJAX ha complicado mucho la tarea de las tecnologías asistivas. ¿Cuál es su opinión sobre WAI-ARIA?

ARIA está diseñando deliberadamente para tapar los agujeros de las tecnologías más antiguas. Así, en lugar de volver a escribir tus páginas en HTML 5, páginas que pueden ser muy antiguas, o generadas por JavaScripts horribles… bien podría resultar más fácil de añadir unas cuantas tiritas WAI-ARIA que cambiar por completo el marcado.

Muchas de las cosas para las que se usa ARIA desaparecen con HTML5. Así, por ejemplo, en ARIA se puede decir role=navigation (rol=navegación) para decir que este div, o trozo de contenido, es un menú de navegación. En HTML5, por supuesto, basta con usar <nav>, que lleva incorporado de serie un rol ARIA implícito, o lo llevará, cuando las tecnologías estén acabadas de implementar, por lo que no tendrás que añadir un role=navigation en contenidos nuevos. Pero si estás remozando cosas viejas que tienes en un div, o puede que en una tabla o una tabla dentro de una tabla, o igual en una tabla dentro de un iframe dentro de una tabla … en lugar de refactorizar es posible que resulte más fácil escribir sólo role= navigation sobre el horror existente.

Así que ARIA es realmente bueno. Lo malo es que es una especificación compleja. La he leído un par de veces y la he encontrado muy difícil de entender. Por otro lado, HTML5 también me pareció increíblemente difícil de entender después de leer la especificación. Es una de esas cosas en que te tienes que lanzar y hacerlo.

Lo bueno de ARIA es que, en realidad, en gran parte es para sitios web dinámicos, así que en vez de que añadir el marcado a mano, muchas de las nuevas bibliotecas de JavaScript llevan WAI-ARIA incorporado. Por lo tanto, creo (no lo he probado en el último año) que Dojo, por ejemplo, cuenta con muy buen soporte para ARIA, así que si estás usando un widget de Dojo no tienes que preocuparte, ya que al usar la biblioteca, ya estás incorporando soporte para ARIA. Y, como he dicho, lo que viene de serie siempre gana a los accesorios añadidos, y sí, alguien ha hecho ya el trabajo por lo que, como desarrollador, no es necesario que añadas nada más.

Con HTML5, no en todos los casos, pero en muchos, ARIA está incorporado en el lenguaje. Pero ARIA no desaparece completamente, porque HTML5 es un lenguaje de marcado generalista, no es para todas las situaciones, por lo que habrá momentos en que necesites mejorar la accesibilidad con un poco de ARIA. El ejemplo obvio es cuando se hace uso de AJAX para mostrar un aviso “tienes correo nuevo, ¿quieres leerlo?”. Puede que estés usando un div, o no, o un elemento output, si estás trabajando con HTML5, pero en cualquier caso, basta con usar un rol ARIA para indicar que se trata de una región ‘viva’, y los lectores de pantalla estarán al tanto. Es fácil de hacer y valida en HTML 5, además.

Además del curriculum de estándares Opera, y teniendo en cuenta que las cosas cambian cada día, ¿cuáles son los recursos de aprendizaje que recomendarías a nuestros lectores si quieren estar a la última?

Si quieren estar a la última, deben tener en cuenta el hecho de que lo que es el estado del arte de hoy bien podría demostrar ser un giro equivocado en un futuro cercano. Recuerdo, por ejemplo, seguir todos los métodos de reemplazo de imágenes que había en 2003 y 2004, y todo el mundo estaba emocionadísimo por el primer mecanismo de reemplazo de imágenes que asignaba display:none al contenido y mostraba una imagen de fondo, hasta que alguien señaló que los lectores de pantalla, cuando se les indica display:none en el CSS, no anuncian el contenido y, por lo tanto, es inaccesible. Supongo que mi mensaje es, si quieres estar a la última, si quieres vivir en el filo de la navaja del estado del arte, tienes que mantenerte ahí. Porque, de lo contrario, puedes encontrarte con que al bajar del tren resulte que la técnica que sigues utilizando, en realidad podría haberse demostrado defectuosa…

Hay algunos unos cuantos muy buenos recursos que recomiendo. A List Apart es siempre un gran recurso. A veces los artículos son un poco demasiado sobre negocios o diseño para mi gusto, pero para gustos colores. A menudo hay buenas conversaciones en los blogs de Sitepoint. Yo recomiendo el Web Standards Group (webstandardsgroup.org), de Australia, un tipo llamado Russ Weakley tiene un muy buen correo semanal en el que recoge un montón de buenas noticias y enlaces. Además, hay una señora llamada Laura Carlson, que trabaja en la Universidad de Minnesota Duluth, y cada semana Laura envía un e-mail ‘web developments’, que no es más que una lista de todas las conversaciones interesantes que ha habido (http://www.d.umn.edu/itss/training/online/webdesign/). Si quieres estar al día con la accesibilidad web, una lista de correo muy buena y un blog muy bueno es WebAIM, que viene de Utah State University. Un buen amigo mío, llamado Jared Smith, se encarga.

Y recomiendo encarecidamente a los lectores que se mantengan bien lejos de w3schools (Ed: Hay una buena discusión sobre los peligros de w3schools en http://w3fools.org).

¿Y html5doctor.com?

Bueno, por supuesto, por supuesto… Soy británico, y por tanto muy reticente a dar a conocer mis propios sitios, pero sí, HTML5Doctor es un buen recurso para mantenerse al día, y de vez en cuando respondemos a las preguntas que recibimos por correo electrónico. También publico de vez en cuando algo en mi sitio web, una “reading list“, que es básicamente todos los enlaces que tuiteo durante la semana (Ed: en @brucel): me he dado cuenta de que muchos de los usuarios corporativos no tienen acceso a Twitter, por lo que nunca ven esos enlaces, y así…

Por último, ¿dónde ves a Opera en el futuro con todo esto? Los últimos meses tú, Chris Mills y Patrick Lauke, como mínimo, habéis estado publicando un montón de cosas fantásticas, espero que sigáis haciéndolo…

Bueno, Opera ha ido creciendo y creciendo y creciendo … Creo que cuando me incorporé a Opera, que fue hace tres años, estábamos llegando a cien millones de usuarios. La última vez que miré, que fue hace una temporada, estábamos en más de 170 millones, y ahora, hoy, con el lanzamiento de Opera 11.5, veo que estamos en 200 millones de usuarios activos, y eso no son descargas: es la gente que realmente utiliza el navegador en un mes determinado. Así, con el navegador que la gente, lamentablemente, tiende a olvidar, somos el mayor navegador móvil y estamos creciendo extraordinariamente. Siempre me gusta recordar que estoy muy comprometido con la interoperabilidad y con la libertad de elección. Sabemos que a nadie le encanta todo, sabemos que a esta persona no le gusta Opera, esa de ahí puede estar encantada con Chome, a aquella puede que le guste Firefox… Todo lo que pedimos que es (a) que pruebes Opera y (b) independientemente del navegador que utilices como navegador principal, como desarrollador web tienes la responsabilidad de tener al menos cinco iconos del navegador en el ‘dock’. Y si no pruebas en múltiples navegadores, no eres un desarrollador web, eres un desarrollador monoplataforma.

Hay herramientas fantásticas para probar en todas las situaciones. IE puede resultar difícil, porque no se pueden ejecutar varias versiones en paralelo. Con Opera, sabemos que mucha gente tiene gran dificultad en las pruebas con teléfonos móviles, un área en la que tradicionalmente somos fuertes. Claro, uno tiene que obtener el dispositivo, y puede que estés trabajando en un sitio privado, o con una web de preproducción… Si buscas el Opera mobile emulator, es un mal nombre para el producto, de hecho, porque no es un emulador, es exactamente el mismo código que el navegador del teléfono móvil, pero envuelto con un paquete instalable en el PC , Mac y Linux, y imita exactamente el código en el teléfono para que puedas probar sitios móviles en la máquina de escritorio, algo realmente muy útil, que ahorra tener que tener una configuración compleja… Y el proyecto Selenium tiene un driver para Opera que permite hacer pruebas de sitios web de forma automática, algo que es realmente importante.

Y vuestras herramientas de desarrollo, que son excelentes…

Por supuesto. Opera Dragonfly, que te permite hacer pruebas a distancia y depuración remota. Sí: probad todas estas cosas, me gustaría que Opera se convirtiese en vuestro navegador principal pero, si no es así, sigues teniendo que probar en Opera y Chrome y Safari y Firefox e Internet Explorer, por que la web ha de funcionar en todas partes.

…o debería hacerlo, por lo menos. Bueno, creo que te hemos robado suficiente tiempo. Gracias por una entrevista muy interesante.

Gracias, ha sido un placer.

Cita recomendada: CÓRCOLES, César. Bruce Lawson. Mosaic [en línea], julio 2011, no. 89. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n89.1137.