테마 및 테마 컴포넌트(플러그인 포함)의 CSS 식별자 요청

[gormus (Osman Görmüş)]

My theme-component uses objects for the settings, and it offers quite a few fields.

The current grid styles applied to object settings use very narrow columns for the vertical tabs column, and the schema fields.

I wanted to offer an alternative display for the object settings, but I couldn’t see a way to introduce a way to alter settings only for my theme-component; I don’t want to apply my CSS overrides globally for all themes.

Could Discourse possibly add a CSS identifier in the DOM for each theme and theme component, so different CSS rules can be added targeting the specific theme setting pages?

Here’s the simple CSS override I use on my site, which is applied globally:

.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;
}

The default and overwritten styles:

[zogstrip]

The “fix” is as easy as

https://github.com/discourse/discourse/pull/37043

but I wonder about a couple of things

1. if we make it “easy” for theme authors to customize how their settings page look, are we going to make it harder for people to use those page if they’re all different?

2. Should we actually fix that in core instead so that the theme settings page makes better use of the available space? cc @product-managers

[ToddZ]

@zogstrip

if we make it “easy” for theme authors to customize how their settings page look, are we going to make it harder for people to use those page if they’re all different?

This seems like a legitimate concern. As a user, I love that the ubiquity and consistency of Discourse makes it so easy to jump in and participate in a new forum. As an admin, if I had the occasion to help with other sites I’d appreciate the consistency there as well.

(I’m thinking of all the friend & family tech support I’ve been called to do. I’m happy to help with iPhones, but I dread Android because every dang phone is different.)

[mcwumbly (Dave McClure)]

@zogstrip

테마 제작자가 설정 페이지의 모양을 커스터마이징할 수 있도록 “쉽게” 만들어 준다면, 모든 페이지가 서로 다르게 보일 때 사용자들이 해당 페이지를 사용하는 것이 더 어려워지지 않을까요?

네, 이것이 우리가 장려하고 싶은 방향은 아닌 것 같습니다. @martin 님은 이전에 관리자 섹션 전체에 대해 우리가 정한 UI 가이드라인과 관련하여 이 주제에 대해 상당한 맥락을 가지고 계십니다.

일반적으로 관리자 섹션은 커스터마이징하지 않는 것이 좋다고 생각했습니다. 제 기억이 맞다면요.

@zogstrip

사실 테마 설정 페이지가 사용 가능한 공간을 더 잘 활용할 수 있도록 코어에서 수정하는 것이 나쁘지 않을까요?

네, 이 주제를 #contribute:ux로 다루는 것이 더 합리적이라고 생각합니다.

@jordan.vidrine 이 내용은 이전에 formkit로 전환하려는 노력 및 formkit 자체에 대한 피드백과 일부 중복되는 부분이 있는 것 같습니다.

[martin (Martin Brennan)]

@mcwumbly

@zogstrip

if we make it “easy” for theme authors to customize how their settings page look, are we going to make it harder for people to use those page if they’re all different?

Yeah, I don’t think this is something we want to encourage. @martin has a fair bit of context on this question as it relates to establishing the UI guidelines we came up with for the admin section overall a while back.

Yes I am quite opposed to this, the Discourse admin UI should not be customized, the consistency of the UI (well mostly, there are a few pages that still need to be addressed) is a key part of the admin experience.

[zogstrip]

Gave this one another shot

https://github.com/discourse/discourse/pull/37058

Before	After

This is the simplest that I could do. Not sure we want to spend time re-working this UI - the “inner sidebar” feels “off” but that might be more work than what we can prioritize right now

[Moin]

Do you think it’s possible to always have the button for changing the order of the elements visible at the same time as the inner sidebar? If it’s below a long list of settings, changing the order requires a lot of scrolling; you cannot see what happens while you see the button.

[gormus (Osman Görmüş)]

@moin Thanks for pointing this one out. It is often a problem for me too. +1

I agree, moving the buttons below the sidebar (.schema-setting-editor__tree) would improve the user-experience.

Though, I’d prefer separating the up/down buttons from the delete button; moving up/down buttons below the sidebar, and leaving the delete button as it is, below the setting fields.