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?
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!!) ;)
There's nothing wrong with using prefixes for now. Until it is standardised, especially for stuff like webkit animations, your best bet is to continue using them.
Don't forget that they will of course be backwards compatible so even if things are later agreed upon by the working group your web designs will still look awesome.
Thanks guys.. on a tangent.. aren't the browsers actually going to be the source of the standard? In the end, if the major browsers collectively decide to adopt their own standard, wouldn't that be the defacto standard, regardless of the W3C?
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.
@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)
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.
@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....? ;)
@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 ... that's the basic point. A vendor prefix would in turn, be completely ignored if the browser is using a 'standard' prefix given after it. Don't know why I didn't think of that in the beginning.
@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 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.
I just realized one important assumption that I think we all made. What if the W3C changes a 'standard' tag. Since the browsers have browser-specific tags, that assumed standard tag we use today may eventually stop working, but the fallback will be forever.
I can just see, in ten years, people running Dart code to strip-out all the old vendor-specific tags.
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.
I noticed that border-radius is accepted by Chrome, Firefox, and IE. Oddly enough, I also discovered that Oprah never did have a '-o-border-radius' prefix and we all just assumed they did. So, does that make that browser prefix dead? Anybody seen a resource that tracks them as they become standardized?
Is there any reason to keep adding the '-webkit-' tag, considering that it was a fallback until the 'standard' tag was accepted?
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-shadowthan Webkit. So, until the standard is established, you give Mozilla it's own version with-moz-box-shadowand 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-shadowwon'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-shadowlooks fine in all browsers, by all means go with that.(someone, please jump in, I'm confusing the hell out of myself here!!) ;)
Don't forget that they will of course be backwards compatible so even if things are later agreed upon by the working group your web designs will still look awesome.
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.
http://caniuse.com (click on the property you wish to check)
box-shadoworborder-radiusas 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.
box-shadowandborder-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....? ;)
Don't know why I didn't think of that in the beginning.
box-shadowandborder-radius, you no longer need to worry about prefixes.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. ;)
I can just see, in ten years, people running Dart code to strip-out all the old vendor-specific tags.
Anybody seen a resource that tracks them as they become standardized?