How to Automatically Add Browser Prefix to CSS3 Properties

How to automatically add browser prefix to CSS3 properties?

There are several options that come to mind, depending on your use-case:

• SASS with Bourbon
• SASS with Compass

• Less with LESS elements

• Emmet
  CSS3 Abbreviations (In your text editor)

• PrefixFree (client side js)

My personal preference is to use Compass, but the Emmet abbreviations work well if you do not want the overhead of using a CSS pre-processor.

How to add missing browser-specific css declaration properties and prefixes to epub

We will assume that all the relevant CSS is in .css files. You can open the epub by unzipping it, and this will expose the CSS files, wherever they might be. You can then simply run these through your favorite prefixing tool, then zip the book back up.

The problem is that AFAIK prefixing tools typically expect the transform property and add the -webkit-transform counterpart. I am not sure these tools will work if only -webkit-transform is there and you want transform to be added. You'll have to check each tool to see if it provides this behavior. In the worst case, you could write your own plugin for a CSS transformation framework like rework to do what you need.

Does .css() automatically add vendor prefixes?

As @zeroflagL wrote it appears that since jQuery 1.8.0 .css() does add browser specific prefixes (see this).

In earlier versions this is not done automatically by jQuery's .css(). You will have to do it by yourself or you can use jQuery's .cssHooks() to add vendor prefixes.

Code example from here:

(function($) {
  if ( !$.cssHooks ) {
    throw("jQuery 1.4.3+ is needed for this plugin to work");
    return;
  }

  function styleSupport( prop ) {
    var vendorProp, supportedProp,
        capProp = prop.charAt(0).toUpperCase() + prop.slice(1),
        prefixes = [ "Moz", "Webkit", "O", "ms" ],
        div = document.createElement( "div" );

    if ( prop in div.style ) {
      supportedProp = prop;
    } else {
      for ( var i = 0; i < prefixes.length; i++ ) {
        vendorProp = prefixes[i] + capProp;
        if ( vendorProp in div.style ) {
          supportedProp = vendorProp;
          break;
        }
      }
    }

    div = null;
    $.support[ prop ] = supportedProp
    return supportedProp;
  }

  // check for style support of your property 
  // TODO by user: swap out myCssPropName for css property
  var myCssPropName = styleSupport("myCssPropName");

  // set cssHooks only for browsers that
  // support a vendor-prefixed border radius
  if (myCssPropName && myCssPropName !== 'myCssPropName') {
    $.cssHooks["myCssPropName"] = {
      get: function(elem, computed, extra) {
        // handle getting the CSS property
        return $.css(elem, myCssPropName);
      },
      set: function(elem, value) {
        // handle setting the CSS value
        elem.style[myCssPropName] = value;
      }
    };
  }
})(jQuery);

How to set vendor prefixed CSS values (NOT property names) | client-side

maybe Modernizr can fix this, like

// returns: -webkit-linear-gradient(left, red, red)
Modernizr.prefixedCSSValue('background', 'linear-gradient(left, red, red)')

---

How it works:

// prefixedCSSValue is a way test for prefixed css properties (e.g. display: -webkit-flex)
// @credits modernizr v3.6.0 | Build https://modernizr.com/download?-prefixedcssvalue-dontmin
Modernizr.prototype.prefixedCSSValue = function(prop, value) {
    var result = false;
    var elem = createElement('div'); // basically: document.createElement.apply(document, ['div'])
    var style = elem.style;

    if (prop in style) {
        var i = domPrefixes.length; // domPrefixes === [ "moz", "o", "ms", "webkit" ] or []

        style[prop] = value;
        result = style[prop];

        while (i-- && !result) {
            style[prop] = '-' + domPrefixes[i] + '-' + value;
            result = style[prop];
        }
    }

    if (result === '') {
        result = false;
    }

    return result;
};

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)

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.

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

---

Related Topics