This piece of code:
Chrome is a false positive as, for some weird reason, it claims to support -webkit-hyphens, but no other value than ‘manual’.
Most importantly, I haven’t tested the various versions of IE, but at the very least it works properly on Opera, Firefox (correctly identifies the currently released versions as not supporting hyphens) and Safari (correctly identifies it as a supporting browser).
Still, untested as it is, might be useful to somebody else.
You could use this, in combination with Modernizr.load, as a polyfill (dynamically load js to add advanced features to non-supporting browsers), but polyfills are a problematic concept when you are actually required to support your website.
Polyfills work extremely well for covering edge cases. For instance, if you run a mac-oriented site and only expect a fraction of your traffic to come from IE7, and all of the other browsers support a feature you really really want to use, a polyfill becomes reasonable. You only expect to use it with one browser, in a context that you understand.
A website that has to support a dozen different browsers in differing versions, only three of which support the feature you want (as is the case with hyphens1), will end up serving the polyfill to most of the visitors.
Instead of filling in the edge cases and only loading it so rarely that rare bugs aren’t likely to surface, the polyfill becomes major application code that needs to be worked on and supported. This, in and of itself, is not so bad, if it weren’t for the fact that this is a major piece of application code that you expect to discard—it’s a feature the browsers are working on implementing, otherwise it wouldn’t be a polyfill.
A polyfill for hyphens doesn’t make much sense.
CSS3 Hyphens are supported by Safari, Mobile Safari, and the upcoming version of Firefox; nothing else as far as I can see.↩