"Title" attribute for links?

November 25, 2007 9:40 PM

Any chance of the "title" attribute for links, please? In the UI, I mean.

Obviously, people can add a title to whatever link they want, but if it was part of the posting interface, perhaps it would happen more often.

The kind of thing I was thinking of was perhaps to have the pop up that appears when you click on the "link" button to prompt for a title as well as the URL.

posted by GeckoDundee to Feature Requests at 9:40 PM (33 comments total)

We try to keep the posting page as simple as possible and the gain we get from titles is a bit too minor for the interface change and added pain of having to explain and fill in another form field.
posted by mathowie (staff) at 9:45 PM on November 25, 2007

I didn't really want to mention any particular kind of post, but I was thinking specifically of youtube posts. So this recent post from flapjax at midnight for example was really easy to take in, whereas without titles it would've been much more difficult. It sounds like you've been through this before though. And of course a search through the grey reveals that you have. Sorry.
posted by GeckoDundee at 10:07 PM on November 25, 2007

It's hard enough to get people to make links for their URLs in the first place, although it's been getting better as of late.
posted by baphomet at 10:10 PM on November 25, 2007

How about just adding the empty attribute (Title=""), then it's there as a reminder to them in the comment box.
posted by blue_beetle at 10:56 PM on November 25, 2007

I skim the blue, I'd rather have everything in plain sight. If there's extra info that doesn't fit on the front page just put it in the mi, that's what it's for.
posted by Kattullus at 12:22 AM on November 26, 2007

GeckoDundee: Now here is a basic difference of opinion. If it was my site, I would have nuked the Arethra post as a particularly stupid example of mystery meat wankery. As it is, I have my own little user javascript to cut the mystery out of mystery meat posts. I don't know if the front page is getting worse in this regard, or my patience with idiots trying to be cute is wearing thin.

Using the title attribute to communicate information that should be part of the link text is an automatic fail. The post would have been better written as:

Youtube Arethra: The Shoop Shoop Song, Don't Play that Song for Me, etc., etc..
posted by KirkJobSluder at 6:05 AM on November 26, 2007

Previously.
posted by scottreynen at 6:22 AM on November 26, 2007

That this idea won't stay dead should probably tell the admins something. Not that they didn't already know it, since, well, the idea won't stay dead.

KirkJobSluder: ... or my patience with idiots trying to be cute is wearing thin.

Since this is much more strongly worded than your usual, I'd vote for the 'or'.

I'm of two minds. On the one hand some people use TITLE very well to include extra information without bogging down the FPP or interrupting the stream of thought. y2karl is the usual example, but I'm not trying to diss anyone else who does that by leaving them out.

OTOH, I agree that the Aretha post was a perfect example of trying to be cute and ending up just being fucking annoying.

BTW, what's your script,? Is it Greasemonkey? Or an Opera mod? And what do you do with the TITLEs?
posted by lodurr at 6:22 AM on November 26, 2007

The title attribute is a problem if it is used for important information. For one, it is invisible by default. Secondly, the content is not indexed by Goog or Y!, so it’s impossible to search for phrases found only in the attribute.
posted by breaks the guidelines? at 6:31 AM on November 26, 2007

... the content is not indexed by Goog or Y!...

Hmmm.... do you have a source on that? I'm pretty sure I remember reading in the not too distant past that TITLE explicitly is indexed by Google. If it's not, that's a really important thing to know.
posted by lodurr at 6:50 AM on November 26, 2007

lodurr, I cannot say with certainty that Google doesn’t use the title attribute at all, but IMO, they would be wise not to. Because it is not visible by default, it is subject to the same sorts of SEO abuses that the meta type="keywords" elements have been.
posted by breaks the guidelines? at 6:58 AM on November 26, 2007

What Matt said, and a couple others: if someone wants to use the title attribute to good effect, that's fine, but doing it manually is probably the best (and, aside from that, currently totally functioning) compromise.

It's not vital or expected material, so most people will miss it even when it is included; it's not trivial to get folks unaccustomed to the practice to grok the purpose and correct use of it on first contact, so throwing it into the UI would be a questionable move; and there are lots of posts where it would be totally unnecessary to have around.

It just doesn't seem like a real general need exists.
posted by cortex (staff) at 7:02 AM on November 26, 2007

KirkJobSluder's script is Greasemonkey.

It's very difficult to follow a link without at least briefly mousing over it, so the title attribute can be useful. Often the url gives some hints, but youtube is very opaque on this score.

Using the title attribute to communicate information that should be part of the link text is an automatic fail.
Maybe. Sometimes it reads better when one is laconic, provided no important information is left out. The "title" can enrich the user experience though, without doing the heavy lifting.

But this is almost irrelevant as things stand, when we have many posts containing youtube links with no clues (except perhaps the tags on the post) as to what they are about.

Blue_beetle's suggestion seems to me like a good compromise. (Previously made by kindall.

On preview, whether or not it's SEO abuse is an interesting question, but I'm pretty sure lodurr's right about the indexing.
posted by GeckoDundee at 7:03 AM on November 26, 2007

A quick search brings up this page in which the author concludes that the title attribute isn’t indexed.
posted by breaks the guidelines? at 7:03 AM on November 26, 2007

Well, you're right that it could be abused. But when it's used properly, the better thing would be to index it, not avoid it, since it's function is to provide additional information about the link-target.

As for "hidden by default": I would say rather that it's "revealed as requested" -- in any browser I've used in the last several years, it displays on mouseover and goes away (ideally) on mouseout. (Sometimes on Firefox on a Mac it sticks around until you make another title appear. Which is really annoying when it's obscuring something you want to read or click on...but I digress...)
posted by lodurr at 7:04 AM on November 26, 2007

I’m not opposed to the use of title in general, but I do think it causes usability problems. I would be more inclined to agree with your semantic shift in terminology if there was some indication that a title is present. A stylesheet with a selector matching the attribute could help, but then you run into this issue: since virtually any element can have a title, that means that you could have both a child and its parent could have different titles. How would you visually distinguish them when there is no limit to the amount of nesting that could occur. Incidentally, this is the same gripe I have with the push to add href attributes to every element in HTML5.
posted by breaks the guidelines? at 7:14 AM on November 26, 2007

A stylesheet with a selector matching the attribute could help...

... but wouldn't for most people, since AFAIK selectors still don't work in IE.

I'm not sure what usability problems it causes. If I understand you correctly, you're saying it could cause problems because people might use it improperly. That's true of just about anything. It's incumbent upon the person using it to use it intelligently. If they don't, then there's a problem. You have the same issue if people mis-use ALT tags on images, set the styles in such a way as to make link text disappear, etc.
posted by lodurr at 7:19 AM on November 26, 2007

lodurr: I have it up on userscripts.org, and it is greasemonkey and opera compatible. Basically all it does is append a [tag] for the most common offenders of mystery meat posts such as [yt] for youtube, [wp] for wikipedia, [mefi] for metafilter, and [nyt] for New York Times. It doesn't do anything with titles (yet) but it's enough for me to know that posts like this are not worth the time, in contrast with this post which uses commas to cleanly separate link boundaries. I've ranted about mystery meat navigation several times here and I've come to the conclusion that it's more productive for me to fix the problem at my end with javascript filters than to expect any change in policy from the mefi mods on this issue.

I'm certain that some people do use the title attribute to good effect. But the title attribute should not be used as a substitute for descriptive link text for a variety of reasons related to usability and accessibility.

GeckoDundee: Tooltips show on Opera after a two-second pause, and on firefox the href attribute is shown in the status bar at the bottom of the screen forcing the eye to move away from the text and back onto the text. They don't show at all when I use keyboard navigation of links. But I can think of few examples where the title shouldn't have been rolled into the link text to start with.

I don't think it will do much to solve the problem of mystery meat youtube wankery because the people who are not considerate enough to use descriptive link text, are generally not considerate enough to use an optional html attribute to annotate their mystery meat. There are always exceptions.
posted by KirkJobSluder at 7:20 AM on November 26, 2007

It's a while since I've played Diablo, so I've lost the habit of mousing over every pixel on the screen to see if there's hidden information behind it. I think it's a bad idea to hide things behind 'title' attributes. This would be different if there was some visual indication when a link needs to be hovered over, but there isn't.
Addressing lodurr's comment above, on any computer I use it's not so much "displays on mouseover" as "displays shortly after mousover, following a seeming eternity of 'will-it-won't-it' angst unless you jiggle the mouse even a tiny bit in which case start over". Maybe I need to buy newer computers.
posted by nowonmai at 7:27 AM on November 26, 2007

I think it's expecting too much to expect a visual indicator of everything that might happen when you move a mouse pointer over something. Taken to its very logical not-so-extreme, you then have indicators after every link that tell you something about the link, or differently formatted links for different targets or types of target, etc. To the best of my knowledge, tests usually demonstrate that such accommodations end up hindering people's ability to parse the text.

Again, it seems clear to me that the onus has to be on the creator to create quality text and links. If they're sticking stuff into the TITLE attribute that ought to be in the link text, then they're not communicating; it's their problem, and overall and in the long run, they suffer for it more than their users do (since folks won't be clicking their links and won't think highly of their stuff).

You can't make things foolproof. The fools are just too damned ingenious.
posted by lodurr at 7:35 AM on November 26, 2007

You can see an example of the usability problem at its most obvious in this recent FPP. The poster had applied a title the the words “Black Friday,” graciously giving a definition for the term. But since there was no visual indicator, no one noticed that it was there, and it didn’t take long for the inevitable “whatsa ‘Black Friday?’” comment.
posted by breaks the guidelines? at 7:43 AM on November 26, 2007

This is really just a difference of philosophy. You regard it as a usability problem. I regard it as a failure to understand (a) that the feature exists (on the part of readers), and (b) how to use it properly (on the part of the post creator).

I think it's silly to expect everything to be bulletproof. That kind of logic leads to over-design and over-engineering.
posted by lodurr at 8:04 AM on November 26, 2007

(a) I understand that the feature exists, yet I missed it in that post, because nothing indicated the presence of the title in that post until the poster explicitly stated it in a later comment.

(b) What exactly was improper about its usage in that instance?
posted by breaks the guidelines? at 8:11 AM on November 26, 2007

lodurr: You regard it as a usability problem. I regard it as a failure to understand (a) that the feature exists (on the part of readers), and (b) how to use it properly (on the part of the post creator).

These two things together pretty much define a majority of usability problems.

But, another weapon in the fight against mystery meat navigation, a bookmarklet (opera and gecko only) to add a light marker for link boundaries:

javascript:document.styleSheets[0].insertRule('a{border-right:1px dotted #999999;border-bottom: 1px dotted #999999}',0);

posted by KirkJobSluder at 8:20 AM on November 26, 2007

(B) I'd say "nothing" -- but you missed the post, so I'd have expected you to say he should have included information in the body of the post instead of the title attribute.

I'll put this another way, in case my meaning still isn't clear: Expecting the TITLE tag to always have a visual indicator violates the widely accepted principle of separating content from presentation. If you want to use a selector to add a visual indicator, you're free to do so. (Let's not get side-tracked by the fact that Microsoft has not seen fit to support selectors. And yes I know I raised the point.) I don't happen to think it's necessary, and in fact I think it would get in the way of meaning, so I won't.

Criticizing the title attribute strikes me as a bit like expecting the standard to enforce good content creation practices. That's not what the standard is for. If you're only limiting your critique to Metafilter, that's a whole different discussion.
posted by lodurr at 8:21 AM on November 26, 2007

“Expecting the TITLE tag to always have a visual indicator violates the widely accepted principle of separating content from presentation.”

I disagree. Every graphical browser has built-in default styles for the basic HTML elements. Although these styles are customizable, it is certainly important to have a default presentation style in order to distinguish links, headlines, and lists from normal text. The title attribute is poorly implemented in this sense because the default presentation is for it to be completely hidden.
posted by breaks the guidelines? at 8:37 AM on November 26, 2007

I don't think anyone is really criticizing the attribute. What is being discussed is the role of such "revealed as requested" elements in the design of a good metafilter post. The Black Friday post failed on two issues that are relevant here:

1) It hid the definition of "Black Friday" (an Americanism) behind a "revealed as requested" feature with variable implementation across browsers and platforms.

2) It included multiple youtube links with no visible separation between links.

The title tag is a nice addition, but anyone using the title attribute should assume that the end user is not going to perform whatever magical steps are needed to display it. In this case, the post would have been improved by 1) adding or linking to a definition of Black Friday. 2) providing some context to the links rather than dumping one link per word in a sentence.
posted by KirkJobSluder at 8:43 AM on November 26, 2007

Well, if one uses the "white" theme and enables Mefi's optional Inline YouTube support, those are all non-issues: The white theme outlines anchored text with dotted[/dashed] lines, and the YouTube widget gives you a nice arrow that will let you watch the video without even going to a new page.

So, Matt was ahead of all of us on this one.
posted by lodurr at 9:01 AM on November 26, 2007

I’m not sure to what your referring by “anchored text.” Do you mean the phrase “Black Friday” in that post? If so, the dotted border on that text is not part of MeFi’s style—Firefox and Opera apply a border to the abbr element, which is how the phrase was marked up, but the presence of a title attribute has no bearing on that.
posted by breaks the guidelines? at 10:29 AM on November 26, 2007

Certainly, and it's not an issue for the small number of people who downloaded my userscript, or who use any number of custom styles that are available. But the mefi audience includes people using the lofi interface, readers using RSS aggregators, readers using mobile phones, and readers using voice browsing. The basic principle I'm proposing is that a good post shouldn't depend on the reader's choice of optional browser, themes, javascript enhancements, stylesheets, or metafilter settings.
posted by KirkJobSluder at 10:38 AM on November 26, 2007

by george, breaks, you're right, it's abbr, not 'a'.

That said, I do now remember the standard rendering for 'a' in the MeFi stylesheet is 'font weight: bold'. No appearance of affordance for clicking or hovering.

KirkJobSluder, now I'm not sure I understand what you're after. You want a better UI for MeFi, but not using MeFi features? The "Display YouTube Video inline?" setting renders YouTube links painfully, almost disruptively visible (it's actually kind of cool to see the violence done to MLYTPs*). As for people making bad FPP formatting decisions -- well, how much do you want to try to control their behavior? Unless you just strip out TITLE, you're not going to block people from using it, and no tool short of rigorous moderator-driven deletion is going to get people to improve the information content of their links.

It would probably not be too difficult to include an optional feature that added a little widget after all links that have title tags.

--
*Multi-Link YouTube Posts
posted by lodurr at 11:33 AM on November 26, 2007

A community that is able to respectfully and thoughtfully examine how to improve the content that appears on the front page would be nice. And part of that would include some thought about how we use title attributes, and construct hyperlinks, leading to perhaps some good advice in the guidelines.

And as I said above, if this was my site both the link-per-word and especially link-per-syllable and link-per-character mystery-meat would vanish without apology. Failing that, I'm happy to pass along the end-user technical solutions to the problem.
posted by KirkJobSluder at 12:29 PM on November 26, 2007

KirkJobSluder : "... contrast with this post which uses commas to cleanly separate link boundaries" ... "a bookmarklet (opera and gecko only) to add a light marker for link boundaries..."

If only there were some bog-standard cross-browser method of delineating between adjacent characters in a single link and adjacent links in rendered HTML.

Damn you, W3C, for ignoring such basic usability concerns!

I mean, really, what were they thinking? You could do it with a simple underline or something...
posted by Pinback at 4:17 PM on November 26, 2007