The case for rel="enlarge" in HTML5

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.

Scope

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.

Semantics

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.

Benefits

• 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

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…

IE6 users are people too

Ever since my (very late) entry to this industry, I’ve always had a bit of a problem with Internet Explorer 6. That is, I have a problem with other people’s problem with the problems that IE6 can cause.

IE6 is just one of those things. It’s a ballache, for sure, but it’s happened and you just have to deal with it, until one day you don’t. Thanks to efforts over the last few years from lots of people, including Microsoft, that day is drawing near. Yet so many people are still angry about it, and more importantly angry at IE6 users. These people are not morons, or stubborn, or obtuse, or backward. As Marcus correctly points out every time the topic is raised on Boagworld, they either don’t know or they don’t care.

The not knowing has always been a big part of the problem, and something which has recently been addressed (in Europe at least) by Microsoft being forced to deliver a “browser choice” screen to Windows users who only have IE installed. How successful this will be remains to be seen, but it should get at least some users upgrading from IE6 to IE8/9, which is great. The other bit is the not caring, and that’s what seems to get designers’ backs up:

“What do you mean you don’t care? Don’t you want a richer experience online?”

No, they do not. People simply are not bothered. After all, they get on fine with what they use now, so why change? The sensible practise of not fixing things that ain’t broke comes in, and if you take a step back from your role as a web professional then you’ll see that it’s a logical decision to make. Wrong, as we know, but still logical. The IE6 user, then, is neither enthusiast nor expert in the field of web browsers, which means that no matter how hard you try you’re unlikely to convince them they need to upgrade their IE or switch to a different browser. In fact, you probably fail as soon as you try, because there’s nothing worse than having someone’s opinion about a topic you have zero interest in forced on you.

So this leaves us with IE6 users who are going to be difficult to tempt from their old browser, which leaves you scratching your head because IE6 isn’t playing ball with your CSS. You might want to just say “screw it” and let IE6 users have the broken layout. If you’re a bit more extreme, you might want to serve them a very basic stylesheet or just unstyled semantic  markup. Alternatively, if you’re completely mental, you might want to block them from accessing the content altogether.

The third option is obviously never appropriate (unless you are running an app or site which is just too complex for IE6, in which case you should gracefully explain to the user why they can’t access the page and what they can do about it) and in my opinion neither is the second. It seems just a little spiteful, and that’s not really fair on IE6 users – they’re people too, and their money is as good as anyone else’s. The first option is acceptable if your stats tell you that IE6 users make up a low percentage of your visitors – too low, in other words, to recoup the cost of fixing the layout. Of course, you’re unlikely to literally do nothing, unless the problems are very minimal. More likely, you’ll link to the amazing IE7.js script by Dean Edwards which will patch IE6 with support for things like fixed positioning and alpha transparent PNGs. This is absolutely fine.

If your concentration of IE6 users is still around 10% or higher, then you ought to think a bit more carefully. If the IE7.js script fixes everything, great – but chances are it won’t. So instead, try going through the site in IE6 and writing down all of the problems. Personally, being a tiny bit out with some margins doesn’t count as a problem for me as long as the layout itself is intact – you might feel differently. So once you have your list, you can scrutinize each one to see if it really needs to be fixed, keeping in mind the characteristics of an IE6 user compared to other users.

A good example is my recent redesign of thackerays.co.uk, where the  IE6 stage was very brief. The first problem was inevitable, what with the layout making use of so many floats: IE6 was doubling the left and right margin values on floated block elements. This was fixed quickly by specifying these elements as display: inline in the IE6 stylesheet. Straight away, the layout looked familiar again. Next up were some areas where IE6 had not collapsed the top and bottom margins properly. I think this may have something to do with using the “clearfix” method for self-clearing floats on contaners for floated elements, but I’m not sure. Anyway, this was fixed by just overriding a handful of margin values in the IE6 stylesheet.

I then turned my attention to the navigation. The site uses a couple of “mega menu” elements to give users quick access to categories within the men’s and women’s departments. These menus consist of divs which are absolutely positioned within their parent list items and pushed off screen by negative margins. The :hover pseudo-class on the list item then pulls the margin back in so the menu is shown insantly on hover and with no JavaScript. Great, but IE6 only supports the :hover pseudo-class on anchor elements, and will ignore them for anything else, including list items. So, when IE6 users hover on one of the relevant list items, they get no mega menu. They can, however, click on the list item’s regular link, which takes them to a page containing all options that are in the mega menu, and more. Therefore, IE6 users wouldn’t know they were missing the mega menu and would still be able to navigate the site just as easily – albeit not as quickly. So that issue was simply left alone.

One thing I did do, though, was reconsider the CSS used for the content within the mega menus. Because it has different levels of divs and different levels of anchors, there were quite a few lines of CSS used to override inherited styles. Child selectors eliminate (or reduce) the need for this, but aren’t supported by IE6. This would be a problem anywhere else on the site, but since IE6 users are never going to see this mega menu, it doesn’t matter, so by switching the method to child selectors I was able to remove several lines of CSS and a couple of class attributes in the markup. So, analysing my IE6 problems was helping to improve my site for other browsers.

The only area left to look at was form inputs. To avoid adding lots of classes to the markup, I used attribute selectors in the CSS to style various types of input elements. Of course, IE first supported attribute selectors in version 7, so my poor IE6 users were being left with bog standard text fields, checkboxes and buttons. One solution I considered was to have a jQuery function slipped into the conditional comments which would add corresponding classes to input elements (e.g. input.button for buttons, input.text for text fields) and then apply my desired styles in the IE6 stylesheet. This would have worked fine, but I thought about the IE6 user first. They aren’t an expert or an enthusiast (or if they are, then they must be using IE6 against their will in which case they’ll be used to differences) and they’re running Windows XP or lower, so are they going to be scared off by seeing generic form elements? I don’t think so, especially when the site’s visual style is conservative and monochrome anyway.

And then…that’s it. All this was done in under an hour, which when we’re talking about (at time of writing) 10% of users is not bad at all. Those users are still getting a site that’s pleasing to look at and use, without compromising on load speed by downloading extra scripts. What’s more, because the IE6 styles are cordoned off in their own stylesheet, the work is done. I can leave it there forever, not having to worry about trawling through the main stylesheet and taking out the hacks once IE6 share is low enough.

Of course, I’m not saying this will work for every project – far from it – but in some cases this considered and minimal approach could be the most efficient and rewarding, and might cause you to be a bit less angry with people who use IE6. At least sometimes.

Other, possibly better articles elsewhere:

• The IE6 equation by Jeremy Keith http://24ways.org/2008/the-ie6-equation
• Univeral Internet Explorer 6 CSS by Andy Clarke http://forabeautifulweb.com/blog/about/universal_internet_explorer_6_css/

Buying time

People talk about “you can’t buy time”. I disagree with that – you can completely buy time. You can buy time with money…

Jason Fried asserts the direct relationship between time and money whilst talking to Dan Benjamin on The Pipeline.

Standing still with The Times

Given a choice of which newspaper to read, I’ll always go for The Times. I really hate most papers, and the people who read them, but I’ve always seen The Times as informative, considered and well-written.

As it turns out, that’s not always the case. Whilst flicking through today’s edition I spotted an article entitled “Google is failing consumers by profiting from scam websites” in the Money section. It begins with the suggestion that scam websites are “dominating” Google’s pay-per-click search listings and goes on to basically say that Google don’t care whether websites are bogus as long as they make lots of money, and that users shouldn’t take any notice of the pay-per-click section – they should choose from the organic listings instead.

As journalism goes, it’s pretty wide of the mark. Aside from factual inaccuracies and skewed statistics, it’s obvious the writer simply doesn’t understand how this medium works, or why thousands of genuine online businesses such as the one I work for use it.

Yes, there are fraudulent websites online. And yes, pay-per-click is an easy way for them to attract victims. But there’s no reason to make sweeping generalisations. The article itself quoted that, on average, 5.93% of PPC advertisers were found to be untrustworthy. This hardly constitutes domination of the medium, and the products mentioned as examples of higher risks are GHD styling irons and Ugg boots – both of which are brands notoriously afflicted by fakery. The fact is that the overwhelming majority of PPC advertisers are genuine businesses.

Besides, the organic listings are not all sweetness and light. In many industries (designer clothes is one of the worst) the higher ranking sites have used some sickening SEO techniques to achieve their page one prominence. Body copy is saturated with keywords to the point where reading it aloud would cause you to die of embarassment. Preposterously long text-only lists of “top products” assault your eyes from all sides of the page. Entire site maps are shoehorned into the footer. These sites may rank highly, but their user experience is shit.

To avoid playing this ridiculous SEO game, businesses can turn to pay-per-click. In the short term, it gets them instant and highly targeted traffic and provides a steady stream of sales. In the long term, their PPC campaigns will be honed for maximum efficiency whilst their well-designed, user-focused and semantically-coded site will eventually win out in the organic listings (so long as the content is right). In short, pay-per-click works, and it also keeps Google’s products free.

Of course, these concepts are probably lost on the writer of the Times article. It’s no coincidence that Google was singled out as the culprit even though the article itself states that Microsoft’s PPC network has a higher concentration of fraudsters. News Corp, parent company of The Times and headed by the charming Rupert Murdoch, very publicly dislike Google and want to block it from indexing any of their content. Google, though, will suffer no real damage from the attack. As ever, it’s small and medium sized businesses who use the medium that will lose money.

Unfortunately, my point of view is not likely to find much support, even if it’s expressed more publicly and articulately by someone with more influence. This brings us to the root cause of the problem: people. Nowadays, lots of people hate companies, especially really big ones like Google. They think that such profit-hungry companies are to blame for all the world’s ills and should be outlawed. Some might call these people “communists”, but I prefer the less political and more direct “morons”. So let’s say one of our morons clicks a pay-per-click ad and is subsequently conned by the bogus website at the end of the link. Someone like you or I would just suck it up and move on, or maybe try going after the people behind the bogus website. The moron, however, is angry and rather than admit their mistake, they will look for someone to blame. The obvious target is Google, a really big company who they hate and who gave them the link in the first place, so that’s where the anger is directed. The media and consumer organisations feed off this anger, and give it more public momentum so that article like the one in The Times are taken seriously.

Next time you come across one of these people, don’t give them the time of day. Or, if you have to be polite, at least give them the wrong time so their day gets messed up. Don’t worry, they won’t know you’re lying – they’re a moron, after all.