Dashboard Button Node - </>Class Field not working

[Steve-Mcl]

@MikeW

I have been doing more experiments from which I conclude that the treatment of the </>Class option in various nodes is inconsistent.

In what way?

The class is always applied to the outer element. The elements inside are dependant on the type of widget. That is true whether they are dashboard widgets or your own html in a ui-template.

@MikeW

I am now trying to migrate my nodes to the ui-template node to avoid this grief

That is a bit OTT. The only grief is knowing how to target the inner elements. You only need to figure out the CSS specifiers once for each type of widget/inner element then you can re-use them over and over in all your projects.

@MikeW

That said, a consistently working </>Class option does make good sense. But as implemented now, it needs to be caveated with warnings.

Did you read my previous post?

[jbudd]

Once again I apologise for confusing TextInput with something else.
And for "Jumping in".

It isn't clear if the Button node will be changed so that a class with border-radius will give the same rounded corners as with other dashboard nodes.

[zenofmud]

@Steve-Mcl Steve, I see what you mean but I think that what people wanted was to b able to add a class like myCSSoverRide and then in a ui_template node use something like

<style>
    . myCSSoverRide {
        background-color: red !important;
        color: blue !important;
    }
</style>

and if you do this in the ui_text_input node, the background will be red BUT the text will not be blue because there is CSS that is generated:

.nr-dashboard-theme .nr-dashboard-textinput input {
border-color: #111111;
color: #111111;
font-family: inherit;
}

where the CSS selector is more detailed and it take precedence so the text will be black and not blue. This is confusing because the Node help says:

If a Class is specified, it will be added to the parent card. This way you can style the card and the elements inside it with custom CSS. The Class can be set at runtime by setting a msg.className string property.

but not all elements are styled.

[Steve-Mcl]

@zenofmud

If a Class is specified, it will be added to the parent card. This way you can style the card and the elements inside it with custom CSS. The Class can be set at runtime by setting a msg.className string property.

but not all elements are styled.

They are, by the CSS selector you use in your styling. You can touch every element inside a card if you use the correct selector.

Example - using red as a class name on a text-input to set the input elements' background colour light red and the label elements' foreground colour red...

Any card with red class and containing a label or input

.red label {
    color: red !important;
}
.red input {
    background-color: #e3bfbf8c;
}

To be more specific and only target ui-text-input labels and inputs ...

.nr-dashboard-textinput.red label {
    color: red !important;
}
.nr-dashboard-textinput.red input {
    background-color: #e3bfbf8c;
}

Lastly, to be ultra specific (note how the !important hack is not needed now)...

md-card.nr-dashboard-textinput.red > md-input-container.md-block > label {
    color: red;
}
md-card.nr-dashboard-textinput.red > md-input-container.md-block > input {
    background-color: #e3bfbf8c;
}

---

The thing to realise is how would the dashboard style elements without its own classes? So to override them we need to be specific. The new class field permits you to target groups of elements (thus permitting consistent styles across multiple widgets) but you still have to target the things to style.

Lastly, to be able to use a simple single class name to override specific parts, every style-able element inside the card would need its own class entry and its own input on the editor to allow you to set a class against each internal part. e.g. a button is not just a button - there is a ui-icon element, a span and a div nested inside it.

Alternatively: If instead of putting the class into the cards class list (as we do now) we instead put the class on the button element - you still wouldnt be accessing the "visually styled" parts (which are the icon, span and div). And you wouldnt be able to style the parent container(s) either.

I do agree you need a level of knowledge as to what is inside the card (to be able to target them) but that goes with the territory. What may be beneficial, to help others, would be to put together a list of selectors that will affect what part of a widget.

something like...

widget	element	selector
any card	md-card	md-card.YOUR-CLASS-HERE
text input	label	md-card.nr-dashboard-textinput.YOUR-CLASS-HERE > md-input-container.md-block > label
text input	input	md-card.nr-dashboard-textinput.YOUR-CLASS-HERE > md-input-container.md-block > input
etc	etc	etc

---

Final tip: you can set multiple classes to combine styles e.g. blue-card bold-p-label underlined-label would allow you to combine 3 sets of styling

[MikeW]

Hi

Going back an email or so, I apologise if my comments upset anyone. I admire what you all do. And my CSS skills may not be that good, but this is what I mean by inconsistency:

Test of numeric node widget, switch node widget, text input node widget, and button node widget applying CSS styling through </>Class option:

numeric node widget

background color– does not work

background color with !important – does work

color– does not work

color with !important – does work

border– does work

border-radius– does work

padding – does work with one value (I did not test 2,3 and 4 value cases)

switch node widget

background color– does not work

background color with !important – does work

color– does not work

color with !important – does work

border– does work

border-radius– does work

padding – does work with one value (I did not test 2,3 and 4 value cases)

text input node widget

background color– does not work

background color with !important – does work

color– does not work

color with !important – does not work

border– does work

border-radius– does work

padding – does work with one value (I did not test 2,3 and 4 value cases)

button node widget

background color– does not work

background color with !important – does not work

color– does not work

color with !important – does not work

border– does work

border-radius– does work

padding – does work with one value (I did not test 2,3 and 4 value cases)

Cheers

[zenofmud]

Mike, no appology needed.

What is happening is that the new option will allow you to add a class (a CSS selector) to the md-card but that doesn't insure that all the rules you add in your CSS for that selector will be applied because of the nature of CSS. There for, you may need to add multiple classes as @Steve-Mcl was explaining.

@Steve-Mcl

You can touch every element inside a card if you use the correct selector.

And that is the key, using the correct selector. If you add a entry in the </> Class, the rules you add to that entry in your <style>...</style> may or may not work because of other CSS selectors automatically built that have a a higher precedence.

The bottom line is: CSS is complicated

[MikeW]

Hi

I have already been experimenting with adding multiple classes to the </>Class option, and where the selectors work this works nicely and provides some efficiency compared to putting all the selectors in multiple styles , ie either of bigfont and smallfont, can be mixed with either of color1 and color2; providing 4 style overall options

Cheers

Mike