Sometimes we get so caught up in the syntax and minutiae of a language that we start missing the forest for the trees.
I mean, don’t get me wrong, you’ve definitely got to understand the trees. But if you never take a breath and step back for a bit, you’re inevitably gonna end up in a quagmire of confusion, superstition and fear. So that’s what we’re gonna be fighting, starting today – we’re going to be getting some perspective about CSS. This post is geared towards newbie/mid-level devs, and assumes that you’ve been learning CSS for at least a month or two.
CSS is big.
This is important to understand. It’s easy to underestimate the size, scope and difficulty of CSS when you first get started in development. I mean, it’s just presentation, right? It’s surface stuff! Though it’s easy to get this impression from CSS off the bat, you only have to scratch the surface a teeny bit to learn otherwise. You know those O’Reilly programming books? The ones with pencil drawings of animals on the front? The CSS one is over a thousand pages:
The thing is, there’s always new stuff being added to CSS – it changes and grows every year, and it goes deep.
So what are all these changes? A lot of it is imitating the stuff that the most popular CSS preprocessors and frameworks do. For examples, variables and grid systems were developed outside of vanilla CSS, but are now a part of it. If a tool becomes super popular and enough people ask for it, it might get added into CSS native, and could even end up spelling the death of the tool that was the inspiration for it. Many people think that with the proliferation of CSS Grid and Flexbox, Bootstrap’s days are numbered. Of course, not everything from preprocessors and frameworks will find a home in native CSS – picturing functions and loops in standard CSS is a stretch. But nesting? Hey, who knows?
Who decides all this stuff, anyway?
The CSS specification is maintained by the Wordwide Web Consortium – basically the council of elders who decide everything about the standards for the core technologies that are used on the web.
Also, 4-time winner of the “Most Crushingly Dull Logo” Webby Award
So the W3C defines a bunch of standard related to the web, f.x. what is and is not official HTML and CSS. The CSS part is done by a subsection on the W3C called the CSS Working Group.
These fine folks are the ones who actually decided what CSS is. There are representatives from all the big web companies – Apple, Google, Mozilla, etc. They pay around 50 grand a year to have a seat at the table. There are also folks who are part of the group due to their stature in the CSS world and their contributions to the language. People like Bert Bos, who worked on the language in its infancy, are part of the group. I don’t know if he has to pay the 50 grand. Probably not.
So we know now that CSS is being changed all the time. How exactly does that happen? Well, the first thing we have to talk about is this:
CSS3. As you might know, this is the current version of CSS – it’s what all the major browsers are running. What you are less likely to know is that this is the last version of CSS that we’re ever going to see. The change was made in 1999, and there has been no discussion of a new version. The reason why is that CSS is being broken up into modules, which are being improved independently of each other. And the different versions of these modules are not called versions, they are called levels. To get a look at the current state of affairs for all of these modules, take a look at the CSS Working Group ‘current work’ page.
Once the CSS Working Group makes a decision about something, the browsers have the responsibility to start adopting the new rules and conforming to the specification. They generally all do this pretty quickly, except for Internet Explorer. Everyone makes fun of them and you should feel free too, as well. You can see how a given CSS property is supported by different browsers at caniuse.com. Here’s an example of a support table for CSS Grid. This is very out of date, by the way – it’s way more supported by now:
Wow, IE actually did pretty well this time around. How about that.
One thing we need to touch on is the fact that browsers aren’t simply neutral middlemen that just render our code exactly the way the W3C says to in the spec. A bunch of the default CSS you are used to seeing when you write code is not part of the official CSS spec at all, but is rather defined by the browsers. By the way, browsers in this context are referred to as ‘user agents,’ and every user agent has a ‘User Agent Stylesheet.’ This refers to all the styles that the browser throws into our CSS on top of the definitions that the CSS Working Group lays out. These rules are things like making h1s bigger than h2s and putting confusing default margins on stuff. Here’s a piece of the Chrome User Agent Stylesheet:
That screenshot comes via John Meiert’s awesome collection of User Agent Stylesheets. By and large, the styles the browser adds into our CSS at the very least kind of makes sense, and are useful for getting us thinking in terms of proper semantic HTML. But they can also kind of get in the way, and confuse us about where certain styles are coming from. As such, you may want to reach for a CSS reset. This is a big chunk of CSS that basically just resets everything to zero – turns off default margins, makes everything the same size, stops links from turning all blue and underlined and whatnot. You can write your own, of course, but grabbing one from someone’s blog is pretty darn convenient. Some resets are more drastic than others, google around until you find whatever you’re looking for. Here’s an example of what a piece of one might look like:
And that’s it for today! Next week we’ll talk about the wonderful world of CSS tools and extensions – preprocessors, frameworks, grid systems, you name it! Thanks for reading!