Better (fallbacks) diagnostics

[davidhund]

I like the idea of an IE8 'linter' but your checks are very coarse. They do not, for example, take into account any fallbacks in CSS etc. For example: it warns against rgba() but does not check to see if there's any rgb() or hex. fallback preceding the rule.

It would be helpful if you'd scan the complete rule and check for multiple property-values (fallbacks), e.g.

.mod {
    background-color: rgb(0,0,0); // fallback: simple black
    background-color: rgb(0,0,0,0.7); // semi-trans
    font-size: 16px; // fallback in PX
    font-size: 1rem; // rem-sizes
}

The rule above is perfectly fine in IE8 because of the fallbacks...

[davidhund]

Another thing re:fallbacks would be to check for known polyfills. You warn against the HTML5 sectioning elements, but many pages include e.g. Modernizr. These elements are no issue then.

[etodanik]

I think polyfill checks are different in nature than checking for fallbacks within the rule itself. I can of course start a database of known polyfills but I think this could be a different issue altogether.

I think I'll take upon the first obvious task of checking for fallbacks within the same rule definition (as in your example).

The second, slightly more cumbersome test would be to see if there is a different ie8.css type file that's very common specifically for fallbacks.

[davidhund]

Yeah, checking for polyfills can get cumbersome. However, some of these—such as Modernizr and html5shiv (even the h5BP .oldIE classname)— are so widespread it would be less of a hassle to check for those?