views:

107

answers:

3

In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?

A: 

You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.

I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.

Aren
border-radius also works in Opera, and will work in IE9. I tested border-radius...without the prefix in webkit browsers and it works. I'm asking if it would be okay drop the -webkit- prefix, and just use -moz- for firefox.
omnix
@Kawohi: The CSS3 standard is not complete yet, and probably wont be widely implemented until 2012. IE9 is still in beta, and has begun adopting CSS3, this doesn't mean it's time to standardize. You could still run into issues with your CSS parsing depending on the version of a the browser. Konquerer for linux, Phone Browsers (iPhone/Android/etc...), IE6-8, and older versions of opera do not support `border-radius` and while 9 times out of 10 you're probably ok, I'm telling you, it could cause a validation error, and you may get strange results.
Aren
A: 

border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later. So if you wish to have support for safari 3+ you have to use -webkit-border-radius

Sotiris
A: 

You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.

You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:

An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.

The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:

  • -ms-, mso- Microsoft
  • -moz- Mozilla
  • -o-, -xv- Opera Software
  • -webkit- Apple
  • -khtml- KDE

There are also some you might have never even heard of:

  • -atsc- Advanced Television Standards Committee
  • -wap- The WAP Forum

Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.

In recent years, all major browsers have adopted this as a de facto standard.


How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.

In the case of the border-radius rule you have a stable fallback.

How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.

The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):

=border-radius(!radius)
  -moz-border-radius= !radius;
  -webkit-border-radius= !radius;
  -khtml-border-radius= !radius;
  border-radius= !radius;

We can now write this everywhere:

.stuff
  +border-radius(15px);

This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).

srcspider