새로운 WYSIWYG 에디터는 실제 게시글에 렌더링될 모습을 그대로 반영하려는 시도를 하고 있지만, 이 한 가지 경우에는 오히려 지나치게 잘 반영하고 있습니다. 간단히 말해, “상세 내용 숨기기” 섹션을 포함하여 글을 작성할 때 일반적으로 기본적으로 접힌 상태인 것이 바람직합니다(결국 상세 내용을 숨기기 위한 것이니까요). 하지만 초안을 작성하거나 검토할 때는 내부 텍스트를 확인할 수 있도록 “상세 내용 숨기기” 섹션을 자연스럽게 펼쳐 놓게 됩니다. 문제는 이 섹션이 펼쳐진 상태로 게시되어, 기본값이 펼쳐진 상태가 된다는 점입니다. 솔직히 이 섹션을 기본적으로 펼쳐진 상태로 만들 수 있다는 사실조차 몰랐고, 대부분의 사용자가 원하는 렌더링 방식과 매우 직관에 반하는 것처럼 보입니다.
재현 단계:
RTE 모드에서 새 초안을 시작합니다.
새 “상세 내용 숨기기” 섹션을 생성합니다.
“상세 내용 숨기기” 섹션을 펼칩니다.
게시글을 생성합니다.
기대 동작: 게시글에서 “상세 내용 숨기기” 섹션은 마크다운 에디터에 대한 수년간의 기대에 부합하도록 기본적으로 접힌 상태여야 합니다.
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.
On my site, we’ve been having trouble with the [details] tag where opening it in the preview will cause the block to be open by default.
This is backed up by checking the BBCode for a post, which will have open appended to the tag (as in [details="This should remain closed" open]) if it was open in the preview at the time the post was submitted.
This seems like it defeats the point of the tag, especially since we often use it for spoilers.
