How I Fix an “Invalid CSS” Error and Level‑Up My Stylesheet

I saved your stylesheet with a .sass extension but wrote the code in SCSS style (curly braces + semicolons).

Why it matters:
Sass has two distinct syntaxes:

1. SCSS (.scss) – looks like regular CSS and requires braces {} and semicolons ;.
2. Indented Sass (.sass) – relies purely on indentation and rejects braces and semicolons.

Because the file extension said “indented Sass,” the compiler expected indentation‑only syntax. The moment it hit width: 80%;, it choked on the semicolon and threw this message.

Error Code

/* style.scss — but you saved it as test.sass */
#navbar {
  width: 80%;
  height: 23px;
}

The Moment Everything Broke

I was happily following a Sass tutorial and felt pretty confident until my terminal lit up red:

Invalid CSS after "80%": expected expression (e.g. 1px, bold), was ";"

How I’m fixing it for you:

• Option A (my choice): rename the file to style.scss and keep the SCSS braces exactly as you wrote them.
• Option B (alternate): keep the .sass extension but strip the braces/semicolons and rely on indentation.

I’ve gone with Option A so your original code compiles cleanly, and I’ll deliver the corrected file along with a compiled style.css. Let me know if you’d prefer the indentation‑only route instead.

I opened test.sass and, at first glance, everything looked fine:

/* style.scss — but you saved it as test.sass */
#navbar {
  width: 80%;
  height: 23px;
}

So why was the compiler yelling at me? Time for a deep dive.

Why the Compiler Barfs

Sass ships with two different syntaxes:

Syntax	Extension	Braces {} / Semicolons ;
SCSS	.scss	Yes (CSS‑like)
Indented Sass	.sass	No (relies on indentation)

I’d written SCSS but saved the file with a .sass extension. The indented‑syntax parser reached width: 80%; and screamed because a semicolon simply shouldn’t exist there. Hence the “expected expression” error.

Two Quick Ways to Fix It

Keep My Braces Rename to .scss

/* style.scss */
#navbar {
  width: 80%;
  height: 23px;
}

style.scss style.css   # compiles perfectly

Keep the .sass Extension Drop the Braces

// style.sass
#navbar
  width: 80%
  height: 23px

style.sass style.css   # also compiles perfectly

Either route works as long as syntax and extension match.

Stretch‑It Practice: Making the Snippet Worthwhile

Once I’d solved the error, I figured I’d practice a few core Sass tricks to turn a boring navbar into a flexible, DRY chunk of code.

/* ========= 4A · Variables ==================== */
$nav-height: 2.3rem;
$brand-green: #009688;

/* ========= 4B · Mixin ======================== */
@mixin subtle-shadow($y: 2px) {
  box-shadow: 0 $y 6px rgba(0, 0, 0, 0.15);
}

/* ========= 4C · Loop for Width Utilities ===== */
@for $i from 1 through 12 {
  .w-#{$i}\/*12*/ {
    width: ($i / 12) * 100%;
  }
}

/* ========= #navbar Using It All ============== */
#navbar {
  width: 80%;
  height: $nav-height;
  background: $brand-green;
  @include subtle-shadow(4px);
}

Things I Still Want to Try

Idea	What I’ll research next
Centralize flexbox utilities with @extend	@extend
Wrap common breakpoints in a respond($bp) mixin	Mixins + media queries
Rewrite the loop in indented Sass just for muscle memory	Syntax practice

Final Thought

All it took was one mismatched file extension to derail my flow. The bigger lesson? Tooling is unforgiving when configuration and code don’t align. But once they do, Sass transforms into a powerhouse:

• Variables keep numbers out of hard‑coded jail.
• Mixins eliminate copy‑paste fatigue.
• Loops generate whole utility systems in seconds.

Next time you hit an “Invalid CSS” wall, double‑check the basics then use the opportunity to push your stylesheet skills a notch higher. That’s exactly what I did, and my navbar (and future self) are already thanking me.