or, the "and you thought JS was bad" part.
oklch
if youâre absolutely new to CSS, start here at the Mozilla Developer Network (or MDN). theyâre the people that make Firefox and have the best reference guides for CSS. in general though this guide assumes youâve got a base understanding of CSS so go forth and mess around with the language as much as you can before moving on to the rest of the more complicated stuff.
an easy way to get started is by checking out some of these tools that let you play around with the language:
thereâs been a lot of standards around color, beginning with rgb
and including other fancier things like hsl
. the new âkingâ of color definition is oklch
.
this guide is about writing an application not a regular webpage. to that end, you shouldnât be using regular CSS with <style>
tags anymore â as your application grows and more contributors add to it, you will drown in a sea of madness and salty tears. yes, your mother taught you to wash behind your ears, brush your teeth, and never, EVER use inline styles in your HTML. but those days are over and a new era has come.
the truth is that this space is still rapidly in development and the dust isnât quite settled yet. i think there are compelling arguments for both CSS-in-JS and CSS Modules. youâll probably fine going with either these days.
CSS Modules are a great way to get a lot of the benefits of CSS-in-JS without leaving the CSS world altogether. hereâs a helpful primer on getting started.
CSS-in-JS forgoes CSS files altogether and says we should have our styling where our components are. think about it this way. when youâre sharing HTML these days, we tend to do so via HTML-in-JS. in other words, one can create React components and publish them to the general web to share to fellow developers. similarly, one could argue, the best way to share CSS is to package them inside of something standard like JS.
great reads on the topic
package options
again, thereâs so much action going on in this space that itâs still to be decided what paradigm will win here. for now though, my tentative recommendation is emotion.
related to the previous section on JS, iâll mention again here the technologies included by default related to CSS for you to use out of the box.
browserslist
field in package.json
. (historical note: postcss-preset-env was previously known as âcssnextâ)*.module.css
to take advantage.node-sass
package.)sanitize.css is a CSS Reset that helps normalize things across browsers, a lesser problem these days but still important.
CSS Modules
when you can, itâs suggested to use CSS Modules which provide great scoping for your CSS to a particular JS module. first, name your CSS file [name].module.css
and then you can use it in your JS module as such (take note of the composes
keyword and what itâs doing):
// Button.module.css.className {color: green;background: red;}.otherClassName {composes: className;color: yellow;}
// Button.jsimport React, { Component } from 'react';import styles from './Button.module.css'; // Import css modules stylesheet as stylesimport './another-stylesheet.css'; // Import regular stylesheetclass Button extends Component {render() {// reference as a js objectreturn <button className={styles.otherClassName}>Button</button>;}}
given the recommendation for CSS Modules/CSS-in-JS i might steer you away from CSS preprocessors (which would add yet another layer top of an already complex stack of technologies). but, if thatâs your thing, then take a look at Sass.
the advantages Sass can give you are things like:
(historical note: other packages in the space are things like Less but the community isnât as strong there and the support from other vendors isnât as robust.)
thereâs a bunch of CSS features constantly in the making. letâs look at a couple of more interesting ones that are in the pipeline (as of Fall 2018) and/or are currently in the wild for you to try:
(and many more to comeâŚ)