Picturefill 2.0: imágenes responsivas y el Polyfill perfecto

Hemos visto muchas permutaciones de imágenes en diseño responsivo y pasamos mucho tiempo dando vueltas, golpeándonos la cabeza y gritando a la pared. Pero nuestro incansable viaje está llegando a su fin. El W3C y los fabricantes de navegadores entendieron la indirecta. Hemos recorrido un largo camino con imágenes responsivas. Podemos ver la luz al final del túnel, pero aún queda mucho trabajo por hacer.

Desde los primeros días de los estándares web, no había visto a nuestra comunidad reunirse en torno a un tema aparentemente pequeño: las imágenes responsivas.

Durante los últimos cuatro años (sí, han pasado aproximadamente cuatro años), hemos visto muchas permutaciones de imágenes en el diseño responsivo. Desde los días más perezosos de configuración max-width: 100%(lo mínimo absoluto que debería hacer) hasta implementaciones de JavaScript con más funciones, como Picturefill y data-interchangeel método de Zurb, hemos pasado mucho tiempo dando vueltas, golpeándonos la cabeza y gritando a la pared. . Me alegra decir que nuestro incansable viaje está llegando a su fin. El W3C y los fabricantes de navegadores entendieron la indirecta.

El estado de las imágenes responsivas

En nuestra búsqueda del santo grial de ofrecer la imagen correcta al usuario, nuestra actitud hacia los fabricantes de navegadores hasta ahora ha sido en gran medida: "Olvídate, lo haremos nosotros mismos". Ciertamente no soy una excepción. Estuvimos tan atentos a las imágenes responsivas y estuvimos expuestos a todas las conjeturas y pruebas que normalmente no se hacen públicas que nos impacientamos (con razón) y lo hicimos con JavaScript.

La diferencia entre una transición CSS y una imagen responsiva es, por supuesto, cómo se degradan . Si una transición CSS no funciona, ¿a quién le importa realmente? Su interfaz puede ser un poco inestable, pero la experiencia en su conjunto no se verá afectada porque sus usuarios aún podrán lograr su objetivo y consumir el contenido que necesitan.

En realidad, ese no es el caso de las imágenes. ¿Cómo se degrada una nueva etiqueta de imagen? La imgetiqueta tiene tanta aceptación que ni siquiera pude encontrar cuándo la recomendó el W3C como estándar, aparte de una pequeña referencia en la especificación HTML 4.01 . Reemplazar o incluso expandir la imgetiqueta sería como decirle a Frank Sinatra que use una gorra de béisbol en lugar de un sombrero de fieltro: obtendrás algunas reacciones negativas.

Problemas de recursos

A medida que el diseño responsivo creció en popularidad y los medios a través de los cuales los usuarios consumen información se volvieron incontrolables, poco a poco nos dimos cuenta de que eso imgpor sí solo no iba a ser suficiente. Comenzamos a hacer preguntas como: "¿En qué tamaño de pantalla está el usuario?" y "¿Cuál es la densidad de píxeles de la pantalla?" Estas preguntas alimentaron nuestras técnicas de imagen hasta que nos dimos cuenta de que el tamaño de la pantalla y la densidad de píxeles no tienen absolutamente ninguna relación con la cantidad de ancho de banda disponible para ofrecer una imagen enorme de alta definición.

El RICG comenzó a trabajar en el pictureelemento, compartiendo su trabajo con el W3C a lo largo del camino.

Las soluciones se volvieron bastante complejas. Se empezó a hablar del pictureelemento y apareció un grupo llamado Responsive Images Community Group (RICG). El RICG comenzó a trabajar en el pictureelemento, compartiendo su trabajo con el W3C a lo largo del camino. El resultado nos ha llevado al día de hoy y a esta discusión sobre todo el progreso que se ha logrado.

La introducción desrcset

Debido a que la mayor parte de la comunidad de imágenes responsivas estaba de acuerdo con el pictureelemento y lo esperaba debido a los fantásticos polyfills, como Picturefill, siguió adelante y publicó un documento bien pensado y desarrollado que describe algo llamado srcset, que es una extensión de la imgetiqueta estándar. Sí, lo sé, parece que surgió de la nada. También era súper complicado y demasiado limitante al restringirlo a valores de píxeles (implícitos) y usar una microsintaxis que no permitía escalabilidad con consultas de medios en el futuro. Afortunadamente, la sintaxis ha madurado hasta convertirse en lo que tenemos hoy, lo cual es una recomendación bastante sólida.

Más recientemente, Andrew Clark lo dijo mejor cuando tuiteó : “Miré los atributos srcset y tamaños de imágenes responsivas por primera vez. Caray, es complicado”.

Ni yo mismo podría haberlo dicho mejor. Veamos a qué nos enfrentamos:

img alt="dog" src="dog.jpg"  

En el fragmento anterior se encuentran tres atributos principales alt: srcy srcset. El altatributo es el mismo de siempre; srces la alternativa si srcsetno es compatible; y srcsetobviamente aquí es la carne y las patatas.

Podemos ver tres argumentos en srcset. La primera es la ruta de la imagen. El segundo le da al navegador información sobre los anchos naturales de las fuentes, para que sepa qué recurso servir al usuario (basado en las preferencias del usuario y en referencia cruzada con el sizesatributo ; les dije que era complicado). La última parte establece la proporción de píxeles opcional ( 2xen este ejemplo especifica la imagen de alta definición).

Una cosa que realmente me encanta srcsetes que la especificación establece que el navegador debe contener preferencias de asignación de imágenes para determinadas situaciones de ancho de banda. Esto significa que no tiene que preocuparse por mostrar una 2ximagen en una pantalla de alta definición si ese dispositivo tiene una mala conexión 3G. Las preferencias del usuario deberían tomar el control y el navegador elegiría la imagen adecuada para mostrar.

Preparándose para el pictureelemento

Después de muchas quejas sobre nuestro nuevo y extraño amigo, srcsetel RICG continuó trabajando en el pictureelemento, que finalmente está obteniendo una gran aceptación entre los fabricantes de navegadores... bueno, es decir, con Chrome. La sintaxis propuesta para el pictureelemento puede parecer familiar porque la vimos en gran medida en la primera versión de Picturefill, y no es diferente a cómo se marcan audioy .video

picture  source media="(min-width: 600px)"  img alt="A fat dog" src="small-1.jpg"/picture  

Como puede ver, sourcehay una etiqueta en el pictureelemento, junto con una imgetiqueta normal. Tal como vimos srcen srcset, imges una alternativa. En la sourceetiqueta, tenemos lo que parece una consulta de medios, junto con un srcsetatributo que contiene los mismos argumentos de fuente de imagen y densidad de píxeles que antes. Esta parece una forma agradable y limpia de popularizar las imágenes responsivas; Generalmente estamos familiarizados con la sintaxis, por lo que debería adoptarse fácilmente.

Soporte del navegador

El srcsetatributo ha sido compatible con Chrome desde la versión 34. Al momento de escribir este artículo, no es compatible con ningún otro lugar. Mozilla parece estar trabajando en una implementación (crucemos los dedos). Internet Explorer no está a la vista.

El pictureelemento tiene un apoyo aún peor; Ni siquiera está todavía en Chrome. Pero al igual que Mozilla con Google srcset, Google está trabajando actualmente en implementarlo. Si puede soportar leer una especificación, lo recomiendo encarecidamente. Aunque no tiene mucha trama y el desarrollo de los personajes es bastante débil, sigue siendo una lectura bastante buena.

Picturefill 2.0 se creó porque el soporte nativo es razonablemente cercano . Sabes que necesitaremos un polirelleno sólido como una roca para usarlo cuando llegue oficialmente el momento, ¡así que echémosle un vistazo!

Presentamos Picturefill 2.0

Picturefill 2.0 se lanzó recientemente como versión beta y es un salto bastante grande con respecto a la versión 1. El RICG realmente tenía como objetivo crear una solución integral para imágenes responsivas . El desafío era crear un script que le permitiera a usted, el desarrollador, usar cualquier combinación de las soluciones que se están estandarizando actualmente, sin inflarlo hasta el punto de que no usarlo en absoluto sería más liviano.

Imagínese rellenar una imagen que normalmente tardaría 2 segundos en cargarse usando un archivo JavaScript que tarda 10 segundos en cargarse; no tendría mucho sentido. Picturefill 2.0 evita esto siguiendo muy de cerca la especificación (con algunas omisiones intencionales, que repasaremos más adelante) y permitiéndole usar una srcsetcombinación picturede ambas.

Picturefill es un enfoque de imagen receptivo que imita el elemento de imagen propuesto utilizando divs. ( Versión más grande )

Si bien no podemos lograr de manera confiable todo lo que está en la especificación usando JavaScript (como detectar razonablemente el ancho de banda, que de todos modos sería una configuración del usuario), ciertamente podemos encargarnos de todas las piezas que deben estar en HTML (es decir, elementos y atributos). Esta versión de Picturefill nos acerca un paso más a no necesitar Picturefill, que es el objetivo final de cualquiera que alguna vez haya escrito un polyfill.

Si actualmente estás utilizando la versión 1.0, te recomiendo encarecidamente que actualices a la 2.0. Es un gran paso hacia una mejor solución para ofrecer la imagen correcta al usuario. Se han realizado algunos cambios importantes en la sintaxis y la funcionalidad. Veamos las novedades.

¿Qué hay de nuevo en 2.0?

Una cosa que hace que este polyfill sea diferente de otros que he visto es que rellena un concepto, no solo un bloque de HTML no compatible. Picturefill 1.0 utilizó intervalos y atributos personalizados para imitar cómo pensábamos que deberían funcionar las imágenes responsivas. Para que conste, es una gran solución y actualmente la uso para muchos de mis proyectos que no se han convertido a 2.0.

En el último año, las especificaciones de srcsety picturehan madurado mucho, por lo que ahora podemos utilizar algo parecido a la sintaxis real. Picturefill está empezando a parecerse a un verdadero polyfill, uno que podemos eliminar cuando aparezca un soporte real.

Instalación y uso de Polyfill

Si ha leído hasta aquí, probablemente haya tratado con algún tipo de polyfill en el pasado. Éste no es muy diferente. Se supone que los Polyfills se configuran y se olvidan (para robarle una línea a Ronco ), pero debido a que se trata de un Polyfill HTML, necesitarás crear el pictureelemento manualmente o usar algún tipo de HTML shiv para hacerlo. para ti. Afortunadamente, las herramientas HTML son bastante comunes y se entregan con kits de herramientas como Modernizr ; simplemente verifique que picturesea compatible con cualquier shiv que elija.

!-- Create the actual picture element if you haven’t already. --script  document.createElement( "picture" );/script!-- Asynchronously load the polyfill. --script src="picturefill.js" async/script  

Además de crear el pictureelemento, simplemente debes vincularlo al script. También se recomienda usar el asyncatributo, para que Picturefill no bloquee la carga de su página.

Usando Picturefill 2.0 con srcset

Veamos la sintaxis que proporciona el mejor soporte y que utiliza srcset. Debería resultarnos familiar porque tiene los mismos atributos que vimos cuando hablamos de la especificación.

imgsrcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama"  

La diferencia más evidente entre este fragmento y la especificación es la ausencia de un srcatributo alternativo, que se eliminó intencionalmente para evitar que las imágenes se descarguen dos veces en navegadores no compatibles. Y, realmente, ¿qué sentido tendría esto si las imágenes se descargaran dos veces? Aparte de eso, es bastante fiel a la especificación, pero probablemente evolucionará con el tiempo a medida que la especificación se desarrolle y el polyfill madure.

El sizesatributo le dice al navegador el tamaño de la imagen en relación con la ventana gráfica. Esto a menudo se pasa por alto porque srcsetes la palabra de moda ahora, pero este atributo es igualmente importante. Si desea obtener más información, Eric Portis tiene mucho sentido en este "lío tremendamente complicado".

Usando Picturefill 2.0 con el pictureelemento

El RICG hizo un trabajo tan bueno con esta segunda versión de Picturefill que la sintaxis del pictureelemento no debería sorprender. Coincide muy de cerca con la especificación:

picture  source media="(min-width: 1000px)"  source media="(min-width: 800px)"  source  img alt="Cambodia Map"/picture  

El mayor cambio entre las versiones 1.0 y 2.0 es la eliminación de algunos HTML tradicionales (divs y spans) y la adición de elementos más nuevos ( picturey source). Además, srcsetel soporte está integrado (diablos, ¿por qué no, verdad? ¡Está en las especificaciones!). Este es un gran paso adelante para este polyfill.

Utilice tantas o tan pocas de estas opciones como desee. De acuerdo con la especificación, si no desea utilizar la 2xopción, no es necesario (y así sucesivamente). La diferencia entre este y el pictureelemento oficial es el imgrespaldo . Notarás aquí que el imgrespaldo también tiene un srcsetatributo, en lugar de uno normal src(que es ampliamente compatible). Nuevamente, esto es para evitar la doble descarga (es un problema real). El srcsetcontenido de la imgetiqueta también provocaría una doble descarga si el navegador lo admite srcsetpero no picture. Este error debería solucionarse en la versión beta.

Como muchos buenos polyfills, Picturefill 2.0 se puede ejecutar mediante programación exponiendo una función global, picturefill(). Esto le permite usarlo en cualquier marco de JavaScript ultramoderno que desee. Puede leer sobre algunas opciones para orientar imágenes específicas en la documentación de la API .

Degradando con gracia

Anteriormente en el artículo, aludí al desafío de degradar la imgetiqueta correctamente en navegadores no compatibles. Este fue otro problema al crear Picturefill 2.0. Debido a que es un polyfill, el concepto de navegadores no compatibles realmente no existe (más o menos): estamos usando JavaScript para forzarlo a funcionar.

El caso límite es el siguiente: si un navegador no admite de forma nativa JavaScript pictureo srcset tiene JavaScript desactivado, se le fruncirá el ceño. Ya puedo sentir que pones los ojos en blanco, pero conocer las limitaciones de un sistema es importante antes de confiar en él a gran escala. Si un usuario se encontrara con una imagen con Picturefill en un navegador no compatible con JavaScript desactivado, vería el alttexto de la imagen, una pequeña manera agradable de reforzar la importancia del alttexto descriptivo y significativo, ¿no es así?

El texto alternativo es la alternativa porque la noscriptsolución anterior causaba problemas con los navegadores que admiten pictureo srcsettienen JavaScript deshabilitado (se representarían dos imágenes). El grupo también exploró agregar un srcatributo img(como en la especificación), pero eso resulta en una doble descarga, lo que frustra el propósito de asignar los recursos de imagen apropiados al usuario.

Hemos recorrido un largo camino con imágenes responsivas. Podemos ver la luz al final del túnel, pero aún queda mucho trabajo por hacer. ¡Y nos encantaría tu ayuda!

Cómo participar

Si desea involucrarse y ayudar con el movimiento de imágenes responsivas, únase al RICG a través del W3C. Si eso es demasiado, siempre estamos buscando personas que prueben la versión beta de Picturefill y envíen errores a través del rastreador de problemas en GitHub .

También puede hacer correr la voz sobre excelentes herramientas como Sizer Soze, que calcula el costo de rendimiento de no utilizar imágenes responsivas.

Otros recursos

• Grupo comunitario de imágenes receptivas
• “ El pictureElemento ” (especificación), RICG
• “El srcsetAtributo” (especificación), W3C
• @respimg , RICG en Twitter

Otras lecturas

• Una solución para las imágenes responsivas
• Imágenes responsivas simples con imágenes de fondo CSS
• Cómo resolver imágenes adaptables en diseño web responsivo
• Imágenes responsivas en WordPress con dirección de arte

(al, ml, mrn)Explora más en

• Codificación
• CSS
• javascript
• Diseño de respuesta