• Avec Mosquito, on vient de livrer le site de la Fondation Custodia :
    https://www.fondationcustodia.fr

    Comme d’habitude, c’est du #SPIP, #HTML5 #responsive et tout ça…

    Parmi les points à voir en particulier…

    – Un menu hamburger tout mignon.

    – Des #longforms pour la présentation des expositions :
    https://www.fondationcustodia.fr/Georges-Michel

    – Dans ces longforms, on peut présenter des collections d’œuvres avec mon raccourci <ligne>, qui présente les images sur une ou plusieurs lignes, en adaptant la taille des images pour occuper la largeur de l’écran :

    – Ou avec mon raccourci <slide>, qui présente les documents les uns à côté des autres sur une ligne.
    https://www.fondationcustodia.fr/Les-portraits-en-miniature-12

    Pour rappel, « ligne » et « slide », c’est dans mon #plugin « Insertion avancée d’images », documenté ici :
    http://www.paris-beyrouth.org/Plugin-SPIP-Insertion-avancee-d-images

    On trouvera même quelques habillages automatiques de formes irrégulières, toujours avec ce même plugin, et le raccourci <img|shape> :


    C’est pas toujours évident à utiliser à bon escient, mais là ça donne un aspect « imprimé » particulièrement chic je trouve.

    – Dans les « formes longues », un problème usuel, c’est la navigation verticale « trop » longue, et donc l’utilisation d’une sorte de table des matières pour pouvoir naviguer rapidement. Mine de rien, c’est toujours assez problématique. Là j’ai développé une solution que je trouve bien sympathique, avec une table des matières en haut à gauche de l’écran, qui se plie/déplie, au fur et à mesure du scroll, et au survol, pour indiquer où on est et qui, évidemment, permet de naviguer au clic :

    Détail mignon : pour réaliser le graphisme de ce petit menu, il n’y a pas une seule image, c’est entièrement réalisé en CSS.

    – Il y a une maquette assez sympa pour la présentation des « Collections », avec des panneaux qui défilent horizontalement (et c’est responsive, la présentation change assez radicalement sur téléphone ou tablette) :
    https://www.fondationcustodia.fr/les-portraits-en-miniature

    – Il y a aussi une présentation avec un « méga-zoom » sur les images, pour la présentation des œuvres des « Catalogues », mais comme le contenu n’est pas encore en ligne, alors je reposterai un message pour que tu ailles voir quand ce sera prêt.

    – Quand on clique sur la loupe de recherche, hop un grand pavé recouvre l’écran :

    – Enfin, sur ce site, je me suis particulièrement astreint à ce que toutes les animations/interactions/transitions soient autant que possible réalisées sans Javascript. Du coup, on peut naviguer sur le site avec Javascript désactivé, avec un minimum de dégradations (essentiellement : des images responsive qui vont rester en basse définition). Mais le menu hamburger se déploie, avec ses sous-menus animés, comme si de rien n’était ; le système de « table des matières » des longforms fonctionne très bien, avec ses animations au survol, les sliders un peu partout fonctionnent de manière transparente… (et évidemment : des interactions « au doigt » moins riches sans Javascript).

    – Enfin la page d’accueil obtient un score de 100/100 sur mobile avec PageSpeed, et 97/100 sur ordinateur, c’est chouette.

    À l’intérieur du site, j’ai le plugin Saisies qui me fait chuter la moyenne sur quelques pages, en m’insérant violemment des appels à un fichier CSS et un fichier Javascript (ah, c’est vache !). :-))

    #shameless_autopromo

    • Un effet que j’aime bien sur ce site : j’ai mis des dégradés colorés sous les grandes images, pour avoir quelque chose qui s’affiche avant que les images soient chargées.

      Ce qui donne par exemple, avant chargement de l’image :

      et une fois l’image chargée :

      Ce que je réalise directement dans le squelette ainsi :

      #image_haut {
              background-color: [#(#LOGO_ARTICLE_RUBRIQUE|couleur_extraire)];
              background: linear-gradient(to bottom,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,1})] 0%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,5})] 25%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,10})] 50%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,15})] 75%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,19})] 100%
              );
      }
      #image_haut:before {
              position: absolute;
              top: 0;
              left: 0;
              width: 100%;
              height: 100%;
              content: " ";
              z-index: 1;
              background: linear-gradient(to right,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{1,10})] 0%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{5,10})] 25%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{10,10})] 50%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{15,10})] 75%,
                      [#(#LOGO_ARTICLE_RUBRIQUE|image_proportions{16,9, focus}|couleur_extraire{19,10})] 100%
              );
               mix-blend-mode: soft-light;
      }
    • @realet Je viens de mettre en ligne une détection du focus en javascript, pour plier ou déplier le menu hamburger selon qu’on est sur un lien dans le menu ou en dehors.

      Je fais ceci :

              $("#menu_flottant a").on("focus", function() {
                      $("#afficher_menu").prop("checked", true);
              });
              $("body > *:not(#menu_flottant) a").on("focus", function() {
                      $("#afficher_menu").prop("checked", false);
              });
  • 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

    • Et je viens d’ajouter un paragraphe sur le précalcul des images avec _IMAGE_RESPONSIVE_CALCULER, ainsi que l’ajout de liens <link> pour faciliter l’aspiration du site, avec _SPIP_LIER_RESSOURCES.

  • 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})]
  • J’ai commencé un nouveau #plugin pour #SPIP : centre_image
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/centre_image

    Après installation (PHP 5 au minimum : on a besoin de la fonction image_filter), on se retrouve avec 3 filtres qui s’appliquent à des images :
    centre_image($fichier) retourne un tableau array{x,y} du centre d’intérêt de l’image,
    centre_image_x($fichier) et centre_image_y($fichier) sont plus directement utilisables dans les squelettes, puisqu’ils retournent indépendamment la valeur x et la valeur y de la fonction précédente.

    x et y sont des valeurs entre 0 et 1 (x à 0 à gauche, 1 à droite ; y à 0 en haut, 1 en bas), qui donnent les coordonnées du « point d’intérêt » de l’image, calculé automatiquement sur le principe de l’« entropie ».

    Quelques éclaircissements :

    – un problème classique quand on recarde une image automatiquement, c’est que selon la nature de l’image, on n’obtient pas un recadrage pertinent (têtes coupées parce qu’on a visé trop bas, statue hors cadre parce qu’on a coupé au centre…) ; du coup, je viens déjà d’introduire un réglage automatique dans la fonction image_proportions livrée dans le plugin image_responsive (version 5.0 à l’instant) :
    ``image_proportions($img, 16, 9, "focus")``
    là où l’on pouvait déjà indiquer top, left… si on indique focus, alors l’image sera recadrée en fonction du résultat du nouveau plugin ;

    – une difficulté que je veux régler, c’est l’utilisation de grandes images en fond de page : quand on écrit la tritraille dessus, on fait dans le systématique, et du coup ce n’est pas forcément le plus heureux ; avec ce plugin, on peut décider que si le point d’intérêt de l’image est à gauche, alors on installera la titraille à droite sur l’image (et inversement) ;

    – une orientation que je veux développer pour le plugin image_responsive (d’où le passage en version 5) : faciliter et automatiser la « direction artistique », c’est-à-dire la possibilité d’afficher une version zommée sur le point d’intérêt de l’image quand on l’affiche en petit ; si je connais le « point d’intérêt » avec l’autre plugin, une partie du boulot est déjà fait…

    – le gros hic, c’est que la méthode fonctionne couci-couça (mais vu le but, je pense que c’est très acceptable : avant on coupait ou on plaçait les éléments carrément au pif)… la prochaine étape du développement va consister à donner des outils pour que le webmestre puisse, d’un clic, « forcer » le placement du point d’intérêt.

    • Un petit squelette pour tester sur des documents pris au hasard sur ton site :

      <html>
      <body>

      <BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{inverse}{extension=jpg}>
      <div style="position: relative; float: left;">
      [(#FICHIER|image_reduire{200})]

              <div style="position: absolute; margin-left: -7px; margin-top: -7px; left: [(#FICHIER|centre_image_x|mult{100})]%; top: [(#FICHIER|centre_image_y|mult{100})]%">
              <img src="[(#CHEMIN{imgs/croix.png})]">
              </div>

      </div>
      </BOUCLE_documents>

      </body>
      </html>
    • @speciale : comme tu le vois, si tu passes par |mult{100}%, tu obtiens bien des pourcentages. J’ai préféré la vieille méthode du pseudo-pourcentage en stockant directement la valeur entre 0 et 1 (0.35 est égal à 35%), parce qu’avec des vrais pourcentages, il faudrait que je stocke aussi le symbole % dans la variable, et là c’est super-lourd derrière (si tu veux faire des manipulations mathématiques, tu dois alors d’abord virer le symbole de pourcentage…)

    • Sympa, je l’ai testé avec le petit squelette suivant et une sélection d’images déposées dans squelettes/images :

      <h1>dans ta face !</h1>
      <BOUCLE_ls(DATA){source glob,  #CHEMIN{images}/*.jpg}>
      [(#VALEUR|image_reduire{150})]
      [(#VALEUR|image_proportions{1,1,center}|image_reduire{150})]
      [(#VALEUR|image_proportions{1,1,focus}|image_reduire{150})]
      <hr />
      </BOUCLE_ls>

      J’ai bien fait attention à utiliser des images où « le centre d’intérêt » était déporté dans un coin et jamais au centre, et le résultat était souvent bon. Le squelette de test affiche l’image originale réduite à 150 px, puis la même « recadrée » au centre et enfin une version recadrée #automagiquement sur le focus. Du coup, cela permet de mettre en évidence l’action de l’argument focus par rapport à un recadrage au centre.

      Idée, je pense que ça serait sympa d’intégrer la fonction image_proportions dans le plugin filtres images du core (elle y a sa place amha). Et puis, cela permettrait aux personnes qui le souhaitent de jouer avec centre_image sans installer image_responsive. Tu en penses quoi @arno ?

      #spip_blog #merci :)

    • yep @b_b et @arno, je suis d’accord, je l’ai dit plusieurs fois : ça commence à faire un certain temps maintenant qu’on a nos fonctions d’images dans un plugin bien propre séparé du core (et fourni en dist), donc pour moi TOUTES les fonctions d’images intéressantes devraient s’y trouver, une fois qu’on les a un peu testé. D’après moi ça n’a pas de sens d’avoir plusieurs plugins différents comme « conteneur » de fonctions d’images (sur la zone/contrib il y avait un plugin de fonctions supplémentaires comme ça). On balance tous les trucs utiles dans le plugin commun.

      @nidal j’avais commencé un tout début de truc, mais jamais eu le temps de le faire en entier parce que sur mon temps libre j’essaye de ne pas coder. :)
      Mais je l’ai toujours en tête, et j’en ai même reparlé dans le cadre un projet pro cette semaine…

      Je ne pense pas que ce soit un truc énorme à faire, peut-être une idée d’atelier en plus pour la rencontre de Toulouse dans 3 semaines.

    • @b_b : je suis d’accord. La difficulté, c’est de savoir ensuite comment on continue à faire évoluer ces fonctions une fois qu’elles sont dans le core. (La dernière fois que j’ai voulu intervenir dans un plugin_dist, on m’a annulé ma modif en me renvoyant à des séries de tests à valider et tout et tout. Autant dire que ça me fait chier si c’est pour retourner là-dedans.)

      Après, en l’occurence, on a spip_proportions stable et bien pratique qu’on pourrait sans difficulté ajouter au core. Mais là il s’agit d’intégrer dedans la fonctionnalité « focus », qui est carrément expérimentale. Je ne sais pas trop comment on gèrerait ça.

    • @arno ça pourrait pas être géré à base de pipeline(s) ? La fonction image_proportions (générique, dans le noyau) pourrait avoir un pipeline quand on est dans le cas « focus ». Quand y a rien de spécial, ça prendrait le centre par exemple, mais un plugin pourrait s’insérer dedans et définir X et Y. Cette fonction n’aurait pas à connaître qui peut venir changer ça. Et ce serait donc au plugin centre_image de s’insérer dans le pipeline et de définir X et Y suivant sa méthode. Un truc comme ça.

      Après on peut aussi se dire qu’il n’y aura toujours qu’une seule manière de trouver un centre de manière automatique, et qu’il y ait une fonction unique (non existante par défaut) qui peut être définie (par un autre plugin donc) et quand elle est définie ça l’utilise pour sortir X et Y.

      Mais bon pipeline ou fonction unique, le principe reste le même : « image_proportions » doit juste permettre de s’y insérer (dans le cas « focus » tout du moins), en donnant l’image en question et en permettant de renvoyer un X et un Y.

    • Yo @arno, je viens de voir que tu viens de commiter un ajout pour permettre la définition explicite manuelle du focus d’une image : Allelujah ! :D

      Du coup ça correspond tout à fait au plugin « Focus » que j’avais mollement commencé et dont je parlais. Si ton plugin peut bien être utilisé de manière tout à fait autonome, c’est vraiment ça.

      Par contre je ne comprenais pas où tu stockais les coordonnées du focus. Mais après lecture, il semblerait que tu les gardes dans un fichier JSON contenant le MD5 de l’image, c’est ça ?

      Du coup, en plus d’être utilisable pour les images « spip_documents » avec l’ajout d’interface que tu as fait, c’est potentiellement utilisable aussi pour d’autres images non-"spip_documents", c’est ça ? (Bon ce sont des cas plus rares hein, mais c’est toujours bien de le savoir.)

      #merci !

    • @rastapopoulos : exactement, ça se base « bêtement » sur l’URL du fichier. Dans l’espace privé, ça récupère toutes les images qui ont un lien .hasbox et un type image/…. Et j’ai ajouté l’exclusion sur les images qui sont intégrées à l’intérieur des articles, sinon ça se met à déconner (à cause des doublons).

    • Attention : la nouvelle version réclame qu’on utilise la dernière version du plugin-dits medias, et mon plugin contient des motifs pour forcer l’affichage des images de portfolio en grand (150 pixels de large, et non plus les minuscules trucs de 60 pixels).

      C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

      Dans l’interface privée, un javascript va attaquer les logos et les documents joints :

      Sur la seconde image, on voit bien la différence avec l’actuel : les vignettes sont de très bonne taille (ça donne une impression d’interface carrément plus moderne).

      Le javascript récupère chaque image, et à chacune ajoute un petit cadre vert (indiquant que le centre d’intérêt est chargé), et une croix à l’endroit du centre d’intérêt automatique.

      Si on veut corriger, c’est immédiat : on prend la croix, on la fait glisser vers le centre d’intérêt et voilà, c’est corrigé. Je vois pas comment faire plus simple.

    • Autre question : le filtre « image_recadre » du noyau sait aussi prendre en entrée un ratio maintenant ("3:2, +").
      (Et du coup image_proportions est-il d’ailleurs toujours pertinent, peut-être vaut-il mieux mutualiser puisque la fonction du noyau sait déjà le faire.)

      Mais du coup il manque le fait de pouvoir donner des pourcentages (ceux de centre_image) dans le troisième argument $position, il me semble, c’est ça ? (Car je crois que ça ne connait que top, left, etc.)

      Et un corollaire : dans ce genre de recadrage, si on donne le point de focus, c’est pour qu’il soit « à peu près » au centre une fois le recadrage terminé. Mais suivant où il est placé, ce n’est pas forcément pile au centre. S’il est proche d’un bord, ben ça doit s’arrêter au bord.

    • C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

      ( je ne vois pas ton message sur spip-dev)

    • Oui, je suppose qu’il faudrait aussi améliorer image_recadre, mais encore une fois c’est une question pratique : image_proportions est chez moi et je peux le patcher instantanément. Dans le core je ne sais plus trop si j’ai le droit de patcher ou si je vais me faire jeter.

      Pour ta dernière remarque, oui c’est pris en compte : on recadrer au plus proche du centre d’intérêt, mais ça ne va pas forcément le placer au centre si ce point est près du bord. Mon code qui fait ça n’est pas d’une compacité folle, c’est parce que ça laisse la logique mathématique plus visible comme ça :-))

    • Ah et aussi en rapport : ce plugin jQuery qui recadre en javascript suivant le focus de chaque image (qu’on précise dans le code de l’image) :
      http://seenthis.net/messages/289821

      Cela peut être complémentaire pour générer moins d’images, et aussi pourquoi pas pour définir les hauteurs d’images en « em » afin d’être alignées sur la grille typo et les largeurs sur la grilles des colonnes (qui peut être en %), et donc pas toujours la même proportion suivant l’écran.

    • @rastapopoulos : j’ai un script remplir_image.js qui fait ça aussi. Mais l’avantage avec image_proportions et les nouvelles subtilités d’image_responsive (et <picture>), c’est qu’on n’attend plus sur javascript pour charger et afficher les images. Avec Chrome pour l’instant (et Firefox le mois prochain), c’est incroyablement plus réactif que quand on compte sur jQuery pour faire des calculs et des affichages.
      http://seenthis.net/messages/264068

    • @arno pour le core, logiquement, tu as le droit de patcher tant que ça ne casse rien à l’existant.

      Si on veut faire « propre », je crois qu’il y a deux méthodes pour ça :

      – Soit la fonction a une batterie de tests unitaires. Et donc tu peux modifier dans la branche stable (3.0), tester si ça renvoie toujours les bons trucs pour les anciens comportements, et si tests ok, commiter. Si on part du principe que les tests unitaires sont complets, alors tant que ça renvoie ok, toute modif peut être commitée sans danger.

      – Soit ya pas de tests, ou bien tu n’as pas le temps de comprendre comment les faire tourner (hihi). Dans ce cas, tu peux modifier dans la branche dev (3.1) ! Tu testes sur tes cas à toi (pas les tests unitaires normalisés du coup), et si tu penses que c’est bon, tu envoies en 3.1. Du coup c’est public et tu peux demander à d’autres de tester ton ajout. Si plusieurs personnes pensent que c’est bon (ou que personne ne répond pendant longtemps :D) : tu reportes ta modif dans la branche stable (3.0). Un « backport ».

      Ça ce sont les deux manières qui normalement devraient toujours marcher. Sinon c’est pas gentil. :)

      Après, au-delà, il est possible aussi de commiter directement en 3.0 sans tests unitaires, et reporter en 3.1 (c’est moins logique mais c’est logique quand on est dans un projet réel qui utilise la stable !). Là faut juste être sûr de soi, de ne rien casser.

      Enfin, mon avis purement personnel est que ce serait super que tu améliores image_recadre du noyau avec ces ajouts (notamment le fait de pouvoir lui passer les coordonnées précises), et que ça soit ainsi mutualisé dans un seul endroit (le plugin d’images du noyau, commun à tou⋅te⋅s).

    • Un truc qui me questionne : je vois que ça enregistre les coordonnées calculées ou forcées dans local/ ... du coup, si on vide le cache des images, on perd les coordonnées qu’on avait forcées à la mano en déplaçant la croix ?

      Est-ce qu’il ne vaudrait pas préférer, si on est dans le cas d’un document eregistré dans la table spip_documents, ajouter 1 ou 2 champs pour stocker les coordonnées ?

    • Là l’avantage c’est que ça marche pour n’importe quelle image, même quand c’est pas un document SPIP (les logos par exemple, mais ça pourrait être d’autres choses).

      Mais par contre oui, l’emplacement des JSON posent clairement un problème : une vraie information pérenne ne DOIT PAS se placer dans un dossier temporaire. :D

      Pour rappel, SPIP à 4 dossiers variables : 2 fixes, et 2 temporaires. Et dans le même temps : 2 accessibles, et 2 inaccessibles.

      Les noms des dossiers sont très mal choisis mais restent là par compatibilités. Mais dans le code les noms sont beaucoup plus clairs et logiques :

      – permanent_accessible : IMG
      – permanent_inaccessible : config
      – temporaire_accessible : local
      – temporaire_inaccessible : tmp

      En conséquence, les infos de positions sont permanentes, et accessibles. Et donc si on ne veut pas les enregistrer en base, mais dans des fichiers, alors elles devraient aller dans IMG, pas dans local.

    • @marcimat non non : image_recadre fait déjà les proportions (et je l’utilise régulièrement). Donc pas besoin d’ajouter une fonction pour ça à mon avis.

      Au lieu de faire |image_passe_partout|image_recadre maintenant je fais |image_reduire{taille maximum que je veux}|image_recadre{16:9,''}.

      Mais ce qu’il faudrait du coup, c’est améliorer image_recadre qu’on a déjà, pour lui intégrer la possibilité de définir le centre manuellement et précisément dans l’un de ses paramètres.

    • Ce plugin m’intéresse particulièrement en conjonction avec le plugin image_responsive, plus précisément dans ce qui était décrit dans le premier post avec la fonction image_proportion.
      Cependant,
      #FICHIER|image_proportions{16,9,"focus"}|image_responsive{320/640,1,0}
      avec ou sans guillemets à focus, ne semble rien donner de manière automatique. Si l’on définit le focus de l’image, cet argument semble inutile.
      Je suis en SPIP 3.0.20, Filtre image_responsive en 6.4.1 et Centre image en 0.5.1.

      Merci pour tous ces plugins et pour le coup de main :)

    • J’ai ajouté en SPIP 3.1, en espérant ne rien n’avoir cassé, la possibilité d’utiliser le centrage avec la fonction |image_recadre, du plugin fonctions_images qui est fourni par défaut avec SPIP

      Donc, on activant ce plugin, sans forcément avoir le plugin image_responsive, on peut utiliser des recadrages en centrant sur le point d’intérêt, de la sorte :

      [(#LOGO_ARTICLE|image_recadre{16:9, -, focus})]

      ou encore, pour avoir une taille spécifique

      [(#LOGO_ARTICLE|image_recadre{200:80, - focus}|image_reduire{200, 80})]

      Il y a aussi focus-center comme dans image_proportions.

    • J’ai une question : je viens de rajouter une invalidation du cache (http://zone.spip.org/trac/spip-zone/changeset/97747) pour pouvoir voir l’effet d’un changement du point d’intérêt immédiatement.
      Du coup, j’ai étudié un peu le code et j’ai été sidéré de voir qu’au lieu de sauvegarder dans la base, c’était un fichier .json qui était créé pour enregistrer la position du point d’intérêt.
      Qu’est-ce qui a présidé à ce choix technique ?

    • Je me suis fait une fonction sympa :

      // Permet de recadrer une image en la centrant sur son focus
      function focusimage($img, $largeur, $hauteur, $position = 'center') {
              if ((largeur($img) <= $largeur) AND (hauteur($img) <= $hauteur)) {
                      $img = image_recadre($img, "$largeur:$hauteur", '+', $position, 'transparent');
                      $img = image_recadre($img, $largeur, $hauteur, $position, 'transparent');
              } else  {
                      $img = image_recadre($img, "$largeur:$hauteur", '-', 'focus', 'transparent');
                      $img = image_reduire($img, $largeur, $hauteur, $position, 'transparent');
              }
              return $img;
      }

      Et si l’image est plus petite, elle est affichée au centre par défaut, mais on peut indiquer sa position.

    • Merci pour ce plugin qui s’avère rapidement être indispensable.
      Une chose à préciser dans une éventuelle future documentation (c’est peut-être mentionné dans le fil de discussion mais j’ai pas tout relu) : le point d’intérêt n’est pris en compte que si le filtre image_recadre est appliqué en premier à l’image.

      Ceci fonctionne :
      [(#LOGO_PATATE|image_recadre{4:3, -, focus}|image_machin|image_truc)]

      Mais pas cela :
      [(#LOGO_PATATE|image_machin|image_truc|image_recadre{4:3, -, focus})]

    • Oui et on disait avec @marcimat que peut-être ça pourrait être bien de garder en mémoire cette info au fil des modifs d’une image OU de garder en mémoire la toute première image source quand il y a une suite de filtres d’images d’affilée, et SI la dernière chose avant le « recadre » a les mêmes dimensions que l’image d’origine, alors on peut recadrer avec le même centre, même 12 filtres plus loin.

      Bon, en attendant, faut bien le mettre en premier…

  • 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.

  • Encore du nouveau sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, il s’agit de pouvoir calculer la taille de l’image en fonction de la hauteur, et non plus de la largeur, de la boîte qu’elle occupe. (Et il y avait un bug dans la version précédente, qui faisait qu’il n’y avait jamais d’image de prévisualisation.)

    Pour cela, introduction d’une troisième variable :

    [(#LOGO_ARTICLE|image_responsive{0,0,1})]

    Ici, pas de vignette de prévisualisation au chargement de la page (première variable à 0). Puis pas de « lazy load » (deuxième variable à 0 ; l’image responsive est chargée au document.ready, même si elle est en dehors de l’écran). Et le troisième argument, qui est nouveau, lorsqu’il est à 1, indique qu’on ne va pas calculer l’image selon la largeur de sa boîte, mais selon sa hauteur.

    Je pense que c’est d’un usage très spécifique, parce que concevoir une interface (qui plus est responsive) en définissant les hauteurs de boîtes plutôt que les largeurs, c’est assez coton.

    Au passage, il faut re-modifier le .htaccess.

    Exemple minimal : on place les logos des articles les uns à côté des autres, et ils auront la même hauteur (celle de la boîte contenante : 120 pixels ; ou, automatiquement, 240 pixels en écran haute définition) :

    <div style="height: 120px;">
    <BOUCLE_articles(ARTICLES){par date}{inverse}{0,5}>
    [(#LOGO_ARTICLE|image_responsive{0,0,1})]
    </BOUCLE_articles>
    </div>
    • Bonjour ARNO et un grand merci pour ce plugin.

      Puisque le but ici est d’optimiser les images envoyées en fonction de la taille nécessaire, ne serait-il pas judicieux de passer en plus par le plugin smush pour réduire encorela taille de ces images ?

      Pour l’instant |image_responsive|image_smush ne fonctionne pas je suppose que ce serait au javascript de permettre ce détour.

      Qu’en penses-tu ?

  • Une nouveauté sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée est de pouvoir désormais fixer arbitrairement quelles largeurs d’image on autorise.

    Le principe initial d’image_responsive, c’est de charger l’image une fois qu’on a calculé la page, donc on connaît déjà la largeur réelle d’affichage de l’image. De cette façon, on charge exactement l’image à la taille à laquelle on l’affiche.

    Du coup, il devient totalement inutile même de gérer la largeur réelle de l’image en amont. Ça fonctionnait bien dans mes maquettes précédentes, avec au final un nombre limité de tailles d’images différentes. En laissant faire le plugin, je fabrique certes beaucoup de tailles de la même image, mais pas de façon excessive.

    Le hic, c’est lorsque j’affiche l’image carrément en pleine largeur de l’écran (habituellement, j’étais plutôt dans des largeurs d’affichage fixées). Là, je me retrouve avec la possibilité de calculer des centaines de versions d’une même image, en fonction de la taille de la fenêtre d’affichage.

    Du coup, j’introduis la possibilité de fixer les tailles autorisées pour charger les images :

    [(#LOGO_ARTICLE
        |image_proportions{3,2}
        |image_responsive{320/600/1024}
    )]

    Ici, je fabrique une image de proportions 3/2 (de largeur indéterminée dans ces proportions, je m’en fiche), puisque j’insère une vignette de prévisualisation de 320 (la première valeur). Le javascript qui charge l’image définitive, lui, ne chargera des images que de 320, 600 ou 1024 (en fait : plus les versions haute définition, donc potentiellement six versions de l’image). Exemple : si j’affiche l’image sur une largeur de 479 points, alors je charge l’image de largeur 600 (que je réduis donc à l’affichage).

    On perd évidemment un peu de l’efficacité du plugin, puisqu’on charge une image un peu plus grande que celle qu’on affiche, mais cela évite d’avoir des centaines d’images différentes calculées dans certains cas.

    Si on ne veut pas de vignette de prévisualisation mais les mêmes tailles autorisées au chargement a posteriori, la première valeur à indiquer est 0 :

    |image_responsive{0/320/600/1024}

    Je l’utilise sur la page d’accueil de ce site (#shameless_autopromo) :
    http://festival-scenaristes.com

  • 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.

  • Changeset 13550 – SPIP – Trac
    http://trac.rezo.net/trac/spip/changeset/13550

    La balise #LOGO_ARTICLE et consorts rentrent dans le moule commnun. Les faux filtres |fichier et |lien sont remplacés respectivement par l’écriture #LOGO_ARTICLE** et #LOGO_ARTICLE*. Les faux filtres de positionnement (top,left,right,center,bottom) et les balises #URL_xxx en position de filtres sont à présent à écrire comme argument de la balise, l’écriture #LOGO_ARTICLE|left est donc remplacée par #LOGO_ARTICLE{left} et l’écriture #LOGO_ARTICLE|#URL_AUTEUR est donc remplacée par #LOGO_ARTICLE{#URL_AUTEUR} . Ces deux écritures peuvent se combiner entre elles et avec les deux nombres donnant les dimensions, comme dans LOGO_DOCUMENT{#URL_ARTICLE,bottom,60,80} , l’ordre des 4 paramètres étant libre. Avec tout ça, il n’est plus nécessaire d’écrire || pour stipuler que les filtres normaux commencent.

    #spip #images #css #webdesign #webdev