במצב Markdown, הקלד זאת:
A B
C D
בחר את B ו-C אך לא את A ו-D, ואז “טשטש ספוילר.”
התוצאה תיראה כך:
A [spoiler]
B
C
[/spoiler] D
והתוצאה לא תהיה מטושטשת כספוילר.
A [spoiler]
BC
[/spoiler] D
נסה זאת שוב במצב rich-text. התחל עם זה:
A B
C D
בחר B ו-C וטשטש ספוילר.
המעבר בין הפסקאות יימחק, והתוצאה תיראה כך:
A BC D
אם תחזור למצב Markdown, התוצאה תיראה כך:
A [spoiler]BC[/spoiler] D
What result would you expect in this case, considering the spoiler can’t be both inline and block?
I think the idea that a spoiler can’t be both inline and block is a fact of CSS that the user shouldn’t need to be made aware of.
Consider bolding. You can write this in Discourse bbcode today:
A [b]B
C[/b] D
Or you can write this in HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
It renders exactly the way you’d expect it to render:
A B
C D
But the DOM representation looks like this:
<p>A <strong>B</strong></p>
<strong> </strong>
<p><strong>C</strong> D</p>
The HTML spec calls for something similar to happen for multi-block hyperlinks. If you write this in HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
The HTML spec calls for the DOM representation to look like this, with three hyperlinks:
<body>
<p>A <a href="https://example.com.">B</a>
</p><a href="https://example.com."> </a>
<p><a href="https://example.com.">C</a> D</p>
</body>
You could imagine rendering multi-paragraph inline spoilers in a similar way:
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
But spoilers are different from bold, because spoilers are interactive. When you click on the B part of the spoiler, it’s supposed to reveal both the B and the C part of the spoiler; it’s supposed to look and feel like “one spoiler.”
I think the way to handle this is to support linked spoilers in the DOM representation. Perhaps <spoiler> would have an attribute like name, and when you click on a spoiler, it would reveal all spoilers with the same name. (Should this be done with attributes, properties, or some other system for linking the three spoilers? I dunno, do it any way you like.)
So, suppose you’ve got Markdown like this:
A B
C
D E
[spoiler]F[/spoiler]
And you select B, C, and D and blur them.
The Markdown would then look like this:
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
And the generated DOM would look like this:
<p>A <inline-spoiler name="x">B</inline-spoiler></p>
<block-spoiler name="x"><p>C</p></block-spoiler>
<p><inline-spoiler name="x">D</inline-spoiler> E</p>
<block-spoiler name="y"><p>F</p></block-spoiler>
In JS, when you click on any one of the three spoilers, all spoilers with the same “name” attribute would reveal themselves together.
Thus, from the end-user’s perspective it would feel like you could mix’n’match inline and block spoilers.
העברתי את זה מ-Bug ל-Feature מכיוון שהפונקציונליות שאנו בוחנים כאן אינה נתמכת כעת.
@dfabulich האם תוכל לשתף את מקרה השימוש שאתה מעוניין לתמוך בו? זה יעזור לנו להבין כיצד לגשת בצורה הטובה ביותר לפתרון. האם תוכל לספר לנו כיצד תמיכה בצורה זו של הסתרות inline + block תהיה שימושית בקהילה שלך, או מתי הן עולות?
אני חושב שזו קריאה שגויה לסווג זאת כ"תכונה".
אני יכול לדמיין לומר “באג זה קשה מדי לתיקון; אין טעם לתעדף אותו על פני עבודה אחרת.”
אבל אני לא חושב שאף אחד יגן על ההתנהגות הנוכחית כ נכונה.
לגבי שאלתך, זה לא באמת אפשרי לתת “מקרה שימוש” לתיקון באג. לתכונות יש מקרי שימוש (טשטוש ספוילר: משתמשים רוצים לטשטש ספוילרים כדי שיוכלו לדון במדיה מבלי להרוס את ההפתעה), אבל באגים שוכנים בתוך תכונות. תיקון הבאגים הוא הדרך שבה תכונה ממלאת את מקרה השימוש שלה.
אם אני מתייחס לנושא זה כ"באג", ומודה שיישום הפתרון המוצע שלי עשוי להיות יקר, הדבר הקרוב ביותר שאני יכול לעשות כדי לענות על שאלת “מקרה השימוש” שלך הוא לענות על שאלה אחרת:
“למה הבאג הזה חשוב? בהנחה שההתנהגות הנוכחית אינה נכונה, למי אכפת שאינך יכול לטשטש טקסט מוטמע על פני פסקאות מרובות? האם אתה באמת צריך לעשות זאת?”
ולזה, אני חושב שהייתי אומר: החוויה הנוכחית פשוט מבלבלת, ומערערת את אמון המשתמש ב-Discourse. כאשר אתה בוחר טקסט כלשהו ולוחץ על טשטוש ספוילר, וזה פשוט לא מטשטש את הטקסט שבחרת, זה פשוט מביך לכל המעורבים.
למען האמת, זה יהיה שיפור קל על פני ההתנהגות הנוכחית להציג הודעת שגיאה כאשר משתמש מנסה לספוילר חלקים משתי פסקאות, לחנך את המשתמש לגבי טבע הבעיה. הודעת השגיאה יכולה לומר: “ב-Discourse, אתה יכול לספוילר חלק מפִסקה אחת, או שאתה יכול לספוילר פִסקה אחת או יותר שלמות, אבל אינך יכול ליצור ספוילר המכיל חלקים משתי פסקאות או יותר.”
אבל עכשיו תאר לעצמך שאם היית צריך להציג הודעת שגיאה כזו עבור טקסט מודגש? או נטוי?
וזה מגיע לסיבה שבגללה ספוילרים חשובים לי: הפורום שאני מפעיל (ופורומים אחרים של Discourse שאני משתתף בהם) הם פורומים של גיימרים, שבהם דיבור על מדיה, ובמיוחד מבלי לקלקל את הפתרונות לחידות, הוא עניין גדול באמת.
אני יכול להבין למה מישהו יגיד “טשטוש ספוילר אינו חשוב כמו טקסט מודגש. נתקן את הבאג עבור טקסט מודגש על ידי יצירת קטעים מרובים מודגשים, אבל עבור טשטוש ספוילר, יש לנו דגים גדולים יותר לטגן; בואו נשאיר את באג הספוילר לא מתוקן. אנחנו פשוט לא דואגים לספוילרים כל כך הרבה. משתמשים ימצאו פתרון עוקף.”
אבל בשבילי ובשביל הפורום שלי, והפורומים שאני חי עליהם, טשטוש ספוילר חשוב במעט יותר מטקסט מודגש. זו הסיבה שאני דוחף על באגי טשטוש הספוילר האלה!
מהו ה"מקרה שימוש"? מקרה השימוש הוא: אנו משתמשים בספוילרים כדי לדבר על מדיה מבלי לקלקל הפתעה. ולכן, תכונת טשטוש הספוילר צריכה לעבוד, ולעבוד כראוי, כדי לספק את הצורך הזה.
מצידי, אני חושב שיש כאן באג ופיצ’ר. אנחנו יכולים לחלוק על סמנטיקה, אבל אני כן רוצה להסביר איך אנחנו מסתכלים על זה כדי שתבין מה הלאה, בהתחשב בחשיבות של ספוילרים עבורך ועבור הקהילה שלך.
הבאג הוא שכאשר מנסים להחיל ספוילר באופן מוטמע (inline) ועל פני בלוקים, שבירות הפסקה מוסרות (במצב rich text) ומתווספות (במצב Markdown):
Rich text:
Markdown:
אני מסכים שזו לא חוויה נעימה. אנחנו יכולים לתקן את הבאג הזה, אבל מה שזה ייראה כמו יהיה אחד מהבאים:
בקשת הפיצ’ר היא לתמוך בספוילר בודד שיכול להתחיל באופן מוטמע ולהתפרס על פני מספר בלוקים, ואז להיחשף בלחיצה אחת. ככה ספוילרים לא נועדו לעבוד.
הסיבה ששאלתי לגבי מקרה השימוש שלך היא כדי לסייע הן בתיקון הבאג והן בהבנת חשיבות הפיצ’ר. אנחנו בדרך כלל רואים ספוילרים באופן מוטמע או כבלוקים, אז אני תוהה אם יש מצבים מסוימים שבהם ספוילר מוטמע + בלוק נכנס לפעולה. זה עוזר לנו להכיר טוב יותר את אופן השימוש שלך ב-Discourse ולהבין איך פתרון זה יכול לעזור לך (ולאחרים שמזהים את צרכי הקהילה שלהם במה שאתה משתף כאן).
בהינתן שתי האפשרויות הללו, אני חושב שהייתי בוחר ב"ספוילר יחיד, אך התוכן הנבחר ייכפה לתוך בלוק משלו".
אני לא באמת יכול לתת סיבה מבוססת מקרה שימוש לכך; אני חושב שהתנהגות הבלוק הכפוי עדיין תהיה תקולה.
אבל אפשרות הבלוק הכפוי מרגישה לי “פחות תקולה” מכיוון שהיא “רק” משפיעה על איך שהספוילר נראה: מוסיפה שבירת שורה נוספת בתחילת הספוילר ובסופו.
לספוילרים מרובים ללא קישור יש השפעה על אופן הפעולה של הספוילר. קוראים יצטרכו ללחוץ עד שלוש פעמים כדי לחשוף את כל הספוילר: פעם אחת עבור הספוילר המוביל בשורה, שוב עבור N ספוילרים בבלוק, ושוב בספוילר הסיום בשורה.
עם ספוילרים בבלוק כפוי, זה הופך לבאג קשה קוסמטי, מהסוג שאולי אף אחד לעולם לא יעבוד עליו.
This framing does make sense to me:
We will work on fixing that up; I don’t have an ETA for you but I will update here once we’ve addressed this.