Markup Missive

Published 20 years, 3 months past

In a previous post on heading levels, I used some of meyerweb’s markup as an example.  In that markup, an apparently useless <b> element appeared.  Here’s the markup: 

<h4 class="title"><a href="…” title="…">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>

In that post, I also said:

And yes, there are b elements in my markup, and I’m doing that on purpose.  I’ll talk about it some other time.

So now it’s time.

The boldface element is actually a holdover from the previous designs of meyerweb.  You can still mess with them on the theme example page, if you like.  The original idea was to provide an inline element as a hook on which I could hang some styles.  For example, if I wanted to put the date in a box that exactly surrounded the date’s text, but no more than that, I’d need an inline box.  Therefore, I could either style the <h5> element to generate an inline box, or I could have an inline element there for styling purposes.

In the first case (inlining the h5), I’d lose the block box that the element generates by default, thanks to the browser’s built-in HTML styling.  That might be okay in some cases, but more often than not it would be a problem.  Inline boxes accept a limited set of properties, and putting an inline box between two block boxes is generally a recipe for funkiness.  So that left me with the second case, that of adding an inline element.  As an added bonus, doing so gave me two elements (h5 and b) to style, if I wanted them both.

Here’s the CSS that applies to the date headings and their boldface elements: 

#thoughts h5 {font-size: 1em; line-height: 1em;
  margin: 0 0 0.5em; padding: 0; color: #CCC;}
#thoughts h5 b {font-weight: normal; font-size: 0.9em;}

Although I’m not doing much with the b element, style-wise, what I’m doing is useful.  First, there’s making sure the font weight is normal, and not bold.  All right, that’s not really useful.  Second, the boldface element is used to reduce the size of the date’s font by a small amount.  I use the b element to reduce the size of the font because that leaves the element box of the h5 alone.  In other words, its text box is not reduced, which means it’s consistent with the text around it.  If I ever go back to a design where the date and title are “on the same line” and lined up with each other, as was the case in many of the old designs, I won’t have to do weird fractional math just to make it happen.

Of course, in the current design, that isn’t an issue.  So in a sense, the b element is sort of a vestige from an earlier stage in the site’s evolution, like a markup appendix.  The only difference here is that the b element might become useful again, whereas I don’t think the appendix has much chance of a comeback.

The other expected question is why, if all I wanted was an inline element as a styling hook, I used a b instead of a span.  Simple: the element name is three letters shorter, so for every hook, I’m saving six characters.  If there are, say, twenty such hooks on a page, that saves me 120 characters.  It’s a small consideration, but by such incremental savings are document weights reduced.  “What about semantic purity?” you may ask.  In my view, b and span have the same semantic value, which is to say basically none.  They’re both purely presentational elements, with the difference that span doesn’t have any expected presentational effects in HTML.  So I used the presentational hook that made the most sense to me: b.

If my goal was to emphasize the date, then I’d have used em or strong, but it wasn’t.  I just needed a hook, at least once upon a time, and that was the element I chose as my hook.

And now you have the rest of the story.

Comments (40)

  1. Eric,

    why not a span with a descendent selector #thoughts h5 span, or maybe a span with a class, span class=”entry-date”?

    john

  2. John, from the post:

    Simple: the element name is three letters shorter, so for every hook, I’m saving six characters.

    I thought that was fairly clear… and adding a class to the hook would make things even worse, from a document weight standpoint.

  3. Eric,

    should have read it more closely, but really, is it necessary? For three characters?

    j

  4. …but really, is it necessary? For three characters?

    As I tried to show in the post, there’s no disadvantage to using the b in this situation, and in fact there is a small advantage. So I see no reason why I should use a span in this case when it would offer me nothing of value over the approach I took. That was in fact the whole point of the post, which I made because a few people raised the question when I was writing about headings back in July.

  5. OK then,

    I guess my point is that what we learnt over a long period of time in software engineering is to be very careful with names. Once upona time, memory space was very expensive. As a consequnece, "i" was twice as good a variable name as "in", for instance.
    For a very long time after that, and even to this day if you look at a lot of people’s code, you’ll see that such obfuscating names for variables are considered absolutely fine. But they aren’t. It requires considerable cognitive effort when reading other people’s code to determine what variables are for, and even when debugging or maintaining one’s own code. I much prefer to see "interestRate" as a variable name to i.

    While of course yours is a trivial example, the fact that you have been required to explain a naming choice (actually its a bit more complex than that but that will do for now) means that it is non obvious to quite a few people, and would pose maintenance issues. People are very reluctant to change what they don’t quite understand, for fear that there will be unintended side effects. so the b would stay as a legacy for a long long time.

    in fact, your "b" element is not a <b> element at all. As you say it is just a hook (actually you could argue that it is a surrogate for a semantic element that is equvalent to span class="date-entry").
    So a span would offer a number of benefits over a b element. It would instantly be less confusing to most developers, particularly if a class were used, by making the semantics of the markup explicit. I tend to subscribe to the smokey bear approach to semantics, "where you see style there’s sure to be markup" (apologies for reference to obscure 70’s cartoon) so why not make it explicit?

    Yes, it is a nit pick. Jeffrey is probably going to be rolling his eyes about it. But I guess document markup is like many technical endeavors, the devil is in the detail.

    john

  6. There is another practice in programming that it something of an analogue to Eric’s use of “b” in a small context. The rule of thumb is to (generally) use longer identifier’s for named enties with greater scope, and shorter names for variables with smaller scope. Shorter names – when the scope is small – tends to make the code easier to read.

    In this case “#thoughts h5 b {font-weight: normal; font-size: 0.9em;}” is used by only a small scope, and makes a relatively subtle change to formatting.

    Heh – even the CSS rule is an example in the same vein. Formatting the entire rule on a single line can be more readable, but only when the number of attributes are few.

  7. Isn’t the element box left alone because of the ‘line-height’ property? It would be new to me if ‘font-size’ has anything to do with it.

    (Using B, I or A over SPAN makes perfect sense by the way, maybe I should make some changes as well.)

  8. In a team environment, where 3-4 people are supposed to edit the same JSP, PHP or ASP file, where server-side code is also mixed-in, the kind of general assumptions like (“use span to style inline elements”) are pure gold!

    There’s no way for me to brief my team on each and every little convention I come up with (span -> b) so I might end up with people removing the <b> or worse.

    “Syntactic stereotypes” are useful!

  9. Wait a minute… weren’t you chastising me for using floats incorrectly a month back?

    Hmmmmm…

  10. Actually, it is semantically correct to use a <b> in this instance. While the <b> tag implies bold, according to the w3c spec it is classified as a font style element. Hence a browser, while going against common convention, could display b as italic and vise versa and still be standards compliant. Use of a phrase element (such as <em>) would be much less appropriate.

    As for <span> vs. <b> as has been pointed out span has absolutly no meaning, where as <b> clearly designates a difference in font style.

    Personally I am sick of the “dumb” developer excuse for taking the long way … Anyone fit to edit my code can easily figure out the meaning of a bold tag nested in an h1 tag … for starters its not a common thing to see.

    Don’t think I’m against proper naming of classes and id’s, I am the CSS naming nazi of my workplace! I just feel there are appropriate ways to attack these issues and to avoid font tag like storms of attributes.

  11. Let’s see… You have class=”title” on the header wich is obviously title, and then class=”meta” for some other reason. And then you decide to save on using <b> instead of class.
    Options:
    a) to review everything and try to get by using descendant selectors, context, whatever.
    b) define class .b and then have class=”meta b”. See you save 5 more characters here.

    Somehow I feel all those classes are not needed at all, but I may be wrong.

    Anyway that b does not look good here. Maybe there is no reason for you to go through your pages traying to dig up all entry dates, but
    class=”date” would make that much easier, wouldn’t it?

  12. Gabriel, Rimantas, < b > is allowed markup in these comments :) Allowing markup in comments is an easy way to make sure your pages don’t validate. But the error is drowned on the validator results page by the errors caused by the two erronous /> which wordpress adds to meta elements. Sorry for this off-topic remark!

    On topic: I think saving a few bytes is not important. I don’t mind using B and I, but only when it actually makes sense in an unstyled version of the document. IMHO, B and I have some semantic value, telling the browser that the content is somehow different from the other content. In Opera’s SSR for example, and I guess in Lynx as well, B and I are still visually different, while < span style=”font-weight:bold” > will have no visual effect. So in many cases, it actually makes sense to use B and I.

  13. Hmmm.. anything with pointy brackets is simply removed for these comments if it is not allowed markup, even if I seperate them with spaces :( The ‘HTML allowed’ above this comment field made me forget to read the note below :)

    I meant to say:
    “B and I are still visually different, while <span style=”font-weight:bold”> will have no visual effect”

  14. Don’t mind me – just closing that open <b></b> from comment #8.

  15. Ah well, I tried.

  16. I think there were two b tags opened. Maybe this one’ll close the second and set things right.

    I think using the b tag makes pretty good sense. Where it’s not congruent with the “i” vs. “interestRate” example is that “i” is undocumented anywhere while “b” may very well be documented in a style sheet. If you run across a “b” tag in code but it’s not bolding the text, your first thought is to check the style sheet, where you’ll see that it’s being used to style the text differently. Drop a comment in your style sheet saying “b’s three characters shorter than span” and you’re golden.

  17. Andrei:

    Wait a minute… weren’t you chastising me for using floats incorrectly a month back?

    No. I never said your use of floats was incorrect, as a re-reading of the post in question should demonstrate. I simply said that floats, having been bent to a purpose for which they weren’t intended, aren’t as well-behaved as we might like in such a circumstance. And I never chastised you. The post was one of sympathy, not admonishment, although it now seems that wasn’t clear.

  18. I don’t mind using B and I, but only when it actually makes sense in an unstyled version of the document.

    Here lies the crux of the matter for me. I feel it’s wrong to use B, because unstyled, it will appear bold on the page. A span won’t, hence that’s what you should use.

    I’ve more to say on this issue in my recent article Writing Clean Code.

  19. Actually my article seems to side with Eric! To clarify, I’d use a span only because it has no default style, so it matches Eric’s CSS of ‘font-weight:normal’ (not bold). But going by my article I would suggest using the SMALL tag, as text inside it will also appear smaller when styles are turned off, and smaller text is the effect Eric wants.

  20. Trackback ::

    Lachy's Log

    CSS Guru Explains A<b>use
    The document weight may be reduced, but there are other ways to do that without sacrificing semantic purity. The problem is not the fact that it has no semantics, but the fact that in visual user agents, it portrays semanics that it does not have.

  21. In my view, b and span have the same semantic value, which is to say basically none.

    I agree with you completely, Eric. I’m trying to write up a script to syntax-color code examples on my site, and I’m using <b> tags just as you are. Sometimes you just need a few short, semantically meaningless tags. You can only separate content from presentation to a certain degree.

    I’m not sure why the W3C decided to make HTML so wordy. For an plain span, what’s wrong with <s>? For styled spans, <span class="foo"> is a pain to write (escaping quotes in scripts) and a pain to read (takes up too much space!). What’s wrong with <s.foo> for classes, <s#foo> for IDs?

    the fact that you have been required to explain
    a naming choice (actually its a bit more complex
    than that but that will do for now) means that it
    is non obvious to quite a few people, and would pose
    maintenance issues
    …
    It would instantly be less confusing to most developers,
    particularly if a class were used, by making the semantics
    of the markup explicit.

    Maybe so, but there’s got to be a tradeoff between code readability and code writability. You wouldn’t want to write Photoshop in Applescript, even though the Applescript would be more readable.

    Besides, it doesn’t really take a whole lot of explanation, and I’m sure everyone’s probably smart enough to figure it out anyway. If you see <span style="date">, you’re going to look at the stylesheet to see how he styled it. If you see <b>, and the thing’s not bold, you’re going to…look at the stylesheet to see how he styled it!

    Maybe I’m missing your point though…am I making any sense?

  22. So as I understand it, it all depends on what the meaning of the tag “<b>” be?

  23. Perhaps I am wrong, but I was under the impression that b, u, i and the like were being deprecated in future version of XHTML. If that is the case, then I think it makes sense to avoid them now, in order to be more prepared for future DOCTYPEs. If I’m wrong, then I take no issue with your usage, but I still prefer span. I guess I just value the appearance of my site in Lynx (or other unstyled view) more than saving three characters of bandwidth.

  24. Chris: because <s> is already used for strikethrough.

    Anyways, I don’t agree on this subject :). First of all because b has a specific style attached to it which you have to explicitly disable in your stylesheet, and it will show up weird on user agents not supporting styles, as Jeff nicely pointed out ^_^.

    And if you really worry about bytes – why the hell are you using a text-based markup language :) (not that there are any real alternatives) (compiled HTML, that would be something). Especially in this day and age of broadband internet connections and table-ridden web pages I don’t see the point in saving 6 bytes.

    ~Grauw

  25. Chris,

    If the user agent sets “accepts: gzip” (something like that) in the header it sends to the server, then the page will be compressed. If there are lots of spans and classes they won’t take up so many bytes on the wire.

    Laurens, For cell phones there is at least one standard for transforming XML to a binary representation of the document tree. Cell phones I suppose would have found it a problem to have gzip decoders.

  26. “The post was one of sympathy, not admonishment, although it now seems that wasn’t clear.”

    Sorry… I forgot the smiley on my comment… I was sort of ribbing you back, in sympathy as well. I use this semantic trick all the time, with b and em tags mostly. For precisely the same reason.

  27. Trackback ::

    Legends of the Sun Pig

    I love <b>s
    It’s a gaming/semantic markup crossover pun. Trust me, it’s funny.

  28. “I feel it’s wrong to use B, because unstyled, it will appear bold on the page.”

    Look at the context – it’s inside a >h5< . That’s going to render bold when unstyled anyway (which is why, I suspect, Eric chose to use the tag in the first place).

    I think it’s OK to do this kind of thing on your blog – you’re the only one who has to manage the code. In professional sites, where there are (potentially) multiple people involved, I’d use something more transparent.

  29. Pingback ::

    Lachy’s Log » Blog Archive » Semantics of <span>

    […] se of these elements, where span would ordinarily do the trick. Eric Meyer has previously explained his use of the b element as a presentational […]

  30. Hang on here, you mentioned the possibility of just setting the heading elements to inline, which would save you the hassle. I don’t see what could possibly stop you from just using that in conjunction with the metadata class you reserved for that occasion? If you limit it to that class of headings, wouldn’t it cut out the need for any ambiguous inline child elements whatsoever, as well as reduce the number of required CSS rules?

  31. Oh, wait, nevermind, I guess I forgot that, like you said, problems would arise if you did that with the heading tags – I mean, they wouldn’t have linefeeds separating them, for one thing! You’re right in that an element, of course, can’t have a split personality… I don’t know why I overlooked that there (except that I actually knew about it; I just seemed to think for a moment that, “Hmm, if you just limit it to the H# elements of that class, it’ll be okay…” — when it wouldn’t, alas, be “okay” in any circumstance.

  32. Damn, my late night/early morning grammatical logic sense is considerably more sluggish than during the day… Luckily, there is no validator or parser of any kind that would scold me for not closing a bracket (or “parenthesis”, if you want to get all American and pseudo-technical in contrary to my under-respected British dialogue :P). Ah well. I guess I should probably train myself to cut down on my usage of them, anyway – well, definitely the amount of content I wrap inside the things…

  33. And in a final end to my rambles, folks, let me just clarify in yet another off-topic post, that I was referring to the presence of so-called “parentheses” within a string literal… Anyway.

  34. Pingback ::

    CSS Guru Explains A<b>use - Lachy’s Log

    […] he mentioned the use of a <b> element within his markup. He has finally written his reasons for doing so.

    In Eri […]

  35. Pingback ::

    Is it ok to use span? at Advanced CSS Design Resources - last-child.com

    […] If the content is not more important than the text around it, a span is a better choice. Eric Meyers prefers to use the non-semantic <b> tag, which adds style but no […]

  36. Pingback ::

    The Semantics of <small> | Unfortunately Paul

    […] Markup Missive […]

  37. Pingback ::

    uwMike » Archive » CSS Rulers

    […] I’ve used the <b> tag simply because it’s shorter and tighter than inserting spans. Since the bold-tag has been de-commissioned in favour of strong, why not take advantage of it as an inexpensive styling hook? […]

  38. hi my name is robert. i am web designer. now i am facing with some problems in css while working on xhtml pages. it’s about the standards.
    how we can reduce use of classes, ids and div tags if the site is filling with small icons headers text blocks and samll images dropdown lists. i need some examples in which default element tags are extensively used. there by we can reduce div tags and classes inside the html pages

    regards

    crs robert

  39. Pingback ::

    Simple Round Corners in CSS (revisited)

    […] the corners but if you wanted to reduce mark up you could use a nested “b” element as suggested by Eric Meyer (although its use for background images is not likely to be very semantic). Using a nested b […]

  40. Pingback ::

    Simple Round Corners in CSS | Ajaxonomy

    […] the corners but if you wanted to reduce mark up you could use a nested “b” element as suggested by Eric Meyer (although its use for background images is not likely to be very semantic). Using a nested b […]

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