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

Feature
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

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

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

1 Like