CSS Syntax Basics

Introduction

Good CSS starts with correct syntax. If syntax is broken, browsers silently ignore parts of your stylesheet and your page looks wrong. This chapter explains the core grammar of CSS rules, declarations, values, comments, and common syntax mistakes so you can write reliable styles from day one.

Prerequisites

• Basic HTML knowledge
• A linked external stylesheet (styles.css)
• A browser with DevTools

Anatomy of a CSS Rule

A CSS rule has two main parts:

1. Selector: chooses which element(s) to style
2. Declaration block: contains one or more property-value declarations

p {
  color: #334155;
  line-height: 1.7;
}

In this example:

• p is the selector
• { ... } is the declaration block
• color: #334155; is one declaration
• line-height: 1.7; is another declaration

A CSS file is made up of many such rules.

Declarations: Property + Value

Each declaration follows:

property: value;

Examples:

font-size: 16px;
margin-top: 1rem;
background-color: #f8fafc;

Rules to remember:

• property and value are separated by :
• each declaration ends with ;
• whitespace is mostly flexible, but consistency improves readability

Why Semicolons Matter

Browsers are tolerant, but missing semicolons can cause confusing bugs when multiple declarations exist.

Risky:

h1 {
  color: #0f172a
  margin-bottom: 1rem;
}

Safer:

h1 {
  color: #0f172a;
  margin-bottom: 1rem;
}

Use semicolons consistently, including after the last declaration, to make edits safer.

Braces and Blocks

A declaration block must be wrapped with { and }.

Invalid:

.card
  padding: 1rem;
  border-radius: 12px;

Valid:

.card {
  padding: 1rem;
  border-radius: 12px;
}

One missing brace can break many following rules.

CSS Comments

A comment is plain text in your code that the browser does not execute or display. Its only job is to help humans—including you and other developers—understand purpose, logic, or temporary notes.

CSS comments use this format:

/* This is a CSS comment */

Use comments for meaningful sections:

/* Layout: page container */
.container {
  width: min(960px, 100% - 2rem);
  margin: 0 auto;
}

Avoid noisy comments that only repeat obvious code.

Multiple Selectors in One Rule

You can group selectors with commas:

h1,
h2,
h3 {
  line-height: 1.2;
}

The rule above selects every <h1>, <h2>, and <h3> on the page and applies line-height: 1.2; (1.2 times the font size) to all of them.

This reduces duplication for shared declarations.

Value Types You See Often

Common value categories:

• keywords: block, none, bold
• lengths: 16px, 1rem, 50%
• colors: #2563eb, rgb(37, 99, 235)
• numbers: 1.5 (often for line-height)
• functions: calc(...), clamp(...)

Example:

main {
  width: min(900px, 100% - 2rem);
  margin: 2rem auto;
}

Case Sensitivity and Naming

General guidance:

• CSS property names are lowercase (font-size, not Font-Size)
• class names are conventionally lowercase kebab-case (.hero-title)
• keep naming consistent across HTML and CSS

Class name mismatch is a common source of “CSS not applying.”

Basic Formatting Conventions

Readable style:

.button {
  padding: 0.65rem 1rem;
  border-radius: 999px;
  background: #2563eb;
  color: #fff;
}

Useful conventions:

• one declaration per line
• 2 spaces indentation
• blank lines between logical blocks
• consistent quote style when needed

Prettier can automate this formatting.

Common Syntax Errors

Browsers often fail silently, so use DevTools and lints early.

Debugging Syntax with DevTools

When a rule fails:

1. Open DevTools and inspect the target element
2. Check whether the selector appears in the Styles pane
3. Look for crossed-out or missing declarations
4. Verify spelling, punctuation, and units
5. Fix and refresh

You can also temporarily type the declaration directly in DevTools to validate syntax quickly.

Mini Exercise

Create a small file and intentionally test syntax:

1. Write a valid .card rule
2. Remove one semicolon and observe what breaks
3. Misspell one property and inspect DevTools
4. Restore valid syntax
5. Run formatter and compare readability

This helps you recognize syntax failures immediately in real projects.

FAQ

Is CSS strict like Java or JavaScript?

CSS is more fault-tolerant. Browsers skip invalid declarations and continue parsing valid ones.

Do I always need a semicolon on the last declaration?

Technically not always, but you should keep it. It prevents editing mistakes and improves consistency.

Why is there no error popup when CSS is wrong?

Browsers usually do not throw visible runtime errors for invalid CSS declarations. DevTools and linters are your primary feedback tools.

Can I put multiple declarations on one line?

You can, but it hurts readability and debugging. One declaration per line is better for most teams.

What is the fastest way to catch syntax issues?

Use formatter + Stylelint + DevTools together. They catch most syntax and typo mistakes quickly.