If you are unsure of the elements of a CSS rule or you are new to CSS in general I would recommend you read this article first "CSS: An Introduction." This will give you the basic terminology you will need to follow this article.
To allow our documents to render correctly cross browser, we need to use a doc type above the opening html tag. This, of course, also applies to the rendering of our CSS. If we do not use a doc type our results may differ wildly from any given browser to another. If you are unsure of what a doc type is and need further information on this aspect of your documents Holly Bergevin has written a great article here.
The patterns we can apply using our selectors are varied. We will begin by taking a look at what pattern matching is, how it works, and how it can help to define and organize the rules within our style sheets. Getting a handle on pattern matching, will enable us to open our documents up to styling to a greater degree than if we completed our CSS element by element.
Our selectors, and therefore our rules, are dependant on the document tree. Nope, this does not grow in the Amazon Rain Forest. It actually lives in Dreamweaver MX (well, as far as we are concerned it does). It also, of course, lives inside every html document regardless of whether that document is ColdFusion, .asp, .aspx or php based; the language we use is irrelevant. What we are interested in here is the raw basic mark up that is the basis of our html documents.
To see this we will open a new document in Dreamweaver MX. For ease of viewing, I have omitted the doc type from the code below. Always use a doc type for your documents to obtain consistent results in a cross browser manner. Let's take a look at Code block 1.
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
</body>
</html>
In the document tree every element has a parent element except the root element. You may not see the document tree so clearly in Code block 1, but it is there. Let me explain a little. The root element in the code above is the html element. The root element has no parent, and its children which come directly below it in the document tree are the body and head sections. Let's look at Tree view 1 to see how this lays out more clearly.
At this point we need to realize that the document tree is not representative of the code we see in Dreamweaver MX. In code view, the code flows from top to bottom. But when our code is processed, it is processed in the flow of the tree view. We will see how this effects our code a little later in the article.
As we can see from Tree view 1, we clearly have a root element in our document. The body and head areas of our document are children of that root element. Furthermore, the head element has a child element called title. It is worth pointing out at this stage that a child element can only have one parent element and the parent element will be the next item up on the document tree. Let's take a look at Tree view 2 to see how the document tree progresses as we start to build our document.
Within the support files is a document called sibling.html. You can open this page in Dreamweaver MX to use as a "work along page." The CSS you need is embedded in the head of that document.
As you can see, we have now added the h1 tag into the body of our document in Dreamweaver MX. This results in an addition to the document tree as shown in Tree view 2. The h1 tag is now in place and it falls under the body tag. The body tag is now a parent to the h1 and a child to the the html root element. Let's expand on this one more step and add a second item into our Dreamweaver MX document. This time we will add the h2 tag. This changes the document tree to the appearance shown in Tree view 3.
Now you can see that the body has two children, our h1 and our h2 elements. This means that our h1 and h2 elements are in fact related as they have the same parent. They are known as siblings. This is a word I want you to remember. It is important when we want to define certain patterns in our CSS rules. When we understand the relationship between our elements, it makes our CSS rule definitions much easier to code. Provision is made for the use of styling our CSS elements by the use of selectors, and more importantly, our selectors can make use of the element's relationships within our document tree.
This enables us to provide different values for any given element. We can style a completely new set of values for the element to use according to its relationship in the document tree with one of its siblings. Sound complicated? Well it's not really. Let's look at the sibling relationship. To see this in action, we will add a second h2 tag to our Dreamweaver MX document. This gives us a document tree as shown in Tree view 4.
To take advantage of the sibling relationships within the document tree we need to use the special sibling combinator, the + sign. This is used to connect the selectors as shown in the bottom rule of Code block 2. Our h1 and h2 rules are telling the browser to render the h1 and h2 tags as blue and red respectively, and to size them both to 15px. However, if our h2 tag immediately follows an h1 tag, the condition changes. In that scenario we are giving out instructions to change the text to the color green. We achieve this by using the + combinator.
<style type="text/css" media="screen">
h1{
font-size: 15px;
color: blue;
}
h2{
font-size: 15px;
color: red;
}
h1 + h2{
font-size: 15px;
color: green;
}
</style>
We could of course make any number of changes to the sibling h2 selector in this scenario. They would only be applied to the sibling h2 when it followed an h1 tag. The sibling selector we have defined here is known as a direct adjacent combinator. It will only effect the h2 tag when it is adjacent to an h1 tag, and the rule defines that it must not only be adjacent, but it must come after the h1 tag.
We have added to our vocabulary in the previous two paragraphs. The word combinator has come into play. Combinators provide a method of joining our selectors and are the heartbeat of pattern matching in our style sheets. The combinators allow us to style our documents by relationship in the document tree. Various types of combinators are made available for us to use in the CSS specifications, but for now we will look only at the direct adjacent combinator, the + sign. We will explore others as this series progresses.
Let's go back to our document tree and re-explore what exactly is going on within our document. Let's look at how the document tree controls the output of our rules and the flow of information from our document. We have set up our page and added the CSS styles above. Now preview the output in one of the compliant browsers shown in the list at the base of this article.
If you look again at Tree view 4 you will notice that the h1 and h2 tags are children of the body and grandchildren of html. The line of inheritance can always be followed all the way back to the root element. So theoretically, we should be able to follow that line back with our selectors. Change your h1 rule to look like Code block 3. When you have done that, view the page in one of the compliant browsers. You should see no change in the display at all. This is because the line of inheritance is correct. You can even omit the body tag and go directly to the html root element without ill effect.
html body h1{
font-size: 15px;
color: blue;
}
Looking at Tree view 4 again, we can see that the head section of our document branches off separately from the body. It leaves the root element (html) and separates from the body creating its own branch in the document tree and providing its own function within our processed document. We will look more closely at the head branch in my forthcoming series of articles that I have planned on the document tree.
As the head element does not make it into the body of our document we cannot use that branch of the document tree to set our CSS rules against. If we try to change our styles to work against the head element, they will fail. Try the rule as shown in Code block 4 and retest your page.
html head body h1{
font-size: 15px;
color: blue;
}
While our attempt to come into the body of the document through the head branch with our h1 rule was always doomed to failure, it has not effected our CSS rules that have been correctly set. The raw html markup is still in our document, so our adjacent sibling selector will still do its job despite the fact that we lost our styling of the h1 tag. Our h1 + h2 sibling rule does not know or care if the element it is related to has been styled. The CSS rules we have defined only care about the html markup in our document. If the html mark up is correct, and the pattern we have set matches, then our rules will be applied.
You may wonder why, since the body selector was declared, our styling was not shown. The fact is that the document tree is processed from the root element. We indicated the root (html) selector first, and then the head. But we have no body in the head branch of our document tree. So our rule died after the head selector was processed. You can liken this to driving your car and taking a wrong turn into a dead end road. We declared head after html in our CSS rule and thus guided the process of our rule away from the body tag.
| Browser | Supported Windows | Supported Macintosh |
|---|---|---|
| Mozilla | Yes | Yes |
| Opera 7 | Yes | Yes |
| Netscape 7 | Yes | Yes |
| Internet Explorer 6 | No | n\a |
| Internet Explorer 5+ | No | Yes |
| Safari | n\a | Yes |
| Firebird | Yes | Yes |
| Camino | n\a | Yes |
Okay, we have learned a little about the document tree. We have seen an example of how inheritance works. We have also seen what happens when the inheritance is incorrect. Hopefully, this has given you insight into how your documents are processed and how you can take advantage of the relationships between certain elements.
We explored and exploited the relationship between our h1 and h2 tags. The h tags could just as easily have been any other tags. It is not the tag that's important here. It is the relationship between one element and another element that have the same parent within the document tree.
This seems a good place to call a temporary halt to things. I hope you enjoyed this introduction to the document tree. Pattern matching is a powerful method that we can use to exploit the styling of our documents. The next article will look further at the document tree as well as look at other combinators that are available to us within the CSS specifications.
If you have any questions on this article I will see you in the forums 8~). Thanks for reading along!
Keywords
CSS, document tree, selectors, combinators, sibling selectors,
