# Dashboard Button Node - \</\>Class Field not working

**URL:** <https://discourse.nodered.org/t/dashboard-button-node-class-field-not-working/52651>\
**Category:** Dashboard\
**Created:** [24 October 2021 09:53 UTC](https://discourse.nodered.org/t/dashboard-button-node-class-field-not-working/52651 "2021-10-24T09:53:12Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [31 October 2021 10:17 UTC](https://discourse.nodered.org/t/dashboard-button-node-class-field-not-working/52651/19 "2021-10-31T10:17:34Z")

</div>

> [@zenofmud](#):
>
> I think the option has opened a can of worms that is going to cause users confusing until the dashboard is rewritten. Users who want to change the defaults are still going to have to use a browser inspector's tool to examng each widget they want to effect and write CSS selectors specific enough to address the area tehy want to change. You know, kind of like what they've been doing all along. 😐

The point of adding `class` option wasn't to overcome the classes dashboard applies or even to reduce specificity it was to provide a means of setting uniform styling.  
An additional side benefit was being able to dynamically set/adjust the `class` at runtime.

While yes, the dashboard styles and outer elements mean you have to increase specificity in your CSS (or apply the heavy handed `!important`) its still better than having to address all items individually.

**For example...**  
Say you have a dashboard with 10 blue buttons, 10 red buttons, 10 danger labels, 10 warning labels & 10 info labels...

Without the `class` to differentiate the blues from the reds or the danger from the warning from the info labels, you would have to write the styles for 50 items (to target them specifically)

With the `class` you add `red` class to 10 buttons, add `blue` to the other 10 buttons (and so on) then simply target them by differentiating them using the class name

* * *

> [@zenofmud](#):
>
> I understand the idea of the `</> Class` option (I was one of the peoplewanting it) is to provide an `easy` way to apply a change to a single instance of a ui-widget, but in some cases, it doesn't create a CSS selector that it specific enough to override other CSS selectors that are created. The dashboard theme options are taking precedence.

This is (kinda) true - you just need to be more specific. For example, these three buttons have a hard coded background of `red`  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/c/4/c4621bf76c7e6b89ae918c69639c67c195ef8654.png)

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/4/140cf1b2e711b7ce72695c27ea785f08e0876234.png)

however by using the below CSS, I can target every button with a class of `.button-error` to "over power" the background style entry

```css
.button-error.nr-dashboard-button button.md-button {
    background: rgba(255, 0, 0, 0.5) !important;
    color: rgb(30, 0, 0);
}

```

* * *

Lastly, here is a demo i was using to test things when developing the class entry. It demonstrates how multiple items can use the class (for uniformity) and buttons being styled and how one can dynamically set the class of a widget...

![pzIZYRN0PJ](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/c/fcf4fd50081316ec9aad15165b4aaad062450147.gif)

* * *

Hope that helps?

---

_[View the full topic](https://discourse.nodered.org/t/dashboard-button-node-class-field-not-working/52651)._