One of my favorite things about Web development is it’s openness. I love it how open the principles, practices, and techniques behind it are continually open for discussion. One of my top priorities when applying markup to a document is keeping semantics in mind. (X)HTML is a semantic markup language by nature, and it should be treated as such, but semantics can be argued until the end of time in certain cases.
When first researching the specifications published by the W3C, there were certain times where a light went off, and one more piece seemed to fit together. Many times, it was when I would read about one of the many HTML elements and it would just make sense. As I became more and more involved with markup, it became apparent how great (X)HTML can be when used properly. From time to time I will review the specification, re-examine the details, and analyze how I’ve been using a particular tag in practice. Two such tags that I recently reviewed are the
Acronym or Abbreviation?
abbr tags are not only a completely great tool for your readers, they also provide another way for you to include some search engine friendly keywords into your document. According to the W3C Spec,
abbr are considered phrase elements.
Phrase elements add structural information to text fragments. More specifically:
- Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).
- Indicates an acronym (e.g., WAC, radar, etc.).
The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. Western languages make extensive use of acronyms such as “GmbH”, “NATO”, and “F.B.I.”, as well as abbreviations like “M.”, “Inc.”, “et al.”, “etc.” … Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers.
The first time I read the above definition, I was still a bit perplexed as to when each should be used. The specification goes on to say:
The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.
The definition has now grouped the two tags into one and made it a bit more confusing as to what criteria a string should meet before it is classified as either
Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while “IRS” and “BBC” are typically pronounced letter by letter, “NATO” and “UNESCO” are pronounced phonetically. Still other abbreviated forms (e.g., “URI” and “SQL”) are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.
From reading the documentation, we can gather that
acronym are very similar in nature, but on the other hand, they’re different. The specification leaves this issue open for interpretation and many people have their own views.
I tend to side with those that decipher the difference in the actual pronunciation of the phrase. An acronym is a set of letters that can be pronounced as a single word (e.g., NATO pronounced “NAY-TOE”) whereas an abbreviation is pronounced one letter at a time (e.g., CSS pronounced “SEE ESS ESS”).
Is there a need for both
There are many people that feel that
acronym will be deprecated in future versions of XHTML. Personally, I don’t have a strong opinion on whether or not we’ll be able to use
acronym in the future, but given the gray nature of the definition itself, I wouldn’t rule out it’s deprecation.
Beyond the semantics of the tags themselves, there are, of course, browser inconsistencies to deal with as well. From a semantic point of view, browser support could be pushed aside in favor of semantic value. On the other hand, having stylistic control over abbreviated phrases or acronyms can be a strong benefit for the design and usability of a document.