Can I use keyframes without browser detection?

Question

I am making a site that uses some CSS3 keyframes animations.

The guides I have seen suggest using separate code for each browser specifying which code is for what browser as I go along.
eg. This guide which suggests:

@-webkit-keyframes NAME-YOUR-ANIMATION {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}
@-moz-keyframes NAME-YOUR-ANIMATION {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}
@-o-keyframes NAME-YOUR-ANIMATION {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}
@keyframes NAME-YOUR-ANIMATION {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}
#box {
  -webkit-animation: NAME-YOUR-ANIMATION 5s infinite; /* Safari 4+ */
  -moz-animation:    NAME-YOUR-ANIMATION 5s infinite; /* Fx 5+ */
  -o-animation:      NAME-YOUR-ANIMATION 5s infinite; /* Opera 12+ */
  animation:         NAME-YOUR-ANIMATION 5s infinite; /* IE 10+, Fx 29+ */
}

And this one Which suggests slightly different grouping but essentially the same thing.

However I have seen many articles saying that browser detection is poor practice in modern webpages.

This page (same site as above)

W3C agrees but feels an exception could be made for browser prefixes in css.

Is it possible to use keyframes using an approach that just queries the support of the feature rather than specify a browser?

Answer 1

However I have seen many articles saying that browser detection is poor practice in modern webpages.

Yes, browser detection is not good practice as it is unreliable and likely to break in the (near) future.

However, what you are doing here is not "browser detection" as described in that article. You are using vender prefixes.

Vender prefixes are OK, the accepted way of doing this (implementing a feature that is still considered "draft"). It is the only way of doing this.

"The problem" is that browsers don't necessarily support the "standard" way of doing this yet, ie. without the vendor prefix. Probably because they implemented this before it was a standard; before the "final" implementation has been agreed. In the meantime they implement how they think it will work and use a vendor prefix. The vendor prefix'd rule might not work the same way as the final "standard".

So, the vendor prefix'd version will always (or for a while yet) work in the browser it is designed for. The browser ignores all other vendor prefixed rules (in CSS, if a browser does not understand something it should ignore it). When the browser does implement the standard and starts to support the non-vendor-prefixed rule then that is the rule that will take priority.