Il y a eu des centaines d’articles techniques détaillés et plus ou moins smart sur la possibilité de télécharger une image plus ou moins grosse suivant la taille d’affichage, afin de ne pas utiliser une énorme image sur mobile ou une ridiculement petite sur un écran 24″.
Si vous ne devez en lire qu’un
Le dernier pour comprendre où en sont les réflexions, c’est probablement l’article de Bruce Lawson. Il faut aussi lire les commentaires.
Tout d’abord oubliez les astuces à base de javascript et de noscript. Il existe des machins horribles qui résistent à peu près à tout, mais ça reste franchement bancal. Oubliez encore plus les scripts à base de cookie, qui de toutes façons ne pourront jamais répondre à plus du tiers de la problématique, et encore, avec des effets de bords.
Bruce part d’une solution uniquement basée sur des CSS, qui de plus à la bonne idée d’être théoriquement déjà fonctionnelle. Il suffirait d’améliorer le support CSS 3 des navigateurs pour que cela ne se pose plus. Pour l’instant cela n’est possible qu’avec Opera et Chrome, et les optimisations de performance de ces navigateurs risquent de faire télécharger deux images au lieu d’une seule (ce qui est un peu l’opposé du but recherché).
Il propose ensuite un marquage HTML pour arriver au même résultat. C’est rétro-compatible avec les navigateurs actuels, et ne devrait pas être impossible à implémenter.
Maintenant ça ne me plait pas
Tout d’abord le marquage HTML me semble le mauvais endroit pour résoudre la problématique. On parle de répondre à des tailles d’affichage, et ça c’est typiquement une question de présentation, donc de CSS. Certainement il y a des fois où un marquage HTML aura du sens, mais selon moi ce sera un cas particulier du cas général, et utiliser HTML est prendre le problème par le mauvais sens.
Ensuite il y a des problématiques qui marquent un manque de recul (pas de la personne, mais bien en rapport avec les besoins réels et les capacités des navigateurs). Filtrer sur le fait que l’utilisateur est en 3G est seulement impossible pour beaucoup de situations (le navigateur n’a pas l’information), mais aussi n’a aucun sens. Pour une même connexion 3G je peux être à des vitesses réelles qui font presque passer mon ancien 56K pour une alternative acceptable (par exemple à cause des pertes de paquets à gogo), soit être à 7Mb/s et crâner devant la majorité des liaisons ADSL de mon pays (qui est pourtant très bien connecté). De toutes façons la vitesse de connexion sur mon propre accès est un très mauvais révélateur de la vitesse réellement disponible pour joindre le serveur d’en face. Le réseau peut être encombré chez moi, chez mon FAI, sur le serveur d’en face, ou n’importe où au milieu.
Je seconde le commentaire numéro 8 : s’il fallait vraiment tailler le contenu de manière fixe en fonction uniquement de taille d’écran et de vitesse de connexion, une déclaration dans les entêtes de la requête et une négociation HTTP seraient bien plus efficaces. L’option a de plus l’avantage de ne poser aucun problème de compatibilité arrière.
La problématique de base
Toutefois, on revient au problème initial. À force de discuter certains ont oublié la problématique de base : choisir une image en fonction de la taille à afficher. Le mécanisme éventuel ne doit prévoir que ça : permettre de spécifier différentes adresses (ou différents suffixes) en fonction de différentes hauteurs ou largeurs.
Charge à vous d’utiliser une entête ou l’adresse IP côté serveur pour vérifier si c’est de l’ADSL ou de la 3G (ça me semble une mauvaise idée mais vous pouvez déjà le faire). Charge à vous d’utiliser des @media pour proposer plusieurs versions en fonction de la taille de l’écran ou de son orientation, ou de contraindre cette taille en fonction. En combinant tout cela vous devriez pouvoir faire tout ce qui vous amuse, mais la problématique qui nous manque c’est uniquement celle de fournir plusieurs URLs en fonction de la taille prévue pour l’affichage. De toutes façons on ne trouvera jamais de solution qui fait le café.
Je n’ai pas « la » solution, mais selon moi (et je rejoins beaucoup le commentaire 15) :
- La réponse principale doit être côté CSS (quitte à avoir d’autres types de réponses ailleurs pour des cas niches)
- Elle ne doit s’occuper que de proposer des images alternatives en fonction de la largeur ou hauteur prévue pour afficher l’image (et non de la taille du viewport ou d’autres paramètres tiers)
- Elle ne doit pas provoquer de double téléchargement sur les navigateurs non compatibles
- Elle doit avoir un fallback acceptable sur les navigateurs non compatibles
Le reste se fait avec les outils existants, pas en les remplaçant.
Le jeu de « ma solution à moi »
Si vraiment je devais créer quelque chose à chaud (ce qui se révèlera forcément une erreur), j’aurai quelque chose comme ça :
img.intro {
content: content-if(attr(data-big), width > 300px),
content-if(attr(data-small), height < 50),
attr(src) ;
}
@media all and (max-width:600px) {
img.intro {
width: 300px ;
height: 200px ;
}
}
@media all and (max-width:320px) {
img#thingy {
width: 50px ;
height : 30px ;
}
}
Bon, le pseudo langage sur la condition n’est probablement pas celui qu’il faut retenir mais il est volontairement basé sur un jeu de mot clefs limité et des contraintes qui le sont tout autant (hauteur et largeur disponibles, c’est tout). On peut tout à fait envisager que cela ne fonctionne que si les tailles width ou height sont déterminées explicitement dans la CSS, histoire de ne pas rendre l’implémentation irréalisable. Autre avantage : c’est à priori compatible avec l’existant puisqu’au pire si content-if n’est pas supporté, c’est toute la règle qui est ignorée. Reste au navigateur qui supporte ça de prendre la première version qui correspond.
Laisser un commentaire