Styling Brainstorming

[jkelleyrtp]

I'd like to add a styling system to yew - not having a built-in way of styling components seems a bit unfinished to me. If we want to build better, bigger, and faster web apps, then we need a way of managing styles that doesn't clobber a global namespace and makes sense when looking at the components.

I'd like to see a Stylable trait where we can pull in an existing stylesheet (using css-parser for the servo project), modify it (override the defaults), and then set that as the element style.

We could also have a special style property for each element where we can inject style into even the subdivs of elements.

I personally favor parsing an external stylesheet and doing inline modification because of autocompletes working with .css files, but there is also room for a css! macro and reserve a keyword for the element that the style is being applied to, to access subdivs in that element.

Curious what the thoughts of the community is before I try pull my changes into the project.

[ThomasdenH]

I think the system for styling would be best as a separate system, where individual properties are ideally strictly typed. Then the library could be integrated here.

[jstarry]

I agree with @ThomasdenH and think this could start out as a separate crate but could eventually get added to yew later as it matures, perhaps in the form of "styled components".

@jkelleyrtp are you thinking of taking approach like https://cssinjs.org/? I would love having a way to use declarative styles like this. Then the integration with yew is as simple as setting the class name

[jkelleyrtp]

@jstarry I was definitely feeling inline CSS in the same way that JSS works - I like having the state of the component directly tied to its appearance. I'm going to approach this in the same way that styled-components work so we can just drop existing stylesheets into components but also be able to modify them on component updates.

[matiu2]

Personally I just use bootstrap. Then apply the class attributes as needed: https://hackerthemes.com/bootstrap-cheatsheet/

I don't use the JS part of it; just the stylesheets.

I can imagine possibly a high level API that just applies those, but I think I would prefer to just apply them myself.

The question is where does the scope of yew end ? perhaps what's needed is a separate yew-styling plugin/library ?

[hgzimmerman]

@jkelleyrtp Have you made any progress towards this?
I have a loosely defined proposal on how to implement this typed up and would love to give it a shot in building it, but if you have something in the works, I would rather hold off and wait on that.

[hgzimmerman]

Nevermind, I've got a prototype in the works here in case anyone wants to check it out:
https://github.com/hgzimmerman/yew_css

[MuhannadAlrusayni]

Here is my thoughts on building styling system.

I think there are two different places that we need to handle style:

1. a default style for every component.
2. a unique style for every component instate.

A default style for every component

Every component can have it's own default style, let's say a Button component have this default style:

color: black;
background: white;
border: 1px solid black;
border-radius: 4px;

At this point we need to defined the behavior of the styling system, thus we need to answer these questions:

• How the styling system will get these default styles? and from where?
• How the styling system will apply these default styles to the components ?

A unique style for every component instate

Some times we change style for component instate, by adding, removing .. etc styles to the component instate, thus we need to defined a how the styling system would allow us to do that.

possible answer for the 1st question

How the styling system will get these default styles? and from where?
By using trait Theme that would return Style struct that contains CssName and CssValue pairs, for the component. Every theme struct would implement this trait.

Theme that uses classes

This trait uses the class to construct Style for it. this trait is simple to implement but doesn't have full access to the component state. it also can have styles even if we have no components for them, it is easy to reuse existing css libraries with this trait.

    pub trait Theme {
        fn style(&self, class: impl Into<Cow<'static, str>>) -> Option<Style>;
    }

    // example
    pub struct DefaultTheme;

    impl Theme for DefaultTheme {
        fn style(&self, class: impl Into<Cow<'static, str>>) -> Option<Style> {
            match class.into().as_ref() {
                "button" => unimplemented!(),
                "flexbox" => unimplemented!(),
            }
        }
    }

Theme uses components state

This trait uses the component state to build Style for it, it have full access to the component state, but it's not simple to implement as well as it's only support components that are present in Component enum.

    pub trait Theme<Comps> {
        fn style(&self, class: impl Into<Comps>) -> Option<Style>;
    }

    // example
    pub struct DefaultTheme;

    impl<'a> Theme<Components<'a>> for DefaultTheme {
        fn style(&self, comp: impl Into<Components<'a>>) -> Option<Style> {
            match comp.into() {
                Components::Button(btn) => unimplemented!(),
                Components::Flexbox(flexbox) => unimplemented!(),
            }
        }
    }

    pub enum Components<'a> {
        Button(&'a Button),
        Flexbox(&'a Flexbox),
    }

This my try, for sure there are a lot of things that need to be changed for these ideas to fit in Yew. I didn't answer the other questions, since I don't have clear answer for them.

[richard-uk1]

I'm having a play with writing a css parser from rust tokens, and it seems to be going well. It's available at https://github.com/derekdreery/style. The idea is that you can do things like

<div style={{font-size: 10px; flex-direction: column}}></div>

from within a macro in rust code, making using css/styles feel really natural.

[jstarry]

Wow, awesome @derekdreery! Looks like the yew html macro could depend on your style macros under the hood. Is that what you had in mind?

[kellytk]

I agree with

individual properties are ideally strictly typed

from #533 (comment).

[richard-uk1]

Looks like the yew html macro could depend on your style macros under the hood. Is that what you had in mind?

Happy to help out however you want to use them.

There are a couple of small caveats:

• hex colors are not valid tokens in the rust lexer, so they have to be quoted (e.g. color: #"fff")
• same goes for lengths that start with e (this is because the lexer tries to interperet the number as a float with an exponent). (e.g. font-size: 1"em")

individual properties are ideally strictly typed

The lib I'm working on does typecheck your CSS, so only valid types of property values are allowed for a given property name.

[fromrileywithlove]

My preference is to use css modules, or css that's localised to the component, keeping components from conflicting with each other automatically. To this end there is the css-modules crate, which simply aliases all of the class names in a css file and imports a list of those aliases into rust.

The author of the crate was recently harassed into deleting their GitHub account by a group of transphobes but everything still works just fine.

Edit: I forgot to say that I also use it with rollup for post processing.

[art-in]

I'm trying to revive it here: https://github.com/art-in/css_mod

I took its parser and rewrote everything around without unstable rust features.
So it works on stable rust and with no complaints from rust-analyzer.
API is slightly different though.

[bl42]

First off, New to rust & New to yew... Figure it would be a great place to learn both!

Recently been using a lot of Svelte and I have really enjoyed their take on styling.

<style>
	p {
		color: purple;
		font-family: 'Comic Sans MS', cursive;
		font-size: 2em;
	}
</style>

<p>Styled!</p>

They do stuff under the hood of generating classes and attaching them to the elements but it avoids concepts of theming and leaves it to the developer/css.

Ideally (for me) an API like so would exist like so where I could leverage css variables to do the theming/customization of a child component in CSS.

impl Component for Model {
  fn style(&self) -> Css {
        css! {
            div {
                background: black;
                --main-text-color: white;
            }
        }
    }
    fn view(&self) -> Html {
        html! {
             <div>
                  <MyComponent /> <!-- changes child's --main-text-color by setting the var -->
             </div>
         }
     }

It may not be possible (still learning) but I would be interested if it does.

[jstarry]

@bl42 I like the look of that.

Minor detail: the function signature wouldn't quite work like that if the CSS was generated at compile time since we wouldn't have an instance of the component then.

Ideally (for me) an API like so would exist like so where I could leverage css variables to do the theming/customization of a child component in CSS.

I don't quite understand your vision here, could you elaborate a bit more?

[MuhannadAlrusayni]

I have developed trait with similar functionality, Component should declare their Style struct that will be used to style the component (e.g. Entry) instead of using some sort of collection that doesn't help at checking the used style if it works with the Component or not.

My project using Seed, but I'm pretty sure this idea is applicable in Yew too.

[lukidoescode]

CSSinRust is now compatible with yew 0.17.* (https://crates.io/crates/css-in-rust). Check out https://github.com/lukidoescode/yew-fullstack-boilerplate on how to use it. I'd appreciate any PRs.

[onehundredfeet]

Just saw this on my feed today, a Sass compiler built in pure Rust: https://github.com/connorskees/grass

This looks great. Is there a way of providing a sass or css file that overrides these defaults? It would be great to give to an artist for them to tweak.

[lukechu10]

How about the way vueJS does it: https://vue-loader.vuejs.org/guide/scoped-css.html#deep-selectors

You could add an unique id to every component, modify the css which should be pretty simple, and recursively add an attribute to every DOM element in the component, perhaps at render time.

[teymour-aldridge]

I have one possible solution: https://github.com/lovelace-ed/lovelace/blob/main/utils/mercutio/src/lib.rs

Note that it depends on Malvolio (another crate I've written) and I can't publish the next version of that until Rocket cuts its next release 🤷🏼

[fxdave]

Reading this conversation, the bs-css was the best implementation example, I think.

One more thing to consider is that the browser downloads the whole wasm code at once. As far as I know, yew cannot split bundles currently. So maybe it's not the best performance to keep the CSS in rust right now. Also, CSS in WASM requires two compilations, one for WASM, one for CSS. As I see, currently the css-modules is the best performing option with in-rust syntax checking.

[EndilWayfare]

I think I'm approaching the "styling" question from a slightly different angle. "CSS-in-<language>" may be a good fit for modular aesthetic/layout styling, but it seems a bit heavy-handed for data-driven styles where object-identity of an element/component matters more than its semantic-identity.

For example, I'm currently working on a Resizable component (vastly simplified MVP based on re-resizable) that is most simply implemented in React with the style prop. Creating a new style tag (or diffing into one) seems like a lot of overhead to just "update width/height of this specific element in response to mouse/touch event shenanigans". Inline, element-level styles can easily be abused, I'm not disputing that. But I think they still have a place.

The obvious workaround is to use NodeRefs and mutate styles in update (or use js-sys/external .js to wire events directly, using yew only for bootstrapping). This is tempting, but you give up the advantages of pure unidirectional flow. You also have to special-case your initial render, because your NodeRefs don't exist yet. You may also have to do a lot of bookkeeping if elements-with-styles can pop in/out of existence based on Props (e.g. if "what edges/corners are draggable" can change dynamically).

Handling a style prop along the lines of the current html! macro system sounds like a bit of a nightmare. Striking a balance between static verification, ergonomics, and performance seems seriously nontrivial. Maybe it's not worth it to support use-cases like mine? But, just wanted to throw it out there, because it seems like an angle otherwise missing from the discussion.

[srid]

Composable styles are becoming popular, via https://tailwindcss.com/

Today I can use the twind shim in a Yew app and get Tailwind support for free, but a proper CSS compiler that generates only the classes in use inside the html! macro (like postcss does in the JS world) woud be nice. See also https://windicss.org/ for some ideas (it compiles and replaces the N-classes into a single class).

[ekanna]

Tailwindcss JIT compiler
https://tailwindcss.com/docs/just-in-time-mode

[futursolo]

Since there have been no commits on the css-in-rust crate for over a year, I have decided to create a fork to provide Yew 0.18 support and fix a couple known issues that I had when using the crate as well as some improvement on the internals.

https://github.com/futursolo/stylist-rs

I would appreciate any feedback on this.

[jaredcbaum]

Works like a charm so far, thanks!

[futursolo]

@vkavoun, migrated from #3107:

Would you be able to explain why you want to do that. I guess for SSR and shrinking the bundle, but id sooner use windicss. The css bundles are rendered ahead of time to tiny bundles that are served ahead of time.

I initially forked it because:

1. I need to fix a couple issues that presents in the original css-in-rust crate.
2. There is too many unnecessarily clones with the original API. I want to optimise it.
3. css-in-rust never supported Yew 0.18+.

My preference to CSS-in-Rust comes from React's css-in-js solution because extract-based css solution (e.g.: tailwind css) is not very ergonomic to use without IDE support (e.g.: misspell a class name), where as css-in-js will always get strict type checking with TypeScript.

If you prefer CSS frameworks with built-in classes, you can continue to use them, there is nothing wrong with it.

[chetankhilosiya]

I think we should keep the css in plain .scss files. 1 for each component preferably named as <component_name>.scss. and 1 global .scss file can be named anything. The global .scss file can be used for common styling requirements like button styling or list styling for complete app. The component scss file will be used for styling particular component and scoped for that component only. so that two components scss won't affect each other.
The component trait can have associated value for css filename.
Example
struct MainPage {

}

impl Component for MainPage {
fn style(&self) -> CSS;
}

the style method can give the compiled .scss file. or user can write the css in style function directly also.
Advantages:

1. Having standard scss syntax is familiear to many web developers already. Or devs can use plain css also in .scss file.
2. The scss syntax allows to use variables for theming purpose.
3. User have choice to write css in same file as component or can create different file for css. Creating different file for css have its own benefits for large projects.
4. As directly css syntax is written with classes and used in html, it is much easier to debug such classes in developer console of browser instead of creating custom class names with inline/custom css syntax.(which can change on subsequent builds).
5. scss processors are already available and won't increase compile time that much.

With about design I will also propose to separate the html code in separate file with <component_name>.html. and add 1 macro to include the complete file in view() function returning Html.
This allows user to use existing way to write html or use separate file for html separating business logic with view logic.
This helps for large code bases.

Let me know any feedback regarding this approach.

[jaylenchen]

I refactored the repo(tauri+yew) created by create-tauri-app to workspace repo, and I write a package to run first to generate the index.html. this package used handlebars + glob to allow you write the scss file in your component, glob will find all of the scss file below src code, and the hanelebars will generate the index.html which has the all scss path. finally, the index.html will be moved to root folder of the yew repo, then trunk serve will run the index.html

this menthod can allow you to write a component with a independency css file

[fodurrr]

https://github.com/unocss/unocss, this is soo goood.

[talves]

For those wanting to use Tailwind (v3) and using node, I've created a simple example repo. I use yarn in the example, but it would be easy to convert to npm. This configuration allows for me to publish to Netlify easily with CI/CD. I use the concurrently package for development mode recommended by tailwind if you compile separately.

Here is the repo

Here is the current demo

[pintariching]

I'm currently working on railwind which is a tailwind compiler ported to rust and I'm wondering if it could be used here as a sort of plugin or extension if that's possible.

[wt]

Do you have an example repo somewhere?

[vkavoun]

I will describe my tailwindcss solution.

Tailwindcss precompiles the css before wasm is built.

I use trunk for building the app.

This is the basic structure of my code.

I use tailwind with postcss. In my opinion its the most flexible implementation.

// postcss.config.js module.exports = { plugins: { "postcss-import": {}, "postcss-preset-env": {}, "postcss-apply": {}, "tailwindcss/nesting": {}, tailwindcss: { config: "./tailwind.config.js" }, autoprefixer: {}, }, };

postcss-apply is a must for the production implementation.

The way to have extra small css bundles and no chance of duplicate classes.

The optimal styling is to have a master css file. In that file after the tailwind includes you should include the css files for the components will be using in the project.

This will allow you to break the styles much further. You will be avoiding the isolate scopes for css. It's handled by the class attached to a component.

Example:

@tailwind base;
@tailwind components;
@tailwind utilities;

.button {
  @apply inline-flex items-center ...;
}

.panel {
  @apply overflow-hidden rounded-lg bg-white border shadow ...;

  .title-group {
    @apply mb-4;

    .title {
      @apply text-lg font-medium leading-6 ...;
    }

    .sub-title {
      @apply mt-1 pb-2 text-sm ...;
    }
  }
}

You can see I am nesting. My preference is to not use scss and use tailwindcss/nesting instead. It doesn't really matter much in the end.

The main flaw, that i see, is that you have to migrate the css from project to project.

Originally, I implemented the build process with tailwindcss-cli but in the end I ended up using rollup in the end.

import postcss from "rollup-plugin-postcss";

const extensions = ["css"];

export default [
  {
    input: "./src/main.css",
    
    external: [],

    plugins: [
      postcss({
        config: {
          path: "./postcss.config.js",
          ctx: {},
        },
        minimize: true,
        modules: false,
        extract: true,
      }),
      resolve({ extensions }),
      //   commonjs(),
      //   // babel({
      //   //   extensions,
      //   //   babelHelpers: 'runtime',
      //   //   include: ['frontend/**/*'],
      //   // }),
      //   typescript(),
      //   terser(),
    ],
    output: {
      file: "./tailwind.css",
    },
  },
];

A rollup configuration could help you with building webworkers/sharedworkers/serviceworker

I recommend using rollup when using vite. It's faster to just write a rollup config vs a vite config/plugin.

Just an aside:

I recommend rollup for almost all build problems. Vite and Nextjs are great but there are limitations to those stock implementations.

Ive moved away from webpack but it's still the most stable and compatible.
For cross-source building. I recommend build.rs. Using the rust build script can easily execute, build other projects, and move the seperation of concern from frontend code to rust.

Thanks

[pintariching]

I'll describe how I used railwind:

There are two options:

• You can use the railwind_cli and hook into trunk in the Trunk.toml file and run railwind -o static/railwind.css on "pre_build" and to stop from trunk running in an endless loop, you need to exclude the static/railwind.css or the entire static folder from watch.
• Another option, if you don't want to install the railwind CLI and use the library directly, then add railwind to your build-dependencies in Cargo.toml and add a build.rs file with the relevant library code and also make sure to exclude the static folder or the railwind.css file from trunks watch to stop the endless loop.

[FantasyPvP]

any update on this?

[TiemenSch]

Regarding bundling stylesheets of different (component library) crates: I think this is mostly the domain of bundlers and build tools like Trunk, where there are plenty of investigatory issues that look promising: trunk-rs/trunk#759, trunk-rs/trunk#710, and even trunk-rs/trunk#3 from way back then. If Yew component library crates can support whatever direction they take, even if by convention, I think that would be a huge win.

If bundling external component library crate SCSS can already be achieved in some convenient way using their current Dart-Sass support, it might be worth writing a guide or recommendation for that. Anyone got experience with that?

Regarding dynamic styling and full-blown theming, that is where we might look for changes and improvements to the current macro's and traits, that feel as if they could use some ergonomics improvements at times. Is any of the CSS-in-Rust tools still under active development? I feel that some ergonomics are missing when writing my <div> style={....}</div> strings with no checking built-in and classes!("m-2", "width-full") enumerations with all their separate quotations "".