198
-webkit-column-count: 3;
-webkit-column-gap: 10px;
-webkit-column-fill: auto;
-moz-column-count: 3;
-moz-column-gap: 10px;
-moz-column-fill: auto;

I am a beginner at CSS and when I was looking at some CSS code the other day, I found these lines. In the tutorials I used to learn CSS, I have never seen anything like these lines. What is the explanation for these lines? Or is there a source where I could learn to implement lines like these?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
idude
  • 4,654
  • 8
  • 35
  • 49
  • 98
    these are a setback in programming, that encourages you to repeat code and make your source awful: "We are too many browsers, four or five!, so we cannot reach an agreement, you are only a millions of programmers, so please keep repeating these lines and shut up, for the moment we do not want to deface our code with an if, not to mention a switch/case." – Hernán Eche Oct 30 '14 at 12:47
  • 3
    @HernánEche you perfectly summarized one of the horrendous faces of the stupid browser wars. Starring the question just because of your comment. Thank you! – Rodrigo Jun 06 '17 at 02:56

2 Answers2

214

These are the vendor-prefixed properties offered by the relevant rendering engines (-webkit for Chrome, Safari; -moz for Firefox, -o for Opera, -ms for Internet Explorer). Typically they're used to implement new, or proprietary CSS features, prior to final clarification/definition by the W3.

This allows properties to be set specific to each individual browser/rendering engine in order for inconsistencies between implementations to be safely accounted for. The prefixes will, over time, be removed (at least in theory) as the unprefixed, the final version, of the property is implemented in that browser.

To that end it's usually considered good practice to specify the vendor-prefixed version first and then the non-prefixed version, in order that the non-prefixed property will override the vendor-prefixed property-settings once it's implemented; for example:

.elementClass {
    -moz-border-radius: 2em;
    -ms-border-radius: 2em;
    -o-border-radius: 2em;
    -webkit-border-radius: 2em;
    border-radius: 2em;
}

Specifically, to address the CSS in your question, the lines you quote:

-webkit-column-count: 3;
-webkit-column-gap: 10px;
-webkit-column-fill: auto;
-moz-column-count: 3;
-moz-column-gap: 10px;
-moz-column-fill: auto;

Specify the column-count, column-gap and column-fill properties for Webkit browsers and Firefox.

References:

David Thomas
  • 249,100
  • 51
  • 377
  • 410
  • 1
    +1. However, additionally note that Google have stated that Chrome will no longer have prefixes for new features; if the feature is experimental, it will be hidden behind a config flag and default to disabled instead of being prefixed. Existing prefixes will remain in place in the short term and will be removed through the normal process. – Spudley Aug 06 '13 at 14:44
  • @Spudley: really? Gosh, that seems annoying: I'd rather be pleasantly surprised by a new CSS technique, using a prefix, than have to go explicitly looking to turn on new features. Incidentally, so far as you know, is it a single flag to to turn on *all* experimental features, or a checklist to turn on individual features one-by-one? – David Thomas Aug 06 '13 at 14:47
  • 2
    the point Google is trying to make is that if a feature is experimental then it shouldn't be in use in production sites; defaulting to disabled discourages that because end-users won't have it enabled but web devs can still experiement with it. And if a feature is ready for production then it shouldn't need a prefix. That's the theory anyway. Myself, I think it's a sensible way of doing things; the whole prefix idea has left us with a mess of duplicate code: W3C dragged their feet over new standards, and nobody wanted to wait for them to be finalised before using new features. – Spudley Aug 06 '13 at 14:52
  • 4
    What I'm confused about is why you use the regular `border-radius` as well as the vendor specific ones? Is it because `border-radius` isn't a W3 standard yet? Why not use `border-radius` and not the vendor specific ones? – Chris Smith Apr 20 '16 at 19:16
  • @ChrisSmith I may be late but I want to tell you why. While a css rule is still not standardized, some vendors still want to implement it. So some browsers know `border-radius` only with the `-webkit-` prefix, others need the `-moz-` prefix. And as time proceeds the new rule is now a standard and the vendors start to implement the rule without the prefix. They do this with a different rate, so Firefox may support it earlier than chrome. but when it does it will use the standard, 'cause the standard is defined after the prefixed version. – Mischa Sep 21 '17 at 09:03
  • Just an update about the Chrome engine: since version 28, Chrome uses [Blink](https://www.chromium.org/blink) and not Webkit anymore – Vítor França Nov 30 '21 at 21:35
59

What are -moz- and -webkit-?

CSS properties starting with -webkit-, -moz-, -ms- or -o- are called vendor prefixes.


Why do different browsers add different prefixes for the same effect?

A good explanation of vendor prefixes comes from Peter-Paul Koch of QuirksMode:

Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations.

Let's say a W3C working group is discussing a grid declaration (which, incidentally, wouldn't be such a bad idea). Let's furthermore say that some people create a draft specification, but others disagree with some of the details. As we know, this process may take ages.

Let's furthermore say that Microsoft as an experiment decides to implement the proposed grid. At this point in time, Microsoft cannot be certain that the specification will not change. Therefore, instead of adding the grid to its CSS, it adds -ms-grid.

The vendor prefix kind of says "this is the Microsoft interpretation of an ongoing proposal." Thus, if the final definition of the grid is different, Microsoft can add a new CSS property grid without breaking pages that depend on -ms-grid.


UPDATE AS OF THE YEAR 2016

As this post 3 years old, it's important to mention that now most vendors do understand that these prefixes are just creating unnecessary duplicate code and that the situation where you need to specify three different CSS rules to get one effect working in all browser is an unwanted one.

As mentioned in this glossary about Mozilla's view on Vendor Prefix on May 3, 2016,

Browser vendors are now trying to get rid of vendor prefix for experimental features. They noticed that Web developers were using them on production Web sites, polluting the global space and making it more difficult for underdogs to perform well.

For example, just a few years ago, to set a rounded corner on a box you had to write:

-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
border-radius: 10px 5px;

But now that browsers have come to fully support this feature, you really only need the standardized version:

border-radius: 10px 5px;

Finding the right rules for all browsers

As still there's no standard for common CSS rules that work on all browsers, you can use tools like caniuse.com to check support of a rule across all major browsers.

You can also use pleeease.iamvdo.me/play/. Pleeease is a Node.js application that easily processes your CSS. It simplifies the use of preprocessors and combines them with the best postprocessors. It helps create clean stylesheets, support older browsers and offers better maintainability.

Input:

a {
  column-count: 3;
  column-gap: 10px;
  column-fill: auto;
}

Output:

a {
  -webkit-column-count: 3;
     -moz-column-count: 3;
          column-count: 3;
  -webkit-column-gap: 10px;
     -moz-column-gap: 10px;
          column-gap: 10px;
  -webkit-column-fill: auto;
     -moz-column-fill: auto;
          column-fill: auto;
}
Community
  • 1
  • 1
Raman Sahasi
  • 30,180
  • 9
  • 58
  • 71