soy Kseso y esto EsCSS

HiDPI Images for Variable Pixel Densities

HiDPI Images for Variable Pixel Densities

·Por Kseso ✎ 2

Imágenes de alta resolución para dispositivos de densidad de píxel diferentes

En cuanto a las imágenes, el objetivo de las aplicaciones web de los desarrolladores es servir las imágenes con la mejor calidad lo más eficientemente posible. Este artículo desarrolla algunas técnicas útiles para hacer esto hoy y en el futuro próximo.
"Responsive image" que le dicen otras veces.

Créditos y licencias de uso

Autoría del Original

Artículo original de Boris Smus (aka @borismus) publicado el 22 de Agosto en html5rocks: "High DPI Images for Variable Pixel Densities" sobre cómo servir imágenes de distinta calidad en función de las características del dispositivo que las va a mostrar.

Licencia Original

Except as otherwise noted, the content of this article is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.

Disclaimer

De entrada mis disculpas por los fallos o errores tanto en la traducción como interpretación de los conceptos expuestos. Si encuentras algún pasaje mejorable, déjame tu propuesta en los comentarios. Gracias.


High DPI Images for Variable Pixel Densities

INTRODUCCIÓN

Una de las características del panorama actual de los dispositivos web es que hay una amplia gama de densidades de píxeles en las pantallas disponibles. Algunos dispositivos tienen pantallas de muy alta resolución, mientras que otros se han quedado detrás. Los desarrolladores de aplicaciones deben dar soporte a una amplia gama de densidades de píxeles, cosa que puede ser bastante difícil. En la web móvil, los problemas se agravan por varios factores:

  • Gran variedad de dispositivos con formas muy diferentes.
  • Red de ancho de banda limitado y vida de la batería.

En cuanto a las imágenes, el objetivo de las aplicaciones web de los desarrolladores es servir las imágenes con la mejor calidad lo más eficientemente posible. Este artículo cubrirá algunas técnicas útiles para hacer esto hoy y en el futuro próximo.

EVITE LAS IMÁGENES SI ES POSIBLE

Antes de abrir esta caja de Pandora, recuerde que la web tiene muchas tecnologías poderosas que son, en buena medida, independientes de la resolución y el DIP. En concreto, el texto, SVG y gran parte de CSS, debido a la función del escalado automático del píxel en la web (a través del devicePixelRatio).

Dicho esto, no siempre se pueden evitar imágenes en mapa de bits. Por ejemplo, se puede gestionar los archivos que serían muy difíciles de replicar en puro SVG / CSS, o se trata de una fotografía. Si bien se puede convertir la imagen en formato SVG de forma automática, con las fotografías no tiene mucho sentido porque por lo general no se ven bien.

EL FONDO

UNA HISTORIA MUY BREVE DE LA DENSIDAD DE PANTALLA

En los primeros días, las pantallas de ordenador tenía una densidad de píxel de 72 o 96 ppp (puntos por pulgada).

Los dispositivos han mejorado gradualmente en densidad de píxeles, impulsado principalmente por el caso del uso de los móviles, en el que los usuarios tienen, en general, sus teléfonos más cerca de sus caras, haciendo más visibles los píxeles. Para el 2008, 150dpi en los teléfonos eran la novedad. La evolución de la densidad de visualización continuó aumentando y hoy en día los los hay con pantallas de 300dpi (de marca "Retina" de Apple).

El Santo Grial, por supuesto, es una pantalla en la que los píxeles son completamente invisibles. Para el factor de forma de teléfono, la actual generación de pantallas Retina/HiDPI puede estar cerca de ese ideal. Pero los nuevos tipos de dispositivos portátiles, como el proyecto Glass, probablemente seguirán impulsando el aumento de la densidad de píxeles.

En la práctica, las imágenes de baja densidad se ven igual en nuevas pantallas como lo hicieron en las anteriores, pero en comparación con las imágenes nítidas de alta densidad que los usuarios están acostumbrados a ver, las imágenes de baja densidad tienen un aspecto discordante y pixeladas. La siguiente es una simulación aproximada de cómo una imagen 1x se verá en una pantalla de 2x. En contraste, la imagen 2x ve bastante bien.

PÍXELES EN LA WEB

Cuando la web fue diseñada, el 99% de las pantallas lo fueron a 96 ppp (o pretendían ser), y pocas previsiones se hicieron para la variación en este frente. Debido a la gran variación en los tamaños de pantalla y densidades, necesitábamos una manera estándar de hacer que las imágenes se ven bien en una variedad de densidades de pantalla y dimensiones.

La especificación HTML recientemente ha abordado este problema mediante la definición de un píxel de referencia que los fabricantes utilizan para determinar el tamaño de un píxel CSS.

"Se recomienda que el pixel de referencia será el ángulo visual de un pixel en un dispositivo con una densidad de píxeles de 96 ppp y una distancia desde el lector de longitud de un brazo. Para la longitud de un brazo nominal de 28 pulgadas, el ángulo visual es por lo tanto unos 0,0213 grados."

Utilizando el píxel de referencia, un fabricante puede determinar el tamaño del píxel físico del dispositivo en relación con el píxel estándar o ideal. Esta relación se llama "relación de pixel del dispositivo" (device pixel ratio).

CÁLCULO DE LA RELACIÓN DEL PIXEL DEL DISPOSITIVO

Supongamos que un teléfono inteligente tiene una pantalla con un tamaño de píxel físico de 180 píxeles por pulgada (ppi). El cálculo de la relación de píxeles del dispositivo requiere tres pasos:

  1. Comparar la distancia real al que se sostiene el dispositivo con la distancia para el píxel de referencia.
    Por las especificaciones, sabemos que a las 28 pulgadas, lo ideal es 96 píxeles por pulgada. Sin embargo, puesto que es un teléfono inteligente, la gente sostendrá el dispositivo más cerca de sus caras que si fuese un ordenador portátil. Vamos a suponer que la distancia es de 18 pulgadas.
  2. Multiplicar la relación de distancia por la densidad estándar (96ppi) para obtener la densidad de píxeles ideal para la distancia dada:
    idealPixelDensity = (28/18) * 96 = 150 píxeles por pulgada (aproximadamente)
  3. Tomar la relación de la densidad de píxeles física a la densidad de píxeles ideal para obtener la relación de pixel del dispositivo.
    devicePixelRatio = 180/150 = 1,2
    N.T.: 1 pulgada (inch) = 2´54cm

Así, ahora cuando el navegador tiene que saber cómo cambiar el tamaño de una imagen para adaptarla a la pantalla de acuerdo con la resolución ideal o estándar, el navegador se refiere a la proporción de píxeles dispositivo de 1,2 - esto es, por cada píxel ideal, este dispositivo cuenta con 1,2 píxeles físicos-. La fórmula para ir entre el ideal (como se define por la especificación web) y los píxeles físicos (puntos en la pantalla del dispositivo) es la siguiente:

physicalPixels = window.devicePixelRatio * idealPixels

Históricamente, los fabricantes de dispositivos han tendido a redondear el devicePixelRatios (DPR). EL IPhone y el Ipad de Apple informan de un valor de DPR de 1, y sus equivalentes Retina de 2. La especificación CSS recomienda que:

"La unidad de píxeles se refiere al número total de píxeles del dispositivo que mejor se aproxima al píxel de referencia."

Una de las razones del porqué puede es mejor redondear se debe a que puede dar lugar a un menor número de dispositivos con valores de sub-píxeles de distintos.

Sin embargo, el la realidad del panorama de los dispositivo es mucho más variada, y los teléfonos Android tienen a menudo un valor para DPRs de 1,5. La tableta Nexus 7 tiene una DPR de ~1,33, al que se llegó por un cálculo similar al anterior. Se espera ver más dispositivos con DPRs distintos en el futuro. Debido a esto, usted nunca debe asumir que sus clientes van a tener valores de DPRs enteros.

APROXIMACIÓN A LAS TÉCNICAS DE IMAGEN HiDPI

Hay muchas técnicas para resolver el problema de mostrar las imágenes con la mejor calidad lo más rápido posible, en general se engloban en dos categorías:

  1. Optimizar las imágenes individualmente, y
  2. Optimizar la selección entre múltiples imágenes.

Opción una sola imagen: utilizar una imagen, pero hacer algo inteligente con ella. Estos métodos tienen el inconveniente de que, inevitablemente, tendrán que sacrificar el rendimiento, ya que va a descargar las imágenes HiDPI incluso en los dispositivos más antiguos con menor DPI. Éstos son algunos de los enfoques para el caso de una sola imagen:

  • Usar una imagen HiDPI muy comprimida
  • Usar un formato de imagen asombroso
  • Usar un formato progresivo de imagen

Opción de múltiples imágenes: utilice imágenes múltiples, pero hacerlo inteligentemente para elegir la que se carga. Estos enfoques conllevan trabajo extra para el desarrollador que tiene que crear varias versiones del mismo archivo, y luego encontrar una forma de selección. Estas son las opciones:

  • JavaScript
  • Del lado del servidor
  • CSS: @Media Queries
  • Basado en funciones del navegador ( imagen-set () , <img srcset> )

IMAGEN HiDPI MUY COMPRIMIDA

Las imágenes ya suponen la friolera del 60% ​​del ancho de banda de descarga de un sitio web típico. Al servir imágenes HiDPI a todos los clientes, vamos a aumentar este número. ¿Cuánto más va a crecer?

Hice algunas pruebas que generaron fragmentos de imágenes 1x y 2x con calidad JPEG a 90, 50 y 20. Aquí está el script que usé (utiliza ImageMagick) para generarlas:

A partir de esta pequeña muestra, no científica, parece que comprimir imágenes de gran tamaño compensa equilibrar la relación relación calidad-tamaño. Para mi ojo, las imágenes 2x muy comprimidas en realidad se ve mejor que las imágenes no comprimidas 1x.

Por supuesto, servir en baja calidad imágenes 2x muy comprimidas dispositivos 2x es peor servirla con calidad alta, esto va contra la premisa de servir las imágenes con la mejor calidad lo más eficientemente posible. Si compara las imágenes de "calidad: 90" con las de "calidad: 20", notará una pérdida de nitidez y un granulado creciente. Estas artimañas no son aceptables en los casos en que las imágenes de alta calidad son claves (por ejemplo, una aplicación para visualizar fotos), o para los desarrolladores de aplicaciones que no están dispuestos sacrificar tanta calidad por la eficiencia.

La comparación fue hecha en su totalidad con imágenes JPEG comprimidas. Vale la pena señalar que existen muchas opciones con sus pros y contras entre los formatos de imagen que podemos elegir (JPEG, PNG, GIF), lo que nos lleva a ...

UN FORMATO DE IMAGEN ASOMBROSO

WebP es un bonito y atractivo formato de imagen que comprime muy bien, conservando una alta calidad en la imagen. Por supuesto, aún no está totalmente implementado.

Una forma de testar el soporte WebP es a través de JavaScript. Se carga una imagen de 1px a través de data-uri, se espera, ya sea a su carga o alaviso de error, a continuación, se comprueba que el tamaño es correcto. Modernizr tiene entre sus características esta detección , que está disponible a través de Modernizr.webp

Una manera mejor de hacer esto, sin embargo, es usar directamente el valor de CSS image() . Así que si usted tiene una imagen WebP y otra de reserva JPEG, puede escribir lo siguiente:

#pic { background: image("foo.webp", "foo.jpg"); }

Hay algunos problemas con esta vía. En primer lugar, image() no está completamente desarrollado y soportado. En segundo lugar, cuando WebP va, JPEG está de vuelta. Sigue existiendo una mejora relativamente importante: un 30% más pequeño según esta galería WebP. Por lo tanto, WebP por sí solo no es suficiente para resolver el problema de un alto DPI.

FORMATOS PROGRESIVOS DE IMAGEN

Formatos progresivos de imagen como JPEG2000, Progressive JPEG, Progressive PNG y GIF tienen la ventaja (un tanto discutible) de ir mostrando la imagen en su lugar antes de estar completamente cargada. Esto puede suponer aumentar el peso del archivo, aunque hay pruebas contradictorias sobre ello. Jeff Atwood afirma que el modo progresivo ", añade el 20% al tamaño de las imágenes PNG, y un 10% el tamaño de las imágenes JPEG y GIF". Sin embargo, Stoyan Stefanov sostiene que, para archivos de gran tamaño, el modo progresivo es más eficiente (en la mayoría de los casos).

A primera vista, las imágenes progresistas parecen muy prometedores en el contexto de servir las imágenes de mejor calidad lo más rápido posible. La idea es que el navegador puede dejar de descargar y descodificar una imagen una vez que se sabe que los datos adicionales no se aumentarán la calidad de la imagen (es decir, todas las mejoras fidelidad son sub-pixel).

Mientras que las conexiones son fáciles de cortar, a menudo son caras de restablecer. Para un sitio con muchas imágenes, el enfoque más eficaz es mantener una única conexión HTTP activa, utilizándola el mayor tiempo posible. Si la conexión se interrumpió prematuramente debido a que una imagen no se descargó completamente, entonces el navegador tiene que crear una nueva conexión, y puede ser un proceso más lento en entornos de baja latencia.

Una solución a esto es usar el HTTP Range request, que permite a los navegadores especificar en la petición un rango de bytes. Un navegador inteligente podría hacer una solicitud HEAD para obtener la cabecera, procesarla, decidir qué parte de la imagen realmente se necesita, y luego pedirla. Desafortunadamente el HTTP Range recibe escaso apoyo en los servidores web, por lo que este enfoque no es práctico.

Por último, una limitación obvia de este enfoque es que no tienes que elegir la imagen que desea cargar, sólo varía la calidad de la misma imagen. Como resultado, esto no aborda la "cuestión planteada" en este caso.

USO DE JAVASCRIPT PARA DECIDIR QUÉ IMAGEN CARGAR

La primera, y más obvia aproximación para decidir qué imagen cargar es el uso de JavaScript en el lado del cliente. Este enfoque le permite saber todo acerca de su agente de usuario y hacer lo correcto. Puede determinar el "device pixel ratio" via window.devicePixelRatio , obtener el ancho de la pantalla y la altura, e incluso potencialmente hacer algún tipo de rastreo de la conexión de red mediante navigator.connection o hacer una solicitud falsa, como hace la librería foresight.js. Una vez que haya recogido toda esta información, usted puede decidir qué imagen va a cargar.

Hay aproximadamente un millón de bibliotecas JavaScript que hacen algo como lo anterior, pero por desgracia, ninguna de ellos de forma sobresaliente.

Una gran desventaja de este enfoque del uso de JavaScript significa que se demora la carga de imágenes hasta que el analizador "adivino" haya terminado. En esencia, esto significa que las imágenes ni siquiera se empiezan a descargar hasta después de los eventos pageLoad. Más sobre ésto en el artículo Jason Grigsby.

DECIDA QUÉ IMAGEN CARGAR EN EL LADO DEL SERVIDOR

Puede dejar la decisión del lado del servidor escribiendo controladores de peticiones () para cada imagen que va a servir. Este controlador se basa en verificar soporte a Retina basado en el User-Agent (la única cadena de información que se transmite al servidor). Luego, en función de si la lógica del lado del servidor quiere servir HiDPI activos, se cargan al activo correspondiente (nombre de acuerdo a alguna convención se conoce). Entonces, basado en lo anterior, servir los archivos HiDPI o los que corresponda (nombrados de acuerdo a alguna regla conocida).

Por desgracia, el User-Agent no necesariamente proporciona información suficiente para decidir si un dispositivo debe recibir imágenes de calidad alta o baja. Además, no hace falta decir que todo lo relacionado con User-Agent es un hack y debe evitarse si es posible.

(N.T.: amplía este apartado: Adaptive Images con PHP ⇩)

USO DE MEDIA QUERIES DE CSS

Siendo conciso, las media queries de CSS te permiten indicar tus intenciones y dejar que el navegador haga lo correcto en su nombre. Además del uso más común de media queries (hallar el tamaño del dispositivo) también puede aplicar devicePixelRatio. El valor asociado en las @media queries es device-pixel-ratio y sus variantes max- y min-, como se podría esperar. Si desea cargar imágenes de HiDPI y la proporción de píxeles del dispositivo supera un umbral, esto es lo que puede hacer:

#my-image { background: (low.png); } @media only screen and (min-device-pixel-ratio: 1.5) { #my-image { background: (high.png); } }

Esto se vuelve un poco más complicado al tener que usar los prefijos privativos y el orden en que se han de declarar los max- | min- :

@media only screen and (min--moz-device-pixel-ratio: 1.5), (-o-min-device-pixel-ratio: 3/2), (-webkit-min-device-pixel-ratio: 1.5), (min-device-pixel-ratio: 1.5) { #my-image { background:url(high.png); } }

Con este enfoque, se recuperan los beneficios del análisis de la cabecera (look-ahead parsing), que se había perdido con la solución de JS. También tendrás la flexibilidad de elegir de forma "responsive" (por ejemplo, puede hacer las imágenes de baja, media y alta DPI), que se perdió con el enfoque del lado del servidor.

Por desgracia, todavía es un poco difícil de manejar, y da una extraña apariencia al CSS (o requiere preprocesamiento). Además, este enfoque se limita a las propiedades CSS, así que no hay manera de establecer una <img src=""> y las imágenes deben estar en todos los elementos como un fondo. Por último, al basarse estrictamente en proporción del pixel del dispositivo, puede terminar en situaciones donde su teléfono de alta DPI termina descargando un archivo enorme de imagen 2x, usando una conexión EDGE. Esto no es la mejor experiencia de usuario.

(N.T.: Más sobre las @media queries: ⇩)

UTILICE LAS NUEVAS FUNCIONES DEL NAVEGADOR

Últimamente ha habido mucha discusión en torno al apoyo de la plataforma web para el problema de la imagen de alta DPI. Apple recientemente irrumpió en el ruedo con la propuesta webkit image-set (). Como resultado, tanto Safari como Chrome lo soportan. Puesto que es una valor de CSS, image-set () no aborda el problema de las etiquetas <img>. Se ha presentado @srcset, que aborda este tema, pero (en el momento de escribir estas líneas) no tiene implementaciones de referencia (por ahora). La siguiente sección profundiza en la image-set y srcset

LAS FUNCIONES DEL NAVEGADOR EN APOYO DEL HiDPI

En última instancia, la decisión sobre qué método se utiliza depende de sus necesidades particulares. Una vez dicho esto, tenga en cuenta que todos los enfoques mencionados anteriormente tienen inconvenientes. De cara al futuro, sin embargo, una vez que image-set y srcset tengan un amplio apoyo, van a ser las soluciones adecuadas a este problema. Por el momento, vamos a hablar de algunas de las mejores prácticas que nos pueden llevar tan cerca de ese futuro ideal como sea posible.

En primer lugar, ¿en qué se diferencian? Bueno, image-set () es una propuesta de CSS, adecuado para su uso como un valor de la propiedad background de CSS. srcset es un atributo específico de los elementos <img>, con una sintaxis similar. Ambas le permiten especificar los valores de la imagen, pero el atributo srcset permite también configurar la imagen que desea cargar en función del tamaño de la vista.

MEJORES PRÁCTICAS PARA IMAGE-SET

El valor image-set () de CSS está disponible con el prefijo -webkit-image-set () . La sintaxis es bastante simple, tomando una o más declaraciones de imagen separados por comas, que consisten en una cadena de dirección URL o valor url () seguido de la resolución correspondiente. Por ejemplo:

background-image: -webkit-image-set( url(icon1x.jpg) 1x, url(icon2x.jpg) 2x );

Lo que esto indica al navegador es que hay dos imágenes para elegir. Una de ellas está optimizada para pantallas de 1x, y el otro para las pantallas de 2x. El navegador tiene que elegir cuál cargar, sobre la base de una variedad de factores, que incluso pueden incluir la velocidad de la red, si el navegador es lo suficientemente inteligente (no implementado actualmente hasta donde yo sé).

Además de cargar la imagen correcta, el navegador también la escala en consecuencia. En otras palabras, el navegador asume que la 2ª imagen es dos veces más grande que la imagen 1x, y así escala la imagen 2x hacia abajo por un factor de 2, de modo que la imagen parece tener el mismo tamaño en la página.

En lugar de especificar 1x, 1.5x o Nx, también puede especificar una densidad de píxeles del dispositivo determinado en dpi.

Esto funciona bien, excepto en los navegadores que no admitan image-set, que no mostrará ninguna imagen en absoluto. Esto es claramente malo, por lo que debe utilizar una alternativa (o una serie de ellas) para abordar esta cuestión:

background-image: url(icon1x.jpg); background-image: -webkit-image-set( url(icon1x.jpg) 1x, url(icon2x.jpg) 2x ); /* Esto será útil si la image-set se admite y soporta sin prefijo. También si se incluyen otras versiones del prefijo * / background-image: image-set( url(icon1x.jpg) 1x, url(icon2x.jpg) 2x );

Con el código anterior, los navegadores que soporten image-set mostrarán el archivo de imagen que le corresponda, y si falla, la imagen 1x. La advertencia obvia es que mientras el soporte de los navegadores a image-set sea escaso la mayoría de las aplicaciones de usuario obtendrán el archivo 1x.

En esta demos se utiliza image-set () para cargar la imagen correcta, descargando de nuevo al activo 1x si esta declaración CSS no es compatible.

Llegados a este punto, se estará preguntando por qué no hay ya un polyfill (es decir, una chuleta en JavaScript) para image-set () y acabamos antes. Pues resulta que es muy difícil implementar polyfills eficientes para las funciones de CSS. (Para una explicación más detallada del porqué, vea este debate www-style).

IMAGE SRCSET

He aquí un ejemplo de srcset:

<img alt="my awesome image" src="banner.jpeg" srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

Como se puede ver, además de las declaraciones de x que image-set proporciona, el elemento srcset también indica valores w y h (ancho y alto) que corresponden al tamaño de la ventana, tratando de servir a el archivo más apropiado. Lo anterior serviría banner-phone.jpeg a dispositivos con un ancho inferior a 640px, banner-phone-HD.jpeg a los dispositivos de pequeñas pantallas y de alta DPI (2x), banner-HD.jpeg a dispositivos de alta DPI con pantallas de más de 640px y banner.jpeg para todo lo demás.

(N.T.: amplía este apartado: Picture element ⇩)

USO DE IMAGE-SET EN ELEMENTOS DE IMAGEN

Debido a que el atributo srcset en los elementos img no se ha implementado en la mayoría de los navegadores, puede ser tentador reemplazar sus elementos img por <div>s y utilizar el enfoque del image-set. Esto funcionaría, pero con con advertencias. El inconveniente es que la etiqueta <img> tiene desde hace mucho tiempo un valor semántico. En la práctica, esto es importante sobre todo para los rastreadores web y por las razones de accesibilidad.

Si se decide por usar -webkit-image-set, puede tener la tentación de utilizar la propiedad background de CSS. El inconveniente de este enfoque es que es necesario especificar el tamaño de la imagen, que se desconoce si está utilizando una imagen no 1x. En lugar de hacer esto, puede utilizar la propiedad content de CSS de la siguiente manera:

<div id="my-content-image" style="content: -webkit-image-set( url(icon1x.jpg) 1x, url(icon2x.jpg) 2x);"> </div>

Esto automáticamente escala la imagen en función de devicePixelRatio. Vea este ejemplo de la técnica anterior en la acción, con una lammada adicional a url () para los navegadores que no admitan image-set.

POLYFILL SRCSET

Una característica útil de srcset es que viene con un seguro de serie. En el caso en que el atributo srcset no está implementado, todos los navegadores saber procesar el atributo src. También, ya que es sólo un atributo HTML, es posible crear polyfills con JavaScript.

Esta polyfill viene con tests para garantizar que es lo más fiel a la especificación como sea posible. Además, hay controles para evitar que el polyfill ejecute cualquier código si srcset está implementado de forma nativa.

Aquí una demo del polyfill en acción.

CONCLUSIÓN

No hay una varita mágica para resolver el problema de las imágenes de alta DPI.

La solución más fácil es evitar por completo las imágenes, optando por SVG y CSS en su lugar. Sin embargo, esto no siempre es realista, sobre todo si disponemos de imágenes de alta calidad en el sitio.

Enfoques en JS, CSS y el uso del lado del servidor, todos tienen sus fortalezas y debilidades. El enfoque más prometedor, sin embargo, es mejorar las funcionalidades del navegador. A pesar de que la compatibilidad de los navegadores con image-set y srcset es aún incompleta, hay bases razonables para utilizarlos hoy.

En resumen, mis recomendaciones son las siguientes:

  • Para las imágenes de fondo, utilice image-set con código alternativo para los navegadores que no lo soportan.
  • Para las imágenes de contenido, usar un polyfill srcset, como respaldo en el uso de image-set (ver más arriba).
  • Para situaciones en las que está dispuesto a sacrificar la calidad de imagen, considere el uso imágenes 2x fuertemente comprimidas.

Complementos al artículo original

Artículos y páginas como complemento al artículo original y ajenos a él

  1. @media Queries Un adivino de variables y hacedor de imposibles
  2. Colección de @media Queries para smartphones
  3. Picture Element: vía libre al responsive imag
  4. Adaptive Images usando PHP

Autoría del Artículo Original, Créditos obligados y licencias

Artículo original de Boris Smus (aka @borismus) publicado el 22 de Agosto en html5rocks: "High DPI Images for Variable Pixel Densities"
Artículo original publicado bajo una licencia Creative Commons Attribution 3.0 License, y los códigos y ejemplos con Apache 2.0 License.
La traducción al español realizada aquí se licencia en los mismos términos y condiciones que la original.

avatar del Editor del blog

the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.
#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso