Catégorie : Technique

Il y a eu des centaines d’ar­ticles tech­niques détaillés et plus ou moins smart sur la possi­bi­lité de télé­char­ger une image plus ou moins grosse suivant la taille d’af­fi­chage, afin de ne pas utili­ser une énorme image sur mobile ou une ridi­cu­le­ment 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 proba­ble­ment l’ar­ticle de Bruce Lawson. Il faut aussi lire les commen­taires.

Tout d’abord oubliez les astuces à base de javas­cript et de noscript. Il existe des machins horribles qui résistent à peu près à tout, mais ça reste fran­che­ment bancal. Oubliez encore plus les scripts à base de cookie, qui de toutes façons ne pour­ront jamais répondre à plus du tiers de la problé­ma­tique, et encore, avec des effets de bords.

Bruce part d’une solu­tion unique­ment basée sur des CSS, qui de plus à la bonne idée d’être théo­rique­ment déjà fonc­tion­nelle. Il suffi­rait d’amé­lio­rer le support CSS 3 des navi­ga­teurs pour que cela ne se pose plus. Pour l’ins­tant cela n’est possible qu’a­vec Opera et Chrome, et les opti­mi­sa­tions de perfor­mance de ces navi­ga­teurs risquent de faire télé­char­ger deux images au lieu d’une seule (ce qui est un peu l’op­posé du but recher­ché).

Il propose ensuite un marquage HTML pour arri­ver au même résul­tat. C’est rétro-compa­tible avec les navi­ga­teurs actuels, et ne devrait pas être impos­sible à implé­men­ter.

Main­te­nant ça ne me plait pas

Tout d’abord le marquage HTML me semble le mauvais endroit pour résoudre la problé­ma­tique. On parle de répondre à des tailles d’af­fi­chage, et ça c’est typique­ment une ques­tion de présen­ta­tion, donc de CSS. Certai­ne­ment il y a des fois où un marquage HTML aura du sens, mais selon moi ce sera un cas parti­cu­lier du cas géné­ral, et utili­ser HTML est prendre le problème par le mauvais sens.

Ensuite il y a des problé­ma­tiques qui marquent un manque de recul (pas de la personne, mais bien en rapport avec les besoins réels et les capa­ci­tés des navi­ga­teurs). Filtrer sur le fait que l’uti­li­sa­teur est en 3G est seule­ment impos­sible pour beau­coup de situa­tions (le navi­ga­teur n’a pas l’in­for­ma­tion), 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 alter­na­tive accep­table (par exemple à cause des pertes de paquets à gogo), soit être à 7Mb/s et crâner devant la majo­rité des liai­sons ADSL de mon pays (qui est pour­tant très bien connecté). De toutes façons la vitesse de connexion sur mon propre accès est un très mauvais révé­la­teur de la vitesse réel­le­ment dispo­nible pour joindre le serveur d’en face. Le réseau peut être encom­bré chez moi, chez mon FAI, sur le serveur d’en face, ou n’im­porte où au milieu.

Je seconde le commen­taire numéro 8 : s’il fallait vrai­ment tailler le contenu de manière fixe en fonc­tion unique­ment de taille d’écran et de vitesse de connexion, une décla­ra­tion dans les entêtes de la requête et une négo­cia­tion HTTP seraient bien plus effi­caces. L’op­tion a de plus l’avan­tage de ne poser aucun problème de compa­ti­bi­lité arrière.

La problé­ma­tique de base

Toute­fois, on revient au problème initial. À force de discu­ter certains ont oublié la problé­ma­tique de base : choi­sir une image en fonc­tion de la taille à affi­cher. Le méca­nisme éven­tuel ne doit prévoir que ça : permettre de spéci­fier diffé­rentes adresses (ou diffé­rents suffixes) en fonc­tion de diffé­rentes hauteurs ou largeurs.

Charge à vous d’uti­li­ser une entête ou l’adresse IP côté serveur pour véri­fier 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’uti­li­ser des @media pour propo­ser plusieurs versions en fonc­tion de la taille de l’écran ou de son orien­ta­tion, ou de contraindre cette taille en fonc­tion. En combi­nant tout cela vous devriez pouvoir faire tout ce qui vous amuse, mais la problé­ma­tique qui nous manque c’est unique­ment celle de four­nir plusieurs URLs en fonc­tion de la taille prévue pour l’af­fi­chage. De toutes façons on ne trou­vera jamais de solu­tion qui fait le café.

Je n’ai pas « la » solu­tion, mais selon moi (et je rejoins beau­coup le commen­taire 15) :

• La réponse prin­ci­pale doit être côté CSS (quitte à avoir d’autres types de réponses ailleurs pour des cas niches)
• Elle ne doit s’oc­cu­per que de propo­ser des images alter­na­tives en fonc­tion de la largeur ou hauteur prévue pour affi­cher l’image (et non de la taille du view­port ou d’autres para­mètres tiers)
• Elle ne doit pas provoquer de double télé­char­ge­ment sur les navi­ga­teurs non compa­tibles
• Elle doit avoir un fall­back accep­table sur les navi­ga­teurs non compa­tibles

Le reste se fait avec les outils exis­tants, pas en les remplaçant.

Le jeu de « ma solu­tion à moi »

Si vrai­ment je devais créer quelque chose à chaud (ce qui se révè­lera forcé­ment une erreur), j’au­rai 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 condi­tion n’est proba­ble­ment pas celui qu’il faut rete­nir mais il est volon­tai­re­ment basé sur un jeu de mot clefs limité et des contraintes qui le sont tout autant (hauteur et largeur dispo­nibles, c’est tout). On peut tout à fait envi­sa­ger que cela ne fonc­tionne que si les tailles width ou height sont déter­mi­nées expli­ci­te­ment dans la CSS, histoire de ne pas rendre l’im­plé­men­ta­tion irréa­li­sable. Autre avan­tage : c’est à priori compa­tible avec l’exis­tant puisqu’au pire si content-if n’est pas supporté, c’est toute la règle qui est igno­rée. Reste au navi­ga­teur qui supporte ça de prendre la première version qui corres­pond.