Choosing What to Ship: A Progressive Enhancement Strategy

The plain-language idea

Every lesson in this track has circled the same question from a different feature's angle: is this safe to use yet? That question doesn't have one universal answer, because "safe" isn't a fixed property of a CSS feature — it's a moving target that depends on the feature's current support level and on how much fallback complexity a team is willing to carry. A useful way to make that judgment concrete is to sort any feature into one of three buckets:

• Safe baseline — broadly supported enough to ship with no fallback at all. Flexbox, basic Grid, clamp(), custom properties.
• Newly available — supported in current browsers but not everywhere a real user base still lives. Ship it gated behind @supports (covered earlier in this track), with a real fallback for the gap — not a silent "hope nobody's on an old browser."
• Experimental — worth knowing about, not yet safe as the only path to a piece of UI. Fine to use as a genuine enhancement with zero dependency on it working, unsafe as the sole mechanism something relies on.

The important part isn't memorizing which bucket a given feature is in today — that classification changes as browser support shifts, which means this is a habit to maintain, not a decision made once and forgotten. A feature that's "newly available" this year is plausibly "safe baseline" in a year and was "experimental" a year before that. Treating support level as a fixed fact, rather than a moving one, is how a codebase ends up with either overly cautious CSS that ignores years of real progress, or fragile CSS that assumes support it doesn't actually have.

See it in a real thing: shipping a feature-detected enhancement instead of guessing

/* Baseline: works everywhere, ships unconditionally */
.card {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 1rem;
}

/* Enhancement: only applied where the browser can actually honor it */
@supports (container-type: inline-size) {
  .card-container {
    container-type: inline-size;
  }

  @container (min-width: 24rem) {
    .card {
      flex-direction: row;
    }
  }
}

The baseline rule alone is a complete, working UI — every browser gets a correctly stacked card. The @supports-gated block is pure addition on top, never a rewrite of the baseline. That ordering is the actual substance of progressive enhancement: build the reliable experience first, as the thing that ships regardless of what happens next, then layer modern behavior on top of it as enhancement. The alternative — designing for the newest browser first, then trying to patch backward for everything else — tends to produce a worse fallback, because the fallback was never the design's starting point; it's an afterthought bolted onto CSS written the other way around.

What people usually miss

Watch out

• This classification is a recurring judgment call, not a solved problem with one correct answer. Two reasonable engineers can disagree about whether a given feature is "safe baseline" yet for a specific product's actual user base — that disagreement is normal, and being able to articulate the reasoning behind a choice matters more than landing on the objectively "right" bucket.
• Progressive enhancement is a design principle first, a technical pattern second. @supports is the mechanism, but the actual discipline is deciding what the baseline experience even is before reaching for the enhancement — skipping that step and only adding @supports after the fact tends to produce a fallback that was never really designed, just whatever happened to be left over.
• "Experimental" doesn't mean "ignore it." Knowing an experimental feature exists, what problem it solves, and roughly where it's headed is worth having — it's the difference between a team that adopts a feature the week it's genuinely safe and one that's still relying on an old workaround a year after a clean native solution shipped.
• A user base isn't uniform. "Is this safe to ship" depends on who actually uses the product — a product with a userbase forced onto older, managed browsers has a different safe-baseline line than a greenfield internal tool used only by people on current browsers. The three-bucket framework is the same; where a given feature lands in it isn't universal.
• Fallback complexity is a real cost, not a free insurance policy. Every @supports branch is code that has to be maintained, tested, and eventually removed once the fallback stops mattering — treating every feature as "gate it just in case" adds real ongoing cost, which is part of why "safe baseline" features are deliberately shipped with no fallback at all.

Why this matters in interviews

"How do you decide whether a new CSS feature is safe to use in production?" is a real question that's really asking whether a candidate has a repeatable framework — baseline versus newly-available-with-a-gated-fallback versus experimental — or just a vague sense of "I check caniuse." Being able to name the tradeoff explicitly, and admit it's a judgment call that shifts over time rather than a fact to look up once, is what separates someone who's actually shipped this decision from someone reciting a rule.