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 and abbr tags.

Acronym or Abbreviation?

The acronym and 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, acronym and abbr are considered phrase elements. Phrase elements add structural information to text fragments. More specifically:

ABBR

Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).

ACRONYM

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 acronym or abbr.

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.

What separates abbr and acronym

From reading the documentation, we can gather that abbr and 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 acronym and abbr?

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.

Advertise here with BSA

A tip for document portability

One way to avoid having to check for bad links through an entire website after it was moved would be to mark up the document in such a way where the URIs are not dependent on where they reside. For instance, using absolute URIs which include the current domain of the site. It’s not often that a site domain would change, but in the case of changing servers, you might want the links to be pointing to your development URI for testing purposes.

Enter the base tag

Instead of including the site domain in various links within a document, you could include the domain in the base tag found in the head of your document. The base tag is defined by the W3C as:

In HTML, links and references to external images, applets, form-processing programs, style sheets, etc. are always specified by a URI. Relative URIs are resolved according to a base URI, which may come from a variety of sources. The BASE element allows authors to specify a document’s base URI explicitly.

When present, the BASE element must appear in the HEAD section of an HTML document, before any element that refers to an external source. The path information specified by the BASE element only affects URIs in the document where the element appears.

The base tag allows authors to define from which URI all links should originate. In my eyes this can be both a good and a bad thing. On one hand, your document is now portable in that you can control the root URI for the entire page simply by managing the value of the href attribute within the base tag. On the other hand, you can lose the ability to structure (true) relative URIs in certain circumstances. Essentially, the base tag treats relative URIs as absolute URIs by adding it’s href value to any relative URI.

For example, I was getting started on a particular site that had three major ‘sections’, and it seemed fitting to store the markup for each section in it’s respective folder. Not only does that help me with organizing the markup, it would give the possibility to setup subdomains for the folders and help the company out with SEO. As I was testing the initial structure of the site, I discovered that some of the site navigation was no longer functional. The site is run using a template server side, so at first I couldn’t figure out why site navigation links would work on one page, but not the next. As it turned out, there was a base tag included in the template that I had overlooked. It was interfering with the folder structure of some links because that base tag was included with the header file of the template I was working on and not including an additional folder in the path if applicable. Removing the base tag solved the problem.

Personally, I prefer the ability to use true relative URIs anywhere I please, and manage a pseudo base URI using a variable defined server side. In a sense, it’s using the idea of the base tag, while not limiting yourself in such a way as described above.

Other shortcomings of the base tag

Interestingly enough, Roger Johansson discovered a nasty IE6 bug associated with base elements. He notes that if a base element is present, it makes selecting text quite a challenge in Internet Explorer. Roger’s solution was also to remove the element itself, as it was only included due to the CMS he was using. While not a huge disaster, something like that wouldn’t sit well with me and prove to be quite an annoyance.

I’ve also read that it was possible in IE6 to define multiple base tags, treating them as code blocks within a document. Technically you could have different base hrefs defined in various sections of your document and they would behave as such in Internet Explorer. Thankfully, IE7 doesn’t sport this “feature” and will only use the base as expected.

In closing…

All in all, I think that the base tag could prove to be a valuable resource, but in my personal use, it can prove to be a nuisance. Just about every site I develop is using some sort of server technology to control a template for the site, which helps to cut down on development time. The presence of a base element has more than once caused a few moments of confusion and frustration for me. The root URI is defined as a server side variable in the majority of my projects, and using that as opposed to a base has proven to be much more useful.

Advertise here with BSA

How else can link be used?

The purpose of link is to define a relationship between the current document and another one. The three most common uses of link are probably what I listed, but maybe not in that order; stylesheets, RSS, and favicons. It makes perfect sense because essentially, you’re linking your document to another for various purposes. For example:

<link rel="stylesheet" href="css/screen.css" type="text/css" media="screen, projection" />

Chances are you have something very similar in the head of each and every document you’ve marked up in recent history. In that example, I’m telling browsers that the current document is linked to css/screen.css because it has a relavance of being the document stylesheet. The browser will apply this direction and present the reader with a styled document.

<link rel="alternate" type="application/rss+xml" title="Monday By Noon RSS Feed" href="/feed/" />

Along with CSS, link is used to designate favicons and the location of RSS feeds. Chances are you probably use it for that as well, but the link tag has the more general purpose of defining the relationship between two documents. This purpose can be taken advantage of in a variety of ways.

It is up to the author to decide which relevance a link may have, as you aren’t limited to a set of options to choose from. You can make up your own. A few examples of the more common choices include:

• Alternate
• Stylesheet
• Start
• Next
• Prev
• Contents
• Index
• Glossary
• Copyright
• Chapter
• Section
• Subsection
• Appendix
• Help
• Bookmark

You can read detailed descriptions of each within the W3C spec of link. As I look through that list of the most commonly used references to link, I realize that I can be using the tag in a much more effective manner. Other uses of the tag I’ve seen around the sites I visit most are to provide the correct location for pingbacks or designate links to sections of the site archive.

User agents use link as a feature

Browsers are able to take advantage of the link tag by including features within the application itself that make use of the relationships created with link. The most obvious example would probably be the inclusion of a favicon. When a favicon is designated, most browsers will use it to place in the address bar next to your URL to help you distinguish yourself. It will also be used near bookmarks and maybe in other ways depending on the browser.

Another excellent example of a browser taking advantage of link is Mozilla’s Firefox. Mozilla saw the value of RSS and decided to help expose its usefulness in a totally new way. When the browser was told that there was a feed associated with the current document, it would put a feed icon in the address bar, which was clickable by a reader should they want to use the feed.

There are other browsers that use link to add contextual menus within the browser itself to help a reader with site navigation. While these browser features aren’t often implemented, it’s the intended purpose.

The SEO advantages of link

link also brings with it some SEO benefits that may not be initially obvious. Some search engines will use your link to find other related documents that should be indexed as such because it will show that your document has more worth.

Not only can you advise search engines about related documents due to navigational structure, but also documents which have been translated into other languages. Telling search engines this information up front can be beneficial to the indexing of your site. While the link tag may be most useful for styling, RSS, or extensive document collections, using it in applicable ways can always help out.

Advertise here with BSA