What to do with browser-specific tags as they become standarized

[mmcgu1966]

I’ve noticed that Chrome now accepts the ‘standard’ border-radius and box-shadow tags, instead of having to use ‘-webkit-‘.
Is there any reason to keep adding the ‘-webkit-‘ tag, considering that it was a fallback until the ‘standard’ tag was accepted?

[Senff]

This is one of those things that break my mind as well. I’m ridiculously torn about the use of vendor-specific prefixes, I do understand the need for them at first, but they’re such a pain to actually work with. Excellent question.

However, the only answer I could probably come up with, is that’s it’s probably not standard enough yet (as in, supported/approved/etc by W3C). Only as soon that is the case, we can assume that a non-webkit browser will interpret the tag exactly the same way a webkit browser does.

Until then, it’s possible that various browsers do different things with it, so in order to NOT have non-webkit browsers do things you DON’T want them to do, you don’t give them the non-vendor-specific version.

(that sounded confusing!)

Mozilla could do something completely different with (non-vendor specific) box-shadow than Webkit. So, until the standard is established, you give Mozilla it’s own version with -moz-box-shadow and Webkit it’s own version with -webkit-box-shadow.

In short, I would just say, don’t use box-shadow (instead of -webkit-box-shadow) just cause Webkit accepts it — it may do funky things to other browsers, whereas you can be sure that -webkit-box-shadow won’t mess up Mozilla, Opera, IE, and all the other non-webkit ones.

Obviously, this is all about official standards. If you feel that the generic box-shadow looks fine in all browsers, by all means go with that.

(someone, please jump in, I’m confusing the hell out of myself here!!) ;)

[Senff]

I think the best/clearest post I’ve read about the necessity of vendor prefixes is this one: http://www.alistapart.com/articles/prefix-or-posthack/

Before I read that post, I was anti vendor prefixes. After that, I just found them annoying, but at least useful, and I understood why they exist and how they (help to) define standards.

[wolfcry911]

@mmcgu1966, you may want to check out these tables when deciding when to drop which prefixes
http://caniuse.com (click on the property you wish to check)

[joshuanhibbert]

I was also going to link to what @wolfcry911 shared. I don’t use prefixes for box-shadow or border-radius as 99% of browsers now support the non-prefixed property.

@Senff As far as I am aware, the non-prefixed property is an agreed upon standard, so all browsers should treat unprefixed properties the same. The prefixed properties are for browsers to experiment. So therefore, you have to keep in mind that the non-prefixed property may not behave the same as the prefixed properties.

[Senff]

@joshuanhibbert I agree that’s the case for box-shadow and border-radius — I don’t use prefixed for those either anymore.

But of course that isn’t the case for ALL new properties, and sometimes it may happen that a property is fine without the prefix in one browser, but may not have been standardized yet (which is bascially what I was going for).

Or am I just being way too complicated here….? ;)

[joshuanhibbert]

@Senff If a browser is using a non-standard version of a property, then that browser should flat out ignore the non-prefixed version of that property, only using the prefixed version.

[joshuanhibbert]

@mmcgu1966 Exactly. But with some properties, such as box-shadow and border-radius, you no longer need to worry about prefixes.

[Senff]

@joshuanhibbert Doh, that makes perfect sense. Like @mmcgu1966 – why didn’t I think of that in the beginning. These prefixes are making my brain melt and I’m clearly overcomplicating things.

[joshuanhibbert]

@Senff Haha, they are certainly confusing. And there are people who oppose their use at all.

[Senff]

@joshuanhibbert I’m still on the fence myself, to be honest. I really do recognize why they’re useful during the “experimental” stage, but on the other hand (apart from the fact that it’s just more work for us) I would also support using ONLY standardized tags, and not any tags that are only read by one type of browser.

I’m all for experimentation, but not a big fan of experiments in a live environment.

Remember the late 90s browser wars, when Microsoft got blasted for coming up with their own IE-specific tags (that other browsers, most notably Netscape Navigator, wouldn’t recognize)? It’s practically the same thing, except now it’s all OK to do.

ANYWAYS….. I’m babbling. ;)

[Paulie_D]

Frankly, it makes more sense to me to use an app or js to prefix your CSS on the fly. That eliminates many of the issues raised and you only have to deal with your module/app/js being current.

[Author]

Posts