-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error - Unknown @ rule: @-ms-keyframes #295
Comments
Here is the line that broke it: |
This is intentional. Microsoft has unprefixed keyframes for IE 10 and will no longer use the prefixed version. See: |
I see. What about backwards compatibility for versions of IE < 10? Similar to how prefix warnings are output for legacy -moz, etc. |
IE 10 is the first IE to support CSS animations. |
This is directly copied from bootstrap, but was added to a beta version of IE10, but never the production version so is uncessary. Refs: http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web-forward-in-ie10-release-preview.aspx CSSLint/csslint#295
Closed? Strange. And Diggabyte's just question about backward compatibility remains completely unanswered... (Or is "stupidly neglected" perhaps a better term in this specific case?) I just noticed that - after more than six years - this issue is still topical. I am confident that the CssLint behavior is incorrect. As I see it, a specific browser version has NOTHING to do with correct (historical) CSS analysis. Or perhaps should I understand that targeting and using earlier versions of IE should not be taken seriously anymore? (Nowadays, that might be a fair subject of discussion, but six years ago when IE10 was just released?...) And during the last six years, everybody who is/was related to the CssLint project seemed to pretend that this is quite fine. Otherwise, Diggabyte's question would have been satisfactory answered. Seems that quality goes down the toilet on purpose here. Madness. Good luck with this project. |
Introduced after this commit:
e14628b
Looks like the @-ms-keyframes prefix was accidentally overwritten with @-o-keyframes when fixing issue #286
I commented on the line that broke it.
The text was updated successfully, but these errors were encountered: