Why CSS properties do have different names for Chrome, FF, Opera?

I want a shadow below div called "shadow":

#shadow { box-shadow: 1px 1px 1px #000 };

Done?

Not at all. It works just in one browser. Guess which one.

For FF/Chrome I have to add not too intuitive:

-moz-box-shadow: 1px 1px 1px #000;
-webkit-box-shadow: 1px 1px 1px #000;

And now everything is ok. This scheme applies to MANY CSS properties. Why?

Luckily there's no -webkit-border, moz-font or -ie-backgroundcolor.

PS. Yes, not a single word about IE. Calling THIS a browser is like comparing wheelchair to 开发者_如何学GoModena cars.

PS 2. Why there is a logo next to Google Chrome tag below my post? Or why there are no logos for Opera & FF?

---

This happens because browsers do not want conflicts with each other. In addition to that, there isn't really a "spec" for box-shadow at the moment, so several browsers have their own implementation of it.

This approach allows any vendor-specific extension to coexist with any future (or current) CSS properties without causing conflicts because, according to the W3C specifications, a CSS property name will never begin with a dash or an underscore:

Source: http://reference.sitepoint.com/css/vendorspecific

---

It's a way for browsers to release features before the CSS Spec is fully approved.

For instance, look at the CSS3 gradients. -moz- vs -webkit- are completely different.

background-image: -webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0.15, rgb(145,4,88)),
    color-stop(0.58, rgb(174,30,115)),
    color-stop(0.79, rgb(209,57,150))
);
background-image: -moz-linear-gradient(
    center bottom,
    rgb(145,4,88) 15%,
    rgb(174,30,115) 58%,
    rgb(209,57,150) 79%
);

This may be of interest: http://www.alistapart.com/articles/prefix-or-posthack/

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents. And in this case, you’re being vaccinated against a bad case of multi-year parser hacking and browser sniffing. We suffered through that long plague once already. Prefixes will, if used properly, ward off another outbreak for a long time to come.

NOTE: It's good practice to include the version without the prefixes, as to continue the sites function when the property is fully adopted.

---

Properties which are implemented based on unfinishes specs are given vendor prefix. Same thing if given vendor thinks their implementation is not finished, even though the spec is.

---

The abilities of the browsers are ahead of the standards they're supposed to follow. They give you access to the abilities in the interim until the standard is published, then they follow the published standard and provide back-compatibility with the funky-looking "webkit..." formats.

---

As others have already answered, it is because they are implementing a feature for which the specifications are not yet complete, or a feature for which their implementation is not yet complete.

This is intentional behaviour; the CSS spec specifies that this is how they are supposed to do things in this case. The reasons for this rule are as follows:

• To ensure that where different browsers implement the feature differently (due to changes or inconsistencies in the spec), those differences can all be incorporated into the same stylesheet.
  For example: The early versions of -moz-border-radius worked quite differently to -webkit-border-radius; there were significant syntax differences between them, so if they'd both been just border-radius, you wouldn't have been able to support them both.
• To simplify the transition when the spec is complete.
  If you do use a feature with a vendor prefix, always put the non-prefixed version of the feature last, after the others. This way, a browser that has recently been upgraded to support it properly will pick up the correct version rather than it being overridden by the out-of-date prefixed version.
• To ensure that web developers know when they are using a feature which is not necessarily ready for prime time use.
  This is important: you should be clear that using a feature with vendor prefixes means that you're using a feature which the browser makers and specification writers do not believe is ready yet. You need to know this. Don't let it stop you using something if it's useful, but be aware that things may change with the next version.