Should I Remove Vendor Prefixes

Should I remove vendor prefixes?

No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.

How can I find out which prefixes are no longer required?

Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.

How can I clarify that the prefixes are no longer required?

There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.

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.

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

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

Are vendor prefixes still needed in css Angular 6?

Vendor prefixes support depend on web browser's render engine. Angular is just a JS framework. CSS is outside of the scope

From my experience, most of Web browsers support popular syntax as transform, box-shadow without prefix already. If you want to sure, let check at https://caniuse.com/

If you don't want to care about those prefixes, let's use Autoprefixer cssnext. These are polyfill tools that support newest specification of CSS. When the browser is fully supported new specs, CSSNext will automatically remove them for you

How do I know when is the right moment to stop using a specific css vendor-prefix?

It's the developer's choice, ultimately. Keeping in mind the target audience, if you have a lot of Opera Mobile users than of course you'd want to keep around -o- prefixes.

If you use something like Autoprefixer, you generally don't have to worry as it will do that part for you. I believe the general rule of thumb for those that "support modern browsers" is going 2 versions back of each browser's latest. That knocks a huge majority of -moz and -webkit prefixes from back in the day. Anything more than that is usually for compatibility's sake, and that kind of stuff should have audience data to back it's merit up.

How do I find out when I can safely drop vendor prefixes for a CSS3 property?

When can I use... contains browser support tables with convenient indicators of which versions of which browsers require the vendor-prefixed versions of various CSS3 features, as well as features in other standards like HTML5, its new JavaScript APIs, SVG, etc. That should be the first place you stop at.

The site is updated regularly (for now, at least) as new versions of browsers are released and the drafts of the relevant CSS3 modules are updated.



Related Topics



Leave a reply



Submit