More Markup

Published 20 years, 3 months past

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.

Comments (26)

  1. 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.

  2. It’s definitely hard to order b and span, because they are a few of the pure presentational tags in HTML, but it’s no rule to not use them. I use b for presentational bolds only, and that’s the way it should be used. And it saves a couple of bytes compared to span style="font-weight: bold". And bytes are king.

  3. span has no more semantic purity than b, in my view. Both are intended for purely presentational effects.

    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.

    Neither adds anything to the document’s semantics in a fashion that, for example, strong does.

    That depends on context. In the context of a simple document being printed out, no, span adds nothing. In the context of, say, a bit of Javascript that gives you the option of, say, fixing spelling mistakes in a pre-checked comment, a <span class=”misspelt”> conveys important information to the script.

    The difference between <span> and <strong> is simply that the precise meaning of a <span> element is defined outside of the HTML specification. That’s nothing new – the XFN specification recently released is another example of leveraging generic element types within HTML to convey semantic information… unless you are calling XFN presentational as well?

  4. “But a gzipped 10.5KB page is still smaller than a gzipped 10.4KB page. It will always be smaller.”
    Really? :)

  5. 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?

  6. 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.

  7. 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?

    Table is legal, too, but I’m not holding my breath to hear the pronouncement that it’s OK to overcome deficiencies in CSS when it comes to mapping visual effects to semantic presentation.

  8. 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.

  9. 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!

  10. 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. :-)

  11. 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!

  12. “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.

  13. Hey, be sure to check out http://www.browsehappy.com. Interesting …

  14. 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 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.

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

  16. How about using Markdown for comments, and not allowing markup at all?

  17. 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.

  18. 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

  19. 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 :)

  20. Just some followup on questions posed and comments made.

    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.

  21. 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.

  22. 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.

  23. 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.

  24. 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.

  25. 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, 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.

  26. 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.

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview