CSS Error Handling

Introduction

Let’s learn about CSS Error Handling

Sorry, I am writing this article after a very long time, yet this is not my original; I was reading about error handling in Google and found some important points, that are presented here. We know the use of syntactically correct markup is certainly not encouraged by permissive browser parsers that correct mistakes or guess intent when provided with malformed markup. The situation for CSS is a bit better, and the CSS 2.1 specification does describe what browsers should do in the case of various errors, but then again, making the assumption that browsers are not permissive and correctly implement all aspects of web specifications is dangerous.

Unknown Properties

If an unknown property is encountered, a CSS-conforming user agent should ignore the declaratin. Given:

h1 {color: red; trouble: right-here;}

The property "trouble" would simply be ignored and the rule would simply set the color. It does not matter what the position of the bogus property declaration is, the result should be the same as long as the declaration is otherwise well-formed.

h1 {trouble: right-here; color: red;}

The case is obviously different if the various separators are missing.

Malformed Rules

In the case where semicolons (;), colons (:), quotes ('or"), or curly braces ( { } ) are misused, a browser should try to handle any unexpected characters and read the properties until a matching value can be found. As an example, consider the simple case of forgetting a semicolon:

h1 {color: red text-decoration: underline; font-style: italic;}

In this case, we should see the browser continue to parse the value of color as “red text-decoration: underline” before it sees a closing semicolon. The font-style property that follows would then be used. Because the color property has an illegal value, it should be ignored.

Other cases are a bit more obvious. For example, here we see the colon missing in a style rule declaration:

h1 {color red; text-decoration: underline; font-style: italic;}

In this case, the color property is simply ignored and the text is underlined and italic.

The situation for quotes and braces is the same, with compliant browsers working to find a matching closing character for any open construct, potentially destroying anything in between. Consider this set of rules, where quite a large amount of style may be lost

h1 {color: green; font-family: "Super Font;}

h2 {color: orange;}

h3 {color: blue; font-family: "Duper Font";}

Be careful, though, because in this case, you might assume that the rule closes off with a quote, but that may introduce more open construct errors later on in the style sheet.

Unclosed Structures and End of File

A CSS browser should close all braces and quotes when it reaches the end of a style sheet. While quite permissive, this would suggest that

<style type="text/css">
h1
{
color: green
}
</style>

Should render properly, since the open rule would be closed automatically by the end of the style sheet. Open quotes would also be closed in a similar manner when the end of the style sheet is reached. Testing reveals this action is actually the case in browsers, but creating a syntactically correct style sheet is obviously far superior to understanding the expected failures of a conformant browser.

Illegal or Unknown Property Values

CSS-conforming browsers must ignore a declaration with an illegal value. For example:

h1 {font-size: microscopic; color: red;}

Would simply not set the font-size value but h1 elements would be red. Usage of illegal characters can turn what would appear to be a correct value into an incorrect one. For example

h1 {color: "green";}

Is incorrect, not because green is an illegal color, but because it is not the same as the keyword green when it is quoted.

Do not assume that a CSS-compliant browser will fix such small oversights. For example, a browser given

h1 {color: green forest;}

We should not use green but instead, ignore the entire rule. Of course, what browser vendors actually do when encountering malformed web documents varies.

Incorrect @ Keywords and Media Values

When an @ media value or media type for a <style> tag is used, incorrect values should be ignored. For example, if you specify <style type="text/css" media="tri-corder">, the browser is supposed to ignore the entire <style> block unless it understands such an odd type. Media types will be explained in depth later, but for now understand that when encountering syntax problems, a CSS-compliant browser should simply ignore anything related to misunderstood values.

Ignoring Network Failures

When style sheets are linked rather than placed within the page, the browser must apply all types it is able to fetch and simply ignore those it can’t. So if you had:

<link rel="stylesheet" href="global.css" type="text/css">
<link rel="stylesheet" href="pagelevel.css" type="text/css">

And the first was fetched by the browser, but the second failed, it would simply apply the rules it had. Obviously, such transitory errors are hard to account for, but other considerations presented in this section should have been caught in the validation of markup and style, explained next