[Skip to the Main Content]

Why Validate Cascading Style Sheets?

Or, What’s the worst that could happen when my CSS is malformed?

Documentation exists which states consequences when style sheets contain errors. It’s been there since 1998. And, it was revised 2006.

It’s this.

Cascading Style Sheets, level 2, CSS2 Specification, 4 CSS2 syntax and basic data types, 4.1.8 Declarations and properties which states,

The syntax of values is specified separately for each property, but in any case, values are built from identifiers, strings, numbers, lengths, percentages, URIs, colors, angles, times, and frequencies.

A user agent must ignore a declaration with an invalid property name or an invalid value. Every CSS2.1 property has its own syntactic and semantic restrictions on the values it accepts.

Illegal example(s): For example, assume a CSS2.1 parser encounters this style sheet:


h1 { color: red; font-style: 12pt }  /* Invalid value: 12pt */
p { color: blue;  font-vendor: any;  /* Invalid prop.: font-vendor */
    font-variant: small-caps }
em em { font-style: normal }

The second declaration on the first line has an invalid value '12pt'. The second declaration on the second line contains an undefined property 'font-vendor'. The CSS 2.1 parser will ignore these declarations, effectively reducing the style sheet to:


h1 { color: red; }
p { color: blue;  font-variant: small-caps }
em em { font-style: normal }

Further, reading 4.2 Rules for handling parsing errors offers,

In some cases, user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there. CSS 2.1 reserves for future updates of CSS all property:value combinations and @-keywords that do not contain an identifier beginning with dash or underscore. Implementations must ignore such combinations (other than those introduced by future updates of CSS).

To ensure that new properties and new values for existing properties can be added in the future, user agents are required to obey the following rules when they encounter the following scenarios:

  • Unknown properties.

    User agents must ignore declaration with an unknown property. For example, if the style sheet is:

    
    h1 { color: red; rotation: 70minutes }
    
    

    the user agent will treat this as if the style sheet had been

    
    h1 { color: red }
    
    
  • Illegal values.

    User agents must ignore a declaration with an illegal value. For example:

    
    img { float: left }       /* correct CSS 2.1 */
    img { float: left here }  /* "here" is not a value of 'float' */
    img { background: "red" } /* keywords cannot be quoted */
    img { border-width: 3 }   /* a unit must be specified for length values */
    
    

    A CSS 2.1 parser would honor the first rule and ignore the rest, as if the style sheet had been:

    
    img { float: left }
    img { }
    img { }
    img { }
    
    

    A user agent conforming to a future CSS specification may accept one or more of the other rules as well.

  • Malformed declarations.

    User agents must handle unexpected tokens encountered while parsing a declaration by reading until the end of the declaration, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes. For example, a malformed declaration may be missing a property, colon (:) or value. The following are all equivalent:

    
    p { color:green }
    p { color:green; color }  /* malformed declaration missing ':', value */
    p { color:red;   color; color:green }  /* same with expected recovery */
    p { color:green; color: } /* malformed declaration missing value */
    p { color:red;   color:; color:green } /* same with expected recovery */
    p { color:green; color{;color:maroon} } /* unexpected tokens { } */
    p { color:red;   color{;color:maroon}; color:green } /* same with recovery */
    
    
  • Invalid at-keywords.

    User agents must ignore an invalid at-keyword together with everything following it, up to and including the next semicolon (;) or block ({...}), whichever comes first. For example, consider the following:

    
    @three-dee {
      @background-lighting {
        azimuth: 30deg;
        elevation: 190deg;
      }
      h1 { color: red }
    }
    h1 { color: blue }
    
    

    The '@three-dee' at-rule is not part of CSS 2.1. Therefore, the whole at-rule (up to, and including, the third right curly brace) is ignored. A CSS 2.1 user agent ignores it, effectively reducing the style sheet to:

    
    h1 { color: blue }
    
    

    Something inside an at-rule that is ignored because it is invalid, such as an invalid declaration within an @media-rule, does not make the entire at-rule invalid.

  • Unexpected end of style sheet.

    User agents must close all open constructs (for example: blocks, parentheses, brackets, rules, strings, and comments) at the end of the style sheet. For example:

    
      @media screen {
        p:before { content: 'Hello
    
    

    would be treated the same as:

    
      @media screen {
        p:before { content: 'Hello'; }
      }
    
    

    in a conformant UA.

  • Unexpected end of string.

    User agents must close strings upon reaching the end of a line, but then drop the construct (declaration or rule) in which the string was found. For example:

    
          p {
            color: green;
            font-family: 'Courier New Times
            color: red;
            color: green;
          }
    
    

    ...would be treated the same as:

    
          p { color: green; color: green; }
    
    

    ...because the second declaration (from 'font-family' to the semicolon after 'color: red') is invalid and is dropped.

What’s the worst that could happen if one does not validate their CSS and errors exist? What ever errors remain in style sheets will cause browsers to ignore whatever web developers had intended.

That’s all.


Sean Fraser posted this on June 30, 2006 06:03 PM.

  • Technorati: http://www.elementary-group-standards.com/css/why-validate-cascading-style-sheets.html
  • de.licio.us: http://www.elementary-group-standards.com/css/why-validate-cascading-style-sheets.html
  • furl: http://www.elementary-group-standards.com/css/why-validate-cascading-style-sheets.html
  • reddit: http://www.elementary-group-standards.com/css/why-validate-cascading-style-sheets.html

Comments

Comments are closed.

The Elementary Standards: A Compendium of Web Standards, CSS, Linguistics and Search Engine Optimization methodology Copyright ©2005-2007 Sean Fraser. All work is published under a Creative Commons License. All Rights Reserved.

Palm trees on a grassy field in Hawai’i

Main Content Returns thus