Weekly update – 30 May 2025 – Customizing default theme in AdminThemeUikit

[ryan]

There have been several requests and suggestions for the new AdminThemeUikit default theme. Some of them will no doubt find their way into the core CSS files, but I thought this week it would be useful to look at just how easy it is to apply some of these yourself using the custom CSS options in the AdminThemeUikit default theme. I haven't yet run these through Diogo and Jan, so there may very well be even simpler ways to do these things, but I took my best shot at answering some of the requests here. 

You can specify a custom CSS file (like /site/templates/styles/admin-tweaks.css), or if you are in advanced mode ($config->advanced = true) you can specify custom CSS rules directly in the AdminThemeUikit module settings. Let’s look at how to accomplish some recently requested tweaks. Also attached is a CSS file that compiles them all in one. And all of these work in both light and dark mode, by the way. CSS variables make much of this very easy to do. 

Quote

How can I make the background and text colors more subtle, rather than pure black and white?

In this case, we’ll choose colors that are relatively close to black and white, but a little less harsh for those that like to have their screen brightness high. Of course, adjust the colors as needed for your preferences:

:root {
    /* use slightly lighter main background color */
    --main-background: light-dark(#efefef, #222);

    /* also slightly lighter background color for blocks like Inputfields */
    --blocks-background: light-dark(#fcfcfc, #111);

    /* use text color that is not 100% white/black */
    --text-color: light-dark(#222, #efefef);
}

 

Quote

In the light theme, I don’t want black buttons. How do I make them use the main color instead?

You can adjust the button-background CSS variable:

.light-theme {
    /* if you prefer not to have black buttons on light theme... */ 
    /* use main color for button color */
    --button-background: var(--main-color);
}

.pw .ui-button.ui-state-hover {
    /* highlight button when hovered */
    filter: brightness(1.08);
}

 

Quote

How can I make <select> elements have the same background color as <input type=text> elements?

Set .uk-select elements to use the inputs-background CSS variable:

.Inputfields .Inputfield select.uk-select {
    /* make <select> elements have same background color as text inputs */
    background-color: var(--inputs-background);
}

 

Quote

How can I make the Page List use action links look like buttons rather than text links? (edit, view, move, etc.)

Here we'll use the main color as the background color for the PageList action links, and then make their text white. This gives more of an Original theme appearance, for those that prefer it: 

.PageList .PageListItem .PageListActions > li > a {
    /* make PageList items use action links that look like buttons */
    display: inline-block;
    line-height: 1.3;
    background-color: var(--main-color);
    color: #fff;
    padding: 2px 6px;
    font-weight: bold;
    text-transform: lowercase;
    position: relative;
    top: -1px;
}
.PageList .PageListItem .PageListActions > li > a:hover {
    /* highlight selected action when hovered */
    filter: brightness(1.08);
}
#pw-content-body .PageList ul.uk-pagination > li.uk-active > a {
    /* optional: update active pagination to use main color */
    --blocks-background: #fff;
    --text-color: var(--main-color);
}

 

Quote

How can I make AsmSelect items, PageAutocomplete items, and PageListSelectMultiple items use the main color so that they are more contrasty like the Original theme?

Like with the PageList action link buttons above, we apply new background and foreground colors to these sortable item-based elements. We also make a few other small tweaks to accompany the color change: 

.pw .Inputfields .InputfieldPageAutocomplete li,
.pw .Inputfields .InputfieldPageAutocomplete li a,
.pw .Inputfields .InputfieldPageListSelectMultiple ol li,
.pw .Inputfields .InputfieldAsmSelect .asmListItem,
.pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-default,
.pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover {
    /* make asmSelect/autocomplete/pageListSelect use the main-color */
    --main-background: var(--main-color);
    --border-color: var(--main-color);
    --text-color: rgba(255,255,255,0.9);
    background-color: var(--main-background);
    margin-top: 0;
    margin-bottom: 1px !important;
}

.pw .Inputfields .InputfieldPageAutocomplete li:hover,
.pw .Inputfields .InputfieldPageAutocomplete li:hover a,
.pw .Inputfields .InputfieldPageListSelectMultiple ol li:hover,
.pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover {
    /* highlight hovered items */
    filter: brightness(1.05);
    border-color: var(--main-color);
}

 

Quote

How can I make <input> elements show a :focus state, so that I can tell which input is focused without having to find the cursor?

In this case, we'll instruct <input>, <textarea>, <select> and TinyMCE elements to show a 1px border outline using the main-color when focused: 

.Inputfields input:focus:not([type="submit"]):not([type="file"]):not([type="checkbox"]):not([type="radio"]):not(.uk-form-blank),
.Inputfields textarea:focus,
.pw .Inputfields .Inputfield select.uk-select:focus,
select.uk-select:focus {
    /* have inputs show a focused state indicated by border color */
    border-color: var(--main-color); 
}
.InputfieldTinyMCE .tox-edit-area {
    /* setup a border in tinymce that we can highlight when focused (requires latest PW dev) */
    border: 1px solid transparent;
}
.InputfieldTinyMCEFocused .tox-edit-area {
    /* make tinymce show a border (like other inputs) when focused (requires latest PW dev) */
    border-color: var(--main-color);
}

 

Quote

How can I optimize the appearance of FieldtypeTable/InputfieldTable in the new default theme?

I found that InputfieldTable worked quite well as-is, but making the <table> use a transparent background color seemed to blend in a little better: 

.InputfieldTable .AdminDataTable tr {
    /* make InputfieldTable <table> have same background color as its container */
    background-color: transparent;
}
.InputfieldTableRowSortHandle:hover,
.InputfieldTableRowDeleteLink:hover {
    /* make table action links highlight with main color when hovered */
    color: var(--main-color); 
}

 

Quote

How can I make Repeater items more bold so that they use the main color for the item headers?

For the headers of repeater items, we take the same approach that we did with AsmSelect, PageAutocomplete and PageListSelectMultiple items, giving them the same bolder color scheme that utilizes the main color: 

.pw .Inputfields .InputfieldRepeater .InputfieldContent .InputfieldRepeaterItem > .InputfieldHeader,
.pw .InputfieldFileList > li > .InputfieldItemHeader {
    /* make InputfieldRepeater item headers use the main color */
    --inputs-background: var(--main-color); 
    --border-color: var(--main-color); 
    --text-color: rgba(255,255,255,0.9);
    --muted-color: rgba(255,255,255,0.8);
}
.InputfieldRepeaterItem > .InputfieldHeader:hover {
    /* make hovered repeater header slightly highlighted */
    filter: brightness(1.05);
}

 

Quote

How can I have rounded input elements?

There are two CSS variables for this. One to control the border-radius of <input> elements, and another to control the border radius of buttons:

:root {
  --button-radius: 99999px; /* this is the default value */
  --input-radius: 8px; /* default is 0 */
}

 

Quote

I don't want toggle-style checkboxes, how do I go back to regular checkboxes?

This is one thing I couldn't find a simple way to do with CSS, so I went ahead and added a toggle in the original theme settings (Modules > AdminThemeUikit). You'll now see an option there to "Disable toggle-style checkboxes", should you want it. 

As you can see from the above examples, one of many nice things about the new default theme is that it's quite simple to tweak it for your preferences. Attached is my admin-tweaks.css example file that has all of the above, and a couple more small things too.

Please reply with your own custom CSS tweaks that you like. Thanks for reading and have a great weekend!

admin-tweaks.css

[adrian]

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

 

[adrian]

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

[monollonom]

Thanks for sharing @ryan.

Do the CSS selectors need to be this specific? Or is it because we have to overwrite styles written with less that tend to produce these (thanks to the nested selectors)?

For example:

.PageListActions a { }
/* instead of */
.PageList .PageListItem .PageListActions > li > a { }

/* or */

.InputfieldRepeaterItem > .InputfieldHeader { }
/* instead of */
.pw .Inputfields .InputfieldRepeater .InputfieldContent .InputfieldRepeaterItem > .InputfieldHeader { }

 

[ryan]

I don't know if they need to be that specific, I didn't have time to try out different versions. I wanted to post stuff that I knew would work the first time, but I wouldn't be surprised if many could be simplified. If you find any that can be let me know and I'll update the post. 

[bernhard]

Thx for adding some of my requests.

2 hours ago, adrian said:

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

+1! These toggles can be a no-go. And I think the current solution is a no-go as well.

Imagine you are a module developer and you want (or need) to use checkboxes in one place. What do you do? Instruct all your clients/users of your module to set their backend to not use toggles?

Easy solution? Not really... What if they had some modules installed that rely on the toggle-styled toggles? For example because they built an interface like this:

This interface would break when using checkboxes! Because checkboxes don't have this left-right pointing indicator.

I think there needs to be a better solution. And I think, again, that the new toggles look nice, but at what cost?

I think we module authors have to have the option to control whether something is a checkbox or it is a toggle. This can't be the decision of the style that is being used. Maybe you can make the toggle-styles only apply to container-divs that have the class "toggle-style" or something? That would be a progressive enhancement. All checkboxes would remain checkboxes and if you @ryan decide that toggles look nicer on the page editor's settings tab, go for it and add the class "toggle-style" there. If I develop a module where I think toggles look nicer, I can add the class "toggle-style" too. But if nobody decided to add that class, we should get good old checkboxes. And a working user interface.

[adrian]

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more.

I love css vars (I never jumped on the less/sass bandwagon), but they only work if they are distinct enough to modify everything as needed because if we need to mix and match between css vars and class/id targeted overrides it becomes an awful mess very quickly and things will surely get broken with future PW changes.

I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things).

I really wanted the background of the main nav to be darker color with white text, so went with:

:root {
    --main-background: #FFF;
    --text-color: light-dark(#444, #efefef);
    --muted-color: light-dark(#999, #efefef);
    --masthead-text-color: #FFF;
}

#pw-masthead {
    background-color: #c3d152;
}

but you end up with the placeholder for the search box white as well.



I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

[adrian]

--muted-color is also used for the page list action links but these should be highlighted, not muted. But regardless of what you think they should look like, they definitely shouldn't be tied to the same color as hidden pages. And is there a reason it's --muted-color and not --muted-text-color?

[adrian]

I think this has already been reported but can't find it. There is a really bad FOUC on smaller screens - the top nav shows before being hidden for the hamburger menu. Also, the close button on the hamburger menu is broken.

And another crazy css variable reuse --main-background also determines the background color when hovering over menu items in the hamburger menu. This doesn't work with the colors I am trying to work with.

[d'Hinnisdaël]

I would like to echo the request to get back proper checkboxes. ProcessWire provides distinct inputfields for checkboxes vs. toggles, so I'm confused to find that all of them now look like toggles. It's rather unintuitive and, as Bernhard mentioned, not amazing for module developers. Not sure what problem the global switch to toggles was solving, but I don't think there was a problem to begin with. Checkboxes are great, toggles are great, let's keep them separate 🙂

[diogo]

@ryan thanks for doing this work!

For process modules, I want to point out that you can use variables like this

color: var(--text-color, #000);

This will use the light/dark color from the new theme, but default to black if the variable doesn't exist and, therefore, work on the current theme also.

 

14 hours ago, adrian said:

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

I tend not to agree with this. The submenus have a completely different feeling than the main menu, since they are boxed and stacked vertically and allow for a much stronger marking with the background. The size of the font is also smaller and denser, and it's readability would suffer more with a lighter color. Also, unlike the main menu, the links in the submenus are not even marked with the active class, since many of them don't even represent pages, but actions.

 

15 hours ago, adrian said:

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

There seems to be a strong reaction against the toggles, and some good arguments. Although I would argue that, comparing to the light switch situation (referred on a blog post linked in the other thread), our toggles on and off states are unequivocally clear because of the use of muted vs strong colors. @jploch and I really like how the toggles look like in the theme, but are not insensitive to the requests. We'll discuss possible solutions with @ryan.

 

12 hours ago, adrian said:

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more.

I personally made a point in keeping the number of css vars low. I'm totally open to tweaking them, and adding a couple more, but I will definitely not add a bunch more. The idea of these variables is to allow users very easily create a different feeling to the admin, by only changing a few colors. Having few variables and making them depend, by default, on other variables, allows you to completely change all the colors with defining only 5 or 6 variables. You are correct that changing the background also changes the button text, the reason is that, like this I know for sure, that whatever colors you chose, there will be contrast between the background of the button and the text even if you don't define the (--button-color) variable yourself.
 
For a complete change and control of the admin theme (not only colors), I would say it's better to with the original theme or AdminStyleRock and LESS. Again, this doesn't mean that we can't tweak the variables to account for cases like in your example.

 

12 hours ago, adrian said:

--muted-color is also used for the page list action links but these should be highlighted, not muted. But regardless of what you think they should look like, they definitely shouldn't be tied to the same color as hidden pages. And is there a reason it's --muted-color and not --muted-text-color?

There's no special reason why it's --muted-color and not --muted-text-color. 

In our opinion, the most important information on pages list is the the name of the the pages, and the most important action is to find the page you need to work on. The action buttons are always the same, and so, it's much easier for you to find the one you want to activate, then looking for the correct page on the list. Most of the time you will even be clicking "edit", which is the first one to the right of the page name. That's a very automated process. Also, in our case, "muted" does not mean unreadable. We want the hidden pages to be as easy to find as the non hidden pages, and easier to find than the action buttons. For us, using a softer color makes it softer to the eyes that a string of words appears from nowhere when you hover the pages in the list.

Again, I'm willing to tweak the name of the variables to make them clearer, and even add a couple more variables to the list, but I wouldn't be happy to add a bunch of new variables and make the system more complex.

 

 

[adrian]

Hi @diogo - thanks for your thoughts!

I think the key thing here is that if you like the look of the new theme (and there are many things I do like), then it's great (checkbox/toggle issues aside), but if you don't like the look or just want to theme it easily to match a client's brand, then it's really painful to adjust - I think that is what most of us are taking issue with.

The key things I want to be able to do easily are:

• set the background and text color of the top level nav without it impacting the color of the dropdowns (like we could before)
• change the grey background to white and be able to fix the issue with the background color of the page actions row - personally I would really appreciate an option to go back to the button look without css overrides, but just being able to set the background of the rows without it impacting other things (I can't remember now what it was) would be fine.
• change the inactive state of buttons to match the primary color rather than using it for the hover state

Honestly, that would satisfy everything for me. Thanks for considering.

 

1 hour ago, diogo said:

the submenus are not even marked with the active class, since many of them don't even represent pages, but actions.

Other than Modules > Refresh, I am curious what else are actions and not pages? I really think the active class here would be great.

1 hour ago, diogo said:

The idea of these variables is to allow users very easily create a different feeling to the admin, by only changing a few colors. Having few variables and making them depend, by default, on other variables, allows you to completely change all the colors with defining only 5 or 6 variables.

Sorry, but even though this sounds good in theory, I really don't think it works in practice. You can't overwrite variables that are the dependents of other variables without consequences (unless there is something I am missing). And the contrast issues prevent changing 5 or 6 variables to get things working if you decide to go with darker over lighter colors for backgrounds.

1 hour ago, diogo said:

For a complete change and control of the admin theme (not only colors), I would say it's better to with the original theme or AdminStyleRock and LESS.

The thing is though, that with AdminStyleRock you only needed to change a couple of things to make a significant change. You can't actually do that with the new approach (and have it remain readable). But, I really love CSS vars and want to make this new approach usable.

1 hour ago, diogo said:

There's no special reason why it's --muted-color and not --muted-text-color. 

The issue with page list actions comes about when you want the background to be white and not the new grey. Now the white background highlighted color of the page list actions row doesn't work so the links to "edit" aren't very visible at all. Changing the background color of these has been other consequences because of the few css vars issue. So, I ended up restoring the actions to buttons using .PageList .PageListActions a, .PageList .PageListActions a:hover,.PageList .PageListerActions a,.PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { 

 

 

[ryan]

@adrian 

Quote

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more.

I'm still learning about CSS properties/variables, so I might be missing something. But based on what you've said above (and in other places), I'm wondering if you are missing the cascading and inheriting aspects of CSS properties/vars? Maybe you are thinking of them like PHP variables? They are quite a bit more powerful than that. If I understand it correctly, the actual number of variables you can customize is the number of CSS variables multiplied by the number of elements using it that can be targeted with a selector. We probably have thousands of customizable properties just with the set of variables we have now, where the selector is like the namespace for the variable. So when you set a value of something like --blocks-background, you are setting a default/fallback value if setting it within :root { ... }, and then, it may be overridden further down the tree. In your masthead example, you would target the --blocks-background within #pw-masthead, or something more specific within it. In your PageList example, you would target --muted-color within .PageList, or something more specific within it. So in my mind, it doesn't make sense to have tons of CSS variables unless you plan to treat them like PHP variables, which would be using them incorrectly. The current set of CSS variables seems well thought out to me, but I'm still learning. 

[ryan]

@adrian

Quote

I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things).

No, it is not a matter of time before the old one is no longer supported. I've said this a few times already, but the Original theme is not leaving. It is "base" theme of ProcessWire, and the one which the new Default theme depends upon. If some new feature is added, it has to be accounted for in the Original theme before the new Default one. If these themes were like PHP classes, then the Original would be like WireArray, and the new Default would be like PageArray... one inherits from and depends on the other. The new Default theme is not a separate theme the way that AdminThemeReno was a separate theme. If the Original style suits your needs better, there is no reason to transition.

[ryan]

Quote

I think there needs to be a better solution. And I think, again, that the new toggles look nice, but at what cost?

I don't have strong feelings about checkmark style versus toggle style checkbox controls. It sounds like some people do. I'm fine with regular checkmark style being the default rather than the toggle style, but I divert to the designers. I don't understand the strong feelings because they both represent the same selected (1) or not selected (0) states. You posted a screenshot with "light" (left) and "dark" (right) labels, and that is not what we are doing. Those labels make it represent something else. That relates more to our dedicated toggle Inputfield, which has an entirely different appearance.

In the physical world, the checkmark style represents something we would do with a pen, and the toggle style represents something we'd do with our hands on a machine. If I think of an airplane cockpit, there won't be any physical check boxes and marks. The same is true with literally any physical tool or machine we interact with. On my Android phone at least, there are no checkmark style inputs in the OS, they are all toggle style. So I'm quite used to them being one and the same as check marks, which is probably why I don't notice one way or the other. But I do prefer checkboxes when they are unlabeled and in the far-most right column of a table, like a delete checkbox, because it uses a little less space, even if a toggle style checkbox might be easier to click/tap vs. an unlabeled checkbox.  

[ryan]

Quote

I would like to echo the request to get back proper checkboxes. ProcessWire provides distinct inputfields for checkboxes vs. toggles, so I'm confused to find that all of them now look like toggles. It's rather unintuitive and, as Bernhard mentioned, not amazing for module developers. Not sure what problem the global switch to toggles was solving, but I don't think there was a problem to begin with. Checkboxes are great, toggles are great, let's keep them separate

Our Toggle Inputfield is a different animal, both in appearance and function. It represents 2-3 different labeled states, and an undecided state (4 states total) whether that means Yes/No/Unknown, On/Off, This/That/Other/None, Boy/Girl, Happy/Sad, Clean/Dirty, Off/Low/Medium/High, or anything else that has multiple named states. Checkbox fields, whether visualized as check mark style or toggle style, represent unchecked or checked, 0 or 1. I think a Toggle Inputfield might better be compared to radio inputs with labeled options like Yes and No, or something like that.   

[adrian]

46 minutes ago, ryan said:

I've said this a few times already, but the Original theme is not leaving.

I know this is the intention and I understand how the new one depends on it, but even if it remains that way indefinitely, module authors (in particular @bernhard) are already having to deal with differences between the two - will he support both or at some point give up and only support the new? At some point new modules will come along that only work with the new theme and so those of us using the old one will have unusable modules.

Software changes and in my experience you need to upgrade to the latest implementation sooner than later because at some point it will bite you and the longer you leave it, the more you will need to do to fix things.

[adrian]

1 hour ago, ryan said:

I'm still learning about CSS properties/variables, so I might be missing something. But based on what you've said above (and in other places), I'm wondering if you are missing the cascading and inheriting aspects of CSS properties/vars? Maybe you are thinking of them like PHP variables? They are quite a bit more powerful than that. If I understand it correctly, the actual number of variables you can customize is the number of CSS variables multiplied by the number of elements using it that can be targeted with a selector.

It might well be possible to do what you're saying (I have typically only used them at the root level), but I think what you're suggesting becomes very messy very quickly. Styling is complicated and I don't want to veer too far from the defaults of the new theme, which is why I listed these key things at the start of my post above: https://processwire.com/talk/topic/31277-weekly-update-– 30-may-2025-– customizing-default-theme-in-adminthemeuikit/?do=findComment&comment=249059

I think if we could handle those easily, we'd be ok here, giving us the ability to give the admin a quick color skin to match client's sites without having to adjust a million different things to avoid contrast issues.

[ryan]

@adrian 

Quote

I know this is the intention and I understand how the new one depends on it, but even if it remains that way indefinitely, -

Whether it's the intention doesn't really matter in this case because it's the physical reality of how it is constructed. They are the same AdminTheme, same markup, different styling. It also supports the ability for you to add your own themes. But if you want to do something more than what the Original does then you will still want to create a separate AdminTheme module. 

Quote

module authors (in particular @bernhard) are already having to deal with differences between the two 

Same here and this is totally expected. That's why we're introducing and testing this on the dev branch. But my preference would be that people report issues on GitHub rather than complaining or saying they don't like dark mode. We're working hard to help ProcessWire grow and bring something great to our current and future users. By the time we're done with it, the goal would be that it makes no difference to module developers whether the user is on Original or new Default. 

Quote

...will he support both or at some point give up and only support the new? At some point new modules will come along that only work with the new theme and so those of us using the old one will have unusable modules.

You can't make modules that only work with the new theme. The new theme (or others using AdminThemeUikit's theme system) all are limited by what's in AdminThemeUikit Original theme. Someone would have to create a new AdminTheme module if they wanted to do what you are suggesting. 

[ryan]

@adrian

Quote

I really wanted the background of the main nav to be darker color with white text, so went with:
...
but you end up with the placeholder for the search box white as well. I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

The problem is that you set your #pw-masthead text color to be white (#fff). It sounds like you want your search box to use the reverse. So all you would need to add is this (which doesn't strike me as messy): 

#pw-masthead .pw-search-form {
  --masthead-text-color: var(--text-color);
}

 

[adrian]

@ryan - maybe all our concerns will go away once all the bugs are sorted out. Maybe all of bernhard's modules will work without issue, maybe my issues with checkbox toggles not working in my modules with custom AJAX loaded tables will be fixed and maybe it will be possible to skin colors easily without contrast issues. Maybe then your point about them being the same theme just with different styling will be correct and this all won't matter. If that is the case, then I sincerely apologize for my frustration.

I think the problem is that it's actually hard for any of us to know what are actually issues that should be reported on Github vs decisions that have been made that we just have to deal with. 

I know you spent some time in the first post of this thread showing how certain things can be overridden and that is helpful, but I'd love to see you or konkat try to replace the grey background with white and make the main nav have a darker color (just a simple green or blue) and get an idea for the struggles that are had when attempting this. Here's another example I have just noticed. --masthead-active-color controls the color of the active top level menu item, but it's also used for all submenu items (which as we know don't have active or inactive states, so why is it used here?). I just don't see how that makes sense. For example, I want the green nav background and I want to distinguish the active page at the top level, but now the submenu items are also white. Is there a recommended way to deal with this?

I'd ideally like the submenus to not have the green background - which can obviously be down with overrides, but it just seems like skinning has become more difficult than it used to be and css vars should make it easier.

5 minutes ago, ryan said:

The problem is that you set your #pw-masthead text color to be white (#fff). It sounds like you want your search box to use the reverse.

Not really - I just want to be able to adjust menu text separately to the search box without needing overrides. 

[szabesz]

https://www.youtube.com/watch?v=EoEeRWHJ8xs

3 hours ago, ryan said:

Checkbox fields, whether visualized as check mark style or toggle style, represent unchecked or checked, 0 or 1. I think a Toggle Inputfield might better be compared to radio inputs with labeled options like Yes and No, or something like that. 

A checkbox is a checkbox and should not be confused with a toggle, I think. A toggle is not a skin for a checkbox.

https://infyom.com/blog/user-interface-design-tips-checkbox-vs-toggle-switch/

https://uxdesign.cc/the-good-the-bad-and-the-toggle-2abc0fbbd099

Quotes:

A toggle switch requires two steps: selection and execution, whereas a checkbox requires only the selection of an option, and the execution/saving action is normally required later or at a different area.

Usage recommendations

• Do not use toggles in forms. Use checkboxes or radio buttons instead.
• Do not use toggles in filters or multiple selections of elements.
• Inhale.
• Use toggles for settings and changes that have an immediate effect on the UI (same applies for the segmented control).
• Avoid mixing toggle button groups and segmented controls.
• Exhale.
• Avoid using switches with multiple options.

Edited May 31 by szabesz
typo

[diogo]

@adrian i maintain that we can tweak the variables for scenarios like yours. I don't see the default theme as highly customisable, and that's not the intention. For that we have Less. In my view, the default theme should be easily customisable, to a certain extent, for those who don't want many changes and also don't want to use Less.

I'll be on vacation for a week, so I won't be able to discuss changes with Jan and Ryan in the next days. For now you can change the color of the menus with:

.pw-dropdown-menu {
	--masthead-active-color: var(--masthead-text-color);
}

This changes the --masthead-active-color, but only inside the menus. For everything else, it remains how it is defined in the :root. The theme itself defines variables only in the root, exactly so that defining variables in other elements always overrides them without using !important.

[diogo]

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that.

Funny, just before submitting, i noticed this 😆

 

[teppo]

On 5/31/2025 at 5:55 PM, ryan said:

If I understand it correctly, the actual number of variables you can customize is the number of CSS variables multiplied by the number of elements using it that can be targeted with a selector. We probably have thousands of customizable properties just with the set of variables we have now, where the selector is like the namespace for the variable.

Yes, variables can be changed in a specific scope. That being said, I was also uncertain whether utilizing this was a good idea, or recommended. Mainly as it seems that it might be prone to cause issues at some point in the future.

To demonstrate, take this for an example (even if it was not used with variables specifically in the context of this thread):

.PageList .PageListItem .PageListAction > li > a:hover

That is a rather specific selector. If at some point in the future we needed to add an extra level of markup between ".PageListActions" and "li", or wrap the "a" tag in a "span" tag, etc. that would break styles relying on this selector.

(Yes, it's just CSS, but that would still be an undesired outcome.)

This is a benefit of having more, and more specific, CSS variables as well: if there was a --page-list-actions-link-hover-brightness variable, it would feel safe to use that. At the very least it would be less likely that someone decided to remove support for it from the admin style, as they would see right away that it will likely cause issues.

(And no, I am NOT suggesting that we need to go to this level with our variables; just using this as a hypothetical example!)

The point I'm trying to make here is that if this is what we are suggesting and/or recommending users to do, then we should be very, very mindful of making any structural changes in the admin. This may already be the case, so perhaps I'm just stating the obvious 🙂

If not making changes to structures in the admin seems unreasonable, one option might be to define "safe contexts", kind of like hooks for CSS variables — i.e. add a list of IDs or classes that "will not be changed or removed, no matter what". Things like "#pw-masthead", or "#pw-masthead .pw-search-form" from Ryan's examples, or ".pw-dropdown-menu" from Diogo's reply 🤷‍♂️