J'ai déjà posté ce message, mais personne n'a réagi : faut-il en conclure que
qui ne dit mot consent ?
Par contre, même si c'est le cas, puis-je commiter sur spip avec mon compte
spip-dev de developpeur de plugin ???
Le problème :
Quand on recharge un bloc ajax, il est automatiquement scrollé s'il n'est pas
entièrement visible. Dans certains cas, celà peut être très gênant.
Cette modification proposée ne change pas le fonctionnement actuel.
Questions :
- pas d'objections ?
- le nom de la classe pour ne pas scroller est il ok ?
- ok pour commiter ?
- qui peut commiter ?
Le Friday 15 October 2010 14:25:13 Martin Arnaud, vous avez écrit :
Pas d'accord. Je trouve la solution pas bonne du tout: ça consiste à
ajouter du code HTML extérieur à une balise SPIP pour modifier le
comportement de cette balise.
Arnaud
OK. As-tu une meilleure idee à proposer pour resoudre le problème ?
- Ajouter dans la balise <INCLURE{fond=montruxajaxifie}{ajax}> un truc genre
<INCLURE{fond=montruxajaxifie}{ajax}{noscroll}> ou
<INCLURE{fond=montruxajaxifie}{ajax_noscroll}> ? (avec ce genre de syntaxe,
c'est la façon d'interpréter {ajax} qui devrait être changée : la modif
serait plus lourde)
Le Friday 15 October 2010 14:25:13 Martin Arnaud, vous avez écrit :
Pas d'accord. Je trouve la solution pas bonne du tout: ça consiste à
ajouter du code HTML extérieur à une balise SPIP pour modifier le
comportement de cette balise.
Arnaud
Pourtant c'est ce qu'on fait par exemple pour rendre un formulaire CVT ajaxable. On met du HTML autour de la balise.
<div class="ajax"> #FORMULAIRE_TRUC
</div>
Là c'est exactement le même principe :
<div class="noscroll">
<INCLURE{fond=truc}{ajax}>
</div>
Par ailleurs, ici ce n'est même pas le comportement de la balise qu'on veut changer (comme pour le CVT) : au final quand on met {ajax}, ça fait *effectivement* de l'ajax. Il n'y a aucune différence sur la fonctionnalité {ajax}.
Cette proposition modifie le comportement tout à la fin qui fait que ça scroll obligatoirement, c'est-à-dire un comportement *d'affichage*. Et pour modifier un comportement d'affichage, ça me parait pas aberrant d'utiliser des classes CSS.
Le Friday 15 October 2010 14:25:13 Martin Arnaud, vous avez écrit :
Pas d'accord. Je trouve la solution pas bonne du tout: ça consiste à
ajouter du code HTML extérieur à une balise SPIP pour modifier le
comportement de cette balise.
Arnaud
Pourtant c'est ce qu'on fait par exemple pour rendre un formulaire CVT ajaxable. On met du HTML autour de la balise.
<div class="ajax"> #FORMULAIRE_TRUC
</div>
On peut, mais pas nécessairement (le div a pu etre mis dans la balise).
Là c'est exactement le même principe :
<div class="noscroll">
<INCLURE{fond=truc}{ajax}>
</div>
Et justement, il ne s'agit pas de mélanger les deux méthode :
Si on pilote l'ajax d'une inclusion par un argument ET par un div englobant qui font chacun une chose, c'est *incohérent*.
Patrick Stewart n'aimerai pas du tout.
Par ailleurs, ici ce n'est même pas le comportement de la balise qu'on veut changer (comme pour le CVT) : au final quand on met {ajax}, ça fait *effectivement* de l'ajax. Il n'y a aucune différence sur la fonctionnalité {ajax}.
Cette proposition modifie le comportement tout à la fin qui fait que ça scroll obligatoirement, c'est-à-dire un comportement *d'affichage*. Et pour modifier un comportement d'affichage, ça me parait pas aberrant d'utiliser des classes CSS.
Je n'aime pas trop. En particulier, cela suppose de remonter dans la chaine des parents, car la classe n'est pas forcément sur le div le plus proche.