Le plugin « Insertion avancée d’images est disponible sur la zone, et via l’installation automatique de l’espace privé de SPIP. Il est recommandé pour la version 3.0 au minimum (et, pour le raccourci <slide>, pour la version 3.1).
– Quand on a conçu SPIP en 2000, la bande passante utilisée par les images restait une question importante : on affichait les images en petit dans les articles, et on proposait de cliquer dessus pour que l’utilisateur puisse les charger uniquement s’il en a envie. Clairement, plus personne ne fait ça… On veut des images en grand et puis c’est tout. C’est aussi pour cela qu’on affiche le type et le poids du fichier dans <doc> (pour que l’utilisateur ait une idée de ce qui l’attend s’il clique sur ce terrifiant fichier de… 160ko) ; mais aujourd’hui, en dehors de fichiers spécifiques, genre gros PDF ou fichier d’image monstrueux, ça n’a pas de sens de continuer à le faire pour des images…
Bref, le coup d’insérer des petites vignettes cliquables au lieu de grandes images, ça ne se fait plus du tout.
À l’inverse, insérer de belles grandes images qui occupent toute la largeur de la colonne, c’est la norme désormais.
– Une habitude (étrange…) qu’on avait était d’insérer des petites images sans légende à l’intérieur des textes. Bon, ça non plus, ça ne se fait plus : quand on met une image, si on a une légende, hé ben on affiche la légende, ça ne coûte pas plus cher…
– Un usage que j’ai supprimé de mes sites : la différence entre portfolio et hors portfolio. Si une image est associée à un article, c’est qu’on veut l’afficher dans tous les cas (si on veut conserver des images dans le site, mais sans les associer à un article, on a maintenant la médiathèque). Donc une image s’affiche toujours de la même façon avec le raccourci <img>, et si elle n’est pas affichée dans l’article, on la mettra dans le portfolio en dessous, sans se demander si elle est dans le « portfolio » (au sens technique SPIP) de l’article, parce que c’est une notion incompréhensible pour les usagers.
Je ne l’ai pas encore fait dans ce plugin, mais je pense qu’il faudrait complètement réserver l’utilisation de <doc> à des présentations de documents à télécharger, genre grosses images ou fichiers PDF, et ne plus du tout l’utiliser pour insérer des images dans le texte. Du coup, sur mes sites, j’utilise désormais uniquement <img> pour insérer des images, et plus jamais <emb> ni <doc>.
1. Refonte du raccourci <img>
Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img> : l’image est affichée « en grand », et jamais sous forme de vignette. Elle peut être évidemment placée au centre, à gauche ou à droite, mais l’utilisation première est d’afficher l’image sur toute la colonne de texte disponible.
Une idée vraiment importante est de se débarrasser totalement de la différence entre les images du portfolio et les images hors du portfolio : les images s’affichent de la même façon dans tous les cas, et jamais sous forme de vignette.
2. Si on a mis un titre, un descriptif et/ou des crédits, ils s’affichent avec <img>. C’est dans la continuation de la logique précédente : si on met un titre, c’est qu’on veut un titre. Donc <img> affiche toujours le titre (quand il est renseigné).
3. C’est responsive, évidemment.
4. Balisage moderne avec <figure> et <figcaption>.
5. Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions. Pas de considération de la notion SPIP de « portfolio » ici (voir ci-dessus : c’est une notion qu’on devrait totalement abandonner je pense) : si une image est assez grande, elle est cliquable et puis c’est tout…
On conserve la possibilité de faire un lien hypertexte « à la main » sur une image, même si je pense que l’usage a également plus ou moins disparu de nos jours (quand on clique sur une image, on s’attend plutôt à la voir en grand, pas à changer de page).
Et ainsi, le raccourci de base est toujours :
qui affiche l’image à la largeur de maximale de la colonne de texte (éventuellement plus petite si l’image est plus petite), avec son titre, son descriptif et ses crédits, de manière responsive et en gérant les écrans haute définition :
6. Possibilité de forcer la largeur d’une image « à la main » :
Noter que techniquement, dans ce cas on aura grâce au plugin image_responsive une gestion plus avancée du balisage, mieux adaptée au chargement anticipé des images, puisque ça va utiliser le srcset avec les valeurs 1x et 2x (pour le retina).
7. Une subtilité javascript épatante ici : les images flottantes à droite ou à gauche, c’est très joli sur un grand écran, mais sur un téléphone ça détruit généralement complètement la maquette, parce qu’on met une image « flottante » de 250 pixels dans une colonne de 320 pixels, et qu’il reste du coup 70 pixels pour afficher le texte, et généralement c’est une catastrophe.
Le plugin inclue donc un mécanisme javascript qui vérifie la largeur des images flottantes et de la colonne de texte pour supprimer le float quand l’image devient proportionnellement trop large par rapport à sa colonne d’affichage (plus de 60% de la colonne de texte). Dans ce cas l’image est « forcée » en présentation centrée, avec sa légende, et on récupère un affichage optimal même sur petit écran.
À l’inverse, on peut aussi se prévoir des styles pour les écran très larges (ça c’est pas directement dans le plugin, mais le balisage le permet facilement) :
8. Option de présentation : rond : ça force l’image à s’afficher dans un cercle. Oui, tout rond. Même si l’image est un JPG, ça se fait en CSS, donc ça évite de recourir à un PNG dix fois plus gros.
Si on veut obtenir un rond exact, il faut que l’image en question soit déjà carrée. Sinon on obtiendra un oval, généralement assez moche.
Ça peut valoir le coup de l’associer à l’option largeur si on veut faire flotter une grande image à droite ou à gauche :
9. Trop mignon avec un navigateur récent : une image arrondie (avec rond) flottante forcera un habillage irrégulier par le texte : c’est-à-dire que le texte habillera le cercle de façon… circulaire, et non en rectangle. Ça se fait directement en CSS avec shape-outside. C’est automatique quand on utilise ˋrond`, pas besoin d’option supplémentaire.
10. Extrêmement puissant : on peut demander un habillage irrégulier automatiquement sur les images JPG dotées d’un fond uni grâce à l’option shape. Attention, ça n’utilisera pas ma vieille technique de « tranches » (de image_ragged), mais sur la base d’un polygon calculé avec une nouvelle fonction : image_detourer_polygon. Ça c’est carrément spectaculaire.
11. Une petite animation rigolote : l’option flip permet de faire tourner l’image sur elle-même lorsqu’elle apparaît dans le viewport (en fonction du scroll, donc). Ça donne l’impression d’une pièce de monnaie qui tourne sur elle-même avant de s’arrêter pour s’arrêter :
ça devient encore plus fun si on force l’affichage dans un rond :
ou carrément dans un rond flottant avec le détourage automatique :
12. Et enfin l’animation la plus puissante : le zoom sur un détail de l’image avec l’option kenburns (déterminé avec le plugin centre_image) :
C’est une animation volontairement lente, mais alors : extrêmement spectaculaire… Et pour le coup, ça a généralement un véritable intérêt éditorial.
13. Nouveau raccourci : <ligne>
Et enfin, la possibilité d’afficher plusieurs images sur une même ligne, avec adaptation aux différentes tailles d’écran, avec un nouveau raccourci : <ligne> :
Cela fabrique un portfolio local (on peut en faire plusieurs dans un même article) où l’on tente d’aligner les images horizontalement sur une ou plusieurs lignes, en adaptant leurs dimensions, de façon à obtenir des lignes qui occupent toute la largeur :
-
Au plus près de la planète Mars
-
L’état de plasma
-
Au plus près de Saturne
-
La saga du micro-ordinateur
Noter qu’ici encore, s’il y a des titres, descriptifs et/ou crédits, ça s’affiche. Sinon, non.
C’est à la fois très puissant, et assez déstabilisant, parce que la composition est automatique et… responsive. Du coup l’affichage dépend énormément des proportions des images et de la taille de l’écran. Du coup il faut réussir à se faire à l’idée que l’affichage sera variable, semi-automatique, et ne pas chercher à avoir des positionnements absolus qu’on décrète soi-même (ce qui est le « problème » de la mise en page responsive : il faut accepter que ça se recompose).
14. Ça prend en compte l’option large :
qui se contente d’insérer une classe .large. Ça ne sert pas à grand chose pour l’instant, mais c’est extrêmement utile dans un autre de mes plugins (pas diffusé pour l’instant), et chacun pourra de toute façon bidouiller ses feuilles de style soi-même : ça permet d’afficher cette image plus large que la colonne de texte.
15. Nouveau raccourci : <slide>
Il y a désormais un raccourci super-méga-trop-la-classe : <slideXXX>, qui fabrique automatiquement un slider horizontal quand on en met plusieurs à la suite. Par exemple :
provoque l’affichage suivant :
À l’usage : je recommande d’avoir pour ce slider des images ayant exactement les mêmes proportions, c’est ce qui donne l’aspect régulier et bien aligné de ce genre de présentation. Si les images n’ont pas les mêmes proportions, on se retrouve avec des images de hauteurs différentes, l’alignement horizontal n’est plus respecté, et c’est nettement moins élégant.
Je suis très content, c’est totalement responsive, multilingue (même en direction rtl) et ça fonctionne entièrement sans Javascript. (Attention, limitation : on ne peut mettre actuellement que 8 images à la suite, mais ça fait beaucoup pour un slider.)
L’intérêt c’est de mettre ces petits sliders (idéalement 2 ou 3 images pas plus) directement dans le corps du texte, et donc d’en mettre plusieurs dans différents endroits du texte si on veut.
Un petit javascript gère, par ailleurs, le « swipe » horizontal pour passer d’une image à l’autre sur écran tactile.
