A while back,Eric Meyer wrote an article regarding heading levels in which he mentioned the use of a <b> element within his markup. He has finally written his reasons for doing so.
In Eric’s current design, they are not much more than a left over from a previous design. He states:
The boldface element is actually a holdover from the previous designs of meyerweb. … The original idea was to provide an inline element as a hook on which I could hang some styles.
Then he goes on to explain how he’s using it to apply some styles which would not work well had they been applied heading containing it. No-one has complained about the usefulness of having an extra element to play with for styling purposes; however, most of us would have used a <span> element instead. But eric defends his decision by saying that:
… 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.
The document weight may be reduced, but there are other ways to do that without sacrificing semantic purity. For this, I did a little experiment. I saved the markup for this the article (after 10 comments). Firstly, I converted the document to UTF-8. After saving the document as UTF-8 character encoding, excluding the BOM, this required changing all the character entities used in the file to UTF-8 character encodings. Each entity changed was documented in this comparison chart. This documents, for each entity, the Unicode character name, Hexadecimal character reference, original markup entity used, original byte count, new markup, UTF-8 Hexadecimal bytes, new byte count, saving per character, number of instances of the entity and finally, the total savings for the document. In total, this added up to 439 bytes. Afterwards, the <b> elements were converted to <span> elements. There were two in this document, totalling an additional 12 bytes.
Note: There were originally 2 additional opening tags, with no closing tags for <b> elements. However, these were in the comments and were meant to be encoded using < and >. Thus, these two markup errors were corrected before this experiment was started
Following this, the markup errors resulting from the XML syntax used on empty elements were corrected. There were a total of 23 errors of this kind in the document, each comprising an unnecessary space (U+0020) and solidus (aka. slash – U+002F). This removed an additional 46 characters from the files.
The sample files after these corrections were made are available. The markup errors were corrected in all files because the main focus of this file size comparison is about character encoding savings and the use of <b> instead of <span>. The files are:
| Example | Encoding | File Size (Bytes) |
|---|---|---|
| Example 1 | ISO-8859-1 | 22,375 |
| Example 2 | UTF-8 using <b> |
21,936 |
| Example 3 | UTF-8 using <span> |
21,948 |
That is a saving of 427 bytes. Additionally, by checking the HTTP response headers, it’s easy to see that the documents are being served as compressed using gzip encoding. When using gzip, the small amount of bytes saved by using <b> over <span> is miniscule compared with that achieved by using gzip. For that article, the original file size was 24,576 bytes (as served from meyerweb including markup errors). The Content-Length indicated by the HTTP response headers is 7726. Thus, even the file size saved by converting to UTF-8 is small by comparison, but much more than the difference of using <b> instead of <span>
Also, I should point out that many have commented that Eric has used a superfluous number of classes throughout his markup. I’m not going to judge his use of classes because it would take far too long to analyse how and why each class is used. I just wanted to point out that removing some could also reduce the file size.
“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.
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. It relies on style sheets to remove that perception so that the semantics of actually having no additional semantics is perceived (well, that is, not perceived) correctly by the user in the absence of stylesheets. Thus, the use of stylesheet in this case is, in a kind of backwards way, being used for semantic purposes. This, as everyone should know, breaks the rules of separating structure, content and presentation.
Finally, in an ideal, CSS3, non-IE world; he could use ::outside to provide the extra box and applied the styles directly to the containing element. But those days are still a long way off yet, so as an interim solution, I recommend the use of <span> for such purposes.