7 ms·
You're doing it wrong. Vendor prefixes are not forks, they are test beds. If a designer uses vendor prefixes in production code, they're setting themselves up
by thwarted 16y ago
You're doing it wrong. Vendor prefixes are not forks, they are test beds. If a designer uses vendor prefixes in production code, they're setting themselves up to have to maintain them when browser vendors eventually remove them. This is the price you pay for ABSOLUTELY NEEDING CSS3 FEATURES NOW, OMG, JUST DO IT! OUR APP IS NOT COMPLETE WITHOUT ROUNDED CORNERS! or whichever CSS3 feature you didn't need before CSS3 was conceived of.
And wrapping up their use in a library that is meant to spackle over differences in vendor prefix property implementation is even worse, since it hides what is meant to be public for trying things out. You wanna get vendor prefixes removed? Work on converting your site to use them for testing purposes and report bugs and your opinions as to how you think things should work: providing your real world use cases is much more constructive than covering up differences in things which are, by design, supposed to be different.
That being said, any browser that claims to support CSS3 but only through vendor prefixes is lying. Which means that any vendor who claims CSS3 support for things that have not been finalized or agreed upon or that don't work like they should is lying.
Incidentally, I expect more from alistapart. Encouraging the use of vendor prefix stuff in production files ends up delaying the standardization process.