Internet Explorer 9 support

[cateland]

Using Radium with Internet Explorer generate the subsequent Error :

SCRIPT438: L’objet ne gère pas la propriété ou la méthode « matchMedia »

Meaning that the window.matchMedia is not available.

I think it would be a great instead of crashing to notice the developper via a console warning in developpement mode that one of his component who use media query won't work fully as intended. And give us an opportunitty to gracefully degrade such component.

[ryan-roemer]

Generally speaking, with React my sense is that it's left up to the library consumer to polyfill down to the browsers you expect to support (e.g., es5-shim) -- https://facebook.github.io/react/docs/working-with-the-browser.html#browser-support-and-polyfills

Perhaps we just need to add similar documentation / warnings in the README / site pointing to http://caniuse.com/#feat=matchmedia and suggesting something like https://afarkas.github.io/webshim/demos/#matchMedia ?

[cateland]

I tried to use https://github.com/paulirish/matchMedia.js polyfill to stumble on the next error (thx for pointing to that polyfill)

SCRIPT438: Object doesn't support property or method 'addListener'

[ryan-roemer]

EDIT: addListener is going to need es5-shim polyfills IIRC Actually, I think it's another polyfill needed. Yikes polyfill explosion!

[ryan-roemer]

Aha! https://github.com/paulirish/matchMedia.js/blob/master/matchMedia.addListener.js

[alexlande]

Huh, I didn't realize that addListener was a separate polyfill. Sorry about that!

I think this is both a documentation + code issue. Radium definitely shouldn't blow up if a browser doesn't have matchMedia and you don't have a polyfill. It's valid to want to not support media queries on old IE but use them elsewhere, for example.

We need to:

• [ ] Update docs to mention this
• [x] Handle cases matchMedia (and maybe addListener separately) aren't available.

[MattKunze]

Keyframe animation doesn't work in IE9 either. I don't think there is a workaround or polyfill, but it would be nice to gracefully do nothing in this case rather than throwing exceptions.

I'm getting 'SCRIPT5022: DOM Exception: SYNTAX_ERR (12)' when it calls animationStyleSheet.sheet.insertRule(rule, animationStyleSheet.sheet.cssRules.length) in the keyframes function.

[MattKunze]

Do you have a preferred way you want to handle detecting the availability of features like this? I'd be happy to create a PR, just want to make sure it lines up with your thinking.

The matchMedia/addListener cases seem easy to detect. With keyframes, it could either try to detect IE9, or maybe just add try/catch blocks around the offending statements.

[ianobermiller]

Actually, we should just be able to do a feature detect on animation: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations/Detecting_CSS_animation_support

We already have all this code in prefix, so I suggest exposing the _getPrefixedProperty method and just making sure it returns a string for the animation property. My plan is to refactor prefix into a module Prefixer, instead of just a function, and including methods getPrefixedStyle, getPrefixedProperty, and the cssPrefix and jsPrefix values.