Major browser vendors implement CSS features at their own speed, and they have been using vendor prefixes to add experimental or nonstandard CSS properties. Following are a list of major prefixes:
-webkit-
: Chrome, Safari, WebKit based browsers-ms-
: Internet Explorer, Microsoft Edge-o-
: pre-WebKit versions of Opera-moz-
: Firefox.example {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
border-radius: 10px;
}
In theory, these prefixed properties should not be used in production. But in reality it doesn’t work as expected, here’s why:
Vendor prefixing is one way to extend browser support to the point those prefixed properties implemented but not before any of that.
Modern CSS has moved away from vendor prefixing in favor of feature queries where you can style conditionally and provide fallback styles for something unsupported.
If you’re still writing vendor prefixes then you should consider setup automatic prefixing because manual vendor prefixing doesn’t scale well. It’s painful, tedious and error-prone for human eyes to keep track of which properties need to be prefixed for which browser versions.
The CSS @supports
at-rule lets you specify declarations that depend on a browser’s support for one or more specific CSS features, known as feature queries.
Feature queries associate a block of statements with a supports condition. The supports condition consists of one or more name-value pairs combined by conjunctions (and
), disjunctions (or
), and/or negations (not
). Precedence of operators can be defined with parentheses.
@supports (display: grid) {
/* */
}
@supports not (display: grid) {
/* */
}
@supports (display: grid) and (not (display: inline-grid)) {
/* */
}
@supports (-moz-transform-style: preserve) {
/* */
}
This is the direction major browser vendors are pushing forward, it works great when providing a mean to write fallback styles when something not supported, but keep in mind following limitations:
@support
at-rule will only work on browsers that support @supports
. Don’t forget to write fallback code outside of feature queries.Consider vendor prefixing is something can’t be removed completely even when using feature queries because of fears of missing out unchecked features. On the rise of CSS (pre|post)-processors, vendor prefixing can be done automatically. For this solution to work, you’ll need following tools:
.browserslistrc
as follow:# supported browsers
defaults
not IE 11
maintained node versions
gulp.task('autoprefixer', () => {
const autoprefixer = require('autoprefixer')
const sourcemaps = require('gulp-sourcemaps')
const postcss = require('gulp-postcss')
return gulp
.src('./src/*.css')
.pipe(sourcemaps.init())
.pipe(postcss([autoprefixer()]))
.pipe(sourcemaps.write('.'))
.pipe(gulp.dest('./dest'))
})
Beside auto prefixing, PostCSS can help with polyfills but very limited when new CSS features require JavaScript implementation in client side.