Новый WYSIWYG-редактор стремится точно отображать то, что будет показано в финальном посте, но в данном конкретном случае он делает это слишком буквально. Если коротко: когда вы пишете пост со секцией «Скрыть детали», вы, как правило, хотите, чтобы она была закрыта по умолчанию (в конце концов, она предназначена для того, чтобы скрывать детали). Однако при написании или просмотре черновика вы естественным образом будете держать секцию «Скрыть детали» открытой, чтобы видеть находящийся внутри текст. Проблема в том, что при публикации секция «Скрыть детали» сохраняется в открытом состоянии, из-за чего она открывается по умолчанию. Честно говоря, я даже не знал, что можно сделать так, чтобы она открывалась по умолчанию, и это кажется крайне неочевидным с точки зрения того, как большинство пользователей ожидают, что эта секция будет отображаться.
Шаги для воспроизведения:
Начните новый черновик в режиме RTE
Создайте новую секцию «Скрыть детали»
Откройте секцию «Скрыть детали»
Опубликуйте пост
Ожидаемый результат: В посте секция «Скрыть детали» должна быть закрыта по умолчанию, так как это соответствует многолетним ожиданиям, сформировавшимся в Markdown-редакторе.
Фактический результат: Секция «Скрыть детали» открывается по умолчанию.
При написании вы можете в любом случае переключать его между открытым и закрытым состоянием, так что да, я просто имел в виду, что финальный пост должен по умолчанию быть закрытым.
Как создать раскрытые детали в визуальном редакторе, если не оставлять их открытыми перед публикацией? Разве раскрытые детали, которые были открыты до публикации, и есть именно это? Вы получаете то, что видите.
Да, вы получаете именно то, что видите. И в данном случае это выглядит неочевидно и противоречит сути раздела «Скрыть детали». Ожидание, что пользователь вручную закроет каждый раздел «Скрыть детали» перед публикацией, не обеспечит хорошего пользовательского опыта.
Я не думаю, что это предполагаемый сценарий использования. Детали по умолчанию должны быть закрыты и открываться по желанию. Необходимость помнить о ручном закрытии перед созданием поста не очень удобна.
Удаление слова «open» в Markdown перед публикацией тоже не кажется более интуитивным. Однако, если вы хотите видеть, что пишете, в предпросмотре при использовании редактора Markdown, вам приходится это делать. Это мой обычный рабочий процесс: создаю блок с деталями, добавляю «open», чтобы видеть форматирование в предпросмотре во время набора текста, а в конце удаляю «open».
Для меня переключение их в закрытое состояние равносильно удалению «open» в Markdown.
Поэтому я не согласен с
потому что мой опыт был таким же ранее. Мне приходилось удалять форматирование «open» перед публикацией.
Это было обоснованием при разработке этой функции, и именно так всё и происходит, но я согласен, что текущее поведение кажется контринтуитивным, потому что публикация секции details с open=true представляется мне очень редким пограничным случаем, и из-за этой поддержки страдает опыт по умолчанию — более распространённый сценарий.
Думаю, разумно предположить, что большинство людей создают секции «details» с намерением, чтобы они были закрыты при публикации, чтобы не загромождать пост или не перегружать его, возможно, второстепенным содержимым; иначе зачем вообще размещать контент в секции «details»?
Однако, если мы по умолчанию будем закрывать все секции «details» при публикации, то сделаем невозможным для кого-либо разместить открытую секцию «details» без переключения в режим Markdown, и это противоречит идее WYSIWYG. Если она открыта в редакторе, то должна быть открыта и в опубликованной теме или ответе.
Мне интересно, не вводит ли в заблуждение текст-заполнитель — когда секция открыта, мы сообщаем вам: «этот текст будет скрыт»:
У меня пока нет чёткой идеи, как поступить, но я согласен, что что-то кажется не совсем правильным.
Кроме того, сообщества, которыми я пользуюсь, организуют книжные клубы, и разделы «details» часто используются для публикации спойлеров (особенно когда текста много и использование тега спойлера неудобно). Если они будут открыты по умолчанию, это создаст огромную проблему. (На самом деле именно так я и обнаружил эту проблему изначально.) Если они будут открыты по умолчанию, многие пользователи раскроют спойлеры к книгам для других, и меня бы не удивило, если бы многие вернулись к использованию markdown, чтобы избежать этого.
Привет, я как раз собирался создать аналогичную тему. В нашем сообществе этот элемент используется исключительно для спойлеров, и новый редактор сейчас вызывает у пользователей путаницу: они не знают, что его нужно закрыть перед публикацией, из-за чего многие сталкиваются со спойлерами.
Так как долгое время поведение по умолчанию заключалось в том, что он был закрыт, пользователям трудно обосновать это изменение.
Привет! Я с того же форума, что и @seanblue, и заметил эту проблему с открытыми блоками
.
Понимаю, что редактор, apparently, работает как задумано. Однако для обычного пользователя не очевидно, что именно так и должны работать редактор и блоки
. Если бы это было очевидно, все бы вручную закрывали свои блоки , и проблем бы не возникало.
У нас на форуме много пользователей, которые вообще не привыкли к Discourse/форумам, и им уже сложно разобраться с базовыми функциями, такими как добавление таблиц и блоков
в посты; дополнительный источник путаницы — то, что блоки не скрывают информацию, особенно когда в подсказке написано: «Этот текст будет скрыт».
Кроме того, опытные пользователи не в курсе изменений, и вдруг блоки
ведут себя не так, как раньше, из-за чего они случайно оказываются то открытыми, то закрытыми, потому что пользователи не заметили изменений. Это сбивает с толку как новых, так и давних пользователей Discourse. Честно говоря, не понимаю, кому это выгодно.
Также есть проблема, которую упомянул seanblue: мы в основном используем блоки
для скрытия спойлеров в книжных клубах, и теперь, когда они по умолчанию больше не закрыты, при открытии темы все спойлеры оказываются видны, что раздражает
@lindsey, я думаю, что мы уже получили достаточно отзывов, чтобы сделать здесь исключение. По умолчанию компонент должен скрывать элементы, поэтому, на мой взгляд, это оправданное исключение.
Да, я согласен — спасибо всем, кто написал здесь, обратная связь очень ценна. Мы учтём это, чтобы разделы «Скрыть детали» по умолчанию были закрыты при публикации из визуального редактора. Я вернусь с информацией, как только узнаю больше о сроках.
На нашем сайте возникли проблемы с тегом [details]: при его открытии в предпросмотре блок по умолчанию оказывается раскрытым.
Это подтверждается проверкой BBCode-разметки поста: если тег был открыт в предпросмотре в момент отправки поста, к нему добавляется атрибут open (например, [details="Это должно оставаться закрытым" open]).
Кажется, это сводит на нет саму суть тега, особенно учитывая, что мы часто используем его для спойлеров.
Это недавно изменили, чтобы богатый редактор последовательно сериализовал закрытый Markdown-тег [details], независимо от его текущего состояния (открыто/закрыто). Пожалуйста, сообщите нам, если обнаружите какие-либо проблемы.
