Could you please add a specific class that identifies the burger icon of the Menu component?
So that in this case it is possible to select it with CSS to modify the styles?
2 Likes
Ahhh interesting, that would be one for @ben to take a look at 
@ben and how can I to select with CSS the active menu item color, to change that color?
Do you need CSS? Can be done under Font and Text Style. Click on Active State and change the colour there.
I need to edit che active item color via CSS.
Yeah sorry. Good news is I have worked out how to change the colour of the burger as well which I was trying to do the other day.
Could you share a bit more about your specific use case?
We’re generally hesitant to add non-Tailwind classes to the output HTML. One of the guiding principles of Elements is that all styling should be handled through Tailwind, which serves as our design system. This ensures consistency across all projects, templates, and components, and avoids fragmentation or reliance on hardcoded class names.
In Elements, control over styling is intentionally placed in the hands of the user, using our built-in styling controls, not via custom classes attached to components. This design decision is meant to keep things modular, scalable, and consistent.
Also, introducing a custom class for something like the hamburger icon raises broader questions:
- What happens if a user swaps out the current Menu component for a different navigation component in the future?
- Would every nav component need to support this same class?
- What happens to your custom styling if that class isn’t included?
These kinds of dependencies break the core principle of Tailwind and Elements — they move styling control away from the system and into fragile, inconsistent overrides.
That said, if we understand what you’re trying to achieve, we may be able to guide you to a cleaner solution using Tailwind utilities or built-in controls 
The active menu item color is controlled via the styling controls in the Menu component. We don’t expose a class for this, again in keeping with the Tailwind philosophy — styling should be declarative and scoped via utility classes rather than traditional CSS selectors.
If there’s something the built-in controls don’t allow you to achieve, let us know what you’re aiming for and we’ll see how we can help — or whether it’s something we should consider expanding in a future update.
Hi Ben, thank you for your answer. I understand the philosophy behind Elements, and I basically agree with this thought.
However, it may happen that you need to change a style, and to do so in certain specific cases it may be useful not to use a Tailwind class. And this thing will not necessarily create an irreparable rift.
I understand the coherence in wanting to use only Tailwind classes, but on the other hand I also consider “coherence” the fact of choosing a theme for a website and maintaining it over time without having to change it every day at will (just because the theme styles are coherent with each other).
A small style change with CSS certainly does not upset the general coherence.
As I anticipated in another post, I am creating a custom component called SlideBar, among the options there is that of overwriting the colors of the links of the Menu component (of the svg logo, of the menu items and of the buttons) placed inside the SlideBar when the SlideBar is in the “stuck” state.
I would just like to be able to set the color of the burger icon when SlideBar is in stuck state, but if there is no class name that precisely identifies that icon it becomes difficult with css to select it.
I think it would have been useful for the user to be able to change that color in the ‘stuck’ state but if it is not possible and this thing is against the rules then let my request go.
This sounds like a great use-case for a Global. A user could create a Global Menu component, and then use the Global overrides feature to adjust the link/icon colours when placed inside a SlideBar.
This approach keeps the styling control in the hands of the user, rather than relying on styling being inherited or overridden by the parent component.
Let’s say the user places a Menu inside your SlideBar. If the SlideBar is overriding the Menu’s colors directly, then when the user clicks on the Menu to edit it, the colour settings they’ve chosen won’t visually match what’s actually being displayed — and that’s likely to cause confusion.
Confusion is bad 
You can target it using a custom CSS selector like:
nav button[x-data] > svg
Of course, this approach relies on the current HTML structure, and it could break if the internal structure changes — but that’s also a risk even when depending on a specific CSS class name.
There are no strict “rules” around how you build your add-ons — you’re absolutely free to approach things in a way that best suits your project.
That said, for built-in components, we follow a clear design philosophy: styling is controlled via our utility-based design system (Tailwind), with the goal of keeping everything predictable, modular, and consistent. That’s why we don’t apply extra classes or enforce parent-child styling dependencies — the user is always in control.
ok