Chad Perrin: SOB

15 February 2008

tooltips for text on the Web

Over at Lunar Ocean, Antoine Toulme commented on my use of the <acronym> tag. He was apparently not familiar with the <acronym> tag in HTML 4 and XHTML 1.x. For those who are not familiar with it, the <acronym> tag is what I used to create the tooltip effect here: HTML

Basically, it provides a roll-over tooltip effect, where pointing your mouse at the tagged text should cause a little off-colored box to appear with some alternate text in it. It is part of the standard for both HTML 4 and XHTML. Of course, I don’t think there’s any such thing as a browser that implements the entire HTML 4 or XHTML specification, so it’s almost inevitable that there are browsers that don’t support a tag like <acronym>.

Assaf commented at Lunar Ocean, correctly pointing out that at present the proposed HTML 5 standard deprecates <acronym> in favor of <abbr>, which makes perfect sense to me. There isn’t much need for both — <abbr> can serve that purpose for acronyms as well as any other types of abbreviations, and if you really need to distinguish between them, you can do so with a style class in your CSS. In addition to all that, <abbr> is less typing than <acronym>. Assaf recommends using <abbr> instead of <acronym> because of the apparently incipient deprecation of the latter tag. Unfortunately, that’s not the whole story.

Not too long ago, a few of the editors and weblog writers at TechRepublic (I’m one of those writers — check out the TechRepublic IT Security weblog) were involved in a brief discussion of the support for <acronym> and <abbr> tags in IE. This came up because the subject of the <acronym> tag came up briefly in comments to one of my ITSEC articles there. It became quickly evident that there are widespread inaccurate beliefs about these two tags.

For those who aren’t familiar with it, <abbr> is basically exactly the same thing as <acronym>. The difference is that <acronym> is meant to be used for acronyms to provide alternate text that explains the acronym to the reader, and <abbr> is meant to be used for the same purpose with all other types of abbreviated text (other than acronyms).

What most of the people in the behind-the-scenes TR discussion seemed to believe, incorrectly, is that the <abbr> and <acronym> tags are both unsupported by Internet Explorer. Further, one or two of them suggested that we (the writers for TR’s weblogs) should never use either one of them, because of that lack of support. There are some problems with this reasoning, however:

  1. The <abbr> and <acronym> tags are parsed by some search engines, and taken into account when determining search keyword associations and search rankings. Thus, using these tags helps with search engine optimization.
  2. Using either of these tags in no way hurts anything. If the only difference between two versions of text is the presence or absence of these tags, go ahead and use them. Not only will it potentially help with search engine optimization, but it will also help in that — for those users who employ browsers that do support these tags — in at least some cases they lend additional usability for the website.
  3. Internet Explorer does support the <acronym> tag. It just doesn’t support the <abbr> tag.

Point 3 there bears on the comments at the Lunar Ocean post. In choosing between the <abbr> and <acronym> tags, you need to make a choice between:

  1. <acronym>: a tag that is supported by more browsers now, but may become obsolete in the future, judging by a proposed specification that may one day become a standard
  2. <abbr>: a tag that, right now, isn’t supported properly by the browser with the single biggest share of the market — and, thus, the browser used by the most potential visitors or customers at your website

I don’t advocate for using standards-noncompliant code just to cater to Microsoft Internet Explorer, of course. In fact, I use standards compliant code that breaks in IE somewhat frequently. I’m a bad boy, that way. What I do advocate is using standards compliant code that works as close to “everywhere” as you can reasonably get. In the case of <abbr> vs. <acronym>, then, the choice seems obvious to me.

When using <acronym>, however, make sure the CSS code for your website includes some styling for the <acronym> tag. In terms of general principle, this is because the dotted underline styling for the tag in Firefox is not part of the actual HTML and XHTML standards. It’s just the default styling employed by the browser. Since it’s not part of the standard, there’s no guarantee it will always be there — and, as such, you should make sure the styling is explicit in your code.

More specifically, you should explicitly style the <acronym> tag because, while Internet Explorer supports the tag according to the standard specification, it doesn’t provide default styling for <acronym> the way Firefox does. As such, in IE, <acronym> tagged text will look exactly like the rest of the text, undifferentiated from the rest — which means IE users won’t even know there’s a tooltip there to be viewed — unless you use CSS to style the tag yourself.

11 Comments

  1. […] 2: See Chad’s post: 1. : a tag that is supported by more browsers now, but may become obsolete in the future, […]

    Pingback by Acronyms at Lunar Ocean — 15 February 2008 @ 12:11

  2. Thanks for the clarification Chad.

    Not sure I reached for a choice though. I hope my readers are Firefox-based given my audience.

    The point I wanted to make above all was that it was simple with this tag to add more meaning to words. It made me think of he way text shows when hovering a comic from xkcd, or how Assaf uses links.

    I am tempted to add some Facebox call these days. The blocker is that they won’t show up in the feeds reader. Well I need to actually try it out.

    Comment by Antoine — 15 February 2008 @ 12:32

  3. That’s not exactly correct. The abbr tag consists of significant content, and less significant expansion (the title, usually visible when you bother to hover over the element). IE displays the content correctly, but IE 5/6 do not handle the title correctly (tooltip or DOM). IE 7 fixes the abbr issue.

    So it boils down to how much do you care. According to Google Analytics, the majority of my blog readers run FF followed by Safari and IE. IE is split 2:1 between 6 and 7. The trend is showing significant increase for FF, less so for IE 7, and diminishing for IE 6.

    So do you optimize for every single browser out there? Lynx? PlayStation portable? On my blog, IE 6 usage falls just short of the cut off point where I stop caring about added features. I do still care that people can read the content, which IE 6 handles, I just don’t care enough for the tooltip.

    Even if IE 6’s share was larger, since it’s diminishing, I would rather solve this with a JavaScript bugwards compatibility hack then use acronym now and then go and fix the content later.

    Comment by Assaf — 15 February 2008 @ 12:34

  4. Antoine:

    I didn’t intend to give the impression that you specifically made a choice. I was responding more to the fact that Assaf suggested a choice — and that suggested choice was the <abbr> tag.

    Assaf:

    That’s not exactly correct. The abbr tag consists of significant content, and less significant expansion (the title, usually visible when you bother to hover over the element). IE displays the content correctly, but IE 5/6 do not handle the title correctly (tooltip or DOM).

    The difference from untagged content is only the “less significant expansion” to which you refer. Thus, my point.

    So it boils down to how much do you care. According to Google Analytics, the majority of my blog readers run FF followed by Safari and IE. IE is split 2:1 between 6 and 7.

    I’ve got a majority of Firefox users, with IE in second place. I care enough so that, when it doesn’t hurt me at all, I make the decision that provides functionality to more visitors.

    . . . especially since some of my readers are counted among both the Firefox users and IE users (some people use one at home, the other at work, for instance).

    So do you optimize for every single browser out there? Lynx? PlayStation portable?

    Does it hurt you that much to type “acronym” rather than “abbr”?

    Even if IE 6’s share was larger, since it’s diminishing, I would rather solve this with a JavaScript bugwards compatibility hack then use acronym now and then go and fix the content later.

    . . . assuming the current proposed specification becomes the standard. Besides, you’re going to have to change it all if you want it to be HTML 5 compatible anyway. You’re currently using HTML 4 and/or XHTML 1.x right now.

    Comment by apotheon — 15 February 2008 @ 04:18

  5. I have to say, ALL browsers are correct in how they handle abbr and acronym, so long as they recognize it. Unless I am reading the spec wrong (entirely possible!), it does not specify any default behavior. So IE’s approach is just as valid as Firefox’s. This is a semantic tag, which means that the best approach from the HTML writer’s viewpoint is to tell the browser what the desired display mechanism is (via CSS) instead of assuming any particular default behavior on the browser’s part. This is both inline with the spec and inline with the separation of presentation and content that HTML is supposed to (IMHO, at least) acheive.

    On that note, I am the W3C’s newest member of the HTML 5 working group, so please let me know if there is anything you’d like brought up in that forum. :)

    J.Ja

    Comment by Justin James — 15 February 2008 @ 07:40

  6. You have a point, Justin.

    Of course, for the purpose to which people actually choose to put the <abbr> tag, that doesn’t make it any more useful in IE 6.

    Also . . . if the <abbr> tag has no defined behavior, that makes me wonder why anyone bothered to add it to the specification. Might as well just leave it out of the spec, and let it get ignored by browsers that wouldn’t do anything with it anyway.

    Maybe I should just use <foo> from now on, instead of <abbr> or <acronym>.

    Comment by apotheon — 16 February 2008 @ 10:12

  7. “Also . . . if the <abbr> tag has no defined behavior, that makes me wonder why anyone bothered to add it to the specification. Might as well just leave it out of the spec, and let it get ignored by browsers that wouldn’t do anything with it anyway.”

    I agree, many of the tags that are in there purely for semantic reasons 1) need default behavior defined in the spec for the “screen” device type, and 2) need to then have browsers actually follow the spec.

    This is what drives me nuts about HTML… the stuff with standardized, default behavoior is dumb, device specific stuff like the DOM (like a printer supports an “onBlur” event…). Meanwhile, you’d need a bazillion tag CSS definition to ensure that everything that you probably will ever use is properly covered, instead of hoping that the user’s browser defaults to something sane.

    “Maybe I should just use <foo> from now on, instead of <abbr> or <acronym>.”

    Technically, you could, as long as you defined a style for it… ;)

    If it helps, something that is currently being discussed is doing some random sampling of pages and measuring the usage of tags. Not quite sure what or to what ends, though. That cuts both ways. As one person already mentioned, a mere 1% of pages that use a tag is still millions of pages.

    J.Ja

    Comment by Justin James — 16 February 2008 @ 03:59

  8. To explain why ABBR is broken on IE 6 you have to try accessing it from the DOM. What you would expect is an element with content and title attribute, which simply doesn’t show correctly. What you get, on the other hand, is an empty unknown element, followed by a text node, followed by another empty unknown element. You can’t apply styling with CSS because the element has no content, and no tooltip will show since the element doesn’t take any space on the display.

    You can structure your HTML entirely by using a single element like span or div (you don’t need both, just change the display attribute to block or inline). That will get you presentation but no semantics. It’s only when you care about semantics that the abbr tag becomes useful. You can run a script to create an index of abbreviations, use screen readers which know how to parse and speak it, etc.

    Specifying all these uses in advance is outside the scope of HTML, but enabling them is in the scope of HTML.

    Comment by Assaf — 16 February 2008 @ 04:46

  9. J. James:

    Note — You can use backticks here as though they were <code> and </code> tags. Thus, if you enter:

      `<abbr>`
    

    . . . you get <abbr>. I edited where you quoted me so that the relevant tags would have backticks around them. The reason this works is that I’m using a Markdown plug-in for this WordPress. Markdown syntax is dead simple to learn. Here’s a guide to Markdown syntax.

    Back to the topic at hand:

    I agree, many of the tags that are in there purely for semantic reasons 1) need default behavior defined in the spec for the “screen” device type, and 2) need to then have browsers actually follow the spec.

    Indeed. Anything in the spec should darned well have default behavior, for the most part. If there’s to be anything that doesn’t have default behavior to unique to itself, perhaps there should just be one each block-type and inline-type generically named behavior-less tag as a catch-all, so that we can just use them with CSS classes and be done with it. Oh, wait — we already have those. They’re called <div> and <span>. So . . . why have something pointlessly behavior-less in the spec like <abbr>? Thank goodness the folks at Mozilla decided to give <abbr> and <acronym> some default behavior.

    Technically, you could [use <foo>], as long as you defined a style for it… ;)

    . . . except that I’m trying to maximize cross-browser compatibility, so I use <acronym> instead (with the underline styling defined). Some browsers have severe issues with unrecognized tags. I was just being facetious, anyway — as I’m sure you’re aware.

    Assaf:

    To explain why ABBR is broken on IE 6 you have to try accessing it from the DOM. What you would expect is an element with content and title attribute, which simply doesn’t show correctly. What you get, on the other hand, is an empty unknown element, followed by a text node, followed by another empty unknown element. You can’t apply styling with CSS because the element has no content, and no tooltip will show since the element doesn’t take any space on the display.

    I’m not sure what your point is, here. I mean — yeah, that’s true. My point was that <abbr> is broken, and we should consider not using it because of that. You just reinforced the fact that it’s broken, when you’d been arguing previously that we should all use it instead of something that isn’t broken.

    You can structure your HTML entirely by using a single element like span or div

    Amusing that I read this now, after I just typed up a related point to Justin above. Convergent thought processes, I guess.

    It’s only when you care about semantics that the abbr tag becomes useful.

    It’s not even useful then, in IE 6 — unless you mean “I like to semantically indicate things in the source as a means of documenting my code without using class attributes.” After all, well-employed class attributes could serve as semantic context for your universal <span> and/or <div> tags.

    Specifying all these uses in advance is outside the scope of HTML, but enabling them is in the scope of HTML.

    . . . and all of that fails when the browser doesn’t support the tag, to say nothing of the fact that you could have all that with things like:

      <span class="abbr" title="Situation Normal, All Fucked Up">SNAFU</span>
    

    What you don’t get from that is stuff like default behaviors, et cetera. You know — the stuff you seem to be saying doesn’t matter.

    Comment by apotheon — 16 February 2008 @ 08:28

  10. “I’m not sure what your point is, here.”

    I’m correcting Justin. Browsers are correct if they don’t do anything interesting with the title attribute of abbr/acronym/a (see below). But IE 6’s handling of abbr is broken, any way you look at it. I’m just illustrating how to test for that.

    I consider the tooltip an optional feature. The title attribute does not do anything interesting on the iPhone, BlackBerry, WAP, PlayStation, Lynx and many other browsers. Also some feed readers and aggregators will strip it out.

    Ideally I would like it to be supported everywhere, but I’m willing to to accept that some browsers provide degraded functionality that shows the content, just not the expansion. I consider it acceptable on the iPhone, and I consider it acceptable on IE 6.

    As for semantics, right now abbr as a tag name has known and standardized semantics, abbr as a class name doesn’t.

    Comment by Assaf — 17 February 2008 @ 04:58

  11. I’m correcting Justin.

    My mistake. I thought you were responding directly to me with that.

    As for semantics, right now abbr as a tag name has known and standardized semantics, abbr as a class name doesn’t.

    . . . which doesn’t matter in the hypothetical example I provided above, because it only needs to be as “standardized” as necessary to make sure your web developers are on the same page. The semantics of it are pointless for the rest of the world if the standard doesn’t do anything with them.

    Comment by apotheon — 18 February 2008 @ 12:12

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License