html vs css pt2/navigation lists
Last time I talked about the balance between html and css, today it is time to give you a solid example as to illustrate my point. Hopefully this will clear up any remaining doubt left from the first article. This article will take a closer look at navigation lists and how an extra span + optional extra class can make our css work easier.
navigation lists
/* html code */
<li><a> nav item </a></li>
<li class="active"> nav item </li>
/* css code */
li a {display:block; padding:0.5em;}
li.active {padding:0.5em;}
Navigation lists are a drag to style. Semantically, navigation items fit very well inside a list, but getting them to behave in a horizontal manner isn't easy when you're starting out with css. It gets worse when someone tells you that active items shouldn't be clickable. I know this way of thinking isn't generally accepted, but imagine having to code the navigation list like this in our example.
The problem we're facing is the disappearing <a> tag. Active items (or disabled items for that matter) are usually similar in styling,
only differentiated by color or other graphical tuning. But the margins and paddings on such elements remain the same, as they should fit in with the normal navigation items.
This issue is most apparent when the whole area of the navigation item should be clickable (display:block on the <a> tag), leaving us no
choice as to apply the padding on the <a> tag.
The css provided above is annoying, because we have to repeat the padding value for both active and disabled items, as we lack a structural element to apply it to in case of a disabled link. If the design changes, we have to make sure we adapt both values. css code like this leaves us right open for errors, it litters the css file and makes it quite a bit harder to maintain.
improved code for better css handling
/* html code */
<li><a class="item"> nav item </a></li>
<li class="active"><span class="item"> nav item </span></li>
/* css code */
li .item {display:block; padding:0.5em;}
/* css code alternative */
li a, li span {display:block; padding:0.5em;}
And yet, this issue is pretty simple to fix, it just requires you to adapt your html code a bit. First I replaced the missing <a> with
a <span> tag. It keeps the code structurally consistent (which is a tiny plus) but introduces a semantically useless span element (shame but
I can definitely live with it).
I've also added a class="item" to both <a> and <span> tags, which keeps my css
as clean as can be. You can just as well leave it out and use the alternative css notation I provided. I'm not a big fan of writing css like that, but I know quite a few of
you are and since it's not really crucial to the point I'm trying to make I decided to add it just as well.
Whether you add the extra class or not isn't important, what matters is that we reduced the css code and even more importantly, lifted repetitive code from our css without making any semantical concessions in our html code. The only thing we did was add a useless structural element. If you ask me, that's a small price to pay.
more to follow
I hope this example has been clear enough to illustrate what I'm talking about. It's a first in a row of small improvements I'll be documenting. html purists probably won't
like the idea of adding useless elements to their code, I on the other hand don't mind as long as it doesn't semantically hurt my html. I believe that the css improvement
here is considerable enough to warrant the extra <span>. But be sure to make up your own mind!
Next time we'll be looking at titles, and how an extra class can ease your css worries a tiny bit.
article info
visitor stats
article section stats
(80/...): stats for article in this blog section
article global stats
(.../90): stats for article in all sections
articles in html practical
blog archive
All my articles are neatly filed inside the archive. Search and filter your way to the article you like:
contact me
If you want to leave me a quick message or you have any questions, drop me a note.
OK, gotchya now. ;) My aim is to use as little mark-up as possible to get the job done but if a particular design or effect or the need for increased flexibility requires the use of some extra elements, I don't have a problem with using them as long as you don't get carried away with them.
A classic example is my preferred image replacement method - the Gilder-Levin technique - which uses an empty span (or other inline element) inside the element being replaced. Sure the empty element's not really doing anything but it means that the technique ticks most of the boxes from an accessibility point of view.
What I tend to do in this situation, rather than add the superfluous
class="item", is to mark up my list as simply as:<ul class="navigation"><li><span>current item</span></li><li><a>item 2</a></li><li><a>item 3</a></li></ul>...and then add an extra contextual selector to my CSS file, such as:
.navigation li a,.navigation li span {
/* styles for list items go here... */
}
This method allows you to save a fair few bytes in extraneous markup, plus you can even skip the
class="active"on the link to the current page.Well, I've considered working like this, but I had some serious reservations. As for leaving out the item class:
I don't like linking multiple css selectors to one batch of statements. It makes my css file harder to read and it's a drag when you have to somehow unlink them afterwards when design changes are made (and the two can't be linked to the same batch of statement anymore).
There enough cascading as it is. In the example you're given, you still need to declare the separate css properties for both a and span tags, which makes it more difficult to piece everything together from the css file.
As for leaving out the active class:
I like the ideal of microformats, where a class gives extra semantic meaning to an element. The active class does just that. By leaving it out, you're taking that away, and you're giving the span tag the meaning of activated item. This is purely an implied meaning which is not deductable from the piece of html code.
This will become a problem when you have navigation that has other items which are not linked but are not active (disabled items in an a-z index for example). To keep things consistent, we decided to keep the active class there instead of moving it to the span tag.
Like I said in my first article, this string of examples is here to ease the css at the expense of lesser trimmed html code. In your case, you're making the html slimmer but you're making the css more difficult. I understand why people do this, I just simply don't agree with this way of working.
Furthermore, I really can't be bothered about bits and bytes. :)
Thanks Niels, I enjoyed this article. I'm one of your HTML-purists, but your use of the extra
<span>tag doesn't offend at all. It's perfectly in keeping with what the HTML Recommendation says it's for: "a generic mechanism for adding structure".Like Jordan, I would ditch
class="item". Semantically speaking, it amounts to tautology. (Remember that<li>stands for "list item".) I appreciate your stated goal of leaner CSS, but lean HTML is just as worthy. The repeateditemclass attributes clutter the place up, I think.However, I agree with keeping
class="active"in order to provide meaning. I don't see why you wouldn't want to move it to the<span>tag, though...?Likewise, you might create a class to explicity describe list items that are disabled or inactive. Assuming that disabled items are in a minority (as say, "Q" might be in an English A-Z menu) then it won't require many extra class attributes.
So, here's what I would use:
p.s. I hope I get the markdown correct - first time I've used it.
I don't know about this. The
spanhere has the function of a wrapper, and a wrapper doesn't really add structure to your document, it simply wraps an already singular container. I think adding structure means separating or grouping several elements which weren't before. But that could just be my interpretation.I know the class has "item" has little to no semantic meaning, I'm still looking for a better name. I also realize this way of working is a little weird. But it does allow me to style things separate from their html implementation, which can be a real plus.
To give you an example of this, not too long ago I had to design a horizontal navigation which featured an extra introductory text on the home page of the site, beneath each link. In this situation, the
spanturned into anh2, but the styling remained perfect without extra workIt's a shame the site isn't online anymore, but the thing I'm trying to say is that it's not bad to design your css to be as future proof as possible. Even though html and css are firmly coupled, I think styling on html elements is not always a wise thing to do, as visual design has little or nothing to do with html semantics.
Among other reasons, it gives you more options when you are styling the active element. If you put the "active" class on the list item, you can style two elements instead of one. Sometimes this comes in handy.
Also, if you look back at the example I talked about earlier, extra elements might be included inside the list item, and they are also "active". So putting the class on a
spanis a tad limiting.And one last thing. A lot of these decisions are based on flexibility and consistency. We work with a few external partners who implement our code, so keeping our code consistent and predictable is an important issue. From that point of view, I always try to reach a flexible solution with as little clutter as possible. And sometimes, a little clutter can make your life a lot easier later on :)
* required fields