Do designers need to code? This has been the question of the moment of late. Though, speaking of late, I may have missed the main period of discussions around the subject. Regardless, here’s my take… Disclaimer.

Is a web designer really a web designer if they can’t code?

A lot of the arguments revolve around the (false) fact that ‘designers can’t understand what they’re designing if they can’t build it’. This argument suggests that a web designer who can’t code is a fake who’s just blagging their way if they don’t know/understand how to actually build the websites they design…

This is wrong. By this token I should understand MySQL and programming and Project Managers should understand design theory and programmers should be able to manage clients. There’s a reason we have different job titles; people do different jobs.

A designer who can build websites is a designer–developer, a designer who can’t write HTML/CSS is a designer.

Designers should work with developers

One reason, I think, that people believe that designers should be able to code is that they need to honour their designs, they need to be sure their designs are buildable by being the ones who have the responsibility of building them.

The problem is not that designs need to be buildable, it’s that developers should be permitted to send designs back and make compromises. Designers and developers need to collaborate, not be combined. Designers need to keep pushing the envelope, making tricky and outside-the-box visuals that push the work of the developer forward. The developer needs to be able to work back the other way, show the designer the boundaries that cannot be broken. Designers shouldn’t lead developers, developers shouldn’t lead designers, there should be a happy middle ground where teams work together, specialising in their respective areas but understanding and appreciating each others’.

A designer who codes badly is less use to a developer than a designer who can’t code at all. Developers need designers, not bug making machines.

But the client was shown a PSD that needs to be honoured…

I think this may well be one reason why people believe designers should code; the situation where the client has seen a PSD and thus expectations are set. A developer hasn’t seen the visuals and is all of a sudden expected to build something he’s had no input in. For the most part this may not be the case at all, but it definitely could be…

The remedy here might be to make sure designers only create things that they can build, achieving this by making sure designers can code.

This is fixing the wrong problem, the problem here is a lack of communication and a lack of collaboration, not a lack of skills. Designers and developers should work together from the outset, working in the browser to ensure that a) the team is working as, well, a team and b) that a client is never shown a PSD (showing a client a PSD in 2011 is just foolish).

The recurring theme is collaboration… Designers and developers need to coexist, not be one and the same.

HTML and CSS isn’t easy…

…but it is easy to do badly. I know loads of designers who can make the most stunning visuals but their code is not a strong point. Sure, they can write HTML and CSS, but it’s not where they specialise or excel, in much the same way a lot of developers have no design sense.

A designer who writes bad code is less use than a designer who can’t code at all. Once a designer writes poor code then either a) a decent dev has to come along and spend time bug fixing, or b) poor code becomes a tangled mess off spaghetti CSS and browser hacks.

Do not undervalue the importance of HTML and CSS, they are easy to do badly, but hard to do excellently. You need excellence in both design and development, so leave each role to its respective person.

These rules introduce restrictions

If a designer needs to code what he’s designed then he’ll design to what he can do, not to what can be done. This is a fundamental mistake to introduce.

A designer who isn’t restricted by a secondary skill set will produce things outside the box, push the envelope and keep innovating. A designer who is limited by their dev knowledge is hemmed in, scared of pushing the boundaries for fear of creating themselves work they cannot complete.

By forcing one thing you are restricting another, this is not a good thing to bring into your team. What you need to do is keep the contact and collaboration (there it is again) between design and build to ensure that everyone is achieving their full potential.

Real life examples

I know two people, personally, who both excel in their given fields. One is a fantastic designer who constantly produces unconventional but stunning websites, the other is an incredible front-end and JS developer (among other things). The designer can write code, but it’s not his focus, he doesn’t write production code because the developer does that.

They have a dynamic working relationship whereby they collaborate (and again) and consult with each other throughout the whole project. The designs look incredible and they’re built very well. This is more valuable than a constrained designer forced into producing buggy, poor code to build designs they’re not fully happy with.

What do they need to understand?

If a designer doesn’t understand code then this is fine; they don’t need to understand code, they need to understand their medium. Having an understanding of the web is not the same as being able to build it.

A good designer working with a good developer is a team that is good at making websites.

Don’t dilute someone’s skill set by trying to expand it, play to the strengths of your team. Designers who can code do exist, but they don’t have to. If you are a designer who can code (and thus a designer–developer) then that’s great, if you’re a designer who can’t code, but work well with developers that can, then great!

But there is no right or wrong answer

Designers can code, sure, but they didn’t ought to be required to. No one should be saying that a web designer isn’t so because he can’t code, that’s actually pretty rude…

If you have the budget to hire two people then get yourself a designer and a developer. Your designer doesn’t need to be able to code, they just need to work well in a team.

However, if your budget dictates you can only hire one person then hire someone who is a designer and developer. If you need to hire a designer–developer then make are they’re sufficiently good at both. If you can only hire one person then your designer does need to be able to code.

Designers do not have to be able to code, no one can make such a sweeping statement. It depends what you need, what you are comfortable with, and what works best for your team.

Massive disclaimer

When I say designers and developers I’m separating people into two camps; designers (people who just design (people that the industry seem to have a problem with)) and designer–developers (people who design and code (the people the industry expect)).

I’m not saying designers write bad code, because a designer who can and does write code is a designer–developer. Designers are, by definition, people who don’t write code.

So if you are a designer and you think I’m saying you can’t write code when you can then I’m classing you as a designer–developer. If you’re a designer who can’t code then that’s great. Please, no one take any offence, because none is intended.

In short

Designers shouldn’t have to be able to code to be called designers; designers should be able to collaborate and understand the rest of the team and vice versa.

If you need a designer–developer then yes, your designer does need to be able to code. If you can afford a designer and a developer then they don’t.

As David Kaneda so rightly put it:

“Just a thought: Devs don’t need to learn design, designers don’t need to learn programming — people need to learn how to collaborate.”

I’m currently writing my dissertation in which I explore the relevance of design education in the knowledge economy and an increasingly digital future.

P.R. I remember when I first came across CSS Wizardry, I was very impressed. I assume you opted not to go to uni and devised your professional career yourself and as far as I can see, very successfully so.

Thanks for the kind words. And yeah, I did opt to skip university and go straight into the industry as soon as I could.

P.R. I would be interested to hear your opinion about design education. Do you think formal design education is still relevant? Why did you choose not to go to university? Do you feel that you somehow missed out on aspects of formal education that go beyond teaching (such as social life, time to experiment, etc.)?

I personally would (and actively do) suggest to people that, before considering enrolling in formal education in a web design/development field, they consider the benefits they would reap from the money it would cost.

The reasons for this are generally that a) university is very expensive b) something such as web development is so accessible and learnable without a formal course that you can very easily learn the course content yourself for a fraction of the price (the cost of a few good books) or c) learn better, more current topics. Universities, where web development is concerned, are notoriously behind-the-times. I’ve heard countless horror stories, including the most recent from someone whose lecturer is teaching table based build!

When the time came for me to decide on uni or industry it was a pretty simple decision. Several factors were taken into account but the most resounding were my then tiny web presence already gaining industry recognition and my own first-hand view of just what the courses were offering. Every clue at that time pointed to me having a wider knowledge, understanding and foothold than the graduates of the courses I was considering taking. As big-headed as that sounds it is unfortunately the truth; at 17 I had managed to teach myself more than most universities teach their students over three to four years.

The final deciding factor in the move was a simple test of sorts. I sent two applications to two universities and to two web development agencies. Both agencies responded, and the first one I contacted offered me the job at the interview. That agency was Sense Internet; an award-winning big-hitter and quite a known name. To me the choice was clear—go to learn what I already knew over four years at an expense to myself, or start out full-time industry life at Sense…

It was a few months after starting at Sense that I discovered Newcastle uni (one of the two I applied to) was using my Web Design+ document to teach their students. I almost ended up being on a course that were teaching using my material.

So yeah, for those reasons I (gladly) decided against university.

As far as missing out goes, it’s a double edged sword. With uni comes a lot of socialising, with working at a respected agency comes credibility and cash. Bearing in mind I am still only 20 I guess I still am missing out, but I don’t see it that way. Being in the industry has allowed me to move even further ahead, doing what I love and getting paid for it really is great in my opinion.

With regards relevance, I’d say whilst not wholly irrelevant, a design/development degree is far from relevant. By that I guess I mean that relevance is probably not the best way of measuring it. It’s more necessity, and as far as I’m concerned it is definitely not necessary.

P.R. Judging by your portfolio and the informed commentary you put out there in your articles and on twitter, I’d say you’re probably better educated than most design school graduates. How did you acquire these skills and knowledge? Were there any obstacles you had to overcome? Do you think university (or ‘design school ) can prepare students adequately for the professional world?

Thanks! I got these skills through genuine interest, lots of experimenting, stacks of reading and a lot of hard work. From the age of 15 my days would usually consist of get up, go to school, go to work, come home and tinker on my computer ’til the early hours. My PC in my room didn’t actually have an Internet connection either, so I’d save articles and tutorials onto a USB stick to read in my room later.

Two years of this and I’d decided I didn’t need university. The key was that I was learning about the industry as it happened—things were always up-to-date. This is where degrees and formal education are lacking in my opinion; you can’t plan the content of a course three years before it results in graduation. Three years in Internet years is such a long time it’s untrue. That’s why people are still being taught table-based development.

I definitely don’t think university can prepare you professionally, as it’s just so far behind. As soon as you graduate and enter the industry a lot of people will have to disregard and relearn aspects of their education right away.

P.R. Lastly, what is your view of the ‘professional world’? Many employers still require degrees, why do you think that is?

I think the kind of employers who might ask for a degree are probably the type of employer who don’t actually understand the technical side of web development. An employer who can look at, and appreciate and recognise, the talent of a web developer will know from that alone how good they are. Someone who doesn’t know what they’re looking for can always quantify their skills based on whether they have a degree or not. Whether this is a fair or accurate representation is another question entirely.

In summary I personally think that you really don’t need to go to university for web design/development. Over two-years of working in my room (i.e. alongside a full-time activity), at the cost of one or two good books I managed to go above and beyond what I could have spent three to four years learning full time at the expense of tens-of-thousands of pounds learning.

Teach yourself at your own pace and learn what you want, when you want. Keep up to date, buy a few good books, get on Twitter, read articles and have a genuine passion and interest and you’ll do a better job than any university will do.

As for the social aspect, sure I missed a few years of partying mid-week and eating shop-brand beans-on-toast, but I did gain a wealth of knowledge, amazing friends, some exciting, real-world work and moreover a professional reputation. All before other people my age are even graduating yet.

Forget uni, teach yourself, learn more, have fun.

Harry

A little background

N.B. I am in no way saying we invented the concept of designing in the browser, we merely adopted it very early, before most.

I have championed designing in the browser long before it became popular. True fact. I was doing this long before it was a mainstream practice.

When working at Sense I was extremely lucky to work alongside a man called Philip Meitiner. He was Sense’s Account Director and a genuine pleasure to work with and learn from. It was whilst we were working on a white-label website for some big name clients (Nissan, Renault, Mercedes, Volvo and more…) that we decided to ditch Photoshop and dive straight into the browser. This idea was born from the fact that I’d put together a series of HTML wireframes whose code was of a quality that I deemed suitable for production. It seemed backward to us to then fire up Photoshop and design an image based on a set of HTML pages, to then return to the HTML and style it.

Thus was born our idea to design in the browser. We saved the HTML in isolation and used it as a starting point for each development of the various sites we had to build. We branded and designed each white-label in the browser and sent live, actual code back to the client for approval. It was, for everyone involved (though me more so) a dream come true.

The article I wish I’d written

Months later, 24 Ways published their article on designing in the browser. If there was one article I wish I’d written, it’s that one. Phil was equally dismayed, however at least we knew we were on to something good.

How it works

For those not in the know, designing in the browser is exactly as it sounds. Instead of building a website in Photoshop then markup, you dive straight into the browser and notepad and get cracking. A few benefits:

• Saves time, cutting all Photoshop work.
• Changing repeated elements (e.g. hyperlink colours) takes just one CSS declaration in the browser. It takes a lot of donkey work in Photoshop.
• Clients buy websites, not printouts of websites. Designing in the browser allows them to see how their site looks in its intended environment.
• This makes progressive enhancement usage much simpler. If they view it in Chrome, they see your round corners. If they view it in IE they see square corners. Both are intended behaviours, and both are fine.
• It can show things like hover effects and interactions that Photoshop can’t.

“Clients buy websites, not printouts of websites.”

How it improves build quality

There are a few reasons why I believe that designing in the browser improves the overall build quality of a website.

Users don’t (generally) visit a website for its design, they visit for its content. Designing in the browser considers content first. This is absolutely essential for a well thought out website, in my opinion. In Photoshop you design a layout and then populate it with content. Designing in the browser you start with your content and design around it. Content is the focus and the design does nothing but complement it. You’re coming up with a suitable way to house the content you’re starting out with, rather than shoehorning content into a preconceived design.

By focussing on what your users are actually coming for, you often find that a better UX will follow. Ignore anything extraneous to begin with, nail the fundamentals (hint: typography!) and concentrate on how pretty it looks after. Designs change more frequently than content does; invest in the content early.

“What happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?”

Another reason is that, particularly if you are in a team where the designers don’t do a lot of hands-on coding and build, devoting a lot of code to purely visual effects and design can lead to insensible builds, insemantic markup and a whole host of other issues. This is, admittedly, a marginal chance, but coding around the content before the design will often lead to more sensibly built websites, focussing more effectively on its content.

The main time to use the designing in the browser as your primary build method is probably with a lot more sites than you’d imagine. Blogs, ecommerce, portfolios, news sites, apps, aggregators. You name it.

Designer to developer

Hopefully this one doesn’t happen often, but it can do…

I’m sure developers have had this countless times–a designer brings you a design that just isn’t codable. The client had been shown a PSD that you have no hope of coding unless you botch and hack at markup and use ridiculously extraneous amounts of Javascript to manipulate it. By designing at code level you avoid all these problems from the outset. What you code is your design, your design is codable.

Designers obsolete?

Far from it. The designer is often the developer anyway, and if not, the designer is needed to call the creative shots and create initial visuals. Take Venturelab for example. Si came up with the skeleton of that design in Photoshop. Any type work, any calls-to-action, lists, navigation and tables were done by me, in the browser. Si created two ‘mood board’ style PSDs (and very good ones at that) but Justin was only ever shown working code, designed in the browser.

Nail the backbone in Photoshop if needs be, but in areas where rapid development and the need for quick and arbitrary changes are needed (think typography and link colours etc.) designing in the browser is far more efficient. Imagine the pain of changing the zebra-stripe colours of a giant table in Photoshop when you just edit one CSS declaration and see to it all in one go.

On pushing the limits

There have however been one or two occasions in my career where not designing in the browser has done more good for a project than bad.

“There’s a large chance that [a developer working in the browser] won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.”

The first example links back to what I said about designers handing sites to developers that the developers can’t code. If the person designing the site is also the person building it, there is a (pretty large) chance that they’ll take the easiest simplest route to completion. There’s a large chance that they won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.

If I draw on my own experience, the Findus Crispy Pancakes site is an excellent example of designers giving developers the kind of headaches we love. I built Findus about a year or so ago whilst at Sense. Rob designed the site in Photoshop and when I saw it I nearly fainted. I had no idea where I’d even start coding up such a complex looking, overlapping, quite frankly mental design.

Yet despite this, I got my developers brain on and got to work. I finished the site about four days ahead of schedule and enjoyed every minute of it. That design pushed me more than it would have if it had started out in the browser. It was a lot better for being in Rob’s hands first. And I still maintain that it was one of my most challenging builds to date (IE6 support…).

Developers still need designers!

Follow Rob on Twitter. Fantastic designer and all-round nice guy.

It is important that the designer and developer have overlapping knowledge of each others’ respective areas, yet play to their fullest in their own. The Findus site was a bit of fun on a small project which allowed me and Rob to really stretch ourselves, and that’s what it’s all about.

Big brands

Another couple of times where designing in the browser hasn’t been viable was when we, at Sense, were working on the Travelodge and Rizla websites. Travelodge was designed by another agency anyway, but even so, as they had very stringent brand guidelines that stated that round corners were a pivotal part of the brand, everything needed to be done in Photoshop.

Another example would be Rizla, which, again, we built at Sense. As Rizla’s brand is so important to their success and recognition it could not have just gone straight into the browser. Rizla wasn’t so much about quickly accessible content, so much as heavily designed and branded content. We allowed for users to change the design, and for the design to carry off promotional work, which could not have happened straight in the browser.

Aiding programmers

This section was edited in part by Dan Bentley.

Programmers manipulate markup. A Photoshop document is nigh on totally useless to a programmer, whose involvement lies in all that magic stuff that happens behind the scenes. Allowing programmers access to the code from an earlier point means they can start their job alongside the developer sooner.

Furthermore is the idea that Javascript developers can visualise their involvement much sooner, too, and see what markup they will be manipulating from the outset, rather than having to second guess what markup might result from the developer’s take on the PSD. They can start manipulating the DOM and begin building prototypes alongside the main build developer right from the start, making life easier for them as well.

When do you design in the browser?

At every available opportunity.

It saves time, it’s a much better way of presenting concepts to clients, it leads to better quality builds, it gives more consideration to content, it’s more fun than working in Photoshop (at least from my point of view), it’s easier to experiment, it’s far more efficient and the quality of the code is usually better as it concerns itself with content over decoration.

“Designs change more frequently than content does; invest in the content early.”

For any content-centric sites (I know, all sites are about content) such as blogs, web-apps, CMS style dashboard builds, news sites, informational sites or anything similar, you can’t lose by designing in the browser.

If you’re an account manager type person at an agency, run the idea past your development team; I’m pretty sure they’d love to work like this, if they don’t already.

When can’t it be used?

Sometimes, designing straight in the browser just can’t work. Heavily branded or very graphical sites that are more about decoration or branding than content will be a struggle to create without opening Photoshop first. However, by completing the major chunk of the layout and graphical design in Photoshop, you can often leave it at that, and model/work on type straight in the browser (what happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?). For the fine details, designing in the browser will be far more efficient and true-to-life than using Photoshop will ever be. Embrace it, and enjoy it.

Final word

So, do you design in the browser? Are there any reasons why you don’t? Would you like to? Leave a comment and open the debate up a little wider…

“I think it’s just another place where the more famous designers just pat each other on the back, regardless of what they actually produce.
It’s too elitist and the more known designers only follow each other, leaving less known people following them but their own work barely been seen. This in turn fuels the cycle—the famous get more so, while the more humble designers go unnoticed. I am seriously unimpressed with Dribbble”

So, if you’re really really wanting a Dribbble invite, don’t worry; you’re not missing much.

Also, follow Suze on Twitter.

As the site was built very quickly, we are adapting it as it grows and fixing any bugs as they happen. Let me know if you find anything astray. Anyway, enough talking, go look for yourselves!

I hope Type Tips comes in useful for you, and that the information in there is of some notable value. If you do like it, please share it by tweeting the link, I’d appreciate it. Any other thoughts? Just drop me a comment…

Many hands make light work

There are lots of contradictions in sayings and phrases. Like this one, if many hands do make light work, then how does this next one work?

Too many cooks spoil the broth

A stitch in time…

While the cat is away…

Absence makes the heart grow fonder vs. time is a great healer

This one is another glaring contradiction, so I decided to combine the two into one poster.

Out of sight, out of mind

Two wrongs don’t make a right

This one doesn’t really follow the code paradigm, but I thought I’d include it anyway.

Got any more that would work in this way? Leave any suggestions in the comments.

Also, I do realise that, programmatically, not all of these posters make perfect sense. For example, $cooks > 'enough' doesn’t really work in a programming sense… It’s just a bit of fun!

Naturally I designed the cards in Illustrator but my initial thoughts were to flatten these vector files and send them off to a print company to be done by them. However, after remembering Moo, I decided to give them a shot and get a limited run of just fifty cards made—this was because I wasn’t sure on just how good the quality might be…

The main reason for my concerns about quality was the fact that I was to print the cards from a .jpg image, rather than a lossless vector format. However, when they arrived I was amazed to find they were perfectly legible, totally flawless and perfectly finished. Nothing was even slightly questionable about the cards or their quality, I was pretty impressed!

As well as the quality of the cards themselves I was delighted to find they were presented in a gorgeous heavy card case along with some sorting tags for ‘Mine’ and ‘Theirs’ business cards. A beautiful way to present some top quality cards.

Moo MiniCards

As well as getting myself some business cards from Moo I decided to surprise Suze with some MiniCards with a few photos from her Flickr stream. The cards were, again, top quality, presented in a lovely shallow box. She was really pleased with them! Although she is wondering what exactly to do with them, so please post any suggestions!

A firm recommendation…

After the speed with which the cards were printed and delivered, their outstanding quality, the beautiful presentation and the sheer pleasure of using Moo (not to mention the extremely attractive prices) I will, without a shadow of a doubt, be using Moo again, and definitely recommending them to anyone who requires professional business cards or something novelty like their MiniCards. Five star service.

Typographic work planner markup:

The rich, semantic markup is as follows. Notice the use of the more semantic elements and attributes such as summary="", colgroup, scope="", caption and more…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

  <title>Typographic work planner</title>

  <link rel="stylesheet" type="text/css" href="css/style.css" />
</head>
<body id="home">
  <div id="wrapper">
    <table summary="An overview of upcoming and recently completed work ?
    by employees">
      <caption>Work schedule</caption>
      <colgroup>
        <col id="date" />
        <col id="user" />
        <col id="dec" />
      </colgroup>
      <thead>
        <tr>
          <th scope="col">Date</th>
          <th scope="col">User</th>
          <th scope="col">Description</th>
        </tr>
      </thead>
      <tfoot>
        <tr>
          <td colspan="3">Sense Internet Ltd work planner</td>
        </tr>
      </tfoot>
      <tbody>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
      </tbody>
    </table>
  </div>
  </body>
</html>

In detail…

There are a few things in the table you may not have seen before, briefly, they are:

• summary="": This is an attribute which provides a brief overview of the table and its contents/purpose.
• caption: This is a table specific caption, essentially a heading/title explicitly for the table.
• colgroup and col: This is an essentially invisible element that just adds semantic meaning to the table. It defines the columns and can—in some browsers—be used to style them.
• scope="col": This is an attribute which tells the browser whether the th is a title for a column or a row. This then obviously makes the other possible attribute value row.
• tfoot: This is a table footer and contain pretty much anything you like. It must however appear before the tbody.

Typographic work planner CSS:

The CSS used to create the work planner is pretty basic, with a dash or progressive enhancement added via some CSS3. View the full CSS file with reset etc.

table{
  margin-bottom:20px;
}
td,th{
  border-bottom:1px solid #ccc;
}
tbody tr{
  background:#fff;
}
tbody tr:nth-of-type(even){
  background:#ffc;
}
th,tfoot,caption{
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:1.6em;
  font-weight:bold;
}
th,td{
  padding:10px 0;
}
caption{
  font-size:2.4em;
  position:absolute;
  left:-9999px;
}
.date{
  width:160px;
  padding:10px 15px 10px 5px;
  font-family:Georgia, "Times New Roman", Times;
  font-size:1.6em;
  font-style:italic;
}
.user{
  width:460px;
  padding-right:20px;
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:4.8em;
  font-weight:bold;
}
.desc{
  width:280px;
  font-size:1.2em;
}
tbody tr.today{
  background:#ff8;

  text-shadow:1px 1px 1px rgba(0,0,0,0.3);
}
tfoot{
  color:#666;
}
tfoot td{
  padding:10px 5px;
}

Typographic work planner demo