Now Playing Tracks

Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies

I agree. Vendor prefixes must die. Think and code according to the standards.

Public service announcement: Every time you call a proprietary feature “CSS3,” a kitten dies. Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all. This distinction is not nitpicking. It’s important because it encourages certain vendors (*cough* Apple*cough*) to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread. The shiny new toys dazzle us and we start promotingthem too, contributing to the echo chamber.

“HOW CAN I HELP?”

The easy rule of thumb is to avoid proprietary features altogether. Don’t use them, don’t evangelize them, and most certainly, don’t depend on them. However, I understand that this might be more easily said than done. If you can’t completely shut proprietary stuff out of your life, here are a few guidelines I’m sure you can follow:

  • Make sure their usage complies with the principles of progressive enhancement so that the design works fine without them.
  • Don’t evangelize them or, if you have to, make sure to explain that these features are proprietary and what that means.
  • If you have to use them in your code, add a comment about this. Something like /* Warning: Non-standard */ would suffice. Many people learn front-end coding by viewing the source of existing websites. Even if you don’t give talks or write tutorials, you are probably indirectly teaching folks with every piece of code you put out there.
  • Call out articles, talks, demos, etc. that evangelize these features with no warnings, or that only use a single vendor’s prefix (which is also a very serious problem). Or, even better, fix them yourself, if possible.
To Tumblr, Love Pixel Union