[GH-ISSUE #1228] css appearance for modules with multiple gtk #7400

New issue

Open

opened 2026-05-23 02:54:16 +01:00 by JakeStanger · 1 comment

JakeStanger commented

2026-05-23 02:54:16 +01:00

Owner

Originally created by @xMAC94x on GitHub (Nov 2, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1228

Is your feature request related to a problem? Please describe.
When I want to specify the css of some modules. Especially models like clock and and battery are composed out of multiple gtk elements (e.g. a button and the label ). Its hard to differentiate them. Especially when i want to differentiate the button of the clock from the button of the battery.

Note: sometimes (e.g. Battery) the button has a hardcoded class .button, sometimes (e.g. clock), such a hardcoded class is missing.

Describe the solution you'd like
I want to have a clean strategy that describes how we handle css classes (and namings) of such multiple composed modules.
Possible strategies might be:

We already have .class as apperance modifier. If a module is composed out of multiple gtk elements, we always give that .class to the top level element and then allow to use descendant selectors .customclass > button. when there are multiple top level elements, they have to be wrapped in something (like a div)
We choose to apply the .class to all gtk elements and let people select via label.customclass, however this might cause issues when there are multiple labels
We add additional properties to the modules, which users can specify to have custom classes for e.g. the button of a clock. e.g. buttonclass
We dont add properties to the modules, but we choose to consistently hardcode specific css classes to specific things, e.g. give all buttons the hardcoded .button class.

Describe alternatives you've considered
If such a strategy already exists, I would love to see a short section in the styleguide with some examples.

Originally created by @xMAC94x on GitHub (Nov 2, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1228 **Is your feature request related to a problem? Please describe.** When I want to specify the css of some modules. Especially models like clock and and battery are composed out of multiple gtk elements (e.g. a button and the label ). Its hard to differentiate them. Especially when i want to differentiate the button of the clock from the button of the battery. Note: sometimes (e.g. Battery) the button has a hardcoded class `.button`, sometimes (e.g. clock), such a hardcoded class is missing. **Describe the solution you'd like** I want to have a clean strategy that describes how we handle css classes (and namings) of such multiple composed modules. Possible strategies might be: - We already have `.class` as apperance modifier. If a module is composed out of multiple gtk elements, we always give that `.class` to the top level element and then allow to use descendant selectors `.customclass > button`. when there are multiple top level elements, they have to be wrapped in something (like a `div`) - We choose to apply the `.class` to all gtk elements and let people select via `label.customclass`, however this might cause issues when there are multiple labels - We add additional properties to the modules, which users can specify to have custom classes for e.g. the button of a clock. e.g. `buttonclass` - We dont add properties to the modules, but we choose to consistently hardcode specific css classes to specific things, e.g. give all buttons the hardcoded `.button` class. **Describe alternatives you've considered** If such a strategy already exists, I would love to see a short section in the styleguide with some examples.

JakeStanger added the

T:Core Enhancement

A:Config

labels

2026-05-23 02:54:16 +01:00

JakeStanger commented

2026-05-23 02:54:16 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 19, 2025):

Every module already has a classname matching the module name. Eg you can already target .battery and .clock. It's also possible to add your own classes and names to any widget.

Is there something additional you're asking for here?

@JakeStanger commented on GitHub (Nov 19, 2025): Every module already has a classname matching the module name. Eg you can already target `.battery` and `.clock`. It's also possible to add your own classes and names to any widget. Is there something additional you're asking for here?