I just want one!

Okay, I didn’t actually register http://ʎɹɹɐɥ.com/, I registered what you might call its alias: http://xn--jna6b0ca7h.com. So, by that token, you find the upside down version of your domain (mine being harry) via this upside down letter converter, paste the result (mine being ʎɹɹɐɥ) into this IDN converter and add whatever domain extension (mine being .com) to the resulting string (mine being xn--jna6b0ca7h). You then register the outcome, and you can access it via the upside down version! http://ʎɹɹɐɥ.com/ is just an alias of http://xn--jna6b0ca7h.com/ in a sense…

If you view the source of this page you’ll see the markup actually links to http://ʎɹɹɐɥ.com/ but resolves to http://xn--jna6b0ca7h.com/ in the status bar when you hover it.

I want details!

If you want to actually understand the technicalities behind it, you ought to read the two articles linked previously.

Why would I need this?

You don’t, but it is cool, right? Although, you could use it as a pretty nifty short-URL for your blog on Twitter like Daring Fireball’s awesome http://✪df.ws one.

Which leads me on to…

You don’t have to have an upside down domain, you can use glyphs in there too. Grab some glyphs from CopyPasteCharacter and pop those into the converter too.

Registering your domain

This is not a plug…

I’ve heard reports of people being asked about languages for the IDNs from their registrar of choice. I went with Heart Internet and registered http://xn--jna6b0ca7h.com/ no trouble, just as if it was a regular domain.

Be sure to comment it you buy/have bought one yourself.

View demo

Look at the site in IE8, then Firefox, then Safari/Chrome. Keep refreshing.

I have created a demo page which simply represents three items of data expressed as percentages. It is not the data itself or the numbers we are concerned with here—it is the proof of concept. The fact that this can be done on my made up data shows that you can do it too, on real life information.

Progressive enhancement

At Venturelab, we decided to use progressive enhancement as a matter of course. CSS3 and designing in the browser all the way!

Progressive enhancement is, in my opinion, one of the most exciting schools of thought web development has seen in years (though I have only been in the web for three…). It is the idea whereby any non-essential features (i.e. anything whose absence will have no adverse effect on the usability or accessibility of a website) are added to the website in a progressive manner—usually through CSS3.

The benchmark example is rounded corners; to apply these through old means, for example with images, would have taken a developer a substantial amount of time—time the client is paying for. It seems silly now to think that way-back-when, putting rounded corners on a div might have taken upward of 30 minutes, when we can apply it in about 5 seconds using -moz-border-radius:5px;.

It really is a no brainer—anyone visiting the site in a browser with no CSS3 support will see square corners. Does this matter? Of course it doesn’t. No one visits a site to look solely at the design—they visit for content. Does it matter to them what shape the corners of your RSS button are? No again. Progressive enhancement saves you time, and your client money.

Isn’t this just graceful degradation?

Graceful degradation = building for the best and getting worse; progressive enhancement = building to cater the worst and getting better…

The line between progressive enhancement and graceful degradation is fine but significant. Graceful degradation is the idea that you’d build a site for, say, Firefox, then selectively break and downgrade it in the likes of IE(6). Progressive enhancement takes a much more positive attitude in that you build for IE(6) and then selectively upgrade it in browsers like Firefox and Safari. It’s no longer starting great and getting worse, it’s now starting great and getting better.

Internet Explorer

N.B. Only tested in IE8 as this is not a final solution, rather a proof-of-concept.

Internet Explorer(8)’s take on my bar charts is as you’d expect from any browser, it renders it perfectly well, providing clear, accessible content, with a flawless UX and perfectly usable. This is not bad! We don’t need to downgrade anything, this is our starting point. It looks good and it functions perfectly. If you did as above and visited in IE8 first, you wouldn’t know that there were round corners missing—because that doesn’t matter.

Firefox

Next up is Firefox, where we add some round corners to the blue bars, and also a very subtle drop shadow (text-shadow:;) on the text. This is no more usable than before, the content is no more accessible than in IE, but it does look a tad nicer.

Safari/Chrome

It is in Webkit based browsers such as Safari and Chrome that the real magic happens. Webkit’s proprietary CSS is above and beyond that of any other rendering engine…

What if I couldn’t be bothered opening Photoshop to make a subtle gradient .gif for the bars? No worries, use Webkit’s gradient CSS. A little reflection might look nice on the bars too, but I don’t fancy any superfluous markup or .pngs to fiddle with. Ah great, Webkit has a bit of reflection CSS too.

However, for the real show-piece, the Webkit animation. I’m not using any Javascript libraries anywhere else in the page so I don’t fancy pulling a whole one in for something that won’t really be missed if it’s not there. I hear Webkit has animations… magic!

The code

Now that’s the theory covered, let’s look at what does all this stuff… Please note, I have used some PHP to randomise the values used by the bars of the chart. As a result, some CSS appears in the source code of the PHP file, and the rest in the page’s CSS file. The code shown in the examples below is condensed into one large chunk.

The markup

The markup simply comprises of one uncluttered dl. The reasoning behind a definition list is that each item is a title, followed by some information about that title. Not only is this semantically correct, it’s a nice set of elements to be working with to achieve the layout we’ve got.

<dl id="chart">
  <dt>Sales increase this week</dt>
  <dd><span id="data-one">47%</dd>
  <dt>Revenue increase this week</dt>
  <dd><span id="data-two">59%</dd>
  <dt>Profit increase this week</dt>
  <dd><span id="data-three">26%</dd>
</dl>

That’s all there is to it.

The CSS, CSS3 and progressive enhancement

/*------------------------------------*\
  CHART
\*------------------------------------*/
#chart{
  width:520px;
}
#chart dt{
  width:160px;
  float:left;
  margin:0 20px 5px 0;
  padding:2px 0;
  display:inline;
  font-weight:bold;
  text-align:right;
}
#chart dd{
  width:339px;
  border-right:1px solid #ddd;
  float:left;
  margin-bottom:5px;
  display:inline;
}
#chart dd span{
  color:#fff;
  background:#09f;
  text-align:center;
  padding:2px 0;
  display:block;

  text-shadow:1px 1px 1px rgba(0,0,0,0.2);
  -moz-border-radius:2px;
  -webkit-border-radius:2px;
  border-radius:2px;
  background:-webkit-gradient(linear, left top, →
  left bottom, from(#09f), to(#077fd0));
  -webkit-box-reflect:below 0 →
  -webkit-gradient(linear, left top, →
  left bottom, from(rgba(0,0,0,0)), to(rgba(0,0,0,0.25)));
}
#data-one{
  width:47%;
}
#data-two{
  width:59%;
}
#data-three{
  width:26%;
}
#data-one{
  -webkit-animation-name:bar-one; /* Give the bar an animation with a
    unique name */
}
#data-two{
  -webkit-animation-name:bar-two; /* Give the bar an animation with a
    unique name */
}
#data-three{
  -webkit-animation-name:bar-three; /* Give the bar an animation with a
    unique name */
}
#data-one,#data-two,#data-three{ /* Define animation styles for all three
    bars at once */
  -webkit-animation-duration:0.5s; /* Animation duration in seconds */
  -webkit-animation-iteration-count:1; /* Amount of times to loop */
  -webkit-animation-timing-function:ease-out; /* Ease in, out etc. */
}
@-webkit-keyframes bar-one{
  0%{ /* Define bar-one styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-one styles at 100% (0.5 seconds) */
    width:47%;
  }
}
@-webkit-keyframes bar-two{
  0%{ /* Define bar-two styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-two styles at 100% (0.5 seconds) */
    width:59%;
  }
}
@-webkit-keyframes bar-three{
  0%{ /* Define bar-three styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-three styles at 100% (0.5 seconds) */
    width:26%;
  }
}

In detail

There may well be some bits in there that you’re not familiar with, particularly CSS animations. Basically, to animate an element you need to do a few things:

1. Assign the element an animation name. This name is the ‘hook’ to link an animation, defined later, to an element.

   #data-one{
     -webkit-animation-name:bar-one;
   }

2. Assign the element animation properties. Here you set things like duration, repetition and ease-in/out.

   #data-one,#data-two,#data-three{
     -webkit-animation-duration:0.5s;
     -webkit-animation-iteration-count:1;
     -webkit-animation-timing-function:ease-out;
   }

3. Set up the keyframes of the animation. Here you set the various points. Here we have one thing to animate through two states, so we simply set a beginning at 0% and and end at 100%. We could set at any percentage in between but as we just have a beginning and an end, we don’t need to—Webkit sees to that.

   @-webkit-keyframes bar-one{
     0%{
       width:0%;
     }
     100%{
       width:47%;
     }
   }

With regards the Webkit reflections, it may be a better idea to consult the Surfin’ Safari page on that, as anything I’d say would most likely be a poorly pulled off rehash.

Closing word

So there you have it, a real life, justifiable and wholly appropriate application of CSS3 and progressive enhancement coupled with data visualisation. Don’t be held back by the limitations of older browsers—relish in the opportunities new ones bring.

And as a final bonus, @VIPickering requested this (view in Safari/Chrome)… enjoy.

From my point of view, creating the widget could not have been simpler—simply writing some basic form HTML which posts to the blog will yield results, and it then just requires dropping into an XML document and placing on a live server, and linking to via the Netvibes developer centre.

You can view the ‘master’ XML document here: http://csswizardry.com/netvibes/index.xml

N.B. This article addresses iPhone development and iPhone development only. There is no reason why you cannot or should not develop for other mobile devices and platforms, Apple or otherwise. This just happens to be an iPhone only post.

The practical upshot of this is that you need to do no cross-browser testing, and can use all the CSS3 you like. This post will show you some of the basics of developing and designing websites for the iPhone and Mobile Safari.

To start

The first thing to remember when developing a site to be displayed on an iPhone is that it is very similar to designing a print stylesheet. You need to linearise everything. Make sure you have one column and everything is read in one line—straight from top to bottom. This will also put your markup writing skills to the test.

Some people don’t agree with browser sniffing, but you need to detect the iPhone somehow.

This first bit of code is a PHP browser sniffing snippet, the actual CSS we’ll use is not brought through via any server side code, we’ll use some CSS media queries for that. What we’ll use this code for is serving the markup with an iPhone specific meta tag and to shorten the current page’s title.

<?php
  $browser = strpos($_SERVER['HTTP_USER_AGENT'],"iPhone");
    if ($browser == true){
    $browser = 'iphone';
  }
?>

What the above code does is sees if the user agent contains any instance of ‘iPhone’ using the strpos PHP function. Place this piece of code at the very top of your header include, before any other markup. In order to action something if the browser is an iPhone, simply use the following bit of PHP logic in the place you want it to be initiated:

<?php if($browser == 'iphone'){ ?>DO THIS<?php } ?>

We want people to save your site to their home screen…

Now, to put that snippet to use. We want to do two things with this little piece of PHP.

Saving to the homescreen—shortening the page title

First off, we’d like users to be able to save a link to your site on their home screen, this is simple enough, they simply need to select to do so from within the browser. However, if you look at the title of my home page alone, it’s quite long: CSS Wizardry—CSS, Web Standards, Typography, and Grids by Harry Roberts. This would never fit underneath an icon without being shortened, so we need to serve a different title to the iPhone only. To achieve this we us the PHP snippet like so:

<?php if($browser == 'iphone'){ ?>
  <title>Short iPhone only title</title>
<?php }else{ ?>
  <title>Regular title</title>
<?php } ?>

Now, both when browsing and saving your site to their home screen, a user will only ever see the shortened version.

The home screen icon

Actually making the icon is very simple. All you need to do is upload a 57×57px icon (usually a larger version of your favicon) to your server root. The icon must be named apple-touch-icon.png, and the iPhone will sort the rest out. See my icon.

Stopping user pinch-zooming

The second use for the PHP snippet is to serve the iPhone a meta tag which disables the user pinch-zoom that Mobile Safari offers:

<?php if($browser == 'iphone'){ ?>
  <meta name="viewport"
  content="width=device-width,
  minimum-scale=1.0, maximum-scale=1.0" />
<?php } ?>

This means that, once we’ve linearised the content and sorted the font sizing, the user will only ever have to traverse down your page, much like a native app.

Beginning styling

Some developers prefer to redirect iPhone users to a totally different version of the site—we won’t be doing that.

We could use the PHP snippet to serve the iPhone a whole new stylesheet, or even send the user to a whole new site, rather like Twitter does (m.twitter.com). However, there’s a simpler way to do it using some CSS media queries. The advantage of this is that you’re simply reusing old content and pre-written markup, and only ever using one CSS file.

The first thing you need to do is make sure the HTML link element that points to your main stylesheet does not have a media attribute:

<link rel="stylesheet" type="text/css" href="/path/to/style.css" />

Next, we’re going to use Quick Tip #15 that I wrote on my Quick Tips page. This means that we can just add our iPhone styles directly onto the end of the main stylesheet, and inherit all the styles set for desktop viewing:

/*--- Main CSS here ---*/

/*------------------------------------*\
	IPHONE
\*------------------------------------*/
@media screen and (max-device-width: 480px){
/*--- iPhone only CSS here ---*/
}

Now any CSS before the media query will be used across all platforms, but anything between the query will be used by any screen media with a maximum screen size of 480px (i.e. an iPhone).

Things to remember

There are a few key things to remember when developing CSS for the iPhone:

• Avoid explicit absolute widths—where possible you should use percentage widths.
• Linearise everything—where possible, remove all floats. We want no content side-by-side unnecessarily.

The first thing to do is to set the -webkit proprietary CSS -webkit-text-size-adjust on the body which will resize the text for you, meaning you shouldn’t have to touch any font sizes yourself. Also, if your body copy is set in a sans font such as Arial, now is your chance to use some Helvetica—for normal sites, Helvetica should not be used as body copy as it renders hideously on a PC. Take advantage of the fact that you can guarantee its presence and quality on an iPhone. Change your font-family:

/*--- Main CSS here ---*/

/*------------------------------------*\
	IPHONE
\*------------------------------------*/
@media screen and (max-device-width: 480px){
body{
  -webkit-text-size-adjust:none;
  font-family:Helvetica, Arial, Verdana, sans-serif;
  padding:5px;
}
}

Above, I also added a small padding to make sure nothing touches the edge of the browser. All wrapper and content divs from here on in should be set to width:100%; making them the whole width of the screen, minus 10px.

Structure

Now, as all layouts differ I am going to assume a similar one to mine, a simple two column set up with a logo and menu in the header. If your layout is different I am sure you can quite easily retrofit it. As I mentioned before, remove all stylistic floats and set all widths to 100%. If you are using divs sensibly (i.e. for large bodies of content and not for nav items) this code should see you right for linearising the content:

@media screen and (max-device-width: 480px){
body{...}
div{
  clear:both!important;
  display:block!important;
  width:100%!important;
  float:none!important;
  margin:0!important;
  padding:0!important;
}
}

That will force all divs to rest one on top of the other, full width and in order. You have begun linearising all your content.

The navigation

If you have a navigation menu in which all the items are floated and made horizontal, insert the following:

@media screen and (max-device-width: 480px){
body{...}
div{...}
#nav,#nav li{
  float:none!important;
  clear:both!important;
  margin:0 0 20px 0!important;
  display:block;
  padding:0;
  text-align:left!important;
  width:100%;
}
#nav{
  border:1px solid #ccc;
  padding:5px;
  -webkit-border-radius:5px;
}
#nav li{
  margin:0!important;
}
#nav li a{
  display:block;
}
}

This then will give you a vertical navigation menu which has a 100% width and the actual links themselves have a larger hit area (applied via display:block;), meaning that it’s prominent at the top of each page and easier for users to select single items.

Images

As images inherently have a set pixel width (i.e. their own width) there is a high chance that they will break out of the wrapper area (as a lot of images will be above 480px wide). To combat this simply add the following:

@media screen and (max-device-width: 480px){
body{...}
div{...}
#nav,#nav li{...}
img{
  max-width:100%;
  height:auto;
}
}

Other than elements very specific to my site, that is pretty much all the CSS I use to quickly size and linearise my content. Any elements specific to your own site will obviously need considering on a case-by-case basis, but if you remember to not set absolute widths and to always linearise your content then it should be a doddle. Oh and it’s a great time to use some guaranteed CSS3.

View a screenshot of an entire page of CSS Wizardry on an iPhone.

Do you have an iPhone version of your site? Have you any more tips you’d like to add? Please do so in the comments below.

The em dash —

The em dash (—)—so named because it is the width of a capital ‘M’—is used to delimit a separate clause in a sentence—rather like this—or similar sub-clause structures. Often used in its place however is the hyphen (-). Looking at the two side by side the difference is quite clear:

Proper em dashes:

The em dash (—), or m dash, m-rule, etc., often demarcates a parenthetical thought—like this one—or some similar interpolation.

Improper hyphens:

The em dash (—), or m dash, m-rule, etc., often demarcates a parenthetical thought – like this one – or some similar interpolation.

Spaces around em dashes

The proper setting of em dashes seems somewhat unclear. The ideal way to set them is with hair spaces ( ) either side — like this. However, IE6 doesn’t support the hair space leaving the options of either fully spaced — like this, or unspaced—like this.

The en dash –

The en dash (–)—so named because it is half the width of a capital ‘M’ (an ‘n’)—has altogether different uses to the em dash. The en dash is used in ranges, for example:

• 6 – 10 years
• July 10 – August 1 2009
• pp. 40–42
• §§ 12–13

Read more specific guidelines on Wikipedia.

The hyphen

The purpose of the hyphen (-) is to join two words—for example ‘front-end’—and to separate syllables when splitting a long word over two lines. As previously mentioned, the hyphen is often misused in place of both the above.

The minus

There is also a separate dash for the minus symbol. The proper entity for a minus symbol is simply −.

More reading

A reader of the old CSS Wizardry left me with a link to one of his own articles covering a few further variations of each.

“I need to get an old ass banger.”

So, is that ‘old-ass banger’, or ‘old ass-banger’? You decide ;)

What the facts state

<b> and <i> are still valid, and as XHTML is just an XML serialisation of HTML, pretty much all the elements apparent in the HTML spec are true of the XHTML spec too—it is, pretty much, just the way in which these elements are written that makes them different in XHTML.

Twitter

With the help of @smashingmag I turned to Twitter and my knowledgeable followers and asked the question:

“Using <i> and <b> in (valid) XHTML (strict)… your thoughts on this would be much appreciated. #upcomingBlogPost Cheers all!” @csswizardry

Most of the answers I got said petty much the same thing: use strong and em … b and i are deprecated. While this is largely true, there are some myths that need dispelling.

• strong and em are not the same as bold and italics. strong is strong emphasis and em is emphasis. It is purely through convention that these two elements happen to adopt either bold or italicised appearances.
• b and i are not deprecated in any way in HTML or XHTML. They are still in existence, still valid and still (in the right places) usable.

Some replies

A few choice replies I received which are, on the whole, representative of everyone’s thoughts:

“strong and em make more sense, especially when taking screen readers into account. @CreativeNotice

Or so you’d think, see below…

“I prefer <strong> </em> because of semantics . You want to put emphasis, not just make text italic.” @WeHelpDesign

True, if you do just want emphasis that is…

“Using <i> and <b> is just fine if it’s for visual bling without real semantic background.” @levito

Ah, this is more like it!

“<b> and <i> tags describe presentation, not structural semantics. Rather style <em> and <strong> tags.” @hornergraphic

A view that is seemingly shared by almost everyone else who responded.

What about strong and em?

The vast majority of people who replied were in favour of strong and em over b and i. Presuming all respondents were assuming the question was ‘What are your thoughts on using b and i to represent strong emphasis and emphasis, and thus replace strong and em?’ then they’d have all been spot on correct. However, b and i and strong and em are totally separate things. b and i assume no semantic value, meaning literally bold and italic respectively. strong and em however have nothing to do with bold or italics. As previously mentioned, it is through convention only that the default styling for each is so.

strong and em are ‘spoken word’ type elements, where they represent a change in tone only. This means that their styling is in no way linked to their naming, it is just that us, as people, are familiar with italicised prose sounding more stressed—or emphasised—than surrounding text. This is where the importance of aforementioned semantics and screenreaders come in. Or is it…?

The screenreader fallacy

Screenreaders don’t use strong and em!

The common belief is that strong and em’s semantic meaning is used by screenreaders to alter tonality when reading content aloud, thus letting the user know that the copy is in fact meant to be understood in a different manner to any neighbouring text. This was something I too believed until the wonderfully knowledgeable @pekingspring pointed me toward this article by @stevefaulkner—it turns out screenreaders don’t use strong and em to alter tonality!

This means that screenreaders see no semantic value in the strong and em element. However, they should be used unconditionally where a change in tone is implied, whether a screenreader will understand this or not.

Where to use <b> and <i> then?

One of my first thoughts was where to use these elements if indeed they are still usable. My initial idea was the use of i for markup up things that have to be italicised but the italics aren’t indicative of any tone. To quote the Penguin Guide to Punctuation:

“Another use of italics … is to cite titles of complete works…”

Initially I thought this was the ideal use for the i element—something that had to be in italics, yet implied no tone of voice. It was such a good fit! However, @pekingspring came to my aid again and reminded me that the cite element is for this exact purpose. That was that idea gone.

Another possible usage for the i element was gleaned from the Typography Manual iPhone app, which states:

“Italics should be used for single letters in a sentence referred to as letters. [for] example ‘The letter j appears too large.’”

An idea I had for using b was somewhat linked to the cite element anyway. A common mistake is to markup the ‘author’ of a quote in cite tags. This is of course incorrect, but what do you use? It’s not really a paragraph, so what is it? I did consider the b element for this, but I feel that such a piece of information does need a more semantic element to represent it.

Friend and colleague @simonwiffen has a very nicely written example usage for each, which I personally think are spot on. The following chunk of text is lifted directly from an internal document written by @simonwiffen:

1.4.3 Strong, emphasis, bold and italic

<strong> (strong emphasis) and <em> (emphasis) should be used as opposed to <b> (bold) and <i> (italic) unless the bold or italic is required without any semantic context (for example in a product name).

Examples

Remember you must check this box

<p>Remember <strong>you must</strong> check this box.</p>

You should really try to validate your pages

<p>You should <em>really</em> try to validate your pages</p>

Read more about Splashdown!™ below

<p>Read more about <b>Splash<i>down</i>!™</b> below</p>

Succinct and, in my opinion, pretty hard to argue with.

HTML5 has it sussed

I won’t be using HTML5 for a long while yet, but that’s another story altogether…

Ideally I’d like to retrofit the HTML5 specification’s definitions of each for use right now in XHTML, however I’m not sure I’d be comfortable going ahead with doing such a thing, coding to one spec whilst picking my favourite bits of another.

The <b> element in HTML5

“The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.”

HTML5

The <i> element in HTML5

“The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.”

HTML5

A go-between in the meantime?

There will always be the argument that instead of using b and i you could or should use something like <span class="italics"> or <span class="bold"> so as to avoid using insemantic elements, however a class name like that is more insemantic than an in-spec HTML element. Not to mention the fact that a span with a class applied is far more cumbersome than a ‘pre-made’ piece of HTML.

The resolve?

So which is worse?

• Using i to mark up emphasised text
• Using em to mark up italicised and non-emphasised text
• Using i to mark up purely italicised text
• Using <span class="italics"> to mark up italicised text

Special thanks to the following for help with this article: @smashingmag, @pekingspring, @stevefaulkner, @simonwiffen and all my Twitter followers.

I think that the fact that b and i are still in the spec, are valid (even in strict) and are being carried over to HTML5 (albeit slightly redefined) indicates that there is still a very real place for them in web development right now. The frequency with which they’ll be used is slim at best, but they should not be ruled out, and at the very least not misunderstood. I’m not going to make the leap myself just yet, but they are there, they are usable, and one day I might just use them.

What are you going to do?

When not to use it

You should never not use an alt attribute, rather leave it empty, thus: alt=""

The only time you can really get away with not having a complete alt attribute is if the image holds no context or information that the user needs to be aware of. This is usually the case when the image is purely decorational, though it may be argued that the image should therefore be added through CSS in the spirit of separating style and content. By that token it is fairly safe to say that there should never be an instance in which you leave an alt attribute empty.

You’re using it, but not quite right…

The next best scenario is that you are using images correctly, for their correct purpose and are using alt attributes, but they don’t really do as much as they should. A lot of the time I come across images that have less than ideal alt attributes.

Image sourced via Google Images—original author unknown.

One example might be the above image of a car. This, while technically correct, is not ideal: <img src="/img/car.jpg" alt="Car" />. All this tells the user is ‘Car’. It doesn’t say whether it’s a picture with the word car in it, or whether it’s a picture of a car. A much better alt attribute would be alt="A photograph of an abandoned car" (as used in my code).

Other poor uses

Another real-world example of poor alt attribute usage is actually on CNN’s website. On their home page today (26 January, 2010) they have a series of headlines with accompanying images. The code for such a pairing looks like this:

<img height="68" border="0" width="120" alt="Haiti's swanky club →
now home to misery" src="http://i.cdn.turner.com/cnn/2010/WORLD/ →
americas/01/26/haiti.camp/tzvids.haiti.aid.cnn.jpg"> →
… Haiti's swanky club now home to misery

This is wrong on two counts:

1. A screenreader will read out to the user Haiti’s swanky club now home to misery … Haiti’s swanky club now home to misery. Every image/headline pairing on the page is laid out like this, meaning in every instance a user using a screenreader will hear the headline twice. This will surely soon get annoying.
2. Secondly, the image was actually of earthquake survivors holding a large bag, nothing to do with clubs and, unfortunately, far from swanky.

Using the attribute properly

On the BBC’s home page however (on the same date) they are using alt attributes perfectly. They have an image of a woman wearing a veil, alongside the article’s headline France report back face veil ban. The image’s alt attribute: alt="A woman wears a full-length veil in Lyon, 25 January".

The biggest no-no of all

One thing which consistently winds me up is the ridiculously bad practice of stuffing alt attributes with keywords. alt attributes are an accessibility feature, end of. They are not a way of slipping in keywords out of sight, and any attempt to do so is irresponsible and incredibly bad practice. The only time ‘keywords’ may be validly placed in alt attributes is if it’s explicitly related to the image; for example: <img src="/img/product.jpg" alt="A photograph of Mike's Carpets' ProClean™ carpet cleaner" />.

How to do it properly

Writing proper alt text is incredibly simple, yet a little more time consuming than the ‘Car’ cop-out. All you need to do is write out in full exactly what the image shows. If it’s an elephant giving a donkey a piggy-back don’t be lazy and use alt="Elephant and a donkey". Instead, write out alt="A photograph of an African elephant giving a donkey a piggy back across a swamp".

Also, for any pages that use similar images repeatedly but are slightly different to one another, make sure your alt attributes reflect these differences. A good example would be my portfolio page. Instead of using alt="Screenshot" over and over again I used text like alt="Screenshot of Suzanna Haworth’s website" and alt="Screenshot of RAAMaudio UK Ltd." etc.

This is one of the most basic aspects of web development, but one that too many people are still getting wrong.

Photo by Simon Wiffen.

Sense Internet

I applied the job at Sense when I was 17. My interviewer was my soon to be boss and Creative Director Tony Jacobs. Just from seeing the company and meeting Tony I knew this was where I wanted to work.

After starting at Sense on 14 July, 2008, I got to meet some amazing people, who were excellent at their jobs, great to get on with and an all round top team. I worked on a range of projects of varying sizes with different roles and responsibilities. I was allowed to exercise my skills, and learn from others. I could voice my opinion in as much as I listened to what others had to offer. It was an excellent creative and skilled environment.

One of Sense’s greatest assets is its people and it provided me with friends, colleagues, and above all my beautiful girlfriend Suzanna. We were both fortunate enough to work with people who became good friends to the both of us. Working with someone you’re in a relationship with, some would say, is inadvisable, but I loved every minute of it. It was something that made my next decision all the more difficult…

The decision

After, for one reason or another, losing friends, colleagues and mentors from Sense things began feeling a little different. It’s more than fair to say Sense was still an amazing company, and probably the best I have will ever worked for, however things just didn’t feel the same. I had no views to leaving Sense at all, I was still happy there, until I was granted an opportunity to work once more with the massively talented Dan Metcalfe, and my previous ‘mentor’, Simon Wiffen.

That opportunity was to work for entrepreneur Justin Whitston at his new startup, Venturelab. After meeting Justin and hearing his ideas, as well as his business plan and impressive portfolio, I was loving the idea of a fresh new challenge. Over the next month I had some really big decisions to make.

I could stay at Sense where, owing to their position, I had the chance to shape a team and become a senior developer. I would stay with friends in a job I was more than happy with, working with and for some great people. Or, I could take a risk, up and leave and work with two friends for a brand new company building websites for entrepreneurs and, whereas Sense worked with large household names, on unknown projects and clients. It was traditional agency work vs. a chance to work in a more fast paced business centred environment.

Venturelab

After much deliberation I decided to head to Venturelab. I wasn’t really ready to leave Sense, but opportunities like this don’t come around that often. It was something I had to do now, while I could. Being 19 I can afford to take career risks right now that maybe I couldn’t later on.

So, as of 11 January, 2010, I was employed by Venturelab. I miss Sense and all its wonderful characters and working environment a lot, but the idea of new challenges is exciting to me. I now have the opportunity to break away from your ‘typical’ web work and a chance to help businesses really grow. Plus the technical aspects of being a web developer at Venturelab is amazing—I have submitted and had accepted a proposal for the dev team to adopt a progressive enhancement approach across the board, using CSS3 as standard on all builds.

Sense people: Amy Littlefair, Simon Wiffen, Matt Tarbit, Ben Tappin, Wes Mason, Dan Metcalfe, Connor Wilkinson, Jonny Stirling, Richard Harwood, Mark Barrett, Gemma Lawson, Gaz Battersby, Vince Pickering, Andy Mason, Rob Farnell, George Kamsika, Darren Armstrong, Suzanna Haworth, Aidan Cook, Paul Allen, Dan Bentley, Tony Jacobs, Ro Ramtohul (sorry if I missed anyone).

Final word

Working at Sense was the most amazing experience I’ve ever had. The work, the people, the company, everything. I do almost feel like I wasn’t ready to leave, but Venturelab was an opportunity that I couldn’t pass up on—the new environment, the chance to work with Si and Dan once more and an opportunity for more varied responsibilities.

I’d like to thank Sense; the people I met, the opportunity I was given, their faith in a 17 year old developer and the amazing environment in which they ‘employ’ their team (I use the term employ lightly, as Sense never felt like a normal job). It has been an absolutely fantastic time—with too many good times to even try and remember—and I hope we cross paths again sometime in the future.

To Aidan, Sense, and everyone there; thank you.
Harry

The good

It’s nice to be able to say that lately I’ve been noticing an increase in good customer service rather than bad. Instead of boring you with reams of storytelling and recounts, I’ll just give a list and a few points on why I enjoyed dealing with each:

• Moo: I used Moo’s online system to make my new business cards. They quality was amazing, the delivery was speedy, the process was smooth and the company is great. I’d definitely recommend them.
• Tampopo: Suze and I headed to Tampopo yesterday for some lunch. If you live near a Tampopo and have never been, I urge you to go. The food is outstanding, the service is quick and the staff are extremely friendly.
• La Bottega Milanese: This is a tiny little coffee shop that has recently opened by my house. It’s not a franchise or a chain, it’s one guy who has opened up a lovely little shop. The coffee was excellent, he was extremely friendly, the shop was nice and it was just a more enjoyable experience than your typical Starbucks type coffee.
• North Bar: North Bar is a gorgeous little bar in the centre of Leeds, and a personal favourite of mine. The beers there are out of this world and the service is always superb. If you like world beers, you’ll love North Bar.

The bad

Unfortunately there is a flip-side. There are places where the service is not that good.

• PC World: Just after Christmas I bought myself a Dell Inspiron Netbook from PC World. I Suze called up the night before to reserve one black Netbook at the online price of £249. We arrived at the store the next day to find they’d reserved two red ones at £279. When we mentioned this they seemed to think it was our fault. ‘It says here you wanted red. It says here you want two. You don’t want to pay for extra security?!’
• Oporto, Jake’s Bar and Bar Room Bar: This might just be ‘one of those things’ but anyone following me on Twitter will know that this got me absolutely livid. I headed out with a good friend Joe Whitley for a few drinks in Leeds only to be turned away from three bars because they weren’t prepared to let two guys in without any female company. So much for organising a night out with a male friend. Three of the better bars in Leeds, plus my favourite, Oporto, really managed to annoy and alienate me last night…

In short…

So, in short, the products of all the above are completely acceptable, and worth the amount you pay for them. What made all the difference however is the non-monetary value added (or subtracted) through customer service. It’s something all businesses should definitely try and focus on more.

Any stories of good or bad customer services yourselves?