Le nouvel éditeur WYSIWYG tente de représenter exactement ce qui sera rendu dans le message réel, mais dans ce cas précis, il le fait trop bien. En bref, lorsque vous écrivez un message avec une section « Masquer les détails », vous voulez généralement qu’elle soit fermée par défaut (c’est pour masquer les détails, après tout). Cependant, lorsque vous écrivez/révisez votre brouillon, vous aurez naturellement la section Masquer les détails ouverte afin de pouvoir voir le texte qu’elle contient. Le problème est que cela publie la section Masquer les détails dans l’état ouvert, de sorte qu’elle est ouverte par défaut. Honnêtement, je ne savais même pas que vous pouviez la rendre ouverte par défaut et cela semble très contre-intuitif par rapport à la façon dont la plupart des utilisateurs voudraient que la section soit rendue.
Étapes pour reproduire :
Démarrer un nouveau brouillon en mode RTE
Créer une nouvelle section « Masquer les détails »
Ouvrir la section « Masquer les détails »
Créer le message
Attendu : Dans le message, la section « Masquer les détails » devrait être fermée par défaut, car cela correspond à des années d’attentes de l’éditeur Markdown.
Réel : La section « Masquer les détails » est ouverte par défaut.
Lorsque vous écrivez, vous pouvez l’ouvrir et la fermer de toute façon, donc oui, je disais juste que le dernier message devrait être fermé par défaut.
Comment créer des détails ouverts avec l’éditeur WYSIWYG si ce n’est pas en les laissant ouverts avant de publier ? N’est-ce pas que les détails ouverts lorsqu’ils étaient ouverts avant la publication sont exactement cela ? On obtient ce que l’on voit.
Oui, vous obtenez ce que vous voyez. Et je dis que dans ce cas, obtenir ce que vous voyez est contre-intuitif et va à l’encontre de l’objectif d’une section masquer les détails. S’attendre à ce que l’utilisateur ferme manuellement chaque section Masquer les détails avant de publier ne serait pas une bonne expérience utilisateur.
Je ne pense pas que ce soit l’utilisation prévue ici. Les détails doivent être fermés par défaut, et éventuellement ouverts. Devoir se souvenir de les fermer manuellement avant de créer un message n’est pas très fluide.
Supprimer le « open » dans markdown avant de publier n’est pas non plus plus intuitif. Mais quand vous voulez voir ce que vous écrivez dans l’aperçu en utilisant l’éditeur markdown, vous devez le faire. C’est mon flux de travail normal. Créer des détails, ajouter « open » pour que je puisse voir le formatage dans l’aperçu pendant que je tape, et à la fin supprimer le « open ».
Pour moi, les basculer pour qu’ils soient fermés, c’est comme supprimer le « open » dans markdown.
Donc je ne suis pas d’accord avec
parce que mon expérience était la même avant. J’ai dû supprimer le formatage « open » avant de publier.
C’était aussi le raisonnement lors du développement de cette fonctionnalité et c’est exactement ce qui se passe, mais je suis d’accord que le comportement actuel semble contre-intuitif car publier une section de détails open=true me semble un cas limite très rare, et finit par nuire à l’expérience par défaut/la plus courante à cause de ce support.
Je pense qu’il est raisonnable de supposer que la plupart des gens créent des sections de détails dans l’intention de les fermer lors de la publication afin d’éviter d’encombrer ou de surpeupler leur message avec du contenu peut-être accessoire ; sinon, pourquoi avoir le contenu dans une section de détails du tout ?
Mais, si nous fermons par défaut toutes les sections de détails lors de la publication, alors nous rendons impossible pour quiconque de publier une section de détails ouverte sans passer en mode Markdown et cela entre en conflit avec le principe du WYSIWYG. Si c’est ouvert dans l’éditeur, alors c’est ouvert dans le sujet / la réponse publiée.
Je me demande si le contenu placeholder est déroutant — lorsqu’il est ouvert, nous vous disons « ce texte sera masqué » :
Je n’ai pas encore d’idée claire sur la marche à suivre, mais je suis d’accord que quelque chose cloche.
De plus, les communautés que j’utilise hébergent des clubs de lecture et les sections de détails sont couramment utilisées pour publier des spoilers (surtout lorsqu’il y a beaucoup de texte et que l’utilisation d’une balise de spoiler est maladroite). Avoir ces sections ouvertes par défaut serait un gros problème. (C’est d’ailleurs comme ça que j’ai découvert le problème au départ.) Si elles sont ouvertes par défaut, de nombreux utilisateurs gâcheront les livres pour d’autres utilisateurs, et je ne serais pas surpris que beaucoup reviennent à markdown pour éviter cela.
Salut, j’allais créer le même fil de discussion. Dans ma communauté, il n’est utilisé que pour les spoilers, et maintenant ce nouvel éditeur est assez déroutant pour nos utilisateurs, ils ne savent pas qu’ils doivent le fermer avant de publier, donc les gens se font spoiler.
Comme il était depuis longtemps par défaut fermé, il est difficile de justifier le changement auprès des utilisateurs.
Salut ! Je viens du même forum que @seanblue et j’ai remarqué ce problème avec les boîtes de détails ouvertes.
Je comprends que l’éditeur fonctionne apparemment comme prévu. Cependant, il n’est pas évident pour l’utilisateur que c’est ainsi que l’éditeur et les boîtes de détails sont censés fonctionner. S’il était évident, tout le monde fermerait manuellement ses boîtes de détails et il n’y aurait pas de problèmes.
Nous avons beaucoup d’utilisateurs sur le forum qui n’ont pas l’habitude d’utiliser Discourse/les forums du tout, et ils ont beaucoup de mal à comprendre les fonctionnalités de base comme l’ajout de tableaux et de boîtes de détails à leurs messages ; cela ajoute un point de confusion supplémentaire que les boîtes de détails ne cachent pas d’informations, surtout avec le texte « Ce texte sera masqué ».
De plus, les utilisateurs de longue date ne sont pas au courant du changement, et soudainement les boîtes de détails ne se comportent plus comme elles l’ont toujours fait, ce qui entraîne leur ouverture ou fermeture aléatoire car les utilisateurs n’ont pas réalisé qu’il y avait eu un changement. C’est donc déroutant pour les nouveaux utilisateurs de Discourse comme pour les anciens. Je ne suis vraiment pas sûr de qui en bénéficie.
Ensuite, il y a aussi le problème mentionné par seanblue, à savoir que nous utilisons principalement les boîtes de détails pour masquer les spoilers dans les clubs de lecture, et maintenant qu’ils ne sont plus fermés par défaut, lorsque vous ouvrez un fil de discussion, tous les spoilers sont visibles, ce qui est irritant
@lindsey Je pense que nous avons reçu suffisamment de commentaires pour faire une exception ici. Par défaut, le composant est censé masquer des éléments, il s’agit donc d’une exception justifiée à mon avis.
Oui, je suis d’accord — merci à tous ceux qui ont posté ici, vos commentaires sont très précieux. Nous allons en tenir compte pour nous assurer que les sections « Masquer les détails » soient fermées par défaut lors de la publication depuis l’éditeur de texte enrichi. Je ferai un suivi une fois que j’en saurai plus sur le calendrier.
Sur mon site, nous avons eu des problèmes avec la balise [details] où son ouverture dans l’aperçu fait que le bloc est ouvert par défaut.
Ceci est confirmé par la vérification du BBCode d’un message, qui aura open ajouté à la balise (comme dans [details="Ceci devrait rester fermé" open]) s’il était ouvert dans l’aperçu au moment où le message a été soumis.
Cela semble contrecarrer l’objectif de la balise, d’autant plus que nous l’utilisons souvent pour les spoilers.
