j'avais souvent l'habitude d'utiliser sur mes site image_reduire et image _recadre, afin de ne pas avoir à surveiller les redacteur au niveau de la taille des images et ainsi de s'assurer obtenir toujours un résultat au niveau de la présentation.
Mon souci c'est que je fais désormais la plupart de mes site en responsive et je ne parviens plus à gérer cela de la même façon. J'utilise la pluspart du temps simplement du css avec @media, et un peu de javascript pour redimensionner ou réarranger mes éléments selon la taille du navigateur.
Ma question serait possible en spip de gérer le recadre_image en fonction de @media ou autre.
La solution que je vois pour le moment, c'est de générer 3 ou 4 image, puis avec le css de les rendre visible ou invisible.
Je me demandais si il existerait une solution plus élégante.
Ces 2 plugins sont il un exemple de ce SPIP essaie d'éviter,
si j'en crois les explications données récemment suite au dépot de GAMadeSimple,
c'est à dire de proposer 2 plugins se proposant de faire un peu la même chose ?
Dans un tel cas, à défaut d'unicité, il me semble que la stratégie SPIP
pourrait être de fournir les moyens clairs de s'orienter
parmi les différentes possibilités qui s'offrent.
Pour quelqu'un comme moi qui n'est pas expert en CSS et d'adaptativité,
sur quels critères choisir plutôt l'un ou plutôt l'autre de ces plugins ?
Ces 2 plugins sont il un exemple de ce SPIP essaie d'éviter,
si j'en crois les explications données récemment suite au dépot de
GAMadeSimple,
c'est à dire de proposer 2 plugins se proposant de faire un peu la même
chose ?
c'est deux directions de recherche un peu différentes, mais il y a déjà du
code en commun
Pour quelqu'un comme moi qui n'est pas expert en CSS et d'adaptativité,
sur quels critères choisir plutôt l'un ou plutôt l'autre de ces plugins ?
Ces 2 plugins sont il un exemple de ce SPIP essaie d'éviter,
si j'en crois les explications données récemment suite au dépot de GAMadeSimple,
c'est à dire de proposer 2 plugins se proposant de faire un peu la même chose ?
c'est deux directions de recherche un peu différentes, mais il y a déjà du code en commun
Pour quelqu'un comme moi qui n'est pas expert en CSS et d'adaptativité,
sur quels critères choisir plutôt l'un ou plutôt l'autre de ces plugins ?
tu préfères ton papa ou ta maman ?
Je n'ose croire qu'il n'y ait que des raisons infantiles d'avoir 2 plugins
et non un seul.
Je n'ose croire qu'il n'y ait que des raisons infantiles d'avoir 2 plugins
et non un seul.
En l'espèce c'est un domaine technique naissant dans lequel aucune solution technique n'est idéale ni ne s'impose à ce jour. La bonne approche sera celle qui sera normalisée par le W3C et implémentée dans les navigateurs et disponible pour tout le monde dans 5 ans ou plus le temps que le parc se renouvèle.
En attendant on est conduit à faire du bricolage avec ce que permet HTML/CSS/JS, et de trouver le meilleur compromis possible.
Pour faire (très) court et (très) résumé, il y a 2 grandes approches :
- la famille des solutions basées sur JS, explorée par Arno : dans ce cas le markup initial est peu modifié, la sélection et le choix des images se fait côté navigateur en JS, ce qui permet potentiellement plus de finesse dans l'adaptation des images à la taille réelle affichée ;
- la famille des solutions qui repose sur un markup amélioré, dans la limite de ce que permet HTML, et qui repose le moins possible sur Javascript. C'est la voie que j'ai exploré, dans le but d'avoir une solution qui fonctionne même sans javascript (ou si javascript est cassé à cause d'un bug d'un js chargé).
Il se trouve qu'on a commencé en même temps à peu de choses près et travaillé en parallèle. Probablement que si on avait plus d'affinités on aurait travaillé plus ensemble.
Ça n'empêche pas une certaine forme de synergie : en ce qui me concerne j'ai suivi de près ce que faisait Arno et j'ai repris plusieurs idées ou optimisations astucieuses.
Sachant qu'on était de toute façon, et dès le départ, dans 2 optiques différentes, avoir un seul plugin n'apporterait rien de plus, car ce choix entre l'une ou l'autre méthode reste du ressort de celui qui fait le site in fine, et peut dépendre aussi du projet lui même et des priorités associées.
Bref il n'existe pas de réponse unique à ce jour.
Si tu veux en savoir plus sur les images adaptatives cf
Ça ne résoud pas tout, mais pour "celui fait fait le site in fine",
ça permet de plus facilement matcher a priori un projet
avec l'un ou l'autre de ces plugins
JL
Le 03/02/2014 14:13, Cédric Morin a écrit :
En l'espèce c'est un domaine technique naissant dans lequel aucune solution technique n'est idéale ni ne s'impose à ce
jour. La bonne approche sera celle qui sera normalisée par le W3C et implémentée dans les navigateurs et disponible pour
tout le monde dans 5 ans ou plus le temps que le parc se renouvèle.
En attendant on est conduit à faire du bricolage avec ce que permet HTML/CSS/JS, et de trouver le meilleur compromis
possible.
Pour faire (très) court et (très) résumé, il y a 2 grandes approches :
- la famille des solutions basées sur JS, explorée par Arno : dans ce cas le markup initial est peu modifié, la
sélection et le choix des images se fait côté navigateur en JS, ce qui permet potentiellement plus de finesse dans
l'adaptation des images à la taille réelle affichée ;
- la famille des solutions qui repose sur un markup amélioré, dans la limite de ce que permet HTML, et qui repose le
moins possible sur Javascript. C'est la voie que j'ai exploré, dans le but d'avoir une solution qui fonctionne même sans
javascript (ou si javascript est cassé à cause d'un bug d'un js chargé).
Il se trouve qu'on a commencé en même temps à peu de choses près et travaillé en parallèle. Probablement que si on avait
plus d'affinités on aurait travaillé plus ensemble.
Ça n'empêche pas une certaine forme de synergie : en ce qui me concerne j'ai suivi de près ce que faisait Arno et j'ai
repris plusieurs idées ou optimisations astucieuses.
Sachant qu'on était de toute façon, et dès le départ, dans 2 optiques différentes, avoir un seul plugin n'apporterait
rien de plus, car ce choix entre l'une ou l'autre méthode reste du ressort de celui qui fait le site in fine, et peut
dépendre aussi du projet lui même et des priorités associées.
merci pour ces explications, je me posais les mêmes questions... Sans donner de réponse toute faite, ça permet d'orienter ses choix.
Est-ce qu'il ne serait pas intéressant de les ajouter à la page du plugin?
Je les ai rajouté sur SennThis d'Arno*...
jean marie
Le 03/02/2014 14:13, Cédric Morin a écrit :
JLuc a écrit :
Je n'ose croire qu'il n'y ait que des raisons infantiles d'avoir 2 plugins
et non un seul.
En l'espèce c'est un domaine technique naissant dans lequel aucune solution technique n'est idéale ni ne s'impose à ce jour. La bonne approche sera celle qui sera normalisée par le W3C et implémentée dans les navigateurs et disponible pour tout le monde dans 5 ans ou plus le temps que le parc se renouvèle.
En attendant on est conduit à faire du bricolage avec ce que permet HTML/CSS/JS, et de trouver le meilleur compromis possible.
Pour faire (très) court et (très) résumé, il y a 2 grandes approches :
- la famille des solutions basées sur JS, explorée par Arno : dans ce cas le markup initial est peu modifié, la sélection et le choix des images se fait côté navigateur en JS, ce qui permet potentiellement plus de finesse dans l'adaptation des images à la taille réelle affichée ;
- la famille des solutions qui repose sur un markup amélioré, dans la limite de ce que permet HTML, et qui repose le moins possible sur Javascript. C'est la voie que j'ai exploré, dans le but d'avoir une solution qui fonctionne même sans javascript (ou si javascript est cassé à cause d'un bug d'un js chargé).
Il se trouve qu'on a commencé en même temps à peu de choses près et travaillé en parallèle. Probablement que si on avait plus d'affinités on aurait travaillé plus ensemble.
Ça n'empêche pas une certaine forme de synergie : en ce qui me concerne j'ai suivi de près ce que faisait Arno et j'ai repris plusieurs idées ou optimisations astucieuses.
Sachant qu'on était de toute façon, et dès le départ, dans 2 optiques différentes, avoir un seul plugin n'apporterait rien de plus, car ce choix entre l'une ou l'autre méthode reste du ressort de celui qui fait le site in fine, et peut dépendre aussi du projet lui même et des priorités associées.
Bref il n'existe pas de réponse unique à ce jour.
Ah oups, originellement c'était dans le carnet
mais quand j'ai changé la rubrique pour le mettre dans une rubrique plus appropriée au thème,
pouf il s'est retrouvé dans le pas-wiki.
Hmmm...
Ma foi, même si c'est un peu court, je pense que ça y aurait sa place,
mais quelqu'un d'autre peut valider quand même ?
C’est quand même plus des notes qui ont leur place dans le wiki, quitte à les lier dans la doc du plugin, qu’un article de doc qui se tient et qui est compréhensible amha.
Ah oups, originellement c’était dans le carnet
mais quand j’ai changé la rubrique pour le mettre dans une rubrique
plus appropriée au thème,
pouf il s’est retrouvé dans le pas-wiki.
Hmmm…
Ma foi, même si c’est un peu court, je pense que ça y aurait sa place,
mais quelqu’un d’autre peut valider quand même ?
C'est quand même plus des notes qui ont leur place dans le wiki, quitte à les lier dans la doc du plugin, qu'un article
de doc qui se tient et qui est compréhensible amha.
C'est un article "d'orientation" dans l'univers documenté.
Je le verrai bien genre en petit sticky dans la rubrique...
mais je le rewikirai si ta réticence se confirme.
Ah oups, originellement c'était dans le carnet
mais quand j'ai changé la rubrique pour le mettre dans une rubrique
plus appropriée au thème,
pouf il s'est retrouvé dans le pas-wiki.
Hmmm...
Ma foi, même si c'est un peu court, je pense que ça y aurait sa place,
mais quelqu'un d'autre peut valider quand même ?
C'est quand même plus des notes qui ont leur place dans le wiki, quitte à les lier dans la doc du plugin, qu'un article
de doc qui se tient et qui est compréhensible amha.
OK c'est bien rédigé pourtant, mais pour le "compréhensible" je comprend qu'il manque une intro...
Je l'ai donc remisé dans le wiki en attendant une éventuelle intro aux concepts.
JL
Ah oups, originellement c'était dans le carnet
mais quand j'ai changé la rubrique pour le mettre dans une rubrique
plus appropriée au thème,
pouf il s'est retrouvé dans le pas-wiki.
Hmmm...
Ma foi, même si c'est un peu court, je pense que ça y aurait sa place,
mais quelqu'un d'autre peut valider quand même ?
