Новый WYSIWYG-редактор стремится точно отображать то, что будет показано в финальном посте, но в данном конкретном случае он делает это слишком буквально. Если коротко: когда вы пишете пост со секцией «Скрыть детали», вы, как правило, хотите, чтобы она была закрыта по умолчанию (в конце концов, она предназначена для того, чтобы скрывать детали). Однако при написании или просмотре черновика вы естественным образом будете держать секцию «Скрыть детали» открытой, чтобы видеть находящийся внутри текст. Проблема в том, что при публикации секция «Скрыть детали» сохраняется в открытом состоянии, из-за чего она открывается по умолчанию. Честно говоря, я даже не знал, что можно сделать так, чтобы она открывалась по умолчанию, и это кажется крайне неочевидным с точки зрения того, как большинство пользователей ожидают, что эта секция будет отображаться.
Шаги для воспроизведения:
Начните новый черновик в режиме RTE
Создайте новую секцию «Скрыть детали»
Откройте секцию «Скрыть детали»
Опубликуйте пост
Ожидаемый результат: В посте секция «Скрыть детали» должна быть закрыта по умолчанию, так как это соответствует многолетним ожиданиям, сформировавшимся в Markdown-редакторе.
Фактический результат: Секция «Скрыть детали» открывается по умолчанию.
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.
Это недавно изменили, чтобы богатый редактор последовательно сериализовал закрытый Markdown-тег [details], независимо от его текущего состояния (открыто/закрыто). Пожалуйста, сообщите нам, если обнаружите какие-либо проблемы.
