Requesting CSS identifiers for themes, theme components (plugins too?)

Contribute Feature

AI-generated summary

In a feature request titled ‘Requesting CSS identifiers for themes, theme components (plugins too?)’, gormus seeks CSS identifiers to allow theme-component-specific styling of settings pages, as current global overrides affect all themes. They shared a CSS fix improving layout for object settings, showing before/after visuals. zogstrip proposed a simple PR to improve core layout instead, questioning whether allowing theme-specific UI customization might harm admin UX consistency. ToddZ and mcwumbly agreed, emphasizing that admin UI consistency is critical for usability — especially for admins helping others — and that customization should be discouraged. martin reinforced this, stating the admin UI should remain uncustomizable to preserve its consistent experience. zogstrip later submitted a revised PR improving layout without major redesign. Separately, Moin noted usability issues with reordering buttons being hidden under long lists, suggesting they be placed below the sidebar for better visibility. gormus supported this, recommending keeping delete buttons in place but relocating up/down controls for improved UX.

1

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:

default_styles
default_styles1730×1927 242 KB

overwritten_styles
overwritten_styles1730×2151 302 KB

5 Likes
2

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? :thinking: cc @product-managers

3 Likes
3

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.)

4

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.

In general, we consider the admin section to be something we don’t want to be customized, if I recall correctly.

Yeah, I think treating this topic as Contribute > UX makes more sense.

@jordan.vidrine I think this has some overlap with your earlier efforts to get things converted to formkit, as well as feedback on formkit itself.

2 Likes
5

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.

1 Like
7

Gave this one another shot

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

Before After
before
before1961×1453 204 KB
after
after1961×1453 189 KB

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 :thinking:

1 Like
8

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.

2 Likes
9

@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.

2 Likes