This is part 1 of 2. Part 2 is my Guide to the use of Semantic HTML (HyperText Markup Language) Elements
I’ve seen a lot of articles discussing the importance of HTML and XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) 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.
Other examples which bear mentioning include the use of empty anchor elements to trigger Javascript events — in this case, it’s partially a limitation of the identity of an anchor element, but an empty anchor element should always be considered an error, as it results in a behavior-less anchor if the Javascript is not available.
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 (World Wide Web Consortium), 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 (Uniform Resource Identifier) 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
- Guidelines from WCAG (Web Content Accessibility Guidelines) 2.0 on the use of HTML for semantic structure
- Traditional HTML Semantics (Part I of a three-part series on web semantics by John Alsopp)
- HTML: The Foundation of the Web – Niels Matthijs
- Semantic HTML and Search Engine Optimization – From the Opera Developer Community, by Joost de Valk
- Who will read your semantic HTML? – Jesse Skinner
- When semantic markup goes bad – Matthew Paul Thomas
- Semantics – why bother? – Mel Pedley at Accessites
- HTML Semantics from Western Civilization, Pty.
- Graph the Semantic HTML Structure of your Web Page – Joe Dolson
Joe Dolson
You’re right – that should be on the list. I must not have bookmarked it…and it doesn’t show up for the searches I did! Thanks, Mike.
Mike Cherim
I think Mel’s article is pretty good.