Setting Up a CSS Workflow

CSS is easiest to learn when you can see the effect of a change immediately, and easiest to work with professionally when your workflow scales past a single stylesheet. This lesson covers the practical setup: linking a stylesheet correctly, using browser DevTools to experiment with styles live, and understanding when it becomes worth introducing a preprocessor or a build step.

Why it matters

CSS does nothing until it is connected to a page, and a wrong path in the link element is the classic first bug: the page loads, unstyled, with no error on screen. Knowing how a stylesheet is linked, and how to try out changes live in DevTools before writing them down, is the routine you will repeat on every project.

Linking a Stylesheet

CSS is connected to HTML with a <link> tag inside <head>: <link rel="stylesheet" href="styles.css">. The path in href is resolved relative to the HTML file's location, so a common beginner error is an incorrect relative path when files are organized into folders.

Live-Editing Styles in DevTools

Open DevTools (F12), select an element in the Elements tab, and the Styles pane on the right shows every CSS rule applying to it, including which stylesheet and line number each rule comes from. You can toggle properties on and off, edit values, and add new declarations directly in this pane to test ideas instantly — changes here are temporary and vanish on reload, so once you find a value you like, copy it back into your actual .css file.

• Click any property value (like a color or a margin) to edit it in place and see the page update immediately.
• Use the "+" button in the Styles pane to add a brand-new rule for testing.
• The "Computed" sub-tab shows the final resolved value of every CSS property after all rules and inheritance are applied — useful when several rules are competing.

When to Introduce a Preprocessor or Build Step

For a single page or a small project, a plain linked .css file is entirely sufficient. As a project grows — multiple pages sharing colors and spacing, deeply nested component styles, or a need to split styles into many organized files — a preprocessor like Sass (.scss) becomes useful. Sass adds variables, nesting, and reusable mixins, and compiles down to plain CSS that browsers already understand, so you introduce a small build step (via a tool like Vite or the Sass CLI) that watches your .scss files and outputs .css automatically. Modern CSS has closed part of this gap natively with custom properties (variables) and nesting, so many projects now delay reaching for Sass longer than they used to.

Examples

<!-- index.html -->
<head>
  <link rel="stylesheet" href="css/styles.css">
</head>
<body>
  <h1 class="title">Getting Started</h1>
</body>

The page loads css/styles.css relative to index.html. If styles.css contains ".title { color: teal; }", the heading text renders in teal — visible immediately, with no build step required.

// styles.scss
$primary: teal;

.title {
  color: $primary;
  &:hover {
    color: darken($primary, 15%);
  }
}

/* Compiles to: */
/*
.title { color: teal; }
.title:hover { color: #0a4d4d; }
*/

Running the Sass compiler produces a plain .css file with the variable substituted and the nested &:hover rule expanded into a standard descendant-free selector, ready to link into HTML exactly like a hand-written stylesheet.

Exercise

The playground page already links style.css. Write your first rules: give the page a sans-serif font, make the heading teal, and limit main to a width of 600px, centred on the page.

Expected result: the content sits in a centred column and the heading is teal.

/* The page contains: <main> with an <h1>, a <p> and a <button> */

/* TODO: a sans-serif font for the whole page */

/* TODO: a teal heading */

/* TODO: main is at most 600px wide and centred */

/* The page contains: <main> with an <h1>, a <p> and a <button> */

body {
  font-family: system-ui, sans-serif;
}

h1 {
  color: teal;
}

main {
  max-width: 600px;
  margin: 0 auto;
}

Quick quiz

Interview questions