David Goss

The case for rel="enlarge" in HTML5

Posted in Uncategorized by dvdgoss on April 26, 2010

Lately I’ve been following the development of HTML5 with interest, and have come across the WHATWG RelExtensions Wiki, which lists proposed legal rel values. Having seen what I feel is a gap, I have decided to propose one of my own.

Currently there is no standard way to indicate that a link points to an enlarged version of the image it contains. I propose that there should be one in the form of a value “enlarged” on the rel attribute.


To be clear, we are talking about anchor elements that contain one child image element, where the link points to an image file which is the same as the source of the child image element except a larger size (in dimensions -file size isn’t relevant). To make things easy, we’ll call the image file being linked to the “target” and the link’s child image the “thumbnail”. In the example below, the target is a 500×500 image of a sweater, and the thumbnail is a 75×75 version of the same image.

<a href="blue-sweater-500.jpg"><img alt="Blue Sweater" src="blue-sweater-75.jpg" /></a>

That shows the scenario in its simplest form. There could easily be another scenario, for instance, where the target is a rectangular image but the layout of the page dictates that the thumbnail must be square. In this case, the thumbnail would be a smaller and cropped version of the target. I still think this is acceptable.

Use cases

The use cases for this standard are widespread and common:

  • A set of product shots on an e-commerce site.
  • A series of screenshots on a tutorial.
  • A collection of photos on a gallery site.


The rel attribute is used for describing the relationship between the document being linked to and the current document, as in the most commonly used example rel="stylesheet" used on link elements to indicate the file being linked to is a stylesheet for the current document. What we are saying with rel="enlarged" is that “the file being linked to is an enlarged version of an image within the current document” or more specifically “the file being linked to is an enlarged version of the image within this link”.

You could argue that this stretches the concept of the rel attribute a little, since we are describing a relationship to one element on a document rather than the whole document. You’d be right, but I feel it’s an acceptable stretch and a more suitable solution than using the class attribute or adding a new attribute.

I spent quite a bit of time thinking about which word would be best for this. After discarding things like “zoom” and “magnify”, which could imply that the target is an enlarged version of only part of the thumbnail, I settled on “enlarged”, but I would be grateful for any better suggestions either in the comments here or on the WHATWG wiki as I still don’t think it’s perfect.


  • Using rel=”enlarged” would provide a semantic hook for stylesheets, enabling authors, users and user agents to visually differentiate such links if desired.
  • Using rel=”enlarged” would provide a semantic hook for scripts which are commonly used to override the default behaviour of such links and provide an on-page ¬†slideshow-style interface to improve the user experience. Many such scripts use their own rel or class value as a hook – hopefully the introduction of a standard would make this less common.
  • Using rel=”enlarged” would provide a semantic hook for user agents to improve the default behaviour for such links, where either a script like those described above is implemented by the author and the user has JavaScript disabled, or no script is implemented by the author.

I am going to list here any sites which use rel="enlarged". Please comment with the URL if your know a site that does use it, and I will add it to the page.

CSS3 restraint

Posted in Uncategorized by dvdgoss on April 12, 2010

Over the last six months I’ve gotten increasingly excited about CSS3 and how it will improve things for the front-end developer. Because I generally build pages rather than applications, I would go so far as to say CSS3 is as important as HTML5, at least from my perspective.

Not for the usual reasons, though. Whilst I’m delighted to have things like shadows and rounded corners native to CSS, ultimately these visual flourishes are exactly that – flourishes. The design can do without them if they aren’t supported, and it’s encouraging to see more and more people going down that progressive enhancement path with their work.

Typically, what excites me the most are the boring parts. Selectors, for a start. Things like even, first-child and nth-of-type can eliminate the need for a lot of extra class values in markup, particularly in things like tables and lists. With Internet Explorer development seemingly going at full speed, we could reasonably expect a switch to full reliance on these selectors within a few years.

Media queries have also got my attention. Phones with full web browsers (not to mention the iPad and its inevitable copies) are fast on increase, and being able to serve different style sheets to browsers depending on screen size will be of huge benefit – I think we will see less and less mobile versions of sites as a result.

Happily, lots of other people are excited about my third choice: RGBA colour. Most designers and developers will know how much of a pain in the backside opacity is to work with. RGBA beats opacity in most cases, mainly because you can apply different transparencies to text and its container. I also love how easy life is if your colour scheme is based on lighter shades of the one colour. In some cases, you can have the entire page’s colour scheme running off one value, which you can change instantly to transform the page.

Multiple columns are long overdue, but they are coming in CSS3 to free us from some awkward uses of floats to achieve what should be easy.

The best thing about all this, though, is its backwards compatibility. Selectors, media queries, RGBA and multiple columns will all simply be ignored by browsers that don’t understand them, and safe fallbacks for those browsers are easy to implement in all cases (either that, or fallbacks aren’t needed at all).

A few people have predicted that, with the mainstream arrival of web fonts, 2010 will be a year in which we’ll see typography put to terrible use. I agree, but I also think CSS3 could be abused to equal levels of horror. I’ve found myself looking at elements and thinking “ooh, I could round that corner” and “hey, that image could have a shadow” only to realise I would be using those styles just for the sake of it. Let’s hope restraint is shown all round, or we could have some silly looking websites…