Markdown 모드에서 이렇게 입력하세요:
A B
C D
A와 D가 아닌 B와 C를 선택한 다음, “스포일러 흐림”을 적용합니다.
그 결과는 다음과 같이 보입니다:
A [spoiler]
B
C
[/spoiler] D
그리고 그 결과는 스포일러 흐림이 적용되지 않습니다.
A [spoiler]
BC
[/spoiler] D
이제 리치 텍스트 모드로 다시 시도해 보세요. 이것으로 시작합니다:
A B
C D
B와 C를 선택하고 스포일러 흐림을 적용합니다.
단락 구분 기호가 삭제되고, 결과는 다음과 같이 보입니다:
A BC D
Markdown 모드로 다시 전환하면, 결과는 다음과 같이 보입니다:
A [spoiler]BC[/spoiler] D
스포일러가 인라인과 블록을 동시에 가질 수 없으므로, 이 경우 어떤 결과를 기대하시나요?
스포일러가 인라인과 블록을 동시에 가질 수 없다는 생각은 사용자가 알 필요 없는 CSS의 사실에 불과하다고 생각합니다.
굵게(Bolding)를 생각해 보겠습니다. 현재 Discourse bbcode에서는 이렇게 쓸 수 있습니다:
A [b]B
C[/b] D
또는 HTML에서는 이렇게 쓸 수 있습니다:
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
이는 예상대로 정확히 다음과 같이 렌더링됩니다:
A B
C D
하지만 DOM 표현은 다음과 같습니다:
<p>A <strong>B</strong></p>
<strong> </strong>
<p><strong>C</strong> D</p>
HTML 사양은 다중 블록 하이퍼링크에 대해서도 유사한 일이 일어나도록 규정합니다. HTML에서 이렇게 쓰면:
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
HTML 사양은 DOM 표현이 세 개의 하이퍼링크를 포함하도록 다음과 같이 보이도록 규정합니다:
<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>
다중 단락 인라인 스포일러도 비슷한 방식으로 렌더링할 수 있다고 상상해 볼 수 있습니다:
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
하지만 스포일러는 굵게와 다릅니다. 스포일러는 _인터랙티브(상호작용 가능)_하기 때문입니다. 스포일러의 B 부분을 클릭하면 스포일러의 B 부분과 C 부분이 모두 드러나야 하며, "하나의 스포일러"처럼 보이고 느껴져야 합니다.
이를 처리하는 방법은 DOM 표현에서 연결된 스포일러를 지원하는 것이라고 생각합니다. 아마도 <spoiler>에는 name과 같은 속성이 있을 수 있고, 스포일러를 클릭하면 동일한 이름을 가진 모든 스포일러가 드러나게 될 것입니다. (이것은 속성, 프로퍼티, 또는 세 개의 스포일러를 연결하기 위한 기타 시스템으로 해야 할까요? 저는 모르겠습니다. 원하는 방식으로 하시면 됩니다.)
즉, 다음과 같은 마크다운이 있다고 가정해 보겠습니다:
A B
C
D E
[spoiler]F[/spoiler]
그리고 B, C, D를 선택하여 흐리게 처리(블러)했다고 합시다.
그러면 마크다운은 다음과 같이 보일 것입니다:
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
그리고 생성된 DOM은 다음과 같이 보일 것입니다:
<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>
JS에서 세 스포일러 중 하나를 클릭하면, 동일한 “name” 속성을 가진 모든 스포일러가 함께 드러나게 됩니다.
따라서 최종 사용자의 관점에서는 인라인 스포일러와 블록 스포일러를 자유롭게 조합할 수 있는 _느낌_을 줄 수 있습니다.
Contribute > Bug → Contribute > Feature 로 옮겼습니다. 여기에서 논의하고 있는 내용은 현재 지원되지 않는 기능이기 때문입니다.
@dfabulich 지원하고자 하는 사용 사례를 공유해 주시겠습니까? 그러면 해결책을 가장 잘 접근하는 방법을 이해하는 데 도움이 될 것입니다. 인라인 + 블록 스포일러 형식을 지원하는 것이 커뮤니티에서 어떻게 유용한지, 또는 언제 그런 상황이 발생하는지 알려주실 수 있을까요?
이 문제를 "기능"으로 분류하는 것은 잘못된 판단이라고 생각합니다.
"이 버그는 수정하기 너무 어렵고, 다른 작업보다 우선순위를 두는 것이 합리적이지 않다"라고 말하는 것은 상상해 볼 수 있습니다.
하지만 현재의 동작이 _올바르다_고 주장하는 사람은 아무도 없을 것입니다.
질문에 대해 말씀드리자면, 버그 수정에 대해 "사용 사례(use case)"를 제시하는 것은 사실 불가능에 가깝습니다. 기능에는 사용 사례가 있습니다(예: 스포일러 블러: 사용자는 스포일러를 블러하여 서프라이즈를 해치지 않고 미디어에 대해 논의하기를 원함), 하지만 버그는 기능 안에 존재합니다. 버그를 수정하는 것이야말로 해당 기능이 그 사용 사례를 충족하는 방법입니다.
이 문제를 "버그"로 취급하고, 제가 제안한 해결책을 구현하는 데 많은 비용이 들 수 있다는 점을 인정한다면, "사용 사례"라는 질문에 가장 근접하게 답할 수 있는 방법은 다른 질문을 답하는 것입니다:
“왜 이 버그가 중요한가? 현재의 동작이 잘못되었다는 전제 하에, 여러 단락에 걸친 인라인 텍스트를 블러할 수 없다는 사실에 누가 신경 쓸까? 정말로 그렇게 해야 하는 이유가 있는가?”
이 질문에 대해 저는 이렇게 답할 것입니다. 현재 경험은 그저 혼란스럽고, 사용자가 Discourse에 대한 신뢰를 떨어뜨립니다. 텍스트를 선택하고 'Spoilers 블러’를 클릭했는데 선택한 텍스트가 단순히 블러되지 않으면, 모든 관련자에게 부끄러운 일입니다.
솔직히 말하면, 사용자가 두 단락의 일부를 스포일러로 만들려 할 때 에러 메시지를 표시하여 문제의 본질을 교육한다면, 현재 동작보다 약간은 개선될 것입니다. 에러 메시지는 이렇게 말할 수 있습니다: “Discourse에서는 하나의 단락의 일부를 스포일러로 만들거나, 하나 이상의 전체 단락을 스포일러로 만들 수 있지만, 두 개 이상의 단락의 일부를 포함하는 스포일러를 만들 수는 없습니다.”
하지만 굵은 글씨(bold)에 대해 그런 에러를 보여줘야 한다고 상상해 보세요. 아니면 이탤릭(italic)은요?
그리고 이것이 바로 스포일러가 저에게 중요한 이유입니다. 제가 운영 중인 포럼(그리고 제가 참여하는 다른 Discourse 포럼)은 게이머 포럼으로, 미디어에 대해 이야기하고, 특히 퍼즐의 해답을 스포일러하지 않는 것이 매우 중요합니다.
"스포일러 블러는 굵은 글씨만큼 중요하지 않다. 굵은 글씨 버그는 여러 굵은 글씨 섹션을 만들어서 수정하겠지만, 스포일러 블러는 더 중요한 일이 있으니 버그는 그대로 두자. 스포일러를 그렇게까지 중요하게 여기지 않는다. 사용자는 우회 방법을 찾게 될 것이다."라고 말하는 사람의 입장을 이해할 수는 있습니다.
하지만 저와 제 포럼, 그리고 제가 활동하는 포럼들에게는 스포일러 블러가 굵은 글씨보다 약간 더 중요합니다. 그래서 저는 이 스포일러 블러 버그들을 계속 추궁해 온 것입니다!
"사용 사례"는 무엇인가? 사용 사례는: 스포일러를 사용하여 서프라이즈를 해치지 않고 미디어에 대해 논의하는 것입니다. 따라서 스포일러 블러 기능은 그 필요성을 충족시키기 위해 작동하고, 올바르게 작동해야 합니다.
저는 여기에 버그와 기능 요청이 둘 다 포함된다고 생각합니다. 용어에 대한 해석은 다를 수 있지만, 스포일러가 귀하와 커뮤니티에 얼마나 중요한지 고려하여, 앞으로 어떻게 진행될지 이해하실 수 있도록 저희가 이 문제를 어떻게 보고 있는지 설명드리고 싶습니다.
버그는 인라인과 블록을 가로지르는 스포일러를 적용하려고 할 때, 줄바꿈이 제거되는(리치 텍스트 모드) 또는 추가되는(마크다운 모드) 것입니다:
리치 텍스트:
마크다운:
이것이 좋은 경험은 아니라는 데 동의합니다. 이 버그를 수정할 수 있지만, 그 결과물은 다음과 같은 두 가지 형태 중 하나가 될 것입니다:
기능 요청은 인라인에서 시작하여 여러 블록에 걸쳐 적용되고, 한 번의 클릭으로 전체가 공개되는 단일 스포일러를 지원하는 것입니다. 이는 스포일러가 설계된 방식이 아닙니다.
귀하의 사용 사례를 질문한 이유는 버그 수정과 기능의 중요성을 모두 이해하는 데 도움이 되기 위해서입니다. 일반적으로 스포일러는 인라인 또는 블록 형태로 사용되므로, 인라인 + 블록 스포일러가 필요한 특정 상황이 있는지 궁금합니다. 이는 귀하가 Discourse를 어떻게 사용하는지 더 잘 이해하고, 이 문제를 해결하는 것이 귀하(그리고 여기서 공유된 내용에서 자신의 커뮤니티의 필요성을 알아보는 다른 사용자들)에게 어떻게 도움이 될 수 있는지를 파악하는 데 도움이 됩니다.
두 가지 옵션 중 하나를 선택해야 한다면, 저는 "단일 스포일러, 하지만 선택된 내용은 별도의 블록으로 강제됩니다."를 고를 것 같습니다.
이것에 대한 사용 사례 기반의 이유는 정말로 드릴 수 없습니다. 강제 블록 동작이 여전히 버그가 있을 것이라고 생각하기 때문입니다.
하지만 강제 블록 옵션은 스포일러가 보이는 방식에만 “단순히” 영향을 미치기 때문에 저에게는 “버그가 덜한” 것처럼 느껴집니다. 스포일러의 시작과 끝에 추가 줄바꿈을 넣는 정도이니까요.
여러 개의 연결되지 않은 스포일러는 스포일러가 동작하는 방식을 변화시킵니다. 독자는 스포일러 전체를 보기 위해 최대 세 번까지 클릭해야 합니다. 처음에는 인라인 스포일러, 그 다음 N개의 블록 스포일러, 그리고 마지막으로 인라인 스포일러를 각각 클릭해야 하니까요.
강제 블록 스포일러의 경우, 이는 미관상의 하드 버그가 됩니다. 어쩌면 아무도 영원히 고치지 않을 종류의 버그 말이죠.
이런 프레이밍은 내게는 합리적으로 느껴집니다:
이를 수정하는 작업을 진행할 예정입니다. 정확한 예상 완료 시점(ETA)은 아직 없지만, 문제가 해결되면 여기에 업데이트를 남기겠습니다.
