Pouvoir afficher une image ou un document sans titre #4914

Closed
opened 2022-12-01 11:16:57 +01:00 by Yohooo · 33 comments

Bonjour, je ne trouve pas de ticket parlant de cette problèmatique précise.

La suppression du modèle <img> a empêché de pouvoir publier une image sans legende.

C'est pourtant utile lorsque :

  • on utilise un document dans plusieur endroits du site avec certain endroit où l'on a besoin de titre et d'autre ou on n'en a pas besoin.
  • on nomme ses images avec un titre dans le backoffice pour pouvoir le trier / classer / retrouver facilement avec le moteur de recherche, mais que l'on ne veut pas voir la légende s'afficher sous l'image.
  • on utilise le titre juste pour renseigner la balise alt, , mais que l'on ne veut pas voir la légende s'afficher sous l'image.

Pour l'instant nous avons 3 solutions inadaptées pour arriver à supprimer un titre :

  • utiliser <doc|titre= > (foireux)
  • utiliser _COMPORTEMENT_HISTORIQUE_IMG_DOC_EMB dans mes options (et perdre beaucoup d'évolutions recentes du plugin).
  • créer ses propres modèles (pas adapté à l'utilisateur)

Ne pourrait-on pas créer un filtre <doc|nolegend> pour arriver à ces fins ?

Bonjour, je ne trouve pas de ticket parlant de cette problèmatique précise. La suppression du modèle \<img\> a empêché de pouvoir publier une image sans legende. C'est pourtant utile lorsque : - on utilise un document dans plusieur endroits du site avec certain endroit où l'on a besoin de titre et d'autre ou on n'en a pas besoin. - on nomme ses images avec un titre dans le backoffice pour pouvoir le trier / classer / retrouver facilement avec le moteur de recherche, mais que l'on ne veut pas voir la légende s'afficher sous l'image. - on utilise le titre juste pour renseigner la balise alt, , mais que l'on ne veut pas voir la légende s'afficher sous l'image. Pour l'instant nous avons 3 solutions inadaptées pour arriver à supprimer un titre : - utiliser \<doc|titre=&nbsp;\> (foireux) - utiliser \_COMPORTEMENT_HISTORIQUE_IMG_DOC_EMB dans mes options (et perdre beaucoup d'évolutions recentes du plugin). - créer ses propres modèles (pas adapté à l'utilisateur) Ne pourrait-on pas créer un filtre \<doc|nolegend\> pour arriver à ces fins ?
Owner

on utilise le titre juste pour renseigner la balise alt, , mais que l'on ne veut pas voir la légende s'afficher sous l'image.

Ça c'est mal, très mal, il y a un champ dédié pour ça maintenant.

utiliser <doc|titre= > (foireux)

Pourquoi est-ce foireux ? Si tu uses du titre pour usage détourné de son affichage, ça me semble normal que tu doives utiliser un moyen de contournement pour ne pas l'afficher. Sinon, il te reste la solution de créer un modèle perso comme tu le signales.

> on utilise le titre juste pour renseigner la balise alt, , mais que l'on ne veut pas voir la légende s'afficher sous l'image. Ça c'est mal, très mal, il y a un champ dédié pour ça maintenant. > utiliser <doc|titre= > (foireux) Pourquoi est-ce foireux ? Si tu uses du titre pour usage détourné de son affichage, ça me semble normal que tu doives utiliser un moyen de contournement pour ne pas l'afficher. Sinon, il te reste la solution de créer un modèle perso comme tu le signales.
b_b added the
amélioration
label 2022-12-01 11:22:07 +01:00
b_b added this to the spip-4.2 milestone 2022-12-01 11:22:11 +01:00
Owner

Tu peux déjà utiliser le raccourci <docXX|nolegend> ou <docXX|cequetuveux> et ça utilisera le modèle doc normal avec une classe nolegend ou cequetuveux.

Ensuite plus qu'à mettre une règle CSS pour la masquer sur ces modèles

Tu peux déjà utiliser le raccourci `<docXX|nolegend>` ou `<docXX|cequetuveux>` et ça utilisera le modèle doc normal avec une classe `nolegend` ou `cequetuveux`. Ensuite plus qu'à mettre une règle CSS pour la masquer sur ces modèles
Author

Pourquoi est-ce foireux ? Si tu uses du titre pour usage détourné de son affichage, ça me semble normal que tu doives utiliser un moyen de contournement pour ne pas l'afficher. Sinon, il te reste la solution de créer un modèle perso comme tu le signales.

Pardon, ce n'est pas ça qui fonctionne :
<doc|titre= >

mais ça :
<doc|titre=&nbsp;>

Et c'est foireux parce que :

  • ça génére une balise figcaption presque vide avec &nbsp; comme titre et que si on a une feuille de style qui met, par exemple, la legende sur fond coloré, on a un carré vide qui apparaît
  • c'est tout simplement pas conforatble à écrire

Tu peux déjà utiliser le raccourci <docXX|nolegend> ou <docXX|cequetuveux> et ça utilisera le modèle doc normal avec une classe nolegend ou cequetuveux.

Ensuite plus qu'à mettre une règle CSS pour la masquer sur ces modèles

OK, c'est la solution de secours pour l'instant. Mais pas à la portée des utilisateurs.
Et ça génère une balise figcaption qui ne sert à rien.

Ça c'est mal, très mal, il y a un champ dédié pour ça maintenant.

Avait pô vu. Au temps pour moi.

> Pourquoi est-ce foireux ? Si tu uses du titre pour usage détourné de son affichage, ça me semble normal que tu doives utiliser un moyen de contournement pour ne pas l'afficher. Sinon, il te reste la solution de créer un modèle perso comme tu le signales. Pardon, ce n'est pas ça qui fonctionne : <doc|titre= > mais ça : <doc|titre=\&nbsp;> Et c'est foireux parce que : - ça génére une balise figcaption presque vide avec \&nbsp; comme titre et que si on a une feuille de style qui met, par exemple, la legende sur fond coloré, on a un carré vide qui apparaît - c'est tout simplement pas conforatble à écrire > Tu peux déjà utiliser le raccourci `<docXX|nolegend>` ou `<docXX|cequetuveux>` et ça utilisera le modèle doc normal avec une classe `nolegend` ou `cequetuveux`. > > Ensuite plus qu'à mettre une règle CSS pour la masquer sur ces modèles OK, c'est la solution de secours pour l'instant. Mais pas à la portée des utilisateurs. Et ça génère une balise figcaption qui ne sert à rien. > Ça c'est mal, très mal, il y a un champ dédié pour ça maintenant. Avait pô vu. Au temps pour moi.

Il n'y a strictement aucun usage détourné @b_b : mettre des titres et descriptifs est absolument obligatoire et indispensable si on a une base de milliers de documents, et qu'on doit pouvoir les chercher retrouver quand on veut les insérer dans les contenus ensuite.

Or comme le dit @Yohooo, suivant l'endroit où on l'insère, on ne veut pas forcément de légende obligatoire, ça peut être des choses pour faire joli, ou des pictos, etc.

C'est exactement le même principe que le ticket #4856 : apparemment ya pas mal de gens qui ne comprennent pas pourquoi l'évolution très bien et légitime des modèles obligerait forcément à perdre des fonctionnalités qui étaient parfaitement légitimes aussi, et courantes !

Je ne saisis pas trop (et il semblerait que je sois pas le seul) pourquoi la solution proposée dans les deux cas c'est "démerdez vous dans votre coin" (et chacun sa ptite solution différente avec des nomenclatures différentes). Et non pas d'avoir prévu des remplacements livrés par défaut qui continuent de fournir les mêmes fonctionnalités pour ces cas : insérer en inline, et insérer sans légende.

Il n'y a strictement aucun usage détourné @b_b : mettre des titres et descriptifs est absolument *obligatoire et indispensable* si on a une base de milliers de documents, et qu'on doit pouvoir les chercher retrouver quand on veut les insérer dans les contenus ensuite. Or comme le dit @Yohooo, suivant l'endroit où on l'insère, on ne veut pas forcément de légende obligatoire, ça peut être des choses pour faire joli, ou des pictos, etc. C'est exactement le même principe que le ticket https://git.spip.net/spip/medias/issues/4856 : apparemment ya pas mal de gens qui ne comprennent pas pourquoi l'évolution très bien et légitime des modèles obligerait forcément à *perdre des fonctionnalités* qui étaient parfaitement légitimes aussi, et courantes ! Je ne saisis pas trop (et il semblerait que je sois pas le seul) pourquoi la solution proposée dans les deux cas c'est "démerdez vous dans votre coin" (et chacun sa ptite solution différente avec des nomenclatures différentes). Et non pas d'avoir prévu des remplacements *livrés par défaut* qui continuent de fournir les mêmes fonctionnalités pour ces cas : insérer en inline, et insérer sans légende.
Author

Coucou,

Je m'en suis sorti en ajoutant la condition :

{si #ENV*{legende}|=={non}|non}

ici : f2f036ff48/modeles/document_legende.html (L3)

C'est une modif simple et utile qui ne demande pas de modifier la feuille de style et qui pourra être utiliser sur tous les types de documents.

il suffira alors d'ajouter |legende=non sur n'importe quel style de document pour voire disparaître la légende.

ça serait super si ça pouvait être intégré au plugin.

Coucou, Je m'en suis sorti en ajoutant la condition : `{si #ENV*{legende}|=={non}|non}` ici : https://git.spip.net/spip/medias/src/commit/f2f036ff489a642556c52d0527004c9fcf18583f/modeles/document_legende.html#L3 C'est une modif simple et utile qui ne demande pas de modifier la feuille de style et qui pourra être utiliser sur tous les types de documents. il suffira alors d'ajouter |legende=non sur n'importe quel style de document pour voire disparaître la légende. ça serait super si ça pouvait être intégré au plugin.
Contributor
  1. J'ai souvent ce problème, donc je plussoie
  2. Par contre on pourrait utiliser en terme de nomenclatura celle du plugins albums, qui proposer <album|masquer_legende=oui>
1. J'ai souvent ce problème, donc je plussoie 2. Par contre on pourrait utiliser en terme de nomenclatura celle du plugins albums, qui proposer `<album|masquer_legende=oui>`
Contributor
  • créer ses propres modèles (pas adapté à l'utilisateur)

Pourquoi ça ne serait pas adapté ?

Afin d'assurer une compatibilité ascendante de plusieurs dizaines de sites en 3.2 passant à 4.1, j'ai juste créé ce modèle qui permet d'avoir <imgNNN|alignement> et <imgNNN> pour une image inline : https://git.spip.net/spip-contrib-squelettes/soyezcreateurs/src/branch/master/modeles/image_img.html

> - créer ses propres modèles (pas adapté à l'utilisateur) Pourquoi ça ne serait pas adapté ? Afin d'assurer une compatibilité ascendante de plusieurs dizaines de sites en 3.2 passant à 4.1, j'ai juste créé ce modèle qui permet d'avoir `<imgNNN|alignement>` et `<imgNNN>` pour une image inline : https://git.spip.net/spip-contrib-squelettes/soyezcreateurs/src/branch/master/modeles/image_img.html

Pourquoi ça ne serait pas adapté ?

Parce qu'il parle de la création même de ces modèles persos il me semble, pas de leur insertion, donc un utilisateur ne crée pas de modèles, c'est le dév qui fait ça, l'intégrateur avec accès webmaster. Donc si t'es juste admin qui utilise l'existant bah t'as rien pour le faire proprement de base sans bidouille (ce qui est le demande de ce ticket de permettre ça dès la dist).

> Pourquoi ça ne serait pas adapté ? Parce qu'il parle de la création même de ces modèles persos il me semble, pas de leur insertion, donc un utilisateur ne crée pas de modèles, c'est le dév qui fait ça, l'intégrateur avec accès webmaster. Donc si t'es juste admin qui utilise l'existant bah t'as rien pour le faire proprement de base sans bidouille (ce qui est le demande de ce ticket de permettre ça dès la dist).
Contributor

Mon avis c'est qu'idéalement il faudrait pouvoir passer une chaine vide <docxx|titre=''>, et qu'ensuite coté compilo on soit capable de detecter la différence entre chaine vide et null.

Mon avis c'est qu'idéalement il faudrait pouvoir passer une chaine vide `<docxx|titre=''>`, et qu'ensuite coté compilo on soit capable de detecter la différence entre chaine vide et null.
Contributor

Remarque également : on peut vouloir insérer une image avec un titre (tiré de la base) mais pas la légende.

Remarque également : on peut vouloir insérer une image avec un titre (tiré de la base) mais pas la légende.
Contributor

bon. J'avoue que cette affaire et le fait qu'on ne tranche pas me chagrine un peu. Je serai assez d'avis d'intégrer la solution de @Yohooo qui

  1. Ne mange pas de pain
  2. Est simple pour tout le monde
  3. N'implique ni plugin, ni modification css, ni quoi que ce soit autres que du SPIP "brut"
bon. J'avoue que cette affaire et le fait qu'on ne tranche pas me chagrine un peu. Je serai assez d'avis d'intégrer la solution de @Yohooo qui 1. Ne mange pas de pain 2. Est simple pour tout le monde 3. N'implique ni plugin, ni modification css, ni quoi que ce soit autres que du SPIP "brut"
Contributor

Pourquoi ça ne serait pas adapté ?

Parce qu'il parle de la création même de ces modèles persos il me semble, pas de leur insertion, donc un utilisateur ne crée pas de modèles, c'est le dév qui fait ça, l'intégrateur avec accès webmaster. Donc si t'es juste admin qui utilise l'existant bah t'as rien pour le faire proprement de base sans bidouille (ce qui est le demande de ce ticket de permettre ça dès la dist).

Mais ce que je propose, c'est juste de rajouter à media le modèle que j'ai créé. Et ça marche. C'est transparent sur tous les sites qui utilisaient <img...>

> > Pourquoi ça ne serait pas adapté ? > > Parce qu'il parle de la création même de ces modèles persos il me semble, pas de leur insertion, donc un utilisateur ne crée pas de modèles, c'est le dév qui fait ça, l'intégrateur avec accès webmaster. Donc si t'es juste admin qui utilise l'existant bah t'as rien pour le faire proprement de base sans bidouille (ce qui est le demande de ce ticket de permettre ça dès la dist). Mais ce que je propose, c'est juste de rajouter à media le modèle que j'ai créé. Et ça marche. C'est transparent sur tous les sites qui utilisaient `<img...>`
Contributor

Est-ce qu'on pourrait éviter de melanger le sujet des images inline et celui des légendes ?

Est-ce qu'on pourrait éviter de melanger le sujet des images inline et celui des légendes ?

Oui les deux sont importants à garder (à mon avis) mais pas forcément de la même manière "tout mélangé" qu'avant. On peut bien vouloir une insertion en modèle normal, pas inline mais en voulant explicitement masquer telle ou telle information remplie dans la base (par défaut ça affiche tout). Au moins masquer toute la légende complète, mais c'est vrai que comme dit plus haut, on peut voiloir parfois afficher le titre mais pas le reste, ou même inversement : les crédits car important légalement, mais pas le titre (qui pourrait ne pas être signifiant).

Oui les deux sont importants à garder (à mon avis) mais pas forcément de la même manière "tout mélangé" qu'avant. On peut bien vouloir une insertion en modèle normal, pas inline *mais* en voulant explicitement masquer telle ou telle information remplie dans la base (par défaut ça affiche tout). Au moins masquer toute la légende complète, mais c'est vrai que comme dit plus haut, on peut voiloir parfois afficher le titre mais pas le reste, ou même inversement : les crédits car important légalement, mais pas le titre (qui pourrait ne pas être signifiant).
Contributor

Proposition :

  • sans_legende
  • sans_credit
  • sans_titre
  • sans_description

Plutot que titre=non, car on pourrait vouloir afficher un titre dont le texte est "non"

Proposition : - sans_legende - sans_credit - sans_titre - sans_description Plutot que titre=non, car on pourrait vouloir afficher un titre dont le texte est "non"

"sans" ou "masquer" ? 😛

"sans" ou "masquer" ? 😛
Owner

"sans" ou "masquer" ?

J'allais aussi proposer masquer qui me semble plus adapté.

> "sans" ou "masquer" ? J'allais aussi proposer masquer qui me semble plus adapté.
Contributor

bah perso je suis trouver que sans est plus adapter, puisqu'on ne la masque pas : on ne la met carrément pas. Mais j'irais pas me battre sur ce genre de chose.

Sinon "supprimer"

bah perso je suis trouver que sans est plus adapter, puisqu'on ne la masque pas : on ne la met carrément pas. Mais j'irais pas me battre sur ce genre de chose. Sinon "supprimer"
Author

Est-ce qu'on pourrait éviter de melanger le sujet des images inline et celui des légendes ?

Pour les légendes, la syntaxe <docXXX|masquer_legende=oui> s'applique à tous type de documents (puisque document_legende est inclus dans chaque type de document). Elle est rapide et peut-être faite tout de suite.

Pour le questions de fond, après avoir lu le code du modèle de @RealET qui est spécifique aux images, celui-ci apporte d'autres changements :

  • prise en compte de l'aspect "inline" qui avait disparu
  • prise en compte du titre du document dans la balise alt si le champ alternative textuel n'ai pas rempli
  • différence de calcul de l'autolien

Je propose une piste (peut-être pour spip 5) : Ce traitement spécifique d'une image pourrait être pris en compte en remettant à plat l'utilisation de la syntaxe <embXXX> pour les images. Après tout <embXXX> est utilisé de manière native pour les extensiosn csv, txt et surtout svg. Elle est aussi utilisé pour les pdf dans les plugin lecteur pdf. Donc pourquoi ne pas l'utiliser de manière distincte pour les images pixélisée ?

Ce serait aussi plus logique. Il nous faudra toujours distinguer 2 cas de figure :

  • La situation où on crée une icône avec un lien vers le document
  • La situation où un document est incorporée

C'est dans ce dernier cas que <embXXX> est utilisé.

Enfin, cette méthode permettrait d'opérer facilement en transition entre les ancien et les nouveau site :

  • Soit en maintenant les vieux squelettes en y ajoutant un #INCLURE{modele/img} et tout le monde serait content.
  • Soit en recherchant remplaçant les <imgXXX> par des <embXXX>

... et tout le monde serait content

> Est-ce qu'on pourrait éviter de melanger le sujet des images inline et celui des légendes ? Pour les légendes, la syntaxe <docXXX|masquer_legende=oui> s'applique à tous type de documents (puisque document_legende est inclus dans chaque type de document). Elle est rapide et peut-être faite tout de suite. Pour le questions de fond, après avoir lu le code du modèle de @RealET qui est spécifique aux images, celui-ci apporte d'autres changements : - prise en compte de l'aspect "inline" qui avait disparu - prise en compte du titre du document dans la balise alt si le champ alternative textuel n'ai pas rempli - différence de calcul de l'autolien Je propose une piste (peut-être pour spip 5) : Ce traitement spécifique d'une image pourrait être pris en compte en remettant à plat l'utilisation de la syntaxe `<embXXX>` pour les images. Après tout `<embXXX>` est utilisé de manière native pour les extensiosn csv, txt et surtout svg. Elle est aussi utilisé pour les pdf dans les plugin lecteur pdf. Donc pourquoi ne pas l'utiliser de manière distincte pour les images pixélisée ? Ce serait aussi plus logique. Il nous faudra toujours distinguer 2 cas de figure : - La situation où on crée une icône avec un lien vers le document - La situation où un document est incorporée C'est dans ce dernier cas que `<embXXX>` est utilisé. Enfin, cette méthode permettrait d'opérer facilement en transition entre les ancien et les nouveau site : - Soit en maintenant les vieux squelettes en y ajoutant un `#INCLURE{modele/img}` et tout le monde serait content. - Soit en recherchant remplaçant les `<imgXXX>` par des `<embXXX>` ... et tout le monde serait content
Author

bah perso je suis trouver que sans est plus adapter, puisqu'on ne la masque pas : on ne la met carrément pas. Mais j'irais pas me battre sur ce genre de chose.

Sinon "supprimer"

C'est toi qui avait proposé masquer ici : #4914 (comment)

> bah perso je suis trouver que sans est plus adapter, puisqu'on ne la masque pas : on ne la met carrément pas. Mais j'irais pas me battre sur ce genre de chose. > > Sinon "supprimer" C'est toi qui avait proposé masquer ici : https://git.spip.net/spip/medias/issues/4914#issuecomment-45738
Owner

La vraie question, qui est la même que pour #4856, est : avant on avait un fonctionnement super compliqué avec des comportements divers et variés sur les 3 types de modèle document, qui permettaient de faire des variantes dans tous les sens, mais auxquelles personne ne comprenait rien en général.

On a décidé de tout simplifier avec un parti pris de fonctionnement par défaut simple et cohérent entre tous les modèles et leurs usages. Donc forcément il y a des usages qu'on ne couvre plus, on le savait à peu près depuis le départ.

Celui décrit ici en effet, ou celui décrit dans #4856 où les gens uploadaient des petites images utilisées ensuite dans le texte comme pictos inline, et surement d'autre...

Est-ce qu'on doit remettre tout ça dans le core au motif que "ben oui avant ça marchait comme ça", ou est-ce qu'on doit garder le parti prix de simplicité du core et considérer que le support des usages historiques (qu'on ne veut pas forcément encourager) relève d'un (ou plusieurs) plugins ?

Je suis plutôt pour la seconde solution parce que

  • c'est facile de venir chouiner "ah mais vous nous avez enlevé ça" et de pas voir que peu de personnes essayent de faire le grand écart entre maintenir un trilliard de fonctionnalités cachées/historiques/légitimes/super importantes et moderniser et faire avancer le projet, au risque de se décourager ;
  • il y a aucune espèce d'enjeu à avoir toutes ces petites features d'origine dans le core - notamment parce que ça semble pas les meilleurs pratiques du monde quand on commence un nouveau site ;
  • il est super simple de faire un plugin communautaire qui rétablit ces features là que les gens installeront quand ils migrent un ancien site ;
  • ça fait reposer l'effort sur un plus grand nombre de personnes, et en premier celles qui ont besoin de ces features super importantes.

Maintenant, si pour faire ça dans un plugin il semble qu'il manque des choses importantes dans le core (comme par exemple vu ici #4856 (comment)), alors oui ajoutons le

La vraie question, qui est la même que pour #4856, est : avant on avait un fonctionnement super compliqué avec des comportements divers et variés sur les 3 types de modèle document, qui permettaient de faire des variantes dans tous les sens, mais auxquelles personne ne comprenait rien en général. On a décidé de tout simplifier avec un parti pris de fonctionnement par défaut simple et cohérent entre tous les modèles et leurs usages. Donc forcément il y a des usages qu'on ne couvre plus, on le savait à peu près depuis le départ. Celui décrit ici en effet, ou celui décrit dans #4856 où les gens uploadaient des petites images utilisées ensuite dans le texte comme pictos inline, et surement d'autre... Est-ce qu'on doit remettre tout ça dans le core au motif que "ben oui avant ça marchait comme ça", ou est-ce qu'on doit garder le parti prix de simplicité du core et considérer que le support des usages historiques (qu'on ne veut pas forcément encourager) relève d'un (ou plusieurs) plugins ? Je suis plutôt pour la seconde solution parce que - c'est facile de venir chouiner "ah mais vous nous avez enlevé ça" et de pas voir que peu de personnes essayent de faire le grand écart entre maintenir un trilliard de fonctionnalités cachées/historiques/légitimes/super importantes et moderniser et faire avancer le projet, au risque de se décourager ; - il y a aucune espèce d'enjeu à avoir toutes ces petites features d'origine dans le core - notamment parce que ça semble pas les meilleurs pratiques du monde quand on commence un nouveau site ; - il est super simple de faire un plugin communautaire qui rétablit ces features là que les gens installeront quand ils migrent un ancien site ; - ça fait reposer l'effort sur un plus grand nombre de personnes, et en premier celles qui ont besoin de ces features super importantes. Maintenant, si pour faire ça dans un plugin il semble qu'il manque des choses importantes dans le core (comme par exemple vu ici https://git.spip.net/spip/medias/issues/4856#issuecomment-60618), alors oui ajoutons le
Contributor

C'est toi qui avait proposé masquer ici : #4914

ah bah tu vois, c'est que je devais pas attacher une importance folle à ce problème.

Donc oki pour masquer.

Pour @cerdic pour le problème des comportements antérieurs, c'était d'abord et avant tout l'implicite "si c'est doc ca fait ca, sauf si c'est dans portfolio, ca fait ci".

Alors que là on partirait sur de l'explicite : je dis EXPLICITEMENT que je ne veux pas la légende/le titre.

Et c'est bien parce que nous avons une base saine que nous pouvons nous permettre d'avoir des variations si c'est cohérent.

> C'est toi qui avait proposé masquer ici : #4914 ah bah tu vois, c'est que je devais pas attacher une importance folle à ce problème. Donc oki pour masquer. Pour @cerdic pour le problème des comportements antérieurs, c'était d'abord et avant tout l'implicite "si c'est doc ca fait ca, sauf si c'est dans portfolio, ca fait ci". Alors que là on partirait sur de l'explicite : je dis EXPLICITEMENT que je ne veux pas la légende/le titre. Et c'est bien parce que nous avons une base saine que nous pouvons nous permettre d'avoir des variations si c'est cohérent.

Je ne vois toujours pas en quoi c'est un besoin rare ou perso (ni plus ni moins rare que gérer l'insertion de SVG).

Encore une fois, ya aucun rapport avec "ça marchait avant", au contraire c'est plutôt bien "c'était le bordel avant avec parfois des mauvaises pratiques" et maintenant on peut réfléchir à bien avoir cette fonctionnalité MAIS faite proprement, bien carré et explicite.

C'est une TRÈS mauvaise pratique de conseiller au gens de ne remplir aucune info d'un document pour réussir à l'insérer sans légende (seule et unique manière de faire par défaut actuellement : c'est DONC ce que font concrètement les rédacs au quotidien, logique). Car après quelques temps et des centaines/milliers de documents, on ne retrouve plus rien, on peut pas les chercher dans la médiathèque (pour les insérer à plusieurs endroits par ex) puisque aucun titre…

Je ne vois pas ce qu'il y a de compliquer à : ok on force l'affichage de tout par défaut MAIS on laisse la possibilité de débrayer ensuite au cas par cas.

En 100 caractères de plus :

[(#REM)
	Legende pour les documents
]<BOUCLE_legendaire (DOCUMENTS) {id_document=#ENV{id,#ENV{id_document}}} {tout} {si #ENV{masquer_legende}|non}>
[(#ENV*{titre,#TITRE}|trim|sinon{#ENV*{descriptif,#DESCRIPTIF}|trim}|sinon{#ENV*{credits,#CREDITS}|trim}|oui)
<figcaption class='spip_doc_legende'>
	[(#ENV{masquer_titre}|non)[<div class='spip_doc_titre [(#ENV{titre}|non)#EDIT{titre}]'><strong>(#ENV*{titre,#TITRE*}|propre|ptobr)</strong></div>]]
	[(#ENV{masquer_descriptif}|non)[<div class='spip_doc_descriptif [(#ENV{descriptif}|non)#EDIT{descriptif}]'>(#ENV*{descriptif,#DESCRIPTIF*}|propre|PtoBR)[(#NOTES|PtoBR)]</div>]]
	[(#ENV{masquer_credits}|non)[<div class='spip_doc_credits [(#ENV{credits}|non)#EDIT{credits}]'>(#ENV*{credits,#CREDITS*}|propre|PtoBR)</div>]]
</figcaption>
]
</BOUCLE_legendaire>

Je ne vois toujours pas en quoi c'est un besoin rare ou perso (ni plus ni moins rare que gérer l'insertion de SVG). Encore une fois, ya aucun rapport avec "ça marchait avant", au contraire c'est plutôt bien "c'était le bordel avant avec parfois des mauvaises pratiques" et maintenant on peut réfléchir à bien avoir cette fonctionnalité MAIS faite proprement, bien carré et explicite. C'est une TRÈS mauvaise pratique de conseiller au gens de ne remplir aucune info d'un document pour réussir à l'insérer sans légende (seule et unique manière de faire par défaut actuellement : c'est DONC ce que font concrètement les rédacs au quotidien, logique). Car après quelques temps et des centaines/milliers de documents, on ne retrouve plus rien, on peut pas les chercher dans la médiathèque (pour les insérer à plusieurs endroits par ex) puisque aucun titre… Je ne vois pas ce qu'il y a de compliquer à : ok on force l'affichage de tout par défaut MAIS on laisse la possibilité de débrayer ensuite au cas par cas. En 100 caractères de plus : ``` html [(#REM) Legende pour les documents ]<BOUCLE_legendaire (DOCUMENTS) {id_document=#ENV{id,#ENV{id_document}}} {tout} {si #ENV{masquer_legende}|non}> [(#ENV*{titre,#TITRE}|trim|sinon{#ENV*{descriptif,#DESCRIPTIF}|trim}|sinon{#ENV*{credits,#CREDITS}|trim}|oui) <figcaption class='spip_doc_legende'> [(#ENV{masquer_titre}|non)[<div class='spip_doc_titre [(#ENV{titre}|non)#EDIT{titre}]'><strong>(#ENV*{titre,#TITRE*}|propre|ptobr)</strong></div>]] [(#ENV{masquer_descriptif}|non)[<div class='spip_doc_descriptif [(#ENV{descriptif}|non)#EDIT{descriptif}]'>(#ENV*{descriptif,#DESCRIPTIF*}|propre|PtoBR)[(#NOTES|PtoBR)]</div>]] [(#ENV{masquer_credits}|non)[<div class='spip_doc_credits [(#ENV{credits}|non)#EDIT{credits}]'>(#ENV*{credits,#CREDITS*}|propre|PtoBR)</div>]] </figcaption> ] </BOUCLE_legendaire> ```

Alors que là on partirait sur de l'explicite : je dis EXPLICITEMENT que je ne veux pas la légende/le titre.

Et c'est bien parce que nous avons une base saine que nous pouvons nous permettre d'avoir des variations si c'est cohérent.

Ah bé on a dit pareil en même temps. Toutafé d'accord, c'est justement maintenant qu'on peut proposer des trucs clairs, carrés, explicites, bien mieux qu'avant (et par défaut, sans rien de très compliqué à maintenir en plus).

> Alors que là on partirait sur de l'explicite : je dis EXPLICITEMENT que je ne veux pas la légende/le titre. > > Et c'est bien parce que nous avons une base saine que nous pouvons nous permettre d'avoir des variations si c'est cohérent. Ah bé on a dit pareil en même temps. Toutafé d'accord, c'est justement maintenant qu'on peut proposer des trucs clairs, carrés, explicites, bien mieux qu'avant (*et* par défaut, sans rien de très compliqué à maintenir en plus).
Author

Encore plus simple niveau syntaxe :

  • Sans légende : <docXXX|supprimer=legende>
  • Sans titre : <docXXX|supprimer=titre> ou <docXXX|supprimer=title> ou <docXXX|supprimer=tit>
  • Sans descriptif : <docXXX|supprimer=descriptif> ou <docXXX|supprimer=description> ou <docXXX|supprimer=desc>
  • Sans credits : <docXXX|supprimer=credits> ou <docXXX|supprimer=credit>
  • combo : supprimer descriptif et crédit : <docXXX|supprimer=descriptif,credit> ou <docXXX|supprimer=descredit>

En seulement 4 caractères de plus que le code de @rastapopoulos :

[(#REM)
	Legende pour les documents
]<BOUCLE_legendaire (DOCUMENTS) {id_document=#ENV{id,#ENV{id_document}}} {tout} {si #ENV{supprimer}|match{legend}|non}>
[(#ENV*{titre,#TITRE}|trim|sinon{#ENV*{descriptif,#DESCRIPTIF}|trim}|sinon{#ENV*{credits,#CREDITS}|trim}|oui)
<figcaption class='spip_doc_legende'>
	[(#ENV{supprimer}|match{tit}|non)[<div class='spip_doc_titre [(#ENV{titre}|non)#EDIT{titre}]'><strong>(#ENV*{titre,#TITRE*}|propre|ptobr)</strong></div>]]
	[(#ENV{supprimer}|match{desc}|non)[<div class='spip_doc_descriptif [(#ENV{descriptif}|non)#EDIT{descriptif}]'>(#ENV*{descriptif,#DESCRIPTIF*}|propre|PtoBR)[(#NOTES|PtoBR)]</div>]]
	[(#ENV{supprimer}|match{credit}|non)[<div class='spip_doc_credits [(#ENV{credits}|non)#EDIT{credits}]'>(#ENV*{credits,#CREDITS*}|propre|PtoBR)</div>]]
</figcaption>
]
</BOUCLE_legendaire>

Testé ici : https://git.spip.net/Yohooo/medias

**Encore plus simple niveau syntaxe :** - **Sans légende :** `<docXXX|supprimer=legende>` - **Sans titre :** `<docXXX|supprimer=titre>` ou `<docXXX|supprimer=title>` ou `<docXXX|supprimer=tit>` - **Sans descriptif :** `<docXXX|supprimer=descriptif>` ou `<docXXX|supprimer=description>` ou `<docXXX|supprimer=desc>` - **Sans credits :** `<docXXX|supprimer=credits>` ou `<docXXX|supprimer=credit>` - **combo :** supprimer descriptif et crédit : `<docXXX|supprimer=descriptif,credit>` ou `<docXXX|supprimer=descredit>` **En seulement 4 caractères de plus que le code de @rastapopoulos :** ``` [(#REM) Legende pour les documents ]<BOUCLE_legendaire (DOCUMENTS) {id_document=#ENV{id,#ENV{id_document}}} {tout} {si #ENV{supprimer}|match{legend}|non}> [(#ENV*{titre,#TITRE}|trim|sinon{#ENV*{descriptif,#DESCRIPTIF}|trim}|sinon{#ENV*{credits,#CREDITS}|trim}|oui) <figcaption class='spip_doc_legende'> [(#ENV{supprimer}|match{tit}|non)[<div class='spip_doc_titre [(#ENV{titre}|non)#EDIT{titre}]'><strong>(#ENV*{titre,#TITRE*}|propre|ptobr)</strong></div>]] [(#ENV{supprimer}|match{desc}|non)[<div class='spip_doc_descriptif [(#ENV{descriptif}|non)#EDIT{descriptif}]'>(#ENV*{descriptif,#DESCRIPTIF*}|propre|PtoBR)[(#NOTES|PtoBR)]</div>]] [(#ENV{supprimer}|match{credit}|non)[<div class='spip_doc_credits [(#ENV{credits}|non)#EDIT{credits}]'>(#ENV*{credits,#CREDITS*}|propre|PtoBR)</div>]] </figcaption> ] </BOUCLE_legendaire> ``` Testé ici : https://git.spip.net/Yohooo/medias
Contributor

Encore plus simple niveau syntaxe

alors attention, là tu rajoute des raccourcis et autres alias, et à terme ca peut justement remettre du bazar. Donc je dirais oui mais non

  • oui pour avoir juste supprimer =
  • non pour les alias : il faut que le truc à supprimer correspond précisement au champ, donc titre/descriptif/credits et rien d'autre (sauf légende éventuellement). Attention aussi aux singulier/pluriel.
  • non pour la situation concatener : si on supprime plusieurs, il faut une virgule. descriptif,credits ok, descredit non.
> Encore plus simple niveau syntaxe alors attention, là tu rajoute des raccourcis et autres alias, et à terme ca peut justement remettre du bazar. Donc je dirais oui mais non - oui pour avoir juste supprimer = - non pour les alias : il faut que le truc à supprimer correspond précisement au champ, donc `titre`/`descriptif`/`credits` et rien d'autre (sauf légende éventuellement). Attention aussi aux singulier/pluriel. - non pour la situation concatener : si on supprime plusieurs, il faut une virgule. `descriptif,credits` ok, `descredit` non.
Author
  • J'avais deviné ce type de remarque.
  • J'ai finalement opté pour "masquer". Plus explicite.

Modifié ici : https://git.spip.net/Yohooo/medias/src/branch/master/modeles/document_legende.html

ça vous va ?

- J'avais deviné ce type de remarque. - J'ai finalement opté pour "masquer". Plus explicite. Modifié ici : https://git.spip.net/Yohooo/medias/src/branch/master/modeles/document_legende.html ça vous va ?
Contributor

Pour moi ce serait bon. Reste plus qu'à ouvrir un PR incluant

  • changelog
  • tous tes commits en 1 seul, sous forme de commit conventionnel
Pour moi ce serait bon. Reste plus qu'à ouvrir un PR incluant - changelog - tous tes commits en 1 seul, sous forme de commit conventionnel
Owner

Et mettre à jour la doc officielle !

Et mettre à jour la doc officielle !
maieul referenced this issue from a commit 2023-11-14 13:26:29 +01:00
maieul referenced this issue from a commit 2023-11-14 13:28:41 +01:00
maieul referenced this issue from a commit 2023-11-14 14:57:10 +01:00
Author

Pour la doc officielle , voici un paragraphe à insérer ici https://www.spip.net/fr_article6744.htm juste derrière le paragraphe "Renseigner les informations d’une image" lorsque la PR sera fusionnée :

{{{Pour masquer la légende ou un de ses éléments :}}}

À partir de la version 4.2.7 de Spip, il est possible d’afficher une image sans sa légende, son titre, son descriptif ou ses crédits. Pour cela, utilisez les codes suivant en fonction de vos besoins :
- <code><docXX|masquer=legende></code> pour masquer la légende ;
- <code><docXX|masquer=titre></code> pour masquer le titre ;
- <code><docXX|masquer=descriptif></code> pour masquer le descriptif ;
- <code><docXX|masquer=credits></code> pour masquer les crédits ;

Il est aussi possible de masquer plusieurs de ces éléments en les espaçant par des virgules :

Par exemple, <code><docXX|masquer=descriptif,credits></code> masquera le descriptif et le crédit.

J'ai fait la proposition en commentaire de l'article dans le backoffice. N'étant par administrateur, je ne peux faire plus. Il faudrait aussi ajouter ces possibilités juste derrière le paragraphe "Aligner l’image avec les codes <docXX|left>, <docXX|center> et <docXX|right>" :

{{{Redimensionnement :}}}

Il est possible de diminuer la taille des images en indiquant soit une largeur, soit une hauteur. 
- Le code  <code><docXX|center|largeur=200></code> permettra d'afficher une image limitée 200px de large.
- Le code <code><docXX|center|largeur=200></code> permettra d'afficher une image limitée 200px de haut.

{{{Liens}}}

Il est possible de créer un lien sur une image en ajoutant : 

<code>|lien=adresse_de_mon_lien</code>
Dans le petit code généré, l'image ci-dessous pointe sur un site externe.

Il y aussi une qq coquille à modifier sur la page :
un légende -> une légende dans le paragraphe "Renseigner les informations d’une image"

**Pour la doc officielle** , voici un paragraphe à insérer ici https://www.spip.net/fr_article6744.htm juste derrière le paragraphe "*Renseigner les informations d’une image*" lorsque la PR sera fusionnée : ``` {{{Pour masquer la légende ou un de ses éléments :}}} À partir de la version 4.2.7 de Spip, il est possible d’afficher une image sans sa légende, son titre, son descriptif ou ses crédits. Pour cela, utilisez les codes suivant en fonction de vos besoins : - <code><docXX|masquer=legende></code> pour masquer la légende ; - <code><docXX|masquer=titre></code> pour masquer le titre ; - <code><docXX|masquer=descriptif></code> pour masquer le descriptif ; - <code><docXX|masquer=credits></code> pour masquer les crédits ; Il est aussi possible de masquer plusieurs de ces éléments en les espaçant par des virgules : Par exemple, <code><docXX|masquer=descriptif,credits></code> masquera le descriptif et le crédit. ``` J'ai fait la proposition en commentaire de l'article dans le backoffice. N'étant par administrateur, je ne peux faire plus. Il faudrait aussi ajouter ces possibilités juste derrière le paragraphe "*Aligner l’image avec les codes <docXX|left>, <docXX|center> et <docXX|right>*" : ``` {{{Redimensionnement :}}} Il est possible de diminuer la taille des images en indiquant soit une largeur, soit une hauteur. - Le code <code><docXX|center|largeur=200></code> permettra d'afficher une image limitée 200px de large. - Le code <code><docXX|center|largeur=200></code> permettra d'afficher une image limitée 200px de haut. {{{Liens}}} Il est possible de créer un lien sur une image en ajoutant : <code>|lien=adresse_de_mon_lien</code> Dans le petit code généré, l'image ci-dessous pointe sur un site externe. ``` Il y aussi une qq coquille à modifier sur la page : un légende -> une légende dans le paragraphe "Renseigner les informations d’une image"

Tout a l'air bon dans cette PR donc, en quelques few caractères en plus seulement : #4966

Et sans avoir à faire un micro plugin pour un truc pas juste utile mais obligatoire par défaut : dès qu'on a XXX documents on doit remplir toutes les infos de tous les documents, sans pour autant vouloir que tout s'affiche partout en permanence, qu'un truc se fasse par défaut toutafé, mais en pouvant le débrayer de base.

Tout a l'air bon dans cette PR donc, en quelques few caractères en plus seulement : https://git.spip.net/spip/medias/pulls/4966 Et sans avoir à faire un micro plugin pour un truc pas juste utile mais obligatoire par défaut : dès qu'on a XXX documents on *doit* remplir *toutes* les infos de *tous* les documents, sans pour autant vouloir que tout s'affiche partout en permanence, qu'un truc se fasse par défaut toutafé, mais en pouvant le débrayer *de base*.
maieul referenced this issue from a commit 2024-01-09 15:36:26 +01:00
maieul referenced this issue from a commit 2024-01-10 09:43:17 +01:00
b_b referenced this issue from a commit 2024-01-11 11:50:33 +01:00
b_b referenced this issue from a commit 2024-01-11 11:54:02 +01:00
b_b referenced this issue from a commit 2024-01-11 11:54:54 +01:00
b_b closed this issue 2024-01-11 11:56:01 +01:00
b_b referenced this issue from a commit 2024-01-11 12:01:25 +01:00
Owner

C'est intégré et reporté dans SPIP 4.2, reste à une personne motivée de copier/coller la doc gentiment fournie par @Yohooo sur spip.net.

C'est intégré et reporté dans SPIP 4.2, reste à une personne motivée de copier/coller la doc gentiment fournie par @Yohooo sur spip.net.
b_b added
documentation
and removed
amélioration
labels 2024-01-11 12:03:37 +01:00
b_b reopened this issue 2024-01-11 12:03:42 +01:00
Contributor

c'est fait

c'est fait
Sign in to join this conversation.
No Milestone
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: spip/medias#4914
No description provided.