FireworksColdFusionDreamweaverFreehandFlashMXHome
Latest New Content

Latest Free Content
View All
Free Content
Accessibility
CMX Learning Guides
Hosted by enterhost

Newly Supported CSS Selectors in IE7

By: John Gallant , Holly Bergevin ,

Page 1 of 5

Set for printing

Next

Now that IE7 has been released and has begun to penetrate into the userbase, it won't be too long before we can start using more advanced CSS in our pages. Two of the most useful items will be the Child and Adjacent Sibling combinators. These were briefly covered in a couple of Adrian Senior's articles on the Child combinator and Sibling combinator. But now that it is about to become feasible to use them for real web pages, it is time to delve more deeply into the subject.

Even though these two combinators have been part of the W3C CSS specifications for some time, their lack of support has keep most Web developers from putting them to full use. Therefore some basic training in their usage is in order, especially if you have never tried to employ such CSS in large involved site designs. Even when they work correctly, these combinators can add major complications to understanding how your CSS should function. We'll try hard to make it all understandable, and clue you in to what is currently known about problems in browser support.

Note that selectors that include the actual symbols, ">", "+" and the space that is considered a descendant combinator, are referred to as Child, Adjacent Sibling, or Descendant selectors, however the actual symbols themselves (including the space) are called combinators.

A Better Way

Before we get into the combinators themselves, it's a good idea to clarify just what they do differently and why that is a good thing. The "why" is easy; it's to reduce the web page disease called "class-itis." The main reason class-itis is so common on the web is the fact that we have, up until now, had only a single type of fully supported combinator available for building compound CSS selectors. That is the descendant combinator, written as a simple space between parts of a compound selector.

When using the descendant combinator, an element selector on the right is selected if it falls anywhere between the tags of the element selector on the left. An example is p a {color: red;}, which selects any link that falls inside any paragraph. It's useful, yes, but it's also a fairly generalized kind of selection combination.

The progression of class-itis typically goes like this. First, you start with a nice clean HTML structure with simple CSS styling pointing to headings, paragraphs, and so forth. Then someone tells you they need to have the first paragraph within each DIV block display text colored red. You can't just change the global paragraph style because that would affect them all, so you are forced to place a special class name on all those first paragraphs to specifically control them.

Then similar requests are made all over the site dozens of times. The result is a serious case of class-itis. Why is this bad? Because it isn't much better than using the bad old FONT tags to control styling. Sure, classes allow an infinite amount of styling complexity, but along with that can come infinite confusion later on, or possibly sooner rather than later!

As an example, let's say that you have given a class attribute to all those first paragraphs, and everything is fine. Now you are told that it's the first two paragraphs that need the styling, not just the first one. To accomplish that with the current class system you must make sure that each of those second paragraphs also has the special class. Eventually this kind of practice will fill the source up with classes everywhere, making it all too likely that further styling will mysteriously conflict with older styling, causing much tearing of hair.

Wouldn't it be nice if we could just use CSS to say, in effect, "Apply the following styles to the first and second paragraphs inside each DIV block." Well, it so happens that the newly supported CSS combinators will allow us to do exactly that, with just a small amount of clever usage.

Reviewing How They Work

In an earlier article we wrote:

...let's review some terminology. The W3C CSS2.1 specification explains selectors and combinators in the following way:

"A selector is a chain of one or more simple selectors separated by combinators. Combinators are: whitespace, ">", and "+". Whitespace may appear between a combinator and the simple selectors around it." And, "A simple selector is either a type selector or universal selector followed immediately by zero or more attribute selectors, ID selectors, or pseudo-classes, in any order."

The first newly supported combinator (also frequently called a selector, which is only partially accurate) will be the Child combinator, designated by a ">" symbol placed between simple selectors. An example of this is #leftcol>p  {color: blue;}, which would make the text blue in all paragraphs that are direct children of #leftcol.

But if #leftcol contained a DIV, and that DIV contained a paragraph, the above selector #leftcol>p would not make that paragraph's text blue, because the Child combinator, unlike the more frequently used Descendant combinator (a simple space), selects only direct children, not just any more deeply nested descendants of the element shown to the left of the ">" symbol.

The other newly supported combinator will be the Adjacent Sibling combinator, designated by a "+" symbol similarly placed between simple selectors. While the Child combinator targets direct children of another element, the Adjacent Sibling combinator targets an element that directly follows, but is separate from, a previous element. Thus, with the rule h2+p {color: blue;}, you would be able to make the text blue for any paragraph that directly followed an H2 element.

Okay, assuming you have some understanding of how these combinators are supposed to work, let's experiment on a complex element arrangement to see what we can accomplish without using any classes.

We can't provide live demos within the body of this article because CSS selectors must be written and added, either as embedded (in the HEAD) or as externally linked-in styles. We try to avoid adding new CSS rules to the CMX style sheet every time we happen to write about selector issues, because it would eventually make that file hugely bloated. Instead we have a separate demo page, so that you may take the code and easily do your own testing and experiments. The screen shots for this article were taken directly from that demo page and from modifications of it.

Page 1 of 5 1 2 3 4 5 Next


download
Download Support Files


Keywords
CSS, child combinator, adjacent sibling combinator, descendant combinator, selector