What CSS Actually Is

What CSS Actually Is

CSS (Cascading Style Sheets) is the language that describes how HTML content should be presented — colors, spacing, layout, typography, animation. HTML says what a page contains; CSS says how it should look. It's maintained as a set of modular specifications by the W3C's CSS Working Group, which is why you'll see references to "CSS Grid Level 1" or "Selectors Level 4" rather than one single version number the way you'd talk about Python 3.13.

The first CSS specification (Level 1) was proposed by Håkon Wium Lie in 1994 and became a W3C Recommendation in December 1996. Before CSS existed, styling was done with HTML attributes like <font color="red"> scattered through every page — CSS separated content from presentation, which is the single most important idea in the entire language and the reason it's called cascading: rules from different sources cascade together, and CSS has explicit, predictable rules for which one wins.

That word — cascading — is not decorative. It's the actual algorithm the browser runs on every single element: gather every rule that could apply, sort them by origin, importance, specificity, and source order, and apply the winner. Most "my CSS isn't working" confusion is really just not knowing this algorithm exists.

The Cascade — How the Browser Decides Which Rule Wins

When two rules target the same element and the same property, the browser doesn't pick randomly or just take "whichever loaded last." It runs through a strict sequence of tie-breakers, in this exact order:

• ▶

  1. Origin & Importance — user-agent (browser default) styles lose to author (your) styles, which lose to user styles marked !important, which lose to author styles marked !important. In practice: your normal CSS beats the browser's defaults, and !important beats almost everything, which is exactly why overusing it turns a stylesheet into a maintenance nightmare — you end up needing !important to beat your own earlier !important.

• ▶

  2. Specificity — a numeric score calculated per selector (covered in detail below). Higher score wins, full stop, regardless of which rule appears first or last in the file.

• ▶

  3. Source Order — only reached when specificity is exactly tied. The rule that appears later in the stylesheet (or in a later <link>/<style> block) wins.

This ordering explains a specific, very common bug: you add a new CSS rule at the very bottom of your file, expecting it to override an earlier one because "it comes later" — but it doesn't apply, because the earlier rule has a higher specificity score. Source order is the last tie-breaker, not the first.

Specificity, With the Actual Math

Specificity is usually taught as an abstract concept. It's actually just arithmetic — a 3-column score, conventionally written as (A, B, C), calculated per selector:

• ▶

  A — count of ID selectors (#header). Each one = 1 point in this column.

• ▶

  B — count of class selectors (.btn), attribute selectors ([type="text"]), and pseudo-classes (:hover). Each one = 1 point in this column.

• ▶

  C — count of type/element selectors (div, p) and pseudo-elements (::before). Each one = 1 point in this column.

Columns are compared left to right, never added across columns — a single ID selector (1,0,0) beats fifty combined class selectors (0,50,0), because you compare column A first and A already decides it.

/* Specificity (0,1,1) — one class + one element */
nav.primary-menu { color: navy; }

/* Specificity (0,2,0) — two classes, no element */
/* This WINS over the rule above: (0,2,0) > (0,1,1) at column B */
.site-header .primary-menu { color: crimson; }

/* Specificity (1,0,0) — one ID */
/* This wins over BOTH rules above, regardless of order in the file */
#main-nav { color: forestgreen; }

Inline styles (style="color: red" written directly in HTML) beat every selector-based rule regardless of specificity score — they aren't even part of this A/B/C system, they sit above it. !important goes a level above even that. Both exist as escape hatches; relying on either routinely is usually a sign the underlying CSS architecture needs rethinking, not a normal styling technique.

The Box Model — Where 90% of Layout Bugs Actually Come From

Every single element on a page is a rectangular box made of four layers, from inside out: content, padding, border, and margin. The bug that catches nearly every beginner is this: by default, width and height apply only to the content box — padding and border get added on top, making the element's actual rendered size larger than what you set.

.card {
  width: 300px;
  padding: 20px;
  border: 2px solid #ccc;
  /* Rendered width is actually 300 + 20+20 + 2+2 = 344px, NOT 300px */
}

.card-fixed {
  box-sizing: border-box; /* width now INCLUDES padding + border */
  width: 300px;
  padding: 20px;
  border: 2px solid #ccc;
  /* Rendered width is exactly 300px, content area shrinks to fit */
}

This is common enough that most CSS resets — including the popular modern-normalize approach and Josh Comeau's widely-used reset — apply box-sizing: border-box to every element globally as one of the first rules in the entire stylesheet:

*, *::before, *::after {
  box-sizing: border-box;
}

Flexbox vs Grid — Which One, and When

This gets asked constantly and the honest answer is that they solve different shaped problems, not competing versions of the same problem. My rule of thumb after years of picking wrong in both directions: if you're arranging items along a single line — a navbar, a row of buttons, a sidebar next to content — reach for Flexbox first. The moment you're thinking in rows AND columns simultaneously — a photo gallery, a dashboard, a page-level layout — Grid is almost always less code and fewer nested wrapper divs.

.product-grid {
  display: grid;
  /* auto-fit + minmax: as many 240px-min columns as fit, no media query needed */
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

That single repeat(auto-fit, minmax(...)) line is doing what used to take three or four separate media query breakpoints in pre-Grid CSS — the grid recalculates its own column count as the viewport resizes, with zero JavaScript and zero @media rules.

What's Genuinely New in CSS by 2026

CSS has shipped more practically useful features in the last five years than in the decade before that. These aren't experimental — all of the following have solid cross-browser support as of 2026.

Do You Still Need Sass in 2026?

This is a genuinely different answer than it would have been in 2019. Sass became popular because vanilla CSS had no variables, no nesting, and no mixins. Native CSS now has custom properties (variables), and nesting shipped natively in all major browsers in 2023. A lot of what teams reached for Sass to get is now just... CSS.

My honest take: for a small to mid-size project, I'd skip adding a Sass build step in 2026 purely for variables and nesting — native CSS covers that now, and one less build tool is one less thing to configure and maintain. Where Sass still earns its place is generating large sets of repetitive utility classes with @each loops across a big design system, which native CSS genuinely can't do yet.

Writing Your First Stylesheet

CSS reaches an HTML page in one of three ways: an external .css file linked via <link> (the standard, maintainable approach), a <style> block inside the HTML <head>, or inline via the style attribute on a single element. For anything beyond a one-off test, external stylesheets are the only one worth using in real projects — they're cacheable by the browser and keep structure and presentation separated.

body {
  font-family: system-ui, sans-serif;
  margin: 0;
  background-color: #f8fafc;
}

.hero-title {
  color: #1e293b;
  font-size: clamp(1.75rem, 4vw, 3rem);
  text-align: center;
}

Practice This Code — Live Editor

Bugs You'll Hit in Your First Week With CSS

• ▶

  Margin collapsing between stacked elements — two vertically adjacent block elements with margin-bottom: 20px and margin-top: 20px don't add up to 40px of gap; adjacent vertical margins collapse into a single 20px gap (the larger of the two). This trips up nearly everyone the first time they measure the actual rendered spacing and it doesn't match their math.

• ▶

  "display: none vs visibility: hidden" confusion — display: none removes the element from layout entirely, as if it doesn't exist; visibility: hidden keeps its space reserved but makes it invisible. Using the wrong one is a very common cause of "my layout shifted when I hid this element" bugs.

• ▶

  Percentage heights not working — height: 50% on a child does nothing unless the parent has an explicit height set. Percentage heights resolve against the parent's computed height, and if the parent's height is itself auto (sized by its content), there's nothing concrete to take 50% of.

• ▶

  z-index doing nothing — z-index only has an effect on elements with a position value other than static (relative, absolute, fixed, or sticky). Setting z-index: 999 on a statically positioned element is silently ignored by the browser.

• ▶

  Forgetting the universal box-sizing reset — without box-sizing: border-box applied globally, every width calculation involving padding or border needs manual mental math, which is exactly the trap covered in the box model section above.

Where CSS Skill Actually Shows Up on the Job

At most product companies — think mid-size D2C brands, fintech dashboards, SaaS admin panels — CSS isn't a separate role anymore; it's assumed baseline knowledge for any frontend developer. What differentiates a junior from a senior frontend dev in interviews at these companies is rarely "do you know Flexbox" and almost always can you debug a live layout bug you've never seen before — reading computed styles in DevTools, understanding why a specificity conflict is winning, spotting a stray margin collapse.

• ▶

  🖥️ Product & SaaS Dashboards — dense data tables, responsive charts, and form-heavy admin panels live or die on disciplined CSS architecture (BEM naming, utility classes, or CSS Modules) that scales across a large, multi-developer codebase without specificity wars.

• ▶

  🛍️ E-commerce & D2C Storefronts — product grids, filter sidebars, and checkout flows need pixel-precise, fast-loading CSS since even small layout-shift regressions measurably hurt conversion rates tracked via Core Web Vitals (CLS specifically).

• ▶

  📧 Email Template Development — a genuinely different, much harder discipline: email clients (Outlook especially) support only a small, inconsistent subset of CSS, so email developers still write table-based layouts with inline styles, closer to how the web looked in 2005.

• ▶

  🎨 Design Systems & Component Libraries — teams building shared UI libraries (used across dozens of internal apps) invest heavily in CSS custom properties and design tokens so a single brand-color change propagates everywhere without touching component code.

CSS Interview Questions That Actually Get Asked

Test Yourself

Where This Actually Leaves You

CSS has a reputation for being "not real programming," usually from people who've never had to debug a specificity conflict across a 200-component design system at 11pm before a release. The cascade, the box model, and the sizing algorithm behind Flexbox and Grid are genuinely deterministic systems — once you understand the rules, "CSS is being weird" mostly stops happening, because it was never being weird. It was following its rules exactly; you just hadn't learned them yet.

The fastest way to actually internalize the cascade and specificity is to break something on purpose: take the specificity example in this article, open your browser's DevTools, and watch the computed styles panel show you exactly which rule won and why, struck-through rules and all. That one habit will teach you more in twenty minutes than another article's worth of theory.

Frequently Asked Questions (FAQ)