Let’s say you have this CSS:

body {
	color: DarkSlateBlue;
}

Along with a bunch of other properties, color is inheritable, which means every bit of text on the page — unless there’s a specific color defined — will now be DarkSlateBlue.

Let’s expand on this some more and bring in some HTML.

<article>
	<h1>I am a heading</h1>
	<p>I am a paragraph.</p>
  <h2>Subscribe</h2>
	<form>
    <label for="email">Email address</label>
    <input type="email" id="email" placeholder="hello@test.com">
    <button>Submit</button>
	</form>
</article>

See the Pen Nearly all the text is purple by Andy Bell (@piccalilli) on CodePen.

Looking at the demo, the headings, paragraph and label have DarkSlateBlue text, but the input (both placeholder and value) and button still have the default colour text. This is because they have specific colours assigned to them in dev tools, like so:

button {
	color: buttontext;
}

input {
	color: fieldtext;
}

These are system colours that are applied in the user agent stylesheet — default styles applied by the browser. Because these elements have a color value applied, they won’t inherit the colour from body, like the other elements on the page are.

The inherit keyword

This keyword is really handy. Not all CSS properties are inheritable, even though a lot are. You can use the inherit keyword to inherit those non-inheritable properties.

article {
	display: flex;
}

h1 {
	display: inherit;
}

With this snippet, the <h1> will now have a computed display value of flex.

Back to our little snippet of HTML, though. Let’s make the input and button inherit the DarkSlateBlue colour. Colour is inheritable, but we can use the inherit keyword to force the element to inherit those properties over the default styles assigned by the user agent stylesheet.

input, button {
	color: inherit;
}

See the Pen Even more of the colour is inherited by Andy Bell (@piccalilli) on CodePen.

Easy peasy right? Let’s push it a little further and use another inheritable property: font. We’ll set some font values on the body first:

body {
	color: DarkSlateBlue;
  font-family: Tahoma;
  font-size: 2rem;
}

The magic of inheritance means all the text elements have again, inherited the font-family and all the text is bigger.

See the Pen Nearly everything now uses Tahoma font by Andy Bell (@piccalilli) on CodePen.

The reason the text elements like headings are bigger, with no additional sizing authored by us, is because the user agent styles size them with em units, which are a ratio of their parent’s computed font-size. For example, this is the h1 font size style in the Chromium user agent style:

h1 {
	font-size: 1.5em;
}

Because we set the body to have a font-size of 2rem, my browser has computed that to 24px. The h1 has a font-size of 1.5em which is 24 * 1.5: 36px.

Right, back to our little demo. The problem is, our placeholder style is still grey. This is because in the user agent stylesheet, placeholders have a specific colour assigned to them, so they no longer inherit either the body colour or the input colour.

This is the placeholder rule in the Chromium user agent stylesheet.

::-webkit-input-placeholder {
  -webkit-text-security: none;
  color: darkGray;
  pointer-events: none !important;
}

The color is set to darkGray, so even when the input is inheriting color, it won’t affect the placeholder because it has a more specific style assigned to it. No dramas though because all we need to do is this with a more cross-browser friendly selector:

::placeholder {
	color: inherit;
}

See the Pen Now everything is inheriting colours and fonts by Andy Bell (@piccalilli) on CodePen.

Controlling inheritance

I’m waxing lyrical about how powerful inheritance is, but in the real world, you’re not building simple examples like the above. There’s going to be plenty of times where your element has inherited styles that you don’t want. Let’s look at some options.

Write more specific styles

This is my most favoured approach. Just like we covered in the cascade and specificity primer: user agent styles are low in the cascade priority, so even writing flat type selectors like so, will do the job for you:

a {
	color: red; /* Very easily overrides the user agent style */
}

This is how we’ve tackled the problems above and is probably the path of least resistance when authoring your CSS.

Use keywords

Let’s run through revert, initial and unset keywords.

revert

.my-element {
	color: revert;
}

This will set the property to the user agent stylesheet value — AKA the default browser style. So, if .my-element was a <button>, the colour would be set back to buttontext, like we covered earlier.

unset

.my-element {
	color: unset;
}

This one can be a bit confusing. If the property you are assigning unset to is inheritable, then you are effectively doing this:

.my-element {
	color: inherit;
}

If it’s not an inheritable property though, the property value will be the same as what the next keyword — initial — does.

initial

.my-element {
	color: initial;
}

This is the nuclear option and I recommend avoiding. This will set the value back to the element’s CSS specification value, which in human terms means, it’s gonna remove the style all together.

Wrapping up

See, inheritance isn’t scary is it? It’s fantastically powerful and if you embrace it, you will write less CSS. You’ll also have a more maintainable codebase and your users will get a better experience overall. Magic.

It’s so different to traditional and native software development where you have to very specifically style every single element. I get why developers who come from that background don’t like CSS. It’s a shift in mental model though; let go of the need for absolute control and everything becomes easier. That’s a principle for building for the web in general that will improve everything for you. Trust me.

A lot of the time, the cascade and specificity are explained within and inch of their lives in expansive guides or detailed articles. These articles are fantastic, but I think the size and complexity of them can scare developers too, so I’m going to simplify it for you today. In fact, keeping things simple is one of the most effective ways to keep any codebase manageable and maintainable. It’s especially the case with CSS though. Let’s dig in.

The C in CSS stands for Cascade

Let’s tackle the elephant in the room first. The Cascade is an algorithm that solves conflicts for you where multiple rules could apply to an HTML element.

Let’s use a really simple example:

.my-element {
	background: goldenrod;
	background: coral;
}

This element has two background declarations. The cascade has done its thing and determined that .my-element will have a coral background. Why though?

Because the coral declaration comes after the goldenrod one, coral wins. In the vast majority of your standard CSS authoring, remember this and you’re good to go. There are exceptions though, so let’s focus more on those because this first bit was dead easy right?

See the Pen A square with a coral background by Andy Bell (@piccalilli) on CodePen.

The order of importance

No, this isn’t a weird British Royal Family thing; it’s a simple ruleset to remember because not all properties are equal. What I mean by that is certain CSS property types will be prioritised over others. This list is ordered least to most specific.

Normal declarations

This is your background, padding, line-height and margin properties. Y’know, the stuff you’re slinging into your code most of the day.

Active animations

This is when your animatable properties are being affected by an active @keyframes animation.

Declarations that utilise !important

Not to be feared but to be admired: the humble !important property does exactly what it says on the tin: it determines an important value. It’s added as part of your declaration value like so:

.my-element {
	background: grey !important;
}

This will ultimately win (nearly) every time, but treat it as it will win every time and you won’t have problems with it.

The !important property is designed to be honoured by proxy of it being important, so only use it when you feel you absolutely need to. I’ll write more on this if people want me to, but use it wisely and !important can be really useful and helpful in keeping your codebase simple.

The order of origin

This order is taken into account by the cascade from least specific to most specific.

User agent base styles

Every major browser ships with a user agent stylesheet. These are default styles that are applied to HTML elements to prevent every element looking the same if there’s no CSS that applies to that HTML.

Local user styles

These styles are mostly operating system level stuff such as font size preferences. Local user styles also technically apply to CSS that is authored in browser extensions but my recommendation in more modern times is to presume that these are injected as <style> which will be more specific than styles authored in CSS files.

Authored CSS

Hey champ, this is your stuff that you are writing!

Authored !important

Yup, just like we covered earlier: those !important values are gonna win over your standard property values.

Local user styles with !important

Say you absolutely want your font size to be the same on every website. An operating system and browser combo could technically declare that as an !important property and that will beat all of the above.

User agent !important.

Finally, if the user agent styles have an !important value, this will ultimately win.

That’s it for the cascade, let’s tackle its best friend: specificity.

Specificity

Fun fact, because I’m from Yorkshire in the UK, I struggle to say this word, which for someone who teaches CSS, is not ideal. I digress though, but for a reason — to give you a quick breather — so retract those shoulders and breathe out because specificity isn’t hard, trust me.

Let’s go back to .my-element but tweak the CSS. It’s important to note that we’re using <div> element that has a class attribute.

div {
	background: goldenrod;
}

.my-element {
	background: coral;
}

The winner is coral because .my-element has a specificity score of 0-1-0, whereas div has a specificity score of 0-0-1. Let’s dig into scoring some more.

See the Pen CSS class wins because it's a more specific selector by Andy Bell (@piccalilli) on CodePen.

Specificity scoring

Each selector rule gets a score. The higher the score, the more likely that rule’s CSS is going to apply. The score is in this format: 0-0-0, or "hundreds"-"tens"-"singles". This does expand, but let’s not worry about that right now until we need to. Let’s do a quick fire scoring rundown.

Universal selector — AKA the wildcard selector

* {
	/* Your CSS declarations and properties here */
}

Score: 0-0-0 — 0 points

Type selector — AKA element selector

h1 {
	/* Your CSS declarations and properties here */
}

Score: 0-0-1 — 1 point

Pseudo-element selector

::before {
	/* Your CSS declarations and properties here */
}

Score: 0-0-1 — 1 point

Class selector

.my-element {
	/* Your CSS declarations and properties here */
}

Score: 0-1-0 — 10 points

Pseudo-class selector

:hover {
	/* Your CSS declarations and properties here */
}

Score: 0-1-0 — 10 points

Attribute selector

[href] {
	/* Your CSS declarations and properties here */
}

Score: 0-1-0 — 10 points

ID selector

#myElement {
	/* Your CSS declarations and properties here */
}

Score: 1-0-0 — 100 points

Inline style attribute

<div style="background: blue"></div>

Score: 1-0-0-0 — 1,000 points

!important rule

.my-element {
	background: red !important;
}

Score: 1-0-0-0-0 — 10,000 points

Wait just one minute, !important is a cascade thing, right?! It’s both a cascade and specificity thing. Someone with a name like Chad Smith might cite this as the reason why CSS “sucks” on Twitter. That’s not true though because all you have to do is remember !important applies to the cascade and specificity, just like you need to remember that JavaScript can’t compare numbers properly. All programming languages have stuff like this to learn and CSS is no different.

Also, do you remember when I said the scoring will expand? This is it. For both inline style attributes and !important rules we stitch on an extra number. For you, dear reader, this is a cue that the CSS you’re writing better be damn important because you’re in the realms of very high specificity.

Combining selectors equals more points

Now you know how many points each selector type gives you, let’s combine some to show how this part works.

h1#myElement {
	/* Your CSS declarations and properties here */
}

We’ve got 1 point because we’re using a type selector (h1) and 100 points because we’re also using an ID selector (#myElement). Therefore the specificity score here is 1-0-1 — 101 points.

Let’s do one more for fun.

h1.my-element::before {
	/* Your CSS declarations and properties here */
}

We’ve got 2 points because we’re using both a type selector (h1) and a pseudo-element selector ::before. We’ve also got 10 points because we’re using a class selector (.my-element). Therefore the specificity score here is 0-1-2 — 12 points.

:not(), :is() and :where()

Let’s say you have this CSS:

h1:is(.my-element) {
	/* Your CSS declarations and properties here */
}

It has the exact same specificity score as:

h1.my-element {
	/* Your CSS declarations and properties here */
}

This is because with both :is() and :not(), the most specific selector passed into those pseudo-classes will be picked, so don’t think about using those as a specificity boost.

With :where(), that pseudo-class and any selector passed into it has no specificity. Let’s go back to one of the earlier selectors to demonstrate.

h1#myElement {
	/* Your CSS declarations and properties here */
}

This has a score of 1-0-1 — 101 points. Let’s add :where() into the mix.

h1:where(#myElement) {
	/* Your CSS declarations and properties here */
}

This now has a score of 0-0-1 — 1 point because the 100 points from the ID selector has now been discarded because it is within a :where() pseudo-class. It’s why you probably spotted its usage in CSS resets because those reset styles are much easier to override thanks to :where()’s low specificity.

Child and sibling selectors add no specificity

One quick thing to remember is using child and sibling selectors (>, ~ and +) won’t affect your specificity score. For example, these have the same score as each other:

.my-element li {
	/* Your CSS declarations and properties here */
}

.my-element > li { 
	/* Your CSS declarations and properties here */
}

Dev tools are your best friend

If you open up dev tools in your browser and go to the styles tab, it’ll look a bit like this:

The stuff that’s less specific in terms of both the cascade and specificity will be lower down the panel. Anything more specific will be higher in the panel. What has been discarded will be crossed out, so by proxy, what isn’t crossed out is applied. That knowledge alone should make your life easier!

Wrapping up

I strongly recommend that you get a specificity calculator in your arsenal. My favourite is by the fantastic folks at Polypane. Their specificity calculator is super easy to use and does a really good job of breaking it down for you.

There’s also new CSS capabilities that can help, such as Cascade Layers. I personally haven’t found the need for these (yet), so I’m not qualified to write about them. I’ll let someone who definitely is explain them to you instead.

I’ll finish by saying I find this stuff super boring to write about but it’s really important to understand. I hope this primer will make you feel more comfortable with two of the most fundamental parts of CSS. If you’re looking for quick advice on how to deal with this in the real world, I would say keep your selectors as low scoring as possible. If you get stumped, remember the order of origin and use dev tools! Remember, if it’s crossed out in the CSS panel: something more specific is in play.

Take the above example: it’s visually a circle because it has border-radius applied to it, but it’s still a box, as far as the browser is concerned.

This is really important to remember when you’re working with CSS, but what’s even more important to remember is understanding how these boxes are both sized and how they interact with their surrounding, sibling boxes.

Padding, borders and the content box

The default box-sizing value for all elements is content-box. This means that when we add padding and/or border to an element, those values will be combined with the desired/content-driven width and height of the element.

This is because the width is applied to the content box part of the box box model. This can be confusing — especially when you are first starting out with CSS.

.box {
  width: 100px;
  padding: 10px;
  border: 10px solid;
}

What happens here is your box’s computed width is actually calculated as 140px. This is because each side of the border box is 10px (20px combined), and each side of the padding box is 10px (20px combined). The width of the box only accounts for these inline sizes.

This is how the box model works out of the box (pun intended), and it’s often unexpected behaviour for beginners because y’know, if you set a width or height, you expect your element to honour that. It’s completely understandable how this confuses people!

Most of the time though, it’s preferable for this default box model behaviour not to be the case. To get more predictability, add this little snippet of CSS to your element’s CSS:

.box {
  box-sizing: border-box;
}

This snippet completely transforms the browser’s calculation of an element’s size. To convert this CSS into plain English, you’re saying: “Take the dimensions that I specified and also account for the padding and border too, instead of adding them to the desired size”.

What you get as a result is a box that’s 100px wide, instead of 140px wide, just like you specified when you set width to 100px!

The most effective way of showing you this is with a demo. When you toggle the “box sizing” switch to ON, box-sizing: border-box is applied to the box element, making the resulting size the same as the desired size. When it’s switched OFF, the default browser behaviour takes over.

See the Pen A quick demo showing the impact of box sizing on a box element by Andy Bell (@piccalilli) on CodePen.

The element has 10px of padding and a 10px border, which means 40px is added to the width because the element has padding and border either side. The demo box has a minimum size of 250px to make the text easier to read.

Globalising box sizing rules

A lot folks add the box-sizing rule as a global selector to a reset — or default normalising styles — so to demonstrate a more complete example, this is how our CSS now looks:

/* Reset rule */
*,
*::before,
*::after {
  box-sizing: border-box;
}

/* Box component */
.box {
  width: 100px;
  padding: 10px;
  border: 10px solid;
}

What this reset rule does is instead of just targeting the .box element with box-sizing, it targets every element on the page and any of their pseudo-elements.

This means that every time you add and element to a page, you can guarantee it will be the size that you think it is with little to no surprises. Of course, in a responsive world, setting specific sizes can be problematic, but even then, you know padding and border are not going to make your elements bigger than you thought they’d be.

Wrapping up

I hope this quick run-through of the box model and box sizing has unlocked the concept in your brain. Knowing the fundamentals like this will make you a better CSS developer, I promise. Here's some links:

• Box Model - web.dev
• The box model - MDN
• The CSS Box Model - Margin, Borders & Padding explained - Kevin Powell
• Happy international box sizing awareness day