Have you run into any significant issues with the overhead of "bloat" that comes with inline styles? Injecting so many styles inline especially for complex list items might potentially have some performance issues despite having a virtual dom.

I have been considering refactoring my personal ui lib to use css for static styles with css modules while all themable/dynamic styles inline. Many might say the mixture gets increasingly complex scaling but I have not run into such an issue.

This is a very fair point. We've followed a similar approach to what you're considering, with styles living in a couple places:

- Scss library of variables, mixins, and functions that can be imported in whole or piece-by-piece into components that can use them. Doesn't compile any CSS classes on its own.

- A lean global “browser reset”, uses some of the global style variables from the library.

- A simple React component (we call it `Cell`) that is used absolutely everywhere. This component has its own .scss file which imports the global scss library, and is essentially a one-stop-shop for `functional` CSS for colors, dimensions, typography, elevations (drop shows and zindexes), scrolling, etc. React authors use it via props instead of writing class names. Eg `<Cell color='action-primary' elevation={2} fontFamily='header'>`. Heavily reusing this component is what most directly addresses the performance concerns you note.

- While Cell is sufficient for composing most layout and aesthetics at all levels of the page, one-offs are often needed for fine detail work:

--- Simple cases are handled directly where needed via inline styles (easy to read when everything is in one place). We don't do anything fancy here for authoring (no radium etc), just an inline style autoprefixer that runs through postcss loader via webpack.

--- Per-component scss files for more complicated needs (unique animations, novel compositions, complex interactions, etc). The component scss imports the global scss library so all our standard theme/helpers/etc are available everywhere. The component scss outputs to unique hashed classnames via webpack, so there is no risk of class name collisions between components. This allows for very focused scss files with short, straightforward names.

A lot of this works very well - in particular the global scss library, the Cell component, and the ability to opt-in to more fine grained control per component. However, there is some duplication between the scss library and a few javascript utils we've made to help keep inline styles consistent. These issues are somewhat made up for by how transportable our style layer is - if we were to switch away from React, or start a new project on a different stack, having the style vars and class library defined in scss already would make it easy to simply drop in and get rolling.

Interesting insights, though I wish much of these practices to be viable outside of closed source.

-A Scss library for functionality rather than compiling definitely seems interesting as a halfway point between pure css or pure javascript.

-When I was using pure inline-styles I rarely ran into cases where I couldn't get away with using divs or other style-less elements. The downside was div soup and bloat when rendering large quantities of components that had resets.

-I would be very interested, if allowed, to see the design of your Cell component. Rather than a component itself I find it simpler to define certain highly reused styles in the global scope, such as grid layout. Styles like these generally don't need encapsulation and are highly reusable since they are mainly containers.

-

--I must admit that prefixed inline-styles are atrocious to look at it definitely is enjoyable dealing with a component in roughly a single file. Big loss was targeting an n:child for styling

--Since I don't write any production code I can get away with the web animation api or any resource still in early stages or have not been highly adopted yet. I generally have a prefix for the global css classes e.g. 'qp-grid' and my projects are hardly big enough to have naming collisions.

It is unfortunate mixing css and inline-styles make it quite difficult to apply to an open source lib but I am quite hopeful for a solution or practice to address the issues.