This episode opens the CSS journey: the definition and a brief history, the anatomy of a CSS rule, and three ways to include a stylesheet in an HTML document. You'll understand why the external approach has become the industry standard and how CSS application order works.

CSS stands for Cascading Style Sheets — the language that controls how HTML elements look. If HTML is the skeleton of a page, then CSS is its clothing, color, and motion. Since it was introduced in the mid-1990s, CSS has grown from the simple CSS1 into CSS3 and beyond, which is now shipped as independent modules such as Flexbox, Grid, and Animations.
This Episode 1 is the very first foundation. You'll understand what makes CSS cascading, read the structure of a CSS rule, and practice the three ways to include a stylesheet in HTML. From here, every declaration you write will carry clear meaning rather than being pure memorization.
Why does this episode matter? Because the most common beginner mistake is mixing CSS into HTML haphazardly. By the end of this episode, you'll know when to use inline, internal, or external styles, and why one approach is superior for real projects.
A CSS rule consists of a selector, a declaration block, properties, and values. Look at the example below:
h1 {
color: blue;
font-size: 28px;
}h1 is the selector that targets which element gets styled. Inside the curly braces, color and font-size are properties, while blue and 28px are values. Each property-value pair is separated by a colon and ends with a semicolon.
Selectors can get far more complex — classes, ids, attributes, even combinations of elements. All of these are covered step by step in episode 2. For now, remember the basic pattern: the selector determines who, and the declarations determine what changes.
Not every property name is valid. Browsers ignore mistyped declarations, so watch your spelling. Values also need to match the property type: color accepts keywords like red, hex codes like #ff0000, or functions like rgb(255, 0, 0). Episode 3 will dissect text and color properties in depth.
The first way: write properties directly in an element's style attribute. For example:
<p style="color: teal; font-weight: bold;">
Paragraf dengan inline style.
</p>Inline styles work and are quick for one-off experiments, but they can't be reused. Imagine 100 paragraphs that each need the same style — the markup becomes messy and hard to maintain. Use inline styles only for quick testing in DevTools or when injecting styles from JavaScript.
The second way: write CSS inside a style tag in the head section of the HTML document:
<!DOCTYPE html>
<html lang="id">
<head>
<meta charset="UTF-8">
<title>Internal Style</title>
<style>
h1 {
color: navy;
}
p {
font-size: 16px;
}
</style>
</head>
<body>
<h1>Judul</h1>
<p>Paragraf.</p>
</body>
</html>Internal styles group all rules in one place, but they only apply to a single page. They're fine for genuinely unique pages, yet duplication across pages remains a problem.
The third way — and the industry standard — is to keep CSS in a separate file and connect it with the link tag:
<!DOCTYPE html>
<html lang="id">
<head>
<meta charset="UTF-8">
<title>Eksternal Style</title>
<link rel="stylesheet" href="css/style.css">
</head>
<body>
<h1>Judul</h1>
<p>Paragraf.</p>
</body>
</html>Fill css/style.css with the same rules as before. A single stylesheet can be used by many pages at once, so a change only needs to be made once. This is the main reason the link rel="stylesheet" tag is always recommended.
The word cascading refers to how the browser combines all style sources — browser defaults, external stylesheets, internal, inline, and even styles from scripts — into a single final result. Not every declaration clashes brutally; there's a hierarchy that decides who wins.
The main rule: when two rules of equal strength target the same element, the rule that appears last in the source wins. This is why the order you write your CSS file matters so much.
From weakest to strongest:
style attribute.!important, and selector specificity rules.Specificity is a key concept you'll dig into in episode 2. For now, just understand that inline styles beat external files, and !important is a last-resort knife that must be used very carefully.
Use the project from episode 0 as your base. Make sure the server is running:
npx serve .Open localhost:3000 in the browser. Change values in css/style.css and watch how the page changes. You can also test cascading behavior by adding duplicate rules and seeing that the last rule wins.
Try adding an inline style to h1:
<h1 style="color: red;">Judul</h1>Notice that the h1 is now red even though css/style.css sets a different color. This proves the cascading hierarchy: inline styles are stronger than external stylesheets. The command npx serve . helps you test scenarios like this without complicated server configuration.
The most common symptom: the page appears with no styling at all. The cause is almost always a wrong href path. Check the location of the CSS file relative to index.html — in our structure, css/style.css means the path css/style.css from the project folder. Open DevTools and check the Network tab to see whether the CSS file loads with status 200.
One missing curly brace will break every rule that follows. Use your editor's auto-formatting (for example Prettier) and keep the two-space indentation inside the declaration block. When in doubt, run npx prettier --write css/style.css to tidy the file.
Key takeaways:
In the next episode, episode 2, we'll cover basic selectors and the specificity hierarchy — types of selectors like class, id, and attribute, how browsers calculate specificity weight, and how to write winning rules without a mess. Get your style.css ready, because selector writing practice is about to begin!