Cross-browser CSS, Baseline & Legacy Code

Your CSS runs in many browsers: the latest Chrome on a new laptop, Safari on an iPhone, Firefox on a college computer, and a two-year-old browser on an inexpensive Android phone that has not been updated. A professional front-end developer has to answer one question again and again: "Can I use this feature for our users?"

This lesson gives you the tools to answer it. You will learn what Baseline means, how to set a browser target with browserslist, why vendor prefixes exist and how tools add them for you, how to test on real browsers, and how to recognise the old hacks you will meet when you maintain an existing site.

Baseline: a shared answer to "can I use it?"

Baseline is a status that browser makers and the web community agreed on. It looks at the core browser set: Chrome and Edge, Firefox and Safari, on both desktop and mobile. A feature has one of three statuses:

Features that became newly available in the same year form a group such as "Baseline 2024". You will see a Baseline label at the top of many MDN pages and on caniuse.com and web.dev. Some features taught in this course, with their status in late 2026:

Statuses change as browsers ship new versions, so check the current label when you start a project rather than trusting a list in a tutorial, including this one.

Setting a target with browserslist

Teams write their browser target down in one place, and the build tools read it. The common format is browserslist, stored in package.json or a .browserslistrc file:

# .browserslistrc
baseline widely available

Browserslist understands Baseline queries such as baseline widely available, baseline newly available and a year, such as baseline 2024. Older projects often use the default query instead, which you may see written out as > 0.5%, last 2 versions, Firefox ESR, not dead. Adding with downstream to a Baseline query also includes browsers built on the same engines, such as Samsung Internet, which matters in India where many Android phones ship with their maker's own browser.

Tools such as Autoprefixer, Lightning CSS, Babel and the build steps of Vite read this target to decide what to add or transform.

Vendor prefixes

For many years, browsers shipped experimental CSS features with a vendor prefix: -webkit- (Safari and Chrome), -moz- (Firefox), -ms- (Internet Explorer and old Edge) and -o- (old Opera). Developers wrote every version by hand:

/* What you find in a stylesheet from around 2013 */
.box {
  -webkit-border-radius: 8px;
  -moz-border-radius: 8px;
  border-radius: 8px;
  -webkit-transition: opacity 0.3s;
  -o-transition: opacity 0.3s;
  transition: opacity 0.3s;
}

Prefixed features caused a mess, because sites kept the prefixed lines for years. Browsers now ship experimental features behind settings flags instead, and new features arrive unprefixed. For the few prefixes still useful today, do not write them by hand. Autoprefixer (a PostCSS plugin) or Lightning CSS reads your browserslist target and adds exactly the prefixes those browsers need, and removes ones they do not.

A handful of prefixed properties are still part of everyday CSS, because the prefixed form is the one that works everywhere: -webkit-line-clamp for multi-line truncation (see Text Effects), -webkit-text-stroke, and -webkit-user-select for Safari, which does not support the unprefixed user-select. Treat any other prefix in old code as a candidate for deletion, after checking.

Progressive enhancement in practice

The safest way to use a newer feature is to write a working version first and improve it where the feature exists (see @supports Feature Queries). Here the cards use a plain grid everywhere, and a style that needs a newer feature only where it is supported:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Progressive enhancement</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 16px; }
    .plans { display: grid; grid-template-columns: repeat(auto-fit, minmax(12rem, 1fr)); gap: 12px; }
    .plan { padding: 16px; border: 2px solid #cbd5e1; border-radius: 12px; }
    .plan h2 { margin-top: 0; }

    /* Fallback for everyone: a fixed highlight colour */
    .plan--popular { border-color: #7c3aed; background: #f5f3ff; }

    /* Enhancement: derive the tint from the border colour when relative colours exist */
    @supports (color: oklch(from red l c h)) {
      .plan { --accent: #0e7490; border-color: var(--accent); background: oklch(from var(--accent) 0.97 0.02 h); }
      .plan--popular { --accent: #7c3aed; }
    }

    .status::after { content: "Your browser uses the fallback colours."; }
    @supports (color: oklch(from red l c h)) {
      .status::after { content: "Your browser supports relative colours."; }
    }
  </style>
</head>
<body>
  <p class="status"></p>
  <div class="plans">
    <section class="plan"><h2>Basic</h2><p>50 GB data, ₹299 per month</p></section>
    <section class="plan plan--popular"><h2>Popular</h2><p>2 GB per day, ₹719 for 84 days</p></section>
    <section class="plan"><h2>Family</h2><p>Four SIMs, ₹999 per month</p></section>
  </div>
</body>
</html>

Both versions are correct and usable. Visitors with newer browsers simply get a slightly richer design.

Testing on real browsers

• Install Chrome, Firefox and Edge on your computer and check every page in each.
• Safari cannot be installed on Windows. On iPhones and iPads, browsers have traditionally all used Safari's WebKit engine, so testing in Safari on an iPhone covers most iOS users. Borrow a device or use a paid cloud testing service.
• Test on a real mid-range Android phone. It shows performance and touch problems that a desktop browser in device mode hides.
• Read your analytics. The browsers and versions your own visitors use matter more than global statistics.

Legacy code you will meet

Many company sites still contain CSS written for Internet Explorer. Microsoft retired the Internet Explorer 11 desktop app in June 2022, so most of these hacks can be removed, but you need to recognise them first:

Common mistakes

• Using a feature because it works on your laptop. Your browser is probably the newest version. Check the Baseline status and your target.
• Writing prefixes by hand. You will forget some and keep useless ones. Let Autoprefixer or Lightning CSS do it from your browserslist target.
• Wrapping Widely available features in @supports. It adds noise. Save feature queries for Limited and recently Newly available features.
• No fallback for an enhancement. If the page is broken without the new feature, it is not an enhancement.
• Never testing Safari. Many layout bugs appear only there.

Key points

• Baseline statuses: Limited availability, Newly available (all core browsers) and Widely available (30 months later).
• Write your target down with browserslist, for example baseline widely available; build tools read it.
• Vendor prefixes are mostly history; Autoprefixer or Lightning CSS adds the few still needed.
• Build a working base first, then enhance with @supports for newer features.
• Test in Chrome, Firefox, Edge, Safari and on a real mid-range phone; trust your own analytics.
• Recognise IE hacks, old Flexbox syntax and clearfix, and remove them carefully, one group at a time.

.header {
  border-radius: 6px;
  background: linear-gradient(#ff6600, #cc3300);
}

.row {
  display: flex;
}

.summary {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow: hidden;
}