Hello,
suite à une discussion sur irc, il semble que certains utilisateurs utilisent deux box à la fois, comme thickbox ou fancybox
Par ailleurs thickbox avait le bon goût (à mon avis) de selectionner toutes les liens vers des images dont le mime type etait indiqué dans la page.
Il semble que fancybox ne le faisait pas initialement, mais le fait maintenant.
Plusieurs questions se posent :
comment éviter que 2 box activées ne se collent sur la meme image dans ce cas ?
comment eviter que les box ne traitent toutes les images de la page
faut il garder le comportement a base de mimetype ou à base de classe
Mes quelques sous de reflexion :
→ je pense qu’il faudrait définir une convention de classe commune (‹ nobox › par exemple) qui signale les images à ne pas traiter, qui serait gérée par tous les plugins *box.
→ que les plugins *box posent cette classe sur les liens qu’elles ont deja traités (et qui ne seront pas traités une seconde fois par l’autre box)
→ je suis personellement pas convaincu par l’utilisation des class thickbox, fancybox,nyrobox, trucbox, totobox, demainbox, autrebox… qui amènent une orgie de classe dans les squelettes suceptibles d’être utilisés avec une box. Sans compter qu’à chaque nouveau plugin, il faut recorriger …
Il me semble que l’intérêt de thickbox c’est qu’on l’active et ça marche, sans avoir modifié son squelette. Et qu’on devrait pouvoir utiliser indiférremment thickbox, fancybox ou une autre. Cela milite pour une class générique ou pour garder l’utilisation sur la base des mime type, a l’exception de ceux qui ont une classe nobox, dans ce cas.
Il me semble que l'intérêt de thickbox c'est qu'on l'active et ça marche,
sans avoir modifié son squelette. Et qu'on devrait pouvoir utiliser
indiférremment thickbox, fancybox ou une autre. Cela milite pour une class
générique ou pour garder l'utilisation sur la base des mime type, a
l'exception de ceux qui ont une classe nobox, dans ce cas.
Entièrement d'accord avec ces deux points. Il faudrait aussi homogénéiser :
1) les squelettes de portfolio (actuellement celui de cheznous n'a pas
le même nommage que celui de la dist), de manière à ce que les
galeries se fassent bien sur les deux.
2) la gestion des longdesc pour afficher les légendes, que je n'ai
codée (et pas totalement finie) que dans la fancybox. Cf. "afficher la
légende" dans Bolloré au Cameroun, un bilan en images (Les blogs du Diplo, 16 juin 2009)
Pour Thickbox, je pense qu’en faisant la mise de thicbox 2 à la 3.1, certains soucis ne seront plus présent…
Pour la gestion des box sur toutes les images, pourquoi ne pas mettre un rel au modèle doc/img? Cela permettrait de différencier les différents groupes d’images. On prendrait soit un identifiant rubrique, soit l’identifiant de l’article en compte. Bien entendu, on ajoute un suffixe ou préfixe au tout pour qu’il n’y ait pas de conflit lorsque l’ID_ARTICLE et l’ID_RUBRIQUE sont identiques…
Hello,
suite à une discussion sur irc, il semble que certains utilisateurs utilisent deux box à la fois, comme thickbox ou fancybox
Par ailleurs thickbox avait le bon goût (à mon avis) de selectionner toutes les liens vers des images dont le mime type etait indiqué dans la page.
Il semble que fancybox ne le faisait pas initialement, mais le fait maintenant.
Plusieurs questions se posent :
comment éviter que 2 box activées ne se collent sur la meme image dans ce cas ?
comment eviter que les box ne traitent toutes les images de la page
faut il garder le comportement a base de mimetype ou à base de classe
Mes quelques sous de reflexion :
→ je pense qu’il faudrait définir une convention de classe commune (‹ nobox › par exemple) qui signale les images à ne pas traiter, qui serait gérée par tous les plugins *box.
→ que les plugins *box posent cette classe sur les liens qu’elles ont deja traités (et qui ne seront pas traités une seconde fois par l’autre box)
→ je suis personellement pas convaincu par l’utilisation des class thickbox, fancybox,nyrobox, trucbox, totobox, demainbox, autrebox… qui amènent une orgie de classe dans les squelettes suceptibles d’être utilisés avec une box. Sans compter qu’à chaque nouveau plugin, il faut recorriger …
Il me semble que l’intérêt de thickbox c’est qu’on l’active et ça marche, sans avoir modifié son squelette. Et qu’on devrait pouvoir utiliser indiférremment thickbox, fancybox ou une autre. Cela milite pour une class générique ou pour garder l’utilisation sur la base des mime type, a l’exception de ceux qui ont une classe nobox, dans ce cas.
Pour la gestion des box sur toutes les images, pourquoi ne pas mettre un rel
au modèle doc/img? Cela permettrait de différencier les différents groupes
d'images. On prendrait soit un identifiant rubrique, soit l'identifiant de
l'article en compte. Bien entendu, on ajoute un suffixe ou préfixe au tout
pour qu'il n'y ait pas de conflit lorsque l'ID_ARTICLE et l'ID_RUBRIQUE sont
identiques...
Les groupes d'images sont définis par un sélecteur, qui par défaut est
"#portfolio img" (ou équivalent), et ça me semble être la bonne
approche.
Pour la gestion des box sur toutes les images, pourquoi ne pas mettre un rel
au modèle doc/img? Cela permettrait de différencier les différents groupes
d'images. On prendrait soit un identifiant rubrique, soit l'identifiant de
l'article en compte. Bien entendu, on ajoute un suffixe ou préfixe au tout
pour qu'il n'y ait pas de conflit lorsque l'ID_ARTICLE et l'ID_RUBRIQUE sont
identiques...
Les groupes d'images sont définis par un sélecteur, qui par défaut est
"#portfolio img" (ou équivalent), et ça me semble être la bonne
approche.
Il faudrait que ce soit utilisable aussi sur des images isolées dans le contenu, pas uniquement dans des portfolios, non ?
Un attribut "class" ou "rel" (valeur à déterminer) directement sur l'image, ou le lien qui l'entoure, serait sans doute plus générique.
Les groupes d'images sont définis par un sélecteur, qui par défaut est
"#portfolio img" (ou équivalent), et ça me semble être la bonne
approche.
Il faudrait que ce soit utilisable aussi sur des images isolées dans le
contenu, pas uniquement dans des portfolios, non ?
Le sélecteur dont on parle prend chaque image du texte comme une image
isolée, et l'ensemble des images du portfolio comme étant un groupe.
Il me semble que c'est la chose la plus logique pour commencer et
faire simple. En ajoutant le .nobox comme bloqueur.
Un attribut "class" ou "rel" (valeur à déterminer) directement sur l'image,
ou le lien qui l'entoure, serait sans doute plus générique.
A partir du moment où tu peux modifier le sélecteur via CFG, c'est
déjà très générique et très amplement suffisant pour une utilisation
classique.
S'il s'agit de décider de "plusieurs galeries mélangées sur une seule
page", on sort totalement du générique, et là il faut que tu ajoutes
une ligne de js à la main pour gérer... et des class et rel à foison
si ça t'amuse.
Dans thickbox 3.1, il n’est pas nécessaire de créer un js spécifique pour chaque nom rel unique… Il le prend en compte automatiquement si je ne m’abuse…
Le 18 juin 2009 15:14, Fil <fil@rezo.net> a écrit :
Les groupes d’images sont définis par un sélecteur, qui par défaut est
« #portfolio img » (ou équivalent), et ça me semble être la bonne
approche.
Il faudrait que ce soit utilisable aussi sur des images isolées dans le
contenu, pas uniquement dans des portfolios, non ?
Le sélecteur dont on parle prend chaque image du texte comme une image
isolée, et l’ensemble des images du portfolio comme étant un groupe.
Il me semble que c’est la chose la plus logique pour commencer et
faire simple. En ajoutant le .nobox comme bloqueur.
Un attribut « class » ou « rel » (valeur à déterminer) directement sur l’image,
ou le lien qui l’entoure, serait sans doute plus générique.
A partir du moment où tu peux modifier le sélecteur via CFG, c’est
déjà très générique et très amplement suffisant pour une utilisation
classique.
S’il s’agit de décider de « plusieurs galeries mélangées sur une seule
page », on sort totalement du générique, et là il faut que tu ajoutes
une ligne de js à la main pour gérer… et des class et rel à foison
si ça t’amuse.
Les groupes d'images sont définis par un sélecteur, qui par défaut est
"#portfolio img" (ou équivalent), et ça me semble être la bonne
approche.
Il faudrait que ce soit utilisable aussi sur des images isolées dans le
contenu, pas uniquement dans des portfolios, non ?
Le sélecteur dont on parle prend chaque image du texte comme une image
isolée, et l'ensemble des images du portfolio comme étant un groupe.
Il me semble que c'est la chose la plus logique pour commencer et
faire simple. En ajoutant le .nobox comme bloqueur.
Il faut juste prévoir dans ce cas la possibilité de passer "nobox" au modèle <doc>.
Un attribut "class" ou "rel" (valeur à déterminer) directement sur l'image,
ou le lien qui l'entoure, serait sans doute plus générique.
A partir du moment où tu peux modifier le sélecteur via CFG, c'est
déjà très générique et très amplement suffisant pour une utilisation
classique.
Effectivement.
S'il s'agit de décider de "plusieurs galeries mélangées sur une seule
page", on sort totalement du générique, et là il faut que tu ajoutes
une ligne de js à la main pour gérer... et des class et rel à foison
si ça t'amuse.
Il faut juste prévoir dans ce cas la possibilité de passer "nobox" au
modèle
<doc>.
Tu veux parler de <doc1|nobox> ?
Oui.
et donc, ça marche déjà...
L'idée est bien d'avoir par défaut un *box sur les vignettes de docs (dont
surtout images, certes), non ?
Non, le sélecteur de "box" c'est "un lien vers une image, sauf les
nobox" ; et le sélecteur de galerie, c'est "les images sélectionnées
précédemment, mais seulement si elles sont dans un div nommé
portfolio".
Autrement dit (et en pseudo code jQuery) : la box s'applique à
$('a[type=image/*]:not(.nobox)') ; et la galerie à $('#portfolio
a[type=image/*]:not(.nobox)')
Il faut juste prévoir dans ce cas la possibilité de passer "nobox" au
modèle
<doc>.
Tu veux parler de <doc1|nobox> ?
Oui.
et donc, ça marche déjà...
Magique. On découvre de nouvelles choses tous les jours...
L'idée est bien d'avoir par défaut un *box sur les vignettes de docs (dont
surtout images, certes), non ?
Non, le sélecteur de "box" c'est "un lien vers une image, sauf les
nobox" ;
Pourquoi seulement les images ? Les *box savent aussi afficher des vidéos, des anims flash, etc.
et le sélecteur de galerie, c'est "les images sélectionnées
précédemment, mais seulement si elles sont dans un div nommé
portfolio".
OK.
Autrement dit (et en pseudo code jQuery) : la box s'applique à
$('a[type=image/*]:not(.nobox)') ; et la galerie à $('#portfolio
a[type=image/*]:not(.nobox)')
C'est plutôt le plugin Lecteur multimédia qui gère ce genre de choses,
puisqu'en général on les embed dans l'article
Avec quasiment toutes les plateformes de partage de vidéos qui proposent maintenant de la HD, l'ouverture dans une *box devient sans doute intéressante.
J’avoue ne pas être totalement convaincu par tous les arguments mais je n’ai peut-être pas compris la portée de la proposition.
Dans mon cas, je laisse à l’opérateur la possibilité d’activer la box qui préfère sur chaque bloc de page comme:
le corps d’un article ou d’une rubrique (modèle img)
le portfolio (noisette)
un album photo (une page plus complexe que le portfolio)
car ce sont des besoins différents qui s’expriment au travers de la consultation de ces blocs.
Ensuite, les box ne proposent pas toutes les mêmes services ce qui ne les rend pas aujourd’hui interchangeables (Thickbox a un diapo auto que les autres n’ont pas).
Tout ceci fait que je pilote l’application d’une box à un bloc par configuration. Dans la proposition de Cedric je n’arrive pas à voir si je vais continuer à avoir cette même flexibilité.
++
Eric
Le 18 juin 2009 14:26, Fil <fil@rezo.net> a écrit :
Il me semble que l’intérêt de thickbox c’est qu’on l’active et ça marche,
sans avoir modifié son squelette. Et qu’on devrait pouvoir utiliser
indiférremment thickbox, fancybox ou une autre. Cela milite pour une class
générique ou pour garder l’utilisation sur la base des mime type, a
l’exception de ceux qui ont une classe nobox, dans ce cas.
Entièrement d’accord avec ces deux points. Il faudrait aussi homogénéiser :
les squelettes de portfolio (actuellement celui de cheznous n’a pas
le même nommage que celui de la dist), de manière à ce que les
galeries se fassent bien sur les deux.
J’avoue ne pas être totalement convaincu par tous les arguments mais je n’ai peut-être pas compris la portée de la proposition.
Dans mon cas, je laisse à l’opérateur la possibilité d’activer la box qui préfère sur chaque bloc de page comme:
le corps d’un article ou d’une rubrique (modèle img)
le portfolio (noisette)
un album photo (une page plus complexe que le portfolio)
car ce sont des besoins différents qui s’expriment au travers de la consultation de ces blocs.
Ensuite, les box ne proposent pas toutes les mêmes services ce qui ne les rend pas aujourd’hui interchangeables (Thickbox a un diapo auto que les autres n’ont pas).
Tout ceci fait que je pilote l’application d’une box à un bloc par configuration. Dans la proposition de Cedric je n’arrive pas à voir si je vais continuer à avoir cette même flexibilité.
++
Eric
Le 18 juin 2009 14:26, Fil <fil@rezo.net> a écrit :
Il me semble que l’intérêt de thickbox c’est qu’on l’active et ça marche,
sans avoir modifié son squelette. Et qu’on devrait pouvoir utiliser
indiférremment thickbox, fancybox ou une autre. Cela milite pour une class
générique ou pour garder l’utilisation sur la base des mime type, a
l’exception de ceux qui ont une classe nobox, dans ce cas.
Entièrement d’accord avec ces deux points. Il faudrait aussi homogénéiser :
les squelettes de portfolio (actuellement celui de cheznous n’a pas
le même nommage que celui de la dist), de manière à ce que les
galeries se fassent bien sur les deux.
J'ai essayé récemment de passer une image svg à thickbox. Ca a complètement bloqué de manière à ce que on soit obligé de fermer FF.
Est-ce que vous avez une idée quel fichier modifier pour faire accetpter les *.svg (et d'autres type de fichier) à thickbox ?
merci, klaus++
Fil schrieb:
Pourquoi seulement les images ?
Parce que c'est ce qu'on a codé jusqu'ici
Les *box savent aussi afficher des vidéos,
des anims flash, etc.
Petite remarque annexe : quand on fait afficher la légende, ce n'est pas gardé en mémoire (alors que ça pourrait pas trop difficilement puisque la page n'est pas rechargée).
Du coup quand il y a vraiment des grosses légendes intéressantes (comme ici sur un site de journalisme), avec un texte qui apporte vraiment des infos, et bien si on veut lire vraiment le texte à chaque fois, il faut re-cliquer sur le bouton pour toutes les photos de la galerie.
Petite remarque annexe : quand on fait afficher la légende, ce n'est pas
gardé en mémoire (alors que ça pourrait pas trop difficilement puisque la
page n'est pas rechargée).
C'est intégré, merci de la suggestion (non pas qu'on n'y avait pas
pensé, mais...)
