I tested it in the docker demo of Custom Sidebar which is a Home Assistant instance just with Custom Sidebar installed and it doesn’t occur, so that seems something else on your side, most probably it is coming from your theme (seems like a rollover style to me).
It should be the same, just use the same styles under card-mod-sidebar-yaml with a card-mod theme.
Yes, it should override it. You just need to make sure that your custom style has a higher specificity than the one that you want to override.
just discovered the little hack to have the menu title execute an action does not work on my companion app
this is the partial
titleClick: |
window.titleClick = () => {
const path = '/ui-overzicht/welkom';
window.history.replaceState(null, '', path);
window.dispatchEvent(
new CustomEvent(
'location-changed',
{
detail: {
replace: path
}
}
)
);
};
and this is set on the item itself
title: |
[[[
@partial titleClick @partial title
return `<span style="cursor:pointer"
onClick="javascript:titleClick()">
Rumah kami: ${tijdStr}
</span>`;
]]]
would that be expected?
Yes, if it is the Companion App on iOS (which uses Safari WebViews) that code should be problematic (Safari in mobile is known for ignoring click events and also any interactive event in elements that are not links or buttons).
Also, I am seeing that I made a mistake in the code that I gave you before. It is not React, just plain HTML, so it should be:
<span onclick="javascript:titleClick()">
Instead of:
<span onClick="javascript:titleClick()">
But let’s try to make some tests to see what code makes Safari WebView happy. Try with an ontouchstart event:
<span ontouchstart="javascript:titleClick()">
If it works, then it is possible to make a code that works for desktop and the App.
Remember to clean cache on each test.
perfect!
I have it like this now, and working both in Desktop browser And Companion app
title: |
[[[
@partial titleClick @partial title
return `<span style="cursor:pointer"
ontouchstart="javascript:titleClick()">
Rumah kami: ${tijdStr}
</span>`;
]]]
Perfect. Take into account that it is a touch event, if your desktop device has a trackpad it can capture them but for example mouse clicks will not work.
right… I believe I had tested that, but now, after updating to B9, I can no longer navigate on my Macbook using the trackpad… (no Mouse attached)
that is a pity really, I need to more on my Desktop than in Companion app.
its not a Safari thing, also Chrome is borked now.
wonder why I didnt see this before the update, I am sure the cache was clear (it is not used at all/disabled) and I did clear it anyways…
Mouse pointer is still the Handle so that part works
update
believe using both works:
title: |
[[[
@partial titleClick @partial title
return `<span style="cursor:pointer"
ontouchstart="javascript:titleClick()"
onclick="javascript:titleClick()">
Rumah kami: ${tijdStr}
</span>`;
]]]
That is the normal behaviour, desktop devices do not respond to touch events, unless that you have a special device that detect them or a special screen that is capable of reacting to them, so if it was working before it was not expected.
Instead of adding both events you can check capabilities first and then return the code with the correct event. Try with this:
title: |
[[[
@partial titleClick @partial title
const event = 'ontouchstart' in window
? 'ontouchstart'
: 'onclick';
return `<span style="cursor:pointer"
${event}="javascript:titleClick()">
Rumah kami: ${tijdStr}
</span>`;
]]]
wish I could give 2 hearts there 
nice, thanks a lot, this is becoming a fine css javascript masterclass …
Hi @elchininet , thanks for a great project and especially your homeassistant-selector library. I don’t use the custom-sidebar directly, I just needed to sort the sidebar items into groups. For that I used some of your source code, and the selector library to create my dream sidebar. 
I added the copied div.divider element to the sidebar, then assigned each item a new attribute with its own group, also for the divider element. The divider has an event listener to click and a handle to toggle visibility of the group items. Toggle of these ‘groups’ is similar to _panelOrder in sidebar, which is stored in localstorage, so visibility of these groups is stored and synchronized for all tabs. 
I have checked the documentation, now custom sidebar offers only to edit style divider without click function, it would be great if you add this feature in the future. I think a lot of people would appreciate this feature. 
Hi @VietNgoc,
Looks good. 
FYI, several things that you did there could be done just adding the proper configuration: using reactive variables to hide and show the children and some custom CSS for the groups items.
Unfortunately, it is not possible to add a feature to click on dividers. Dividers are not clickable because they are not elements but pseudo-elements of the sidebar items, so if the divider property is set, it just adds a pseudo element in that sidebar item. But as I mentioned, it could be achieved if a regular element is styled to hide its icon and add a divider to it.
Hi @elchininet, many thanks for this great project and the detailed documentation. custom-sidebar works wonderfully and I was able to set everything in sidebar-config.yaml the way I wanted it. Since I have a lot of entries, I would like to go one step further and group the items. You mentioned in the post above that this could be done just adding the proper configuration: using reactive variables to hide and show the children and some custom CSS for the groups items. I’ve looked at the custom sidebar docs and I have to be honest and admit that I don’t understand the instructions there about reactive variables and certainly can’t implement them for grouping items. I imagine I’m not the only one with this concern and limited technical skills. Would it be possible for you to provide some snippets for grouping items?
Hi @RoLiFru,
I have plans to create a blog entry with that topic when I have some time. But reactive variables are explained in the documentation and if you look at the release in which reactive variables were implemented you will find an example of hiding and showing a sidebar item clicking on another item. Well, if you set the same reactive variable in the hide property of multiple items, all of them will get hidden or will be shown when the desired item is clicked. On top of that, if you create a specific style for the children (for example, a bigger padding-left and a different color) you can make them look like children of the parent. Let me know if you don’t understand something but if you cannot get it, as I mentioned, I have plans of creating a blog entry about that, I’ll let you know when it is ready.
Regards
Hi @elchininet ,
after some experiments I managed to get the result I wanted on my home-screen Tablets 
Thx for this nice addon.
If I set the hide_all: true, I have the problem that on the Companion App I am not able to enter the settings anymore ?
Even if I create a link to /config.
Maybe somebody has figured this out and can point me to the right direction ?
If someone has the correct link to enter app-settings even if not admin, please let me know and maybe add it to your wonderful documentation
Greetings,
Kilowatt
Could you explain a bit better what issue you are facing? I can help you out, but first I need to understand what the issue is.
Hi,
I tried to use hide_all: true and then in the companion app the link for settings (sensors and so on) disappears.
I added a new Entry with href to /config but this is not working to.
So when setting up a new Companion App it is not possible to make sensor settings
Greetings Kilowatt
In that case you don’t need to add a new entry because the config item already exists but hidden, you just need to show it:
hide_all: true
order:
- item: settings
hide: false
Check this entry out.
thank you very much for your explanation. I tried your linked example of hiding and showing a sidebar item by clicking on another item and get the parent item (named “Example” in your example), but clicking on it does not show the child. I am definitively missing out on something and will be happy to wait for your blog post and then make another attempt. Thank you once again for all your work and for answering the users’ questions! Regards
Make a backup of your configuration and try with a minimum example just with two items and check if it works. If it works, start adding one by one the rest of your configuration until you figure it out where the issue is, if it doesn’t work, post your code and I’ll check it out in the docker demo.
With the fast development of this custom plugin, there is something that has become more obvious:
leaving the instance and getting back to it seems to not cause an auto update of the frontend. This most noticeable in my header template where I have the time…
In the morning it simply shows the last time I opened the app the night before.
Or after posting this… I left for 8 minutes as you can see :
Also, on 1 of my items, the Energy tab, I have set a notification template. This stalls when leaving, and, after returning there, one can see the complete history of that entity state race in that notification.
It’s a fun effect, but nor really as it should be imho.
js_variables:
# energy
netto: sensor.netto_verbruik
partials:
energy: |
const nettov = states(netto) < 0;
order:
- item: energy
match: href
order: 7
icon: >
[[[ @partial energy
return nettov ? 'mdi:home-lightning-bolt'
: 'mdi:home-lightning-bolt-outline'; ]]]
icon_color: >
[[[ @partial energy
return nettov ? 'var(--power-color)' : 'brown'; ]]]
#this is the entity that stalls, and when getting back to the menu later, it races all past historic values...
notification: >
[[[ @partial energy;
return states(netto); ]]]
In the current 2025.3 beta, Bram has inplmeneted an auto update front-end refresh, but it does not help with this sidebar effect.
Maybe you can have a look why this happens, and if the new feature in the Frontend could be used to also update the sidebar?
I did read this:
https://elchininet.github.io/custom-sidebar/advanced-configuration-options/javascript-variables
more importantly the final Important section.
However, I would expect a header to follow the state of the sensor at all times in this case?