> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Css

<AccordionGroup>
  <Accordion title="Pseudo-element selectors should be valid">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a::beforre { /* Noncompliant; there is a typo on the word "before" */
      ...
      }
      ```

      ```css Fix theme={null}
      a::before {
      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Strings should not contain new lines">
    <div class="paragraph">
      <p>According to the W3C specifications:</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>A string cannot directly contain a newline. To include a newline in a string, use an escape representing the line feed character in ISO-10646 (U+000A), such as "\A" or "\00000a".</p>
        </div>

        <div class="paragraph">
          <p>\[…​]</p>
        </div>

        <div class="paragraph">
          <p>It is possible to break strings over several lines, for aesthetic or other reasons, but in such a case the newline itself has to be escaped with a backslash ().</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a {
      content: "first
      second";     
      }
      ```

      ```css Fix theme={null}
      a {
      content: "first\Asecond";     
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Shorthand properties that override related longhand properties should be avoided">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a {
      padding-left: 10px;
      padding: 20px; /* Noncompliant; padding is overriding padding-left making it useless */
      }
      ```

      ```css Fix theme={null}
      a { 
      padding: 10px; /* Compliant; padding is defining a general behaviour and padding-left, just after, is precising the left case */
      padding-left: 20px;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Text contrast ratio should be at least 4.5:1">
    <div class="paragraph">
      <p>Text should provide enough contrast with its background so that it can be read easily by people with moderately low vision, including colorblind people.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a CSS selector defines both the <code>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</code></p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      body {
      font-size: 17pt;
      }
      .myclass {
      color: #777;  // NonCompliant
      background-color: #888;
      }

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

      ```css Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Expressions within calc should be valid">
    <div class="paragraph">
      <p>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:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>no empty calc()</p>
        </li>

        <li>
          <p>there should be an operator between the arguments</p>
        </li>

        <li>
          <p>there should not be any division by zero</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Otherwise calc()\` function will be invalid and the entire rule using it will be ignored.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      .btn {
      border: solid black 1px;
      width: calc(100% 80px);  /* Noncompliant */
      }
      ```

      ```css Fix theme={null}
      .btn {
      border: solid black 1px;
      width: calc(100% - 80px);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Media features should be valid">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      @media screen and (unknown: 1000px) { .. }
      ```

      ```css Fix theme={null}
      @media screen and (width: 1000px) { .. }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Selectors should be known">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      field {}

      ul list {}
      ```

      ```css Fix theme={null}
      input {}

      ul li {}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="calc operands should be correctly spaced">
    <div class="paragraph">
      <p><code>calc is a CSS3 function that provides the possibility to do simple math in CSS (add, subtract, divide, multiply). Without spaces around operators, calc</code> will have no effect.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      #div1 {
      position: absolute;
      width: calc(100%- 100px); /* Noncompliant; no space after the % sign */
      }
      ```

      ```css Fix theme={null}
      #div1 {
      position: absolute;
      width: calc(100% - 100px);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Units should be valid">
    <div class="paragraph">
      <p>The W3C specifications define the <code>units</code> 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.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue each time a unit is not officially supported.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a {
      width: 10pixels; /* Noncompliant; "pixels" is not a valid unit */
      }
      ```

      ```css Fix theme={null}
      a {
      width: 10px;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="linear-gradient directions should be valid">
    <div class="paragraph">
      <p>\`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.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when the first parameter of a linear-gradient is not a valid \<side-or-corner> or angle\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      .foo { 
      background: -webkit-linear-gradient(to top, #fff, #000);
      background: linear-gradient(top, #fff, #000);
      }

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

      ```css Fix theme={null}
      .foo { 
      background: -webkit-linear-gradient(top, #fff, #000);
      background: linear-gradient(to top, #fff, #000);
      }

      .bar {
      background: linear-gradient(45deg, #fff, #000);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="at-rules should be valid">
    <div class="paragraph">
      <p>The W3C specifications define the valid <code>at-rules. Only the official and browser-specific at-rules</code> should be used to get the expected impact in the final rendering.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      @encoding "utf-8";
      ```

      ```css Fix theme={null}
      @charset "utf-8";
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Empty blocks should be removed">
    <div class="paragraph">
      <p>Leftover empty blocks are usually introduced by mistake. They are useless and prevent readability of the code. They should be removed or completed with real code.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a { }
      ```

      ```css Fix theme={null}
      a { color: pink; }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Selectors of lower specificity should come before overriding selectors of higher specificity">
    <div class="paragraph">
      <p>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. <code>p a  \{ color: green;}) comes before the selector it overrides (e.g.:  a  \{ color: green;}</code>), 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>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      p a {
      color: green;
      }

      a {
      color: blue;
      }
      ```

      ```css Fix theme={null}
      a {
      color: blue;
      }

      p a {
      color: green;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Color definitions should be valid">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a color definition (<code>color, background-color</code>) is not valid. The color definition is considered valid when it is made of hexadecimal characters:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>longhand: 6 or 8 characters (when alpha is defined)</p>
        </li>

        <li>
          <p>shorthand variant: 3 or 4 characters (when alpha is defined)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a {
      color: #3c; /* Noncompliant; shorthand should be made of 3 characters */
      }
      div {
      background-color: #3cb371a; /* Noncompliant; alpha should have 2 characters */
      }
      ```

      ```css Fix theme={null}
      a {
      color: #3cc;
      }
      div {
      background-color: #3cb371ac;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Pseudo-class selectors should be valid">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a:hoverr { /* Noncompliant; there is a typo on the word "hover" */
      ...
      }
      ```

      ```css Fix theme={null}
      a:hover {
      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Single line comment syntax should not be used">
    <div class="paragraph">
      <p>The W3C specifications say comments should be defined using <code>/\* ... \*/. The use of //</code> is not supported on all browsers and can lead to unexpected results.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      // some comment
      a { color: pink; }
      ```

      ```css Fix theme={null}
      /* some comment */
      a { color: pink; }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Selectors should not be duplicated">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>The rule detects the following kinds of duplications:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>within a list of selectors in a single rule set,</p>
        </li>

        <li>
          <p>for duplicated selectors in different rule sets within a single stylesheet.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```css Bad theme={null}
      p {
      color: blue;
      font-size: 16px;
      }

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

      ```css Fix theme={null}
      p {
      color: red;
      font-size: 16px;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="!important should not be used on keyframes">
    <div class="paragraph">
      <p><code>!important</code> within keyframes declarations is completely ignored in some browsers and therefore it should not be used to be consistent among all browsers.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      @keyframes kf {
      from { margin-top: 50px; }
      50%  { margin-top: 150px !important; } /* Noncompliant; ignored */
      to   { margin-top: 100px; }
      }
      ```

      ```css Fix theme={null}
      @keyframes kf {
      from { margin-top: 50px; }
      50%  { margin-top: 150px; }
      to   { margin-top: 100px; }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Font declarations should contain at least one generic font family">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>The list of generic font families is as follows:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`serif: Glyphs have finishing strokes, flared or tapering ends, or actual serifed endings.</p>
        </li>

        <li>
          <p>sans-serif: Glyphs have plain stroke endings.</p>
        </li>

        <li>
          <p>cursive: Glyphs in cursive fonts generally have either joining strokes or other cursive characteristics beyond those of italic typefaces.</p>
        </li>

        <li>
          <p>fantasy: Fantasy fonts are primarily decorative fonts that contain playful representations of characters.</p>
        </li>

        <li>
          <p>monospace: All glyphs have the same fixed width.</p>
        </li>

        <li>
          <p>system-ui: Glyphs are taken from the default user interface font on a given platform.</p>
        </li>

        <li>
          <p>ui-serif: The default user interface serif font.</p>
        </li>

        <li>
          <p>ui-sans-serif: The default user interface sans-serif font.</p>
        </li>

        <li>
          <p>ui-monospace: The default user interface monospace font.</p>
        </li>

        <li>
          <p>ui-rounded\`: The default user interface font that has rounded features.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```css Bad theme={null}
      a { 
      font-family: Helvetica, Arial, Verdana, Tahoma; /* Noncompliant; there is no generic font family in the list */
      }
      ```

      ```css Fix theme={null}
      a { 
      font-family: Helvetica, Arial, Verdana, Tahoma, sans-serif;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Duplicate imports should be removed">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      @import 'a.css';
      @import 'a.css'; // Noncompliant

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

      ```css Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Duplicated font names should be removed">
    <div class="paragraph">
      <p>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 <code>font or font-family properties contain a duplicated font name. This rule ignores \$sass, @less, and var(--custom-property)</code> variable syntaxes.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a { 
      font-family: 'Georgia', Georgia, serif; /* Noncompliant; 'Georgia' is duplicated */
      }
      ```

      ```css Fix theme={null}
      a { 
      font-family: Georgia, serif;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Properties should not be duplicated">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>This rule ignores <code>\$sass, @less, and var(--custom-property)</code> variable syntaxes.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a { 
      color: pink; 
      background: orange; 
      color: orange
      }
      ```

      ```css Fix theme={null}
      a { 
      color: pink;
      background: orange
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="CSS properties should be valid">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>This rule ignores:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`\$sass, @less, and var(--custom-property) variable syntaxes.</p>
        </li>

        <li>
          <p>vendor-prefixed properties (e.g., -moz-align-self, -webkit-align-self\`).</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```css Bad theme={null}
      a {
      colour: blue; /* Noncompliant; colour is not part of the specifications */
      }
      ```

      ```css Fix theme={null}
      a {
      color: blue;
      }
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>