J’ai des utilisateurs qui modifient mal la syntaxe des citations, ce qui fait échouer la fonction de citation. Par exemple, voici un cas issu d’un sujet actuel. Voici le code non échappé :
[quote=“CFO.Digest.Input, post:1, topic:3258”]
il a suggéré que je remette de l’huile minérale. [/quote]
Le problème est que le /quote se trouve dans le flux, tandis que l’ouverture de la citation est sur sa propre ligne. J’ai constaté que l’on peut faire l’un ou l’autre, mais ils doivent correspondre. Par exemple, cela fonctionne (j’ai ajouté des ’ pour échapper la fonction) :
'[quote=“CFO.Digest.Input, post:1, topic:3258”]
il a suggéré que je remette de l’huile minérale.
'[/quote]
et cela fonctionne aussi :
'[quote=“CFO.Digest.Input, post:1, topic:3258”]il a suggéré que je remette de l’huile minérale.[/quote]
… mais on ne peut pas mélanger les modes.
Je sais que quelqu’un dira « alors ne faites pas ça » ou « utilisez le bouton de citation », mais nous avons toujours des utilisateurs qui ne le font pas correctement.
N’y a-t-il pas un moyen de parser cela afin que les modes puissent être mélangés ?
Oh mon Dieu… alors on impose essentiellement des normes de codage à nos clients et utilisateurs ?
Bien que je sois d’accord avec l’analyse de Sam concernant le format, il y a une différence entre rendre le texte difficile à lire pour l’auteur et le rendre difficile à lire pour tous ceux qui consultent le message. On dirait presque qu’on pénalise les lecteurs pour les erreurs de l’auteur…
Je vais donc continuer à éditer les messages lorsque les gens les gâchent.
Edit : Une autre option serait d’ajouter automatiquement un saut de ligne après [/quote] s’il n’y en a pas déjà un… corriger automatiquement le format pour améliorer la lisibilité.
Ce n’est pas une mauvaise idée, mais si les utilisateurs sélectionnent simplement du texte et utilisent le bouton de citation, cela fonctionne. Est-ce qu’ils retournent éditer la citation et cassent ainsi la mise en forme ?
Oui, ils le sont ! Vraiment tout à fait remarquable… et sans même remarquer qu’ils cassent le format en cours de route. Je suppose qu’ils n’ont pas l’aperçu activé ? Ou peut-être le font-ils depuis un mobile…
Et la personne qui a fait ça, l’un des principes de l’entreprise… heureusement que je ne l’ai pas nommé éditeur !
Aha ! Mobile est un bon choix. C’est difficile de sélectionner exactement ce qu’il faut, et vous risqueriez d’être maladroit sans avoir d’aperçu lorsque vous essayez de le « corriger ».
J’ai édité le message en ajoutant un retour chariot après la balise de fin de citation, mais il me semble toujours surprenant que le flux de texte ne soit pas analysé comme du HTML, où les sauts de ligne et les retours chariot n’affectent pas le fonctionnement des balises. Cela me semble être un bug…
Non, c’est ainsi que fonctionnent les balises. Vous ne pouvez pas les insérer au hasard dans un ordre aléatoire et vous attendre à ce que cela fonctionne.
L’ordre n’est pas aléatoire, il est tout à fait correct. Mais contrairement au HTML, dans ce système, l’emplacement des sauts de ligne a de l’importance.
Tout ce qu’il a fallu pour réparer ce message cassé, c’est d’ajouter un saut de ligne / CR après la balise de fermeture.
Je suis prêt à continuer à éditer manuellement les messages lorsque les utilisateurs ne respectent pas la structure requise, mais il semble toujours étrange que les sauts de ligne aient de l’importance pour l’analyseur…
Jetez un œil à la spécification Markdown. Contrairement au HTML, Markdown dépend entièrement des sauts de ligne bien placés.
Un saut de ligne erroné dans un élément <h1> n’aurait aucun impact sur le rendu, mais :
ici dans le monde
Markdown cela compte
C’est vrai pour de nombreux éléments : les tableaux Markdown sont horriblement cassés par des sauts de ligne supplémentaires. Les tableaux HTML, en revanche, ne le sont pas.
Je ne suis pas sûr que l’analogie avec le HTML soit pertinente ou utile. On ne demande pas aux utilisateurs d’écrire du HTML. Pouvez-vous imaginer la douleur de manquer des balises <p></p> et <br> ? Des murs de texte littéraux.
Si vous pensez « Markdown d’abord », ce qu’est Discourse, plutôt que « HTML d’abord », ce que Discourse n’est absolument pas, alors les défis posés par l’ajout de balises sans respecter la structure commencent à avoir du sens.
Je n’ai aucun problème à naviguer dans ces eaux, comme tout développeur, mais nos utilisateurs sont des civils et penseraient que le markdown a quelque chose à voir avec les prix chez Walmart.
Comme tu le dis, heureusement, nous ne leur demandons pas d’écrire du HTML ! Qu’est-ce que l’on gagne à les obliger à implémenter le formatage markdown ? Il semblerait qu’un peu de bon sens en matière de code les protégerait de ces réalités de notre monde.
Je ne sais pas à quel point il serait compliqué de forcer automatiquement un saut de ligne après un [/quote] (tant qu’il ne se trouve pas dans un bloc de code ou quelque chose de similaire…) et je comprends qu’il y ait une structure à respecter lors de l’utilisation du markdown.
Mais je comprends aussi à quel point cela peut être frustrant lorsqu’une citation mal formée apparaît dans un message utilisateur à cause d’une si petite « erreur » qu’est le fait d’écrire du texte sur la même ligne qu’un [/quote] (je ne suis pas sûr de pouvoir appeler cela une erreur).
Y a-t-il un cas intentionnel où du texte serait écrit sur la même ligne qu’un [quote] ?
S’il n’y en a aucun, alors je pense qu’il n’y a aucune raison pour qu’un texte existe sur la même ligne, et un saut de ligne forcé après la balise de fermeture de la citation pourrait être bénéfique à la fois pour les utilisateurs et le personnel. Mais je suis aussi certain que ce n’est pas aussi simple que cela en a l’air.
Exactement. La nature fondamentale du Markdown est qu’un saut de ligne (ou deux sauts de ligne) équivaut à une balise de paragraphe. Pour cette raison, certaines balises nécessitent des sauts de ligne avant ou après elles pour être correctement interprétées. C’est, je crois, une partie de la spécification.
