CSS/styling of default widgets in Code tab?

I was wondering, whether it’s possible to tweak style (and classes) of the components, which make up standard (built-in) widgets.

I am using the oh-label-item list widget to display both actual temperature and - additionally - a setpoint temperature (in the badge):

The only thing I want to change here, is to add the margin-right-half class to the badge <span>, to get a little space between the two values.

<div class="item-after">
  <span class="badge margin-right-half">23.0 °C</span>
    22.7 °C

I could of course, define a custom widget and achieve all kinds of CSS changes that way. But for thi prupose, it seems a bit of an overkill.

So is there a way to add the config/class:xxx YAML in the compact YAML code tab?


Many thanks

There is no config for the list badge. To accomplish this you would have to use the stylesheet property and add the css directly.

I’m not sure what you mean by overkill here. This is exactly what the custom widget system is for. If you have a solution that would work then use it; there really isn’t any significant functional difference between using the built-in widgets and your custom widgets.

Thanks for pointing me in the direction of custom widgets.

Maybe, I’m making it too complicated. But: Really the only thing I want to do is use a, say, oh-label-item and populate the badge field as field (which works) and then display the badge field with a little gap before the label.

I have creaged an oh-labelbadge-item widget like so:

uid: oh-labelbadge-item
tags: []
    - context: item
      description: Item to be shown in lable
      label: Label Item
      name: item
      required: false
      type: TEXT
    - context: item
      description: Item to be shown in badte
      label: Badge Item
      name: badgeitem
      required: false
      type: TEXT
  parameterGroups: []
timestamp: Jan 3, 2024, 6:15:58 PM
component: oh-label-item
  badge: =@props.badgeitem

… hoping that I only had to specify the components, that I change/add. but no. Nothing works anymore. The icon (category), title isnt there, even the value isn’t shown…

So do I really have to “recreate” all parameters and all configs that are already part of the original oh-label-item? And if so, where can I find the YAML for that, so I don’t have to secondguess all of them?

I should have been more clear. My first comment is the direct answer here. If you are just doing this for one item then you can absolutely use the code tab on the default list item configuration page. You just don’t have to worry about adding a class to the badge (which is good, because there’s no good way to do this). You just have to add one short stylesheet parameter:

  badge: Badge Text
  stylesheet: >
    .badge {
      margin-right: 5px;

My second comment was more of a general one. If it were me, and I needed to do this for more than one single item then I would absolutely do it by creating a custom widget. As soon as you have more than one instance of a widget it will always be easier for modifications and maintenance if you build a single custom version of that widget instead of trying to remember where all the different individual ones that need editing are.

No, it’s true that when you make the custom widget you do have to go through the process of setting up each of the properties that you will want to be able to customize. That’s just the nature of the widget system. There are plenty of very nice list widget examples in the marketplace these days that can probably serve as quick and easy templates if you want one.

. That’s just the nature of the widget system. There are plenty of very nice list widget examples in the marketplace these days that can probably serve as quick and easy templates if you want one.

OK, but what if I wanted to reproduce the existing oh-xxx plus a twist. Is there somewhere where to copy the parameter section and the config section of the currently existing oh-xxx components? For example, I struggle to set the icon to the category parameter of the item definition. how to set title to what ever I specified as an Item-Label etc.?

If you want to build an identical clone of an oh- widget from scratch, then you need to refer to the .vue files in the ui source code repository. That is where (most of) the oh- components are found. There is no where that I know of where someone has translated all the component definitions into the custom widget yaml.

The problem with this approach is that although you could make it look identical, you will never be able to truly replicate the function of the oh- components because the widget system doesn’t give you access to the underlying javascript. You would have to start your clone from the source f7-list-item base but then that clone wouldn’t have the oh actions etc.

I do apologize for reverting on this seemlingly simple issue:

in solution a – use the Code tab – is there a possibility to reference any item members (like item.name to start with) in the Code tab to use simple expressions like:

  badge: ="item.name + "_Setpoint"

in solution b – create a custom widget – is there (just as miraculous upgrade in OH4???) now any possibility to refer to those item members (like item.category or item.label) so I can at least prepopulate the parameter fields with the information already included in the item definition? (somehow the oh-xxx widgets can do that).

I’ve never tried, but I doubt it. However, there’s not much to be gained by this anyway is there? These metadata configurations have to be entered manually on an item by item basis so there is no significant benefit to entering an expression each time over entering an item name directly.

The only way to do this is the same as ever. You need to have something (namely a repeater) in the widget that is making an api call to retrieve the entire information about the item. The default available information remains only the state, displayState, and one new piece, the state type (.i.e, OnOff state or QuantitySate). If the UI had to make an api call to fetch the full information about every item that was used in a widget on each page, it would slow to a crawl and it wouldn’t be worth it because >90% of that information would never get used.

True, but 1) they are not limited by the widget yaml because they are defined natively in the vue files, 2) the places where you see this happen (e.g., the model tabs) are specially built separately from the basic oh components, and 3) that doesn’t weigh down the UI as described above because the model pages can all be populated from one api call instead of individual calls for each and every item.