What CSS3 Features Still Need Vendor Prefixes

What CSS3 features still need vendor prefixes?

There is a great site which allows you to check out support of any css property by most modern browsers. It also shows info about vendor prefixes (if they are needed).
This site is named "Can I use" - http://caniuse.com

Do I still need to use prefixes with CSS3 features?

Short answer : Use Them because HTML5 and CSS3 are still under development and are not fully supported by any browser.

Other stuff you may like to read : As a developer, we need to see from user point of view, cross-browser compatibility is essential to maintain your website layout almost same in all browsers, more over it also gives professional edge to your work if your layout is consistent in all browser, using proprietary properties won't increase your page load time, and most of the users don't update their browsers to latest version, and so they get a shabby rendered page, so to be safe use them unless and until CSS3 and HTML5 are completely supported by all browsers.

Are vendor prefixes still relevant for CSS3 features like box shadow and border radius?

Yes if your want your webApp to run on

  Firefox 3.6-, Safari 4-,Android 2.3-,  or  iOS 3.2-

but today you don't need it anymore

and check caniuse

Where should I use CSS vendor prefixes

You can search through Can I use to see which browser/version combinations need a vendor prefix.

But if you use a build tool, such as Grunt or Gulp, for your front end development work you can have these vendor prefixes automatically added to the resulting CSS. Take a look at Autoprefixer (Grunt plugin Gulp plugin)

When do I need use vendor prefixes?

CSS property with prefix means that this is early browser implementation. After several browsers implement any css feature with prefix(rely on not recommended W3C spec) W3C fix any differences or mistakes in specification which where finding in implementation process and CSS feature become a W3C recommendation.

For example, prefixed linear-gradient syntax with prefix:

background: -o-linear-gradient(top, #3DC8FF 0%, #008CC3 100%);
background: -moz-linear-gradient(top, #3DC8FF 0%, #008CC3 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #3DC8FF), color-stop(100%, #008CC3));
background: -webkit-linear-gradient(top, #3DC8FF 0%, #008CC3 100%);

And with out:

background: linear-gradient(to bottom, #3DC8FF 0%, #008CC3 100%);

As you can see first argument changed: if you want gradient from top to bottom you need top value for prefixed css values and to bottom for W3C linear gradient recommendation.

So you need prefixes for older browser versions where there is unprefixed values or for that css properties that don't has W3C recommended specification and implemented rely on W3C draft.

As front-end developer you must support many browsers modern and older your css contains properties with prefixed for Opera(-o), Firefox(-moz) and Chrome, Safari(-webkit)

Also there are mobile browsers. Now you need use -webkit prefix for mobile, because Mobile Safari, for example, use only prefixed css properties. Opera Classic(Opera Mobile before 14 version) mobile browser is not updated and will always has -o prefixed css properties.

Why are there vendor prefixes in CSS3?

This has been asked before, but the short answer is that CSS3 is not a finished product. CSS 2.1 wasn't published until 2011, and only a handful of CSS3 modules have even reached the level of a formal recommendation, so it's premature to talk about a CSS3 specification that is universally implemented. Thankfully, modern browser makers are helping to push things forward and are helping to craft the standard which follows the lead of real-world practice. As they move closer to general standards, the prefixes are dropped.

What are CSS vendor prefixes?

When new features are introduced to the CSS specification, or simply as a test balloon by one browser vendor, the feature is often hidden behind a vendor prefix. E.g. border-radius started as -webkit-border-radius in Chrome/Webkit browsers, and -moz-border-radius in Firefox. If you want to use such a new feature which is not yet standardised across the board but must be prefixed like this, you need to add all the various -webkit-* and -moz-* forms to your CSS file to support it in all browsers. An autoprefixer makes this easier by allowing you to just use the standard name border-radius, and it'll add all the vendor-specific prefixed versions as alternatives automatically.

Why people use CSS vendor-prefix although the specs clearly says don't

CSS 3 spec is newer than CSS 2.1, so let's skip what 2.1 says.

The spec says implementations —that refers to browsers, not stylesheets— should not require vendor prefixes. That's different from whether or not they do. Some browsers do require prefixes for some styles.

The thing is the W3C's CSS Working Group, who write the CSS spec, do not actually have power over browser developers — the browser developers have to choose to follow the spec (in part or in full). What's exciting is that more and more the main browsers are falling into line with the spec, and vendor prefixes are needed less and less.

The vendor-prefixed properties you need to provide depends on what browsers you support. Within a given browser, the requirements often vary by version. Newer versions of browsers for the most part require fewer vendor CSS properties than older versions of the same browser.

Snippets found online don't always age well. For example

-webkit-transition: all 4s 
-moz-transition: all 4s ease;
-ms-transition: all 4s ease;
-o-transition: all 4s ease;
transition: all 4s ease; 

would typically be considered overkill these days. Always check the date on bits of code found online. On SO, checking rep can help you distinguish between workable answers and best answers.

There's a whole separate question of how dropping support for old browsers related to web accessibility. Won't get into that here, but there are some people who say that choosing to only support more recent and/or popular browsers is inherently problematic.

Autoprefixer can be configured to target exactly the browsers you want to support. It adds only the vendor-specific CSS needed to meet the need you specify. By default, Autoprefixer uses the Browserlist default. With that setting, no vendor-specific code is needed to support border-radius: 10px 5px and transition: all 4s ease. You can see that by running your two rules through https://autoprefixer.github.io/, "filtered" by > 0.5%, last 2 versions, Firefox ESR, not dead. You can see which browsers that covers at https://browserl.ist/?q=%3E+0.5%25%2C+last+2+versions%2C+Firefox+ESR%2C+not+dead

In practice, a lot of people simply do not write vendor-specific CSS, relying on Autoprefixer built into their build tooling. For example, you might have a Gulp or webpack setup that automatically runs your stylesheets through Autoprefixer. If that's new to you, a good starting point might be postcss-cli, the command line tool for PostCSS.

npm install -g postcss-cli autoprefixer
postcss my-styles.css --use autoprefixer --dir output-directory

When do browsers remove vendor prefixes and experimental flags?

It's mostly the other way around. A W3C spec can only become a recommendation when it has two complete, independent implementations. Officially, at least. Sometimes the rules are bent a bit.

It matters less than you think. Once there are interoperable implementations for most of the browsers in current use, any variation of the specification from the implementations is normally considered as a bug in the specification, not in the implementations. So at that point the spec is effectively stable for that feature, regardless of its status as Draft, CR, PR, or Recommendation.

Browser makers talk between themselves and the spec writers to decide when they're going to implement something, and when they agree that their implementations are complete. The "Recommendation" status is just the final step, to tell web authors it's all good for them to use it.

Of course, only the most defensive of web authors will wait that long.

---

Related Topics