New theme

[wiiznokes]

renderer

[hecrj]

While this approach is simple, the main reason for style sheets to exist is dynamic widget state.

A Container is a static widget, but a Button may have completely different appearances depending on its internal state (hovered, pressed, disabled, etc.). We want to avoid generating all the possible appearances unnecessarily during view.

[wiiznokes]

We want to avoid generating all the possible appearances unnecessarily during view.

Forgive me but i don't understand why my rfc imply that

pub struct ButtonColors {
    pub background: Option<Background>,
    pub border_color: Color,
    pub text_color: Color,
}

// we could use a builder patter here
let colors = ButtonColors {
    background: None,
    border_color: color!(...),
    text_color: color!(...),
};

Button::new("hello")
    // this is just a setter.
    .colors(colors);

we can then match the internal state to compute his appearance, based on his styling state

[dphaldes]

I like the way flutter handles this (which in turn inspired Jetpack Compose). Each platform gets its own Theme object like Material and Cupertino. These objects define the look of all the inbuilt widgets like checkboxes and buttons. They also have a similar colour palette system (like the one mentioned in the RFC) so that any custom widgets can also follow the theme. The palette system is also useful for recolouring the app instead of recreating the entire theme like you see in Material 3 - Material You
This way custom UI design languages can be implemented like Fluent for flutter and Flutter Chicago and plugged into existing apps and switching themes to match platforms becomes trivial. These packages also expose few widgets that are platform specific.
This theme object can be applied in the root node to style the entire app, or in any specific node to only style a portion of the widget tree.
Widgets can also have their own specific overrides. For example, ButtonStyle lets you override the properties like colour and size (No behaviour like animations) without needing an entire Theme. Some widgets like Containers simply expose a background colour field, since they are used commonly.
The benefit of this approach is that Developers need not create an entire theme for changing small values and colours, but they can if they want to. It also lets you have some portions of your app in one design language, while the rest of the app is in another design.
From my understanding, Iced is already halfway through by its use of Stylesheets. Although I am not sure if it allows for different theme for a portion of a scaffold.

TLDR: Current methods of style sheets are nice for implementing custom design language, but a base palette structure needs to be implemented in it so that they can be used for styling/creating custom widgets that follow the same theme.
Also, helpers to override simple properties (like background) needs to be exposed for situations when creating a new theme is not justified (single use button/container).
I highly recommend that you to go through how flutter handles its cross-platform theme and styles.