Hop,
Le 11/05/2016 10:02, p@henix.be a écrit :
Log:
Pouvoir forcer l'utilisation des tag SPIP 3 via la constante _SAISIE_TAG_3Details: Connexion · GitLab
Je comprends pas pourquoi il faut un define pour focer l'usage des li dans SPIP 3.1, peux-tu m'éclairer sur la raison de cet ajout (et le besoin) ?
++
b_b
Le 11/05/2016 13:54, Bruno Bergot a écrit :
Je comprends pas pourquoi il faut un define pour focer l'usage des li
dans SPIP 3.1, peux-tu m'éclairer sur la raison de cet ajout (et le
besoin) ?
Oui, sauf truc vraiment impératif, ça serait bien de pas trop ajouter de multiples exceptions, ça fait du code en plus à maintenir, c'est moins lisible, et ça fait plein de "petites merdouilles" qu'on va se trainer ensuite.
--
RastaPopoulos
Hello,
La raison est assez simple : j'ai un site avec des formulaires (un poil
complexes) coté publique dont le css est construit sur le modèle ul>li.
Il est passé en 3.1 et tout les formulaires on logiquement cassé.
Comme il n'y a pas de moyen simple pour forcer Saisies à produire du
code compatible, je l'ai crée.
Peut être que je devrait limiter l'impact de cette constante à l'espace
publique afin de ne pas perturber les formulaires de l'espace privé ?
++
Le 11/05/16 13:54, Bruno Bergot a écrit :
Hop,
Le 11/05/2016 10:02, p@henix.be a écrit :
Log:
Pouvoir forcer l'utilisation des tag SPIP 3 via la constante
_SAISIE_TAG_3Details: Connexion · GitLab
Je comprends pas pourquoi il faut un define pour focer l'usage des li
dans SPIP 3.1, peux-tu m'éclairer sur la raison de cet ajout (et le
besoin) ?++
b_b
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 11 mai 2016 à 14:51, Phenix <p@henix.be> a écrit :
Hello,
La raison est assez simple : j'ai un site avec des formulaires (un poil
complexes) coté publique dont le css est construit sur le modèle ul>li.
Il est passé en 3.1 et tout les formulaires on logiquement cassé.
Comme il n'y a pas de moyen simple pour forcer Saisies à produire du code
compatible, je l'ai crée.
Une petite question en lisant ce que tu écris, pourquoi est-ce à Saisies de
fournir un code compatible ? (c'est une vraie question hein)
Compatible à quoi ?
Peut être que je devrait limiter l'impact de cette constante à l'espace
publique afin de ne pas perturber les formulaires de l'espace privé ?
Tes formulaires sont cassés par rapport à quoi ? La css ? Le javascript ?
Tu fais une css par balise ? Ou par class ?
Ces questions sont pour comprendre ton besoin initial.
Amicalement,
Ybbet.
++
Le 11/05/16 13:54, Bruno Bergot a écrit :
Hop,
Le 11/05/2016 10:02, p@henix.be a écrit :
Log:
Pouvoir forcer l'utilisation des tag SPIP 3 via la constante _SAISIE_TAG_3Details: Connexion · GitLab
Je comprends pas pourquoi il faut un define pour focer l'usage des li dans
SPIP 3.1, peux-tu m'éclairer sur la raison de cet ajout (et le besoin) ?++
b_b
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Hello,
Une petite question en lisant ce que tu écris, pourquoi est-ce à
Saisies de fournir un code compatible ? (c'est une vraie question hein)
Saisies fournissait du code compatible avant spip 3.1 et puis n'en
fourni plus.
On a donc un problème de rétro-compatibilité avec les formulaires SPIP
3.0 (coté publique, sur du CSS maison).
Compatible à quoi ?
Comme dit plus haut : avec le css construit sur base des balise ul>li de
SPIP 3.0.
Tes formulaires sont cassés par rapport à quoi ? La css ? Le javascript ?
Tu fais une css par balise ? Ou par class ?
En l’occurrence c'est la CSS, mais on peut imaginer des problèmes
javascripts aussi.
Ces questions sont pour comprendre ton besoin initial.
Mon besoin est assez simple : faire que le CSS des formulaires construit
autour de l'ancienne structure ul>li fonctionne aussi en 3.1.
Assurer la rétro-compatibilité est un des points forts de SPIP, je pense
que mon commit va dans ce sens. Après comme je l'ai dit, il faudrait
sans doute limité l’influence de la constante à l'espace publique.
++
Le 11/05/16 15:10, Ybbet Spip a écrit :
Le 11 mai 2016 à 14:51, Phenix <p@henix.be <mailto:p@henix.be>> a écrit :
Hello,
La raison est assez simple : j'ai un site avec des formulaires (un
poil complexes) coté publique dont le css est construit sur le
modèle ul>li.
Il est passé en 3.1 et tout les formulaires on logiquement cassé.Comme il n'y a pas de moyen simple pour forcer Saisies à produire
du code compatible, je l'ai crée.Une petite question en lisant ce que tu écris, pourquoi est-ce à
Saisies de fournir un code compatible ? (c'est une vraie question hein)
Compatible à quoi ?Peut être que je devrait limiter l'impact de cette constante à
l'espace publique afin de ne pas perturber les formulaires de
l'espace privé ?Tes formulaires sont cassés par rapport à quoi ? La css ? Le javascript ?
Tu fais une css par balise ? Ou par class ?Ces questions sont pour comprendre ton besoin initial.
Amicalement,
Ybbet.
++
Le 11/05/16 13:54, Bruno Bergot a écrit :
Hop,
Le 11/05/2016 10:02, p@henix.be <mailto:p@henix.be> a écrit :
Log:
Pouvoir forcer l'utilisation des tag SPIP 3 via la constante
_SAISIE_TAG_3Details: Connexion · GitLab
Je comprends pas pourquoi il faut un define pour focer l'usage
des li dans SPIP 3.1, peux-tu m'éclairer sur la raison de cet
ajout (et le besoin) ?++
b_b
----
spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
http://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
http://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 11 mai 2016 à 15:23, Phenix <p@henix.be> a écrit :
Hello,
Une petite question en lisant ce que tu écris, pourquoi est-ce à Saisies
de fournir un code compatible ? (c'est une vraie question hein)Saisies fournissait du code compatible avant spip 3.1 et puis n'en fourni
plus.
On a donc un problème de rétro-compatibilité avec les formulaires SPIP 3.0
(coté publique, sur du CSS maison).Compatible à quoi ?
Comme dit plus haut : avec le css construit sur base des balise ul>li de
SPIP 3.0.
Je n'ai pas de code #SAISIE sous SPIP 3.0 sous la main… Est-ce qu'il n'y
avait pas de class généré ?
J'avais la même problématique récemment avec info_sites. Et "naturellement"
dans mes développements, je suis passé avec une class sur mes formulaires…
tout en gardant les ul>li
cf.
Tes formulaires sont cassés par rapport à quoi ? La css ? Le javascript ?
Tu fais une css par balise ? Ou par class ?En l’occurrence c'est la CSS, mais on peut imaginer des problèmes
javascripts aussi.Ces questions sont pour comprendre ton besoin initial.
Mon besoin est assez simple : faire que le CSS des formulaires construit
autour de l'ancienne structure ul>li fonctionne aussi en 3.1.Assurer la rétro-compatibilité est un des points forts de SPIP, je pense
que mon commit va dans ce sens. Après comme je l'ai dit, il faudrait sans
doute limité l’influence de la constante à l'espace publique.
ok 
++
Le 11/05/16 15:10, Ybbet Spip a écrit :
Le 11 mai 2016 à 14:51, Phenix <p@henix.be> a écrit :
Hello,
La raison est assez simple : j'ai un site avec des formulaires (un poil
complexes) coté publique dont le css est construit sur le modèle ul>li.
Il est passé en 3.1 et tout les formulaires on logiquement cassé.Comme il n'y a pas de moyen simple pour forcer Saisies à produire du code
compatible, je l'ai crée.
Une petite question en lisant ce que tu écris, pourquoi est-ce à Saisies
de fournir un code compatible ? (c'est une vraie question hein)
Compatible à quoi ?Peut être que je devrait limiter l'impact de cette constante à l'espace
publique afin de ne pas perturber les formulaires de l'espace privé ?Tes formulaires sont cassés par rapport à quoi ? La css ? Le javascript ?
Tu fais une css par balise ? Ou par class ?Ces questions sont pour comprendre ton besoin initial.
Amicalement,
Ybbet.
++
Le 11/05/16 13:54, Bruno Bergot a écrit :
Hop,
Le 11/05/2016 10:02, p@henix.be a écrit :
Log:
Pouvoir forcer l'utilisation des tag SPIP 3 via la constante
_SAISIE_TAG_3Details: Connexion · GitLab
Je comprends pas pourquoi il faut un define pour focer l'usage des li
dans SPIP 3.1, peux-tu m'éclairer sur la raison de cet ajout (et le besoin)
?++
b_b
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone----spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 11/05/2016 à 14:51, Phenix a écrit :
Hello,
La raison est assez simple : j'ai un site avec des formulaires (un poil
complexes) coté publique dont le css est construit sur le modèle ul>li.
Il est passé en 3.1 et tout les formulaires on logiquement cassé.
Certes, mais du coup, c'est pareil pour tous les formulaires de SPIP qui seraient utilisés dans l'espace public par ton site.
Il me semble que ce n'est pas "Saisies" à contraindre, mais le CSS utilisé qui devrait pouvoir comprendre la nouvelle structure HTML.
Comme il n'y a pas de moyen simple pour forcer Saisies à produire du
code compatible, je l'ai crée.
Peut être que je devrait limiter l'impact de cette constante à l'espace
publique afin de ne pas perturber les formulaires de l'espace privé ?
On ne peut pas, je crois bien, sans créer 2 caches de squelettes différents (avec la globale marqueur_skel) que n'utilise pas saisies actuellement.
Mais bon, du coup activer cette constante va casser tout autant tous les plugins qui s'attendent à avoir une certaine structure HTML pour les formulaires, les javascript particulièrement.
Il me semble que la modification des formulaires de ul > li à div.editer-groupe > div.editer est un des changements connus du passage de 3.0 à 3.1 et que bon… j'aurais plutôt dit que ça fait partie des choses à adapter dans les plugins et squelettes utilisés pour les rendre mieux compatibles. (J'admets que c'est chiant, et que ça a déjà agacé plein de monde de modifier les plugins de la zone), mais c'est pas non plus extrêmement difficile de re-cibler les CSS et JS sur d'autres balises / classes.
Sinon, tu as une autre solution locale, c'est de définir, pour toi, dans ton mes_options le filtre_saisie_balise_structure_formulaire(), qui prendra le pas sur celui du plugin ; c'est peut être une solution pour ne pas ennuyer le plugin ?
MM.
Le 11/05/2016 15:54, Matthieu Marcillaud a écrit :
Il me semble que la modification des formulaires de ul > li à
div.editer-groupe > div.editer est un des changements connus du passage
de 3.0 à 3.1 et que bon… j'aurais plutôt dit que ça fait partie des
choses à adapter dans les plugins et squelettes utilisés pour les rendre
mieux compatibles.
Voilà.
Ce changement de structure on le connait depuis déjà les bétas. C'est documenté, et ça vaut pour absolument tous les formulaires générés.
Donc un site qui décide en connaissance de cause de passer en 3.1 depuis 3.0, ça me parait pas immensément à côté de la plaque que ce soit à lui de modifier ses CSS et JS pour prendre en compte la nouvelle structure des formulaires.
(Surtout que c'est une mauvaise pratique de se baser sur des balises, et non sur les classes, et il y avait déjà des classes avant.)
Et sinon, la fonction de génération de la structure est effectivement surchargeable oui, donc pour un besoin extrêmement rare (= une personne qui ne voudrait absolument pas changer ses CSS mal conçue :D), la personne peut surcharger pour son site précis.
--
RastaPopoulos
Attention.
Il n'a jamais été dit que la structure en DIV était obligatoire et qu'on ne pouvait plus utiliser les ul/li.
Ce qui a été dit c'est : la structure en div est plus accessible, on la recommande, elle est utilisée par défaut dans les formulaires de SPIP en 3.1, et dans le plugin SAISIES.
Mais la structure en ul/li reste licite, et on préconise d'utiliser les classes .editer-groupe et .editer pour styler les formulaires ou manipuler en JS indépendamment des balises HTML retenues pour structurer les formulaires.
--
Cédric
RastaPopoulos a écrit :
Le 11/05/2016 15:54, Matthieu Marcillaud a écrit :
Il me semble que la modification des formulaires de ul > li à
div.editer-groupe > div.editer est un des changements connus du passage
de 3.0 à 3.1 et que bon… j'aurais plutôt dit que ça fait partie des
choses à adapter dans les plugins et squelettes utilisés pour les rendre
mieux compatibles.Voilà.
Ce changement de structure on le connait depuis déjà les bétas. C'est
documenté, et ça vaut pour absolument tous les formulaires générés.Donc un site qui décide en connaissance de cause de passer en 3.1 depuis
3.0, ça me parait pas immensément à côté de la plaque que ce soit à lui
de modifier ses CSS et JS pour prendre en compte la nouvelle structure
des formulaires.(Surtout que c'est une mauvaise pratique de se baser sur des balises, et
non sur les classes, et il y avait déjà des classes avant.)Et sinon, la fonction de génération de la structure est effectivement
surchargeable oui, donc pour un besoin extrêmement rare (= une personne
qui ne voudrait absolument pas changer ses CSS mal conçue :D), la
personne peut surcharger pour son site précis.
Le 11/05/2016 20:08, Cédric Morin a écrit :
Il n'a jamais été dit que la structure en DIV était obligatoire et qu'on
ne pouvait plus utiliser les ul/li.
Bah oui, mais justement Saisies génère la structure recommandée officiellement. Ce n'est à mon avis pas au plugin de gérer les cas particuliers de gens qui veulent absolument continuer d'avoir une autre structure que celle recommandé (surtout pour cause de CSS assez facile à corriger).
Et du coup pour ça ya la surcharge de la fonction. Chez les gens, donc, pas dans le plugin.
--
RastaPopoulos
Hello,
Certes, mais du coup, c’est pareil pour tous les formulaires de SPIP qui seraient utilisés dans l’espace public par ton site.
Ce n’est pas grave puisque la css s’applique correctement. Je veux justement que tout les formulaires publiques utilisent ul>li.
Il me semble que ce n’est pas « Saisies » à contraindre, mais le CSS utilisé qui devrait pouvoir comprendre la nouvelle structure HTML.
Je ne suis pas trop d’accord avec ce raisonnement : un squelette devrait fonctionner, peut importe la version de SPIP.
Un plugin c’est une autre histoire, mais un squelette qui ne ce base que sur le langage SPIP n’a aucune raison de ne pas fonctionner sur toutes les versions (hors syntaxte spécifique à certaine version de SPIP).
On ne peut pas, je crois bien, sans créer 2 caches de squelettes différents (avec la globale marqueur_skel) que n’utilise pas saisies actuellement.
Je pensais simplement ajouter un test_espace_prive dans le if du test de la contante. J’ignore les implications que cela à sur le cache.
Mais bon, du coup activer cette constante va casser tout autant tous les plugins qui s’attendent à avoir une certaine structure HTML pour les formulaires, les javascript particulièrement.
Dans le cas qui m’occupe, ce n’est pas le cas. Normalement les plugins ce base sur les class justement, donc il ne devrait pas avoir de problème a utiliser aussi bien ul>li que div.
Il me semble que la modification des formulaires de ul > li à div.editer-groupe > div.editer est un des changements connus du passage de 3.0 à 3.1 et que bon… j’aurais plutôt dit que ça fait partie des choses à adapter dans les plugins et squelettes utilisés pour les rendre mieux compatibles. (J’admets que c’est chiant, et que ça a déjà agacé plein de monde de modifier les plugins de la zone), mais c’est pas non plus extrêmement difficile de re-cibler les CSS et JS sur d’autres balises / classes.
Dans le cas d’un plugin, je suis d’accord.
Mais avoir une solution pour faire fonctionner les anciens squelettes me semble être une bonne chose. On code sur le nouveau et on reste compatible avec l’ancien.
Sinon, tu as une autre solution locale, c’est de définir, pour toi, dans ton mes_options le filtre_saisie_balise_structure_formulaire(), qui prendra le pas sur celui du plugin ; c’est peut être une solution pour ne pas ennuyer le plugin ?
Effectivement, je pourrai. Comme ce n’est pas une fonction _dist, je n’ai pas pensé à surchargé via filtre_.
Hello,
(Surtout que c’est une mauvaise pratique de se baser sur des balises, et non sur les classes, et il y avait déjà des classes avant.)
Je ne vois pas pour que ce serai plus une mauvaise pratique de ce baser sur les class plutôt que sur les balises.
Les pratiques sont des choses qui évolue dans le temps, il est souvent difficile de prévoir à l’avance ce qui est une bonne pratique et ce qui n’en est pas une.
Ici le squelette est assez ancien et à l’époque personne ne disait que c’était une mauvaise pratique de ce baser sur les balises, car elles ont autant de chance de changer que les class.
Demain, les float seront une mauvaise pratique parce qu’on aura les flex-box, ce n’est pas pour autant que les navigateurs vont casser tout les sites qui utilisent des float.
Et sinon, la fonction de génération de la structure est effectivement surchargeable oui, donc pour un besoin extrêmement rare (= une personne qui ne voudrait absolument pas changer ses CSS mal conçue :D), la personne peut surcharger pour son site précis.
Comme dit plus haut, le css n’est pas mal concue, juste d’une autre époque. Il n’en reste pas moins valable.
Comme dit d’en mon autre mail : la fonction n’étant pas une filtre_..._dist, je n’ai pas pensé à la surchargée.