wheresrhys

The other day I neglected to mention how I had resolved the list/table dilemma on the site I’d been working on.

As I explained, the content fitted the semantics of a table more than that of a list, but Internet Explorer’s bugs in applying positioning to <tr> tags (up to and including ie8) prevented me from using a table to implement the design.

Or did it.

In the end I had two choices of mark-up for each item in the list:

<ul>
  <li><h3><a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
</h3>
     <ul>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>
        ...
     </ul>
  </li>
</ul>

or

<tr>
  <th colspan="3" scope="row">
    <a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
  </th>
  <td class="rating">
     <img alt="4 stars" src="/img/star4.png"/>
  </td>
</tr>
<tr>
  <td>All Inclusive</td>
  <td>8, 15 dagen</td>
  <td class="location">Marsa Alam</td>
  <td class="price">vanaf €399</td>
</tr>

The second example, combined with appropriate column headings, I figured gave the closest approximation to the real table structure of the content. And the presence of a <th> every other row does suggest that rows are to be taken in pairs (though I’m not sure this is any help to screen reader users).

The above means, I think, that I am closer to web design zen. I have rejected the false grail of table based design, and only now that I have mastered CSS and semantic structure can I claim to understand the table and start to mold it to my enlightened purposes.

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!

Marking up web pages semantically is normally more or less a doddle. Most tags are named (or have abbreviated names) that are straightforward. If you’re writing a  paragraph, wrap it in a <p> tag. If you’re writing an ordered list put it in an <ol>… and so on and so forth. And it’s actually less effort than typing eg <div class=”list”>.

But there are nevertheless lots of examples where the tags offered by (x)html seem hopelessly limited in their semantic meaning. Recently I worked on this site. On the home page is a list of holiday offers, and I ummed and aahed over how to mark it up for a while. Previously I would always follow the same practice – lists of complex items would be marked up as a list, and whatever more complicated markup needed would be placed inside the <li> items. But I’ve read somewhere that putting too much information within a list item can actually be a hindrance to accessibility,  so this time things would be different.

Design of list of holiday packages

The design superficially lent itself to a simple nested list:

<ul>
  <li><h3>Blue Reef Resort</h3>
     <ul>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>
        ...
     </ul>
  </li>
</ul>

But it’s hardly satisfactory. The items in the sub-list are in fact properties of the particular holiday offer. In fact, the whole thing is more like a table, which becomes clear if we just move some bits around.

Modified design to show true semantic structure

So to achieve the required design all we need is to hide the table header and move some of the cells around. The first task is easily completed with a display:none, but the second is alas not very feasible. While support for floating and positioning table, tr and td elements is supported in ie8 and other good browsers, in ie6 and ie7 there are big problems as they more or less ignore that the <tr> element is there. You can’t float a tr, you can’t give it position:relative (in order to absolutely position td’s within it) but, bizarrely, you can absolutely position a tr, though this is of limited use. Racking my brains for a use the only one I’ve come up with is in order to give you the ability to absolutely position the tr’s td’s absolutely in relation to the tr, but then you would need a different style for each tr to avoid them layering on top of each other. Which admiteddly could be generated dynamically as an inline style, so perhaps not all that hopeless a situation.

ie6 and ie7 also don’t support floating on table cells either, in case you were thinking that was an option.

As it turns out, I may have discovered a new bug in Internet Explorer 8. While writing this I set up a test page to make sure what I thought was the case was correct (turns out I was, in my main thesis, incorrect, as I thought HTML/CSS had no provision for positioning table elements). Here are 3 screenshots:

Correctly positioned table elements (firefox)

Incorrect table element positioning (ie8)

Incorrect table positioning (ie6/7)

Once again, ie has problems dealing with relative positioning on tr’s. On the face of it it’s not as bad in ie8 as in ie6/7, but what’s happening is that instead of letting the tr’s confuse the positioning completely, it just ignores them, and goes ahead and positions relative to the next positioned ancestor, which is een worse if you look at where the cells get put relative to where they shoudl be – ie6 and ie7 nearly get it right (but this might be a fluke that a larger table would unmask), but ie8 is completely wrong.

The long and short of this article is that there are lots of instances where a table should be the natural choice of markup (given a little thought about what the content’s structure is), but once again thanks to Internet explorer, it’s going to have to be a nice idea that will have to be shelved for the time being.

So, unless you fancy individually positioning each tr with its own style rule, nested lists it is for now.

A few months ago a blogger posted a now infamous post on the falilings of CSS as a design tool, and advocating tables be used instead (if you want to read why he’s wrong, this is probably the best riposte, quite rightly pointing out that he thinks because he is bad at CSS then CSS must be too hard to do design with, and you can justify using tables instead).

But what I found most notable about the whole debate was how he throws meaningless phrases around and no-one seems to pick him up on it.

For instance

tables have the correct semantics for doing layout

What on earth does this mean? From dictionary.com:

Semantics: the meaning, or an interpretation of the meaning, of a word, sign, sentence, etc.

Well, what he seems to be saying is that tables’ meaning is “used for layout”, but the whole point is that they don’t!

In another article I think he reveals his not particularly investigative side.  In response to a comment:

> put your content inside a table, lose most users with disabilities

That is far from clear. I just did a Google search on “html accessibility tables” and got a zillion pages on how to make tables accessible. Even the W3C’s own web site says you can make accessible web sites using tables as long as you adhere to certain constraints.

Well, I did that search for html accessibility tables, and most, if not all, of those zillions of pages are about making html data tables more accessible. If you search for html accessibility tables layout you will find a lot of pages explaining why you shouldn’t use tables for layout as it’s inaccessible. The only article I could find condoning table use dated from 2002, in a time when dreamweaver still largely used tables, and the condoning was merely an acknowledgement that while the standard tools in the industry still used tables you couldn’t expect everyone to switch over overnight. In fact the article opens with a pretty good summing up of what’s wrong with tables.

So, why have I written this article, responding to something from a few months ago? Simply to illustrate that there is still so much junk been pumped out onto the internet on designing using tables that it is as hard as ever to find information on designing tables.

I really think I’ve hit the nail on its head when it come to captioning pictures. I really do.

It always bugged me that there wasn’t a really semantic way to caption a picture, despite it being a very common use of words both on the internet and off (for instance, I caption everything I see by talking about it VERY LOUDLY), and this all came to a head yesterday on stackoverflow.com.

And I hit upon the perfect semantic way of doing it. The picture on the right is a working example. The caption is actually a heading – a h5 in this case – above the image in the markup, but a combination of padding and positioning has put it beneath the picture.

Semantically if you put a heading above a paragraph/section then the heading should tell you what’s in that paragraphsection. Surely the same extends to images too. So my markup literally means “The following picture is a picture of a man looking like santa hammering in a nail”.

So here’s the bare bones code, though you’d obviously want to use classes and wotnot:

<div style="position:relative;padding-bottom:50px">
<h5 style="position: absolute; bottom: 0pt; left: 0pt;
           height: 40px; line-height: 14px; font-size: 12px;">Caption</h5>
<img src="..."></div>

Vive la moderate improvement in accessibility.

Finally, I realised today that because of web standards, my job will get easier with time – another 2 years and I won’t have to take ie6 into account… a few more after that and ie7 will be gone… and from ie8 it will be plain sailing. So the job will be easier, but much less fun.

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.

Why is there a woman in a bra and a hard-hat on my blog?

It’s a legitimate question.

No, I haven’t been hacked into by feminists. And I am certainly not endorsing the new bob the builder adult role-play range.

It’s here to raise awareness of a far more pertinent question: Why is there a woman in a bra and a hard hat on most pages of consumerdirect.gov.uk. Now, I’m no prude, but was this really the best choice of imagery for a website which is just a  boring old consumer advice site? I saw the South Park episode with Paris Hilton in it the other day (series 8 has got to be the best), and the jist of it was… come to think of it, not exactly my point now, but it is a sad reflection on society when people – the government for chrissakes – think it’s necessary to sex up a consumer affairs site.

Particularly when they have clearly paid a lot more attention to the garish and inappropriate design than they have to the important stuff. The contact form, we are gleefully informed, doesn’t work in Safari, probably the most standards compliant browser. It’s bad that a site, particularly a government site, doesn’t work across browsers, but for something as uncomplicated as a contact form to fail… I wonder, I really do.

Oh, and the reason for me visiting consumer direct in the first place? RyanAir’s booking form allows your browser to save all your credit card details, including CV2 number, without you saying you want it to. I was going to email RyanAir to tell them this should really be fixed, but they have no way of contacting them online (take a look at this RyanAir bashing site).

So a day of online dissatisfaction. Except, that is, that I’ve booked my holiday to Riga.

The new specs for HTML 5 and XHTML2 are being hammered out at the moment, and I think for many year hence too. While reading the Jungle Book in the park just now and ruminating on how best to build a certain navigation without too much superfluous html it occurred to me that there were two reasons for trying to minimize the extranuous html:

1. More tags means a higher code to document ratio, which means lower rankings in Google
2. The extra tags are confusing for screen readers

Then I thought of a possible solution to part 2.

Empty tags (such as the <em>’s used in the navigation of this site) and other meaningless bits added to the html for the sake of making the design work could be wrapped in special tags that:

1. Semantically mean “the thing inside me has no meaning”
2. Can easily point out to screen readers that what is inside them is to be ignored

Thus making the designer’s life easier without compromising accessibility

These tags could be <nomeaning><empty><e>, or anything really. There’s plenty of possible unused words.