Web app styling interlude: How to identify the key pieces of a styling solution

There are many ways to process "styles" for your web application. We can break down the key decisions about which processing approach to use based on a few design decisions.

You can mix and match these approaches within the same app. For example, some of your components may be using one combination and another component, another approach. Themeing, always a hot topic, may use a variety of approaches as well as a good themeing engine can be quite complex to integrate into your application.

By selecting the model you want to use from each of the areas below, you can then decide on a specific set of software to perform the processing. For example, if you want to author in js, apply at runtime using inline css, you could use glamor.

Or if you want to use css, process them at build time but have them load through stylesheets, you can use css-loader and style-loader in webpack.

Authoring Environment

You can author CSS in

• CSS
• JS/JSX
• less/scss
• ...

There are many authoring environments.

When Styles are Processed

Styles may be processed at different times. Ultimate flexibility means that you process them all at the last minute even though that may create more overhead (processing time and space). The least flexbility means all of the processing is done prior to provisioning e.g. raw CSS stylesheets coming from the server.

• Build time
• Load time
• Runtime

Load time is different than runtime in that load time is when the "module" containing styles is loaded into the target environment.

How They are Provisioned

Styles are really only provisioned in two different ways:

• Stylesheets
• Inline

Lifecycle

There are a few varieties here, but the key ones are:

• Forever: Once loaded, forever there.
• Removable

Removable means that the styles, however they are applied, can be removed. In the case of stylesheets, the stylesheet can be removed. This is a popular approach to reduce the style burden on browsers. In the case of Inline, they can be overwritten with previous values or removed.

Access to Provisioned Styles (External to Publishing Environment)

This is most abstract part, but essentially if you want author your styles in one envionment, such as CSS, but need access to the style names as derived from that content, you need to use an access mechanism that supports that model.

• None: No access to the authored styles is provided regardless of the environment.
• CSS from CSS: You can access other CSS defined information, e.g. CSS variables located in other CSS stylesheets.
• JS from CSS: You can access the CSS from JS, e.g. obtain classnames for definde CSS styles.
• CSS from JS: I do not know of any context where a stylesheet can access the javascript context.

For example, if you need classnames from your css directly in your JS so you can apply the classnames to a react component, css-loader/style-loader can provide that if you use the "import" styles approach e.g.

import styles from "./styles.css"

Using this common approach allows you to use styles.myContainerStyle in your javascript code. You could use access to the styles to help shape them based on user feedback or specific user agent environments.

Other approaches allow you to do the same thing but have your styles in javascript:

import styles from "./styles.css.js"

allows you to access the classnames as in the previous example but you'll have to use a css-js-loader or postcss-js-loader processor along with other loaders (at least in webpack) such as css-loader/style-loader to enable it.