Jeff, yes, b and i are 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.

That’s incorrect. There are a number of search engines that weight keywords found within <strong> elements heavier than keywords found within <b> elements.

Ah. OK. I take back the assertion that all UAs treat them equivalently. I stand by the point that, in practice, b is at least likely to be interpreted with semantics (usually like strong) as without semantics (like span), despite the specifcation indicating that it has no semantics.

Why wouldn’t they?

Because many, many sites use b where they really want em or strong. UAs, almost without exception, value real-world compatibility over spec-compatibility.

that’s no excuse to mistake one for the other when authoring

I’m absolutely not arguing you should use b when you mean strong. I’m arguing that the assertation that b has no semantics is untrue in practice since many UAs assign it the same semantics as strong. It’s a reason not to use b, not a reason to use it. Perhaps my use of the word “interchangable” was misleading. Sorry if I haven’t been clear.

As far as I know, in every UA on the planet b and strong are totally interchangeable, i.e. in practice they have the same semantics.

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 – user-agents change all the time (especially Google), so even if no search engines understood that keywords are more important than keywords today, the same might not be true tomorrow.

I’m not referring to Eric here; he obviously understands the difference between them.

The fact that most browsers render it in a bold face is incidental. With a screen reader, the difference could be very noticeable.

(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 strong where 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 handles b just like strong and so the idea that b is just like span except when rendered by a visual UA without stylesheets is inaccurate.

As far as I know, in every UA on the planet b and strong are totally interchangeable, i.e. in practice they have the same semantics.

Not really. b has no semantics, it only hints that its content should be rendered in a bold face, without any explanation why. strong on 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 a span, but that’s just because of personal preference.

Are b, u, i, etc. going away in future version of XHTML? (Jeff Croft)

I don’t know. There have been promises along those lines, as there have been promises to do away with the style attribute and h1 through h6. Time will tell. In the meantime, if you’re using current XHTML versions, or HTML for that matter, then b and 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.

Surely your initial statements were made in haste, Eric? I can’t quite fathom how they might hold up under further scrutiny. (Seth Thomas Rasmussen )

On the contrary, my statements on this topic were made after years of thinking about markup– over a decade now, actually, although I’ve taken such considerations seriously for perhaps only two-thirds of that period. At this point in the present discussion, if you don’t think my statements stand up to scrutiny, then there’s likely nothing I can do to convince you otherwise. That probably sounds defensive, but it’s actually delivered with the equivalent of a shrug and a smile. It’s not imperative to me that everyone fall into total agreement, either with my views or with others, and in fact I believe there are multiple right answers in this area.

I wrote these posts because I think these are markup-use issues that ought to be explored. I’ve presented my view, with supporting evidence and arguments. Others have presented their views. At least now those who are learning can consider both views, and make their own informed decisions.

As for <b>: as my site has an XHTML 1.1 Strict doctype it is very simple, I just can’t use it (Laurens Holst)

Yes, you can. XHTML 1.1 has but one document type (effectively Strict) and it contains a presentation module that itself contains b and similar elements; see http://www.w3.org/TR/xhtml11/doctype.html#s_doctype for an overview. The module isn’t even deprecated. I’m not recommending you use the elements in the presentation module, but they are there.

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.

As far as I know, in every UA on the planet b and strong are totally interchangeable, i.e. in practice they have the same semantics. Perhaps someone who is more familiar than I with the workings of non-visual UAs and, in particular, aural browsers and search bots could help with more details on this but it’s certianly my experience that even UAs that can’t render bold text interpret b as denoting special emphasis. So asserting that b has the semantics of span rather than the semantics of strong isn’t really consistent with actual user experience and, given the requirments of backward compatibility, is unlikely to be the case in future UAs.

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.

And if you’d never had to write about the issue, that would save quite a lot of bandwidth. Not changing your heading graphic would save a few more kb. You could only provide a single RSS flavour for a saving of ~100 bytes per page. You could strip comments or unnecessary whitespace out before the page is published. You could use a more abbreviated class-naming scheme. Looking at your markup, it’s pretty clear that you don’t, in general, care about saving the tiny amounts of bandwidth we’re talking about here. So I think that’s a pretty spurious justification to use here.

That said, I don’t really care if you use b. I don’t think it’s particularly great markup but the differences we’re talking about are tiny; maybe a slight increase in the weight given to entry dates by search engines, maybe a slightly odd rendering by aural browsers. I disagree much more strongly with the use of h5 headings for the entry date since the date isn’t a subheading of the article heading but part of the same heading; they should share a h4 element and the date should be in a seperate div. But that’s a different topic :)

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.

I really wouldn’t worry about browsers… I’ve never heard about nor seen any browser not being able to handle UTF-8.

As for <b>: as my site has an XHTML 1.1 Strict doctype it is very simple, I just can’t use it :). And I must say, I didn’t miss it for a single second. When I’m going to seperate style from content, I’d better do it properly.

Btw, I don’t agree with the whole ‘span is a presentational tag’ thing. I use spans to add additional semantics, such as <span class=”file”> for filenames which will get a different presentation to the user. The HTML spec offers a nice lot of semantics, but if you look at the available tags you’ll notice that they’re mainly technical writing-related tags, so sometimes you have to come up with your own semantics.

Finally, if span were presentational, then why isn’t it deprecated :). And if one uses an occasional span purely for markup purposes – well, at least it’s fully transparent. Nevertheless, I guess I could amend my position on this a little – for example, if you would want to give filenames emphasis, but a different kind of emphasis than usual, I agree that <em class=”file”> might indeed make more sense than using a span :). It’ll also degrade better. OTOH, then there’s two parts to remember – both the class and the fact that I’d have to use it on an em. Ugh ^_^.

~Grauw

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.

<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…

I’m glad Jim addressed the problems with your statements comparing b and span. Surely your initial statements were made in haste, Eric? I can’t quite fathom how they might hold up under further scrutiny.

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.