Web comics authors: Please stop using HTML image attributes

I like XKCD. Everyone that I know who’s heard of XKCD likes it as well. But there’s one little annoying thing its author, Randall Munroe, does that I wish he would stop: putting additional commentary about the strip into HTML meta attributes on the image of the comic. Specifically, I’m referring to the title attribute, which is often incorrectly said to be the alt attribute (the name of the strip is actually what goes into the alt attribute). The contents of the title attribute is displayed when you hover your mouse above the image. The worst annoyance with the title attribute, that it wouldn’t be displayed in full in Firefox 2 unless you right-clicked on the image and opened up the Image Properties dialog, has been fixed in Firefox 3, but there are still many other problems with the customary use of the image’s title attribute for displaying additional text commentary.

The main problem with the use of the image title attribute to inject additional humor is that it is not obvious from a user interface standpoint. I read the entire backlog of 200 or so XKCD strips when I first found out about the comic, only to then discover that I had completely missed out on the “hidden” joke on each one. And since it was such a big backlog, I never even bothered going back to check out the jokes. Simply placing them as text beneath the comics, as a sort of caption postscript, would have worked much better.

More recently, when I found out about the excellent web comic Daisy Owl, I again read the entire backlog without realizing there was additional content on each comic in the form of a title attribute. The use of the image title attribute is spreading like a malevolent virus! Now, it’s gotten to the point that I hover my mouse cursor over every web comic image for fear of missing anything, even though the vast majority thankfully don’t use this feature. Now that’s just a waste of my time.

Also, using the image title attribute for these purposes simply isn’t good according to web accessibility standards. The title attribute is specifically intended to label the link that the image points to, while the alt attribute is used to describe the image itself. The title attribute is thus meaningless in the context of web comic images, which typically don’t link to anything, and relies on a browser quirk to display the contents of the title attribute even in the absence of a link. It doesn’t make sense to use the image attribute against its intended purposes simply because most web browsers happen to display it in a pop-up text box on an image mouse-over event. Needless to say, the use of image attributes in “creative” ways confuses screen reader programs used by the blind, which rely on the image attributes actually being what they say they are.

So Randall, I love your strip, but please just put the additional commentary as plain text somewhere on the page below the image. The trick with the title attribute was cute at first, but is now just annoying, and I’m afraid it’s spreading across the blagosphere, with new web comics authors feeling compelled to put something in their image title attributes as well.

14 Responses to “Web comics authors: Please stop using HTML image attributes”

  1. drinian Says:

    Dude, I don’t think that too many blind people are going to be reading a graphical comic in the first place.

    Why the hatred for easter eggs?

  2. William (green) Says:

    I like the fact that it’s hidden. I did the same thing you did, by the way.
    The fact that it’s not obvious makes it a little more worthwhile, somehow.

  3. Knacker Says:

    Haha, metadata! The scourge of POSIX!

  4. T2A` Says:

    I recall glancing over some stats that said about 4% of the web follows web standards. Obviously it’s not that important. Hell, even this very site fails XHTML validation. D:

    Dinosaur Comics is much worse than XKCD (in the annoying hidden messages; it’s actually a lot better than XKCD overall). He puts extra crap in the image title, the comments email subject, and you can’t even tell the actual title of the comic without checking the RSS feed or the archive.

  5. drinian Says:

    Read the strip
    Now I see
    Just remember
    The comic’s free

    Burma-Shave

  6. Knacker Says:

    one more question; why do unix nerds hate metadata anyway? I find myself wishing that mainstream filesystems had it from the start like the original macintosh. The original mac wasn’t a great system for my purposes by any means, but still, the idea that data didn’t have to be a random, unexplained assortment of files appeals to me.

    We’re getting some of it now, with M3U and EXIF for mp3s and jpegs respectively, but still, there should have been some sort of standard for that from the beginning, so file systems could be more like an intuitive database and less like my bottom desk drawer at work where I just throw crap I don’t care to organize.

  7. Knacker Says:

    And also so that people would actually USE it rather than avoid it because it’s not what they’re used to.

  8. drinian Says:

    I think you answered your own question; it was something that could be implemented in the file formats themselves.

    More importantly, not integrating metadata into the filesystem makes it much easier to define flexible metadata formats that address each format’s particular needs — and guarantee that you can send those files over the network without losing said metadata.

  9. Knacker Says:

    Yes, but that basically guarantees that the metadata won’t be available except to specialized programs that are made to deal with whatever format is in question. And without some sort of metadata standard, you can only identify unknown file formats by their extension; cyde has gone through how this is problematic himself. And since there isn’t a metadata standard, most proprietary formats just completely ignore the possibilities.

    I think that all files should have, for example, metadata for author and date created that won’t get reset when you download the file, and that any file manager should be able to unearth this information, and it should be preserved when transferred over a network with any protocol.

    You’ve stated your opinon logically and rationally regarding the realities of current protocols, it doesn’t change that they are limited in a way no one can see because they’ve been raised in an environment where the limitations are law.

  10. drinian Says:

    You, sir, have a much more optimistic view of the truthfulness of file creators than I do.

    And I still maintain that your way is much more limiting.

    Also, it’s only Windows that determines file type by extension. KDE has done a fine job by looking at headers for years now, not to mention libmagic.

  11. knacker Says:

    Well, its in the best interest of the files’ creators that their stuff be usable.

    Your way is cumbersome and based on thirty year old design decisions.

    Doesn’t matter, it’ll probably not happen for about ten years.

  12. Knacker Says:

    I think I should also clarify that my idea of metadata would be similar to (but hopefully more powerful than) ADS in NTFS or Extended attributes in ZFS… Or… like the resource fork on Mac OS 9 >.

    The idea isn’t that the metadata will be prescribed, into predefined fields that every file must have and which would be just empty space on files that didn’t implement it, but a flexible database that could be used for any purpose, and the FS would be agnostic as to what data it would contain (except for well known attributes such as author and date created that would be common to almost all files). Each file would be a database fragment that could hold any type of information, but for which there is a standard method of reading.

    I’m actually starting to think, with the advent of the iPhone and other walled garden type electronics that everybody loves that a file-based system is on it’s way out, replaced by these stupid playskool toys where you’re prevented from doing anything really powerful… So my idea might not be an eventuality as I thought.

  13. JD Baldwin Says:

    “The main problem with the use of the image title attribute to inject
    additional humor is that it is not obvious from a user interface
    standpoint.”

    I submit that if you like your humor “obvious,” then visiting xkcd is
    the proverbial barking up the wrong tree.

    “Also, using the image title attribute for these purposes simply isn’t
    good according to web accessibility standards. The title attribute is
    specifically intended to label the link that the image points to,
    while the alt attribute is used to describe the image itself. The
    title attribute is thus meaningless in the context of web comic
    images, which typically don’t link to anything, and relies on a
    browser quirk to display the contents of the title attribute even in
    the absence of a link. […] Needless to say, the use of image
    attributes in ‘creative’ ways confuses screen reader programs used by
    the blind, which rely on the image attributes actually being what they
    say they are.”

    Sad as it might have to be to admit, there are some things blind
    people will simply never be able to appreciate directly. Funny
    drawings are among these things. A blind person who wants to “read”
    xkcd is just going to have to find a sighted person to describe it to
    him. And, in that (probably rare) case, the ALT text will be just as
    much (or as little) appreciated as it is now.

    “So Randall, I love your strip, but please just put the additional
    commentary as plain text somewhere on the page below the image.”

    That would completely defeat the point of the joke.

  14. J. Albert Bowden II Says:

    “Also, using the image title attribute for these purposes simply isn’t good according to web accessibility standards.” what standards are you referring to? specifically? there’s nothing on the w3c, dive into accessibility, wasp that i’ve seen that supports that claim.

    “Specifically, I’m referring to the title attribute, which is often incorrectly said to be the alt attribute (the name of the strip is actually what goes into the alt attribute)” actually the alt attribute is text replacement for the image, not necessarily “the name” of the image. it describes the image for the user that cannot see it. if you read their source code, you’ll see that the markup is right on and they are implementing it correctly. example: http://xkcd.com/401/ comic is about large hadron collider, image is titled (literally) large_hadron_collider.png, and the alt attribute appropriately says, large hadron collider. the title attribute in this case, adds further insight to the author’s creation. it’s not supposed to be the same as the alt attribute.

    “The title attribute is specifically intended to label the link that the image points to, while the alt attribute is used to describe the image itself. ” – um, in your words the title attribute is only applicable for a link? a link that has an image embedded in it? resources? i’m going to say negative on that one ghost rider.

    “The title attribute is thus meaningless in the context of web comic images, which typically don’t link to anything, and relies on a browser quirk to display the contents of the title attribute even in the absence of a link.” – meaningless to you. i’m not saying you are meaningless by any means, i am saying the authors use is meaningless to you. how does that make what he’s doing wrong? it’s his/her choice.

    “It doesn’t make sense to use the image attribute against its intended purposes simply because most web browsers happen to display it in a pop-up text box on an image mouse-over event.” it doesn’t make sense to you. exactly. you as in you personally. straight up, most of this post doesn’t make sense to me. or my hardcopy reference books. nor the web, and google, which of course i’ve been scouring to see where/what you are rambling about.

    “Needless to say, the use of image attributes in “creative” ways confuses screen reader programs used by the blind, which rely on the image attributes actually being what they say they are.” – xscd’s “creative” methods follow w3c spec and should provide the appropriate content for screen readers. back to the example. JAWS tells the blind user that they are at a site full of comic strips. they know they are viewing comics. JAWS tells blind man, hey this is, titled hadron.png, they know the image is actually titled hadron. then the alt description says, hadron collider, so they know they are on a comic site, looking at a pix labeled and described hadron collider. then jaws reads the title attribute “When charged particles of more than 5 TeV pass through a bubble chamber, they leave a trail of candy.” which makes the butt of the joke (in your words) or simply makes the joke for the blind person.

    “The main problem with the use of the image title attribute to inject additional humor is that it is not obvious from a user interface standpoint.” i could not agree with you more on that one. however, maybe the author isn’t worried about that. it’s web…do what ya feel, do what ya like. maybe he’s not all about getting his content out there and/or could careless who sees his stuff? but in this case, they are using it right. all of it.

    title attribute showing on hover is not a browser quirk, its default now for the big boys. moreover, maybe you just don’t like it. nothing wrong with that. everything’s relative. but writing a blog about web standards/techniques based on your likes/dislikes isn’t exactly science. are you just mad that he’s using titles? or are you mad that you didn’t get the jokes at first? was it the ego shot? maybe he should put a disclaimer warning potential laughers…these jokes aren’t dumb and easy. they are intuitive and creative. so if you don’t get it after 3 seconds, abort mission.

    i think you’re just hating for the sake of hating. not kewl dood. at least not in the webcomm.