Je viens d’uploader un de mes plus importants #plugin pour #SPIP (au sens où c’est un de ceux que j’utilise le plus désormais, et qui change le plus l’aspect des sites que je développe) : Insertion avancée d’images
►https://zone.spip.org/trac/spip-zone/browser/_plugins_/medias_responsive_mod
C’est vraiment un gros truc, avec beaucoup de choses, je vais le documenter au fur et à mesure…
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.
Outre le fait que personne ne comprend vraiment la logique <img>, <doc> ou <emb>, la question qui prime est le fait que les usages qui ont justifié ces différents raccourcis ont disparu.
– 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 occupe 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>.
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).
6. Possibilité de forcer la largeur d’une image « à la main » :
<img23|right|largeur=300>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.
<img13|center|rond>Ça peut valoir le coup de l’associer à l’option largeur si on veut faire flotter une grande image à droite ou à gauche :
<img13|left|rond|largeur=200>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 :
<img13|center|flip><img13|center|rond|flip>ou carrément dans un rond flottant avec le détourage automatique :
<img13|left|rond|flip|largeur=200>
12. Et enfin l’animation la plus puissante : le zoom sur un détail de l’image (déterminé avec le plugin centre_image) :
<img13|center|kenburns=1.6>Je pense qu’il faudrait renommer l’option simplement zoom, parce que personne n’arrive jamais à mémoriser ça…
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. 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> :
<ligne13>
<ligne14>
<ligne15>Ça c’est vraiment impressionnant… (en revanche, je n’utilises pas le même code HTML que pour les <img>, alors que je pense que je devrait le faire, pour profiter des raccourcis décrits précédemment).
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).
Bon, je dois m’absenter pour la journée, je compléterai avec des copies d’écran plus tard. Mais déjà, j’invite les Spipeurs•ses à jouer avec, parce que c’est un outil que j’installe sur tous mes sites, et qui change radicalement leur fonctionnement. Je suis très très très très preneur de retours à ce sujet.
Pas testé, mais sur le principe ça rejoint en partie le plugin Medoc de @tetue, en ajoutant le côté responsive.
Mais il y a beaucoup de gadgets visuels : ça mériterait deux plugins distincts (un plugin = une fonction).
Après, la « doc » et la discussion sur seenthis n’engagent pas vraiment la discussions avec la communauté #SPIP.
Ma remarque sur le lieu approprié pour le discussion est un peu sèche et pourrait être mal interprétée : pas d’arrière pensée de ma part, juste une remarque pratique sur le fait que tu « invites les Spipeurs•ses à jouer avec ».
@nicod_ : yep, attention à ne pas confondre évol d’affichage des modèles et débug ergo.
1) Medoc n’est qu’un patch (grossier) qui corrige un bug ergo (hyper chiant quand on y confronté, totalement imperceptible pour les autres)
2) et (plein) d’autres plugins proposent des variantes d’affichage des modèles, responsive ou pas, toussa, toussa…
En tant que patch correctif, Medoc s’utilise avec n’importe lequel de ces autres plugins (dont il doit rester distinct).
Il n’aura plus de raison d’être lorsque le « mode » (« image » ou « document ») aura disparu de la table spip_documents ainsi que ses implications (différence entre portfolio et hors portfolio)… chose que je suis infichue de savoir faire, d’où cet affreux petit sparadrap appelé Medoc ;)
@arno : je suis ravie à l’idée d’essayer ton plugin prochainement :)
Merveilleux ! Super boulot, merci de le partager !
Une remarque sur la notion d’image insérée sans légende, c’est en fait essentiel pour l’accessibilité de pouvoir définir un titre inséré dans le alt de l’image, mais qu’on ne tient pas à afficher en dessous de l’image en légende.
Actuellement
– <img> insère l’image avec le titre en alt
– <doc> insère l’image avec le titre en légende en dessous
Donc, dans la logique de ce que tu as fait, un paramètre |legend ou |nolegend serait pertinent, non ?
@tetue me suis mal exprimé, et trop vite.
Je parlais de
Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img>
qui est le côté très intéressant du plugin de @arno, et qui rejoint ta réflexion sur medoc.
Avec l’ajout du paramétrage de largeur et le côté responsive, ça en fait un travail intéressant qui peut alimenter la réflexion sur la refonte de la gestion des docs dans SPIP (d’où ma remarque également sur le lieu pour en discuter).
Merci @arno , ce plugin a l’air très bien, et rempli de bonnes idées.
Une remarque sur <ligneXX> : je vois* que cela crée autant de <ul> que de <ligne>. Est-ce qu’une syntaxe tel que <ligne|XX,YY,ZZ> ne serait pas plus appropriée, ce qui permettrait de n’avoir qu’un conteneur pour les 3 documents ?
Le terme « ligne » en lui-même aussi est un peu flou, mais je n’ai pas d’idée là comme ça à part avoir une autre notion tel que <images|ligne|XX,YY,ZZ> , <images|cases|XX,YY,ZZ> peut être… ce qui deviendrait un « modèle d’affichage d’une liste de documents sélectionnés »
* note : le modèle est ainsi fait, mais un pipeline enlève ensuite les ul en trop sur ces lignes…
Ah ou… si autant de balises <ligneXX> que de documents à afficher est conservé (plutôt que d’1 pour n documents), pourquoi ne pas utiliser plutôt <imgXX|ligne> ou <docXX|ligne> finalement directement ? ça paraîtrait bien également non ?
Génial ! Le plugin a l’air très très complet et global. Un grand merci Arno* !
Sur <ligne>…
D’abord, je voudrais refaire le code de ce modèle pour qu’il utilise le même code que <img> pour l’affichage de l’image et des intitulés ; pour l’instant ce n’est ni le même code ni la même logique de fonctionnement, ce qui pose différentes difficultés :
– les images de <ligne> s’affichent en background, ce qui fait qu’elles ne sont généralement pas imprimées et/ou difficiles à sauvegarder dans un PDF ; et autres petites difficultés d’utilisation quand les images sont des background…
– le fait d’avoir deux codes à maintenir, c’est un peu chiant (c’est pas dramatique, parce que j’utilise énormément ce plugin, mais c’est chiant)…
– j’aimerais bien avoir les mêmes fonctionnalités (notamment le zoom kenburns dans l’image) y compris sur les images en ligne…
Du coup, utiliser carrément le même modèle avec <imgXX|ligne>, ça semble une bonne piste (surtout que ligne remplace exactement center, left et right dans leur logique de positionnement).
Difficulté : je pense que certaines fonctionnalités n’ont rien à faire dans ligne (notamment forcer la largeur), et donc ça va commencer à faire du code un peu complexe.
En revanche, je ne pense pas intéressant de fusionner la déclaration de plusieurs images dans le même modèle :
– d’abord parce que c’est chiant à manipuler (quand on fait des articles, on déplace beaucoup les images, surtout qu’avec ligne ça demande des réglages parce que certaines associations fonctionnent moins bien que d’autres), et du coup le copier-coller d’une ligne pour une image, c’est plus pratique que d’aller éditer le modèle avec plusieurs images,
– parce que je voudrais pouvoir passer des fonctionnalités différenciées sur chaque image (comme l’effet de zoom).
J’oubliais une option :
14. Ça prend en compte l’option large :
<imgXX|center|large>.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.
Et donc, il y a aussi une discussion en cours sur la liste « spip-dev » (du noyau) sur ce sujet. Qui parle aussi du modèle <media> qui visait à proposer un modèle unifié aussi.
Ainsi qu’un ticket de discussion autour l’intégration de Medoc (+ de ce plugin aussi maintenant) :
▻https://core.spip.net/issues/3449
Hello, :-)
Je viens de faire un test de ton plug pour voir, j’ai un bug avec un SPIP 3.1.4-dev [23345] (php5.6.25), j’ai deux images dans la médiathèque que j’ajoute à un article, je mets donc <img2|left> <img1|left> avec du texte avant chaque image, si je clique sur l’onglet « voir » du porte plume, les images apparaissent et disparaissent d’un coup, quand à l’onglet « plein écran » du porte plume, je ne vois même pas les images, à savoir qu’il n’y a que ton plug et « image_responsive » dans les plugs. A savoir, il faut que je fasse plus de test, mais la première fois, comme il s’agissait d’un spip tout neuf, j’ai activé ton plug avant d’aller dans /ecrire/ ?exec=configurer_avancees et que le résultat, c’est que cette page plante (page blanche) avec juste le logo « infini » et l’url qui s’écrit /ecrire/ ?exec=configurer_avancees&action=tester_taille&i=1&arg=6000-6000 j’ai aussi pas mal de notice dans l’article, mais ça c’est pas grave, cela vient sans doute que dans mes_options, je demande à les voirs
@francky Avec le plugin image_responsive, si ton site tourne avec des URL « propres », il faut absolument modifier ton fichier .htaccess pour que les images fonctionnent. C’est peut-être ça.
Je pense avoir compris le problème, par contre, je ne sais si c’est un bug de spip ou du plug :-(
Pour info, pour voir le problème, il est important qu’après l’installation d’un spip neuf, de ne pas faire le choix d’un type d’url dans /ecrire/ ?exec=configurer_urls , donc le laissé comme il est nativement, puis d’aller dans ecrire/ ?exec=depots pour faire l’ajout du dépôt de la zone, enfin, installer le plugin « medias_responsive_mod » en manuel dans le dossier « plugin » et laissé spip installer la dépendance « Filtre image_responsive », télécharger un jpeg dans la médiathèque, activer le plugin « medias_responsive_mod » et faire un article.
Avec ou sans htaccess, il y n’y a pas de changement de mon côté
Salut @arno
un souci rencontré avec image_responsive (je n’ai pas trouvé le seen dédié, donc je me permet de poster ici) :
Sur un SPIP 3.0.3 avec uniquement ce plugin installé, j’ai cette erreur dans la console de Firefox :
Et quand je regarde ce fichier dans local/cache-js, j’ai (ça donne un a circonflexe majuscule dans le source Firefox)Si je désactive la compression js dans l’espace privé, plus de problème.
La ligne en question se trouve dans ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L311
En regardant de plus près, il semble y avoir également un souci là ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L388 (carré de couleur rouge matérialisant une erreur ?)
(Le fil sur spip_zone : ▻https://www.mail-archive.com/spip-zone@rezo.net/msg43360.html )
@jeanmarie et @arno je viens de corriger le problème, cf :
▻https://zone.spip.org/trac/spip-zone/changeset/103856
@arno avait introduit des caractères chelous (qui semblent être des espaces insécables) au lieu de simples espaces avec la modification suivante :
▻https://zone.spip.org/trac/spip-zone/changeset/89816
wala wala...
Salut,
Sur le point n°5 :
Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions.
Ligne 37 du modèle img.html, il y a un test sur la taille pour utilise soit un <span>, soit un <a> mais, dans les 2 cas, il y a un href="#FICHIER" ce qui, dans le cas du span, crée une erreur de validation.
Idem pour le type="#MIME_TYPE" (et pour les class et data-photo ?)
cf : ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/medias_responsive_mod/squelettes/modeles/img.html#L37
Il ne faudrait pas tester si on a un lien ou un span avant de les insérer ?
Du coup, ça pourrait donner un truc comme ça :
<[(#GET{a})][(#GET{a}|=={a}|oui) href="#FICHIER"[ title="(#TITRE|supprimer_numero|texte_backend)"] class="fond mediabox" type="#MIME_TYPE" data-photo-w="#LARGEUR" data-photo-h="#HAUTEUR"] >
Après, arrivé là, autant tester les largeur/hauteur et insérer le <a> avec tous les paramètres ou juste le <span>, non ?
Je viens d’uploader un nouveau #plugin pour #SPIP : « Métadonnées Opengraph, Twitter et Facebook » :
▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/metas_opengraph
Ça s’intègre dans le squelette article.html avec :
<INCLURE{fond=metas_opengraph}{id_article}>Ça permet de fabriquer les « cartes » de prévisualisation dans Facebook et Twitter notamment :
Les particularités :
– ça ajoute deux champs aux auteurs, qui permettent de renseigner leur compte Twitter et leur compte Facebook, pour qu’ils apparaissent dans les « cartes » de ces réseaux ;
– noter que pour Facebook, le méta article:author apparaît en double : le nom en clair et l’URL du compte Facebook ; c’est la solution que j’ai trouvée pour que ça fonctionne dans Facebook et dans d’autres réseaux qui exploitent OpenGraph mais, évidemment, pas les comptes Facebook (je crois que j’ai essayé avec Pinterest) ;
– ça découpe « intelligemment » le logo de l’article pour que ça apparaisse de manière optimale dans les cartes de ces réseaux ; il faut les plugins image_responsive et centre_image, pour pouvoir recadrer en indiquant le « centre d’intérêt » du logo (ça évite de recadrer l’image n’importe comment).
yop, super merci, par contre récemment ya eu ça déjà, qui fait (pour le but, pas pour l’implémentation) exactement la même chose :
►https://contrib.spip.net/Metas-4845
On va essayer de voir si ya pas des choses à fusionner…
Après je vois bien que dans celui là ça utilise des trucs précis, des champs ajoutés, etc.
Sinon pour le recadrage avec focus : quand ce n’est que pour avoir une image unique, il n’y a plus besoin d’avoir le plugin « image_responsive » à priori, puisque grâce à @marcimat le « image_recadre » fourni par la dist sait déjà le faire, y compris avec « focus », et donc compatible avec « centre_image » : |image_recadre{458:228, -, focus}
Waow, c’est génial, ça, le coup du image_recadre qui fait focus. C’est depuis quelle version ?
Sinon, je me suis tâté pour ajouter des valeurs globales (à régler dans les préférences du site) de façon à pouvoir ajouter des valeurs globales du site (pas seulement des auteurs) :
– fb:admins
– fb:app_id
– twitter:site
Mais en fait je ne suis pas certain que ce soit réellement utile (les « cartes » semblent très bien fonctionner sans, et je ne sais pas bien à quoi ça servirait de les ajouter).
@arno ça a été ajouté il y a un peu plus d’un an par @marcimat ici :
▻https://zone.spip.org/trac/spip-zone/changeset/93466
qui l’a signalé ensuite sur ton fil de seenthis :)
▻https://seenthis.net/messages/362099#message438162
Du coup je l’utilise tout le temps, depuis un an, avec Centre image toujours. :)
Sinon pour les informations, que ce soit pour le site ET pour les utilisateurs, j’ai plutôt tendance à penser que ça n’a rien à voir avec un plugin qui sert juste à ajouter des metas. Car c’est une info qui peut sert à bien d’autres choses (pour le site, afficher ces infos dans le site public, pour les utilisateurs, faire des liens ou je ne sais quoi).
Pour le site, il y a déjà le plugin « Liens sociaux » qui fait ça :
►https://contrib.spip.net/Liens-sociaux
Pour chaque utilisateur, d’après moi c’est plutôt à chaque plugin de réseau (le plugin Twitter, le plugin Facebook…) de permettre ces infos pour les utilisateurs, et donc suivant ce que le site va vraiment utiliser.
Ensuite, le plugin qui ajoute les metas, peut parfaitement tester si ces plugins sont présents, et si les champs sont remplis, les utiliser pour ajouter des metas en plus. [(#PLUGIN{truc}|oui) Ajout]
Supprimer les fichiers absents d’une copie de travail #svn :
svn rm $( svn status | sed -e '/^!/!d' -e 's/^!//' )
Variante pour ajouter les fichiers non versionnés :
svn add $( svn status | sed -e '/^?/!d' -e 's/^?//' )
Utilisées ici : ▻https://zone.spip.org/trac/spip-zone/changeset/101345
Source : ▻http://snipplr.com/view/9997/remove-all-missing-files-from-a-svn-working-copy
Avant l’arrivee de l’electricite les ouvriers ecoutaient de la techno au travail
▻http://www.core77.com/posts/58982/How-Did-Factories-Get-Power-to-Their-Machines-Before-Electricity
ce message faisait planter seenthis, je ne sais pas bien encore pour quelle raison :
►https://github.com/seenthis/seenthis_squelettes/issues/174
Si je me souviens bien, ça s’est mis à planter une fois que j’ai essayé d’inclure des images de l’article dans le seen, sous l’embed de la video (souvent je poste juste le lien et j’enrichis le seen dans le 1/4h qui suit). Un souci dans la gestion des embeds type images ? Core77 qui fait planter les logiciels qui scrapent ?
Pas mal de boulot pour faire évoluer Flip-Zone (#SPIP, #HTML5, #responsive…) :
►http://www.flip-zone.com
Le premier but est de faire une page d’accueil avec un immense image, façon « plein écran » (particulièrement spectaculaire sur une grande tablette…) :
Il y a plusieurs aspects techniques intéressants, ici.
(1) D’abord ce n’est pas réellement plein écran, comme j’ai pu le faire sur certains sites : c’est simplement qu’il y a deux proportions d’images. Une version horizontale si l’écran est horizontal, et une version verticale si l’écran est vertical.
Quand j’essaie de réellement « remplir » l’écran lui-même, il y a plusieurs problèmes :
A. Ça me fait des maquettes aux proportions aberrantes, avec ces gens sur PC aux écrans très horizontaux, la barre de menu au dessus, et des saloperies qui font qu’au final, on doit calculer une maquette en 1365x300 pixels…
B. Techniquement, l’image qui s’affiche là-dedans à des dimensions inconnues, et donc je ne peux pas choisir l’image par feuille de style, mais en attendant que Javascript démarre après le rendu du DOM. Donc pas de <picture>, ce qui est très problématique désormais.
Du coup, cette version propose différentes tailles d’images, de résolutions (écran Retina), et de proportions (horizontal, vertical) en fonction sur support, et dont les dimensions sont directement connues avant même l’affichage de la page ; donc accessibles en CSS et media queries, donc nativement avec la balise <picture>. La grande image de Une est donc directement gérée par une seule balise dans un gros <picture>. C’est donc fait avec mon #plugin Image responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
La grosse particularité de cette page, c’est d’avoir un effet de profondeur, avec le mannequin qui se « détache » du fond, avec en dessous le logo Flip-Zone qui apparaît. Certes j’ai bien un PNG dans l’espace privé avec le mannequin détouré, mais ce n’est surtout pas ce que j’affiche sur le site public (avec des images de cette taille, un tel PNG ferait un fichier monstrueux). Ce que j’affiche, c’est exactement le JPEG déjà utilisé « en dessous », mais avec un masque de détourage qui est une image en niveaux de gris (calculée rapidement en PHP à partir de la couche alpha du fichier PNG). Et pour réussir à afficher une image JPEG avec un masque de détourage dans le HTML, je fais un petit montage en SVG. (De fait, au lieu d’utiliser un JPEG de fond plus un gros PNG par dessus, j’utilise le JPEG de fond, je réutilise le même fichier JPEG par dessus, en le détourant avec un JPEG en niveaux de gris de taille réduite.)
Ce qui amène à une autre difficulté : il faut que cette <image> dans le SVG soit elle-même responsive (la même que le <picture> de l’image de fond), ce qui n’est pas possible directement (même avec des CSS, je n’ai pas réussi à contrôler l’image qui s’affiche à cet endroit). Solution : je fais le <image> du SVG avec rien.gif et j’y insère en Javascript le résultat de ce qui s’affiche dans le <picture>. De cette façon c’est la <picture> nativement responsive qui gère le choix du bon fichier. J’ai abordé ça ici :
▻http://seenthis.net/messages/479467
Et la méthode pour aller chercher le currentSrc de l’image responsive :
▻http://seenthis.net/messages/470853
Même topo, en fait, pour l’image du masque de détourage en niveau de gris, c’est récupéré d’un <picture> (que je cache). Astuce ici : l’image du masque est deux fois plus petite que l’image affichée, parce que je n’ai pas besoin d’être ultra-précis à cet endroit.
Et la dernière difficulté avec ce SVG, c’est que je ne peux pas changer dynamiquement ses proportions (fixées par la viewBox). Solution pour l’instant : il y a deux SVG dans la page à cet endroit : une avec les proportions horizontales et une avec les proportions verticales, et leur affichage est contrôlé par média queries. En dehors du « texte » des balises du SVG surnuméraire, ça ne pèse pas plus lourd, puisque de toute façon c’est le même contenu (tiré des <picture> ailleurs dans la page) qui y est inséré dynamiquement), la seule différence étant la viewBox « en dur » des deux SVG…
(2) Auparavant l’aspect responsive des menus supérieurs était géré de deux façons :
– sur un écran pas trop étroit (petite tablette), les derniers éléments à droite (ceux qui « dépassent » de l’écran) étaient placés dans un petit menu déroulant ;
– sur tout petit écran, remplacement par un menu hamburger et une navigation « cachée » dans un slider à gauche de l’écran.
C’est désormais remplacé par un menu horizontal qui dépasse (si nécessaire) de l’écran, et qu’on peut scroller automatiquement horizontalement. On verra bien si c’est efficace.
Ah, un gain notable : comme je n’ai plus de gestion d’un menu « hors page » avec décalage complet de la page « vers la gauche », je n’ai plus besoin de placer toute la partie scrollable de la page dans un élément spécifique (en scroll:auto) alors que le body n’était plus scrollable. Mine de rien, ça provoquait parfois des bugs d’affichage lors du scroll (notamment sur pages longues, notamment sur Safari). Là je reviens à un très traditionnel scroll sur le <body> de la page, et je n’ai plus ces bugs bizarres au scroll.
(3) Dans la précédente version de la page d’accueil, le but était d’avoir une page très courte. Mais ça ne semble plus trop la mode (les magazines font des pages d’accueil à scroll quasi-infini), et surtout parce qu’on veut mettre en avant le fait qu’il y a des articles désormais (en anglais essentiellement), le choix est désormais inverse, avec une page très longue.
En revanche, calculs amusants (dans les boucles SPIP) pour alterner les articles (un article de temps en temps) et les collections de photos (parfois plusieurs par jour). Et essayer de conserver une certaine construction logique pour les photos (par Couture/Prêt à porter/Mariage…, et par saisons…).
Pour le poids, une possibilité était de charger la longue page (sous la grande image) en "ajaxload" (on charge la page avec juste le haut, et dans un deuxième temps on lance le chargement du bas de page). En pratique ça donne des résultats très désagréables, notamment quand on fait « back » vers la page d’accueil (on perd le positionnement dans la longue page). De la même façon, mon plugin d’images responsives permet de les gérer en lazy load, mais ça ne me semble plus utile : ça bloque le preloader et ça fait un effet désagréable quand on revient sur la page déjà en cache.
En pratique, j’ai l’impression que les navigateurs récents se débrouillent très bien tous seuls pour gérer les chargements et la mémoire si on utilise directement la balise <picture>.
Faudra voir à l’usage.
(4) La construction de la liste essaie de grouper les collections de photos de manière logique, notamment par saisons (genre : « Printemps-été Automne-hiver 2016-2017 ») :
Cette partie a un peu les mêmes principes que le haut de page : effet de « transparence » sur une partie détourée d’une image, géré via un morceau de SVG qui évite de balancer un PNG ; et slider horizontal automatique pour le responsive.
Ah, je n’ai pas évoqué comment faire des liens qui s’affichent « en dessous », mais tout de même cliquables (et qui apparaissent au survol ou au clic). Et ça se gère directement en CSS sans Javascript. C’est un vieux truc que j’utilise depuis longtemps : il y a en réalité deux fois le même contenu, parfaitement superposés (par exemple l’ensemble des vignettes, ou le menu de navigation supérieur…). Et la version du dessus est masquée, et n’apparaît qu’au survol (ou au clic). L’« astuce » importante est que l’élément est masqué uniquement en avec opacity:0, et devient visible avec opacity:1 ; si on jour avec display, ça ne fonctionne plus correctement en tactile, puisque le premier clic sera intercepté pour faire le changement d’affichage (alors que le changement d’opacité se fait sans désactiver le touch).
(4) Des petits effets de pseudo 3D :
J’aurais pu systématiser ces effets, mais ça oblige tout de même à recourir à mon « truc » de masque de détourage en SVG, un peu lourd, puisqu’il faut tout de même une seconde image (le masque en niveau de gris) pour chaque. Et puis graphiquement ça aurait un peu tourné au cirque, et j’essayais plutôt d’introduire de la variété dans cette longue liste.
(5) Ça devrait fonctionner presque entièrement sans Javascript et directement au chargement de la page en CSS, y compris les diverses petites animations de survol. Avec les progrès des navigateurs, à l’affichage ultra-fluide, les pré-loaders, etc., c’est devenu très important d’avoir la page entièrement construite dès le premier affichage, sans calculs Javascript. L’effet de « fluidité » est vraiment important. (Tu me diras que ça a toujours été important, mais a. on ne pouvait pas toujours faire autrement, b. les progrès de fluidité d’affichage des navigateurs rendent les pages « pas très fluides » vraiment perceptibles).
(6) Un peu partout (notamment en énorme sur le haut de page), j’ai le logo Flip-Zone qui apparaît et qui change de couleur en fonction de l’environnement. Auparavant je faisais autant de fichiers graphiques (PNG) que nécessaire. Maintenant c’est du SVG directement intégré dans le DOM, et colorisé par feuille de style. C’est une astuce que j’utilise de plus en plus fréquemment (ça permet notamment de changer la couleur d’une icone non seulement en fonction du contexte, mais tout bêtement au survol d’un lien hypertexte).
(7) Sinon, ce n’est pas totalement nouveau, mais les pages des « articles longs » sont pas mal (encore une fois, c’est du SPIP), notamment avec ses images installées sur une même ligne, plus large que la colonne de texte, et positionnées de manière responsive :
►http://www.flip-zone.com/Caftan-silhouettes
Celle-ci est plus marrante, parce que l’effet de « lignes » fonctionne avec un mélange d’images et de vidéos, et l’image finale en fond d’écran (tout en bas de page) :
►http://www.flip-zone.com/Nicolas-Jebran-5957
Important pour les amateurs de #HTML5 : avec les récentes mises à jour iOS 9.3 et OSX 10.11.4, les nouvelles versions de Safari comprennent enfin la balise <picture> qui permet de gérer des images #responsive (c’est-à-dire qu’on ne charge pas la même image selon les dimensions ou l’orientation de l’écran).
C’est important parce que c’est le dernier gros navigateur à adopter cette balise, et c’est d’autant plus important, c’est que si on s’enquiquine à faire des images adaptées à l’affichage sur smartphone, évidement Safari pour iOS est l’un des principaux concernés.
Et pour rappel, pour gérer ça automatiquement dans #SPIP, j’ai mon chouette plugin image responsive :
▻http://seenthis.net/sites/328805
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Nouvelle fonction rigolote dans mon #plugin #SPIP image_responsive 7.0 :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Il y a désormais un filtre image_responsive_svg (qui fonctionne en gros comme image_responsive, avec pour l’instant seulement les variables $img, $tailles, $lazy et $vertical.
Le but est de résoudre mon souci avec l’utilisation des images JPG à l’intérieur d’un <svg> : là les images sont appelées avec :
<image xlink:href><img src> du HTML.Importantes différences cependant avec le filtre image_responsive :
– on ne peut pas définir de mediaqueries pour chaque dimension, parce que je n’ai pas (encore ?) trouvé de méthode pour afficher directement les bons fichiers via des CSS (et encore moins, évidemment, une balaise <picture>) ; c’est le point qui m’embête le plus ;
– on ne peut pas définir des redimensionnement spécifiques pour chaque taille d’image, parce que j’ai l’impression qu’il est difficile changer les proportions d’un SVG.
(Bon, et pis franchement franchement : je crois que je vais la seule personne sur la planète à utiliser cette fonction, alors bon…)
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})]
Modif du filtre #SPIP |image_proportions, pour améliorer le comportement lié aux plugins image_responsive et centre_image (la modif est dans le #plugin image_responsive) :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/centre_image
Dans la version précédente, on pouvait recadrer et zoomer dans une image en fonction du centre d’intérêt de l’image (détectée automatiquement ou corrigée manuellement dans l’espace privé). À l’usage, je me suis rendu compte que du coup, le centre d’intérêt qui est rarement au centre de l’image, se retrouvait au centre de l’image retaillée. Par exemple, si on a un portrait, le centre d’intérêt est entre les yeux ; si on recadre/zoome, on se retrouve avec les yeux au centre de l’image, du vide au-dessus des cheveux et le menton coupé.
Le comportement dorénavant, avec le critère focus, est plus malin : si les yeux du portrait sont par exemple dans le tiers haut de l’image d’origine, avec le recadrage ils seront encore dans le tiers haut de l’image résultante (c’est l’idée, mais c’est pondéré sinon c’est exagéré). L’effet est bien meilleur, et les images plus dynamiques.
Si on veut recadrer avec le comportement précédent, il faut utiliser le critère focus-center.
Voici une boucle pour tester avec les images d’un article :
<BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{id_article}>
[(#FICHIER|image_proportions{1,1,focus,2}|image_reduire{200})]
[(#FICHIER|image_proportions{1,1,focus-center,2}|image_reduire{200})]
</BOUCLE_documents>Et une copie d’écran :
On voit que les portraits avec le nouveau réglage (image de gauche de chaque paire) sont plus dynamiques et plus « naturels » que le recadrage avec le script précédent (image de droite, avec le nouveau critère focus-center).
C’est vraiment du super boulot !
On veut ça dans le plugin dist ! :D
@arno centre_image et image_responsive sont vraiment intéressant pour le traitement des images.
Cependant, j’essaie d’optimiser au mieux les images et souhaitait utiliser le plugin Smush ▻http://www.mediaspip.net/documentation/les-plugins-developpes-pour-mediaspip/article/smush-optimisation-des-images mais sans succès.
Y aurait-il moyen d’appeler les traitements de ce plugin depuis le filtre image_responsive ?
Bonjour
Je viens d’avoir un comportement étrange avec le filtre image_proportions (peut être aussi que je l’utilise mal :
[(#FICHIER|image_proportions{16,9}
|image_responsive{360/480/600/800}
|inserer_attribut{alt,[(#_contenu_article:TITRE|attribut_html|couper{80})]})]
Contexte : utilisation dans un formulaire d’upload, tout se passe bien avec des images avec largeur inférieure à 3600px. De 3700 à 4000, la page article est vide. Au delà de 4000px, page blanche.
J’ai fais beaucoup de tests (largeur/poids) et ce n’est pas une question de poids.
Quand erreur, le fichier error_log : [29-Dec-2015 17:38:22 America/New_York] PHP Fatal error : Allowed memory size of 125829120 bytes exhausted (tried to allocate 30798801 bytes) in /home/gwadloup/public_html/plugins-dist/filtres_images/filtres/images_transforme.php on line 301
Quand j’enlève image_proportions{16,9}, tout fonctionne bien.
J’utilise aussi le plugin géodiversité.
Bonne année
Cécile
J’ai un gros soucis avec #SPIP-3.1 : il ajoute un timestamp aux fichiers, que ce soient les CSS et les Javascript, mais aussi les images passées par les filtres.
C’est certes épatant pour être certain de bien utiliser la dernière version de chaque fichier, mais en revanche, ça me plante complètement l’aspiration des sites en local (parce qu’en local, le fichier monimage.jpg?1436899191, ça ne marche pas du tout).
Est-ce qu’il y a un moyen prévu (genre une variable) pour pouvoir désactiver cet automatisme ?
J’ai l’impression d’avoir plus de timestamps avec le 3.1, par exemple sur des images passées par image_reduire, qui n’en avaient pas en 3.0.
Ce que je veux, c’est aspirer le site en local, pour en avoir une copie totalement statique. Avec les timestamp, ça ne fonctionne pas.
Pour l’instant, ce que je fais, c’est d’avoir un #FILTRE{mini_html} dans tous mes squelettes, qui me sert déjà à faire différentes bidouilles (essentiellement, supprimer les tabulations et les espaces surnuméraires dans le code source), et donc là-dedans j’ajoute la suppression des timestamp un peu à la hache (chaque fois que je trouve (jpg|gif|png)\?[0-9]+[\'\"], je vire le timestamp).
C’est dans image_graver() visiblement et il n’y a pas d’option pour le virer (option à ajouter, problablement). Cela dit il n’y a pas de raison fondamentale que les timestamp fassent foirer ta copie locale. Peut-être le fait qu’ils sont avec un ?xxx et ne finissent donc plus par .jpg — mais ça aussi ça pourrait se changer.
@b_b, oui j’ai vu |supprimer_timestamp, mais ça m’oblige à reprendre tous mes squelettes, alors que l’idée est plus dans le sens de ce que remarque @fil. Ou, plus largement, dans le sens de ce qu’ai fait pour image_responsive :
►http://seenthis.net/messages/374212
Là quand j’ajoute :
define("_SPIP_LIER_RESSOURCES", true);mes_options, le même site se met à me fabriquer des squelettes plus verbeux contenant les liens <link href…> pour permettre l’aspiration du site et des ressources.Là c’est pareil, idéalement on définirait une variable dans mes_options, et hop terminés les vilains timestamps le temps de faire l’aspiration.
@speciale : le but du timestamp est juste d’éviter que, quand tu fais les mises à jour de ton site (soit en div, soit pendant que tu mets en ligne des articles) tu sois gêné par le cache de ton navigateur. Un logo arton1.jpg, remplacé par une nouvelle version, est toujours le logo arton1.jpg ; le timestamp ajoute la date de mise en ligne du fichier, et donc ton navigateur ne réutilisera pas la vieille image. Donc c’est bien dans le src de l’image que ça doit se trouver, pas dans un data-, qui n’invaliderait pas le cache.
@arno puisque tu as un #FILTRE{truc} dans tes squelettes, tu peux y ajouter le filtre supprimer_timestamp non ?
@b_b : oui c’est ce que j’ai fait (expliqué plus haut), mais pas directement supprimer_timestamp, qui prend un URL en entrée, et pas l’ensemble de la page.
Mais à nouveau, ça oblige à modifier ses squelettes si on n’a pas l’habitude comme moi de mettre un #FILTRE{mini_html} absolument partout…
Le problème se pose aussi sur les js et css compactés et agrégés par SPIP qui ont aussi ce timestamp, mais sur lesquels il n’est pas possible de passer le filtre de suppression de ce timestamp.
Sauf erreur de ma part, le nom des fichiers créés dans local/ dépend déjà de la date des fichiers. Le timestamp est alors inutile et contre productif.
Et si le nom du fichier ne dépend pas pas de la date, il suffirait de la rajouter dans le calcul du nom, non ?
Salut @arno*. Il est bien possible que ▻https://zone.spip.org/trac/spip-zone/changeset/104022 t’intéresse comme réponse à ton problème, d’autant plus que ça se greffe sur #FILTRE{mini_html}
Seenthis, j’ai une question (avec application à #SPIP). Est-ce qu’il existe une méthode recommandée pour indiquer, dans le code HTML, les ressources liées à la page, sans pour autant entraîner le navigateur ou le preloadeur à charger des ressources inutiles ?
Le besoin auquel je veux répondre, c’est la possibilité d’aspirer/dupliquer un site Web sans avoir des fichiers qui manquent une fois hors ligne. En effet, j’ai régulièrement des ressources chargées dynamiquement (ne serait-ce que mes images responsive), qui ne sont pas récupérées de manière transparente par une aspiration de la page.
Pour l’instant, je m’en sors « à la main » en ajoutant des :
<link href… rel="a_telecharger">Mais je n’ai pas systématisé ça sur mes sites en production (et notamment pas dans les plugins qui génèrent ces pages), parce que je ne veux pas que Google m’aspire des fichiers que je ne veux pas « fabriquer » ou « utiliser » rien que pour lui (par exemple, les images responsive jamais utilisées, je préfère qu’elles ne soient pas générées pour rien), parce que je ne veux pas que navigateurs les chargent (ni les pré-chargent) alors qu’ils ne vont pas les utiliser…
Et en gros, s’il y a une méthode connue et/ou recommandée, voir à quel point c’est une pratique à documenter/généraliser dans SPIP, pour avoir des sites qu’on peut aspirer/sauvegarder/dupliquer en statique à coup sûr.
Note : si on va par là (et j’aimerais bien que ce soit au moins une option), il y a aussi les problèmes de noms de fichiers. Il faut que certains plugins fonctionnent systématiquement en URL « .html », et pas en interminables variables PHP (par exemple, j’utilise des choses comme {ajaxload=html}), et/ou éviter d’ajouter la date à la fin des fichiers (CSS/logos) parce que ça me pète mon aspiration…
(Le mot-laid du jour, mais pas très journalistique, est : « preloadeur ».)
des références (mais pas de réponse concrète)
▻http://www.w3.org/TR/html5/links.html
▻http://microformats.org/wiki/existing-rel-values
Autre question liée, est-ce que je peux mettre un <link> à l’intérieur d’un <a>, du genre :
<a href="truc.html">Le contenu usuel du lien
<link href="maressource.jpg" rel="resource"
</a>Parce que dans de nombreux cas, la fonction qui fabrique les ressources (et donc les potentiels <link> à ajouter pour les aspirer) ne sait pas si ce qu’elle va produire se trouve à l’intérieur d’une ancre (je pense évidemment aux images responsive, dont le fonctionnement est totalement indifférent au fait d’être à l’intérieur d’un lien hypertexte).
Bon, je me lance avec une mise à jour assez conséquence de mon #plugin #SPIP image_responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
On peut activer un define dans mes_options.php :
define("_SPIP_LIER_RESSOURCES", true);Avec cette option, le plugin ajoute au code HTML généré une ribambelle de liens (qui n’affichent rien) de cette forme :
<link href="truc.jpg" rel="attachment" property="url">De cette façon, quand on aspire la page, on aspire aussi toutes les ressources qui seront nécessaire pour travailler en local.
Avec image_responsive, évidemment, ça ne peut fonctionner que quand on définit une ou plusieurs tailles autorisées (ce qui est de toute façon un bon principe à la base).
Introduction d’un système de précalcul dans mon #plugin #SPIP image_responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
On peut ajouter dans mes_options.php :
define("_IMAGE_RESPONSIVE_CALCULER", true);Dans ce cas, à chaque fois qu’on a utilisé image_responsive en indiquant des tailles prédéterminées, le plugin va fabriquer les images responsive précalculées en /local/cache-responsive. Depuis le début, le plugin ne précalcule pas les images, mais se contente de retourner vers un script /action/image_responsive.php qui fabrique/cache/sert les images à la volée.
Avantage du pré-calcul :
– si utilisé sur tout le site, on pourra décider de désactiver le script action, et ainsi éviter de se faire remplir le cache local par un crawler qui déciderait de demander toutes les tailles (de 1 à 1000 par exemple) de toutes les images du site…
– le gros avantage immédiat c’est de servir des fichiers image directement depuis Apache, et non plus des scripts PHP qui expédient des images ; je pense que ça allège le serveur, et que c’est sans doute plus rapide si on n’est pas derrière Varnish – mais j’ignore absolument dans quelles proportions.
Inconvénients du pré-calcul :
– toutes les tailles autorisées d’image sont immédiatement fabriquées ; une fois que toutes les pages du site sont calculées, on atteint illico la taille max utilisée par les images responsive (sans le pré-calcul, seules les images réellement réclamées par des visiteurs sont fabriquées). Sur un gros site avec beaucoup d’images, cette taille est potentiellement phénoménale…
– les pages du site sont beaucoup plus lourdes à calculer la première fois, puisqu’il faut précalculer toutes les tailles de toutes les images (principe des filtres graphiques). Sur un site très graphique, ça peut être très important.
Je continue avec mon #plugin #SPIP image_responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Dans la variable des proportions d’image, il est désormais possible d’utiliser des valeurs en pourcentage. Par exemple : 71%x0 va recadrer l’image à 71% de sa largeur, en conservant sa hauteur.
|image_responsive{
588/840/1280/1920,
0,
0,
(max-width: 420px)/(min-width:421px) and (max-width: 700px)/(min-width:701px) and (max-width:1280px)/,
71%x0/83%x0/0x0/0x0
}
Grosse améliation de mon #plugin #SPIP image_responsive : il intègre désormais la gestion de la direction artistique, avec prise en compte (si l’on a envie) du centre d’intérêt automatique de l’image (avec le plugin centre_image :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Il y a maintenant une variable supplémentaire (optionnelle), qui doit d’utiliser avec les valeurs de mediaqueries de la variable précédente. Par exemple :
[(#FICHIER|image_responsive{
600/800/1400,
0,
0,
/(min-width:801px) and (max-width:1000px)/(min-width: 1001px),
1x1xfocusx2 / 3x4xtop / 4x2
})]Ici on a donc :
– soit une image de 600 pixels de large, 800 pixels de large ou 1400 pixels de large
– pas de lazyload (0)
– pas d’alignement vertical (0)
– l’image de 800 est utilisée pour les écrans de 801 à 1000 pixels de large, l’image de 1400 pixels pour les écrans de plus de 1001 pixels (OK, c’est pas dément comme choix…)
La nouvelle variable contient 3 valeurs séparées par des / (avec ou sans espaces), qui correspondent aux valeurs de mediaqueries précédentes. Chaque valeur est de ce type :
– largeurxhauteurxalignementxzoom
Les valeurs alignement et zoom sont optionnelles. Ces quatre valeurs correspondent aux variables de la fonction image_proportions :
Du coup :
– 1x1xfocusx2, image retaillée au carré (1x1), avec centrage sur le point d’intérêt (focus), et zoom de valeur 2 ; utilisé par défaut ;
– 3x4xtop, image taillée en quatre tiers verticalement, découpe sur le haut de l’aime, et pas de zoom ; utilisé pour les écrans de 801 à 1000 pixels ;
– 4x2, image deux fois plus large que haute, recadrage au centre par défaut, pas de zoom ; utilisé pour les écrans de plus de 1001 pixels de large.
Par ailleurs, ici on a indiqué 3 valeurs correspondant aux 3 media queries. Mais on peut aussi n’utiliser qu’une seule valeur de recadrage, qui sera alors systématiquement utilisée pour toutes les tailles (et cela fonctionnera aussi, dans cas, même si on n’utilise pas les mediaqueries).
Plusieurs intérêts :
– pouvoir utiliser des formats d’images différents selon les tailles d’affichage, et/ou orientations d’écran,
– affiner ces recadrage en utilisant le centre d’intérêt automatique de l’image,
– pouvoir zoomer dans l’image selon la taille d’affichage, éventuellement en centrant sur le point d’intérêt de l’image.
Évolutions de mon #plugin #SPIP image_responsive
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
– v5.1 : transparent pour l’utilisateur (sauf bug…), lorsqu’on utilise les fonctionnalités avancées qui fabriquent un srcset ou des <picture><source>, ce n’est plus mon javascript perso qui va gérer les remplacements d’images, mais le polyfill picturefill.js, plus puissant. (C’est en préparation à l’automatisation de l’ajout de la « direction artistique », qui demandera à utiliser les <source> au lieu d’un simple remplacement d’image proportionnelle ;
– v5.2 : ça devient carrément marrant : ajout d’une quatrième variable à image_proportions, qui indique un niveau de zoom. Par exemple :
[(#FICHIER|image_proportions{200,200,focus,2})]
Pour tester :
<html>
<body>
<BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{inverse}{extension=jpg}>
<div>
<div style="position: relative; display: inline-block;">
[(#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>
[(#FICHIER|image_proportions{0,0,focus,2}|image_reduire{200})]
[(#FICHIER|image_proportions{200,200,focus,2}|image_reduire{200})]
[(#FICHIER|image_proportions{200,200,center, 2}|image_reduire{200})]
</div>
</BOUCLE_documents>
</body>
</html>
(Il faut donc maintenant que j’intègre tout ça directement dans la fonction |image_responsive. Ensuite il faudra bien qu’on ait une fonction pour corriger les centres d’intérêt des images, parce qu’avec le zoom, les erreurs deviennent bien plus pénibles.)
Tu n’auras plus d’excuse pour ne pas l’utiliser : je viens de pondre une (énorme) documentation pour mon #plugin #SPIP image_responsive :
▻http://www.paris-beyrouth.org/tutoriaux-spip/article/plugin-spip-image-responsive
Plugin que tu trouveras là :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
et dans tous les bons repositories de plugins SPIP :
►http://plugins.spip.net/image_responsive.html
je like, mais c’est pour ma retraite quand j’aurai appris à coder avec @fil et @archiloque d’ici quelques années
Super @arno.
Note : Tu as une coquille sur le lien La Femis : l’url générée est fausse.
Autres coquilles @arno ; c’est en vrac, désolé :
– « il devient très habituelle de simplement » -> habituel
– « 1. Par défaut. Si on n’a définit aucune taille autorisée » > défini
– « 2. Première taille autorisée. Si on a définit une ou plusieurs » > défini
– « utilisées dans vos CSS, sinon vous risques de lancer des » > risquez
Merci pour cette super lecture :)
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&img=IMG/arton5.jpg&taille=50 1x,
index.php?action=image_responsive&img=IMG/arton5.jpg&taille=50&dpr=2 2x
'>
<source media='(max-width:1009px)'
srcset='
index.php?action=image_responsive&img=IMG/arton5.jpg&taille=100 1x,
index.php?action=image_responsive&img=IMG/arton5.jpg&taille=100&dpr=2 2x
'>
<source
srcset='
index.php?action=image_responsive&img=IMG/arton5.jpg&taille=200 1x,
index.php?action=image_responsive&img=IMG/arton5.jpg&taille=200&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='[\"50\",\"100\",\"200\"]' />
</picture>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.)
Yes ! Je viens d’uploader la version 4.6 : maintenant tout cela fonctionne également avec les images définies par leur hauteur.
Je passe progressivement Flip-Zone sur le nouveau système :
▻http://fr.flip-zone.com/fashion/couture-1
Ce qui est amusant, évidemment, c’est de voir le site sous Chrome avec Javascript désactivé. Je me demande jusqu’où je peux essayer d’aller comme ça…
Bonjour
Ton plugin fonctionne très bien, merci. Par contre PageSpeed réclame des tailles aux images (width et height) et je n’ai pas trouvé comment les rajouter...
Il semblerai que ça devienne important d’optimiser aux mieux les versions mobiles ▻http://www.webrankinfo.com/dossiers/google-mobile/compatibilite-mobile-critere-seo#utm_source=wri
Merci
Tu es certaine que PageSpeed réclame encore les dimensions des images ? Parce qu’avec le responsive, ça n’a plus vraiment de sens (si tu regardes les nouvelles balises <picture>, d’ailleurs, il n’y a jamais de dimensions indiquées en dur dans le HTML). Tu n’aurais pas une version déjà un peu ancienne de Pagespeed (il y a de nombreuses choses qui étaient conseillées à une époque, et qui ne le sont plus).
Note qu’avec ce plugin, l’espace des images est tout de même réservé au chargement, même sans indiquer les dimensions, parce que le conteneur (là où va s’installer l’image), lui, est bien aux proportions de l’image (et l’image est positionnée en absolu à l’intérieur). Du coup, sauf erreur il n’y a pas de redraw au chargement, ni d’effet de « sauté » lorsque les images sont chargées – or c’est bien à cela que servaient le fait d’indiquer en clair les dimensions des images.
Merci pour cette réponse.
Je suis d’accord avec toi pour dire que cela n’a plus vraiment de sens. J’utilise le PageSpeed de Google (webmastertools) et comme j’avais des incohérences au niveau des images, j’ai utilisé aussi GTmetrix (tout ça avec FF) et pour être sure, j’ai installé PageSpeed Insights sur Chrome.
Je te mets mes résultats et étrangement, sur le site où je n’ai pas encore utilisé le plugin, il ne note pas d’erreur sur la taille des images ou l’obligation de les redimensionner alors qu’elles sont beaucoup plus grandes (mais elles ont un width et un height).
Site avec plugin
▻http://gtmetrix.com/reports/www.gite-cabane-ali-nais.com/wXuhHBW6 (là, il a bien pris ma dimension de 180 de large)
▻https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.gite-cabane-ali-nais.com%2FVotre-suite&tab= (là, il prend les images en 600 de large)
Site sans plugin
▻http://gtmetrix.com/reports/www.antilles-passion.com/TqU7BbNz
▻https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.antilles-passion.com%2F
D’après tout ça, j’en suis arrivée à la conclusion qu’il vaut mieux mettre des tailles à la balise image même si c’est une aberration et je ne comprends pas non plus pourquoi il ne tient pas compte des data dans ses vérifications...
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.
Évolution de mon #plugin #SPIP image_responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
J’ai ajouté, dans la page « Admin / Vider le cache » un troisième pavé, permettant de gérer plus finement les images générées pour les besoins du responsive.
Exemple sur un site avec des milliers d’images :
L’idée, c’est d’essayer de faire la différence entre les images utilisées souvent (conserver le cache) et les images utilisées moins souvent (qu’on peut donc virer en priorité si on a besoin). Par approximation, je me base sur l’âge de dernier accès au fichier (fileatime() de PHP).
C’est spécifique à un dossier où tu mets tes trucs responsives, ou bien ça pourrait être ajouté génériquement pour tous les caches d’images (donc pas dans ton plugin mais dans le core, à priori) ?
Cette version est spécifique au dossier des fichiers de ce plugin précis. Mais je pense qu’on pourrait faire un plugin générique qui détaille tous les dossiers de /local pour pouvoir y sucrer précisément ce qu’on veut.
Une spécificité ici : je n’ai pas besoin d’effacer le cache HTML derrière, parce que les images sont générées « à la demande » dans ce plugin. Pour les autres dossiers, il faut prévoir en revanche d’effacer tout le cache HTML en même temps qu’on supprime des fichiers.
#idée_pour_SPIP au passage, donc :)
Évolution de mon #plugin #SPIP image_responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Nouvelle fonction : background_responsive() (mêmes variables que image_responsive(), sauf l’option « vertical »). À installer par exemple dans un div, pour fabriquer une image de background, en mode « cover », chargée de manière responsive évidemment.
<div class="interieur"[(#IMG_FOND|background_responsive{320/600/1280/1920, 1})]>Bien noter que ça ne fabrique pas, pour le coup, une <img>, mais un style="background" (et tout le tralala pour que ça tourne en responsive et en lazyload). Il faut donc l’intégrer à l’intérieur d’une balise (ici un div) pour que ça fonctionne. C’est d’ailleurs pour cela que ce n’est pas une fonction image_…, puisque ça ne donne pas un fichier image en sortie.
Je croyais ne pas avoir trop besoin de gérer les images en background en responsive, puisque je m’en sors très bien d’habitude en utilisant une véritable image (responsive, donc) et son positionnement (voir mon petit remplir_image) :
►http://seenthis.net/messages/264068
Mais on a obligatoirement besoin de background si on veut pouvoir passer des images en position:fixed réellement par rapport au viewport, pour les effets de parallax (tenter de faire la même chose avec des décalages verticaux lors du scroll, ça donne des animations qui sautent et qui collent mal à la tête).
Sinon, par la suite, il faudrait uniformiser l’insertion de data-lazy et data-responsive dans le code de image_responsive (ici je ne peux pas ajouter de classe, parce que je suis déjà dans un div que je ne fabrique pas, contrairement au img).
Nouvel ajout : dans background-responsive, j’utilise deux images – une horizontale et une verticale (l’une étant calculée automatiquement à partir de l’autre) – que je stocke dans data-portrait-src et data-italien-src. De cette façon, au moment du choix de l’image en javascript, selon la taille d’affichage du conteneur (idéalement, ici, l’écran), ça va donc utiliser l’image qui a le moins de pertes.
L’idée, c’est que si je prends une image horizontale, et que j’affichage ça pour « remplir » un écran vertical, j’étais obligé d’expédier une image faisant quasiment deux fois la taille de l’écran, avec la droite et la gauche de l’image en dehors de l’écran. Là, je limite beaucoup le problème. (Je pense que ça devient d’autant pertinent qu’on utilise ici de grandes images, potentiellement en double définition.)
Et aussi : ajout d’un comportement HTC pour un polyfill de background-size: cover sous IE8.