Dealing with different browsers in CSS3

Infrequently it implies limited browser support for developing standards, and other times it suggests having to go back and spin your code when draft standards change. When it comes down to the still-in-progress CSS 3 speculations, not only will browser support vary seriously, but most browsers have implemented what are known as vendor-specific prefixes.

The prefixes complicate things, and they need more work to drop them into your code, but they do serve a purpose. As an example, if you would like rounded corners in CSS three, you'd use border-radius to outline them. But because border-radius continues to be finalized, browsers only support their own versions of the rule. Therefore moz-border-radius will target Firefox, webkit-border-radius targets Safari and Chrome. For Opera, it's o-border-radius. None of the special prefixes will certify, which is less than ideal. There's a proposal drifting around that CSS validators should change their behaviour regarding seller prefixes by issuing an alert rather than an inaccuracy. In any case, if you would like convincing standards conformance in your CSS code, you'll have to keep away from seller prefixes. However, if you would like to play with CSS 3's new toys, you'll see there are some superb reasons explaining why vendor-specific prefixes exist, and why you ought to use them (for the moment) as well as the real suggested rules of CSS three.

To stay with the border-radius example, consider what occurs when you need to target just one corner of an object. The speculation was in turmoil in when the WebKit project made a decision to use webkit-border-top-right-radius and Mozilla went with moz-border-radius-topright. Without the prefix, you'd need to deal with 2 different CSS rules, probably for good with one of them eventually being deprecated, but still out there in older versions of that browser.
Both prefixes are technically wrong and that is a great thing. Ultimately, the final specification will be put out and only 1 rule will be standardised, with all browsers implementing that rule. At that point, you can simply go into your code and remove all your prefix rules. The seller names make them straightforward to find and zap. One thing you need to clearly not do is target only 1 browser's prefixes.

If the concept of vendor-specific prefixes scattered about your otherwise standard CSS makes you uneasy, there's another probability offloading all of the prefixing stuff to JavaScript. Seller prefixes are known to be forking CSS. While we admit with his point, the word forking is difficult if only because there is little wrong with forking code. Actually it is the norm in the open source world. And seller prefixes aren't forks, they are hacks temporary tactics to bump the bounds of the web while standards bodies catch up. Language apart, a point that is valid ignoring standards and littering your CSS with browser-specific code are both bad ideas. JavaScript library will help you avoid seller prefixes in your CSS.

However galvanizing as the script is, all it actually does is dump the prefixing to JavaScript. The approach has some drawbacks it suggests further page load times and it neglects users who've JavaScript disabled. If you'd like to begin using CSS 3's features now, you are not going to avoid seller prefixing, but at least you can select the easy way to handle it. That indicates using the prefixes in your stylesheet, putting your vendor-specific code into separate stylesheets, or employing a JavaScript solution.