The new WYSIWYG editor tries to represent exactly what will be rendered in the actual post, but in this one case it does it too well. In short, when you are writing a post with a “Hide Details” section you generally want it to be closed by default (it is to hide details after all). However, when writing/reviewing your draft, you will naturally have the Hide Details section open so you can see the text inside it. The problem is that this posts the Hide Details in the open state so that it’s open by default. I honestly didn’t even know you could make it open by default and this seems very counterintuitive to how most users would want the section to be rendered.
Steps to reproduce:
Start a new draft in RTE mode
Create a new “Hide Details” section
Open the “Hide Details” section
Create the post
Expected: In the post, the “Hide Details” section should be closed by default since this matches years of expectations from the Markdown editor
Actual: The “Hide Details” section is open by default
How do you create open details with the WYSIWYG editor if not by leaving them open before posting? Isn’t details being open when they were open before posting exactly that? You get what you see.
Yes, you get what you see. And I’m saying in this case getting what you see is unintuitive and counter to the point a hide details section. Expecting the user to manually close every Hide Details section before posting wouldn’t make for a good user experience.
I don’t think that’s intended usecase here. The details should by default be closed, and optionally opened. Having to remember to manually toggle it close before creating a post isn’t very smooth.
Removing the “open” in markdown before posting isn’t more intuitive either. But when you want to see what you are writing in the preview using the markdown editor, you have to do that. That is my normal workflow. Create details, add “open” so I can see the formatting in the preview while I am typing, and at the end remove the “open”.
For me toggling them to be closed is like removing the “open” in markdown.
So I disagree with
because my experience was the same before. I had to remove the “open” formatting before posting
That was the reasoning too when developing this feature and is exactly what happens, but I agree that the current behavior feels counter-intuitive because posting an open=true details section seems like a very rare edge case to me, and end up hurting the default/more common experience because of this support.
I think it’s reasonable to assume that most people create details sections with the intention of having them closed upon posting to avoid cluttering or overpopulating their post with perhaps ancillary content; otherwise, why have the content in a details section at all?
But, if we default to closing all details sections upon post, then we make it impossible for anyone to post an open details section without switching to Markdown-mode and it does conflict with the premise of WYSIWYG. If it’s open in the editor, then it’s open in the posted topic / reply.
I wonder if the placeholder content is confusing — when it is open, we tell you “this text will be hidden”:
I don’t have a clear idea yet on where to go with this, but I agree something feels off.
Also, the communities I use host book clubs and the details sections are commonly used to post spoilers (especially when there’s a lot of text and using a spoiler tag is awkward). Having these open by default would be a huge problem. (That’s actually how I discovered the issue to begin with.) If they are open by default many users will spoil the books for other users, and I wouldn’t be surprised if many revert back to markdown to avoid this.
Hi, I was going to create the same thread. In my community, it’s only used for spoilers, and now this new editor gets quite confusing for our users, they don’t know they have to close it before posting so people got spoiled.
As it was the default behavior for so long to have it closed by default, it’s hard to justify the change to users.
Hey! I’m from the same forum as @seanblue and have noticed this issue with details boxes being open.
I understand that the editor is apparently functioning as intended. However, it’s not obvious on the user-end that this is how the editor and details boxes are intended to function. If it was obvious, then everyone would be manually closing their details boxes and there would be no problems.
We have a lot of users on the forum who aren’t used to using Discourse/forums at all, and they have a lot of trouble just figuring out basic functionalities like adding tables and details boxes to their posts to begin with; it adds a further point of confusion that the details boxes are not hiding information, especially with the flavor text being ‘This text will be hidden.’
Also, long-time users are not aware of the change, and suddenly details boxes are not behaving like they always used to, resulting in them randomly being open or closed because users have not realized there was a change. So this is confusing both to new Discourse users and long-time Discourse users. I’m really not sure who is benefiting here.
Then, there’s also the issue seanblue mentioned which is that we mainly use details boxes to hide spoilers in book clubs, and now that they are suddenly not closed by default, so when you open a thread, all the spoilers are visible, which is irritating
@lindsey I think we have gotten enough feedback now to make an exception here. By default, the component is expected to hide things, so it’s a justified exception imo.
Yes, I agree — thank you to everyone who has posted here, the feedback is very valuable. We’ll take this on to ensure that the “Hide details” sections default-closed on posting from the rich text editor. I’ll follow up once I know more about timing.
