A single CSS file is a wonderful thing. Everything is in one place, nothing is hard to find, and the browser makes exactly one request. For a small site, that is not a compromise — it is the correct answer.
Then the file passes a thousand lines. Two people are editing it at once, merge conflicts appear on every branch, and scrolling to the right section takes longer than making the change. At that point the question is no longer whether to split the CSS, but how to split it so the pieces stay findable.
This guide is about that second question: the physical structure of a project’s stylesheets. Where files go, what they are called, the order they load in, and how a structure that works for three files keeps working at three hundred.
What “File Structure” Actually Means
Two related ideas get called “organizing CSS,” and it helps to keep them apart.
Inside a file
Rule organizationHow rules are ordered, grouped, named, and commented within a single stylesheet.
Layers, section headers, property order, token placement.
Between files
File structureHow the CSS is split into files and folders, and what order those files load in.
Folder layout, file names, link order, build step.
The two work together, and neither one alone is enough. A perfectly layered single file still becomes unmanageable at five thousand lines. Fifty well-named files loaded in the wrong order will produce a cascade that nobody can debug.
File structure answers four questions:
- Where does a new rule go? A developer should never have to guess.
- Where do I look when something breaks? The answer should be obvious from the symptom.
- What order do the files load in? Determined deliberately, not alphabetically by accident.
- How many requests does production make? Usually one, via a build step.
Ask a developer who has never seen the project to add a new component. If they can work out where the file goes and what to name it without asking anyone, the structure is working. If they need a conversation, it is not.
Starting Small: One File
Do not split CSS preemptively. Splitting adds overhead — more files to open, more link tags to maintain, more places for a rule to hide. Until the overhead is smaller than the confusion it prevents, one file is the better choice.
/* ==========================================================================
styles.css
--------------------------------------------------------------------------
1. Settings ....... design tokens
2. Base ........... reset and element defaults
3. Layout ......... containers and grids
4. Components ..... cards, buttons, nav
5. Utilities ...... single-purpose overrides
========================================================================== */
/* ==========================================================================
1. SETTINGS
========================================================================== */
:root {
--color-brand: #0891b2;
--color-text: #0f172a;
--space-3: 16px;
--radius-md: 12px;
}
/* ==========================================================================
2. BASE
========================================================================== */
*,
*::before,
*::after {
box-sizing: border-box;
}
body {
font-family: system-ui, sans-serif;
color: var(--color-text);
line-height: 1.7;
margin: 0;
}
/* ==========================================================================
3. LAYOUT
========================================================================== */
.l-container {
max-width: 1100px;
margin: 0 auto;
padding: 0 var(--space-3);
}
/* ==========================================================================
4. COMPONENTS
========================================================================== */
.card { }
.card__title { }
/* ==========================================================================
5. UTILITIES
========================================================================== */
.u-hidden {
display: none !important;
}Even in one file, the section headers do real work. A developer opening the file knows immediately where the tokens live, where to add a component, and why utilities are at the bottom.
When to split
There is no universal line count, but these signals are reliable.
- The file passes roughly 500–800 lines. Scrolling becomes the main way you navigate.
- More than one person edits it. Merge conflicts get worse with every additional contributor.
- You keep scrolling past the same sections. A sign the layers want to be separate files.
- You want per-component ownership. One file per component lets different people work without colliding.
- You have a build step. Once files are concatenated for production, splitting costs nothing at runtime.
The moment you have more than one stylesheet, the order they load in becomes part of the cascade. Splitting without deciding on an order is how projects end up with utilities that lose to components — a bug that is confusing precisely because everything looks correct.
The Numbered Layer Approach
The simplest effective structure keeps the layer order from the single file, but gives each layer its own file with a number in front of it.
Why the numbers matter
The number prefix does two things at once. It makes the correct load order obvious on disk
— file explorers sort alphabetically, so 01 through 06 appear in
the order they should load. And it removes any ambiguity for a new developer: there is no
question whether base.css comes before or after settings.css.
<head>
<link rel="stylesheet" href="css/01-settings.css">
<link rel="stylesheet" href="css/02-base.css">
<link rel="stylesheet" href="css/03-layout.css">
<link rel="stylesheet" href="css/04-components.css">
<link rel="stylesheet" href="css/05-utilities.css">
<link rel="stylesheet" href="css/06-print.css" media="print">
</head>What goes in each file
body, h1–h6, p, a, img.
.u-hidden, .u-truncate, .u-flow.
@media print block. Linked with media="print" so it never affects the screen version.
This structure carries a project a long way. Its natural limit is
04-components.css — once it passes a thousand lines, it becomes the same
problem you split the original file to avoid. That is the signal to move to
folder-per-component.
The 7-1 Pattern
The 7-1 pattern is the best-known CSS folder structure. It was popularized by the Sass community, but nothing about it requires a preprocessor — it works just as well with plain CSS and a build step.
The name describes it: seven folders, plus one main file that loads them all in order.
What each folder holds
Design tokens and reusable helpers. Produces no CSS of its own — just values that everything else references.
Resets and default element styling. What a bare <h1> or <p> looks like with no class.
Every reusable UI piece. The largest folder, and the one that grows fastest.
Page-level structure — containers, grids, headers, footers. Position and size only.
Rules that genuinely apply to one page. Should stay small — a large pages folder usually means components are missing.
Alternate themes such as dark mode. Mostly a set of token overrides under a different condition.
Third-party stylesheets. Loaded early, never edited, excluded from linting.
The single entry point. Loads every folder in the correct order and nothing else.
The load order in main.css
The order folders load in is not arbitrary — it follows the same generic-to-specific rule as everything else in CSS.
/* ==========================================================================
main.css
--------------------------------------------------------------------------
Load order matters. This is the cascade, written as a file list.
========================================================================== */
/* 1. Tokens — must come first, everything references them */
@import "abstracts/variables.css";
/* 2. Third-party — loaded early so your rules can override them */
@import "vendors/normalize.css";
/* 3. Base — element defaults */
@import "base/reset.css";
@import "base/typography.css";
/* 4. Layout — page structure */
@import "layout/container.css";
@import "layout/grid.css";
@import "layout/header-footer.css";
/* 5. Components — the bulk of the CSS */
@import "components/button.css";
@import "components/card.css";
@import "components/form.css";
/* 6. Page-specific — overrides for individual pages */
@import "pages/home.css";
@import "pages/pricing.css";
/* 7. Themes — token overrides, last so they win */
@import "themes/dark.css";
In this pattern, @import is normally processed by a build tool such as Sass,
PostCSS, or a bundler — it never reaches the browser. If you are writing plain CSS with
no build step, use <link> elements in the HTML instead, because
browser-level @import forces serial downloads.
Is 7-1 overkill?
Often, yes. The pattern was designed for large Sass codebases with many contributors, and it carries real overhead — eight folders, a partial convention to learn, and a build step to set up.
| Signal | Verdict |
|---|---|
| Fewer than 20 components | Overkill — use numbered layers instead |
| No build step | Overkill — the @import chain hurts more than it helps |
| One or two developers | Probably overkill — but harmless if the team likes it |
| 50+ components, several contributors | Worth it — the structure pays for itself |
| A design system shared across products | Worth it — this is what it was designed for |
| Multiple themes or white-label variants | Worth it — the themes folder earns its place |
The valuable part of 7-1 is the ordering principle and the separation of concerns — not the specific number seven. Plenty of healthy projects use four folders. Plenty of unhealthy ones use all eight.
Folder-Per-Component
Once the components layer is the biggest part of the project, it deserves the same treatment the stylesheet got: split it up. The common approach is one folder per component, holding the component’s CSS and its assets together.
Everything about a component lives in one directory. To delete a component, you delete a folder — and you know instantly that nothing was left behind.
Why this scales
What it gives you
Each component is a self-contained unit with a clear owner and a clear boundary.
Deleting a component is one folder deletion, not a search across four files.
Two developers can work on different components with zero merge conflicts.
What it costs
Many small files, which is noisy without a build step to combine them.
Requires discipline — a stray rule in the wrong component folder is easy to miss.
A shared value used by three components needs a home in abstracts, not in any of them.
A component folder may only import from abstracts/ and from itself. If the
card needs something the button defines, that thing belongs in abstracts as a shared
token. Components should never depend on each other.
Naming Files Consistently
File names are part of the structure. A directory listing should tell you what the project looks like without opening anything.
Card.css or
card_style.css.
.product-card, the file is product-card.css.
The mapping should be memorizable.
The rules, in short
- All lowercase. Some servers and build tools are case-insensitive, and mixing cases creates avoidable confusion.
- Hyphens, not underscores — except for a leading partial underscore, where the convention applies.
- Numbers only where order matters. Do not number component files.
- Match the block name.
.cardlives incard.css. - No generic names.
styles.css,main.css, andmisc.cssare all dead ends. - One noun per file.
card.css, notcard-and-modal.css.
styles.css
Card.css
card_styles.css
productCard.css
misc.css
new-styles-2.css
final.cssmain.css
card.css
product-card.css
navigation.css
form.css
modal.css
final.css, final-v2.css, and styles-old.css are
the fossil record of a project that lost track of itself. If a file needs a version
number in its name, the real problem is that the old one was never deleted.
How Files Get Loaded
File structure only affects the cascade through one thing: load order. There are two ways to control it, and most projects use both.
Option A — link elements in the HTML
During development, link each file directly. The browser fetches them in parallel, and the order of the tags is the order of the cascade.
<head>
<link rel="stylesheet" href="css/01-settings.css">
<link rel="stylesheet" href="css/02-base.css">
<link rel="stylesheet" href="css/03-layout.css">
<link rel="stylesheet" href="css/04-components.css">
<link rel="stylesheet" href="css/05-utilities.css">
</head>Option B — a build step
For production, a build tool concatenates and minifies every file into one stylesheet. The HTML then links a single file, and the browser makes a single request.
<!-- Development: five requests, but readable -->
<link rel="stylesheet" href="css/01-settings.css">
<link rel="stylesheet" href="css/02-base.css">
<link rel="stylesheet" href="css/03-layout.css">
<link rel="stylesheet" href="css/04-components.css">
<link rel="stylesheet" href="css/05-utilities.css">
<!-- Production: one request, one file -->
<link rel="stylesheet" href="css/main.min.css">This is the answer to the obvious objection about file count. Fifty files during development does not mean fifty requests in production — it means fifty files a developer can navigate, combined into one file a browser can cache.
| Aspect | Development | Production |
|---|---|---|
| File count | Many small files | One combined file |
| Requests | One per file | One total |
| Readable names | Yes — card.css |
No — minified into one file |
| Comments | Kept | Stripped by the minifier |
| Source maps | Not needed | Generated, so DevTools shows the original file |
Once the CSS is combined and minified, DevTools would show you line 1 of a
main.min.css. A source map tells the browser where each rule originally
came from, so the Styles panel keeps pointing at card.css line 42. Generate
them in production.
Partials and Preprocessor Conventions
If you use Sass or Less, a few file conventions come with the territory. None of them are required for plain CSS, but you will encounter them in almost any codebase that uses a preprocessor.
The underscore prefix
A leading underscore marks a partial — a file that is meant to be imported
into another file, not compiled on its own. Sass will not generate a separate
.css file for a partial, which prevents accidental duplicate output.
The entry point
Exactly one file in the project is the entry point — the one the build compiles. Everything else is imported by it.
/* main.scss — the only file the build compiles */
/* Abstracts — no output, just values */
@use "abstracts/variables";
@use "abstracts/mixins";
/* Base */
@use "base/reset";
@use "base/typography";
/* Layout */
@use "layout/container";
@use "layout/grid";
/* Components */
@use "components/button";
@use "components/card";
/* Utilities — last, so they win */
@use "utilities/helpers";
If a file in abstracts/ emits actual CSS — a stray rule, a reset — it will
appear in the output at whatever point it was first imported. That is how duplicate
resets end up in a compiled stylesheet. Keep abstracts to tokens, functions, and mixins
only.
Where Everything Else Goes
CSS is not the only thing in a project folder. These conventions keep the rest of it predictable too.
-
Images, icons, and other static files. Kept separate from styles so a
build can hash and optimize them independently. Some projects split further into
images/andicons/. -
Self-hosted font files. Usually
.woff2with a.wofffallback. Loading a font file is a network request — the folder keeps them findable. - Third-party CSS you did not write. Normalize, a carousel library, a date picker. Never edited directly, loaded before your components, excluded from linting.
- Alternate token sets. Dark mode, high contrast, or a white-label brand variant. Loaded last so their token overrides win.
<head>
<!-- Vendor loads before your own CSS so you can override it -->
<link rel="stylesheet" href="css/vendor/normalize.css">
<!-- Your layers, in order -->
<link rel="stylesheet" href="css/01-settings.css">
<link rel="stylesheet" href="css/02-base.css">
<link rel="stylesheet" href="css/03-layout.css">
<link rel="stylesheet" href="css/04-components.css">
<link rel="stylesheet" href="css/05-utilities.css">
<!-- Theme overrides last -->
<link rel="stylesheet" href="css/themes/dark.css">
</head>If you need to change something in a third-party stylesheet, override it in your own code. The moment you edit the vendor file, the next library update erases your change — and nobody will remember it was there.
Structures for Three Project Sizes
Rather than one ideal structure, here are three that match three genuinely different situations. Pick the smallest one that fits.
One file
Up to roughly 500 lines. A landing page, a portfolio, a small brochure site.
Layers as section headers inside styles.css.
Numbered layers
A few hundred to a few thousand lines. Most business sites, blogs, and marketing sites.
Five or six files with number prefixes, linked in order.
Folders
A design system, a multi-product platform, or a large team codebase.
Folder-per-layer or folder-per-component, with a build step.
Small: one file
Medium: numbered layers
Large: folder-per-layer
| Project size | Structure | Build step | Files |
|---|---|---|---|
| Small — one page, one author | Single file | Not needed | 1 |
| Medium — a few pages, small team | Numbered layers | Optional | 5–6 |
| Large — design system, many teams | Folder-per-layer or folder-per-component | Recommended | 20–200 |
Start small. When the file gets uncomfortable, split it into numbered layers. When the components file gets uncomfortable, split that into a folder. Each step is mechanical because the layer order was already correct.
Migrating from One File to Many
Rewriting a stylesheet from scratch is almost always a mistake. The safer path is to extract one layer at a time, testing after each move.
The extraction order
Extract from the top of the cascade downward. Each layer you remove from the original file is a layer you no longer have to scroll past.
- Settings. Move every custom property into
01-settings.css. Nothing depends on it except the values, so this move is safest first. - Base. Move the reset and element defaults into
02-base.css. - Layout. Move containers and grids into
03-layout.css. - Components. This is usually the largest move. Extract one component at a time.
- Utilities. Move them into
05-utilities.css— and confirm they still win the cascade. - Print. Move the
@media printblock into its own file.
/* 01-settings.css */
:root { --color-brand: #0891b2; }
/* styles.css — still here */
:root { --color-brand: #0891b2; }
/* Duplicated. Whichever loads
last silently wins, and nobody
knows there are two. *//* 01-settings.css */
:root { --color-brand: #0891b2; }
/* styles.css — removed */
/* One definition.
One place to edit.
Test after every move. */CSS failures are silent, and a rule loaded from the wrong file looks identical to a rule that was deleted by accident. Refresh and check the page after each layer moves — before the next one. If something breaks, you know exactly which move caused it.
Using the DevTools Coverage panel first
Before migrating a large stylesheet, open DevTools and use the Coverage panel to see which rules are actually used. On a mature project it is common to find that a significant share of the CSS is dead — rules for components that no longer exist. Deleting dead rules is easier than moving them, and it makes the migration shorter.
/*
A practical migration checklist
1. Duplicate the stylesheet as a backup
2. Open DevTools → Coverage → reload the page
3. Delete the rules that are clearly unused
4. Create the empty layer files
5. Link them in the correct order in the HTML
6. Move one layer, delete it from the original
7. Refresh. Does the page look identical?
8. Repeat for the next layer
9. Delete the now-empty original file
*/Common File Structure Mistakes
These are the patterns that turn a clean structure into a maze. Each one looks harmless in isolation.
1. Linking files in the wrong order
<link rel="stylesheet" href="utilities.css">
<link rel="stylesheet" href="components.css">
/* .u-hidden loses to .card's
display rule, because
components load later. */<link rel="stylesheet" href="components.css">
<link rel="stylesheet" href="utilities.css">
/* .u-hidden wins, as intended. */2. Splitting by page instead of by layer
css/
├── home.css
├── about.css
├── blog.css
└── pricing.css
/* The card is styled four
times, slightly differently. */css/
├── 01-settings.css
├── 02-base.css
├── 03-layout.css
└── 04-components.css
/* The card is defined once. */3. Chaining @import in the browser
<link rel="stylesheet" href="styles.css">
/* Inside styles.css */
@import "base.css";
@import "layout.css";
@import "components.css";
/* Each import waits for the
previous one to finish. */<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="layout.css">
<link rel="stylesheet" href="components.css">
/* Fetched in parallel.
Or combine them at build time. */4. Naming a file after nothing in particular
misc.css
helpers.css
extra.css
new.css
styles2.css
/* Nobody knows what is in
any of these. */05-utilities.css
03-layout.css
components/card.css
components/modal.css
themes/dark.css5. One giant components file
css/
├── 01-settings.css
├── 02-base.css
└── 04-components.css /* 4,000 lines */
/* The split solved nothing.
The scroll just moved. */css/
└── components/
├── button.css
├── card.css
├── form.css
├── modal.css
└── navigation.css
/* Each file is small and
has one subject. */6. Editing vendor files
/* vendor/normalize.css */
body {
margin: 0;
font-family: Inter; /* added by us */
}
/* Next library update
overwrites the whole file. *//* 02-base.css */
body {
font-family: Inter, system-ui, sans-serif;
}
/* The vendor file stays
exactly as published. */7. Forgetting to delete the original after moving
/* 04-components.css */
.card { padding: 24px; }
/* styles.css — never deleted */
.card { padding: 16px; }
/* Both load. The later one wins,
and the developer who edits
the first file sees no effect. *//* 04-components.css */
.card { padding: 24px; }
/* styles.css deleted.
One definition. */8. Numbering files when order does not matter
components/
├── 01-button.css
├── 02-card.css
├── 03-modal.css
└── 04-form.css
/* The numbers imply an order
that does not exist, and
inserting a component means
renumbering everything. */css/
├── 01-settings.css
├── 02-base.css
├── 03-layout.css
└── components/
├── button.css
├── card.css
└── modal.css
/* Numbers mark the layers.
Components need no order. */
styles-v2.css and final-final.css are symptoms, not solutions.
Version control already tracks history — a version number in a filename means the
previous file was never cleaned up.
Best Practices
These habits keep a file structure workable as a project grows from one stylesheet to fifty.
Start with one file
Split only when the overhead of splitting is smaller than the confusion it prevents.
Number the layers
01-settings.css through 06-print.css — the load order is then obvious on disk.
Follow the generic-to-specific order
Tokens, then base, then layout, then components, then utilities. The cascade then works with you.
Group by layer, not by page
Page-based folders duplicate every shared component. Layers do not.
Name files after their subject
card.css, not styles2.css or misc.css.
Link in order, do not @import
Multiple <link> elements load in parallel; browser-level @import chains serially.
Combine at build time
Many files in development, one file in production. Best of both.
Never edit vendor files
Override them in your own layer. The next library update will erase your changes.
Delete the original after moving
A duplicated rule loads twice, and the one you edit may not be the one that wins.
Start with one file, number the layers when you split, load them from generic to specific, name every file after its subject, and combine them for production.
Frequently Asked Questions
1. What is CSS file structure?
CSS file structure is how a project’s stylesheets are divided into files and folders, and the order in which those files are loaded. It is the physical organization of the CSS, as opposed to the internal organization of the rules inside a single file.
2. Should I put all my CSS in one file?
For a small site or a learning project, one file is fine and often preferable. Once a stylesheet passes roughly 500 to 800 lines, or once more than one person edits it, splitting into files organized by layer or component becomes easier to work with.
3. Does splitting CSS into many files slow down a site?
Not if you use a build step. During development multiple files are easier to work with, and for production they are concatenated and minified into a single stylesheet so the browser makes one request. Linking fifty raw files without combining them would slow things down.
4. What is the 7-1 pattern?
The 7-1 pattern splits CSS into seven folders — abstracts, base, components, layout, pages, themes, and vendors — plus one main file that imports them all in order. It was popularized by the Sass community and works for plain CSS as well.
5. Why are CSS files numbered like 01-settings.css?
Numbered prefixes keep the files in the correct cascade order both on disk and in the browser. Alphabetical sorting then matches the intended load order, so settings always load before base, and utilities always load last.
6. What does the underscore prefix mean in a CSS filename?
In Sass and Less, a leading underscore marks a partial — a file that is meant to be imported rather than compiled on its own. In plain CSS the convention has no technical meaning, but many projects keep the underscore so the file list visually separates entry points from imported fragments.
7. Should I use @import to combine CSS files?
No. @import forces serial downloads because the browser cannot discover
the imported file until it has parsed the parent stylesheet. Use separate
<link> elements during development, or a build step that
concatenates the files into one output.
8. Where should layout rules go in a CSS file structure?
In their own layer, usually a layout folder or a file such as
03-layout.css. Layout rules handle positioning and structure only —
containers, grids, and regions — and should be separate from component appearance so
the two can change independently.
9. Where do third-party stylesheets belong?
In a vendor/ folder, kept separate from your own code so they are never
edited directly. Vendor files load before your components so your rules can override
them, and they are excluded from linting and formatting.
10. How many CSS files should a project have?
As many as the project genuinely needs. A small site might have three or four files; a design system might have one file per component. The number matters far less than whether the structure is consistent and the load order is deliberate.
11. Should pages have their own CSS files?
Only for rules that genuinely apply to one page. Most styling belongs in components,
which are reusable. A pages/ folder is useful for genuine one-offs such as
a landing page hero, but it should stay small — a large pages folder usually means
components are missing.
12. How do I migrate from one big CSS file to a proper structure?
Do it incrementally rather than all at once. Extract one layer at a time — settings first, then base, then components — linking the new files in the correct order and removing the duplicated rules from the original file after each move. Test after every extraction.
Key Takeaways
- File structure is how CSS is split into files and folders, and the order they load in.
- Start with one file; split only when the overhead is smaller than the confusion.
- Numbered prefixes make the correct load order obvious on disk and in the browser.
- Load order runs from generic to specific: tokens, base, layout, components, utilities.
- Group by layer, never by page — pages duplicate, layers do not.
- The 7-1 pattern is seven folders plus one entry file; useful for large projects, overkill for small ones.
- Folder-per-component keeps a component’s CSS, markup, and tests together.
- Name files in lowercase kebab-case, after their subject.
- Use multiple
<link>elements instead of chaining browser-level@import. - Combine and minify files at build time so production makes one request.
- Keep vendor CSS separate and never edit it directly.
- When migrating, move one layer at a time and test after every move.
What to Learn Next
Now that the file structure is settled, the next step is the organization inside each file. Start with How to Organize CSS Code and CSS Naming Conventions.
From there, explore CSS Custom Properties for the tokens layer, and CSS Comments for documenting the structure. When you are ready to build layouts, read CSS Flexbox Guide and CSS Grid Guide, then move on to Responsive Web Design.
If you are still connecting the pieces, read How to Add CSS to HTML, CSS Syntax Explained, and What Is CSS? for the surrounding context.
Practice Challenge
The fastest way to understand file structure is to build one, break it, and rebuild it properly. This exercise takes about thirty minutes.
- Create a project folder with
index.htmland a singlestyles.css. - Build a page with three components: a card, a button, and a navigation bar. Use hard-coded values throughout.
- Add a second page,
about.html, that reuses the card and the button. - Copy the card and button rules into
about.htmlusing a<style>block, and change one value slightly. Now the two pages differ. - Realize the problem. Delete the inline styles and split
styles.cssinto five numbered layer files:01-settings.css,02-base.css,03-layout.css,04-components.css, and05-utilities.css. - Move the custom properties into settings, the reset into base, the nav and container into layout, and the card and button into components.
- Link all five files in order from both pages, and confirm they both render correctly.
- Add a
.u-hiddenutility at the end of05-utilities.cssand verify it can hide a card that hasdisplay: flex— with no!importantneeded. - Now break the order deliberately: move the utilities link above the components link and refresh. Confirm the utility stops working. Put it back.
- Split
04-components.cssinto acomponents/folder with one file per component. - Add a
main.cssentry point that imports all the layers in order, and link only that one file from the HTML. - Finally, open DevTools and confirm you can still see each rule attributed to its original file in the Styles panel.
If you complete those steps, you have felt the duplication problem that forces a split, built a numbered layer structure, watched the cascade break when the order was wrong, and moved up to folder-per-component with an entry point. More importantly, you have seen that the load order is not a detail — it is the mechanism the whole structure depends on, and getting it wrong produces bugs that look like CSS is simply not working.
Inar Learn 