De nieuwe WYSIWYG-editor probeert precies weer te geven wat er in het daadwerkelijke bericht zal worden weergegeven, maar in dit ene geval doet hij dat iets te goed. Kortom, wanneer je een bericht schrijft met een “Details verbergen”-sectie, wil je over het algemeen dat deze standaard gesloten is (het is tenslotte om details te verbergen). Bij het schrijven/beoordelen van je concept heb je de sectie “Details verbergen” echter van nature openstaan, zodat je de tekst erin kunt zien. Het probleem is dat dit de “Details verbergen”-sectie in de open toestand plaatst, zodat deze standaard open is. Ik wist eerig niet eens dat je deze standaard open kon maken en dit lijkt erg tegenstrijdig met hoe de meeste gebruikers de sectie zouden willen weergeven.
Stappen om te reproduceren:
Start een nieuw concept in de RTE-modus
Maak een nieuwe “Details verbergen”-sectie aan
Open de “Details verbergen”-sectie
Maak het bericht aan
Verwacht: In het bericht moet de “Details verbergen”-sectie standaard gesloten zijn, aangezien dit overeenkomt met jarenlange verwachtingen van de Markdown-editor.
Werkelijk: De “Details verbergen”-sectie is standaard open.
Hoe maak je open details met de WYSIWYG-editor als je ze niet open laat staan voordat je ze plaatst? Is het niet precies dat, dat details open zijn als ze voor het plaatsen open waren? Je krijgt wat je ziet.
Ja, je krijgt wat je ziet. En ik zeg dat het in dit geval contra-intuïtief is en tegen het doel van een details verbergen-sectie ingaat. Verwachten dat de gebruiker elke details verbergen-sectie handmatig sluit voordat hij post, zou geen goede gebruikerservaring opleveren.
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.
Hallo, ik wilde hetzelfde onderwerp aanmaken. In mijn community wordt het alleen gebruikt voor spoilers en nu is deze nieuwe editor nogal verwarrend voor onze gebruikers, ze weten niet dat ze deze moeten sluiten voordat ze posten, dus mensen krijgen spoilers.
Aangezien het zo lang de standaardinstelling was om het standaard gesloten te hebben, is het moeilijk om de verandering aan gebruikers te rechtvaardigen.
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.
Ja, ik ga akkoord — dank aan iedereen die hier heeft gepost, de feedback is zeer waardevol. We nemen dit mee om ervoor te zorgen dat de secties “Details verbergen” standaard gesloten zijn bij het plaatsen vanuit de rich text editor. Ik kom erop terug zodra ik meer weet over de 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.
