Archive: July, 2009

I’ve been turned into a caricature. Again.

First there was my Happy Webby, now it’s Smashing Magazine (and that’s not even counting CSS Squirrel).

The very talented Brad Colbow created a comic version of my post Misunderstanding Markup. Not a bad likeness, eh? Mind you, I think Eva-Lotta Lamm really managed to capture my essence at dConstruct last year.

There’s no denying it; I’m much more likely to read something from start to finish when it’s in comic form. Scott McCloud’s Google Chrome comic is the perfect example—it’s unlikely that I would have read the entire technical documentation for a web browser if it hadn’t been presented as sequential art. Now take a look at the “about” page on Huffduffer—wouldn’t you be more likely to digest that content if it were illustrated?

At the start of this year I made a vow to myself to reduce my level of overseas travel. It’s working out pretty well. My Dopplr animal has been downgraded from a squirrel to a butterfly.

I’ve been to a grand total of two conferences in the states this year; the obligatory South by Southwest in Austin and An Event Apart in Boston—it’s always an honour (and a surprise) to be asked to speak at that one. That’s quite a reduction compared to last year and it looks like I won’t be adding to that short list before the year is out.

Reducing my overseas travel hasn’t meant a reduction in attending great events. As well as all the Barcamps and Hackdays, London can boast some world-class conferences like @media and UX London. In fact, if I want to attend kick-arse conferences in the UK, I don’t even need to leave Brighton.

dConstruct is just over a month away. The line-up is particularly stellar this year. Rather than playing it safe, we’ve decided to push the boat out with the challenge of Designing for Tomorrow. To answer that challenge, we’ve lined up the finest minds of the next decade. Adam Greenfield! Mike Migurski! Russell Davies! (no, that one). Expect plenty of mind-boggling talk on ubiquitous computing, data visualisation, mobile design, and science-fiction interfaces.

Think it’s not relevant to your day-to-day work? Think again. And learn to exercise your imagination.

Anyway, tickets are a measly £125 so if you think that’s not worth it, might I suggest diverting your funds to getting a good psychiatrist.

There are still tickets left. If you haven’t been able to make it to dConstruct in previous years because it sold out too quickly, now’s your chance. If you have been to dConstruct before, then you know how great it will be. I’m hoping that the event will be sold out by the day of the event. Partly that’s because I want to see Clearleft’s faith in our peers’ thirst for knowledge rewarded, but mostly it’s because I’ve got a wager to that effect with Cennydd. If his pessimism is rewarded, I’ll be £1 out of pocket.

You’ve still got a few weeks to grab a ticket for the conference itself but if you’re planning to come along to one of the workshops in the run-up to the conference, you’d better act fast; the early bird price of £345—which includes a ticket to the conference—runs out in 48 hours. After that, a workshop costs £395.

Far be it for me to suggest which workshop you should book—they’re all going to be good—but might I point you to HTML5 and CSS3 Wizardry which will be run by a trioka of Clearlefties; Richard, Natalie, and myself. They’ll be handling the CSS3 goodness and I’ll be regurgitating what I’ve been learning from immersing myself in the world of HTML5.

Maybe I should just get Remy to pop in and show off his demos but I suspect he’ll busy preparing for his own jQuery workshop the next day.

Not content with doing workshops, tutorials, screencasts, and a book, the tireless Remy Sharp is organising his own conference. Full Frontal will take place in the beautiful Duke of York’s cinema in Brighton on November 20th. This is going to be a serious JavaScript geekfest. Get this: for a mere £100, you get Simon Willison, Peter-Paul Koch, Christain Heilmann and more. If you’re a JavaScripter and you’ve felt frustrated by the lack of your favourite scripting language at most web conferences, Full Frontal is guaranteed to satiate you.

Between dConstruct, Flash on the Beach, and Full Frontal, I may never have to travel outside of Brighton for a conference again.

As you can probably tell from the Huffduffer logotype, I like ligatures.

Most ligatures are formed by the combination of the lowercase letter f and a subsequent letter—although the gorgeous Mrs Eaves typeface includes a few more unusual ones.

There’s an old letter that looks a lot like the lowercase f and that’s the long s.

ſ

Up until the 19th century, this was the default way of writing the letter s at the beginning or in the middle of words. Our letter s—called the short s—was mostly used when a word finished with an s or when an s followed an s (the word Congress on The Declaration of Independence matches both criteria).

ſs

I was in Warwick last weekend, the day before Richard’s wedding. While Jessica and I were exploring the church crypts, I found some ligatures that were new to me.

This looks like a regular ft ligature but actually it’s a long s followed by a t—look at the way the crossbar on the long s doesn’t go all the way across the vertical stem like it would on an f. Another dead give-away is the fact that the word being spelled is Christian.

On another headstone I found a ligature formed by the combination of a long s and the letter b, used to spell the word Husband.

While there is a corresponding f-based ligature, I can’t remember ever seeing it in the wild. The combination of f and b is rare in the English language. The only examples I can think of are compound words like halfblood or halfbreed; words more often spelled with a hyphen separating the f and the b.

My photographs of the subterranean ligatures didn’t turn out great—my little point’n’shoot camera isn’t very good with low-light conditions—so I whipped out my sketchbook, put a page in front of the letters and recorded some pencil rubbings for posterity.

When I wrote about designing for the street I tossed out this glib remark:

The Social Life of Small Urban Spaces was filled with lessons that can be applied to web design (or as it is more fashionably known now, UX design).

Or, as Mark put it:

Since when did good web design suddenly get called ‘UX’? Everywhere I look now, good UI design is called ‘UX’, good type = ‘UX’, Colour? UX.

My point in equating UX design with plain ol’ fashioned web design is similar to what Jeff was getting at when he wrote I don’t care about accessibility five years ago. It was a controversial thing to say but he explained it eloquently:

When you design for the Web — that is, when you design exclusively and specifically for this medium — when you do that natively, so many of the things we consider problems just start to fall away. … Because when Web design is practiced as a craft, and not a consolation, accessibility comes for free.

…and that’s the way I feel about what is often labelled as UX design. If someone claims to be a web designer but isn’t considering the user experience, they are deluding themselves. UX, like accessibility, should be a given, not a differentiating factor.

And that’s why I don’t care about UX.

The W3C announced last week that the XHTML 2 Working Group will wrap up at the end of this year. This should have been a straightforward, welcome announcement. Instead it has confused a lot of people who believe that it heralds the end of XHTML—see, for example, the comments on Zeldman’s blog post.

This confusion is understandable given the lamentable names that have been assigned to different technologies. This isn’t the first time this has happened…

JavaScript sounds like it has something to do with Java. It doesn’t. Apart from some superficial syntactical similarities, they have nothing in common. Java is to JavaScript as ham is to hamster.

DHTML sounds like it has something to do with HTML. It doesn’t. DHTML is a catch-all term to describe the action of updating the CSS properties of HTML elements using JavaScript. I have my own catch-all term for the combination of HTML, CSS, and JavaScript; I call it web development.

And so to XHTML 2. You’d be forgiven for thinking it has something to do with XHTML 1.0 or XHTML 1.1. It doesn’t.

XHTML 1.0 is simply a reformulation of HTML 4 with XML syntax:

• lowercase tag and attribute names,
• quoted attribute values,
• mandatory closing tags for p and li elements,
• a slash at the end of standalone elements like img, br, and meta.

XHTML 1.1 is the same reformulation but with the added unrealistic demand that documents must served with an XML mime-type.

XHTML 2, by contrast, has had very, very little in common with HTML 4. It was an attempt at a fresh start, to create a theoretically “pure” vocabulary with little concern for backwards compatibility. It was, of course, doomed to failure:

This was a philosophically pure specification that was so backwardly incompatible that it nearly deprecated the img element.

Now that XHTML 2 is dead, some people think that this means XHTML is dead. It doesn’t.

Henri Sivonen apparently attempts to clear up this confusion by writing An Unofficial Q and A about the Discontinuation of the XHTML2 WG which, alas, is not very clearly written. Also, Henri, as pointed out by John Allsopp, your snark is showing:

There are two meanings to XHTML: technical and marketing. The technical kind (XHTML served using the application/xhtml+xml MIME type) is a formulation of HTML as an XML vocabulary. The marketing kind (XHTML served using the text/html MIME type) is processed just like HTML by browsers but the authors attempt to observe slightly different syntax rules in order to make it seem that they are doing something newer and shinier compared to HTML.

Belittling authors who prefer a stricter syntax is no way to explain technical differences between formats.

There are perfectly good reasons for choosing to use the XHTML syntax. Take, for example, Drew’s comment:

Whenever this argument surfaces, there seems to be the assumption that loose syntax is easier for beginners. This baffles me. In my experience simple, strict rules are much easier to learn and code to than loose rules with multiple shortcuts. I like XHTML because attributes must always be quoted. Tags must always be closed. These are simple rules that require no thought, and result in uniform, predictable markup.

I’m not saying that XHTML syntax is better or worse than HTML syntax. I’m saying it’s a personal choice. If you prefer a different syntax to me, that doesn’t mean that one of us is wrong. If I like Thai food and you prefer Italian, neither of us is wrong.

The death of XHTML 2 does not mean the death of XHTML syntax. If you want to continue to close all tags and quote all attributes, you can do so. You can either use the existing XHTML 1 spec or you can use HTML 5.

That’s right; HTML 5 allows you to use whichever syntax you are most comfortable with. Doctor Bruce has the diagnosis:

I like the XHTML syntax. It’s how I learned. I’m used to lowercase code, quoted attributes and trailing slashes on elements like br and img. They make me feel nice and comfy, like a cup of Ovaltine and The Evil Dead on the telly.

But you might not. You might want SHOUTY UPPERCASE tags, no trailing slashes and attribute minimisation. And, in HTML 5 you can choose.

Thanks to the “pave the cowpaths” principle, it’s up to you. As you like it. What you will. Whatever you want, whatever you like.

If you want, you can even serve your documents as application/xhtml+xml, instantly transforming them from HTML 5 into XHTML 5 …yes, another confusing name.

Just remember, XHTML 2, the spec, has nothing to do with XHTML, the syntax. XHTML lives on in HTML 5.

But, but, but…, I hear you cry, surely that does us no good because HTML 5 isn’t supported yet, right?

Define support. HTML 5, unlike XHTML 2, is designed to be backwards compatible. So here’s how you can take an existing XHTML 1 document and convert it to HTML 5…

Take this line:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Replace it with:

<!DOCTYPE html>

Done.

XHTML 2 is dead. Long live XHTML …as HTML 5.

Update: What Zeldman said.

The front page of today’s Guardian ran with a story on Binyam Mohamed and his fight to stop evidence of his torture from being destroyed:

The photograph will be destroyed within 30 days of his case being dismissed by the American courts — a decision on which is due to be taken by a judge imminently, Clive Stafford Smith, Mohamed’s British lawyer and director of Reprieve, the legal charity, said today.

Reprieve recently relaunched their website and they chose Clearleft to help them. I was responsible for the front-end build; that’s my usual role. But unusually, I also had to build a CMS.

We don’t normally do back-end work at Clearleft. That’s a conscious decision; we don’t want to tie ourselves to any particular server-side language. Usually we partner up with server-side developers; either those of the client or independent agencies like New Bamboo. In the case of Reprieve, the budget didn’t allow for that option. We were faced with three possibilities:

1. Write a CMS from scratch, probably using PHP and MySQL—the technologies I’m most comfortable with.
2. Take an off-the-shelf platform like WordPress or Expression Engine and twist it to make it fit the needs of the client.
3. Create a CMS using Django which would give us an admin interface for free.

There was a three person team responsible for the project: myself, Cennydd and Paul. We did a little card-sorting exercise, weighing up the pros and cons of each option. Django came out on top.

I had conflicting emotions about this. On the one hand, I was pleased to have the chance to learn a new technology. On the other hand, I was absolutely terrified that I would be completely out of my depth.

I had seen Simon giving a talk on Django just a few weeks previously. I stuck my hand up during the Q and A to ask Is it possible to learn Django without first learning Python? Simon said that a year ago, he would have said No. But given the work of fellow designers like Jeff and Bryan, the answer isn’t so clear cut. Maybe Django could be a really good introduction to Python.

By far the hardest part of building a Django website was the initial set-up. Sure, installing Django was pretty straightforward …once you’ve made sure you’ve installed the right image libraries, the right database bindings, blah, blah, blah. I can deal with programming challenges but I have no desire to become a sysadmin. Setting up my local dev environment on my Mac was a hair-tearing experience. Setting up the live environment, even on a Django-friendly host like WebFaction, was almost as frustrating …no thanks to the worst. screencast. EVER.

But I persevered, I obediently followed the tutorial, and I discovered all the things that make Django such a powerful framework; the excellent separation of concerns, the superb templating system, the lack of so-called front-end “helpers” that cripple other server-side frameworks. I think Gareth was really onto something when he noticed the way that the web standards world appears to be choosing Django.

In the end, Django proved to be absolutely the right choice for Reprieve. It provided enough flexibility for me to build a site tailored to the specific needs of the client while at the same time, giving me plenty of pre-built tools like RSS and, crucially, the admin interface. The client is extremely happy with the power that the admin interface offers.

For my part, it was an honour to work on a project with this mission statement:

We investigate, we litigate and we educate, working on the frontline, providing legal support to prisoners unable to pay for it themselves. We promote the rule of law around the world, and secure each person’s right to a fair trial. And in doing so, we save lives.