• J’ai ajouté un gros paragraphe consacré à « Image adaptative, recadrage et direction artistique » dans ma documentation du #plugin #SPIP image_responsive :
    http://www.paris-beyrouth.org/Plugin-SPIP-Image-responsive

    Ça explique les critères de recadrage que l’on peut utiliser directement dans le filtre image_responsive, comme ceci :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{
            0/480/800/1280/1920/480/800/1280/1920,
            0, 0,
            (max-width: 480px) and (orientation:portrait)/(min-width:481px) and (max-width: 800px) and (orientation:portrait)/(min-width:801px) and (max-width:1280px) and (orientation:portrait)/(min-width:1281px) and (orientation:portrait)/
            (max-width: 480px)/(min-width:481px) and (max-width: 800px)/(min-width:801px) and (max-width:1280px)/,
            4x5/4x5/4x5/4x5/3x2/3x2/3x2/3x2
            })]

    (lequel code fabrique une bonne grosse balise picture en HTML5, extrêmement efficace au niveau de l’affichage, puisque l’image est préchargée, et l’affichage est instantané quand on revient sur une page déjà affichée).

    Pour le plugin lui-même :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

  • Nouveauté dans mon #plugin #SPIP image_responsive (version 6.6.0) :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Le filtre background_responsive accepte une troisième variable, $align (top, bottom, left, right) pour forcer le centrage de l’image ; avec la valeur focus, le plugin effectue le recadrage et le positionnement en fonction du « centre d’intérêt de l’image » déterminé par le plugin « centre_image ».

    Exemple d’utilisation :

    [(#LOGO_ARTICLE_NORMAL|background_responsive{480/800/1280/1920, 0, focus})]
  • Super amélioration de mon #plugin pour #SPIP, image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, j’introduis la possibilité de fabriquer le code <picture><source> complet pour complètement gérer les images responsive nativement (pour l’instant, dans Chrome).

    L’idée, c’est l’introduction d’un quatrième paramètre dans ma fonction, ce qui permet de définir les media queries correspondant à chaque taille d’image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_responsive{
                    0/50/100/200,
                    0,
                    0,
                    (max-width:470px)/(max-width:1009px)/
            }
    )]

    La première variable (0/50/100/200) est la liste des tailles d’images autorisées :
    – 0 n’est pas une taille d’image, ça signifie simplement qu’au chargement de la page, le <img> se fera sur rien.gif
    – ensuite on autorise des images de 50 pixels, 100 pixels, 200 pixels (donc trois tailles).

    Si on n’indique rien d’autre, on a le fonctionnement habituel du plugin : une fois la page chargée, un javascript calcule la taille de l’endroit qui contient cette image, et en fonction va appeler l’image à la bonne taille (et éventuellement en haute définition si écran haute déf.)

    La seconde variable permettrait de forcer le chargement en « lazy load ». Comme la valeur est zéro (par défaut), ce mode est désactivé. Si on avait forcé la valeur à 1, alors l’image ne serait chargée que si elle visible à l’écran (ou bientôt visible en scrollant). Ça permet, si on a envie, de ne pas charger des images qui seraient bien plus loin en bas de page. Ici, il est important de laisser à zéro, parce qu’on veut un code complet qui se charge dès avant le lancement de la page (voir en préchargement).

    La troisième variable est à zéro (par défaut). Si on met à un, alors on indique qu’on veut que les calculs se fassent sur la hauteur du conteneur, et non sur la largeur. Ici il faut laisser à zéro, je n’ai pas encore adapté mon code pour qu’il fonctionne avec les images alignées verticalement.

    La quatrième variable est la nouvelle : si on décide de l’utiliser, alors on va permettre au plugin de fabriquer le code complet qui fait fonctionner les images responsive directement en HTML5. C’est alors bien plus rapide à l’affichage, et le pré-chargement fonctionne sur ces images.

    Le code généré est le suivant :

    <picture style='padding:0;padding-bottom:63.5593220339%' class='conteneur_image_responsive_h'>
            <source media='(max-width:470px)'
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=50 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=50&amp;dpr=2 2x
                    '>
            <source media='(max-width:1009px)'
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=100 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=100&amp;dpr=2 2x
                    '>
            <source
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=200 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=200&amp;dpr=2 2x
                    '>
            <img class='image_responsive' alt="" src='https://seenthis.net/rien.gif' data-src='IMG/arton5.jpg' data-l='2832' data-h='1800' data-tailles='[\&#034;50\&#034;,\&#034;100\&#034;,\&#034;200\&#034;]' />
    </picture>

    Le principe de cette variable est de contenir autant de mediaqueries qu’il y a de tailles autorisées dans la première variable, en les séparant par des slash (comme pour les tailles de la première variable). Pour rappel : le 0 ne compte pas comme une taille autorisée.

    Ici, on avait les tailles autorisées : 0/50/100/200. On a donc trois tailles autorisées. Dans les medias queries, il nous faut donc définir trois valeurs correspondant à ces tailles d’images autorisées :
    (max-width:470px)/(max-width:1009px)/

    Ce qui signifie :
    – utiliser l’image de largeur 50 dans le cas (max-width:470px)
    – utiliser celle de largeur 100 dans le cas (max-width:1009px)
    – utiliser l’image de largeur 200 dans les autres cas (par défaut donc).

    Noter le slash final, qui permet de voir qu’il y a bien une troisième valeur attendue (valeur vide).

    Le plugin fabrique donc les <source> correspondant à ces tailles, en indiquant à chaque fois l’image en définition 1x et l’image en haut définition (2x).

    Sur les navigateurs qui comprennent ça (Chrome), ça fonctionne très bien : les images sont chargées bien plus rapidement (puisqu’on n’attend plus le chargement de la page, des JS et des CSS avant de lancer le chargement des images), et le preloader est censé prendre en compte ces informations. (Et si on désactive Javascript : ça fonctionne parfaitement sur ces navigateurs…)

    Actuellement caniuse.com donne 40% des visiteurs compatibles (essentiellement : Chrome – donc c’est déjà pas rien) mais la prochaine version de Firefox va l’avoir, et vu que c’est Chrome c’est webkit, je ne vois pas pourquoi Safari traînerait encore longtemps. De toute façon, c’est un enrichissement progressif : si le navigateur ne pige pas, le plugin fonctionnera comme auparavant uniquement en Javascript. (Dommage quand même que ça ne fonctionne pas sur Safari mobile, quand même.)

  • Nouvelle version (4.0) de mon #plugin pour #SPIP, image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, je viens d’introduire un srcset dans l’image.

    Attention, pour l’instant, ça n’est pris en compte que si on n’a indiqué qu’une seule dimension pour l’image, par exemple :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{200})]

    Dans ce cas, le logo est chargé en largeur de 200, avec un srcset pour le 1x et le 2x, c’est-à-dire qu’on a une image de taille unique, mais en simple ou double résolution (et, comme toujours avec mon plugin, la double résolution se fait avec une compression JPEG bien plus important).

    L’intérêt est, ici, que le preloader du navigateur fonctionne bien sur ce type d’images, et on n’attend plus le javascript pour charger la bonne image. Le javascript est tout de même là, parce que ce n’est pas encore compris par tous les navigateurs (50% d’adoption tout de même, notamment Safari et Chrome, prépondérants sur supports mobiles, qui représentent l’essentiel des écrans haute déf.) ; mais sur les navigateurs qui comprennent srcset, le javascript n’est plus utile dans ces cas-là.

    À terme, j’aimerais bien parvenir à passer toutes les options en srcset et picture/media, générés directement depuis mon plugin, mais pour l’instant je n’ai pas réellement de solution idéale. Un des écueils, c’est que dans mon principe, l’image haute définition ne doit pas être simplement l’image deux fois plus grande (sinon on a un JPEG deux fois plus lourd, alors qu’on est sur support mobile…), mais une version très compressée. Et il faudrait de plus introduire des mediaqueries dans l’appel de la fonction, et du coup on perd énormément de l’intérêt du truc.

  • Grosse modif de mon #plugin #SPIP image_responsive : il permet désormais de choisir de charger les images en lazyload
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée, c’est de transformer un des inconvénients de ce système (lancer le chargement des images après un premier rendu de la page) en avantage, et d’intégrer directement un système de lazyload : c’est-à-dire ne charger que les images qui sont réellement affichées dans les limites visibles de l’écran.

    Le plugin change de syntaxe : la deuxième variable permettait de désactiver le chargement des images haute définition, je décide de l’éliminer parce que ça ne sert à rien avec les modifs récentes (calculs et compression plus efficaces), et à la place, la seconde variable permet d’activer (si elle est mise à la valeur « 1 ») le lazyload sur cette image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_proportions{16,9}
            |image_responsive{0,1})
    ]

    Ici, |image_proportions va recadrer l’image selon les proportions 16/9e, sans réduire cependant la taille de l’image.

    Et |image_responsive va fabriquer les éléments permettant le chargement d’une image responsive. Ici, la première variable (« 0 ») est la taille de la vignette chargée par défaut (avec la valeur 0, je décide de ne pas intégrer de vignette : je charge « rien.gif » à la place). La seconde variable (« 1 ») indique donc qu’il ne faut charger cette image que si elle se situe dans la fenêtre visible.

    Au passage, le javascript de lazyload est assez marrant, j’ai privilégié l’efficacité des calculs, du coup la « position » verticale de l’image dans la page est calculé une seule fois (au chargement et au redimensionnement) et stocké dans un « data-top », puis effacé. Ça évite de faire des calculs à chaque fois qu’on scrolle. En revanche, on perd potentiellement en précision (images qui se déplaceraient dans la page, ou blocs affichés/masqués).

    À noter qu’il y a évidemment une tolérance : ça charge un peu plus que l’écran visible, c’est pas la peine que les gens voient trop que les images n’ont pas été chargées.

    Enfin, il y a désormais un calcul en javascript de la hauteur des images tant qu’elles sont en "rien.gif", ça permet de calculer plus précisément le lazyload.

    Comme d’habitude, je l’utilise sur Orient XXI :
    http://orientxxi.info

    • Je me posais la question au sujet du Lazyload, si y’avait pas une autre approche envisageable (c’est peut-être la tienne et j’ai pas compris) :
      – afficher en priorité les images visibles
      – puis aller chercher et « afficher » les autres images (sans attendre que la personne scroll, donc « en-dessous » de la ligne de flottaison)

      J’ai l’impression qu’en terme de rapidité d’affichage c’est équivalent quand on arrive sur le site, mais que cette solution est plus agréable quand on scroll parce qu’on donne une chance pour que les images aient le temps de s’afficher avant (en tous cas forcément plus qu’avec le lazyload).

      C’est peut-être au niveau de la consommation de la bande passante que la solution lazyload est plus avantageuse, mais je ne sais pas quand elle situation elle est vraiment utile.

      Après je dis tout ça un peu comme ça, je sais pas précisément comment ça marche en javascript, peut-être que ce que je propose n’est tout simplement pas possible.

      Une dernière remarque : y’a déjà un plugin LazyLoad dans SPIP.
      http://contrib.spip.net/jQuery-Lazy-Load-pour-SPIP

      Il ne fonctionne pas sur les mêmes principes, mais peut-être pourrait-il être amélioré, en lui donnant des options et tout ? Ou peut-être autonomiser cette fonction si des gens veulent l’utiliser sans le reste du plugin (là encore, tout ça est peut-être trop imbriqué...) ?

      En tous cas merci pour toutes ces contributions autour des images et du #RWD.

    • En gros, ce que fait LazyLoad, c’est de lancer le script jquery Lazy Load, très connu. Mon script est très différent, et son principe de fonctionnement est également très différent, j’ai essayé d’optimiser (limiter les recalculs de positionnement) et ça doit fonctionner en responsive (donc je ne fixe pas les dimensions des images a priori).

      Ensuite, le principe du lazy load n’est pas idéal non plus dans l’absolu (notamment parce qu’il bloque le pré-chargement des images). En tout cas, le fait de charger des images progressivement avant de les afficher, c’est l’assurance de ne pas afficher toutes les images en même temps. Si on a de grosses images, ce n’est pas grave (il y a une image par « écran », plus ou moins), mais si c’est une multitude de petites vignettes (c’est le cas de Flip-Zone), la page est redessinée plusieurs fois (à chaque vignette) et c’est pénible ; en changeant d’un coup toute une série complète de « img src », j’ai bien l’impression que les navigateurs sont optimisés et assez souvent, toute une série de vignettes s’affichent d’un seul coup. Avec un preloading individuel, ça n’a pas l’air de faire pareil (une de mes versions faisait ça : préloading puis affichage). Le preloading avant d’afficher, c’est pas mal sur tout petit écran, mais ça m’a semblé au contraire très pénible sur écran normal.

      Sinon, un preloader de toutes les images, c’est une idée, mais c’est encore un autre principe à mon avis. Je n’y suis pas favorable pour l’instant : charger des trucs « en trop », c’est justement ce qu’il s’agit d’éviter avec les image_responsive (parce qu’on est sans la 3G, parce que le smartphone n’est pas très vaillant…), alors pour le coup, ne charger que si les gens scrollent réellement. Et si tu veux faire ça, à mon avis, le mieux est encore de ne pas utiliser l’option « lazyload » de mon plugin : tu laisses le comportement normal, et je suspecte que c’est plus ou moins le principe de base d’un navigateur a qui on indique tous les « img src » d’une page – il commence par les premiers et/ou les éléments visibles.

  • Ajout à mon #plugin #SPIP image_responsive, une fonction |image_proportions
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL|image_proportions{16,9})]

    L’intérêt par rapport à image_recadre, c’est qu’il s’agit ici de modifier retailler l’image sans en diminuer la taille à des dimensions arbitraires, mais de conserver l’image aussi proche de sa taille initiale que possible.

    C’est rendu nécessaire et utilisable par le principe même du plugin image_responsive, qui va ensuite charger l’image à la taille qui va bien dans tous les cas.

  • Quelques nouveautés pour mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Que l’on utilise par exemple ainsi :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{160})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{160,0})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{0,0})]

    Comme il fonctionne bien, je l’ai désormais systématisé sur Flip-Zone :
    http://www.flip-zone.net
    Si l’on affiche le site avec plusieurs tailles d’écran, on pourra voir que les images qui sont chargées sont de tailles différentes.

    Les deux nouveautés :

    – la première variable désigne la taille de l’image par défaut ; a priori, on choisit la taille minimale d’affichage (sur mobile) ; on peut désormais fixer cette valeur à 0, et dans ce cas l’image par défaut sera « rien.gif » ; au chargement de la page, donc, rien ne se déclenche, on ne charge les images que via javascript. C’est pratique si, comme sur Flip-Zone, on peut avoir des dizaines d’images sur la page ; dans ce cas, limiter le nombre de hits est sensible.

    – la seconde variable est optionnelle, et la seule option est de la mettre à zéro. Si on la fixe a zéro, cela signifie qu’on ne chargera pas les images en haute définition (écran Retina…). En effet, l’intérêt des images responsive est double : (a) charger l’image en fonction de la maquette dans laquelle elle s’affiche à l’écran (selon la taille de l’écran, une image s’affichera par exemple sur 70 pixels de large, 160 ou 524 pixels…) ; (b) charger une image de double définition si on détecte qu’on est sur un écran haute définition (dans ce cas, on a une maquette qui affiche l’image sur « 70 » pixels, mais on affiche une image de 140 pixels puisqu’il y a deux fois plus de points affichés).

    Les deux objectifs sont parfois contradictoires :
    – le point (a) permet de limiter la taille des images chargées sur petit écran,
    – le point (b) force à charger une image deux fois plus larges, donc avec 4 fois plus de pixels, sur affichage à haute définition (souvent des smartphone…).

    Du coup, on peut décider que certaines images se chargent à leur taille d’affichage, mais sans prendre en compte le fait qu’on est sur écran haute définition. Le but du plugin dans ce cas est, essentiellement, d’accélérer l’affichage sur le site.

    Sur Flip-Zone, toutes les vignettes de navigation, qui sont des images, restent en définition normale ; certes ça se voit, mais comme ce sont des photos, je pense que c’est très acceptable vu le poids gagné sur smartphone (la situation de connexion la pire). En revanche, le logo du site, lui, se charge en haute définition sur écran haute déf… parce que c’est une image qui n’est pas très lourde, et parce que c’est un lettrage, dont l’affichage est très sensible à la haute définition.

  • Un nouveau #plugin pour #SPIP, destiné à gérer des images en #responsive : Image Responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Le plugin est actuellement installé sur Orient XXI :
    http://orientxxi.info

    Pour se faire une idée des problématiques :
    http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution

    Aucune des solutions évoquées ne me plaît, et je me suis dit qu’on a déjà dans SPIP ce qu’il faut pour s’en sortir, du coup voici une solution qui me semble intéressante.

    Notez que je suis particulièrement intéressé, ici, par des retours et des commentaires. C’est une solution très expérimentale (je l’ai codée aujourd’hui), et comme elle est du coup directement intégrée à SPIP, je pense que c’est une piste très intéressante à développer.

    Le problème à résoudre :
    – en responsive, selon la taille de l’écran, une image va s’afficher en différentes tailles ; sur la page d’accueil d’Orient XXI, c’est même très important (une même image s’affiche sur 160 pixels de large ou 460 pixels de large selon l’écran) ;
    – de plus, sur un écran haute définition, il faudrait afficher des images encore deux fois plus grandes.

    Du coup, dès qu’on commence à faire du design responsive, on a tendance à charger des images plus lourdes que ce qu’on va réellement afficher. Et ça commence à peser sur une connexion mobile pourrie.

    Noter que c’est un aspect désormais lourdement pénalisé par le calcul du PageSpeed.

    Ma solution avec ce plugin :
    – on fait passer une image (ou, si je ne me suis pas raté, un texte complet contenant plusieurs images) par le filtre |image_responsive{120}
    – cela va modifier le tag <img> :
    + le src va appeler une version réduite de l’image (ici, à 120 pixels de large),
    + l’image d’origine (celle qui est donc dans la version initiale du src) est stockée dans un data-src
    + j’ajoute une classe « image_responsive » à l’image.

    Initialement, quand on charge la page, on va charger une version déjà réduite de l’image et, idéalement, on indiquera la taille d’affichage pour smartphone.

    Une feuille de style est associée au plugin, qui force l’affichage de toutes les images de classe .image_responsive à 100% de la largeur. Attention, c’est le point vraiment important et un peu contraignant : c’est le conteneur de l’image (par exemple un <span class="logo"><img></span>) qui va déterminer la largeur d’affichage de l’image, parce que de toute façon l’image sera affichée sur 100% de cet espace. (La feuille de style va donc styler .logo éventuellement de manière responsive…)

    Une fois la page chargée, un javascript va scanner chaque .images_responsive, récupérer la largeur à laquelle elle est affichée, éventuellement multiplier par la densité de l’écran (2 pour un écran retina), et remplacer l’image par la version de cette nouvelle largeur.

    On charge donc une vignette, puis on remplace par une version de l’image à la taille exacte d’affichage.

    L’idée c’est de faire du responsive, pas du fluide. Si votre image peut s’afficher en 1000 largeurs différentes, ce plugin va finir par fabriquer 1000 fichiers graphiques différents, ce qui n’est pas forcément génial…

    – Assez simplement, là où mettait un [(#LOGO_ARTICLE_NORMAL|image_reduire{320})]
    on met maintenant un :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{120})]
    (en considérant, par exemple, que 120 est la taille d’affichage usuelle de cette vignette sur un smartphone).
    Le reste des automatismes du système se charge automatiquement via le #INSERT_HEAD, donc il n’y a rien à faire, si ce n’est vérifier que les CSS sont adaptées pour forcer le dimensionnement du conteneur de l’image plutôt que l’image elle-même.

    – Important : si votre site repose sur le .htaccess (URL sans query string), il faut absolument y insérer une ligne supplémentaire. Cela permet de traiter les images derrière des URL de fichiers JPG, ce qui devrait faciliter les mises en cache.

    Avec ça, le score PageSpeed de la page d’accueil d’Orient XXI est passée de 76/100 à 94/100. Et l’impression de vitesse sur smartphone est très très nettement améliorée.