I’ve seen a lot of articles discussing the importance of HTML and XHTML semantics. I’ve seen articles describing what it means for a document to be semantic. Most of these articles, however, don’t provide a serious overview of what HTML elements actually may be considered semantic — and what those semantic elements actually mean.
And, even more particularly, why it matters.
Semantics is an erudite area of study. Literally, semantics can be fairly defined as the study of meaning in communication. Communication can readily be extended to cover symbolic notations, representations of language, organization of language, body language and information structures. In developing a web page, we are organizing a means to communicate the content of that page: ideally, we are organizing the page in such a manner that it will be understood regardless of the method by which the page is accessed. It should be equally understandable whether seen, heard, or felt.
The semantics of HTML structure, then, are clearly an important part of web design. Sending mixed signals to the user agent or the user by using a
blockquote purely for it’s native indentation is an abuse of semantics: even the visual impact is dependent on the assumption that user agents will consistently render a
blockquote in an indented manner.
It’s not precisely an issue that you’ve used a semantic element for presentational means, because, in fact, you’ve done more than that: you’ve presented a block of text which is not quoted material as if it were.
Semantic elements of HTML carry meaning regardless of your knowledge of that meaning. The result is that the misuse of an element creates the potential to mislead or confuse an end-user.
The most obvious examples in common use are those which make use of elements with semantic meaning which also offer a browser-contributed default presentation in order to use that presentational style. The
blockquote example above is not uncommon; similarly, the use of empty
p elements to create extra white space or heading elements used as a questionable SEO technique in substitution for normal paragraphs.
Now, you may point to the following paragraph, from the HTML 4.01 specifications, as a response to my opinion:
Authors may also create an A element that specifies no anchors, i.e., that doesn’t specify href, name, or id. Values for these attributes may be set at a later time through scripts.
The fact that it is allowed by the specification does not make it a best practice. With all due respect to the W3C, this should not be permitted. For reference, the HTML 5 specification currently reads:
If the a element has no
href attribute, then the element is a placeholder for where a link might otherwise have been placed, if it had been relevant.
In addition, although I won’t quote everything, the specification states that an anchor which does have the
href attribute must specify a URI as the value of that attribute. It appears to essentially state that an anchor element should have no semantic meaning if the
href attribute is not set and valid. But I could be wrong.
The best means to avoid the misuse of elements is to have a clear understanding of when and why a given element should be used in web development. To hopefully expand on your knowledge in that respect, I’m attempting to provide a semantic guide to HTML elements for your reference and rich disagreement.
Be aware, however, that semantics are largely a matter of opinion. It’s not a question of blindly following the guidelines set by a group; it’s a question of interpreting those guidelines to the best of your ability and belief. This guide reflect how I think HTML elements should be used; and I welcome your opinions.
Other HTML Semantics Articles