Dashboard element css classes

Dashboard
1

Can the list of css classes for a dashboard element be tweeked to include the element label (or name, or icon)?
This would allow custom css for each button.

For example I have two buttons "Power" and "Up". The HTML produced for each one is
<button class="md-raised md-button md-ink-ripple" ...
Untitled 1

If it was eg
<button class="md-raised md-button md-ink-ripple Up" ... I could increase the font size in the Up button through CSS

I know it's possible to create a button entirely in a template node but my use of templates isn't that advanced yet, I only define CSS there.

2

A workaround ...

use the id of the node in a selector (you find the nodes id in the sidebar under the info tab) e.g...

ui-template node (set for head)

<style>
[node-id="1f9886f1.f40569"] > button {
    color: green !important;
    background-color: purple !important;
}
</style>

but I agree, having the ability to specify an additional class or classes on the UI items like button and label etc would simplify this somewhat.

2 Likes
3

Thanks for that suggestion Steve.
It is a viable work-around. Using
[node-id="d516453f.5bb218"] > button i {
font-size:86px !important;
} I can change font size on that specific button:
Untitled 2
Are node ids static? If I imported the flow from a backup would I still have the same ids?

Incidentally the colour and background colour in your example can also be specified (better?) by means of msg.background = "#ff0000"
and background {{background}} in the node properties

4

Once set, yes, static.

Is that a question?

Of course you can use #xxxxxxx colours but if you want it dynamic (sent from a msg), you might as well use JQuery & a ui-template script to set the $('.selector').css("name", "value") of the item.

5

Was that a question? No, just commenting that those two style elements (for a button at least) can also be set in other ways:

From Help for ui_button
The colours of the text and background may be set. They can also be set by a message property by setting the field to the name of the property, for example {{background}} . You don't need to prepend the msg. part of the property name.

The label and icon can also be set by a message property by setting the field to the name of the property, for example {{topic}} or {{myicon}} .

"JQuery & a ui-template script to set the $('.selector').css("name", "value")" goes over my head, sorry!

6

How would the class name be set ?

7

No idea :smiley:

I seem to remember seeing a pattern in some JQuery UI widgets - they have a class or className option that gets appended to the classlist when the widget is instantiated. This permits you to fine tune styling of the element after creation. (though I cant find an example right now - doh)

8

Maybe a field in the node properties in the editor - "CSS Class"?

Just thinking about buttons, that would mean I could easily have round and square buttons, backgrounds etc on the same dashboard.
There would have be to be a template node of course but it would only require CSS, and could be in the page header.

9

so now every UI config panel has to make room for a class field that most users won't need, adding to the complexity... hmmm.

10

My first thought was to include the element name in the CSS classes list. That doesn't mean an extra field in the config panel.

11

The concept of having class for every item is in straight conflict with css specification so should be avoided. The id may be under discussion but not the class.

12

though id has to be unique across the dom - and no way to guarantee that (if users are allowed to choose)

13

In what way @hotNipi?

Bear in mind, it would add a class entry where you specify a value (if nothing was specified, nothing would be added to the class list)

What is the recommended way to style a groups of similar items these days? e.g. .square-button { ... }s and .round-button { ... }s?

14

Button with Id 123 should have same class as button with id 234. That way. Value (name, label or what ever kind) based commonness should be kept as id related. And if there is name based structure for those, that will be helpful for overrides.
To have different types of buttons with different classes (provided by one widget) to drive their look it may be the thing of widget configuration so the class is created. But it is all advanced stuff. The user without any experience of HTML and CSS just can't use them as they are things based on at least some knowledge on that area. Providing such advanced stuff falls on area of distraction rather on being helpful.

Also the id has higher specificity in CSS hierarchy so it will be much easier to to have effect on current dashboard structure. But that is just small technical limitation to get over.

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.