01-Un-nuevo-elemento-HTML-que-agilizará-tu-página web

La Web será más más rápida en un futuro cercano. Y, lamentablemente, esto es lo suficientemente raro como formar parte de las noticias.

Los topes de velocidad no llegarán porque nuestros dispositivos móviles sean más rápidos, aunque lo son. No será porque alguna gigantesca compañía creó algo genial, aunque ya lo hayan hecho. La Web será más rápida muy pronto porque un pequeño grupo de desarrolladores vio un problema y decidió resolverlo a favor de todos nosotros.

El problema son las imágenes. A partir de 2014, el tamaño de una página web promedio entre las 1000 más importantes es de 1.7 MB. Las imágenes ocupan casi 1MB de dicho peso.

Si tienes una conexión de fibra, esa carga de las imágenes no es importante, pero cuando usas un a conexión móvil, esa enorme carga no solo está ralentizando la carga, sino que también está usando tu limitada banda ancha. Dependiendo de tu plan de datos móviles, esto te puede estar costando dinero.

Lo que hace de esa carga de imagen doblemente fastidiosa cuando usas un dispositivo móvil es que estás intentando hacer que imágenes destinadas a grandes pantallas carguen en una un poco más grande que la palma de tu mano. Es una pérdida de banda ancha mostrar píxeles que la mayoría de nosotros nos necesitamos.

Los desarrolladores web identificaron este problema tempranamente en el crecimiento de lo que se llama web «móvil». Recientemente, algunos de ellos se juntaron para hacer algo que los desarrolladores web nunca hicieron—crear un nuevo elemento HTML.

En el inicio era la «web móvil»

Navegar la web en tu teléfono no siempre ha sido lo que es ahora. Incluso en el primer iPhone, uno de los teléfonos con un navegador web real, era bastante terrible.

En aquellos tiempos, navegar en una página web desde pantalla pequeña requería una constante acercamiento en contenidos optimizados para pantallas muchas más grandes. Tomaba un siglo cargar las imágenes en la lenta conexión de red EDGE (Tasas de Datos Mejoradas) del iPhone, y luego estaba todo el contenido flash. Eso no cargaba nunca. Eso fue en el iPhone; navegar la web usando un Blackberry u otro sistema operativo averiaba los navegadores móviles. De alguna manera, era peor.

No era necesariamente la culpa de los dispositivos, aunque los navegadores móviles se detenían, y en mucho casos  lo siguen haciendo. La mayor parte de la culpa era de los desarrolladores web. La web es, por naturaleza, flexible, pero los desarrolladores web lo confinaron al optimizar las  para monitores grandes de computadoras.

Para abordar esto, muchas páginas web empezaron a crear una segunda página web. Ahora suena loco, pero solo hace algunos años, la solución para lidiar con los nuevos dispositivos como Blackberry, el entonces nuevo iPhone y algunos de los primero teléfonos Android era usar un script detector al lado del servidor y direccionar los usuarios a una página web dedicada a dispositivos móviles, por lo general una URL como m.dominio.com.

Estas URL dedicadas para dispositivos móviles —con frecuencia referidas como páginas web móviles— usualmente carecían de varias características encontradas en su «real» contraparte de escritorio. Con frecuencia, las páginas, ni siquiera, redireccionaban bien, dejándote en la página de inicio cuando buscadas un artículo específico.

Las páginas web móviles son un buen ejemplo de que los desarrolladores encontraron un problema y descubrieron una forma de empeorarlo. Por suerte para nosotros, la mayoría de los desarrolladores web no se unieron al rebaño de las páginas web móviles porque algo mejor llegó.

El diseño responsive aniquiló la estrella de las páginas web móviles

En 2010, el desarrollador web Ethan Marcotte escribió un pequeño artículo sobre algo que llamó Diseño web responsive

Marcotte sugirió que, con toda la proliferación de dispositivos móviles y el dolor de crear páginas web dedicadas a estos dispositivos, tendría más sentido abrazar la naturaleza fluida de la web. En vez de eso, sostuvo que se debía crear páginas web más flexibles. Marcotte imaginó páginas que usaban bandas relativas para encajar en cualquier pantalla y funcionar bien sin importar el dispositivo donde se acceda.

02-Un-nuevo-elemento-HTML-que-agilizará-tu-página web

La visión de Marcotte brindó a los desarrolladores una forma de crear páginas que estiren y acomoden su contenido basado en el tamaño y características del dispositivo en mano. Y mientras que el diseño responsive no era, tal vez, una panacea, estaba muy cerca a serlo.

El diseño responsive empezó cuando algunos desarrolladores prominente hicieron sus páginas web personales responsive, pero despegó rápidamente cuando Marcotte y los desarrolladores del Filament Group rediseñaron el The Boston Globe para  hacerlo responsive. El rediseño del Globe mostró que el diseño responsive funcionada mejor que para los portafolios y blogs de los desarrolladores. Este rediseño mostró que este tipo de diseño era el camino hacia el futuro.

Mientras que el rediseño tenía éxito desde el punto de vista del usuario. Marcotte y el Filament Group se encontraron con algunos problemas detrás de bambalinas, en particular con las imágenes. El artículo original de Marcotte lidiaba con las imágenes al bajarles la escala usando CSS. Esto hizo que las imágenes encajaran pantallas más pequeñas y preservara el plano de diseño, pero también significaba que los dispositivos móviles cargarían imágenes grandes sin intención de ser mostradas con resolución completa.

En la mayor parte, esto sigue ocurriendo en casi cada página web que visites con una pantalla pequeña. Los desarrolladores web saben, así como lo supieron los desarrolladores que crearon el Globe, que es esto es un problema. Aún así, resolver eso no es tan fácil como parece a primera vista.

Ese dilema es lo que nos trajo ahora. Resolver este problema requirió añadir un elemento HTML nuevo.

Presentando el elemento Picture.

La historia del elemento Picture inicia con los desarrolladores web trabajando en el Boston Globe, incluyendo a Mat Marquis, quien sería, eventualmente, el coautor de la especificación HTML.

Sin embargo, al inicio, ninguno de los que trabajaban en el proyecto considerada crear nuevos elementos HTML. Marquis y los otros desarrolladores solo deseaban crear una página web que cargara rápido en dispositivos móviles.

Como Marquis explica, pensaron tener una solución. «Comenzamos con una imagen para dispositivos móviles y luego mejorar desde ahí. Usaron coockies y JavaScript. Funcionó hasta una semana antes del lanzamiento».

Por este tiempo, tanto Firefox como Chrome empezaron a actualizar sus capacidades de precargar y las nuevas herramientas de precarga de imágenes quebró el método usado por los prototipos del Globe. La precarga de navegadores se convirtió en más que solo un problema para la solución original del Globe; en realidad el punto decisivo de lo que es difícil sobre las imágenes responsive.

Cuando un servidor envía una página a tu navegador, este último descarga primero todo el HTML en la página y luego la analiza. Al menos eso es lo que ocurría. Los navegadores modernos intentaron acelerar el tiempo de carga al descargar las imágenes antes de analizar el cuerpo de la página. El navegador empieza descargando la imagen mucho antes de saber dónde estará en el diseño de la página o cuán grande necesitará ser.

Esto es, simultáneamente, algo bueno—significa que las imágenes podrán cargar más rápido—algo muy ingenioso. Significa que usar JavaScript para manipular imágenes puede, en realidad, ralentizar tu página web, incluso cuando tu JavaScript está tratando de carga imágenes pequeñas (porque terminas luchando con la herramienta de precarga y descargando dos imágenes)

Marquis y el resto de los desarrolladores que trabajaron en la página web tuvieron que fragmentar su plan original y regresar al cuaderno de dibujo. «Empezamos tratando de debatir alguna solución que pudiésemos usar en adelante… pero nada realmente materializado.» Sin embargo, empezaron a escribir sobre el problema, y otros desarrolladores se unieron a la conversación. Supieron, rápidamente, que no estaban solo luchando con las imágenes responsive.

«Para este tiempo,» Marquis comenta, «contamos con 10 o 15 desarrolladores web, y a nadie se la ha ocurrido nada.»

La página web del The Globe fue lanzada sin solución alguna. Los dispositivos móviles se quedaron estancados descargando enormes imágenes.

03-Un-nuevo-elemento-HTML-que-agilizará-tu-página web

La página web de The Globe en tamaños para celular, tablet y computadoras de escritorio.

Pronto otros desarrolladores de renombre fuera del proyecto Globe empezaron a aportar soluciones, incluyendo Paul Irish de Google y Bruce Lawson de Opera. Pero nadie podía diseñar una solución que cubriera todos los posibles casos de uso que los desarrolladores identificaron.

«Pronto nos dimos cuenta,» dice Marquis, «que, aun si fuésemos capaces de resolver esto con un poco de ingenio de JavaScript, estaríamos trabajando alrededor optimizaciones de nivel de navegadores en vez de trabajar con ellas.» En otras palabras, usar JavaScript significaba luchas con la precarga de imágenes que incluían los navegadores.

Las discusiones pronto de trasladaron hacia problemas de menor nivel, incluyendo el nuevo elemento HTML que podría, de alguna forma, llegar a los problemas de precarga de imágenes en una forma que el JavaScript nunca haría. Fue Bruce Lawson quien, primero, sugirió que un nuevo elemento de imagen estuviera en orden. Aunque no lo sabían para ese entonces, un elemento de imagen ya había sido propuesto una vez, pero nunca llegó a nada.

Bienvenidos a la selva de estándares

Una cosa es decidir que se necesita un nuevo elemento HTML, pero es otra cosa navegar en el estratificado y laberíntico mundo de los estándares Web —especialmente si nadie de tu equipo ha hecho tal cosa alguna vez.

Aunque, tal vez, lo mejor de ser inocente es que tiendes a abrirte paso sin la duda que sucumbe a alguien que sabe cuán difícil será el camino por delante. Y, así, los desarrolladores que trabajaron en el elemento de imagen tomaron sus ideas al WHATWG (Web Hypertext Application Technology Working Group), uno de los grupos supervisa el desarrollo del HTML. El WHATWG está conformado, básicamente, por estudios de navegadores, lo que lo coloca en un buen lugar para medir qué tan probable es que los navegadores trasladen tus ideas.

Para parafraserar a Tosltoy, cada cuerpo estándar es infeliz en su propia forma. Como Marquis estaba a punto de aprender, el WHATWG es, tal vez, el menos feliz cuando personas fuera del grupo realizan sugerencias sobre lo que se debería hacer. Basta con decir que Marquis y el resto de los desarrolladores involucrados no lograron que el WHATWG se interesara en un nuevo elemento HTML.

Ya por este tiempo, el W3C —que es donde se ubica el segundo grupo que supervisa el HTML y el HTML WG— lanzó una nueva idea llamada «grupos de comunidad.» Estos son el intento de W3C por llegar a personas se involucraran en el proceso de estándar, un lugar para proponer problemas y trabajaran en soluciones.

Luego de haber sido derribado por el WHATWG, alguien sugirió que los desarrolladores inicien una comunidad web. Así nació el Responsive Images Community Group (RICG).

04-Un-nuevo-elemento-HTML-que-agilizará-tu-página web

El único problema con los grupos de comunidad es que nadie en los grupos activos toma ninguna atención a las comunidades o, al menos, no lo hacían el 2011.

Felizmente sin conocimiento de esto, Marquis y cientos de otros desarrolladores debatieron una solución de imágenes responsive en el grupo.

Mucho de ese esfuerzo se dio gracias a Marcos Cáceres, que ahora trabaja en Mozilla. A diferencia del resto de los miembros del grupo, Cáceres tenía algo de experiencia en escribir estándares web. Dicha experiencia le permitió abarcar las diferencias entre dos mundos: el desarrollo web y el desarrollo de estándares. Cáceres organizó los esfuerzos de RICG y ayudó al grupo producir el tipo de casos de uso y tesis que los cuerpos estándares estaban buscando. Como Marquis dice, «Marcos nos vio fallar en nuestra comunidad de imágenes responsive y decidió ayudarnos a organizar todo.»

«Traté de juntar a todos los gatos,» Cáceres bromea. Y lo hizo. Él estableció el respos de Github para tener todo en un solo lugar, configuró un espacio para la página web de imágenes responsive y ayudó a juntar todo en el primer documento de casos de uso. «Esto jugó un papel realmente crítico para mí y el resto de la comunidad,» comenta Cáceres. «Nos forzó a expresar lo que era el problema real… y a establecer prioridades.»

Luego de meses de esfuerzo, el RICG llevó sus ideas la comunidad de imágenes responsive WHATWG IRC. Esto tampoco salió muy bien. Como Cáceres dice, «a los cuerpos de estándares les gusta decir ‘oh, queremos bastante aporte de desarrolladores web,’ pero luego los desarrolladores llegan, terminan en lágrimas. O solían hacerlo»

Si lees los registros de WHATWG IRC de ese tiempo, verás que sus miembros caen en una clásica trampo «no se inventó aquí». No solo rechazaron los aportes de los desarrolladores, sino que les dieron la espalda y, sin considerar el trabajo del RICG, propusieron su propia solución. Era algo llamado  set, un atributo que resolvía solo uno de los muchos casos de uso que Marquis y compañía habían identificado.

Los desarrolladores web se quedaron, claramente, con bronca.

Con los desarrolladores presionaron el elemento de imagen, y los creadores de navegadores y cuerpos estándares favorecieron la más limitado y confuso (aun así útil) propuesta set, desde que lo renombraron srcset, pareció que nada nunca habría venido del trabajo del RICG.

Como Paul Irish coloca en el canal WHATWG IRC, «[Marquis] juntó y lideró un grupo de los mejores desarrolladores de web móviles, creó una comunidad, aisló una solución (de muchas), luchó y ganó un consenso dentro del grupo, escribió una especificación en borrador y la propuso. Básicamente hizo lo que las personas que se encargan de los estándares quieren que hagan los ‘autores’. Razón por la cual esto se siente mucho como una derrota.

Irish no estaba solo. La protesta del desarrollador entorno de la contrapropuesta de WHATWG fue muy fuerte, lo suficientemente para que surgieran otras propuestas. Pero los creadores de navegadores fallaron al acordar algo. Mozill mató las ideas de WHATWG de srcset en imágenes; Chrome se rehusó a implementar Picture, que era definido por ese entonces.

Si eso suena como una mala novela, bueno, lo fue. Este proceso es, lo creas o no, cómo se hace la web que estás usando ahora mismo.

Inventado aquí

Para el crédito de WHATWG, el grupo, eventualmente, se sobrepuso de su síndrome «no inventado aquí» o, al menos, lo hicieron parcialmente.

Los compromisos empezaron a suceder. El RICG mostró apoyo a muchas de las ideas añadidas en su propuesta. Eso no fue suficiente para convencer a WHATWG, pero hizo que algunos miembros trabajaran juntos con Marquis y el RICG. A WHATWG aún no le gustaba Picture, pero tampoco lo rechazaban.

Para alguien ajeno, el proceso de revisión parece, de algún modo, a un juego de Ping Pong, excepto que cada vez que alguien tocaba la pelota, esta cambiaba de forma.

El gran avance de Picture vino por parte de Simon Pieter, de Opera, y Tab Atkins, de Google. Ellos lo hicieron una simple, pero potente, sugerencia —hacer de Picture una envoltura de img. De esa forma no habrían dos elementos separados para las imágenes de la web (que era considerado confuso, con razón), pero aún existía una nueva forma para controlar qué imagen un navegador presenta.

Este es exactamente el enfoque usado en la versión final de la especificación de Picture.

Cuando el navegador encuentra un elemento Picture, primero evalúa cualquier regla que el desarrollador web pueda especificar. Luego, después de evaluar las diversas reglas, el navegador escoge las mejores imágenes basado en su propio criterio. Esta es otra característica especial debido a que el criterio del navegador puede incluir tus configuraciones. Por ejemplo, los futuros navegadores pueden ofrecer una opción para detener imágenes de alta resolución en redes 3G, sin importar lo que cualquier elemento Picture pueda decir. Una vez que el navegador sabe cuál imagen es la mejor opción, carga y muestra la imagen en un buen y viejo elemento img.

Esto resuelve dos problemas. Con el problema de la precarga de los navegadores, la precarga aún existe y no hay penalidad de rendimiento. Y sobre el problema de qué hacer cuando el navegador no entiende Picture, ahora todo recae en lo que sea que diga en la etiqueta  img.

En la propuesta final, lo que sucede es que Picture envuelve una etiqueta img. Si el navegador es muy viejo para saber qué hacer con un elemento <picture, entonces carga el plan b de etiqueta img. Todos los beneficios de accesibilidad continúan porque todos los atributos aún siguen en el elemento img.

Todo el mundo está feliz, y la web sale ganando.

Buena teoría, pero muéstrame el navegador

La web solo gana si los navegadores realmente pueden soportar un estándar propuesto. Y, a esta altura del año, ningún navegador de la web soporta Picture.

Mientras que Firefox y Chrome se comprometieron con brindar el soporte, puede que pase años antes que sea una prioridad para ambos. Picture era más como uno bonita teoría.

Entró Yoav Weiss, un excepcional desarrollador que abarca los mundo del desarrollo web y el desarrollo C++. Weiss era un contratista independiente que quería que Picture se convirtiera en parte de la web. Weiss sabía que el C++, el lenguaje en que la mayoría de los navegadores están escritos, pero nunca antes trabajó en un navegador web.

Aun así, al igual que Cáceres, Weiss fue capaz de llenar un vacío, en este caso, el mundo de los desarrolladores web y los desarrolladores C++. Estaba en una posición única para ser capaz de saber lo que Picture necesitaba hacer y cómo lo haría posible. Luego de hablar con los desarrolladores de Chromium, Weiss empezó a hackear a Blink, el motor de renderización que  da poder al navegador Chrome de Google.

Implementar Picture no fue una tarea fácil. «Hacer que Picture ingrese a Blink requería algo de infraestructura que no había,» comenta Weiss. «Tenía dos opciones: o esperar que la infraestructura llegara naturalmente en el transcurso de los siguientes dos años o hacerla yo mismo.»

Weiss —quien, accidentalmente, tiene tres hijos jóvenes y, presumimos, no mucho tiempo libre— se dio cuenta, rápidamente, que trabajar por las noches y los fines de semana no iba a ser suficiente. Weiss necesitaba convertir su trabajo en Picture en un contrato de trabajo. Así que él, Marquis y lo demás se involucrados en la comunidad crearon una campaña de financiación masiva en Indiegogo

Aparentemente, suena como una desafortunada proposición. ¿Por qué los desarrolladores fundarían una característica que, al final, terminará en un navegador web donde ellos no tendrían el control? Pero ocurrió algo sorprendente. La campaña no solo logró su objetivo, lo sobrepasó. Los desarrolladores querían tanto contar con Picture que decidieron invertir su dinero en la causa.

Podrían haber sido polos. Podría haber sido una novedad. O podría  haber sido que los desarrolladores web vieron cuán importante era una solución al problema de las imágenes de una forma que los creadores de navegadores y los cuerpos estándares no lo tenían. Lo más probable es que fuese una combinación de todo lo anterior y más.

Se recaudó suficiente dinero no solo para implementar Picture en Blink, sino para trasladar el trabajo de Weiss de regreso a WebKit de modo que los navegadores WebKit (incluyendo la versión iOS de Safari de Apple) la puedan usar. Todo al mismo tiempo, Cáceres empezó a trabajar en Mozilla y ayudó a generar el soporte de Firefox para Picture.

A partir de ahora, el elemento Picture está disponible en Chrome y Firefox desde diciembre. Ahora está disponible en el canal de dispositivos de Chrome y el Firefox 34+ (en Firefox necesitarás habilitarlo en acerca de:configuraciones).

Opera, también basado en Blink, podrá respaldar Picture en un futuro cercano. Apple parece añadir el soporte a Picture a través del traslado hacia WebKit, aunque no lo terminó a tiempo para el Safari 8. Al igual que los demás, Microsoft ha sido comprensivo y está considerando Picture para el siguiente lanzamiento de IE.

El futuro de la web

La historia del elemento Picture no es solo un cuento interesante sobre desarrolladores web trabajando juntos para hacer de la web un lugar mejor. También se trata de echar un vistazo al futuro. La separación entre aquellos que construyeron la web y aquellos que crearon los estándares web está desapareciendo. Las comunidades W3C está creciendo, y las páginas web como Move the Web Forward apuntan a llenar el vacío entre las ideas de desarrollo y los cuerpos de estándares.

Incluso existe una página web llamada «specification» —que brinda a los desarrolladores web un lugar para sugerir las herramientas que necesitan, discutir posibles soluciones, y luego encontrar grupos de trabajo W3C para hacerlas posibles.

Picture puede estar casi lista, pero el RICG no irá a ningún lado. De hecho, se mantiene y se está haciendo cargo de un nuevo proyecto: Element Queries.

Si este artículo te pareció interesante, no dudes en compartirlo. Y si buscas una agencia digital que pueda crear tu página web, llegaste al lugar indicado. Staff Creativa es una empresa de diseño web que cuenta con más de diez años de experiencia. ¡No dudes en contactarnos!

Este artículo fue originalmente publicado en ars technica, y ha sido traducido y adaptado al español por Staff Creativa, agencia de marketing digital en Lima, Perú. Si encuentras contenido online en inglés sobre diseño de páginas web, gestión de imagen corporativa, marketing digital o packaging, no dudes en contactarnos. Nos encargaremos de traducirlo y publicarlo, y te avisaremos!

The following two tabs change content below.

One Comment

Deja una respuesta