Web Developer Basics: Link Relations In HTML5
In the first installment of this series, we introduced HTML5 and saw how much of its most basic syntax is far more simple and direct than the way most developers are used to coding. In this article, we'll look at some other basic tags and see some of the power of the language. A great deal of this power is due to the fact that browsers are becoming so powerful themselves that they can almost be looked at as "display engines". So HTML5 lets you design and code at a higher level conceptually, leaving some of the implementation details to the browser.
Links That Make You Think
We're all used to coding links to things like other web pages and images. HTML5 introduces the concept of link relations, which essentially allows you to specify why you're linking to a particular resource, in order to help the program reading the page how to process it. For instance, coding <link rel="sidebar" href="URL"> indicates to the browser that it should open the target URL in a sidebar or secondary window (if possible), while using <link rel="tag" href="URL"> indicates to a search engine that the target URL should be used as a keyword for the current document.
Link relations are categorized into external resources and hyperlinks. Both of these obviously can (and usually do) refer to external documents. But a hyperlink is something you must click on to activate, so it's not necessary for the browser to "do" anything special with it in order to process and display the page. On the other hand, an external resource must be processed by the browser. Examples of currently defined external resources include the stylesheet, shortcut icon, pingback server, and prefetch.
Stylesheet: All developers are familiar with the concept of storing stylesheets in a separate file, so that they can be included across all pages in a site and changed in only a single place. The syntax is simpler in HTML5; you can now write <link rel="stylesheet" href="htmlgoodies.css"> without having to specify the language type as CSS...because CSS is the only language used anyway.
Shortcut Icon: This is also a familiar concept, because up to now it's almost always been used as <link rel="shortcut icon" href="/favicon.ico">. The new part is that you can now specify a number of different icons for different purposes, and in different sizes. For example:
<link rel=icon href="favicon.ico">
<link rel=icon href="mac.icns" sizes="128x128 512x512 8192x8192 32768x32768">
<link rel=icon href="iphone.png" sizes="57x57" type="image/png">
<link rel=icon href="gnome.svg" sizes="any" type="image/svg+xml">
And these may all be specified exactly like that in a single HTML5 file! The browser, after identifying the target hardware (default, Mac, iPhone, or Linux, in this case) can decide for itself which is the most appropriate icon and size to use. In the last case, the SVG file is vector-based, so "any" size can be used and the browser will scale it as needed.
Pingback Server: Developers don't usually worry about pingbacks per se; they're more of a concern to bloggers. A pingback essentially allows the author of a document to get a notification when someone has linked to their document (the complete specification can be found here). The syntax is simply <link rel="pingback" href="URL">.
Prefetch: This is a hint to the browser that it would probably be a good idea for it to retrieve and cache the URL it's pointing to, for the convenience of the user (who is almost surely going to click on it any second). It's almost always used by search engines when they build result pages, as the first one or two results are very likely to be clicked. The now-familiar syntax is <link rel="prefetch" href="URL">.
That leaves us with the other new link relations that consist of hyperlinks. We've covered a few of these above, but now you can literally specify relationships to the current document. First, last, prev, up, and next are all actual link types. For many purposes, the full collection of relations will make research users much happier, because you can also specify author information, a link to associated archives, the terms of a copyright license, index, or search interface.
Again, it's important to remember that the benefits of coding pages with this information at the present time may not be immediately apparent, but it will pay big dividends down the line when new browsers and other software tools are able to parse this information. They'll be able to display and use it in ways we might not even be able to imagine now.