[Feature request] Support a small subset of CSS (or CSS-like) rules

[rubyFeedback]

I would like to propose that conky supports, in addition to the current way, CSS-like properties. (If this is the case it would be nice to indicate this via the main README).

Not all CSS properties make sense, but things such as colors would be nice; and perhaps more effects if conky supports
these. Would be even fun to see conky support hovering properties, and neon-like glow effects, but I don't want to make this request here too fancy, as someone has to implement that, and that may take time; and time is a finite resource. So, I would suggest CSS-like properties.

One important part of this proposal is to support external files - here, I mean local files, but something like:

conky_colours.css

This can also be used on a website, by the way, so we get both: support on the www, AND support within conky itself. People could also more easily share their conky-rc files, e. g. the skeleton where the logic resides, and then shuffle in or out different .css files (or, rather, the SUBSET that conky may support; again I am not saying all of CSS should be supported, only the parts that may make sense for conky).

The benefit here would be that it lowers the entry-threshold for new users; and another benefit is that we can share and re-use the main design (excluding the skeleton, although it would be nice if conky could support HTML widget-like properties too, but for the purpose of THIS issue request, I really only want to focus on CSS-like properties. Someone else would have to propose HTML-like widget support. Buttons would be cool, but here I focus only on CSS).

That's mostly the gist of it. Perhaps ID (identifiers) may have to be supported too, so we could arbitrarily name the conky properties, such as foo1, foo2, foo3, and within the CSS identifier also refer to them e. g. #foo1. Note that I am not necessarily suggesting conky supports such sub-elements either; for a first step it should suffice if conky can work on perhaps simple:

.pink  { color: pink }

Or something like that. (Or even RGB colours if that can be parsed); and the ability to tag them onto conky-elements, such as "for this header, I want to use green colour and padding 8px and underlined text". Something like that, but usable via CSS properties IN ADDITION to the current way that works. So this is an additional use case, not at all meant to REMOVE the existing way.

[Caellian]

I see this idea often suggested on similar projects, but I disagree and here's why:

CSS is just a different (less powerful) syntax to do the same

CSS isn't Turing complete (technically, there's dark and verbose ways to make it), Lua is. There's still space to improve Lua things in conky (e.g. supporting change in conky.config after initial load). On the other hand, CSS is completely static - by design, to make browsers performant.

Conky doesn't currently utilize any, but we could (if needed) add proper lambdas, nested tables, lists, etc. to the conky.config. CSS is a bit more powerful in this respect because it allows values to be anything that doesn't contain ; or } characters, but hsl(120, 50, 50) is not much better than "hsl(120, 50, 50)" IMO.

CSS isn't a magic pill

There's two specs related to CSS: CSS syntax and CSS.

Support for different color formats in CSS comes from browser code (latter spec), not from CSS parsing code (former). CSS parsers simply spit out color in 8/9 different formats, and then browser is expected to convert all of them into sRGBA before rendering (which uses a single color format in its pipeline).

So, for colors, it's much easier to just implement parsers and conversion functions for different formats directly to conky, than it is to do all that and then add a new syntax support on top of that.

Same goes for all other CSS features (i.e. CSS, not CSS syntax) - they're requirements for how the browser should (browsers are often inconsistent) handle different properties. Conky barely handles layouting at the moment and has a much simpler render pipeline to that of a browser which makes it difficult to implement many of CSS features.

What classes and selectors?

CSS is used to style HTML elements, it's designed around this idea. Conky in contrast has no concept of components and elements, and could only make use of a few selectors (namely :hover, :active). So even if conky did implement a CSS parser, you could only style a single element. This seems like an overkill way of going from background = "#123456", to background: #123456;.

It might seem like different parts of conky.text are elements, but they're just text segments. Think of it more like rich text content than actual components. Turning a rich text renderer into a component renderer is very complicated - so much so it would be more feasible to rewrite conky on top of a UI toolkit instead of letting it do its own rendering. There's a big tradeoff in performance vs. functionality there and I feel conky is supposed to be lightweight.

I recently added mouse events and that code alone is HUGE compared to the rest of X11 code. I imagine that adding keyboard events, layouting, components, etc. would double the size of conky. It feels more reasonable to simply make conky spit out text (and JSON), and then write a separate (flashy) GUI app that uses conky as input for displaying all the information conky gathers. Supporting all those features for both Wayland and X11 is also much more work than a single person can reasonably handle.

CSS imposes expectations

When people see CSS syntax, they tend to think that the app using it can do everything the browser can, and then get disappointed when they realize that it doesn't and get angry and argumentative. Browsers are some of the biggest blobs of dynamic rendering code in existence, they have huge teams that have been working on them (and optimizing them) since the dawn of the internet.

I just closed 3/4 issues (or turned them into enhancement suggestions) where people assumed bugs for features that aren't implemented. CSS would make it hard to find actual bugs because the issue tracker would be spammed with issues like "inner box-shadow doesn't seem to work" or "clip-path doesn't do anything".

With Lua settings, we parse and handle each option individually, CSS allows you to write garbage and browser is expected to silently ignore invalid options/values. This leads to huge number of bad issue reports for browsers because people don't always know what the expected behavior is. This is fine for browsers because they have teams dedicated to going though through the issues and financial backing for that, conky doesn't.

Concatenation of tables

Lua tables can be manipulated in the script, there's nothing stopping people from separating their "appearance" options from "functionality" and doing conky.config = {table.unpack(appearance), table.unpack(functionality)}. But assuming you don't tinker with conky on the daily, you can just copy someones dotfiles and modify a few values. Having a separate CSS file doesn't really improve on ergonomics of doing that.

What does help is having a layouting engine implemented and supporting stuff like flexbox and css grid. Adding those to conky would require an insane amount of changes and code.

CSS is use-case specific

As I've previously said, CSS is made for web content, conky isn't designed to render websites. More than half of CSS spec doesn't apply to conky, and syntax doesn't really help conky do anything Lua can't.

Alternatives

• Support for parsing and converting different color formats is something that can be added to conky without the rest of CSS parsing (and is a welcome contribution if someone has time).
• Support for different effects (blur, shadows, ...) can be added to conky without CSS.
• "on hover" effects can also be added just the same, in fact, it can be a function that takes in "hover duration" argument, allowing you to do both interpolation (like browsers) and other effects, without using keyframes (which are cumbersome anyway).

[Caellian]

After #1841 gets resolved (accepted/declined), I could add support for including alpha in hex codes, this would supersede the need for own_window_argb_value, and maybe a rgb[a](red, green, blue[, alpha]) parser. If own_window_argb_visual is off the alpha would just be overwritten to 0xff.

Part of #1841 allows easy chaining of string parsers for colors, so it'd be easy to add new formats. hsl, oklab, etc. require extra work for (correct) conversion though.