Css

Pseudo-element selectors should be valid

The W3C specifications define the valid pseudo-element selectors. Only the official and browser-specific pseudo-element selectors should be used to get the expected impact in the final rendering.

a::beforre { /* Noncompliant; there is a typo on the word "before" */
...
}

Strings should not contain new lines

Shorthand properties that override related longhand properties should be avoided

A shorthand property defined after a longhand property will completely override the value defined in the longhand property making the longhand one useless. The code should be refactored to consider the longhand property or to remove it completely.

a {
padding-left: 10px;
padding: 20px; /* Noncompliant; padding is overriding padding-left making it useless */
}

Text contrast ratio should be at least 4.5:1

Text should provide enough contrast with its background so that it can be read easily by people with moderately low vision, including colorblind people.

This rule raises an issue when a CSS selector defines both the background-color and color properties with a contrast ratio of less than 4.5:1, which is the contrast required to meet WCAG AA level. It applies only when the selector is not on a heading (h1, h2,…) or title

body {
font-size: 17pt;
}
.myclass {
color: #777;  // NonCompliant
background-color: #888;
}

.header h4 {
font-size: 22pt;
}

Expressions within calc should be valid

To perform calculations when specifying a CSS property `calc() function can be used. This function takes single expression as parameter. When writing this expression some rules must be respected:

no empty calc()
there should be an operator between the arguments
there should not be any division by zero

Otherwise calc()` function will be invalid and the entire rule using it will be ignored.

.btn {
border: solid black 1px;
width: calc(100% 80px);  /* Noncompliant */
}

Media features should be valid

The W3C specifications define the valid media features. Only the official and browser-specific media features should be used to get the expected impact in the final rendering.

@media screen and (unknown: 1000px) { .. }

Selectors should be known

HTML, SVG, and MathML define the selectors which can be used in a CSS. A selector that is not part of them is likely to be a typo or a misunderstanding of the CSS syntax.

field {}

ul list {}

calc operands should be correctly spaced

calc is a CSS3 function that provides the possibility to do simple math in CSS (add, subtract, divide, multiply). Without spaces around operators, calc will have no effect.

More precisely, before an operator, there must be a single whitespace or a newline plus indentation. After an operator, there must be a single whitespace or a newline.

#div1 {
position: absolute;
width: calc(100%- 100px); /* Noncompliant; no space after the % sign */
}

Units should be valid

The W3C specifications define the units that can be used with lengths. A unit that is not part of the list of supported ones is likely to be a typo and will be seen as a UI bug by the user.

This rule raises an issue each time a unit is not officially supported.

a {
width: 10pixels; /* Noncompliant; "pixels" is not a valid unit */
}

linear-gradient directions should be valid

`linear-gradient was standardized with CSS3. Before that, it was possible to use different non-standard values to define the gradient’s direction. Because these values are not standard, they are not supported in all browsers and therefore they should no longer be used in order to get the expected gradient in the latest browser versions that support CSS3.

This rule raises an issue when the first parameter of a linear-gradient is not a valid <side-or-corner> or angle`.

.foo { 
background: -webkit-linear-gradient(to top, #fff, #000);
background: linear-gradient(top, #fff, #000);
}

.bar {
background: linear-gradient(45, #fff, #000);
}

at-rules should be valid

Empty blocks should be removed

Selectors of lower specificity should come before overriding selectors of higher specificity

Order of instructions in CSS is important: instructions with equal specificity that occur later in the file take the priority. But when a selector with a higher specificity (e.g. p a { color: green;}) comes before the selector it overrides (e.g.: a { color: green;}), the priority is given to the first one. Even if it works properly, this is harder to anticipate the behaviour of the stylesheet while reading as it goes against the principle that the last instruction takes the priority.

p a {
color: green;
}

a {
color: blue;
}

Color definitions should be valid

An invalid color definition will by default be interpreted as black, which is likely to have unintended impacts on the expected look and feel of the website.

This rule raises an issue when a color definition (color, background-color) is not valid. The color definition is considered valid when it is made of hexadecimal characters:

longhand: 6 or 8 characters (when alpha is defined)
shorthand variant: 3 or 4 characters (when alpha is defined)

a {
color: #3c; /* Noncompliant; shorthand should be made of 3 characters */
}
div {
background-color: #3cb371a; /* Noncompliant; alpha should have 2 characters */
}

Pseudo-class selectors should be valid

The W3C specifications define the valid pseudo-class selectors. Only the official and browser-specific pseudo-class selectors should be used to get the expected impact in the final rendering.

a:hoverr { /* Noncompliant; there is a typo on the word "hover" */
...
}

Single line comment syntax should not be used

Selectors should not be duplicated

In CSS, when selectors are duplicated, the browser applies them in cascade. This means that if two selectors are identical, the second one takes precedence. However, if the declarations within the selectors are not conflicting, they will be combined.

This behavior can lead to unexpected results and make debugging more difficult, especially in larger stylesheets. Therefore, it’s generally recommended to avoid duplicating selectors.

The rule detects the following kinds of duplications:

within a list of selectors in a single rule set,
for duplicated selectors in different rule sets within a single stylesheet.

p {
color: blue;
font-size: 16px;
}

p { /* Noncompliant: duplicated selector 'p', overwrites property 'color' */
color: red;
}

!important should not be used on keyframes

!important within keyframes declarations is completely ignored in some browsers and therefore it should not be used to be consistent among all browsers.

@keyframes kf {
from { margin-top: 50px; }
50%  { margin-top: 150px !important; } /* Noncompliant; ignored */
to   { margin-top: 100px; }
}

Font declarations should contain at least one generic font family

The font-family (and the shorthand font) CSS property specifies a prioritized list of one or more font family names and/or generic family names for the selected element.

If none of the font names defined in a font or font-family declaration are available on the browser of the user, the browser will display the text using its default font. It’s recommended to always define a generic font family for each declaration of font or font-family to get a less degraded situation than relying on the default browser font. This lets the browser select an acceptable fallback font when necessary.

The list of generic font families is as follows:

`serif: Glyphs have finishing strokes, flared or tapering ends, or actual serifed endings.
sans-serif: Glyphs have plain stroke endings.
cursive: Glyphs in cursive fonts generally have either joining strokes or other cursive characteristics beyond those of italic typefaces.
fantasy: Fantasy fonts are primarily decorative fonts that contain playful representations of characters.
monospace: All glyphs have the same fixed width.
system-ui: Glyphs are taken from the default user interface font on a given platform.
ui-serif: The default user interface serif font.
ui-sans-serif: The default user interface sans-serif font.
ui-monospace: The default user interface monospace font.
ui-rounded`: The default user interface font that has rounded features.

a { 
font-family: Helvetica, Arial, Verdana, Tahoma; /* Noncompliant; there is no generic font family in the list */
}

Duplicate imports should be removed

Having the import of the same file twice, makes one of them useless. Leaving them in reduces the code’s readability, since their presence can be confusing.

@import 'a.css';
@import 'a.css'; // Noncompliant

@import url("a.css");
@import url("a.css"); // Noncompliant

Duplicated font names should be removed

Having duplicated font names doesn’t help to read the font declaration and may be an indicator the author of the line was not sure how to configure it. This rule raises an issue when font or font-family properties contain a duplicated font name. This rule ignores $sass, @less, and var(—custom-property) variable syntaxes.

a { 
font-family: 'Georgia', Georgia, serif; /* Noncompliant; 'Georgia' is duplicated */
}

Properties should not be duplicated

CSS allows duplicate property names but only the last instance of a duplicated name determines the actual value that will be used for it. Therefore, changing values of other occurrences of a duplicated name will have no effect and may cause misunderstandings and bugs.

This rule ignores $sass, @less, and var(—custom-property) variable syntaxes.

a { 
color: pink; 
background: orange; 
color: orange
}

CSS properties should be valid

The W3C specifications define the valid CSS properties. Only the official and browser-specific properties should be used to get the expected impact in the final rendering.

This rule ignores:

`$sass, @less, and var(—custom-property) variable syntaxes.
vendor-prefixed properties (e.g., -moz-align-self, -webkit-align-self`).

a {
colour: blue; /* Noncompliant; colour is not part of the specifications */
}

Start Here

Setup

Pull Request Review

Scan center

Integrations

IDE

Rule Reference

Resources