CSS rewrite and possible downside

Hi all,

Maybe some of you notice it, I’m actually working on hugely improving and optimizing CSS code.

This work is necessary to simplify CSS and with the work I have already done, this also make the UI even more consistent. Instead of writing CSS like before regarding UI parts, I rewrite it parts by parts, starting by similar items (for example: buttons) then adjust specific parts. CSS should be that way, using classes essentially for first step then id for specific parts. Thanks to @phweyland that remind me that darktable CSS was not respecting that CSS standard.

The only downside that this work will have is that it could break some personal CSS settings or theme you made. Note that tweaking CSS should be easier with this work.

I am also learning Sass to see how I can improve more CSS. I hope to finish that work for darktable 4.0



Intriguing! But I’d advise against pre-processors like SASS. Is it necessary now that CSS has variables? I understand if nesting could be valuable…

I say that I am also learning Sass to see how I can improve more CSS. I never say that I will add variables. Please avoid writing different statement that what I write. Just irritating.

Actually, I just started to learn Sass, I don’t know if this will change something on CSS. And if Sass is only about variables, be sure I will not lost my time with that.

Not a statement, just a curious question:


Without starting by below statement, that would have been easier to see it as just a question.

I’ve used sass quite a bit for our various website, please do ask if you have any questions or if I can be of assistance.

1 Like

For info, the CSS for darktable 4.0 is normally stabilized. Being deprived for about 2 weeks of my personal laptop (and thus of my development and photo environment. Damn!), the feature freeze being in a few days and the deadline for small safe additions set at the very beginning of June, it is now unlikely that I’ll move a few more things. Even if I would have liked to.
Fortunately, most of the work is done and the most important points too. The rest was just details. So it will be for darktable 4.2.

So, for those who use the Master, you’re safe for a few weeks if you adjust the code (the new classes used are detailed at the beginning of the CSS and those will not change, even for 4.2).

@paperdigits: so no SASS by now. I don’t know actually if I will use it or not. I’m quite stopped on UI work

For developers who read that, note that new classes to use are added as comments as the beginning of darktable.css file. How to correctly use class and id (and name them) is also explained. I posted those comments here:

/*** Naming class and ids:

  • classes should be named with underscores, starting by dt_ then what class does (main function). See below.
    Note that some remains with hyphens, they are Gtk ones and can’t be changed. It’s so also a good way to distinguish Gtk classes to darktable classes.
  • ids will be used with hyphens, with so item part name (for exemple: bauhaus-slider)
    Why that? Just because it’s a developer choice and most classes use underscore in code and id use hyphens. So make it easy and, more important, consistent to avoid being confused and make mistake that would cause bug just by wrong typing.

/*** Using classes and ids :

  • classes are used to set same settings for multiples and differents widgets in the UI.

  • ids are used to set a name to a specific widget and so allow to set CSS for this widget

  • some classes had been set on darktable, they all began with a dot. Before adding classes or ids, check what exist before

  • on those classes, some general ones had been set and should be added to your widget on Gtk code:

  • dt_transparent_background:
    • use it on a widget to set transparent background (except on hover) and no border
  • dt_no_hover:
    • don’t change css on hover (for dt_module_btn)
    • ex : colorlabels on header/footer bar
  • dt_ignore_fg_state:
    • don’t change foreground color on state change and don’t use bg if checked
    • ex : polarity buttons in blending ui
  • dt_module_btn:
    • set for all icons (button widget without text on it)
    • ex : btn in module header
    • for toggle button this is combined with a “standard” “toggle” class
  • dt_big_btn_canvas:
    • use it for some buttons that need to have bigger margin on button-canvas
  • dt_dimmed:
    • set all icons that need to be dimmed by default (typed text in search box when checking results and color labels icons)
  • dt_section_expander:
    • use it for all expanders you could add on a module
  • dt_section_label:
    • use it for section label text (titles in modules or some popover like overlays or guides lines ones). This set mainly whiter text and bottom-border line
  • dt_monospace:
    • set monospace font for some specific items (on some tooltips, history number or colorpicker values…)
  • dt_warning:
    • set all warnings messages inside panels, like deprecated modules messages or warning we could see when having white balance applied twice with color calibration and white balance modules
  • dt_bauhaus:
    • use it to set same settings on all bauhaus (sliders and combobox)
  • dt_bauhaus_alignment:
    • used for icons that needs to be aligned with bauhaus widgets in libs
    • ex : color picker for auto-tune setting in filmic or mask on same module and tone equalizer
  • dt_bauhaus_popup:
    • used for all bauhaus popup
  • dt_spacing_sw:
    • use it if spacing needed around some treeview (actually used in collections and tagging modules to have spacing on top and bottom margin regarding buttons/entries around
  • the list above is not exhausting. Those are main ones set actually and should be completed if needed. You could see other classes on this file