More Markup
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.
26 Responses»
Adrian wrote in to say...
Man… I can’t believe how much flack you got over that. I thought it was a pretty well thought out way to do it given your particular situation.
Besides, who cares? As long as it’s doing what you want it to do, and it’s not violating any standards while doing it, then go for it.
Rob Mientjes wrote in to say...
It’s definitely hard to order
bandspan, because they are a few of the pure presentational tags in HTML, but it’s no rule to not use them. I usebfor presentational bolds only, and that’s the way it should be used. And it saves a couple of bytes compared tospan style="font-weight: bold". And bytes are king.Jim Dabell wrote in to say...
Perhaps that is true in your particular case, but it isn’t in general. A span with a class or id attribute simply marks a section of text as being of a certain type, or with a certain label. That’s not presentational. Okay, there are no shared semantics in terms of the HTML specification, but that doesn’t mean that they must, therefore, be presentational.
Greg K Nicholson wrote in to say...
“But a gzipped 10.5KB page is still smaller than a gzipped 10.4KB page. It will always be smaller.”
Really? :)
mogsie wrote in to say...
Jeezz…
The geezers who whine on and on about b vs span… Get a life! Both are legal, and if Meyer uses one or the other is really up to him, isn’t it?
Tramp wrote in to say...
Good grief! Eric, I guess this is some form of flattery. When you are King, they scrutinize your every move, thought, and opinion.
I certainly hope none of this ever keeps you from sharing your thoughts. I appreciate seeing into the mind of a truly creative person who considers the standards as well.
Thank you.
Sandy wrote in to say...
Lachlan Hunt wrote in to say...
Hi Eric,
I hope you didn’t find that article I wrote too critical. From the comments already written to this, it seems the general feeling is that people were too critical in Markup Missive of your use of b. I just want to make sure that you understand the main point of my article was to provide you with some constructive criticism to show other places that could be improved, and not berate you over something as insignifigant as using b instead of span. Although, I have my reason for using span over b, I just want to say that I do respect your opinion, and your right to choose otherwise for your site.
One last point I forgot to mention in my article was that using b does not, in any way limit accessibility; unless it is used in place of other semantic elements, such as strong. So, in the scheme of things, it’s really not that big a deal, though it is still a rather controversial decision.
Eric wrote in to say...
Lachlan: actually, I appreciated your response and didn’t find it too critical at all. This post was mostly about clarifying the points I was originally trying to make, since the first post wasn’t terribly clear about some things. You raised good points that deserved a response, and anyway, if my views can’t stand up to a little pushback then they aren’t worth the photons used to display them.
Sandy: you may not have to wait as long as you think, although it will probably be longer than the three to five minutes it generally takes for anoxia to set in… so keep breathing!
Lachlan Hunt wrote in to say...
That’s good to hear Eric, thank you for your feedback. BTW, your views are certainly worth the photons used to display them. Infact, I’d say they’re worth more than those coming from this cheap monitor I’m reading right now. :-)
Jeff Croft wrote in to say...
Good explanation. The fact that you actually want your text boldfaced in non-CSS views clears up my primary concern.
Now…what about my other? Are b, u, i, etc. going away in future version of XHTML? If so, then I personally want to avoid using them, to future-proof my documents. If not, then I may just adopt them for certain cases.
Thanks!
dave wrote in to say...
“But a gzipped 10.5KB page is still smaller than a gzipped 10.4KB page. It will always be smaller.”
Someone has already commented that you’ve got the figures the wrong way round, but I dispute the fact that it will always be bigger/smaller whichever way you put the figures.
Just as a single color GIF with regular or no patterns can be both large in number of pixels, and smaller in number of bytes than one with complex patterns a web page with more repetition can be smaller when gzipped than a smaller one with less repetition.
I’m just guessing but I think if you only use ‘b’ tags for this purpose then you could actually be *adding* size to your compressed page compared with using ’span’, and ’span class=”whatever”‘ isn’t going to add as much size as you think.
I vote for more characters in the name of clarity, as your reasoning reminds me too much of old-skool programmers still mentally stuck in the 80s who forget that humans are often the weakest link in the chain these days.
Eric wrote in to say...
Hey, be sure to check out http://www.browsehappy.com. Interesting …
Seth Thomas Rasmussen wrote in to say...
Mogsie, it’s not simply about what’s legal… that’s such a simple approach. That’s like when people justify being a jerk because they are allowed to. It’s not about what’s allowed, it’s about what’s a better practice. Not that I’m criticizing Mr. Meyer’s practices, just illustrating a point.
I’m glad Jim addressed the problems with your statements comparing
bandspan. Surely your initial statements were made in haste, Eric? I can’t quite fathom how they might hold up under further scrutiny.Chris Biagini wrote in to say...
Amusing that their layout is mangled in Safari, but works in IE.
<p class="first">, wrapped in a<blockquote>, which, in turn, is wrapped in a<div>. Sweet. It expands with the text, so I guess that’s kinda good…Chris Biagini wrote in to say...
How about using Markdown for comments, and not allowing markup at all?
mogsie wrote in to say...
Ok, Seth I might agree that using span is a better practice than b… Think of how we all would shudder at the thought of the css zen garden being tagged with b instead of span. (The zen garden also illustrates Eric’s point of span being purely presentational.)
Well, instead of using b or span, we might just use
<h5><meyer:date xmlns:meyer="http://www.meyerweb.com/mine/allmine">Tuesday, 24 Augu...which we can all agree upon has the same semantic value as span: none.Laurens Holst wrote in to say...
jgraham wrote in to say...
Eric wrote in to say...
Just some followup on questions posed and comments made.
I don’t know. There have been promises along those lines, as there have been promises to do away with the
styleattribute andh1throughh6. Time will tell. In the meantime, if you’re using current XHTML versions, or HTML for that matter, thenband its ilk will always be valid. You only have to worry about their presence if you convert documents to a (hypothetical) future XML language that doesn’t include such elements. You could at that point either transform them to some other element, or strip them out entirely.Tommy Olsson wrote in to say...
Not really.
bhas no semantics, it only hints that its content should be rendered in a bold face, without any explanation why.strongon the other hand, says that its content should be strongly emphasised. The fact that most browsers render it in a bold face is incidental. With a screen reader, the difference could be very noticeable.I’m not going to argue against Eric’s use of
b. It’s probably a good thing to do, since he wants the date to be boldfaced (not emphasised) when style sheets are off. Having said that, I would probably have gone with aspan, but that’s just because of personal preference.jgraham wrote in to say...
(emphasis mine)
It’s the difference between “could be” and “is” that’s interests me. Are there any UAs that actually treat the elements differently? If not, in what sense do they have different semantics? Now I agree that one should use
strongwhere one means strong emphasis since there might be some UA that makes some tiny distinction between the two. I’m just noting that in the “real world” every UA I’ve ever encountered handlesbjust likestrongand so the idea thatbis just likespanexcept when rendered by a visual UA without stylesheets is inaccurate.Jim Dabell wrote in to say...
That’s incorrect. There are a number of search engines that weight keywords found within <strong> elements heavier than keywords found within <b> elements. Why wouldn’t they?
Of course, even if no user-agent on the planet distinguished between them, that’s no excuse to mistake one for the other when authoring
jgraham wrote in to say...
mpt wrote in to say...
This is just “When semantic markup goes bad” all over again. It’s reassuring to see that Eric’s on the same page. (So to speak.)
Jeff, yes,
bandiare currently supposed to go away in XHTML 2.0. But that’s only a problem in the unlikely event that you ever use XHTML 2.0.David House wrote in to say...
You have to have at least three occurances of the hook per page to save on the 20 bytes you waste with the font-weight: normal (3 occurances, not 4, as you save on the selector). That is, of course, if you don’t cache.