La siguiente es una publicación invitada de Mat Marqués. Mat tiene un anuncio de servicio público importante para nosotros con respecto a las imágenes receptivas.
No quiero ocultar el lede: si está utilizando una versión de Picturefill anterior a la 2.3.1, actualice de inmediato: actualice su /lib
archivos, presente un problema en su proyecto o ejecute una npm update picturefill
y tranquilízate. No ha habido cambios importantes en ninguna versión de Picturefill 2, por lo que no debería tener problemas para actualizar.
Nada está en llamas, aquí. Picturefill no puede tener problemas de seguridad críticos; nadie va a descifrar cibernéticamente su megahercio como resultado de un error de Picturefill, o sin embargo, está pirateando funciona en la televisión. Lo que este problema podría significar para su proyecto son imágenes rotas y lo que podría significar para los estándares web, bueno, eso tiene el potencial de ser un problema mayor.
La cuestión
Con versiones anteriores de Picturefill, es posible que obtenga imágenes rotas tanto en WebKit Nightly como en la vista previa de Microsoft Edge. Esto es lo que nosotros, en la industria de las imágenes receptivas, llamamos “tener un problema grave”.
Una parte pequeña pero importante de la especificación de imágenes receptivas es la adición de un currentSrc
propiedad en img
, lo que nos permite obtener la fuente que se muestra actualmente a través de JavaScript. Con el viejo llano img
de años pasados, siempre podríamos suponer que el valor de un src
el atributo era la fuente que se mostraba; después de todo, era la única opción para una fuente de imagen. Ahora que tenemos toneladas de nuevas opciones para mostrar imágenes de formas más responsables y adecuadas al contexto, eso src
El atributo puede no contener la fuente que se muestra actualmente al usuario, por lo tanto currentSrc
.
Picturefill rellena esto escribiendo la fuente actual en un currentSrc
propiedad, y a los navegadores sin soporte nativo de imágenes receptivas no les importará esto. Sin embargo, el nativo currentSrc
La implementación en los navegadores es de solo lectura. El meollo del problema es que Picturefill hace uso de JavaScript use strict
declaración, lo que significa que Picturefill es muy elocuente sobre posibles errores. Lo último que queremos cuando intentamos crear un polyfill 100% compatible con las especificaciones que funcione en todas partes son errores silenciosos. Cuando Picturefill intenta hacer algo que los navegadores no quieren, no queremos que el navegador haga una excepción. Queremos conocer el problema y solucionarlo de inmediato. En este caso, el navegador se opuso a que Picturefill intentara escribir en una propiedad de solo lectura.
Picturefill se basó en una prueba para picture
elemento de soporte para decidir si debe ejecutarse en absoluto, un vestigio de sus primeras versiones. Cuando las vistas previas de WebKit y Edge implementaron el soporte para srcset
y sizes
sin que picture
, Prueba de Picturefill para picture
elemento falló, por lo que intentó polyfill características compatibles de forma nativa. Esto incluyó intentar escribir a currentSrc
, lo que resultó en un strict mode
excepción. Las excepciones hacen que JavaScript deje de ejecutarse, por lo que Picturefill se detuvo; como resultado, no se usaron imágenes srcset
fueron mostrados.
Nuestro error, mi error, honestamente, fue estropearse al estar tan sintonizados con las implementaciones nativas. Durante mucho tiempo tuvimos el lujo de una clara división en términos de compatibilidad con imágenes receptivas: o bien un navegador solo admitía lo básico srcset
(Solo el 1x
, 2x
Sintaxis de “relación de píxeles del dispositivo”) o admitía picture
, completo srcset
, sizes
, todo funciona. Debido a que había una división tan predecible en la compatibilidad con los navegadores, esto siempre había funcionado bien, y cuando las cosas funcionan bien, no se piensa mucho en ellas. Nadie se da cuenta cuando las bisagras no chirrían.
El problema más grande
Eso es malo, pero lo suficientemente fácil de arreglar por código. Es software; estas cosas pasan. Eso no significa que este tipo de problemas se parezcan a “está bien”, pero los errores ocurren. El mayor problema es el alcance potencial del problema.
Picturefill llegó antes picture
, srcset
, o sizes
fueron un destello colectivo en los ojos de un desarrollador de navegadores, y lo usamos como un prototipo para informar la especificación de imágenes receptivas desde el primer borrador. Después de convertirse en uno de los primeros polyfills reales para todas estas sintaxis, Picturefill se popularizó enormemente: una gran cantidad de sitios web lo están utilizando. Eso hace que este sea un problema grave, y no solo en términos de imágenes faltantes: si este problema llegara a los navegadores estables en lugar de solo las versiones nocturnas y las versiones preliminares, afectaría a una gran cantidad de sitios web.
Por esa razón, Microsoft Edge ha eliminado temporalmente currentSrc
apoyo; se enviará la primera versión estable srcset
y sizes
sin que currentSrc
. WebKit bien puede hacer lo mismo. Sin embargo, si el problema persiste, no podemos saber cuándo se volverá a activar esa característica tan necesaria, si es que se volverá a activar. Los proveedores no pueden arriesgarse a que cientos, miles, de sitios web entren en sus navegadores. Hasta que actualicemos Picturefill, no podemos usar currentSrc
en WebKit o Edge, y si lo eliminan por completo, los otros navegadores pueden hacer lo mismo.
En serio, actualice Picturefill
Las imágenes receptivas surgieron gracias a todos nosotros. Ni el RICG, ni una sola persona, ni ningún grupo “central” de influyentes responsables de la toma de decisiones en materia de estándares web. Ésta es una característica por la que los diseñadores y desarrolladores luchamos, pagamos y convertimos en realidad.
Sin embargo, el final del juego para un nuevo estándar web es largo. Ahora que hemos comenzado a obtener las imágenes receptivas que hemos estado buscando durante tanto tiempo, depende de nosotros mantenerlo todo en la dirección correcta y, en este caso, eso significa que debemos hacer un poco de mantenimiento. Eso podría ser tan fácil como escribir npm update picturefill
o tan complejo como copiar y pegar el contenido de un archivo, pero en ambos casos son unos minutos de trabajo. All of Team Responsive Images está aquí para ayudar si surgiera algún problema, también; puede apostar que estamos muy atentos a los problemas relacionados con la actualización a 2.3.1, porque todo nuestro trabajo depende de que Picturefill permanezca fuera de las implementaciones nativas. Si tiene algún problema al actualizar, aunque no creo que lo haga, no dude en enviarme un correo electrónico directamente. El equipo de Picturefill, y todo el RICG, si eso es lo que hace falta, lo ayudarán a resolverlo.
Nota del autor: Gracias a Alex Jegtnes y Sarah Forst para editar.