Here is best described bug and simple workaround.

Bottom line is: @keyframe rule defined inside media query will result in no animation on IE10/11, so users of jQuery Keyframes unaware of this bug will get nothing with

$.keyframe.define([{ name: 'roll-clockwise', media: '...anything with valid syntax'...

Since usage of this two browsers is significant, and I don't have info whether this bug is resolved in Edge browser or not, my opinion is that jQuery Keyframes should do something about this.

Do you agree?

If yes, which approach would you prefer more:

1.
to retain current $.keyframe.define api,

• detect IE10/11 by UA sniffing,
• detect if media field is used in keyframe definition,
• not append generated keyframe <style> tag to head when condition is found to be false (by using matchMedia().matches)
• queue previous mentioned generated keyframe <style> tag to be appended to head if condition becomes true after resize / orientationchange event

2.
redefine api that deals with responsive animation:
instead $.keyframe.define({media})

    $(selector).playKeyframe({
        name: 'trapdoor-sequence',
        minWidth: '920px',
        minHeight:'500px',
        orientation: 'landscape'
        ...

with same rules: nothing happen if conditions is false, action is queued for eventual later execution if condition becomes true after resize / orientationchange.