Apple réfléchit à comment adapter le web aux écrans haute-résolution [via] : en gros, zoomer les pages comme Opera le fait depuis des années (ce qui revient à changer la taille effective d’un pixel), tout en permettant aux créateurs de pages web de spécifier des versions alternatives haute-résolution de leurs images, pour que les pages zoomées ne soient pas pixellisées.
Ca serait très bien s’ils ne confondaient pas (sans surprise) compatibilité ascendante et immobilisme : alors que c’est un changement assez majeur à la conception des pages web, ils font tout ce qu’ils peuvent pour le faire rentrer dans les tags et attributs HTML / CSS existants, et la seule modification au standard HTML qu’ils proposent est l’ajout d’un “media” CSS dépendant de la résolution.
Leur idée de base : pour afficher une image de 100 par 100 pixels, réalisez-la en quatre ou seize fois plus grand, et utilisez les attributs HTML et CSS pour spécifier sa taille effective. Vous pouvez utiliser les CSS conditionnels pour cacher les images haute-résolution aux browsers travaillant en résolution normale (même si ça va rendre vos CSS imbitables), mais pour les <img> (et on en a toujours besoin pour les contenus, on ne va pas se mettre à faire du remplacement d’images en CSS pour un photolog), Apple propose simplement de faire charger et redimensionner l’image haute-résolution par tout le monde, juste au cas où un visiteur voudrait un jour la regarder sur un écran 30 pouces.
Voilà le commentaire que j’ai posté :
Puisqu’il s’agit uniquement des images, est-ce que ça ne serait pas infiniment plus simple, et plus logique, de modifier simplement les formats de fichiers, plutôt ? Est-ce que les fichiers SVG et PNG (on peut oublier les GIF et JPEG puisqu’il s’agit du développement de nouveaux contenus, donc les formats obsolètes n’ont pas forcément besoin d’être gérés) ne pourraient pas conserver une compatibilité ascendante tout en contenant, sous forme de métadonnées, soit les pixels supplémentaires, soit un pointeur vers les versions haute-définition ?
Imaginez : vous concevez vos boutons de navigation en 300 dpi sous Photoshop, cochez une case pour spécifier l’exportation en 72 dpi, et le PNG contient les deux versions, les pixels complémentaires étant cachés à la vue des anciens browsers.
Ou bien : vous retouchez votre photo en 300 dpi sous Photoshop, cochez une case à l’exportation pour demander la création de maphoto-72dpi.png, myphoto-150dpi.png et myphoto-300dpi.png (voire plus), chaque fichier contenant une référence aux deux autres. Un browser qui charge la version 72 dpi dans un tag img saura où trouver le 300 dpi s’il en a besoin, et un logiciel graphique saura modifier les versions inférieures quand l’utilisateur édite la version haute-résolution.
D’accord, dans les deux cas il y a un peu de bande passante gaspillée, mais si au final le visiteur doit charger la version 300 dpi d’une photo, le fait d’avoir d’abord chargé la version 72 dpi sera pratiquement négligeable.
En outre, votre proposition économise la bande passante pour les images décoratives, mais pas pour le contenu (par exemple, des photos publiées dans un blog ou une galerie, pour lesquelles on ne peut en pratique pas utiliser les feuilles de styles pour spécifier quelle image charger) : le navigateur chargera la version haute-résolution à chaque fois, pour la redimensionner ensuite. C’est un gaspillage de bande passante, de temps processeur et de RAM, et pour l’instant ça donne un résultat moche sous Windows (qui ne redimensionne pas proprement comme OS X).
A vrai dire, le plus simple serait que ce soit géré par le serveur web — le browser envoie un header http précisant la résolution virtuelle d’affichage, et reçoit le bon fichier image en retour — mais ça serait alors à chaque hébergeur de décider s’il veut upgrader son serveur web, alors qu’en passant par l’évolution des formats graphiques c’est chaque éditeur de contenu qui peut décider d’utiliser un logiciel capable de gérer la résolution variable.
Vous voulez savoir quand je poste du contenu sur mon blog ? Il suffit de vous inscrire gratuitement à un agrégateur RSS (Feedly, NewsBlur, Inoreader, …) et d'ajouter www.ff00aa.com à vos flux (ou www.garoo.net pour vous abonner à tous les sujets). On n'a pas besoin de newsletters, pas besoin de Twitter, le RSS existe toujours.
Mentions légales : ce blog est hébergé par OVH, 2 rue Kellermann, 59100 Roubaix, France, www.ovhcloud.com.
Les données des visiteurs de ce blog ne sont pas utilisées ni transmises à des tiers. Les posteurs de commentaires peuvent demander leur suppression par e-mail.
Tous contenus © de l'auteur ou couverts par le droit de citation.
