Re: Fancybox pour une mise a jour de la mediabox ?

Merci Placido,

je vais regarder en détail, car c’était vraiment l’esprit du plugin mediabox d’avoir une surcouche api pour permettre de changer de box dans le futur sans casser tous les plugins et squelettes.

Je pense qu’il faut sans doute faire quelque chose d’intermédiaire :
- avoir le plugin mediabox dans le core avec une api claire, comme tu as fait
- mais qu’il intègre par défaut une box dans un sous dossier ; du coup peut-être pas fancybox en effet, le choix d’une box très light pour le core est peut-être pas idiot
- et qu’on puisse choisir ensuite une autre box facilement en activant un plugin qui necessitera mediabox et viendra prendre la place de la box par defaut

Mais on peut sans doute faire quelques choix de simplification :
- Je pense pas qu’il faille trop compliquer en essayant d’avoir plusieurs boxs qui s'activent d’un coup. Amha il faut que le mecanisme permette d’activer une box ou une autre, mais une seule sera dispo à la fois, et donc configurable etc
- sur la possibilité d’avoir des js et css dynamiques en squelette, je suis un peu réservé, j’aime vraiment pas trop ça et en terme de perf c’est vraiment pas génial

Et les plugins qui ont utilisé directement l’api colorbox au lieu de mediabox devront de débrouiller pour s’adapter, c’est une erreur de leur part :)
(y compris SVP !)

(peut-être que pour éviter trop de casse on ajoutera quelques classes historiques issues de colorbox ?)

En tout cas la version 3.3 de SPIP parait le bon moment pour changer : il faut faire ça sur une montée de version car il y aura un peu de casse quand même, et je pense pas qu’il soit une bonne idée d’embarquer colorbox quelques années de plus

--
Cédric
Le 11 sept. 2020 à 13:08 +0200, [email protected], a écrit :
> J'ai planché il y a quelques temps sur la mise en place d'une mediabox
> alternative, car je trouvais moi aussi la colorbox un peu trop "rigide"
> sur mobile.
>
> Du coup, je suis allé un peu plus loin dans la tentative de faire de
> mediabox une API, sur laquelle on pourrait brancher indifferement
> plusieurs libs.
>
> Du coup on a un découpage comme ceci:
> [core]
> https://framagit.org/cantal-tech/cantal-tech-spip/mediabox
>
> [colorbox]
> https://framagit.org/cantal-tech/cantal-tech-spip/colorbox
>
> [featherlight]
> https://framagit.org/cantal-tech/cantal-tech-spip/featherlight
>
> Les briques sont en place pour connecter d'autres lib, j'avais même fait
> un test avec fancybox (pas publié cependant).
>
> Ç'est fonctionnel en partie privé et publique, et même en prod sur
> quelques sites, mais reste quelques soucis ;
>
> A) la méthode de déploiement est un peu alambiquée, car il faut
> surcharger un plugin-dist, et, sur ce point, SVP est un peu retord. De
> plus, dans la gestion de dépendances actuelle, on ne peut pas spécifier
> que mediabox a besoin d'AU MOINS UNE lib tierce pour fonctionner (mais
> c'est un problème propre à mediabox).
>
> B) Quelques problèmes d'appels à colorbox en dur dans le core
> (https://core.spip.net/issues/4183), ou code js/CSS trop spécifiques sur
> d'autres plugins (inserer_modeles de mémoire).
>
> C) L'organisation du formulaire de configuration de la modale box ; les
> sous-plugins peuvent y insèrer leur propres préférences, (ex: une
> couleur de fond et une opacité pour featherlight) ; Faut-il garder une
> seule configuration générale, ou bien cloisonner chaque configuration
> par en fonction de la lib choisie ?)
>
>
> Avec le recul, assurer un comportement consistant avec plusieurs libs,
> pour l'ensemble de l'eco-système de plugins SPIP me parait illusoir.
>
> Mais adopter un nouvelle lib par défaut, j'acquièce.
> Fancybox est vraiment jolie, quoique un peu gloutone ; et l'ambiguité
> sur la licence associée m'avait finalement reporté sur featherlight.
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip