html vs css pt3/heading headaches
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.
Comments
Denis
You do know about .focus h2, .focus h3 {font-size:120%; margin:1em} don't you? And leave out that last semicolon, what do you need it for?
Niels Matthijs
I know about that alright, it makes for lengthy selectors, especially when you want to cover yourself against 5 levels of headings. It doesn't improve readability and scanability of your css file either.
And it's very annoying when you have to decouple them later on because something changed in the design. I'd rather not work like that.
The last semicolon is there so I don't need to put it there when I add something in my css file later on. Another thing I find very annoying.
Like I said, I won't care about bits and bytes, so I can just as well leave them in and make my job a little bit easier.
Divya
You know, I used to snigger at designers who used span in the h2 tags. But realisation dawned upon me that it is the most flexible way to accomodate future changes (if you dont need it already).
Terrence Wood
If you are learning CSS please don't follow the advice in this series. Increasing the complexity of the DOM so you have a leaner CSS file is not a good practice. It makes your design harder to maintain, increases payload for multiple page requests and slows down javascript.
It's pretty trivial to adjust heading properties (margins, paddings, line-height) in CSS without resorting to additional spans, and in fact, the example here increases the complexity of both HTML and CSS.
As Denis and others have already noted the examples provided in this series seem to lack an understanding of the "cascade" part of CSS.
Niels Matthijs
Actually, I agree with this. This series of articles is probably written for people who are slightly irritated by the mess css can become when quick design changes are required. Usually they stick with it because adding superfluous mark-up is not done. I'm asking those people to consider the benefits for themselves.
I don't see how it makes a design harder to maintain really. As for the increased payload, you can only convince me with some cold numbers. I'm sure it increases the payload, but I need to be convinced that it has a measurable, negative effect on the user experience. As long as I'm not convinced of that, I can't be bothered at all. Links are welcome :)
Actually, it is not when you're working with margins, as they need to be adjusted in relation to the font size. Consider the following css code:
This is how I work. This allows me to adapt the font-size whenever I want with one single change. If you don't have the span tag you need to put the font-size on the .heading, which will screw up the alignment of the elements. You can of course adjust this with the following formula:
But then, you have to recalculate the value every time someone asks you to change the font size on these headings. If you call this trivial, go right ahead. I call it unnecessary work which slows me down more than it should.
Well, you need to elaborate on this because I don't really see how these examples are linked with the cascading part of CSS.
Terrence Wood
Examples of using the cascade instead of html markup are given by Denis and Jordan.
Niels Matthijs
They are assigning css properties to multiple css selectors in one statement, as far as I understand the "cascading" concept that has very little to do with cascading at all.
I think I explained myself before why I don't like that way of working, but I might dedicate an article to it in times to come, seeing as not everyone seems to agree or understand my reasoning.
Again, it's not a method of working I'd like to keep from people which are starting with css, they should find out about the pros and contras for themselves. But for me, it just doesn't work too well.
Jethro Larson
I'll agree stylesheets can get really mucky over time, but the stylesheet is still one place, the html is all over the place. So if there's a place where your code should get mucky it's the single location.
I don't really see how
Is much more complex than
Also if you're getting to
<h5>s you're probably doing something wrong. having your hierarchy 5 or more levels deep is going to lead to confusion.I also think that having your headings looking the same is a bad idea. Choosing which h tag is important as it creates part of the information hierarchy.
Adding the extra
<span>can be a necessary evil but I don't like to embrace it if I can get away with it. I've done some DOM manipulation with jquery so I don't have to add so much BS. I know I'm choosing between two evils but I like my HTML clean. I still always make the site have a reasonable appearance js disabled.Niels Matthijs
True, although I prefer to slightly mess up a pretty clean place (html) instead of making a complete mess worse (css). Also, when implemented well, the html could be centralized too. But that's back-end stuff.
As for the complexity of multiple selectors for one css statement, the problem isn't really in the complexity of the list itself, but the reason for applying them to the same css statement.
I've received css files where 10 or more selectors were linked to the same statement. If you need to adapt just one of them, it's often not clear what the impact will be on the other selectors.
Same goes for the given example with the headings of the focus block. If you string two or three selectors to the same css statement, there's less binding then just assigning it to a single class. Especially people who are not familiar with the css will have a bigger problem making quick changes, as it's not really clear whether the stringed selectors are really related or are just stringed together for bytesaving.
True of course, but I was talking about styled components which can appear in multiple places in the source. Think a "related links" block that can appear in a right column, but also beneath each content section. If the content is pretty nested, an h4 or h5 are not out of the question, but the styling shouldn't change as the styling of the component is not related to its nesting.
NatalieMac
I've read through your three articles, and I'm not convinced that moving the complexity to the HTML is the correct solution.
First, there is the download issue, however slight it might be to those of us lucky enough to have broadband connections. A user only has to download your stylesheet once and it's saved in their cache. They have to download your HTML every time they view a new page.
Second, I've often found myself in the situation of developing a site that will be maintained by someone else, often someone with little or no knowledge of HTML and how it works. Keeping the HTML simple makes their job easier. They don't have to worry about remembering to add classes or ID's or other things they don't understand to the markup. I've never found myself in a situation where I was turning over CSS for someone with little to no knowledge of the CSS to maintain. Most of the time, the people maintaining the sites don't even know the CSS exists.
I have no problem with adding unsemantic elements such as divs and spans to the markup when they're needed to accomplish a presentation that is difficult or impossible without them.
I think a lot of the problems we have from trying to maintain lengthy and complex stylesheets come from lack of proper planning and commenting in the stylesheets. I've dealt with my fair share of those, and know what a nightmare it is to try and make a small change without knowing the impact it might have on other elements. But I think the solution is in better organized and commented CSS files, not in more complex HTML.