wheresrhys

Since starting out in web development probably the most recurrent frustration (along with internet explorer 6) has been the failure of back-end developers to mark-up web pages correctly, i.e. in a semantic manner. It’s frustrating for a number of reasons

1. It’s easy
   It really is. Most of the html tags are named very sensibly and have a clear purpose. Here is a complete list, and the site that list is on also has a walk-through guide to marking up a web page properly.
2. It’s not so easy
   Despite being a doddle, it’s not something you can just assume you know how to do well, and I think too many back-end developers, because they can write html and it doesn’t produce an error message, assume what they write is good enough.
3. Sometimes the incorrect markup is put there in an effort to help
   I’m talking mostly of tables here. It’s painful to have to remove the nested table structure a back-end developer has put in to do the basic layout for you, as it’s a waste of everybody’s time.
4. It would be so easy to ask the front-end people what mark-up they would like
   IT offices aren’t generally the most talkative places in the world, but you do nevertheless hear conversations relating to optimising the caching, server loads and so on. But no-one has ever approached me asking how they should mark-up a page.

I don’t mean this post to come across a huge bitching session. I’m sure if writing some back-end code was as inseparable from front-end development as writing some html is from back-end development then back-end developers would be horrified by the poor quality of front-end developers’ contributions to the code-base. So I offer the following advice to back-end developers in the spirit of co-operation, respect, Obama and all that.

1. Most important of all, don’t worry about what the web page looks like. Removing ‘helpful’ mark-up put in to make the job of applying the design easier is often the most taxing job for a front-end developer.
2. Never use tables to layout a page. Put a div around each major content area and leave it at that, even though it will mean all the unstyled content stacks up vertically.
3. Don’t use inline styles, as these can not be overridden from a stylesheet.
4. Don’t put text directly into a div. Either the div should be a p tag (paragraph) or there should be  a p tag inside the div.
5. As a general rule, for items on a page there will be a corresponding html element.  Here is that complete list again. Take a little time to get to know what elements are available (you probably already know most of them), or even keep a print out on your desk for reference. Sometimes you have to stretch the definition a little (eg sometimes I will use the <strong> tag a bit like a heading, if the heading is supposed to appear inline within a paragraph). Only turn to using a div or a span as a last resort. If you still find yourself using something like <div class=”heading”> instead of <h2>, consider a  lobotomy.
6. Don’t put in img tags for eg bullets in a list. If the image is a design graphic as opposed to a picture with some meaning, the chances are it can be added as a background image later using CSS
7. Similarly, don’t use <br /> tags to add vertical space. Your designer would probably much rather do it with CSS margin or padding.
8. And don’t use font tags to apply a font.
9. For navigation use a <ul> tag to wrap, and <li> tag containing an <a> for each item. Don’t be fooled by the default (vertical) display of lists. Using CSS they can be laid out pretty much however, so even if the list of links is horizontal you should still use this markup
10. Forms are probably the trickiest thing to mark-up. No-one can quite agree what the best way is, but if your front-end developer is a good one chances are they will like something like this accessible forms method. Don’t be put off by the numbered list, as CSS can get rid of the numbers. Pay special attention to how it marks up the radio/checkbox elements. One thing it misses is that you should probably give a class of ‘submit’ to your submit buttons as these will most of the time need a hook to enable them to be styled differently to ordinary text inputs. (Having said all this, forms are one of the few web page elements that even zealous supporters of CSS design will sometimes revert to using a html table for, so I’d check with your front-end person first how they’d like the form marked up).

Now let’s all just get along!

Last year my job was front-end development for dreamteamfc.com, the Sun’s fantasy league website. Much of the work involved styling tables of data, such as that on the right (and that was by no means the most complicated design, though I don’t have a dummy password any more to be able to access them).

It was a source of constant frustration to me that there was a distinct lack of useful information on the web on how to style tables. Any search for “html table design” or “styling html tables” would either result in an outdated guide to designing websites using html tables (It would be great if the w3c had a great big fiery sword they could use to scour the internet of all mentions of using tables for page layout, as the late nineties has left millions of outdated web design tutorials on the web, cluttering up the place and leading astray people new to the field), or turned up a hopelessly unambitious tutorial on how to use very work-a-day CSS to style text colour and background colours.

So I had to get to grips with data tables – the first I had ever styled as I never learned the bad old ways of web design using non-semantic tables – and after doing so fairly successfully (the only extra markup, apart from classes, needed for the design on the right was an empty footer row in the table, and only a few tiny images too) I thought I should share what I’d learned on the web as few other people seem to be doing so.

Nearly a year later I’m finally getting going on this fairly huge task, and there shoudl, if I stay focused, be a number of posts to follow.

Incidentally, the screenshot on this page, and that on my post about internet explorer, were taken using Fireshot, a blinding firefox extension enabling screenshots of whole pages, cropping before saving. A must for anyone who ever needs to share images of web designs.