[SPIP Zone] [Cédric] Adaptive images + <picture>/source + déclaration explicite de quelle image suivant la taille

Archives Zone
#1

Deux choses différentes (= qui peuvent être traitées séparément) dans cet email.

1) Il y a exactement 2 ans, tu expliquais la différence entre ton approche et celle du plugin d'Arno, en décrivant deux grandes voies (JS ou markup avec le moins de JS possible), et en disant que ton plugin utilisait en priorité le HTML :
http://article.gmane.org/gmane.comp.web.spip.zone/35142
Mais depuis, la balise <picture> existe, et elle est désormais reconnu par la majorité des navigateurs. Et le plugin d'Arno, il me semble, l'utilise désormais en priorité, et seulement ensuite le JS. Du coup la distinction que tu indiquais n'est plus autant valable, de ce que je comprends.

Donc la première question est : prévois-tu d'utiliser <picture> en priorité, et ta méthode de markup perso/CSS en fallback sinon ?

2) Dans le plugin d'Arno, il y a une fonctionnalité supplémentaire très pratique : tu peux lister optionnellement des proportions différentes par breakpoint, *lors de l'appel* du filtre. Avec adaptive_image, ça retaille automatiquement par défaut, et ça ajoute aussi un champ pour petite taille dans les documents SPIP si on veut. Mais le plus intéressant, c'est de pouvoir dire quelle image lors du filtre, car ce n'est pas forcément pour utiliser une autre image : ça peut être pour utiliser la même image *dans une autre proportion* suivant les écrans. Là dans celui d'Arno on ne peut pas définir une autre image, juste d'autres proportions de la même image. Mais le mieux serait de pouvoir lister carrément des images précises (donc on peut faire ce qu'on veut soit une autre, soit la même avec une autre cadrage), en plus de celle par défaut.

Donc la deuxième question/proposition est que ce serait pas mal d'avoir par défaut le même super comportement que maintenant (ça retaille tout par défaut, ce qui est mieux que dans le plugin d'Arno qui oblige toujours à appeler le filtre explicitement) MAIS que si on appelle le filtre, on puisse *soi-même* lister les images à utiliser suivant les breakpoints, optionnellement (et quand on le fait pas ça fait juste une retaille classique). Évidemment ça ne marcherait que quand on l'applique sur une image, pas sur un #TEXTE.

Ça pourrait être :

[(#URL_DOCUMENT|image_recadre{16:9}|adaptive_images{
     160/320/480/640/1024,
     #ARRAY{
         160, [(#URL_DOCUMENT_OU_AUTRE|image_recadre{5:4})],
  640, [(#URL_DOCUMENT_OU_AUTRE|image_recadre{1:1})],
     }
})]

- L'image principale serait pour le 1x, donc le dernier élément (ici 1024).
- Si on définit une autre image pour une taille (160), ça utilise cette image.
- Et ça pourrait même être *à partir de cette taille* (pour ne pas avoir à la définir pour chaque taille), ça c'est une idée à discuter…

--
RastaPopoulos

#2

Le 29/02/2016 17:46, RastaPopoulos a écrit :

Mais depuis, la balise <picture> existe, et elle est désormais reconnu
par la majorité des navigateurs. Et le plugin d'Arno, il me semble,
l'utilise désormais en priorité, et seulement ensuite le JS. Du coup la
distinction que tu indiquais n'est plus autant valable, de ce que je
comprends.

Et voilà, la dernière mise à jour iOS et OSX prend en compte cette balise, donc à priori il n'y a quasiment plus de blocage à l'utiliser en priorité (et une autre méthode en fallback).

http://seenthis.net/messages/473240

--
RastaPopoulos

#3

> Le 29/02/2016 17:46, RastaPopoulos a écrit :

Mais depuis, la balise <picture> existe, et elle est désormais reconnu
par la majorité des navigateurs.

Hmmmmm...oui, la majorité, mais quand même :
http://caniuse.com/#search=picture

En résumé
---------
Pour Safari, c'est vraiment la toute dernière version qui est supportée, la 9.1, sorti en janv. 2016

Pour IE, c'est pas du tout supporté. Il reste encore aujourd'hui environ 13% d'internautes sur IE8 + EI9 + IE11
voir http://gs.statcounter.com/#desktop-browser_version-ww-monthly-201603-201603-bar

Bref, c'est encore un peu tôt me semble t-il

#4

Le 30/03/2016 23:44, Peetdu a écrit :

Bref, c'est encore un peu tôt me semble t-il

Je ne fais que répéter :

à l'utiliser *en priorité* (et une autre méthode en fallback)

Ça me parait assez clair. :slight_smile:

Donc non ça ne me parait pas un peu tôt, l'immense majorité des navs le reconnaissent. La minorité qui ne le reconnait pas aurait le fallback. Dans l'idée.

--
RastaPopoulos

#5

Hello,

1) je pencherai plutot pour utiliser les attributs srcset et size sur une balise img
https://responsiveimages.org/
car cela présente l'avantage de rester une simple balise img, on ne change donc pas le DOM selon que l'image est adaptive ou non, et les selecteurs CSS non plus.

Il faut que j'explore cependant la mise en oeuvre : je pense que le filtre se contenterai de remplacer les attribut src et srcset pour gerer l'url de l'image en fonction de la taille de l'image et de la résolution de l'écran.
L'attribut sizes serait laissé à renseigner par le squelette si besoin Il permet par exemple d'indiquer qu'en 1200px une image occupe 1/3 de la largeur, alors qu'en 780px et moins elle occupe 100%, ce qui donne une gestion des adapative image par le navigateur encore plus précise.

Il faut encore que je vois comment je peux gérer l'aspect qualité de connexion.

2) Pourquoi pas, c'est une évolution possible, mais il faut bien y reflechir car le filtre doit se dépatouiller pour mixer les questions des breakpoints et des densités d'écran. Cela peut marcher si les images fournies en argument ne sont que des recadrage, mais laissées en pleine résolution, à charge pour le filtre de faire les redimensionnements adequat.

--
Cédric

RastaPopoulos a écrit :

Deux choses différentes (= qui peuvent être traitées séparément) dans
cet email.

1) Il y a exactement 2 ans, tu expliquais la différence entre ton
approche et celle du plugin d'Arno, en décrivant deux grandes voies (JS
ou markup avec le moins de JS possible), et en disant que ton plugin
utilisait en priorité le HTML :
http://article.gmane.org/gmane.comp.web.spip.zone/35142
Mais depuis, la balise <picture> existe, et elle est désormais reconnu
par la majorité des navigateurs. Et le plugin d'Arno, il me semble,
l'utilise désormais en priorité, et seulement ensuite le JS. Du coup la
distinction que tu indiquais n'est plus autant valable, de ce que je
comprends.

Donc la première question est : prévois-tu d'utiliser <picture> en
priorité, et ta méthode de markup perso/CSS en fallback sinon ?

2) Dans le plugin d'Arno, il y a une fonctionnalité supplémentaire très
pratique : tu peux lister optionnellement des proportions différentes
par breakpoint, *lors de l'appel* du filtre. Avec adaptive_image, ça
retaille automatiquement par défaut, et ça ajoute aussi un champ pour
petite taille dans les documents SPIP si on veut. Mais le plus
intéressant, c'est de pouvoir dire quelle image lors du filtre, car ce
n'est pas forcément pour utiliser une autre image : ça peut être pour
utiliser la même image *dans une autre proportion* suivant les écrans.
Là dans celui d'Arno on ne peut pas définir une autre image, juste
d'autres proportions de la même image. Mais le mieux serait de pouvoir
lister carrément des images précises (donc on peut faire ce qu'on veut
soit une autre, soit la même avec une autre cadrage), en plus de celle
par défaut.

Donc la deuxième question/proposition est que ce serait pas mal d'avoir
par défaut le même super comportement que maintenant (ça retaille tout
par défaut, ce qui est mieux que dans le plugin d'Arno qui oblige
toujours à appeler le filtre explicitement) MAIS que si on appelle le
filtre, on puisse *soi-même* lister les images à utiliser suivant les
breakpoints, optionnellement (et quand on le fait pas ça fait juste une
retaille classique). Évidemment ça ne marcherait que quand on l'applique
sur une image, pas sur un #TEXTE.

Ça pourrait être :

[(#URL_DOCUMENT|image_recadre{16:9}|adaptive_images{
160/320/480/640/1024,
#ARRAY{
160, [(#URL_DOCUMENT_OU_AUTRE|image_recadre{5:4})],
640, [(#URL_DOCUMENT_OU_AUTRE|image_recadre{1:1})],
}
})]

- L'image principale serait pour le 1x, donc le dernier élément (ici 1024).
- Si on définit une autre image pour une taille (160), ça utilise cette
image.
- Et ça pourrait même être *à partir de cette taille* (pour ne pas avoir
à la définir pour chaque taille), ça c'est une idée à discuter…

#6

Le 29/02/2016 à 17:46, RastaPopoulos a écrit :

Donc la première question est : prévois-tu d'utiliser <picture> en
priorité, et ta méthode de markup perso/CSS en fallback sinon ?

Hello, dans cette email de 2016, je faisais référence à une explication
de 2014, le plugin datant lui de 2013.

Nous sommes maintenant trois ans plus tard encore, et la prise en compte
de tous les attributs et balises standards a encore évidemment augmenté
dans tous les navs.

Adaptive Images sert énormément (je l'utilise sur 100% des sites), et
son approche était à coup sûr la meilleure… il y a 6 ans. :frowning:

Cette ancienne approche utilisée actuellement dans Adaptive fait péter
de plus en plus souvent diverses lib JS ou autre positionnement CSS, vu
qu'il y a une couche de fausse image qui se change en vraie image, et
parfois un peu de JS aussi (avec Slick par ex mais ça nous est arrivé
avec d'autres aussi). Je suppose qu'avec des balises standards ça
réduirait les risques.

Je ne suis pas capable de répondre à cette question tout seul alors :
aussi bien en terme de prise en charge par le plus de monde possible +
évidemment de web performance, est-ce que ce n'est pas désormais
totalement bon ou quasiment avec <picture et img srcset, etc ?

Le plugin ne devrait-il pas générer désormais uniquement du standard, et
ajouter un mini JS polyfill/correction pour les cas où ça ne marche pas ?

Évidemment ça casserait complètement le HTML, donc nouvelle branche
majeure (ou autre plugin carrément ?).

Ou bien faut-il utiliser celui d'Arno* qui serait plus à jour ? Mais ça
ne fait pas tout pareil : Adaptive images rend responsive aussi
n'importe quelle image du site automatiquement, et ça c'est foufou.

Ou bien faut arrêter de maintenir l'un des deux, et reporter les
fonctionnalités manquantes dans l'autre, et n'avoir qu'un plugin
d'images responsive/adaptives, maintenant que l'ancienne approche
technique n'a plus de raison d'être avec les standards et navs actuels ?

Questions sincères, n'y connaissant pas grand chose dans ce domaine. :slight_smile:

--
RastaPopoulos

#7

Hello,

Je réponds en résumé : oui le markup est maintenant old et il fait refaire en img+srcset (surtout pas en picture)

Mais a contrario le markup actuel est aussi super interessant pour faire du background(), je pense donc a une option de compat pour ressortir l’ancien markup ou le nouveau, a la demande ou par défaut.

Et les quelques fois ou il fait peter le contenu, ça se règle généralement d’une ou deux lignes de css, donc c’est pas non plus un drame.

image_responsive poursuit un but différent et a des contraintes différentes, donc ça parait difficile de merger.

En particulier une des contraintes d’AdaptiveImage est de ne pas reposer sur du JS.
J’aime beaucoup aussi l’effet progressive loading obtenu par la miniature basse def embed dans la page.

Tout ça fait que je ressens pas non plus un besoin absolu de changer impérativement très vite maintenant tout de suite…

Donc oui, je vais rafraichir un jour ce plugin, il y a 2 ans déjà, le mois prochain, ou dans 5 ans… mais proprement, en prenant le temps de bien faire et tester

--
Cédric

Le 25 juin 2019 à 15:05 +0200, RastaPopoulos <rastapopoulos@spip.org>, a écrit :

Le 29/02/2016 à 17:46, RastaPopoulos a écrit :
> Donc la première question est : prévois-tu d'utiliser <picture> en
> priorité, et ta méthode de markup perso/CSS en fallback sinon ?

Hello, dans cette email de 2016, je faisais référence à une explication
de 2014, le plugin datant lui de 2013.

Nous sommes maintenant trois ans plus tard encore, et la prise en compte
de tous les attributs et balises standards a encore évidemment augmenté
dans tous les navs.

Adaptive Images sert énormément (je l'utilise sur 100% des sites), et
son approche était à coup sûr la meilleure… il y a 6 ans. :frowning:

Cette ancienne approche utilisée actuellement dans Adaptive fait péter
de plus en plus souvent diverses lib JS ou autre positionnement CSS, vu
qu'il y a une couche de fausse image qui se change en vraie image, et
parfois un peu de JS aussi (avec Slick par ex mais ça nous est arrivé
avec d'autres aussi). Je suppose qu'avec des balises standards ça
réduirait les risques.

Je ne suis pas capable de répondre à cette question tout seul alors :
aussi bien en terme de prise en charge par le plus de monde possible +
évidemment de web performance, est-ce que ce n'est pas désormais
totalement bon ou quasiment avec <picture et img srcset, etc ?

Le plugin ne devrait-il pas générer désormais uniquement du standard, et
ajouter un mini JS polyfill/correction pour les cas où ça ne marche pas ?

Évidemment ça casserait complètement le HTML, donc nouvelle branche
majeure (ou autre plugin carrément ?).

Ou bien faut-il utiliser celui d'Arno* qui serait plus à jour ? Mais ça
ne fait pas tout pareil : Adaptive images rend responsive aussi
n'importe quelle image du site automatiquement, et ça c'est foufou.

Ou bien faut arrêter de maintenir l'un des deux, et reporter les
fonctionnalités manquantes dans l'autre, et n'avoir qu'un plugin
d'images responsive/adaptives, maintenant que l'ancienne approche
technique n'a plus de raison d'être avec les standards et navs actuels ?

Questions sincères, n'y connaissant pas grand chose dans ce domaine. :slight_smile:

--
RastaPopoulos

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#8

Quelques précisionsà propos de image_responsive:

- la modification des insertions <img>, ce n’est pas géré par le plugin image_responsive, mais par «medias_responsive_mod»:
https://23forward.com/Plugin-SPIP-Insertion-avancee-d-images
C’est celui-là qui gère les modèles et ajoute les <figure> et <figcaption>.

Ce qui serait marrant, d’ailleurs, ce serait qu’il fonctionne de manière transparente avec image_responsive ou avec adaptative_image, en fonction du plugin qu’on aurait installé (mais alors, pour gérer les dépendances au niveau de paquet.xml…).

- image_responsive ne repose plus sur Javascript. Utilisé de manière poussée, il fonctionne intégralement avec les variantes media, <picture> et les srcset. Par exemple, sur un site récent comme celui-ci, on peut naviguer dans tout le site avec l’intégralité de l’interface graphique, les variantes de recadrage et le support des écrans haute densité («Retina»), avec Javascript totalement désactivé:
https://ihedate.org
Et avec, c’est l’aspect le plus intéressant, le preloading des images intégré aux navigateurs, puisque tout est en HTML5 standard de ce côté.
Et une particularité du plugin, du coup, c’est de proposer des recadrage différents (avec le plugin centre_image) en fonction des tailles et orientations d’écran. C’est un peu compliqué, mais c’est très intéressant à faire (et intégralement en HTML).

- et du coup, pour ceux que ça intéresse, ces grandes images qui structurent les «fonds» de page, c’est géré directement (et donc sans Javascript) par un autre plugin, «Fonds»:
https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/fonds

- à partir du moment où l’on utilise medias_responsive_mod, les insertions <img> existantes dans les articles adoptent le nouveau comportement, et assez curieusement généralement sans péter les articles existants (ça me surprends, en fait).

- la limite sur l’absence de Javascript, justement chez moi ce sont les insertions <img>, que je ne fais pas en statique, parce que je considère que je ne connais pas la dimension de la colonne de texte, surtout que media_responsive_mod facilite l’insertion de plusieurs images sur une même ligne de texte (raccourci <ligne> notamment). Mais vu ce que fait Adaptative Image, ça pourrait se faire plus automatiquement.

Sinon, pour des détails:
- j’ai désactivé par défaut la différence de compression sur écran Retina: ces écrans sont d’une telle qualité désormais que la plus grande compression se voit vraiment trop. Du coup, ça permet si on choisit correctement les tailles, d’utiliser le même fichier pour le 640pixels et le 320 pixels en 2x;
- pour éviter de fabriquer trop d’images (surtout qu’avec Fond, on travaille sur des tailles d’images assez immenses, en «plein écran»), je limite les srcset à 1x et 2x. Pas de taille intermédiaire telle que 1,5x et pas de 3x (à surveiller, d’ailleurs, je n’ai pas d’iPhone X sous la main pour voir si ça se voit).

Arnaud

#9

En parlant d'images dégradées, avez-vous vu (sans JS) le site

https://fr.rbth.com

par exemple

https://fr.rbth.com/histoire/83064-diatlov-ingenieur-chef-adjoint-tchernobyl

je trouve ça carrément beau comme rendu ! Une idée de quelle compression
est utilisée ?

touti

#10

Ah dis donc merci Touti de nous pointer ça c’est super intéressant !

En cherchant un peu j’ai donc trouvé un article qui présente la technique

https://jmperezperez.com/svg-placeholders/

et qui pointe vers la lib utilisée pour générer les images placeholder vectorielles en SVG à partir d’une image
https://github.com/fogleman/primitive

(en GO malheureusement)
et une application Native Mac
https://primitive.lol/

Ça donne envie d’en faire quelque chose ! :slight_smile:

--
Cédric
Le 25 juin 2019 à 17:53 +0200, toutati <toutati@free.fr>, a écrit :

En parlant d'images dégradées, avez-vous vu (sans JS) le site

https://fr.rbth.com

par exemple

https://fr.rbth.com/histoire/83064-diatlov-ingenieur-chef-adjoint-tchernobyl

je trouve ça carrément beau comme rendu ! Une idée de quelle compression
est utilisée ?

touti

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#11

Yep, remarqué à l'époque ici par 0gust1 :
https://seenthis.net/messages/645575

J'avais mis en lien la lib Potracio en PHP :
https://github.com/Otamay/potracio

Utilisé par le CMS PHP Craft :
https://github.com/nystudio107/craft3-imageoptimize/blob/master/src/lib/Potracio.php

--
RastaPopoulos

#12

Hop,

Le 25/06/2019 à 20:42, Cerdic a écrit :

Ah dis donc merci Touti de nous pointer ça c’est super intéressant !

En cherchant un peu j’ai donc trouvé un article qui présente la technique

https://jmperezperez.com/svg-placeholders/

Toujours sur le sujet des placeholders, arno présentait une solution assez élégante et tout en SPIP par ici :

https://seenthis.net/messages/660728#message661081

Un "simple" dégradé qui a des chances d'être moins lourd qu'une image en svg.

++
b_b

#13

Merci pour Potracio qui a le mérite d’exister en PHP, mais je trouve le résultat beaucoup moins esthétique et efficace que celui de Primitive (qui malheureusement n’a aucun portage en PHP et dont je suspecte que le temps de calcul serait excessif)

--
Cédric
Le 26 juin 2019 à 00:38 +0200, RastaPopoulos <rastapopoulos@spip.org>, a écrit :

Yep, remarqué à l'époque ici par 0gust1 :
https://seenthis.net/messages/645575

J'avais mis en lien la lib Potracio en PHP :
https://github.com/Otamay/potracio

Utilisé par le CMS PHP Craft :
https://github.com/nystudio107/craft3-imageoptimize/blob/master/src/lib/Potracio.php

--
RastaPopoulos

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#14

Ah oui j’avais vu aussi (mais oublié depuis), mais par contre ça fonctionne bien sur certaines images, potentiellement beaucoup moins sur d’autres amha

mais ça pourrait être automatisé indeed, peut-être avec un double gradient horizontal + vertical, en deux couches, pour être un peu plus générique ?

--
Cédric
Le 26 juin 2019 à 08:49 +0200, Bruno Bergot <bruno@eliaz.fr>, a écrit :

Hop,

Le 25/06/2019 à 20:42, Cerdic a écrit :
> Ah dis donc merci Touti de nous pointer ça c’est super intéressant !
>
> En cherchant un peu j’ai donc trouvé un article qui présente la technique
>
> https://jmperezperez.com/svg-placeholders/
>

Toujours sur le sujet des placeholders, arno présentait une solution
assez élégante et tout en SPIP par ici :

https://seenthis.net/messages/660728#message661081

Un "simple" dégradé qui a des chances d'être moins lourd qu'une image en
svg.

++
b_b

#15

Le 26/06/2019 à 09:26, Cerdic a écrit :

Ah oui j’avais vu aussi (mais oublié depuis), mais par contre ça fonctionne bien sur certaines images, potentiellement beaucoup moins sur d’autres amha

mais ça pourrait être automatisé indeed, peut-être avec un double gradient horizontal + vertical, en deux couches, pour être un peu plus générique ?

À l'examen du code css, j'ai eu l'impression que c'est déjà le cas.
Juste que c'est peu visible sur l'exemple (mais un peu quand même).

JLuc

Toujours sur le sujet des placeholders, arno présentait une solution
assez élégante et tout en SPIP par ici :

https://seenthis.net/messages/660728#message661081

Un "simple" dégradé qui a des chances d'être moins lourd qu'une image en
svg.

++
b_b

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#16

Le 25/06/2019 à 17:33, Arnaud Martin a écrit :

Quelques précisionsà propos de image_responsive:

M'étant dans le passé trouvé à la peine pour choisir l'un ou l'autre,
j'ai produit une synthèse comparative à partir des éléments communiqués :
https://contrib.spip.net/images-adaptatives-ou-responsives

Ce que j'en retiens comme grande différence, c'est que adaptative
peut être adapté à un fonctionnement "plug and play"
et sinon faut rentrer dans les détails et c'est plus complexe.

JL

#17

Le 26/06/2019 à 08:49, Bruno Bergot a écrit :

Hop,

Le 25/06/2019 à 20:42, Cerdic a écrit :

Ah dis donc merci Touti de nous pointer ça c’est super intéressant !

En cherchant un peu j’ai donc trouvé un article qui présente la technique

https://jmperezperez.com/svg-placeholders/

Toujours sur le sujet des placeholders, arno présentait une solution assez élégante et tout en SPIP par ici :

https://seenthis.net/messages/660728#message661081

Un "simple" dégradé qui a des chances d'être moins lourd qu'une image en svg.

++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Déjà fait ici

https://contrib.spip.net/Astuces-Lazyloading

Rien n'empèche de générer un svg dynamique et la couleur …

--
Bonne journée
Arnaud B. (Mist. GraphX)

#18

Le 25/06/2019 à 17:53, toutati a écrit :

En parlant d'images dégradées, avez-vous vu (sans JS) le site

https://fr.rbth.com

par exemple

https://fr.rbth.com/histoire/83064-diatlov-ingenieur-chef-adjoint-tchernobyl

je trouve ça carrément beau comme rendu ! Une idée de quelle compression
est utilisée ?

https://jmperezperez.com/svg-placeholders/

C'est expliqué ici

--
Bonne journée
Arnaud B. (Mist. GraphX)

#19

Pour revenir au sujet de départ, cette discussion n’aura pas été vaine puisque je viens d’envoyer 3 modifs sur le plugin :

• un petit fix pour eviter qu’une image soit adaptee 2 fois, ce qui pouvait arriver si on empilait des filtres dans les squelettes (marginal)
• une bonne optimisation de l’image fallback/aperçu/thumbnail en améliorant donc la technique déjà utilisée : l’image est produite dans une taille beaucoup plus petite qu’auparavant (typiquement de l’ordre de 160px), mais avec moins de degradation de la qualité jpg, et un effet filter:blur() en css dessus
Sur mon site de test ces images qui sont embed en base64 dans la page passent de 10-12ko à 2-3Ko, ce qui est beaucoup plus léger
• une modernisation du markup : j’ai pensé qu’en changeant le span par un picture j’avais soudainement un markup tout à fait moderne et non surprenant qui devrait mieux s’intégrer dans les usages de type slider ou autre, et améliorer la transition vers une future évolution de la technique sous-jacente
qui pour le moment ne change pas du tout, mais c’est pas bien gênant du moment que ça marche bien)

https://zone.spip.net/trac/spip-zone/changeset/115787/spip-zone/plugins/adaptive_images/trunk
https://zone.spip.net/trac/spip-zone/changeset/115788/spip-zone/plugins/adaptive_images/trunk

A l’écoute de votre feedback !

--
Cédric
Le 25 juin 2019 à 15:05 +0200, RastaPopoulos <rastapopoulos@spip.org>, a écrit :

Le 29/02/2016 à 17:46, RastaPopoulos a écrit :
> Donc la première question est : prévois-tu d'utiliser <picture> en
> priorité, et ta méthode de markup perso/CSS en fallback sinon ?

Hello, dans cette email de 2016, je faisais référence à une explication
de 2014, le plugin datant lui de 2013.

Nous sommes maintenant trois ans plus tard encore, et la prise en compte
de tous les attributs et balises standards a encore évidemment augmenté
dans tous les navs.

Adaptive Images sert énormément (je l'utilise sur 100% des sites), et
son approche était à coup sûr la meilleure… il y a 6 ans. :frowning:

Cette ancienne approche utilisée actuellement dans Adaptive fait péter
de plus en plus souvent diverses lib JS ou autre positionnement CSS, vu
qu'il y a une couche de fausse image qui se change en vraie image, et
parfois un peu de JS aussi (avec Slick par ex mais ça nous est arrivé
avec d'autres aussi). Je suppose qu'avec des balises standards ça
réduirait les risques.

Je ne suis pas capable de répondre à cette question tout seul alors :
aussi bien en terme de prise en charge par le plus de monde possible +
évidemment de web performance, est-ce que ce n'est pas désormais
totalement bon ou quasiment avec <picture et img srcset, etc ?

Le plugin ne devrait-il pas générer désormais uniquement du standard, et
ajouter un mini JS polyfill/correction pour les cas où ça ne marche pas ?

Évidemment ça casserait complètement le HTML, donc nouvelle branche
majeure (ou autre plugin carrément ?).

Ou bien faut-il utiliser celui d'Arno* qui serait plus à jour ? Mais ça
ne fait pas tout pareil : Adaptive images rend responsive aussi
n'importe quelle image du site automatiquement, et ça c'est foufou.

Ou bien faut arrêter de maintenir l'un des deux, et reporter les
fonctionnalités manquantes dans l'autre, et n'avoir qu'un plugin
d'images responsive/adaptives, maintenant que l'ancienne approche
technique n'a plus de raison d'être avec les standards et navs actuels ?

Questions sincères, n'y connaissant pas grand chose dans ce domaine. :slight_smile:

--
RastaPopoulos

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#20

Le 25/06/2019 à 17:33, Arnaud Martin a écrit :

Quelques précisionsà propos de image_responsive:

Merci pour vos explications à tous les deux, c'est cool !

--
RastaPopoulos