Is Browser Prefix Still Required for Linear-Gradient

Is browser prefix still required for linear-gradient?

According to Can I use, as of June 2017, 93.75% of Internet usage is on a browser that supports unprefixed linear gradients (97.2% in the US). For most people, this means you don't need to prefix your gradients anymore.

Sample Image

Below is the first compatible version and release date for the most common desktop browsers:

  • IE v10, released September 2012
  • Firefox v16, released August 2012
  • Chrome v26, released February 2013
  • Safari v6.1, released October 2013
  • Opera 12.1, released November 2012

Information on compatibility history of other browsers (including mobile browsers) is available at Can I use.

Linear-gradient works only with -moz vendor prefix

Remove the center. Then it should work.

Also make sure you have it for all browsers:

background-image: -webkit-linear-gradient(top, rgba(255, 255, 255, 0) 0%, rgba(255, 255, 255, 0) 75%, rgba(255, 255, 255, 0.95) 100%);
background-image: -moz-linear-gradient(top, rgba(255, 255, 255, 0) 0%, rgba(255, 255, 255, 0) 75%, rgba(255, 255, 255, 0.95) 100%);
background-image: -o-linear-gradient(top, rgba(255, 255, 255, 0) 0%, rgba(255, 255, 255, 0) 75%, rgba(255, 255, 255, 0.95) 100%);
background-image: -ms-linear-gradient(top, rgba(255, 255, 255, 0) 0%, rgba(255, 255, 255, 0) 75%, rgba(255, 255, 255, 0.95) 100%);
background-image: linear-gradient(top, rgba(255, 255, 255, 0) 0%, rgba(255, 255, 255, 0) 75%, rgba(255, 255, 255, 0.95) 100%);

Example Fiddle

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.

Do vendor-prefixed CSS properties get updated when non-prefixed parent gets updated?

Most vendor-prefixed features do seem to be updated to match the standardized implementations, because generally the prefixes are reimplemented as aliases of their unprefixed counterparts by the time the latter is shipped in production. But I don't think this can be generalized — well, I guess I just did that, so I'll say instead that this cannot be relied on. Gradients are a well-known example of prefixed features not being updated to match the latest standard.

Actually, that statement isn't even 100% correct — because Mozilla did actually update their -moz-linear-gradient() function to accept the same to <side-or-corner> syntax along with the old <side-or-corner> syntax (both of which have completely opposite meanings), whereas WebKit-based browsers as well as IE11 still do not accept the new to <side-or-corner> syntax for their -webkit-linear-gradient() and -ms-linear-gradient() functions (and -ms-linear-gradient() is completely gone from Microsoft Edge).

But every browser correctly implements the standardized grammar for linear gradients: the to keyword is required when specifying a <side-or-corner> keyword; using such a keyword without the to in a linear-gradient() expression is invalid in every browser.

In other words:

  1. -moz-linear-gradient(top, #FF0000, #FFFF00) works in Firefox;
  2. and -moz-linear-gradient(to bottom, #FF0000, #FFFF00) also works in Firefox;
  3. -webkit-linear-gradient(top, #FF0000, #FFFF00) works in Safari and Chrome;
  4. but -webkit-linear-gradient(to bottom, #FF0000, #FFFF00) does not work in Safari or Chrome;
  5. -ms-linear-gradient(top, #FF0000, #FFFF00) works in IE10 and IE11;
  6. but -ms-linear-gradient(to bottom, #FF0000, #FFFF00) does not work in IE10 and IE11;
  7. linear-gradient(top, #FF0000, #FFFF00) does not work in any browser;
  8. and linear-gradient(to bottom, #FF0000, #FFFF00) works in all browsers.

So, given the mess that is prefixed gradients, I would highly recommend not relying on prefixed implementations to work like the standard all the time. Even if one browser reimplements a prefix as an alias of the unprefixed version of the feature once the implementation becomes stable, not all browsers may do so.

Having said that, it's very likely that all browsers alias their prefixed -*-animation and -*-transition properties to their unprefixed counterparts, and so it's equally likely that the prefixed properties will be automatically updated to support new timing functions as a side effect of their unprefixed counterparts being updated to do so.

How necessary are CSS3 vendor prefixes right now?

You can build a filtered list on this web page and show all of the required prefixes.

http://caniuse.com/#comparison

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