Let’s start first with the “Style” part of Cascading Style Sheets.
Style
As you know, in HTML you’re writing what will be on the page.
Need a paragraph? Add it to your HTML document.
Need an image? Yep, add it to your HTML document.
CSS, on the other hand, determines how your content will look. This is what style is referring to in Cascading Style Sheets.
That paragraph in your HTML document, the CSS can change the color, size, alignment, and so much more.
The CSS can also style the image - should it have rounded corners, have a shadow under the image. If you hover over the image should it move or have a border or maybe a shadow?
And this is just scratching the surface, but you get the idea.
Here is the CSS Academy home page without CSS (only HTML):
You can see that in this image you get all the information, the what of the page. Here’s the exact same page with CSS:
In this image you can see how the CSS transforms the page.
Cascading
Now let's look at the cascading part of Cascading Style Sheets.
Have you ever written CSS only to find that it isn't showing up on the page?
One of the reasons this happens is due to the cascading nature of CSS. This is a crucial thing to understand about CSS.
If two styles conflict the style lower down on the stylesheet will override the styles higher up.
The styles cascade as if water flowing down a waterfall.
You could picture it as if you were starting at the first line of the stylesheet and as you go down you grab styles.
Let’s say you found a style for the font size of a paragraph at the top of the waterfall (aka the top of your stylesheet 😉).
Lower down you find another style that makes the paragraph much larger. What happens? Which font size will show up?
Due to the cascading nature of CSS, the larger font size lower down in the stylesheet is the one that will be used on the page.
CSS will, in essence, drops the style at the top of the waterfall and accepts the one lower down. It never goes back up, it only goes down.
Let’s say you have a paragraph. And you have these two styles:
css1p {2 color: red;3 color: blue;4}
What color will the paragraph be?
You got it. Blue.
If this is still confusing, the reason that it is blue is because the styles cascade. So, if a style lower down conflicts with one higher up it will override the style that was declared higher up in the stylesheet.
Technically both styles need to have the same level of specificity in order for this to happen, but I’ll cover specificity in another post.
Just remember, keeping all things equal, styles lower down will override styles higher up in the stylesheet.
Sheets
Let's jump into the last part, sheets, of Cascading Style Sheets.
The sheet is referring to where the CSS styles are written. Typically this is a separate stylesheet. But, not always.
There are a few places where you can add your CSS:
- Inline with your HTML.
- On the same page as your HTML document.
- In a separate stylesheet.
- CSS-in-JS
Let me walk you through each of these and explain the benefits and limitations of each one.
Adding Styles Inline
As you’re writing your html you may be tempted to add styles right there with your content. Let’s say you have a paragraph that you’ve just added to your HTML document:
html1<p>Hello world!</p>
And you decide you need that paragraph to be centered on the page. So, you decide to do something like this:
html1<p style="text-align: center;">Hello World!</p>
This is adding styles inline.
The Benefits of Inline Styling
It's quick and easy to add inline styles right there in your HTML document.
If you don't have a lot of styles, this may seem like the easiest way to go.
The Limitations of Inline Styles
Typically it only takes a few pages and some changes for you to realize the limitations in this strategy.
Here are the 4 main problems as I see them with inline styling:
- It can be much more time consuming to update styles that are inline. This is because you have to hunt through all your HTML documents to find each instance of that style and update it.
- It can result in more CSS than necessary. If you need to center your text multiple times you’ll have to write that style multiple times. Instead you could add one class and then write the style once. Then you can add the class as many times as you want and you won’t need to add any more lines of CSS. This isn’t super apparent with this example, but trust me, it typically results in a lot more CSS.
- Inline styles add a level of specificity that you may not intend. The more experience you have with CSS, the more you begin caring how specific your styles are and how to elegantly override other styles. Inline styles are quite specific and require more specificity in order to override them. This results in bloated, unnecessarily specific, and sometimes hacky CSS.
- The content (HTML) and presentation (CSS) are getting mixed together. This results in confusion and messiness as the size of your project grows.
Adding Styles on Page (in the Head)
You also have the option of adding a <style> tag inside the <head> of your HTML document. In-between the style tags you would write your CSS just as you normally would like this:
html1<html>2 <head>3 <style>4 h1 {5 color: black;6 }7 p {8 color: red;9 }10 </style>11 </head>12 <body>13 <h1>Hello World!</h1>14 <p>I'm a rock star. Love me.</p>15 </body>16</html>
Do you see how in-between those two <style> tags normal CSS is written?
You can think of that kind of like a mini stylesheet - and only for this page.
Benefits of on Page Styles
Similar to inline, the styles are closely tied to the HTML.
If you want to change a style on a specific page, just go to that page's HTML document and you can change it right there.
If you don't have a lot of styles, this may seem like a great way to go.
Limitations of on Page Styles
You may have some styles that you want to extend across all pages. Maybe you want all paragraph's to have a certain font family.
With this stategy you would have to re-write the font family for the paragraph for each page.
This would result in a lot of repetitious styles.
Even worse... if you ever wanted to change the font-family, think of how long it would take you to make that one change. And that's just one change. Imagine how long it would take you to make a number of style changes 😰.
Adding Styles in a Separate Stylesheet
That leads us to writing your styles in a separate style sheet. This is the generally recommended way of writing CSS. Your HTML document might look something like this:
html1<html>2 <head>3 <link rel="stylesheet" type="text/css" href="styles.css">4 </head>5 <body>6 <h1>Hello World!</h1>7 <p>I'm a rock star. Love me.</p>8 </body>9</html>
Notice in the head of your document there is a link tag. Let's fully understand the attributes of this tag and what's going on here.
The first attribute and value is rel="stylesheet". This is actually a required attribute for the link tag.
It is required because it’s explaining the relationship between your current HTML document and the linked document.
In this case, it’s a stylesheet that you’re linking together.
The type="text/css" is clarifying what media type the browser should look for in order to read it correctly.
The href="styles.css" is indicating where the document exists inside your project. This suggests it’s in the same directory as your HTML document.
Benefits of Separate Stylesheets
So, why is this the generally recommended way of doing things?
Well, there are a few reasons:
- The content (HTML) and presentation (CSS) are clearly separated. This separation typically makes it easier and faster to update either one, even if some time has passed since working on the project. In an organized project, you would know where to look for each one. This separation is also a fairly established standard.
- This results in less CSS being written. You won’t have to repeat yourself as much.
- You can control the level of specificity of your styles. You can also have greater control over what styles will override each other. This reason alone is enough of a reason to separate out your styles.
Limitations of Separate Stylesheets
The biggest limitation of separate stylesheets is that it's not as closely tied to the HTML document as both inline and on page styles are.
The styles for a given HTML document may be broken up into more than 10 or 20 different stylesheets (depending on your stylesheet organization).
Although this has its benefits, it also leads to a few problems:
- Keeping your CSS across all these stylesheets clean and unbloated is hard. A big part of this is that it's hard to know which styles are still being used and which aren't.
- Another challenge is how to organize your stylesheets. One big long stylesheet is not always the best idea. So, where should different styles go?
Another issue with this approach relates to the cascading nature of CSS. Sometimes the styles across different stylesheets override each other unexpectedly. This can be rather frustrating when working on large projects.
You can usually avoid this problem completely by following a naming convention like BEM (my personal favorite), OOCSS, or SMACSS.
This also means you need to learn an effective way of naming your CSS classes.
CSS-in-JS
Another newer option for placing your CSS, is right inside your JavaScript component.
As JavaScript has evolved, many frameworks like React, Angular, and Vue use components as their building blocks.
If you're not familiar with what a component is, imagine your website or web application broken down into groups.
For instance, one group might be the navigation links used to navigate the site. These links are built inside a component. These components are then put together to create pages.
The beauty of this approach is that you only need to create a component once and then you can reuse it in any context within your project.
If you have a button component, for example, you only need to build it once and then place it on any page you might need a button.
CSS-in-JS is a way of writing your CSS inside the component and not in an external stylesheet.
It's a rather controversial approach to writing CSS with some designers/developers strongly for it and some strongly opposed.
Benefits of CSS-in-JS
There are a number of big benefits to this approach:
- The CSS is closely tied to the structure of the page. This makes it very easy to track down unused CSS and keep the CSS very clean and unbloated.
- Since the styles are scoped to the component, you avoid a lot of cascading issues with style overriding other styles unexpectedly.
- In some ways, it makes writing your CSS easier. You don't have to decide how to organize your stylsheets, since you won't really have any. You don't have to learn a naming convention (like BEM) since you won't usually be manually naming anything.
Limitations of CSS-in-JS
There are also a few limitations:
- If you're new to working within component-based frameworks there's a lot to learn just to write CSS. It's also tied so closely with the code that it sometimes requires some knowlege of JavaScript to be able to write CSS effectively.
- There is a lot of CSS-in-JS options - it's hard to narrow down to one. My personal favorite and the one I use on CSS Academy is Styled Components.
- Some CSS-in-JS solutions automatically apply class names to the selectors. This is to avoid any cascading conflicts. However, the class names are ugly and long and not easy to read. If you're using your browser's developer tools for debugging it makes it more difficult.
- Even though this can take some of the pains out of writing your styles in external stylesheets, it also adds a layer of complexity to a project. If it's a simple project, it may not worth it.
Summary
CSS stands for Cascading Style Sheets.
- Cascade: Styles lower down in your stylesheet will override styles higher up.
- Style: Determines how your content will look.
- Sheet: Where you write your styles - whether that's inline, on page, separate stylesheets, or some form of CSS-in-JS.