Hrefless anchors — bring up information on anchor content

The anchor tag allows us to link to a destination (with a URL) or a thing (with a URN). However, very commonly on the web today, people incorrectly use URLs as a way to direct people to more information on a thing. This happens because there is currently no good alternative available.

e.g.: “We suggest you change your password due to the recent Heartbleed bug discovered in OpenSSL.”

The above is typical of many links found on the internet, and highlights 3 main problems:

1. The semantic issue that there is currently no way to express what you really want here. Instead of “show information about the Heartbleed bug”, you can only say “show this Wikipedia article about the Heartbleed bug”. Wikipedia often being chosen somewhat arbitrarily.

2. The person creating the link will often choose their favourite online encyclopedia at the time of authoring, whereas it would be better to use the user’s favourite encyclopedia at the time they follow the URL. The advantage being that the user is in control, and can use an encyclopedia that is on their own computer, or was created after the document was authored.

3. People often don’t bother to link things that users may want to read more about because of the time it takes to get the URL to the Wikipedia article. If an href wasn’t required, I probably would have linked OpenSSL as well, so that users who are interested could easily read about that as well.

So my proposal is that if there is an <a> tag without href or name attributes specified, browsers should take users to information about the text inside. This may involve performing a search for the text on some search engine, or going to the article on Wikipedia, but users should be able to configure this behavior.

I think this would have a positive effect on the web; like on Wikipedia, it would be easy to conveniently link things that users may want to read more about, saving users time and allowing them to get to the information they want with a single click.

The only downsides I can see is that this would reduce page ranking for sites that are currently linked to for general-purpose information, e.g. Wikipedia and Google, and that it could cause issues in some cases if you’re already using anchors without href for some reason - http://stackoverflow.com/questions/3186767/using-anchor-without-href-just-to-get-that-hover-effect

A new tag could be created to avoid the latter, but I feel that using the existing <a> tag would be better, as it seems very logical and, in many cases, would avoid systems requiring update to support the new tag.

I hope this proposal is useful and welcome feedback on it.

Above text taken from an old proposal I made on Bugzilla.

So are you talking about a generic anchor that does not point to a specific URL and just marks up some term? Wouldn’t the existing DFN element suitable for this purpose?

And FYI, the A element without the href attribute is sometimes used to mark up a link which is temporarily inactive: instead of replacing the link with another element like SPAN, its href attribute is just removed (e. g. to prevent a navigation-menu item from pointing to the same page the user is already viewing). Besides (non)clickability, there is some semantics here: link is link anyway (A element is used regardless of whether it is clickable), just inactive.

I don’t think <dfn> would be suitable. It marks up a defining instance of a term. E.g. “<p><dfn>HTML</dfn> is a markup language for web pages.</p>”

I’m talking about having a tag for the opposite: Marking up a term so that it links to a definition. E.g. “I use <a>HTML</a> to make web pages.”

I see your point about it breaking compatibility though, so perhaps another tag should be used, or an attribute to <a>.

One thing that would need to be addressed is keyboard interaction. It’s the href attribute that makes a link focusable with the keyboard, so without it it would be impossible for keyboard users to use the link.

Is this similar to Microsoft Edge’s “Ask Cortana” feature? You highlight some text, right-click, Ask Cortana, and a search is performed to try and locate information about the highlighted portion.

In your case, how does the user agent know how to locate more information? What does it do with ambiguities: for instance, if HTML is the text, how does it know to search for Hyper-Text Markup Language, rather than Hamburger, Tomato, Mayonnaise, and Lettuce?

This reminds me a bit of Smart Tags. Having the author mark up the entity is appealing; the user agent would not need to work so hard to extract entities, and authors would not be surprised by what is turning into links.

It is pretty common to use anchors without hrefs as targets, of course. But you could use anchors without hrefs or names.

I think the user agent could make these links keyboard-accessible when there is an “implied” href.

One thing that could be a bit of a concern is that one way to bootstrap knowledge about entities is by looking at what people link to on the web. If this method of linking became prevalent, actually doing the linking may get more difficult.

Yes, I think this would have some pretty worrisome implications.

Most browsers I use already have a function that lets you select anything and look it up - I use Yandex’ “translate on the fly” all the time.

You could probably use the mark element if you really wanted to highlight things that people should consider looking up - cue discussion - or we could mint a new element. I agree with Léonie that it’s important to work out keyboard accessibility, but a lot of that is about browser implementations, because most of them are not very good for making less-common interaction work well.

You could also use something like schema.org by adding RDFa or microdata to mark things you wanted to clarify are already explained elsewhere without imposing your idea of the best link…

As a human writing documents on the web, links are an important way I can help my reader understand the background and context of what I write. I choose links carefully, or I choose not to link, as a reader is already free to look up anything they want. I don’t quite understand this middle ground—something is important enough to need a link, but not important enough for the author to supply the link.

I’m guessing it would be easy to write some JS that would turn plain <a> elements into Wikipedia links, as an aid to authoring. But giving browsers the power and responsibility to interpret such links strikes me as changing the contract between the author and the presentation in a dangerous way.

@dauwhe hits the key issue here I think. If there’s a reason I’d mark it as a link I’d have half an idea where I’m linking it anyway. I could maybe see the idea of an extra attribute on <a> like reference that says “this href is just a suggestion”, a user could have an extension or a browser setting for their preferred reference source. An author might link to a Wikipedia article for some background information rather than than it being a specifically chosen resource so they mark it with the attribute. A user comes along who has set their preferred reference to Google and instead the browser takes them to a Google search for that topic.

Probably still not worth the hassle though.

It would just search for “HTML”, unless HTML was in an <abbr> tag, then it could use the title attribute, or we could add an attribute for this purpose.

Thanks for everyone’s feedback. Good points all around.

I do still think that URLs are often used incorrectly (e.g. linking to Wikipedia not because you want to direct readers to a Wikipedia page, but rather more information about something), and do believe @chaoaretasty’s idea of adding a reference attribute is a good one.

I’m not convinced that links are often used “incorrectly”. There is already a function in my browser to look up more or less anything I want more information about. Moreover, I am more likely than a page author to know what I want some generic information about - having the author guess, and add links all over the place on the off-chance is likely to make the page far less usable, in particular via keyboard.

So I agree with @chaoaretasty that this isn’t worth the hassle - and I would be surprised if browsers wanted to support it - or for that matter if there was a big demand from authors.