In the beginning, there were three ways to specify colours:
hexadecimal
format (#3FC408), using either three or six characters,
named colours (such as red
, blue
, black
), and
rgb()
- where in the brackets you would have the numerical reference for each of the colours (red, green and blue) from 0 to 255.
CSS3
has since added several new colour formats, including:
rgba()
- red, blue, green, alpha (opacity),
hsl()
- hue, saturation and lightness, and
hsla()
- hue, saturation, lightness and alpha (opacity).
While these new colour formats bring a remarkable amount of flexibility to how developers define colours and the relationships between them, it can also leave older browsers looking worse than expected due to incompatibility.
The problem is that CSS parsers in browsers will skip a property whose name or value is not understood. Older browsers such as Internet Explorer 8 and earlier, do not understand rgba()
, hsl()
, or hsla(),
and as a result will drop any declarations containing them.
Consider the following:
.box {
background: #000;
color: rgba(100, 100, 200, 0.5);
}
Supporting browsers will treat this CSS code as described. Non-supporting browsers will completely drop the color property because the value isn't understood. That means the actual color used will be inherited from the surrounding context and might actually end up black (the same as the background). To prevent this, you should always include a fallback color in either hexadecimal, named, or rgb() format, such as:
.box {
background: #000;
color: blue;
color: rgba(100, 100, 200, 0.5);
}
What ReSharper was asking you to do was to provide a fallback colour. This fallback colour should always go before the new colour to ensure older browsers see and use it correctly, and that newer browsers continue on to use the newer colour format.
More information:
https://github.com/stubbornella/csslint/wiki/Require-fallback-colors