When Front End talks about a "cascade error", we mean that somewhere in the stylesheets, a style is being applied in error. Mostly this is due to the rules of inheritanceand specificity.
To find cascade errors, first go and look at the page where it's showing up. Find the element, and look up its styles in the stylesheets. The Style Guidewill help you. Some people like to use Firebugto help with this. I use Web Developer.
Hierarchy is very important in CSS. The order in which you write rules decides which rules are followed:
p {color:blue; color: red;}
paragraph is red
This always follows, whether the rules come right next to each other:
p {color:red;}
p {color:blue;}
paragraph is blue
...Or are separated by many other rules in the cascade:
p {color:red;}
li {color:green;}
blockquote {font size: larger;}
...
p {color: blue;}
paragraph is blue
In the archive we use lots of stylesheets, but they make up a single cascade. They stack up in the order they are called in the html document <head>. You can look at that by viewing source, or browsing to otwarchive/app/public/stylesheets/site/2.0. Don't change this order.
The main sheets fit together like this:
Then there are roles, which show different styles to different kinds of user and user agent, like: an iPhone, IE6, a printer etc. These are all equally at position 23 in the cascade:
So, for example, userstuff.css overrides the table styles set in elements.css, so users get plain tables. And admin.css overrides the colour of the header set in region-header, so admins can tell when they're logged in.
By the way:
<div style=""overrides<style type="text/css"> </style>overridesstylesheet.cssBut we don't use inline styles on the archive.
Sometimes you write a rule and nothing happens. No matter what you do, the element doesn't change its display! Sometimes this is because there is a rule lower downthe cascade, that is overriding your rule. This is the most common type of cascade error.
But sometimes you've checked everything is in order, and still your style does not show up. This is because there is another type of hierarchy operating in the cascade. It is called "specificity".
There are lots of ways to select an element with CSS. Not all selectors have equal weights. They have a hierarchical order:
Compare these two rules:
#main li {color:red;}
li p.instructions {color:blue;}
| rule | !important | #id | [attribute] | .class | element |
|---|---|---|---|---|---|
#main li {color:red;} |
0 | 1 | 0 | 0 | 1 |
li p.instructions {color:blue;} |
0 | 0 | 0 | 1 | 2 |
li[title="instructions"] {color: green;} |
0 | 0 | 1 | 1 | 1 |
#main li has a value of 1001, and li p.instructions has a value of only 12, so #main li is always going to override li p.instructions, even though it comes after#main li in the cascade. li[title="instructions"] has a value of 111, so it falls in between. So the HTML code <div id="main">...<li title="instructions">...<p class="instructions">guess my color!</p></li></div>will be RED.
Counting in this way is what we mean by "weighing up" a declaration.*
We use some very specific paths on the archive sheets, but we only infrequently use #ids or !important. This is because it is a lot easier to override .meta dd dd, with a weight of 12, than it is to override #main .meta dd dd, with a weight of 1012.
Only use tag and class selectors. The only place #ids are acceptable are in the four region sheets. Regions are shown on every page: #header, #dashboard, #main, #footer, and are set in region-header, region-dashboard, region-main, and region-footer.
When your element won't change, no matter what you tell it, and you've validated your code and spellchecked your selector, it's quite likely your selector is not specific enough. So weigh it and see. You might need to make it weightier, or more specific, or you might need to make the higher rule lighter, or less specific.
Pedantry: Specificity actually uses an infinite base counting system, so 11 elements do not outweigh 1 class, but you do not need to specify 11 elements ever on our archive so this fact is incidental.