html vs css pt3
In this article I'll be continuing my quest for leaner css at the expense of slightly more convoluted html. I hope last week's example on navigation lists was clear enough as to remove any remaining confusion. Today we'll be looking at html headings (<h1> - <h6>
) and why they are such a drag to style.
headings
/* xhtml code */ <div class="focus"> <h2>heading</h2> </div> /* css code */ .focus h2 {font-size:120%; margin:1em;} .focus h3 {font-size:120%; margin:1em;}
Styling a heading in html isn't very difficult. It's usually one of the first examples given when running into practical explanations on html semantics and css. But the whole concept of headings in html wasn't very well thought out when it was conceived a long time ago. When writing html, you need to specifically indicate the level of a heading through a number ranging from 1 to 6.
This is not really much of an issue until you start styling components that can appear in more than one context. The code of this component might change if it falls into a different heading structure. The example code above illustrates this, as we have a focus block that can hold an <h2>
tag as well as an <h3>
tag depending on the context. The component should be styled as a whole and should remain consistent, independent of the context. So we need to include css code for both headings.
We can of course neglect the structural nesting of the headings, but that would hurt our html semantically and structurally. This isn't just a personal quirk of mine either, since the people that are developing xhtml2 have already tackled this problem and removed the numbering from the heading tag. Smart choice, but unless everyone starts adapting xhtml2 within a year, we're stuck with numbered headings for quite a while to come (html5 still has them).
improved code for better css handling
/* xhtml code */ <h2 class="heading">heading</h2> /* css code */ .focus .heading {font-size:120%; margin:1em;}
The improvement is again quite simple. As we lack a general way to style our headings, we simple add a class to each <hX>
tag. In this case, I added a class "heading" to make it as semantically valuable as possible. It's not an illogical addition at all, as html currently lacks a general heading tag, it just has a few specific heading tags. It's a bit of a drag to keep doing this though, but in the end it does pay off, especially when you want to keep your css and styling as flexible as possible. Everyday work experience has taught me that working like this allows you to answer yes more easily to change requests.
There is one more issue that had me troubled for a while, and which ties in with my way of handling paddings and margins. It's an issue that's typical (but not limited) to the styling of headings. If you apply an equal margin to all elements on the same structural level, you'll run into a problem when you start changing font-sizes on one of these elements when all measures are declared in "em"s. It's normal behavior, but not always what you'd prefer.
taking it one step further
/* xhtml code */ <h2 class="heading"><span>heading</span></h2> /* css code */ .focus .heading {margin:1em;} .focus .heading span {font-size:120%;}
You could of course adapt your margins to accommodate the new font-size, but this means hell when you have to quickly change the font-size later on. So by default I simply add an extra <span>
tag inside my headings. I know it's a completely useless element but it's not semantically wrong, just obsolete. As a plus, you can use if for further graphical styling too.
This is how I currently mark up my headings. It has proved itself (to me) as an effective way of handling things, although you could still run into some css troubles when you are nesting headings within a component. Still, not half as much trouble as I had before with multiple declarations of the same style.
make up your own mind
Be sure to remember that I'm not saying everyone should adapt this method because it is 100% better. It remains a personal preference, whether you like to optimize either your html or your css code. It's just another example of how a few html changes can ease your css worries without completely messing up your semantics.
There will be more to come later, so keep checking back.