עורך ה-WYSIWYG החדש מנסה לייצג בדיוק מה שיוצג בפוסט בפועל, אך במקרה זה הוא עושה זאת טוב מדי. בקיצור, כשאתה כותב פוסט עם קטע “הסתר פרטים” (Hide Details), בדרך כלל אתה רוצה שהוא יהיה סגור כברירת מחדל (הרי זה כדי להסתיר פרטים). עם זאת, כשאתה כותב/סוקר את הטיוטה שלך, באופן טבעי יהיה לך קטע “הסתר פרטים” פתוח כדי שתוכל לראות את הטקסט שבתוכו. הבעיה היא שזה מפרסם את קטע “הסתר פרטים” במצב פתוח, כך שהוא פתוח כברירת מחדל. בכנות, אפילו לא ידעתי שאפשר להפוך אותו לפתוח כברירת מחדל, וזה נראה מאוד לא אינטואיטיבי לאופן שבו רוב המשתמשים היו רוצים שהקטע יוצג.
שלבים לשחזור:
התחל טיוטה חדשה במצב RTE
צור קטע חדש של “הסתר פרטים”
פתח את קטע “הסתר פרטים”
צור את הפוסט
צפוי: בפוסט, קטע “הסתר פרטים” אמור להיות סגור כברירת מחדל, מכיוון שזה תואם שנים של ציפיות מעורך ה-Markdown.
כיצד יוצרים פרטים פתוחים בעורך ה-WYSIWYG אם לא על ידי השארתם פתוחים לפני הפרסום? הרי פרטים פתוחים כשהיו פתוחים לפני הפרסום זה בדיוק זה? מה שאתה רואה זה מה שאתה מקבל.
כן, אתה מקבל את מה שאתה רואה. ואני אומר במקרה זה לקבל את מה שאתה רואה זה לא אינטואיטיבי ונוגד את המטרה של קטע הסתר פרטים. ציפייה מהמשתמש לסגור ידנית כל קטע הסתר פרטים לפני הפרסום לא תיצור חווית משתמש טובה.
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.
היי, התכוונתי ליצור את אותו השרשור. בקהילה שלי, הוא משמש רק לספוילרים, ועכשיו העורך החדש הזה די מבלבל את המשתמשים שלנו, הם לא יודעים שהם צריכים לסגור אותו לפני הפרסום כדי שאנשים לא יקבלו ספוילרים.
מכיוון שזה היה ההתנהגות ברירת המחדל כל כך הרבה זמן שזה סגור כברירת מחדל, קשה להצדיק את השינוי למשתמשים.
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.
כן, אני מסכים — תודה לכל מי שפרסם כאן, המשוב יקר מאוד. ניקח זאת לתשומת ליבנו כדי להבטיח שמדורי “הסתר פרטים” יהיו סגורים כברירת מחדל בפרסום מעורך הטקסט העשיר. אני אעקוב לאחר שאדע יותר לגבי תזמון.
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.
