Okay, apparently that wasn’t the rest of the story. In part, that seems to be because I didn’t express what I was trying to say very clearly. In others, it’s because people reminded me of points I should have made, or else brought up good points I didn’t address (or consider). Time for some follow-up.
A few people said “who cares about three/six bytes?” Me, obviously. On many pages, such as the archived entry, it’s not going to be a big deal. On the home page, it will be a slightly bigger deal. On a monthly archive page, it’s common to see twenty or more dates on a single page. There we start to measure weight reductions in tenths of a kilobyte. If I take a similar approach in five other cases, that’s half a kilobyte. It adds up over time, especially when you get several hundred thousand page views a month. The difference is even more fractional when using gzip encoding, as I am. But a gzipped 10.4KB page is still smaller than a gzipped 10.5KB page. It will always be smaller. Why not take the improvement, if nothing else is harmed? (As I believe to be the case here, although obviously not everyone agrees.)
The most common objection to what I wrote is that using b violates “semantic purity”. I disagree entirely. span has no more semantic purity than b, in my view. Both are intended for purely presentational effects. Neither adds anything to the document’s semantics in a fashion that, for example, strong does. So on those grounds, the choice is a wash; neither is any better than the other. The only real difference between the two elements (besides their names) is that b has, mostly by tradition but also by way of description, a default presentational rendering—the text uses a bold font face.
Which leads to the next point, one I forgot to make in the previous post (that’s what I get for writing entries late at night). As I just said, if you use b, then in a view of the document free of author CSS, the text will be boldfaced. That’s exactly what I want in this case; in a browser where an h5 isn’t boldfaced by default, and there is no CSS being applied at all, I’d like the date to be boldfaced. Why? I just do. Oh, sure, I could come up with a rationale like it being important to highlight the entry date in a weblog, but the reasons aren’t really relevant. As the page author, those are the kinds of decisions I get to make. So given that desire, b has another advantage over span for the case I’m describing. In cases where you don’t want the text to be boldfaced in a rendering free of author CSS, then b is actually disadvantageous. There will be inevitable complaints about presentational markup, but in a non-CSS environment, what other presentational influence can I have? None.
It was also pointed out by a few people that I’m over-classing my markup, since I could easily use descendant selectors to get the same results. That’s absolutely true. The classes (title and meta) are more remnants of earlier designs, and have outlived their usefulness. In the beginning, I used the classes because I thought I’d want to use sub-headings in journal entries, in order to break up long posts. (Andrei does this quite a bit, as do some others.) I wanted to be sure that the title and date styles applied only to those particular headings in an entry, and no others. Since then, practice has shown that I never write entries with sub-headings, so the classes aren’t necessary, and in fact my CSS didn’t even need the classes to be there. Thus, I’ve taken out the classes. If I ever find myself wanting to break up an entry into headed sections, I’ll use h6 to do it. So thanks to those who held my feet to the fire on that point.
Lachlan Hunt pointed out that I could save a lot more weight by using UTF-8 characters instead of encoded character entities. True. And if I could get UTF-8 to work, I’d probably try do that, assuming I could be sure the content wouldn’t be mangled in current browsers, a worry I definitely don’t have when it comes to element handling. Lachlan also mentioned that in a CSS3 world, I could use the ::outside pseudo-element to generate another box for styling, instead of nesting one element inside another. Yes, and in an XBL world I could just generate the extra box(es). Until either one or both of those worlds comes to pass, markup is the answer. In this case, I prefer b to span for all the reasons mentioned earlier.
As you might suspect, anyone who doesn’t accept my earlier assertions about markup semantics isn’t going to agree with my markup choices. I’ve no problem with that; note that I never said anything even remotely resembling “b is always better than span“. It isn’t. Neither is span always better than b, as I’ve discussed here and in the previous post. By all means, if you have a deep-seated aversion to presentational elements, then don’t use them. In my world, one avoids using them when a semantic element would better serve the intent. When there is no semantic need, then I figure you should use whatever works best for you. Knowing how to tell the difference between these cases is a big step toward really understanding how to use markup efficiently and well.
