CSS for styling

[VisenDev]

Related #133

I think it might be interesting to experiment with using CSS for styling. CSS is fairly simple and standardized, so it should be intuitive for most people. I got this idea seeing how waybar uses css for its styling and how simple that was.

I'm not sure I'm completely happy with the new situation of using QuickTheme and Theme to decide styles, so here are some alternative thoughts for what CSS styling implementation might look like.

• dvui.Options would be given css_id: []const u8 and css_class: []const u8 fields
• Child widgets would inherit styling rules from their parents unless overriddened
• Concept of what a CSS Style type might look like

  const CssStyle = struct {
     @"font-family": [][]const u8,
     @"font-size",
     color: [7]u8,
     background-color: [7]u8,
     //other standard css options here
  }

  • When rendering, widgets would query the "global dvui css state" with all the information about the current widget, such as css-class, css-id, parent widgets, hovered status, clicked status, etc... Then css state would then use these css selectors to determine how that widget should be rendered.

Example of the jungle theme might look implemented in css

body {
  font-size: 18;
  font-family: pixelify;
}

heading {
  /* Heading font-size will be 75% of body's font-size*/
  font-size: 75%; 
}

caption {
   /* Caption font-size will be 75% of body's font-size*/
  font-size: 75%; 
}

title {
   font-size: 150%;
}

text {
   color: #82a29f,
   background-color: #2c3332,
}

text:active {
  /* Pressed text styling here*/
}

container:hover {
  /* hovered styling here*/
}

/*etc...*/

[david-vanderson]

I'm all for experimenting, but it would take a lot to convince me that using css is a good idea.

But the quesion of how separable code and styling can and should be is an open question. We currently split the difference where sizing is generally controlled locally whereas font/colors come from the theme (but fonts affect sizing sometimes). This was a result of my early experience and I'm reasonably happy with it so far.

I think any change in this area will have to be motivated by what someone is trying to accomplish in a real application. I hear you and agree that Theme/QuickTheme doesn't quite feel right, but we are making progress and it's pushing other areas forward (like naming fonts is getting us closer to loading them at runtime), which I very much appreciate!

[iacore]

We can try out the cascade stylesheet DSL in Zig first before we try out concrete CSS syntax.

CSS is essentially predicates.

If <selector>, then <apply rules>.

We don't have to copy CSS variable names from web land verbatim.

I have commented here that the styler should be function. CSS is a predicate interpreter.

Here's what the selector can match on:

1. widget type
2. sub widget component name (some complex widgets may need this)
3. widget id (could it be string?)

About 2, is our widget system complex enough to need it? Is one font family, one border color, one [everything else] enough for a single widget? This will limit how complex widgets in dvui can be, but make the system simpler.

CSS has 3: tag name (i.e. widget type), class name, id.