![]() |
Site Archive (Complete) | |||
|
ABOUT US |
CONTACT |
ADVERTISE |
SUBSCRIBE |
SOURCE CODE |
CURRENT PRINT ISSUE |
NEWSLETTERS
|
RESOURCES
|
BLOGS
|
PODCASTS
|
CAREERS
|
||||
January 01, 2002
Inheritance: Friend and Foe
One of the most fundamental aspects of Cascading Style Sheets (CSS) is the concept of inheritance. This refers to the way in which a style is passed from an element to its children, so that styles appear to be consistent. This mechanism is indispensible, but it can also be a source of confusion and annoyance-especially if you aren't careful. We'll take a quick look at how inheritance works, and why some properties are inherited while others are not. Then we'll touch on a few ways in which inheritance can actually be an obstacle, albeit one which is easily overcome.
The basics
First, a quick review of the terms we'll be using. A child element is an element which is part of another, and a parent element is an element which has children. For example, given the markup in Figure 1, the
<p> This paragraph contains <em>emphasized text</em> and a hyperlink created with<a href="http://style.webreview.com/"> an anchor tag</a>. </p><em>Figure 1. Example markup.</em> <em> text in the middle of that paragraph was not purple. However, without inheritance, that's exactly what you'd have. Since color is an inherited property, its values are passed from a parent element to its children. Figure 2 shows the difference between the two possibilities-the first way is the correct way, and the second is a hypothetical screenshot from an evil parallel universe where CSS has no inheritance.
![]() Figure 2. Text color with and without inheritance. ![]() Figure 3. Borders with and without inheritance. Oops! Inheritance!Great stuff, right? How could inheritance possibly be bad? As it happens, there are circumstances in which inheritance can be a little confusing. It isn't really bad, of course, but it can bite you in unexpected ways. One way is when a style is inherited when you don't expect it. A few months back, I got e-mail from a developer who had a big problem: His boldface tags were working fine in one browser, but not the other. His markup was clean, there was nothing wrong with the tags, and the styles all checked out as correct. There was no apparent reason why the boldface refused to work in one browser. So he asked me to take a look. It took me a few minutes, but eventually I figured it out:BODY {font-weight: normal;}
normal was inheriting into the <b> tag, thus suppressing the boldface style. The fix was simple enough:
BODY {font-weight: normal;}
B {font-weight: bold;}
<b>) inherits a value (such as font-weight: normal), but has a
more direct rule associated with it (see above), then the assigned rule overrides whatever value was inherited.
Let's take that a step further. Remember the "wrong" example in Figure 1? Let's assume that you actually want your paragraph to look like that, with the <em> and other elements in black, not purple. In
order to do that, you would need the following styles:
P {color: purple;}
EM, STRONG {color: black;}
![]() Figure 4. Overriding inheritance. purple, the <em> and <strong> element use the declared value of black instead.
Inheritance taxNow, let's go back to the boldface problem. It doesn't really make sense that a browser would inherit a style into an element which would override its usual behavior, right? As usual-yes and no. From a CSS point of view, elements don't have "usual behavior." They only have whatever styles are specified. The reason that the browser overrides the font weight of the<b>
element is that it doesn't have a predefined CSS rule regarding the weight of that particular element.
This isn't really a good thing, obviously. There are some elements which should have a small set of pre-defined styles. <b> is one of them, as we've seen. On the other hand, there is such a thing as
taking it too far. Inheritance into tables is one area of possible trouble.
As you may know, some styles just won't inherit into tables. For example, try creating a document in which the color for the body is green and monospace, and inside that document, include a table with some
text in it. Now, load that file into Explorer 4.x for Windows, or Navigator 4.x on any platform. Odds are, you'll see green body text, but black text in another type of font inside the table.
This could be written off as a simple breakdown in the chain of inheritance, and that could well be the case. But another explanation is that the browser already has a predefined style for the color of the text, and at least one or two developers have told me that this is the case. In fact, some browsers appear to have preset styles for the font,
size, and color of text inside tables.
This is a major problem, because your styles combined with the browser's built-in styles could come out something like this, assuming your browser's preferences are set to use black serif text for document display:
BODY {color: green; font-family: monospace;}
TABLE {color: black; font-family: serif;}
BODY, TABLE, TH, TD {color: green; font-family: monospace;}
Trickling downDespite the problems one can encounter, we're definitely a lot better off with inheritance than without it. Over time, we can hope that browsers become more intelligent about how their built-in styles should be written, and we all can worry a little less about trying to cover every last detail of the document's appearance. On the other hand, this is a good lesson to learn: The less you assume about how a document will be displayed, and the more comprehensive your styles are, the less likely you'll be to trip over problems like those explained in this article. Just because you think the<strong> element should be boldfaced, that doesn't necessarily make it so. If you really think that it should be boldfaced in your documents, then make sure you declare that in your style sheets. Otherwise, a browser might come along with different assumptions, and
people using that browser won't see any boldfaced text at all.
Previously in Sense of Style
Styling Buttons
|
|
|||||||||||||||||||||||
|
|