Tags: 24ways



Wednesday, June 7th, 2017

A day without Javascript

Charlie conducts an experiment by living without JavaScript for a day.

So how was it? Well, with just a few minutes of sans-javascript life under my belt, my first impression was “Holy shit, things are fast without javascript”. There’s no ads. There’s no video loading at random times. There’s no sudden interrupts by “DO YOU WANT TO FUCKING SUBSCRIBE?” modals.

As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!

This has made me appreciate the number of large sites that make the effort to build robust sites that work for everybody. But even on those sites that are progressively enhanced, it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.

Monday, December 19th, 2016

Front-End Developers Are Information Architects Too ◆ 24 ways

Some great thoughts here from Francis on how crafting solid HTML is information architecture.

Friday, December 9th, 2016

Get the Balance Right: Responsive Display Text ◆ 24 ways

Some really great CSS tips from Rich on sizing display text for multiple viewports.

Thursday, December 8th, 2016

What the Heck Is Inclusive Design? ◆ 24 ways

I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.

He also includes some tips which read like design principles to me:

  • Involve code early
  • Respect conventions
  • Don’t be exact
  • Enforce simplicity

Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.

Sunday, December 4th, 2016

Fractal ways

24 Ways is back! That’s how we web nerds know that the Christmas season is here. It kicked off this year with a most excellent bit of hardware hacking from Seb: Internet of Stranger Things.

The site is looking lovely as always. There’s also a component library to to accompany it: Bits, the front-end component library for 24 ways. Nice work, courtesy of Paul. (I particularly like the comment component example).

The component library is built with Fractal, the magnificent tool that Mark has open-sourced. We’ve been using at Clearleft for a while now, but we haven’t had a chance to make any of the component libraries public so it’s really great to be able to point to the 24 Ways example. The code is all on Github too.

There’s a really good buzz around Fractal right now. Lots of people in the design systems Slack channel are talking about it. There’s also a dedicated Fractal Slack channel for people getting into the nitty-gritty of using the tool.

If you’re currently wrestling with the challenges of putting a front-end component library together, be sure to give Fractal a whirl.

Thursday, December 10th, 2015

Putting My Patterns through Their Paces ◆ 24 ways

Ethan demonstrates progressive enhancement at the pattern level using flexbox.

I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.


Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Tuesday, December 9th, 2014

Responsive Enhancement

This article first appeared in 24 Ways, the online advent calendar for geeks.

24 Ways has been going strong for ten years. That’s an aeon in internet timescales. Just think of all the changes we’ve seen in that time: the rise of Ajax, the explosion of mobile devices, the unrecognisably-changed landscape of front-end tooling.

Tools and technologies come and go, but one thing has remained constant for me over the past decade: progressive enhancement.

Progressive enhancement isn’t a technology. It’s more like a way of thinking. Instead of thinking about the specifics of how a finished website might look, progressive enhancement encourages you to think about the fundamental meaning of what the website is providing. So instead of thinking of a website in terms of its ideal state in a modern browser on a nice widescreen device, progressive enhancement allows you to think about the core functionality in a more abstract way.

Once you’ve figured out what the core functionality is—adding an item to a shopping cart, or posting a message, or sharing a photo—then you can enable that functionality in the simplest possible way. That usually means starting with good old-fashioned HTML. Links and forms are often all you need. Then, once you’ve got the core functionality working in a basic way, you can start to enhance to make a progressively better experience for more modern browsers.

The advantage of working this way isn’t just that your site will work in older browsers (albeit in a rudimentary way). It also ensures that if anything goes wrong in a modern browser, that it won’t be catastrophic.

There’s a common misconception that progressive enhancement means that you’ll spend your time dealing with older browsers, but in fact the opposite is true. Putting the basic functionality into place doesn’t take very long at all. And once you’ve done that, you’re free to spend all your time experimenting with the latest and greatest browser technologies, secure in the knowledge that even if they aren’t universally supported yet, that’s okay: you’ve already got your fallback in place.

The key to thinking about web development this way is realising that there isn’t one final interface—there could be many, slightly different interfaces depending on the properties and capabilities of any particular user agent at any particular moment. And that’s okay. Websites do not need to look the same in every browser.

Once you truly accept that, it’s an immensely liberating idea. Instead of spending your time trying to make websites look the same in wildly varying browsers, you can spend your time making sure that the core functionality of what you’re building works everywhere, while providing the best possible experience for more capable browsers.

Allow me to demonstrate with a simple example: navigation.

Step One: Core Functionality

Let’s say we’ve got a straightforward website about the twelve days of Christmas, with a page for each day. The core functionality is pretty clear:

  1. To read about any particular day, and
  2. To browse from day to day.

The first use-case is easily satisfied by marking up the text with headings, paragraphs, and all the usual structural HTML elements. The second use-case is satisfied by providing a list of good ol’ hyperlinks.

Now where’s the best place to position this navigation list? Personally, I’m a big fan of the jump-to-footer pattern. This puts the content first and the navigation second. At the top of the page there’s a link with an href attribute pointing to the fragment identifier for the navigation.

  <main role="main" id="top">
    <a href="#menu" class="control">Menu</a>
  <nav role="navigation" id="menu">
    <a href="#top" class="control">Dismiss</a>

See the footer-anchor pattern in action.

Because it’s nothing more than a hyperlink, this works in just about every browser since the dawn of the web. Following hyperlinks is what web browsers were made to do (hence the name).

Step Two: Layout as an Enhancement

The footer-anchor pattern a particularly neat solution on small-screen devices, like mobile phones. Once more screen real-estate is available, I can use the magic of CSS to reposition the navigation above the content. I could use position: absolute, flexbox, or in this case, display: table.

@media all and (min-width: 35em) {
  .control {
    display: none;
  body {
    display: table;
  [role="navigation"] {
    display: table-caption;
    columns: 6 15em;

See the wide-screen styles in action

Step Three: Enhance!

Right. At this point I’m providing core functionality to everyone, and I’ve got nice responsive styles for wider screens. I could stop here, but the real advantage of progressive enhancement is that I don’t have to. From here on, I can go crazy adding all sorts of fancy enhancements for modern browsers, without having to worry about providing a fallback for older browsers—the fallback is already in place.

What I’d really like is to provide a swish off-canvas pattern for small-screen devices. Here’s my plan:

  1. Position the navigation under the main content.
  2. Listen out for the .control links being activated and intercept that action.
  3. When those links are activated, toggle a class of .active on the body.
  4. If the .active class exists, slide the content out to reveal the navigation.

Here’s the CSS for positioning the content and navigation:

@media all and (max-width: 35em) {
  [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .active [role="main"] {
    transform: translateX(-75%);

In my JavaScript, I’m going to listen out for any clicks on the .control links and toggle the .active class on the body accordingly:

(function (win, doc) {
  'use strict';
  var linkclass = 'control',
    activeclass = 'active',
    toggleClassName = function (element, toggleClass) {
      var reg = new RegExp('(\s|^)' + toggleClass + '(\s|$)');
      if (!element.className.match(reg)) {
        element.className += ' ' + toggleClass;
      } else {
        element.className = element.className.replace(reg, '');
    navListener = function (ev) {
      ev = ev || win.event;
      var target = ev.target || ev.srcElement;
      if (target.className.indexOf(linkclass) !== -1) {
        toggleClassName(doc.body, activeclass);
  doc.addEventListener('click', navListener, false);
}(this, this.document));

I’m all set, right? Not so fast!

Cutting the Mustard

I’ve made the assumption that addEventListener will be available in my JavaScript. That isn’t a safe assumption. That’s because JavaScript—unlike HTML or CSS—isn’t fault-tolerant. If you use an HTML element or attribute that a browser doesn’t understand, or you use a CSS selector, property or value that a browser doesn’t understand, it’s no big deal. The browser will just ignore what it doesn’t understand: it won’t throw an error, and it won’t stop parsing the file.

JavaScript is different. If you make an error in your JavaScript, or use a JavaScript method or property that a browser doesn’t recognise, that browser will throw an error, and it will stop parsing the file. That’s why it’s important to test for features before using them in JavaScript. That’s also why it isn’t safe to rely on JavaScript for core functionality.

In my case, I need to test for the existence of addEventListener:

(function (win, doc) {
  if (!win.addEventListener) {
}(this, this.document));

The good folk over at the BBC call this kind of feature-test cutting the mustard. If a browser passes the test, it cuts the mustard, and so it gets the enhancements. If a browser doesn’t cut the mustard, it doesn’t get the enhancements. And that’s fine because, remember, websites don’t need to look the same in every browser.

I want to make sure that my off-canvas styles are only going to apply to mustard-cutting browsers. I’m going to use JavaScript add a class of .cutsthemustard to the document:

(function (win, doc) {
  if (!win.addEventListener) {
  var enhanceclass = 'cutsthemustard';
  doc.documentElement.className += ' ' + enhanceclass;
}(this, this.document));

Now I can use the existence of that class name to adjust my CSS:

@media all and (max-width: 35em) {
  .cutsthemustard [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  .cutsthemustard [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .cutsthemustard .active [role="main"] {
    transform: translateX(-75%);

See the enhanced mustard-cutting off-canvas navigation. Remember, this only applies to small screen screens so you might have to squish your browser window.

Enhance All The Things!

This was a relatively simple example, but it illustrates the thinking behind progressive enhancement: once you’re providing the core functionality to everyone, you’re free to go crazy with all the latest enhancements for modern browsers.

Progressive enhancement doesn’t mean you have to provide all the same functionality to everyone—quite the opposite. That’s why it’s so key to figure out early on what the core functionality is, and make sure that it can be provided with the most basic technology. But from that point on, you’re free to add many more features that aren’t mission-critical. You should be rewarding more capable browsers by giving them more of those features, such as animation in CSS, geolocation in JavaScript, and new input types in HTML.

Like I said, progressive enhancement isn’t a technology. It’s a way of thinking. Once you start thinking this way, you’ll be prepared for whatever the next ten years throws at us.

Responsive Enhancement ◆ 24 ways

My contribution to this year’s edition of the web’s best advent calendar.

Monday, December 8th, 2014

Websites of Christmas Past, Present and Future ◆ 24 ways

A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.

Friday, December 2nd, 2011

Clean conditional loading

It’s December. That means it’s time for the geek advent calendars to get revved up again:

For every day until Christmas Eve, you can find a tasty geek treat on each of those sites.

Today’s offering on 24 Ways is a little something I wrote called Conditional Loading for Responsive Designs. It expands on the technique I’m using on Huffduffer to conditionally load inessential content into a sidebar with Ajax where the layout is wide enough to accommodate it:

if (document.documentElement.clientWidth > 640) {
// Use Ajax to retrieve content here.

In that example, the Ajax only kicks in if the viewport is wider than 640 pixels. Assuming I’ve got a media query that also kicks in at 640 pixels, everything is hunky-dory.

But …it doesn’t feel very to have that 640 pixel number repeated in two places: once in the CSS and again in the JavaScript. It feels particularly icky if I’m using ems for my media query breakpoints (as I often do) while using pixels in JavaScript.

At my recent responsive enhancement workshop in Düsseldorf, Andreas Nebiker pointed out an elegant solution: instead of testing the width of the viewport in JavaScript, why not check for a style change that would have been executed within a media query instead?

So, say for example I’ve got some CSS like this:

@media all and (min-width: 640px) {
    [role="complementary"] {
        width: 30%;
        float: right;

Then in my JavaScript I could test to see if that element has the wide-screen layout or not:

var sidebar = document.querySelector('[role="complementary"]'),
floating = window.getComputedStyle(sidebar,null).getPropertyValue('float');
if (floating == 'right') {
// Use Ajax to retrieve content here.

Or something like that. The breakpoint is only ever specified once so I ever change it from 640 pixels to something else (like 40 ems) then I only have to make that change in one place. Feel free to grab the example and play around with it.

By the way, you’ll notice that in the original 24 Ways article and also in this updated example, I’m only testing the layout on page load, not on page resize. It would be fairly easy to add in an onResize test as well, but I’m increasingly coming to the conclusion that—apart from the legitimate case of orientation change on tablets—the only people resizing their browser windows after the page loads are web designers testing responsive designs. Still, it would be nice to get some more data to test that hypothesis.

Conditional Loading for Responsive Designs

This article first appeared in 24 Ways, the online advent calendar for geeks.

On the eighteenth day of last year’s 24 ways, Paul Hammond wrote a great article called Speed Up Your Site with Delayed Content. He outlined a technique for loading some content — like profile avatars — after the initial page load. This gives you a nice performance boost.

There’s another situation where this kind of delayed loading could be really handy: mobile-first responsive design.

Responsive design combines three techniques:

  • a fluid grid
  • flexible images
  • media queries

At first, responsive design was applied to existing desktop-centric websites to allow the layout to adapt to smaller screen sizes. But more recently it has been combined with another innovative approach called mobile first.

Rather then starting with the big, bloated desktop site and then scaling down for smaller devices, it makes more sense to start with the constraints of the small screen and then scale up for larger viewports. Using this approach, your layout grid, your large images and your media queries are applied on top of the pre-existing small-screen design. It’s taking progressive enhancement to the next level.

One of the great advantages of the mobile-first approach is that it forces you to really focus on the core content of your page. It might be more accurate to think of this as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essential.

But what happens when you apply your media queries for larger viewports and you do have sidebars and multiple columns? Well, you can load in that nice-to-have content using the same kind of Ajax functionality that Paul described in his article last year. The difference is that you first run a quick test to see if the viewport is wide enough to accommodate the subsidiary content. This is conditional delayed loading.

Consider this situation: I’ve published an article about cats and I’d like to include relevant cat-related news items in the sidebar …but only if there’s enough room on the screen for a sidebar.

I’m going to use Google’s News API to return the search results. This is the ideal time to use delayed loading: I don’t want a third-party service slowing down the rendering of my page so I’m going to fire off the request after my document has loaded.

Here’s an example of the kind of Ajax function that I would write:

var searchNews = function(searchterm) {
    var elem = document.createElement('script');
    elem.src = 'http://ajax.googleapis.com/ajax/services/search/news?v=1.0&q='+searchterm+'&callback=displayNews';

I’ve provided a callback function called displayNews that takes the JSON result of that Ajax request and adds it an element on the page with the ID newsresults:

var displayNews = function(news) {
    var html = '',
    items = news.responseData.results,
    total = items.length;
    if (total>0) {
        for (var i=0; i<total; i++) {
            var item = items[i];
            html+= '<article>';
            html+= '<a href="'+item.unescapedUrl+'">';
            html+= '<h3>'+item.titleNoFormatting+'</h3>';
            html+= '</a>';
            html+= '<p>';
            html+= item.content;
            html+= '</p>';
            html+= '</article>';
        document.getElementById('newsresults').innerHTML = html;

Now, I can call that function at the bottom of my document:


If I only want to run that search when there’s room for a sidebar, I can wrap it in an if statement:

if (document.documentElement.clientWidth > 640) {

If the browser is wider than 640 pixels, that will fire off a search for news stories about cats and put the results into the newsresults element in my markup:

<div id="newsresults">
<!-- search results go here -->

This works pretty well but I’m making an assumption that people with small-screen devices wouldn’t be interested in seeing that nice-to-have content. You know what they say about assumptions: they make an ass out of you and umptions. I should really try to give everyone at least the option to get to that extra content:

<div id="newsresults">
<a href="http://www.google.com/search?q=cats&tbm=nws">Search Google News</a>

See the result

Visitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.

I’ve been concentrating on HTML and JavaScript, but this technique has consequences for content strategy and information architecture. Instead of thinking about possible page content in a binary way as either ‘on the page’ or ‘not on the page’, conditional loading introduces a third ‘it’s complicated’ option.

This was just a simple example but I hope it illustrates that conditional loading could become an important part of the content-first responsive design approach.

Update: I’ve published some further thoughts on clean conditional loading

Wednesday, December 1st, 2010

The 24 Ways Annual 2010 | Five Simple Steps

All of this year's 24Ways articles are available as an £8 book with all the proceeds going to UNICEF.

Thursday, December 31st, 2009

The future of the tradition

Drew and Brian did a superb job with this year’s 24 Ways, the advent calendar for geeks. There were some recurring themes: HTML5 from Yaili, Bruce and myself; CSS3 from Drew, Natalie and Rachel; and workflow from Andy and Meagan.

The matter of personal projects was also surprisingly prevalent. Elliot wrote A Pet Project is For Life, Not Just for Christmas and Jina specifically mentioned Huffduffer in her piece, Make Out Like a Bandit. December was the month for praising personal projects: that’s exactly what I was talking about at Refresh Belfast at the start of the month.

If you don’t have a personal project on the go, I highly recommend it. It’s a great way of learning new skills and experimenting with new technology. It’s also a good safety valve that can keep you sane when work is getting you down.

Working on Huffduffer is a lot of fun and I plan to keep iterating on the site whenever I can. But the project that I’ve really invested my soul into is The Session. Over the past decade, the site has built up a large international community with a comprehensive store of tunes and sessions.

Running any community site requires a lot of time and I haven’t always been as hands-on as I could have been with The Session. As a result, the discourse can occasionally spiral downwards into nastiness, prompting me to ask myself, Why do I bother? But then when someone contributes something wonderful to the site, I’m reminded of why I started it in the first place.

My dedication to the site was crystallised recently by a sad event. A long-time contributor to the site passed away. Looking back over the generosity of his contributions made me realise that The Session isn’t a personal project at all: it’s a community project, and I have a duty to enable the people in the community to connect. I also have a duty to maintain the URLs created by the community (are you listening, Yahoo?).

I feel like I’ve been neglecting the site. I could be doing so much more with the collective data, especially around location. The underlying code definitely needs refactoring, and the visual design could certainly do with a refresh (although I think it’s held up pretty well for such a long-running site).

I’m not going to make a new year’s resolution—that would just give me another deadline to stress out about—but I’m making a personal commitment to do whatever I can for The Session in 2010.

Wednesday, December 10th, 2008

24 ways: A Christmas hCard From Me To You

A great 24 Ways article by Elliot on creating and styling hCards.

Monday, December 8th, 2008

Feedback loopy

24 Ways is back again this year. Today’s article is a little something I penned called The IE6 Equation. Share and enjoy!

The design of 24 Ways has been refreshed for this festive season and it has prompted quite a varied reaction. That’s always a good sign. You might love it or you might hate it but you’re probably not ambivalent about it. Veerle has written more on this subject, provocatively asking Do you innovate or opt for the safe route in web design?

The implementation prompted as much feedback as the design itself. Clearly, 24 Ways is a site with an immovable deadline. It’s an advent calendar so it must go live on December 1st. This year, that meant that some cross-browser issues weren’t sorted out on the first day. A few days after the site launched, everything was hunky-dory but in the interim, there was a clamour of epic fail! from indignant visitors to the site. I’m finding that Andy’s thoughts on this term of derision has become the canonical document to point people to for a healthy dose of perspective.

Merlin Mann’s observation, delivered in fewer than 140 characters, deserves to be framed and mounted next to every input device:

Some days, the web feels like 5 people trying to make something; 5k people turning it into a list; and 500MM people saying, “FAIL.”

If you’ve ever created anything on the web—a story, a picture, a video or an application—then you’ll be familiar with the range of responses that will result. I don’t just mean the laughably mindless babblings of the Diggtards and Reddidiots; I’m referring to that peculiar effect that sitting behind a monitor has on otherwise level-headed well-adjusted people. In the same way that some people undergo a Jekyll and Hyde transformation behind the wheel of a car, computer keyboards have a tendency to bring out the fuckwad in many of us—I include myself amongst that group.

The upshot of this effect is that criticism tends to be harsher online than if it were delivered in real life, which might just be due to the lack of . Should you find yourself on the receiving end of some criticism, having built a labour of love, I’ve put together a hierarchy of verb tenses by which you can weigh the feedback you’re receiving:

  1. Past. Advice from someone who has also built something is valuable. Their opinion is informed by experimental data.
  2. Present. If someone else is also building something, it’s worth paying attention to what they have to say.
  3. Conditional. This is the bottom of the pile. If someone describes what they “would” have done or what you “should” have done, it isn’t worth wasting your retinas on the photons of that feedback.

Although this hierarchy of verb tenses was prompted by web-native creations, it probably works equally well for film-making, plumbing, literature, dentistry, music, or just about any endeavour of the human spirit.

Monday, December 1st, 2008

24 ways: 2008

Rejoice! 24 Ways is back again. Prepare for 24 days of web development articles.

Saturday, December 1st, 2007


I don’t often get the chance to listen to many podcasts but when I do, there are a few that I have waiting in my iPod:

A recent addition to the podcast parade comes courtesy of Messrs. Hicks and Oxton. Broadcasting from their RAF base, they produce The Rissington PodcastGardener’s Question Time for the Web. The podcast also sports a brand new website that positively drips with delight. Go ahead and resize the browser window… admire that header, gasp at that footer.

See, this one of the reasons why I’m such a fan of liquid layouts. Not only do they feel inherently more “webby”, more in-tune with the medium, they also offer more capacity to delight. I know they’re harder to build. Fixed width layouts are certainly the easier option. But just as safe design won’t ever offend or excite, safe layouts won’t have quite the same propensity for delivering that warm glow of satisfaction that comes with having a website flow to fit the dimensions of your browser window. See also: Unstoppable Robot Ninja. Gorgeous.

But back to podcasts… I’m almost done with the dConstruct 2007 podcast—just one more talk left to put up. The presentations were ably recorded on the day by Drew. Speaking of whom, it’s that time of the year again: 24 Ways is back. Drew opens up the first window on the advent calendar with a piece on transparent PNGs in IE6. Expect another 23 high-quality articles to follow.

Monday, December 18th, 2006

Boost Your Hyperlink Power

This article first appeared in 24 Ways, the online advent calendar for geeks.

There are HTML elements and attributes that we use every day. Headings, paragraphs, lists and images are the mainstay of every Web developer’s toolbox. Perhaps the most common tool of all is the anchor. The humble a element is what joins documents together to create the gloriously chaotic collection we call the World Wide Web.

Anatomy of an Anchor

The power of the anchor element lies in the href attribute, short for hypertext reference. This creates a one-way link to another resource, usually another page on the Web:

<a href="http://allinthehead.com/">

The href attribute sits in the opening a tag and some descriptive text sits between the opening and closing tags:

<a href="http://allinthehead.com/">Drew McLellan</a>

“Whoop-dee-freakin’-doo,” I hear you say, “this is pretty basic stuff” – and you’re quite right. But there’s more to the anchor element than just the href attribute.

The Theory of relativity

You might be familiar with the rel attribute from the link element. I bet you’ve got something like this in the head of your documents:

<link rel="stylesheet" type="text/css" media="screen" href="styles.css" />

The rel attribute describes the relationship between the linked document and the current document. In this case, the value of rel is “stylesheet”. This means that the linked document is the stylesheet for the current document: that’s its relationship.

Here’s another common use of rel:

<link rel="alternate" type="application/rss+xml" title="my RSS feed" href="index.xml" />

This describes the relationship of the linked file – an RSS feed – as “alternate”: an alternate view of the current document.

Both of those examples use the link element but you are free to use the rel attribute in regular hyperlinks. Suppose you’re linking to your RSS feed in the body of your page:

Subscribe to <a href="index.xml">my RSS feed</a>.

You can add extra information to this anchor using the rel attribute:

Subscribe to <a href="index.xml" rel="alternate" type="application/rss+xml">my RSS feed</a>.

There’s no prescribed list of values for the rel attribute so you can use whatever you decide is semantically meaningful. Let’s say you’ve got a complex e-commerce application that includes a link to a help file. You can explicitly declare the relationship of the linked file as being “help”:

<a href="help.html" rel="help">need help?</a>

Elemental Microformats

Although it’s completely up to you what values you use for the rel attribute, some consensus is emerging in the form of microformats. Some of the simplest microformats make good use of rel. For example, if you are linking to a license that covers the current document, use the microformat:

Licensed under a <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">Creative Commons attribution license</a>

That describes the relationship of the linked document as “license.”

The microformat goes a little further. It uses rel to describe the final part of the URL of the linked file as a “tag” for the current document:

Learn more about <a href="http://en.wikipedia.org/wiki/Microformats" rel="tag">semantic markup</a>

This states that the current document is being tagged with the value “Microformats.”

, which stands for XHTML Friends Network, is a way of describing relationships between people:

<a href="http://allinthehead.com/" rel="friend">Drew McLellan</a>

This microformat makes use of a very powerful property of the rel attribute. Like the class attribute, rel can take multiple values, separated by spaces:

<a href="http://allinthehead.com/" rel="friend met colleague">Drew McLellan</a>

Here I’m describing Drew as being a friend, someone I’ve met, and a colleague (because we’re both Web monkies).

You Say You Want a revolution

While rel describes the relationship of the linked resource to the current document, the rev attribute describes the reverse relationship: it describes the relationship of the current document to the linked resource. Here’s an example of a link that might appear on help.html:

<a href="shoppingcart.html" rev="help">continue shopping</a>

The rev attribute declares that the current document is “help” for the linked file.

The microformat makes use of the rev attribute to allow you to qualify your links. By using the value “vote-for” you can describe your document as being an endorsement of the linked resource:

I agree with <a href="http://richarddawkins.net/home" rev="vote-for">Richard Dawkins</a>.

There’s a corresponding vote-against value. This means that you can link to a document but explicitly state that you don’t agree with it.

I agree with <a href="http://richarddawkins.net/home" rev="vote-for">Richard Dawkins</a> about those <a href="http://www.icr.org/" rev="vote-against">creationists</a>.

Of course there’s nothing to stop you using both rel and rev on the same hyperlink:

<a href="http://richarddawkins.net/home" rev="vote-for" rel="muse">Richard Dawkins</a>

The Wisdom of Crowds

The simplicity of rel and rev belies their power. They allow you to easily add extra semantic richness to your hyperlinks. This creates a bounty that can be harvested by search engines, aggregators and browsers. Make it your New Year’s resolution to make friends with these attributes and extend the power of hypertext.

Friday, December 1st, 2006

24 ways: 2006

It's baaa-aaaack!