Спойлеризация частей двух абзацев работает некорректно

Внести вклад Функция
,
1

В режиме Markdown введите следующее:

A B

C D

Выделите B и C, но не A и D, затем выберите «Скрыть спойлер».

Результат будет выглядеть так:

A [spoiler]
B

C
[/spoiler] D

При этом текст не будет скрыт спойлером.

A [spoiler]
B

C
[/spoiler] D

Теперь попробуйте то же самое в режиме форматированного текста. Начните с этого:

A B

C D

Выделите B и C и примените размытие спойлера.

Разрыв абзаца будет удалён, и результат будет выглядеть так:

A BC D

Если вы переключитесь обратно в режим Markdown, результат будет выглядеть так:

A [spoiler]BC[/spoiler] D
1 лайк
2

Какой результат вы ожидаете в этом случае, учитывая, что спойлер не может быть одновременно строчным и блочным?

3

Я считаю, что идея о том, что спойлер не может быть одновременно строчным и блочным, является фактом CSS, о котором пользователю не нужно знать.

Предыстория: как с этим работает HTML?

Рассмотрим выделение жирным шрифтом. Сегодня в bbcode Discourse можно написать так:

A [b]B

C[/b] D

Или так в HTML:

<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</strong></p>

<p>C</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</a></p>

<p>C</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, и при клике на спойлер будут раскрываться все спойлеры с тем же именем. (Должно ли это реализовываться через атрибуты, свойства или какую-либо другую систему связывания трёх спойлеров? Не знаю, делайте как хотите.)

Итак, предположим, у вас есть Markdown:

A B

C

D E

[spoiler]F[/spoiler]

И вы выделяете B, C и D, чтобы скрыть их.

Тогда Markdown будет выглядеть так:

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» раскроются одновременно.

Таким образом, с точки зрения конечного пользователя это будет ощущаться так, будто можно комбинировать строчные и блочные спойлеры.

4

Я перенёс это из bug в #feature, так как то, что мы здесь исследуем, в настоящее время является неподдерживаемой функциональностью.

@dfabulich Не могли бы вы описать случай использования, который вы хотите реализовать? Это поможет нам понять, как лучше всего подойти к решению. Расскажите, пожалуйста, как поддержка такого формата спойлеров (встроенных и блочных) была бы полезна в вашем сообществе или в каких ситуациях они возникают?

5

Я считаю, что классифицировать это как «функцию» — неверное решение.

Можно представить ситуацию, когда говорят: «Эту ошибку слишком сложно исправить; нет смысла отдавать ей приоритет перед другими задачами».

Но я не думаю, что кто-либо будет защищать текущее поведение как правильное.

Что касается вашего вопроса: дать «кейс использования» для исправления ошибки по сути невозможно. У функций есть кейсы использования (Blur Spoiler: пользователи хотят скрывать спойлеры, чтобы обсуждать медиа, не раскрывая сюрпризы), но ошибки находятся внутри функций. Исправление ошибок — это то, как функция выполняет свой кейс использования.

Почему эта ошибка важна? Потому что мы часто используем спойлеры!

Если я рассматриваю эту проблему как «ошибку» и признаю, что реализация моего предложенного решения может быть затратной, то наиболее близкий ответ на ваш вопрос о «кейсе использования» будет ответом на другой вопрос:

«Почему эта ошибка важна? Принимая во внимание, что текущее поведение неверно, кого волнует, что нельзя скрыть текст внутри нескольких абзацев? Вам действительно нужно это делать?»

На это я бы ответил: текущий опыт просто запутывает и подрывает доверие пользователей к Discourse. Когда вы выделяете текст, нажимаете «Скрыть спойлер», а текст не скрывается — это просто неловко для всех участников.

Честно говоря, даже простое отображение сообщения об ошибке, если пользователь пытается скрыть части двух абзацев, было бы небольшим улучшением по сравнению с текущим поведением. Это сообщение могло бы обучать пользователя сути проблемы. Сообщение могло бы гласить: «В Discourse вы можете скрыть часть одного абзаца или один и более целых абзацев, но нельзя создать спойлер, содержащий части двух или более абзацев».

Но теперь представьте, если бы вам приходилось показывать такое сообщение для жирного текста? Или курсива?

Именно это объясняет, почему спойлеры важны для меня: форум, который я веду (и другие форумы Discourse, где я участвую), — это геймерские форумы, где обсуждение медиа, особенно без раскрытия решений головоломок, имеет огромное значение.

Я понимаю, почему кто-то может сказать: «Скрытие спойлеров не так важно, как жирный текст. Мы исправим ошибку для жирного текста, сделав возможность выделять несколько жирных участков, а для скрытия спойлеров у нас есть дела поважнее; давайте оставим эту ошибку неисправленной. Мы просто не так сильно заботимся о спойлерах. Пользователи найдут обходной путь».

Но для меня и моего форума, а также форумов, где я живу, скрытие спойлеров чуть важнее, чем жирный текст. Именно поэтому я настаиваю на исправлении этих ошибок с функцией скрытия спойлеров!

Какой здесь «кейс использования»? Кейс использования таков: мы используем спойлеры, чтобы обсуждать медиа, не раскрывая сюрпризы. Следовательно, функция скрытия спойлеров должна работать и работать корректно, чтобы удовлетворить эту потребность.

1 лайк
6

С моей точки зрения, здесь есть и баг, и особенность. Мы можем спорить о терминологии, но я хочу объяснить, как мы рассматриваем этот вопрос, чтобы вы понимали, что будет дальше, учитывая, насколько важны спойлеры для вас и вашего сообщества.

Баг заключается в том, что при попытке применить спойлер внутри строки и через несколько блоков:

  • в режиме визуального редактора (Rich Text) разрывы абзацев удаляются;
  • в режиме Markdown они добавляются:

Rich text:

CleanShot 2025-08-21 at 18.20.06
CleanShot 2025-08-21 at 18.20.06122×134 1.18 KB

Markdown:

CleanShot 2025-08-21 at 18.19.30
CleanShot 2025-08-21 at 18.19.30707×266 10.9 KB

Я согласен, что это не самый приятный опыт. Мы можем исправить этот баг, но результат будет одним из следующих:

  • Два отдельных спойлера, по одному на каждой строке, которые нужно нажимать отдельно, чтобы раскрыть;
  • Один спойлер, но выбранный контент будет принудительно помещён в отдельный блок.

Запрос на функцию — это поддержка одного спойлера, который может начинаться внутри строки и охватывать несколько блоков, после чего раскрывается одним кликом. Однако спойлеры не были спроектированы работать именно так.

Я задал вопрос о вашем случае использования, чтобы помочь и в исправлении бага, и в понимании важности этой функции. Обычно мы видим спойлеры либо внутри строки, либо в виде отдельных блоков, поэтому меня интересует, есть ли конкретные ситуации, когда применяется спойлер, сочетающий внутристрочный и блочный режимы. Это поможет нам лучше понять, как вы используете Discourse, и осознать, как решение этой задачи может помочь вам (и другим, кто узнаёт в вашем описании потребности своего сообщества).

1 лайк
7

Учитывая эти два варианта, я бы выбрал «Один спойлер, но выбранное содержимое будет принудительно помещено в отдельный блок».У меня нет веской причины, основанной на конкретных случаях использования; я считаю, что поведение с принудительным блоком всё равно будет содержать ошибки.Однако вариант с принудительным блоком кажется мне «менее ошибочным», потому что он «лишь» влияет на то, как спойлер выглядит: добавляя лишний разрыв строки в начале и в конце спойлера.Несколько несвязанных спойлеров влияют на то, как спойлер работает. Читателям придётся кликать до трёх раз, чтобы раскрыть весь спойлер: один раз для ведущего встроенного спойлера, затем ещё раз для N блочных спойлеров и снова для завершающего встроенного спойлера.При использовании принудительных блочных спойлеров это превращается в косметическую критическую ошибку, того типа, над которой, возможно, никто никогда не будет работать.

2 лайка
8

Такая формулировка кажется мне логичной:

Мы займемся исправлением этой ситуации; у меня пока нет точных сроков, но я обновлю информацию здесь, как только мы решим этот вопрос.

1 лайк