depuis 1a903d57b6, la class css-loading est sur le conteneur. Donc en cas d'erreur il faut l'enelever du conteneur, pas du form #2

hop @cerdic. Tout est dans le message de commit.
Pour voir le problème : crayonner en generant une erreur.

Avant ce commit, on ne pouvait pas voir le message d'erreur.

Plutôt alors un

crayon
  .removeClass('crayon-loading')
  ...

non ?

Parce que le principe de 1a903d57b6 c'était justement de plus manipuler en dur les styles mais uniquement la classe, ce qui permet plus facilement de personaliser le rendu des crayons
(et en l'occurence moi je mets aussi du blur sur le loading, pas que de l'opacity)

a oui d'accord. Il restait encore du coup un peu de css en dur pour le erreurs, mais il faudrait précisement le supprimer. Je te refais un PR.

Hum, oui oki.

Bon ca veut dire que je dois sérieusement me mettre au travail autour du versionnement des réponses formidable, sachant que c'est un objet bancale en terme de structure.

non non la fonction xxx_revision n'est pas lié au versionnement mais à la mise à jour. C'est l'ancien nom conventionnel dans spip avant le modifier

Oups, j'avais fermé ceci mais c'était une erreur. Cf. remarque en #8. Cela étant les remarques de @cerdic restent valable, faut nettoyer.

bon je sais pas trop le mic mac avec cette branche et le merge d'alexis, mais j'ai enfin pris le temps de regarder.
C'est fixé avec 72d12ac sachant qu'on ne passait jamais dans ce bout de code a cause d'une typo sur la variable, ce qui est aussi corrigé.

J'en ai profité pour tester/corriger la gestion d'erreur cf caf91eaba6 et 9955b95851

merci :)

Le merge ce n'est pas ce que je voulais faire. Désolé je patauge :(

Merci en tout cas!

depuis 1a903d57b6, la class css-loading est sur le conteneur. Donc en cas d'erreur il faut l'enelever du conteneur, pas du form #2

depuis `1a903d57b6`, la class css-loading est sur le conteneur. Donc en cas d'erreur il faut l'enelever du conteneur, pas du form #2