Запрос CSS-идентификаторов для тем и компонентов тем (возможно, также для плагинов)

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

Мой компонент темы использует объекты для настроек и предоставляет довольно много полей.

Текущие стили сетки, применяемые к настройкам объектов, используют очень узкие столбцы для колонки вертикальных вкладок и полей схемы.

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

Мог бы Discourse добавить CSS-идентификатор в DOM для каждой темы и компонента темы, чтобы можно было добавлять различные правила CSS, нацеленные на конкретные страницы настроек темы?

Вот простое переопределение CSS, которое я использую на своем сайте и которое применяется глобально:

.schema-setting-editor .schema-setting-editor__wrapper {
    grid-template-columns: minmax(15em, 0.3fr) 1fr;
    gap: 0 3rem;
}
.schema-setting-editor .schema-field {
    grid-template-columns: 1fr;
    gap: 0;
    background-color: var(--tertiary-100);
    padding: 1rem 5px;
}

Стиль по умолчанию и переопределенный стиль:

default_styles
default_styles1730×1927 242 KB

overwritten_styles
overwritten_styles1730×2151 302 KB

5 лайков
2

«Исправление» настолько простое:

но у меня есть несколько вопросов:

  1. Если мы сделаем для авторов тем «простым» кастомизировать внешний вид их страницы настроек, не усложнит ли это использование этих страниц для пользователей, если все они будут выглядеть по-разному?

  2. Может, стоит исправить это в ядре, чтобы страница настроек темы лучше использовала доступное пространство? :thinking: cc @product-managers

3 лайка
3

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

(Я думаю обо всей технической поддержке для друзей и семьи, которую я выполнял. Я с радостью помогу с iPhone, но меня пугает Android, потому что каждый телефон совершенно разный.)

4

Да, я не думаю, что мы хотим поощрять это. У @martin есть достаточно контекста по этому вопросу, так как он связан с установкой руководящих принципов UI, которые мы разработали для административной секции в целом некоторое время назад.

В целом, насколько я помню, мы считаем административную секцию тем, что не должно кастомизироваться.

Да, я думаю, что рассматривать эту тему как ux имеет больше смысла.

@jordan.vidrine, я думаю, что это частично пересекается с вашими предыдущими усилиями по переводу элементов на formkit, а также с обратной связью по самому formkit.

2 лайка
5

Да, я категорически против этого. Интерфейс администратора Discourse не должен кастомизироваться. Последовательность интерфейса (ну, в основном, есть несколько страниц, которые всё ещё нужно доработать) — ключевая часть опыта администратора.

1 лайк
7

Попробовал ещё раз

До После
before
before1961×1453 204 KB
after
after1961×1453 189 KB

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

1 лайк
8

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

2 лайка
9

@moin Спасибо, что обратили на это внимание. Для меня это тоже часто бывает проблемой. +1

Согласен, перемещение кнопок под боковую панель (.schema-setting-editor__tree) улучшит пользовательский опыт.

Однако я бы предпочёл разделить кнопки «вверх/вниз» и кнопку «удалить»: переместить кнопки «вверх/вниз» под боковую панель, а кнопку «удалить» оставить на месте — под полями настроек.

2 лайка