Hello...
Je suis en train d'essayer de comprendre comment utiliser markitup d'une manière simple et précise... et me vient 2/3 questions :
- Pourquoi avoir enlevé les classes génériques barre_inserer par exemple dans ce commit http://trac.rezo.net/trac/spip/changeset/13433 qui représente un bon "point d'accrochage" pour la barre typo au profit d'un ciblage restreint sur textarea[name=texte] ? Cela entraine la nécessité de rajouter du js pour les textareas dont le name n'est pas texte ... alors qu'ajouter une class barre_inserer est beaucoup plus simple à comprendre...
Donc cibler la class me semble plus simple en terme de pérennité... ca permettra aussi notamment de refaire le plugin barre_typo généalisée en 2 coups de cuillère à pot...
- Pourquoi ne pas mettre la fonction barrebouille dans un js externe ... puisqu'elle est sur chaque page par insert_head... cela permettrait de pouvoir la surcharger comme on veut ...
Bref ... j'arrête là mes investigations jusqu'à une réponse à ce sujet...
Car je suppose que cela a été discuté... donc je ne prendrai pas l'initiative de modifier le core et le plugin avant une réponse positive...
++
kent1
Drouet Quentin a écrit :
Hello...
- Pourquoi avoir enlevé les classes génériques barre_inserer par exemple dans ce commit http://trac.rezo.net/trac/spip/changeset/13433 qui représente un bon "point d'accrochage" pour la barre typo au profit d'un ciblage restreint sur textarea[name=texte] ? Cela entraine la nécessité de rajouter du js pour les textareas dont le name n'est pas texte ... alors qu'ajouter une class barre_inserer est beaucoup plus simple à comprendre...
Simplement, dans le premier cas, tu dois surcharger le HTML pour ajouter la barre, dans le second, tu vises simplement les éléments que tu souhaites, en l'occurrence "textarea[name=texte]" correspond aux formulaires qui avaient une barre typo par défaut dans le core de SPIP
Donc cibler la class me semble plus simple en terme de pérennité... ca permettra aussi notamment de refaire le plugin barre_typo généalisée en 2 coups de cuillère à pot...
Je ne vois vraiment pas ce que change l'un par rapport à l'autre ? si ce n'est que tu vas être obligé pour ta solution d'ajouter des classes "barre_inserer" partout ? Peut être peux tu développer en quoi ce sera plus simple ?
- Pourquoi ne pas mettre la fonction barrebouille dans un js externe ... puisqu'elle est sur chaque page par insert_head... cela permettrait de pouvoir la surcharger comme on veut ...
Bonne idée.
Car je suppose que cela a été discuté... donc je ne prendrai pas l'initiative de modifier le core et le plugin avant une réponse positive...
Non, il n'y a eu aucune discussion sur ces points précis si je me souviens bien.
--
MM.
Drouet Quentin a écrit :
Hello...
- Pourquoi avoir enlevé les classes génériques barre_inserer par exemple dans ce commit http://trac.rezo.net/trac/spip/changeset/13433 qui représente un bon "point d'accrochage" pour la barre typo au profit d'un ciblage restreint sur textarea[name=texte] ? Cela entraine la nécessité de rajouter du js pour les textareas dont le name n'est pas texte ... alors qu'ajouter une class barre_inserer est beaucoup plus simple à comprendre...
Simplement, dans le premier cas, tu dois surcharger le HTML pour ajouter la barre, dans le second, tu vises simplement les éléments que tu souhaites, en l'occurrence "textarea[name=texte]" correspond aux formulaires qui avaient une barre typo par défaut dans le core de SPIP
Donc cibler la class me semble plus simple en terme de pérennité... ca permettra aussi notamment de refaire le plugin barre_typo généalisée en 2 coups de cuillère à pot...
Je ne vois vraiment pas ce que change l'un par rapport à l'autre ? si ce n'est que tu vas être obligé pour ta solution d'ajouter des classes "barre_inserer" partout ? Peut être peux tu développer en quoi ce sera plus simple ?
- Pourquoi ne pas mettre la fonction barrebouille dans un js externe ... puisqu'elle est sur chaque page par insert_head... cela permettrait de pouvoir la surcharger comme on veut ...
Bonne idée.
Car je suppose que cela a été discuté... donc je ne prendrai pas l'initiative de modifier le core et le plugin avant une réponse positive...
Non, il n'y a eu aucune discussion sur ces points précis si je me souviens bien.
--
MM.