joined:Aug 9, 2008
I vote for this:
Run your own copy of the validator code and teach it to recognize vendor extensions.
More seriously, nothing much at this stage, because, as suzy says, proprietary extensions are, by definition, not standard, so will never validate - unless someone discovers a valid way of hiding them from the validator as we do for ie using conditional comments.
So I'd ask what you are trying to achieve by validating.
I have just one coding goal: To deliver accessible, useable content available to 100% potential users regardless of platform/device/ua. Validation is one
tool available to facilitate that aim, so I use it similar to g1smd - but it remains just one tool given it is possible to have valid but unhelpful code: display:none being the classic example. I rarely use non-standard code, but if I do, I don't worry when the validator objects once I have assured myself the code will not detract from my priority aim.
However, if the end goal is validation for it's own sake - as it is for some govt departments where policy explicitly specifies this as an unqualified priority - then you're stuck without vendor extensions.
If you aren't in a govt-depart type scenario, then what you decide has political implications - I think there have been several sea-changes over the years: (1) Once they were common (at least their forebears - as the only way to get anything done), (2) then despised as deviating from the standards, (3)then only ie treated as deviating, (4) now increasingly more accepted given the delays in css development. Coupled with that the really influential coders seemed to have moved from demanding ua's comply with the standards - back at (2), to using them. as suzy says to reinforce the property is desired, and help speed introduction of the property as standard per (4).
So, if your basic code delivers content to all users, the vendor extensions are part of planned and managed "progressive enhancement", and you don't mind the political implications, there is little reason to avoid them. However, just be aware, this ties you to the individual vendor development programme. Keeping up to date with the status of all the css modules can be bad enough, without taking on the burden of browser and version specific property-level implementations like this: moz-border-radius
[developer.mozilla.org]. That can make for a lot of reviewing work - or pushing wads of out-of-date code down the pipes unecessarily.