095 Whatever Happened to CSS Browser Prefixes?

If you have been building websites for a long time, you may remember CSS that looked something like this:

-webkit-border-radius: 10px;
-moz-border-radius: 10px;
border-radius: 10px;

Or sometimes it was even worse:

-webkit-transform: rotate(5deg);
-moz-transform: rotate(5deg);
-ms-transform: rotate(5deg);
-o-transform: rotate(5deg);
transform: rotate(5deg);

One visual effect. Five declarations.

Those were the days of CSS vendor prefixes.

I remember them well, and I was glad when we mostly stopped needing them. Each browser or browser engine seemed to need its own version of an emerging CSS feature.

Today, we can write much cleaner CSS. But every once in a while, -webkit- still appears in a modern stylesheet.

So what happened to all those prefixes?

And if they are mostly an older practice, why haven't they completely disappeared?

What Was a Vendor Prefix?

A vendor prefix was a short identifier added to the beginning of a CSS property to indicate a browser engine's implementation of that feature.

Some of the prefixes web developers regularly encountered included:

-webkit-
-moz-
-ms-
-o-

They were associated with different browser engines and browser families.

-webkit- came from WebKit and became strongly associated with Safari and the mobile web.

-moz- was associated with Mozilla and Firefox.

-ms- was associated with Microsoft.

-o- was associated with Opera's older browser engine.

The result was that a developer sometimes needed several versions of what was conceptually the same CSS rule.

Why Did Browser Prefixes Exist?

It is easy to look back at vendor prefixes as nothing more than an annoyance, but they originally served a useful purpose.

Web standards evolve.

A new CSS feature might be proposed and discussed long before its final behavior was completely settled. Browser developers wanted to experiment with those new capabilities before the specification was finished.

A prefix provided a way to say, essentially:

"This is our experimental implementation of this feature."

That allowed browser developers and web developers to test emerging ideas without pretending that the implementation was already a permanent web standard.

Experimental CSS Escaped into the Real World

The difficulty was that web developers started using these experimental properties on real websites.

If a new effect looked good in one browser, designers naturally wanted to use it.

Then another browser implemented the feature slightly differently or under another prefix.

Before long, production stylesheets contained groups of declarations such as:

-webkit-something: value;
-moz-something: value;
-ms-something: value;
-o-something: value;
something: value;

For developers, this became tedious.

We weren't trying to create four different designs. We simply wanted rounded corners, a gradient, a transformation, an animation, or some other increasingly common effect to work in multiple browsers.

Remember Rounded Corners?

Today we casually write:

border-radius: 10px;

And move on.

That simple line represents an enormous improvement over earlier web development.

There was a period when developers used browser-specific CSS for rounded corners. Before CSS could reliably handle them, we sometimes used background images and other techniques just to make a box have rounded corners.

Today the browser understands the standardized property:

border-radius: 10px;

No special browser version is normally necessary.

The Same Thing Happened with Other CSS Features

Many features that once appeared with vendor prefixes eventually became ordinary standardized CSS.

Examples include features involving:

• Border radius
• Transforms
• Transitions
• Animations
• Gradients
• Flexbox
• Various visual effects

Modern browsers now agree well enough on the standardized forms of many of these properties that routinely including every historical prefix would mostly add unnecessary CSS.

So Can We Delete Every Vendor Prefix?

No.

This is where the story gets interesting.

The era of automatically writing several prefixed copies of ordinary CSS properties has largely passed.

But -webkit- has not completely disappeared.

There are still specialized properties and browser behaviors where a WebKit-prefixed declaration can be useful or necessary.

For example, developers may still encounter:

-webkit-text-size-adjust: 100%;

or:

-webkit-appearance: none;

and some visual text techniques continue to use properties such as:

-webkit-background-clip: text;

Therefore, a modern CSS cleanup should not blindly search for -webkit- and delete every occurrence.

The better question is:

"Does this particular prefixed property still serve a current compatibility purpose?"

A Better Modern Rule

Years ago, a developer might have thought:

"I had better add all the browser prefixes just in case."

Today, a better rule is:

Use the standardized CSS property by default. Add a vendor-prefixed version only when there is a specific compatibility reason for doing so.

That produces cleaner CSS and avoids carrying decades of obsolete compatibility code into new websites.

What About -moz-, -ms-, and -o-?

These prefixes can still appear when examining old stylesheets, tutorials, themes, and archived websites.

But they are much less likely to belong in newly written CSS.

If we encounter them in an older site, we should investigate why they are there rather than assuming they are still necessary.

Some may simply be historical leftovers.

That does not mean old CSS was poorly written.

It may have been exactly what was necessary when the site was created.

Old CSS Is a Little Bit of Web Archaeology

This is one of the things I enjoy about maintaining websites that have existed for many years.

A stylesheet can become a record of how web development changed.

We might find:

• Layouts originally built with tables
• Floats used for columns
• Fixed pixel dimensions
• Vendor-prefixed CSS
• Early responsive media queries
• Flexbox
• Grid
• Relative typography
• Modern functions such as clamp()

These are not necessarily mistakes.

They are layers of web history.

A website that has been maintained for decades can contain several generations of web development in a single stylesheet.

Why Standards Matter

There is a larger lesson behind the disappearance of most vendor prefixes.

The web works best when a website does not have to be written separately for every browser.

A developer should ideally be able to write:

display: flex;

and have browsers agree on what that means.

The same is true for:

border-radius: 10px;

or:

transform: rotate(5deg);

That consistency is made possible by open web standards, standards organizations, browser developers, testing, discussion, and a great deal of cooperation.

From a web developer's perspective, I am very happy that the web has moved toward standardized CSS instead of every company requiring its own permanent version of the same property.

Who Is the Neutral Party?

It can sometimes feel as though there must be one neutral organization somewhere deciding exactly how the web works.

The reality is more collaborative.

Organizations such as the World Wide Web Consortium (W3C) and standards groups including the CSS Working Group help develop specifications. Browser makers, developers, accessibility experts, researchers, and other participants contribute to that process.

Another important organization is WHATWG, which maintains major living web standards, particularly HTML and related web-platform technologies.

It is not simply one company telling every browser what to do.

That collaborative standards process is one of the reasons the modern web can work across products made by competing companies.

Competition Without Breaking the Web

Competition Without Breaking the Web

At some point during those years of writing browser-specific CSS, I remember telling my son Luke something along the lines of:

"We're done with all this extra coding. We're writing to the standards. If the browsers want to display our sites properly, they need to get with the standards."

Maybe a simpler way to say it today is:

"We wrote it to the standard. Now it's the browser's turn."

There was a little stubbornness in that statement, but there was also an important principle behind it. Web developers could not reasonably be expected to maintain separate versions of ordinary CSS forever. The long-term solution had to be browsers increasingly agreeing on shared web standards.

That doesn't mean we stopped testing different browsers or fixing legitimate compatibility problems. We still do that today. But there is an important difference between addressing an occasional browser issue and routinely writing several proprietary versions of the same CSS declaration.

Browser competition can be very good.

Companies compete on speed, privacy, security, developer tools, interfaces, energy efficiency, and new capabilities.

But competition becomes much less helpful if every browser requires developers to build a different website.

Standards give browser makers room to innovate while providing developers with a common foundation.

That distinction is important.

Browsers can compete without requiring the web itself to fragment.

Testing Still Matters

Standardization does not mean every browser will always render every page identically.

Browser engines remain complex pieces of software. New features arrive at different times, operating systems render fonts differently, form controls can vary, and occasional browser-specific issues still appear.

We should therefore continue testing important websites in multiple browsers and on different devices.

The difference is that cross-browser testing today is usually about finding exceptions.

Years ago, browser differences often shaped the way we wrote the entire stylesheet.

Don't Copy Old CSS Without Asking Why

This is particularly important when searching the web for CSS examples.

A perfectly good tutorial written many years ago may contain:

-webkit-
-moz-
-ms-
-o-

because those declarations were necessary when the article was written.

If we copy that code today without understanding it, we may be carrying obsolete compatibility rules into a modern website.

The age of a CSS example matters.

Before copying a vendor prefix, ask:

"Do current browsers still require this?"

Cleaning Up an Older Stylesheet

When modernizing a long-running website, we do not need to remove every old declaration simply because it looks old.

A safer approach is:

1. Identify the prefixed property.
2. Determine what feature it supports.
3. Check whether modern browsers support the standard property.
4. Determine whether the prefixed version still provides useful compatibility.
5. Remove it only when we understand why it is no longer needed.
6. Test the site afterward.

This is slower than deleting everything with a global search and replace.

It is also much safer.

Modern CSS Is Remarkably Good

Looking back at vendor prefixes also reminds us how far CSS has come.

Today we have powerful standardized tools such as:

display: flex;

display: grid;

font-size: clamp(1.2rem, 2vw, 2rem);

max-width: min(100%, 70rem);

We can create responsive layouts, fluid typography, flexible images, animations, columns, cards, navigation systems, and complex interfaces with far less browser-specific code than we once needed.

Sometimes we become so accustomed to modern CSS that we forget how much easier this part of web development has become.

From Browser-Specific CSS to Web CSS

Perhaps that is the real story of vendor prefixes.

The prefixes themselves were never the goal. They were part of the process of experimenting with new capabilities while standards were still developing.

Ideally, an experimental idea matures, browsers agree on how it should work, the standardized property becomes widely supported, and developers can eventually remove the temporary browser-specific versions.

We move from:

-webkit-something
-moz-something
-ms-something
-o-something

to simply:

something

That final line may not look very exciting.

But for anyone who remembers maintaining all those browser-specific versions, it is beautiful.

Final Thought

The disappearance of most CSS vendor prefixes represents something bigger than cleaner stylesheets.

It represents the maturation of the web platform.

Different companies still build different browsers. They compete, experiment, innovate, and occasionally disagree.

But underneath that competition is an increasingly capable set of shared web standards.

As someone who remembers writing the same CSS property several times with different prefixes, I am glad we have reached the point where most of the time we can simply write the standard property.

And when I occasionally encounter:

-webkit-

I no longer need to think:

"Oh no, are we going back?"

No.

It is mostly just a little piece of web history that hasn't quite finished its job.