http://www.paris-beyrouth.org

Juste superbe, Brabo @arno !!

Yeah super ! Ça mériterait aussi les « jolis soulignements » de Medium (et de nombreux autres médias désormais), dans les corps de textes principaux tout du moins. :)

Salut @arno,

merci pour ce décorticage, toujours intéressant, de projet et beau résultat !

Un petit retour : il semble y avoir les balises html dans le title de certaines page, par ex ▻https://orientxxi.info/magazine/colloque-du-deni-de-palestine-a-l-apartheid,2674

Erreur de copier/coller, c’est cette adresse qui a un title chelou : ►https://orientxxi.info/outils/selections/les-pays/pays-du-levant,2316

@jeanmarie: ah oui merci. (C’est corrigé maintenant).

C’est beau, bravo et merci. Il y a une chose que vous avez modifiée, et que je regrette, c’est que dans la séquence des identifiants de l’article, prenons aujourd’hui par exemple : « Israël/Palestine > Médias > Eyal Hareuveni > 29 octobre 2018 », il n’y a plus « Orient XXI ». C’est dommage, parce que quand on fait un copié-collé, ça permet de garder l’identification du journal dont vient l’article...

Le nouveau tag #spip_recette pour recenser les retours d’expérience.

Le #plugin #SPIP « Image responsive » d’@arno utilise la méthode Netflix si je ne m’abuse.
A peu de chose près : les images ne sont pas en absolute, c’est le contenant <picture> qui a une hauteur à 0

►https://www.paris-beyrouth.org/Plugin-SPIP-Image-responsive

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

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

https://i.imgur.com/mJWfFAo.jpg

et une fois l’image chargée :

https://i.imgur.com/nQoOoBB.jpg

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

Super astuce, merci :)

Merci pour cette astuce du fond d’image en dégradé CSS.

J’ai essayé de naviguer au clavier et impossible de dérouler le hamburger :(

@realet Je viens de mettre en ligne une détection du focus en javascript, pour plier ou déplier le menu hamburger selon qu’on est sur un lien dans le menu ou en dehors.

Je fais ceci :

Bravo ! quelle réactivité !

#spip_recette

Pour créer l’effet de dégradé ci-dessus…

(1) Je pars de l’image d’origine (celle-ci n’est pas très grande, je préfère si possible travailler avec des images de 2400 pixels de large, pour couvrir les besoins d’un écran haute définition de type iPad) :

http://orientxxi.info/IMG/arton1423.jpg

(2) Dans mon logiciel de dessin, je déterminer (avec des règles bleues ici) comment découper mon image :

http://i.imgur.com/WGJaQxN.jpg

(3) Étape particulièrement importante : j’applique un dégradé vers une couleur d’aplat (qui correspondra à la couleur de mon fond d’article) sur la partie basse de l’image :

http://i.imgur.com/VaAKSIY.jpg

(4) Je découpe l’image en deux parties :

http://orientxxi.info/IMG/fonds/article1423/img_haut1423.jpg http://orientxxi.info/IMG/fonds/article1423/fond_haut1423.jpg

Je sauvegarde ces deux images (img_haut.jpg et fond_haut.jpg par exemple) sur mon disque dur.

(5) Je me rends dans l’espace privé de mon site, sur l’article qui convient, et je trouve en colonne de droite, l’encadré suivant :

http://i.imgur.com/JHXowVn.jpg

Les deux intitulés qui m’intéressent sont : « Image du haut », où je vais installer img_haut.jpg, et « Dégradé du haut » où j’installe fond_haut.jpg. Je peux uploader via « Enregistrer », mais ici, je vais cliquer plutôt sur la pipette.

http://i.imgur.com/PUS7ayG.jpg

Et hop… Cela donne directement une vue réduite de la page :

http://i.imgur.com/fvNXCLn.jpg

La pipette a indiqué que je voulais extraire automatiquement la couleur en bordure bas de l’image. Si le résultat automatique ne convient pas, je peux évidemment renseigner le code de la couleur à la main. (Et à l’inverse, si j’ai oublié de passer par la pipette pour uploader les images, je peux simplement cliquer sur la pipette une fois les images déjà chargées, ça fonctionnera aussi.)

Si nécessaire, j’effectue la même opération pour le bas de l’article.

On peut tout à fait n’installer qu’une image de haut, ou qu’une image de dégradé du haut, ou la même chose en bas, selon la nature des images qu’on utilise. Toute la difficulté, c’est de bien prévoir à quel endroit on accepte ou on interdit de placer le texte par dessus l’image, avant tout par souci de lisibilité.

Un autre usage très simple consiste à ne même pas utiliser d’image, ni en haut ni en bas, mais à simplement choisir une couleur de fond d’article.

Au niveau des squelettes, il faut modifier son squelette d’article pour appeler fonds_article.html, par exemple :

Ce squelette gère l’ajout des images. En revanche, c’est toujours à vous de créer le squelette d’affichage du bloc de texte de l’article (contenant le texte, mais aussi le titre, le sous-titre, et tout ce que vous voulez…).

De manière automatique, le squelette du plugin essaiera de charger un squelette : inc/contenu-article.html

mais vous pouvez aussi lui passer un autre nom de squelette, que vous passerez dans une variable contenu_article :

Oui, c’est un peu brut de décoffrage, il va falloir bosser un peu de votre côté…

Ah, un détail mignon : sur écran de petite taille (smartphone, tablette verticale), les images sont recadrées automatiquement, on conserve tout leur contenu vertical, mais on supprime une partie de la droite et de la gauche de l’image. De cette façon, sur petit écran, on limite l’aspect « minuscule bandeau horizontal », en « zoomant » un peu par rapport à l’image d’origine.

Quelques remarques :

– d’expérience, ce n’est pas évident du tout à utiliser ; pas techniquement (une fois qu’on a réussi à bidouiller les squelettes), ni de l’interface, mais surtout au niveau graphique ; si on n’a pas de solides compétences de graphisme (et si on ne sait pas bien utiliser un logiciel de manipulation d’images), on n’y arrivera pas ;

– du coup : ça réintroduit un graphiste dans la mise en ligne des articles. (Je te laisse réfléchir à ça…)

– réaliser les images du haut avec des dégradés est généralement beaucoup plus difficile que de créer les images du bas de l’article. Avec les images du haut, on est généralement coincés par le corps des gens, sur lesquels on ne peut pas facilement appliquer de dégradé de couleur… avec les images du bas, on a souvent le ciel ou le plafond, c’est nettement plus facile (mais moins spectaculaire puisqu’on ne le voit qu’après avoir scrollé tout l’article)

– par ailleurs, il faut essayer de faire des images « du haut » (au-dessus) du texte très larges et pas trop hautes, c’est-à-dire de grands bandeaux très horizontaux, puisque sinon on va rejeter le texte après l’image, possiblement en dehors de l’écran ; ça ajoute encore de la difficulté dans la création des images de fond du haut de l’article (alors que, en bas de page, on n’a aucun problème à avoir une image très haut).

Le plugin permet aussi de gérer une image en fond d’article (ni en haut, ni en bas, « en fond »…). Cela se passe dans la partie basse de l’interface :

http://i.imgur.com/IMLOOPi.jpg

On chargera donc une image dans « Image de fond », qui devra s’afficher sous le bloc de texte de l’article.

Il y a alors trois options pour dimensionner ce bloc de texte :

– taille automatique, le bloc aura naturellement la taille fabriquée par son contenu ; c’est l’image qui tentera de s’adapter aux dimensions du bloc de texte (donc de manière potentiellement grotesque) ;
– remplir l’écran, le bloc aura la hauteur de la fenêtre du navigateur ; si nécessaire, le plugin ajoutera de l’espace en haut et bas du texte pour centrer le texte dans l’écran, ou au contraire provoquera un ascenseur vertical (pas dément). C’est surtout destiné à un texte très court. Et c’est excessivement difficile à maîtriser, à cause des grandes différences de tailles d’écrans ;
– proportions de l’image : fabriquer un bloc de la « taille » de l’image affichée sur toute la largeur de l’écran ; on ne cherche pas à « remplir » l’écran, mais à afficher toute l’image. Comme précédemment, c’est destiné aux textes courts, ça ajoute du blanc ou ça ajoute des ascenseurs selon la hauteur du bloc de texte, mais c’est généralement plus facile à maîtriser…

Dans le cas de remplir l’écran, par défaut le plugin affichera l’image en « position : fixed », l’image s’affichera avec cet effet de « parallaxe » (qui personnellement me sort désormais par les oreilles…), c’est-à-dire un élément qui ne scrolle pas pendant que le reste de la page défile.

Et une dernière technique : si tu fais ça en haut et bas d’articles, et que tu affiches tous les articles d’une rubrique les uns après les autres dans la même page, tu obtiens un énorme… longform. Et c’est comme ça que j’ai fabriqué ma démo de la Nasa. (Ou, moins « fondue » graphiquement, la page d’accueil de Paris-Beyrouth.)

Dans le cas de la Nasa, toute la difficulté consiste à découper les images pour que le bas de l’article se « fonde » pour devenir le haut-dégradé de l’article suivant, et qu’on ait ainsi une impression de passage d’un article à l’autre avec une même grande image dégradée vers le haut et vers le bas. C’est pas évident à faire graphiquement, ça demande des images très spécifiques, le choix des couleurs se complique d’autant, mais le résultat est assez bluffant.

Super !

Au niveau technique (je fais ce que je sais hein :p) il y aurait sûrement moyen de rendre ça générique pour l’activer (avec une config) sur n’importe quel type de contenu (objet SPIP). Le stockage est dans un sous-dossier « article123 » donc on devrait pouvoir avoir la même chose pour « rubrique123 » ou « patate123 ».
(D’ailleurs je ne vois pas pourquoi l’id est répété dans le nom des fichiers, puisqu’on stocke déjà tout dans un sous-dossier dédié à tel contenu précis.)

Pour les images, effectivement je ne vois pas ce qu’on pourrait automatiser de plus, et donc il faut forcément des compétences graphiques, c’est sûr.

À la limite, avec une interface plus complète dans l’admin avec du JS, on pourrait imaginer faire le découpage, définir la ligne où va commencer le dégradé, et créer le dégrader (pas auto, avec un outil graphique pour définir l’amplitude, etc)… il y a des librairies JS qui permettent de manipuler ce genre de choses. Mais bon ça demande un sacré gros boulot en plus…

@rastapopoulos :

– oui sur la généralisation, très juste, juste faire attention que ça stocke trois petites infos en base de donnée de l’objet (intitulé des images, et dimensionnement quand image de fond) ;

– ne me demande pas pourquoi je répète le numéro dans un dossier déjà numéroté :-))

– une évolution que j’envisage, effectivement, c’est de ne plus demander deux images pour gérer l’endroit où commence le texte, mais d’utiliser directement un curseur à gérer par glisser-déposer sur l’image dans l’interface privée ; parce que c’est un des points les plus bloquants pour les usagers ;

– une autre difficulté : mon plugin image_reponsive ne fabrique pas de timestamp, et comme il faut souvent s’y reprendre à plusieurs fois, hé ben c’est pas pratique parce que l’usager lambda se fait planter par son cache quand il veut voir ses nouvelles images…

#spip_blog

Chouette Arno*. Merci.

Juste une remarque : l’habillage irrégulier ne semble pas fonctionner sur l’exemple de ton article ? (Firefox 53 / OSX)

#spip_blog

Yep : pas Firefox. (Mais ça se dégrade bien : ça fait un habillage « normal » selon le bord « rectangulaire » de l’image.)

#spip_blog

Juste un retour d’expérience d’une novice : 4 utilisations pour votre plugin Insertion avancée d’images (particulièrement le slide) : 2 utilisations « telles quelles » => 1) en espace public ; 2) espace privé, pour afficher des slides de copies écran des fantaisies typographiques (exergue, épigraphe et autres qui ne « passent » pas autrement dans l’espace privé (et l’affranchissement de Java est un gros « plus » dans l’espace privé) ; et 2 utilisations « hors-normes » (ou "hack si vous voulez !) dans l’espace public : 3) création de slide façon « vrai slide javascript », avec les poignées précédent/suivant sur le côté et les bulles de positionnement en haut (ça marche super, le seul hic c’est qu’évidemment la bulle de positionnement ne se met pas à jour - ne change pas de couleur - quand on choisit la slide avec les poignées de côté, mais bon, les visiteurs s’en accomoderont !) et 4) un super petit truc pour afficher les articles suivant/précédent façon « Monde Diplomatique » (les flèches en Java du haut de l’article), en jouant à nouveau sur le CSS uniquement (ce qui fait que, en affichant une double flèche en haut de l’article, ce qui s’affiche en-dessous est initialement « rien » puis si on clique dessus, on fait venir le titre de l’article suivant à l’intérieur du système « slide » (invisible) et de même pour le « précédent ». Je suis très contente de ma trouvaille de débutante et voulais vous en faire part, ça fonctionne à merveille. Merci beaucoup.

Merci @arno et @erational qui vient d’ajouter le lien vers la doc en question dans le plugin :)

#spip_blog <= si jamais je prends le temps de publier une gazette un de ces jours...

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

Génial. Merci beaucoup.

Utilisé pour tous nos derniers sites, avec image_recadre pour le moment, tout simplement. :)

#spip_blog

Pour ma part, je l’utilise aussi sur mes nouveaux projets. Avec le duo image_responsive et medias_responsive_mod, ça tourne super !
Merci

Hop : en utilisation à l’instant pour les vignettes de navigation sur Orient XXI (qui sont systématiquement recadrées horizontalement ou au carré) :
►http://orientxxi.info

Avant :

http://i.imgur.com/ABOkcDB.png

Après :

http://i.imgur.com/Q2OIxET.png

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

cc @matlap

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

De mon côté j’avais commencé à imaginer un petit plugin « Focus » dont le but est de permettre aux admins/rédacs de définir explicitement le point de focus de chaque image. Libre ensuite à d’autres plugins ou aux squelettes d’utiliser ces x/y lors des recadrage.

@rastapopoulos oui, c’est exactement ça qui me manque. Tu as du code ou des idées ?

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

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

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

#spip_blog #merci :)

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

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

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

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

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

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

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

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

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

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

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

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

#merci !

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

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

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

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

http://i.imgur.com/pvTiwUm.jpg http://i.imgur.com/eWW5CuI.jpg

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

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

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

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

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

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

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

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

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

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

@ben : je crois que j’ai posté avec la mauvaise adresse email, mon message n’a pas dû passer. Je viens de réexpédier avec mon adresse usuelle.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et peut être en EXIF si le format d’image le supporte ?

et +1 pour image_proportions dans SPIP directement (ou dans filtres_images) @b_b, @arno

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

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

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

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

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

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

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

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

ou encore, pour avoir une taille spécifique

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

Il y a aussi focus-center comme dans image_proportions.

@marcimat \o/

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

Je me suis fait une fonction sympa :

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

Qu’est-ce qui a présidé à ce choix technique ?

@realet Peut être parce que ça prend en compte les logos, qui ne sont pas stockés en BDD :)

@marcimat Mais oui bien sûr, c’est évident maintenant que tu le dis ;-)

J’en parle ici un peu ▻http://medias.spip.net/medias/video-tutorials/article/affichage-ordre-et-point-d

Bonjour. Le plugin medias est-il toujours nécessaire ? En l’état je ne peux pas changer le point de focus sur le logo de l’article car le clic provoque l’ouverture de la mediabox. Est-ce lié stp ?

@vlentz Tu dois cliquer sur la croix et la déplacer, pas cliquer n’importe où sur l’image directement.

Merci pour le tip. J’ai réussi à le faire sur Firefox (mais plus maintenant) et pas du tout sur Chrome.

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

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

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

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

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

Y’a t-il un moyen de tester le « focus » si il a été utilisé ou pas ? Si ça valeur par défaut a été changée ?

La doc : ►https://www.paris-beyrouth.org/Plugin-centre_image

#spip_blog

je like, mais c’est pour ma retraite quand j’aurai appris à coder avec @fil et @archiloque d’ici quelques années

@reka, une première leçon de code : on ne dit pas « je lirai plus tard », on dit #TLDR

Merci Arno pour cette super documentation

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 :)

@marcimat, merci, corrigé!
#seenthis_c'est_bon_mangez_en

Cool ! je le testais à l’instant ;) mais pas en varnish … en plus court on peut écrire

dis @arno, on présente comment du code sur seenthis ?

@touti : avec des backticks

et, si tu veux présenter ton code sur plusieurs lignes, tu en mets 3 au-dessus et 3 en dessous

pour la doc d’ESI voir
▻https://www.varnish-cache.org/docs/4.0/users-guide/esi.html

à noter, varnish ne traitera pas les requêtes ESI si la page ne commence pas par un < (des espaces sont tolérées).

roo, trop bien! merci @fil

Bon, il y a une grosse difficulté : les petites inclusions sont des appels SPIP basés sur var_ajax=recuperer. Et ces pages ne sont jamais mises en cache par Varnish (@fil me dit que c’est parce que dans ecrire/inc/actions.php, la fonction ajax_retour ne prévoit pas d’envoyer d’information de durée de vie du cache.

Du coup, tel quel, mon inclusion ESI est particulièrement productive (j’ai planté Flip-Zone hier et ce matin) : au lieu d’appeler une page SPIP en cache de Varnish (et si elle ne l’est pas : un appel Apache), j’appelle une page qui contient des dizaines d’inclusions ESI qui demandent à charger des pages SPIP en var_ajax, pages qui ne sont justement pas en cache de Varnish, et déclenchent donc autant d’accès à Apache.

Pour l’instant, tout ce que j’ai trouvé, c’est d’ajouter un réglage à la sauvage dans Varnish, au niveau vcl_fetch :

En fait, autre souci en même temps : depuis deux jours je me cogne des milliers d’erreurs 404, parce que je reçois du traffic bizarre depuis la Chine.

J’ai bien l’impression qu’il s’agit de ceci (le firewall qui censure l’interwebz chinois m’expédie ses indésirables) :
▻http://qz.com/351281/chinas-great-firewall-is-demolishing-foreign-websites-and-nobody-knows-why

désolé pour l’aspect, je pensais pouvoir mettre un tableau au format SPIP dans mon post...

le tableau est un peu mieux présenté :
▻http://contrib.spip.net/Le-point-sur-les-outils-pour-squelettes-recents?var_mode=preview

Zcore + CSS imbriquées + jQuery c’est bien, j’ajouterais semantic-ui à mon paquet pour ne pas avoir à réinventer la roue en termes d’interactions

je ne comprends pas : toutes les images doivent être au ratio 16/9 pour que ça marche ?

Non. L’aspect responsive n’a pas besoin qu’on formate spécifiquement les images. Au contraire, le plugin permet qu’on balance les images d’origine sans faire trop attention.

Mais à l’inverse, pour faire maquette sympa, c’est vraiment plus efficace si on se force à avoir des vignettes de navigation de mêmes proportions (par exemple 16/9, mais ça peut être 4/3, 1/1, ce qu’on veut…). Voir la page d’accueil d’Orient XXI, les vignettes sont toutes recardées aux mêmes proportions :
►http://orientxxi.info

Pour ça, habituellement, on recadre les images directement aux dimensions prévues, genre :

Mais avec le plugin image_responsive, je n’ai plus besoin de savoir la dimension finale de l’image, parce que c’est le plugin qui va charger l’image dont il a besoin. Et même potentiellement la largeur de l’écran d’un smartophone, à double définition.

Donc c’est pas la peine de s’embêter à calculer avec le redimensionnement de l’image en amont : tu balances l’image complète directement, ça chargera juste ce qui est nécessaire selon la maquette la définition de l’écran.

C’est donc un confort lié à ce que fait ce plugin :
– comme il va chercher l’image à la bonne taille tout seul, il n’est plus nécessaire de réduire les images dans le squelette ; ça laisse d’autant plus de latitude pour différentes situations et les écrans retina ;
– mais dans le même temps, j’ai l’habitude de recarder les images pour forcer des maquettes plus typées.

Donc là j’en profite pour recadrer sans réduire, parce que c’est le plugin qui fera le reste du travail selon les situations.

C’est bien sympa et générique, ça mériterait d’être ajouter au plugin dist « filtres_images » (qui est indépendant du core, donc qui a son propre cycle de vie désormais, à peu près).

Dans :
▻http://zone.spip.org/trac/spip-zone/browser/_core_/branches/spip-3.0/plugins/filtres_images
Et dans :
►http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/filtres_images

Ainsi que hex2rgb ? ▻http://seenthis.net/messages/176638

C’est déjà dans le plugin « CSS imbriqués » (version 1.6) :
►http://www.paris-beyrouth.org/tutoriaux-spip/article/plugin-spip-pre-processeur-de-css

1.6. Introduction de la fonction couleur_rgba($couleur, $alpha) qui permet de fabriquer une couleur RGBA à partir d’un code hexadécimal.

Il me semblait bien que je l’avais vue quelque part sur Paris Beyrouth

et une gestion de portrait/paysage/carré ?

C’est à dire @Fil ?

Sur un de mes sites j’ai fait une série de tests sur la largeur et la hauteur pour afficher l’image en pleine largeur si elle est en paysage et assez grande et dans une colonne si elle en portrait ou trop petite. Je m’étais bien pris la tête.

Suite à l’observation de @rastapopoulos j’ai ouvert ▻http://core.spip.org/issues/3144 pour garder une trace du besoin.

b_b me dis de l’ajouter moi même mais je ne sais pas coder moi :-)

C’est classe d’avoir ce genre d’explications sur des sites. Deux-trois retours :
– +1 pour la question des retours lignes. C’était un peu embêtant avant, fallait s’y faire, mais maintenant sur Spip 3 c’est pire :p
– Pour les réseaux sociaux, le rendu est top, cf ▻https://twitter.com/OrientXXI/status/387504642331901952
– moi aussi je veux un bouton de partage vers Seenthis. C’est le bouton pour navigateur intégré sur le site, c’est ça ?
– au niveau typo, je pense qu’on gagne vraiment à remplacer les dernières Arial qui traînent.
– sur la page d’accueil, les trois colonnes ça fait très classe, mais le web ne sait toujours pas justifier du coup ça éclate le texte chez moi. A l’inverse, j’aime beaucoup la page magazine non justifiée.
– le corps 19 pour le texte, ça fonctionne bien, mais par contre le corps 26 pour le chapô, c’est un peu trop gros pour moi.
– j’ai pas compris l’intérêt du plugin « lire aussi » pour constituer des dossiers éditoriaux par rapport à un groupe de mots-clés spécifique.
– le mode plein écran pour les cartes est vraiment impressionnant, et les cartes dans les articles sont bien aussi. Ca pourrait bien intéresser sous-surveillance. Manque peut-être juste un bouton pour revenir à une taille optimale dans le bloc quand t’as déjà zoomé.

Merci en tout cas pour les infos, joli boulot !
#spip_blog

Sur « Lire aussi » et les « Dossiers »…

– D’abord, tu dois savoir que je suis persuadé (de manière quasiment religieuse désormais) qu’il ne faut jamais utiliser les mots-clés pour gérer des statuts éditoriaux. La seule utilisation viable des mots-clés, c’est la thématisation.

À chaque fois que j’ai vu (ou qu’on m’a obligé à le faire) des mots-clés utilisés pour gérer la page de Une, la colonne de droite, les trucs qu’on fait apparaître plus gros… ça rend le site vraiment bordélique à gérer.

– Donc ici, oui, il y a des mots-clés, mais ce sont bien des mots-clés thématiques. Par exemple, les Accords d’Oslo :
▻http://orientxxi.info/accords-d-oslo

Mais il faut bien voir que les mots-clés, ce sont des thèmes « ouverts » : à tout moment quelqu’un peut ajouter tel mot-clés à tel nouvel article, et donc la page « Accords d’Oslo » évoluera selon ces ajouts.

– Ce dont j’avais besoin ici, c’est de créer des « Dossiers » figés. Un objet éditorial regroupant plusieurs articles, qu’on n’enrichira plus par la suite.

Donc pas des mots-clés. Sinon ça veut dire qu’on a un groupe de mots-clés dédiés à cela, et qu’on fabrique un mot-clé à usage unique pour chaque « Dossier ». Pour moi, c’est clairement un détournement des mots-clés, destinés à faire des manipulations éditoriales.

Ça n’est pas le pire détournement possible, mais c’est à éviter.

– Le plugin « Lire aussi » est explicitement destiné à gérer ces regroupements, au lieu de créer des « mots-clés à usage unique ». Il est construit sur le même principe que les liens de traduction : il y a un article de référence, et les articles qui lui sont liés. Dans chaque article concerné, je vois la liste des articles liés, et quel est l’article de référence.

Du coup, ici, c’est facile : l’article de référence est considéré comme la porte d’entrée du dossier (ce ne serait pas facile à faire avec des mots-clés), et je pourrais aussi décider de ne plus intégrer les articles secondaires du dossier dans la navigation, ou de manière différente (je n’ai pas fait ça, mais c’est une possibilité).

Coucou,

Plein de belles choses. Mignon la petite image « dossier » qui se colle sur le logo de l’article d’accueil du dossier.

Quelques bugs ou remarques :
– le logo est un peu pixélisé sur les autres pages que la page d’accueil (ff20/linux)
– quand y’a pas de logo pour les articles dans les listes de « Lire aussi », ça fait un peu bizarre. ici par ex : ▻http://orientxxi.info/magazine/barack-obama-et-hassan-rohani,0381
– c’est peut-être voulu, mais chez moi les thèmes ne sont pas stylés. Ça me fait penser aux sites de journaux américains, qui raffolent de liens bleus ►http://www.nytimes.com

Une petite question. Comment sont fabriquées les url ? Le numéro à la fin, c’est pour google (j’ai un vague souvenir que google demande un nombre unique pour chaque page dans l’url) ?

C’est super de présenter ses réalisations de sites et leur entrailles. Ça devrait être une rubrique sur le blog de SPIP ou sur spip-contrib, pour inviter tout le monde à le faire.

Pour les URL, c’est un bout de code trouvé je crois sur Contrib, mais je ne sais plus où. Dans mes_options.php :
▻https://gist.github.com/anonymous/6899027

Ah si, retrouvé, c’est là :
▻http://contrib.spip.net/Optimiser-les-URLS-pour-google-actus

Hop @arno pour info il existe un plugin leaflet.fullscreen fait par un ty gars sympa sur github ;)

▻https://github.com/brunob/leaflet.fullscreen

Et depuis hier, il gère aussi du pseudo fullscreen pour les vieux navs.

@arno oui c’est un truc « rapide » qui marche, mais du coup :
1) je trouve que ça enlaidie les URLs pour une histoire uniquement technique (en plus même pas pour un standard reconnu mais juste pour faire plaisir à une entreprise particulière)
2) si jamais le site a des objets éditoriaux différents (article, rubrique, événement, patate) : deux objets peuvent avoir le même nombre donc il n’est pas unique (ce qui normalement fait partie de la demande).

Lorsqu’on ne veut pas modifier ses URLs, la solution est de fournir à Google un sitemap particulier, propre à #Google-News. Il y a quelques obligations à respecter, et possiblement des infos en plus quand on les a sous la main (voir la doc).
▻https://support.google.com/news/publisher/answer/74288?hl=fr

J’ai fait ça dans un mini-plugin tout con qui ajoute ça au robot.txt de SPIP et qui fournit un « sitemap_news » basique qui fonctionne. On peut le surcharger ensuite chez soi si on a plus d’infos à y mettre.
▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/sitemap_news/trunk

@arno : merci, je vais tester. Sur Rebellyon, les articles en manchette ont le mot-clé « manchette », ceux en « une », le mot-clé « une ». Et quand on a beaucoup d’articles sur un même sujet, on crée un mot-clé de dossier. Tout cela fonctionne, mais c’est pas forcément aisé à transmettre comme fonctionnement.

Je pense qu’il faut créer ou améliorer un plugin pour ces besoins, car il y a de plus en plus de sites où il y n’y a pas que les « articles » comme objets éditoriaux.

Par exemple pour le besoin de « mettre en une » (que ce soit pour l’accueil complet ou l’accueil d’une rubrique), si on veut mettre en avant des articles et des événements dans la même liste, c’est galère. Ou même si on a un site composé presque que d’événements (un site culturel par ex) et que c’est ça le contenu éditorial principal du site.

Bref, ce type de plugin devrait être agnostique au niveau des objets à manipuler.

Pour gérer les Unes, j’utilise généralement deux solutions :

– la plus efficace et agréable à gérer, ce que je fais sur ce site-là, c’est le plugin « Sélection d’articles » ; c’est rapide, ça marche bien…

– quand le site est plus compliqué, et que justement il faut pouvoir mettre en page d’accueil un peu tout et n’importe quoi (des articles, des rubriques, des « événements », des calendriers, des formulaires d’inscription à des trucs…), je fais dans le lourd : une « rubrique technique » (dont je fais généralement commencer le nom par un dièse), avec éventuellement des sous-rubriques (si la page d’accueil est très structurée), et là-dedans on installe des articles virtuels (des articles qui pointent directement vers une autre URL). C’est encore avec ça que j’ai les résultats les plus puissants et le plus de liberté, même si c’est assez contraignant.

En fait c’est peut-être soit que les gens ont été formés au spipcode, soit qu’ils copient-collent dans du WYSIWYG (dans spip ou ailleurs, d’ailleurs).

ou peut être l’endroit de la documentation ? les gens vont chercher plus facilement sur spip-contrib peut être (ne pas voir une critique mais je vois les mêmes problématiques avec certains de mes plugins qui sont documentés autre part)

sinon aussi l’absence de plugins.spip.net qui est assez simple à changer en créant le zip via archivelist.txt

sinon encore, l’absence de lien de documentation dans le plugin.xml ?

Et finalement, la nécessité du binaire openoffice si je ne fais pas d’erreur ? ou d’autres binaires sur le serveur ? beaucoup de spip users sont quand même sur des hébergements bien fermés non ?

Voilà quelques pistes peut être du pourquoi du comment dont deux sont particulièrement faciles à régler

Comme alternative il y a #DotSPIP, une petite app de bureau pour Mac sur laquelle tu drag/drop tes fichiers ; le texte spipé se retrouve dans le presse-papier, prêt à être collé. Ca n’a pas beaucoup de succès non plus, le marketing est pas au point :)

Peut-être parce qu’il n’y a pas tant de personne sous Mac que ça... :)

=> combiner le truc d’Arno et de Fil pour faire un #webservice avec une API utilisable depuis n’importe où : ainsi, pas de problème de système particulier, et pas non plus le problème de maîtrise du serveur pour le pékin moyen, qui n’aura pas besoin d’installer telle ou telle librairie. Ensuite faire un plugin SPIP qui utilise cette API, que chacun installe chez soi facilement. #idée_pour_SPIP. :)

je l’ai déjà faite cette API (▻http://office.rezo.net) mais jamais pris le temps de faire l’emballage

Si ce n’est pas sur spip contrib ça n’existe pas :-)

Bon, j’ai ma clé, comment je l’emploie cette API ?

#impatient #office2spip

de façon tout à fait concurrente il y a le plugin odt2spip : ▻http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers
– : n’accepte que du odt en format d’entrée*
+ : aucune config serveur spécifique
+ : gère les formules de maths intégrées dans le fichier odt

*vu que le fonctionnement est basé une XSLT odt=>spip, l’ajout du format docx n’est que l’affaire de trouver un dev accepte de trifouiller du MSOffice... (beurk !)

@cy_altern, c’est fort possible que ça marche bien évidemment, mais je m’interroge sur la maintenance à long terme : maintenir soi-même des transformations XSLT pour un ou plusieurs formats, c’est super long et complexe, alors qu’il existe des logiciels ou librairies maintenues collectivement qui font déjà ces transformations (en plus en gérant plus de formats différents). C’est toujours le même problème, d’essayer d’utiliser des choses existantes (si ça fonctionne évidemment).

@RastaPopoulos : dans ce cas la XSLT fait la transformation XML format OpenDocument => langage SPIP , truc qui n’existe (à ma connaissance) nulle part ailleurs (le choix de ce plugin c’est d’éviter de faire XML => HTML => SPIP)
Pour ce qui est de la maintenance du convertisseur, il semblerait que les versions successives d’OpenOffice puis de LibreOffice n’ont jamais modifié le format du XML d’odt depuis que le plugin existe : la XSLT utilisée est restée inchangée depuis sa mise en fonction en 2009...

pour avoir testé office2spip et odt2spip en parallèle sur un gros fichier, j’ai eu les meilleurs résultats avec odt2spip

un coup de #spip_blog pour odt2spip :)

Y’a un peu de code libéré ici : ▻http://zone.spip.org/trac/spip-zone/changeset/76826

à intégrer d’une manière ou d’une autre dans #mediaspip ... @severo risque de s’en charger

Je ne le fais pas, mais à mon avis, j’abonnerais directement mon site SPIP à mon flux RSS de Seenthis. Le tien est là :
►http://seenthis.net/people/davduf/feed

Du coup, dans SPIP, tu peux décider d’afficher non seulement le titre, mais le texte complet formaté en HTML (si tu as envie).

J’avais fait une présentation pour Twitter, qui paraît-il ne peut plus fonctionner sur Twitter, mais qui en revanche devrait directement être utilisable pour Seenthis :
►http://www.paris-beyrouth.org/tutoriaux-spip/article/afficher-des-messages-twitter-sur

Et que dirions nous de la boucle [data] de #SPIP-3 ?
Genre : ►http://spip3.quejai.me/rss-afficher-les-resultats-d-une-recherche-twitter

Mais comment faire pour l’adapter à SeenThis ?

Pourquoi faire ? (À part pour le fun ?)

j’ai tenté un coup de rss sur ►http://zzz.rezo.net mais il aurait fallu styler un peu, et j’ai eu la flemme…

Ah, oui... Merci @Fil ! On approche, on approche. Je fais tes tests de mon côté et je vous reviens vite...

Merci !

Ça marche ici aussi : ►http://www.davduf.net/@Selection-web@

Maintenant, comment affiner l’affichage ? Par exemple, les tags SeenThis ne correspondent pas aux mots clés du site Spip.

Le plus simple (?) serait de ne pas les afficher sur le site.
Des idées ?

Si tu utilises SPIP, le plugin « CSS imbriqués » fournit un pseudo-CSS qui fabrique automatiquement les différentes versions -moz, -webkit… (y compris – surtout – le filtre compatible avec les anciennes versions de MSIE) :
►http://www.paris-beyrouth.org/tutoriaux-spip/article/plugin-spip-pre-processeur-de-css

-spip-gradient : top, #f0f0f0, #bbbbbb ;

Du coup, pas bien compliqué de faire un dégradé compatible avec quasiment tous les navigateurs utilisés (puisque ça fonctionne même sous MSIE 6…).

Là c’est un tuto général, mais merci de l’info.
Donc, à part le café (et encore) que ne fait pas SPIP ? ;)

les pâtes (enfin le beurre dans les)

Comment ça pas de beurre ? Tu oses avouer ça à une bretonne ?!! ohhhh va falloir faire quelque chose d’urgence là messieurs les spipeurs !