27 replies [Last post]
mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

My tableless semantically correct css form:
http://www.urmood.com/urmood_css_tableless_forms/

Hi there,

I've been looking for a good css alternative to table based forms. I found a few articles all with different implementations, however, the majority of them used div, br, lists, paragraphs etc which isn’t semantically correct. Most didn’t validate to XHTML 1.0 Strict, and fell apart in different browsers, and they also didn’t cater for radio buttons, check boxes etc as soon as you added any the form died. The css was bloated too!

ANYWAYS i’ve been working on my own tableless form which covers all the points above and seems pretty bulletproof:

Tested and working in Windows: IE 5, IE 5.5, IE 6, IE 7, FF 1, FF 2, Netscape 6*, Netscape 7*, Netscape 8, Opera 5, Opera 6, Opera 7, Opera 8, Opera 9

Thought I’d share it and see what you guys think, any feedback would be very much appreciated (good or bad I don’t mind) lol

http://www.urmood.com/urmood_css_tableless_forms/

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

I think it all seems pretty

I think it all seems pretty good and can't really find any fault with it. In fact, it's probably better than the way I've been doing forms.
The only things you might want to consider is that some think that tabindex actually creates more problems than it solves and that screen reader users find it more useful to have radio and checkbox labels before the form control (don't have any links to back that one up but I think I've read it a few times at Accessify Forum).

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

Hi Tyssen, Thanks for the

Hi Tyssen,

Thanks for the feedback. Just had a look at the link you posted and I didn't realise that about "tabindex", I'll need to read up on that some more!

In regard to the label position I was trying to follow http://www.w3.org/TR/WCAG20-TECHS/#H44, which says it should be placed after the input. Also read a couple of other articles saying it's best to do it that way, but i'll try and read up some more on that too Shock)

Have you seen any better implementations of a tableless form? I haven't managed to find any, but would be good to know.

Thanks again,

s

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

What I usually do is quite

What I usually do is quite similar except that I've been using an additional span. As far as links to other examples go:

http://www.smashingmagazine.com/2006/11/11/css-based-forms-modern-solutions/
http://jeffhowden.com/code/css/forms/
http://www.themaninblue.com/experiment/InForm/margin.htm

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Have to admit I'm surprised

Have to admit I'm surprised by the possible label before 'radio', 'checkbox' as that is contrary to anything I've ever understood and contrary to the HCI priciples and the W3C which seem fairly definite that labels must follow 'radio' inputs ( I seem to remember an example along the lines of radios laid out inline cause problems towards the middle where it becomes unclear which label is associated with which input); AIM seems to support this as well.
http://www.webaim.org/techniques/forms/controls.php#radio

With Tabindex I think the point may be that it's not wrong to use them but that it's incorrect to believe they will correct an incorrectly laid out form, a correctly laid out one could still benefit from tabindex, possibly?

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

Yeah, it seems like the

Yeah, it seems like the label before radio/checkbox might actually be the minority position, but definitely one that has been discussed before.

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

And the only person talking

And the only person talking about why it's this way (HCI) is Gez Lemon but he appears to be having to repeat himself?

There is the point though that in terms of screen readers, keeping this order despite the associated label linking the items is somewhat of a backward compatible issue.

Although it would actually make life a tad easier from a design /layout /visual point of view I think that labels ought to remain to the right of the radio/checkbox.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Ashdude2000
Offline
Regular
Last seen: 12 years 40 weeks ago
Joined: 2006-10-25
Posts: 46
Points: 0

Problem in safari

dude btw, the "sex" section looks odd in safari and so the the other box at the bottom! the writing goes under the radio button, just thought u should maybe check this if u didnt already know!!

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

mute20 does physically

mute20 does physically moving the label element to the right of it's associated input actually mean you have a 100% accessible form grouping?
as you have updated your example to state.

Or does wrapping the input in the label but placing the text after the input achieve the same thing?

W3C WCAG guidelines were that one should associate labels with controls explicitly until such time as all browsers supported implicit association? do they now?

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

Hi Hugo, Wrapping the input

Hi Hugo,

Wrapping the input in a label should be avoided, this generally causes there to be no explicit association which isn't good. WCAG 2.0 also recommends against implicit association: http://www.w3.org/TR/WCAG20-TECHS/#H44

Implicit association can also lead to problems with screen readers: http://www.brucelawson.co.uk/index.php/2006/we-loves-it-my-precious-and-an-apology-2/

So to answer your question, yes i believe moving the label to the right of the input maintains an 100% accessible form, as there isn't really any other way to do it.

Thanks,

s Smile

mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

Hi Ashdude2000, Thanks for

Hi Ashdude2000,

Thanks for the Safari advice. I'll look in to it.

Cheers,

s Smile

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

mute20 wrote: WCAG 2.0 also

mute20 wrote:

WCAG 2.0 also recommends against implicit association: http://www.w3.org/TR/WCAG20-TECHS/#H44

Although it reads as against due to the fact that some screen readers have problems with this thus the recommendation is to avoid this action , not that it is actually incorrect to do so? and one can use the 'for' attribute while wrapping the input. wrapping the input can allow for some neat little effects to be applied, still we must bow before browser faults as always *shrug*

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

mute20 wrote:Wrapping the

mute20 wrote:
Wrapping the input in a label should be avoided, this generally causes there to be no explicit association which isn't good. WCAG 2.0 also recommends against implicit association: http://www.w3.org/TR/WCAG20-TECHS/#H44

I generally do both: wrap the input with the label and provide a for attribute.

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

lowiepete
Offline
newbie
Lowestoft, Suffolk, UK
Last seen: 8 years 10 weeks ago
Lowestoft, Suffolk, UK
Joined: 2006-11-08
Posts: 7
Points: 0

Some Feedback

Hello Mute,

I too did a lot of research into table-less forms, so I was intrigued with what you did. I'm wrestling with a problem here. As a person with quite severely disabled hands, the accessibility element comes high on the agenda, but disability isn't restricted to the physical effects.

The result of my researches has led me to conclude that a _balance_ between function and useability needs to be given the higher priority. So, the very first impression of your form is that it's frightening! What I'm trying to say is that this is the "perception" that it gives. If I were faced with actually completing it - I'd be sh*t-scared of making a mistake!

Also, there are no visual prompts within the fields, so I'd be in some danger of putting the right answer into the wrong box. As an aside, the [Sex] question - are you asking about my preferences? Should the label not read as [Gender]?

One thing I did learn from was how you used the tabindex numbering, I'll be taking a closer look at that - so thanks for that.

Anyway, that's my two-penn'th - if you'd like to see how I ended up tackling this, then take a look at my feedback form. I've no idea whether or not it is semantically correct, but I do feel that its not intimidating either.

Regards,
Steve (Peter S.)
Caronia II Timeline Webmaster

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Hi Steve, It's interesting

Hi Steve,

It's interesting to hear from someone who can provide direct feedback on accessibility issues, but I'm not sure I follow your assertion that you would find the form mute was showing frightening. Give or take some minor points that is pretty much how I approach forms and includes all the required semantic and basic accessibility issues, as for prompts I would hazard a guess that this was not really the intention of his demo but rather his take on actually structuring the elements.

One thing I would say regarding your form is that the note you make about making a mistake and not filling in all fields of the form will result in loosing all entered data is not a particulaly user friendly one and that would certainly put me off filling it in Smile it's the web developers job to build in some error checking, if a field is blank then you return the person to the form but with the already filled in fields saved and re-displayed. You can do this quite easily for non intensive client server interaction using PHP to check if a hidden filed has been set, if so you populate variable names with values from the posted form. In the form you use these variables to populate the input values. So on initial form no values are set as the variables are empty, on submission a routine checks these posted values and sets them. If an expected value is empty then you automatically return to the form but with any successful values set to a variable to be displayed, if all filled out then you allow the form values to be directed on to the original form destination.

This is one of those aspects of forms that helps people and does not frustrate them when they make a simple error, as we all do from time to time.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

Hi Steve,

Hi Steve,

Thanks for taking the time to review my form. I feel though that you’ve missed the point of the demo. As Hugo has mentioned above, the demo was to show a method of structuring form elements that is semantically correct and adheres to accessibility issues. There isn’t much point in moving away from tables to position form elements if people are going to use different additional markup to achieve the same thing e.g.

,

. Personally I don’t think your form is semantically correct.

The demo form I’ve provided is as basic as can be, anyone using this method to layout form elements should obviously ensure the user interface is amended appropriately. However, with that in mind, and like Hugo, I still can’t see how the form is “frightening!” or why you would be “sh*t-scared” of making a mistake. It is a standard layout for a form and as such is very intuitive, but it's always good to have another opinion.

Having looked at your feedback form I feel there are a few issues you could address, however, there may be reasons why you have done the things below that I am unaware of, if so it would be interesting to find out:

1 - Semantics, use of

,

?

2 - Some people do not use javascript for whatever reason, if this is the case people using your form have to manually delete the text shown in the input fields. If your form contained more fields this could become a tedious task and not very user friendly.

3 - The cursor type you use for your input fields is a hand, it should really be a text cursor. I would have thought that somebody like yourself with “severely disabled hands” would find it even harder to accurately place the cursor in between text should you want to amend it?

4 – As mentioned above by Hugo, maintaining form state is essential. Also if the email address is an important field why not have an email confirmation input? Like the “confirm password” input I have on the demo form. Would save the double warning about the user email address.

5 – Punctuation overload, why “*#*” for a required field? why are all the labels surrounded in “[]”? And why use underscores to highlight information and not or bold text? All this additional punction distracts the eye and makes the form very busy for the user e.g. *Name is a lot neater than *#* [ Name ]

6 – If you wanted to be pedantic the submit button should also be left aligned for form consistency, the users eye has to actively look for the button.

Thanks again for your time. You might also want to check this link out it’s a very interesting read:

http://www.uxmatters.com/MT/archives/000107.php

Cheers,

s Smile

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Good link mute, just what's

Good link mute, just what's required some realworldish tests, although for a moment I thought it was stating that left aligned labels to inputs were preferable Smile

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

lowiepete
Offline
newbie
Lowestoft, Suffolk, UK
Last seen: 8 years 10 weeks ago
Lowestoft, Suffolk, UK
Joined: 2006-11-08
Posts: 7
Points: 0

Oh Wow!!

Whoah Gents...!!!

I don't think that I was claiming at any point that my table-less form was anywhere near perfect! The main point that I was trying to make is that IMHO a balance needs to be struck.

Yes, your form is intimidating - it doesn't give any breathing space. It's the old story of clever use of white space. It's reminiscent of those dreadful forms that the tax man and social security used to use. For a while they improved them - but the politically correct lobby have overtaken them and now they are worse than ever(!) - but I digress...

Use of an explanation as to what happens if the required fields aren't completed is meant as a forewarned is forearmed notice. Many webmasters simply put "Fields marked * are required" and it's not until too late that you find you have lost everything! - clearly, I can't win for being up-front.

As for using PHP to do the verification, that's on my to-do list. The form I presently use is an amalgam of information gleaned from a host of different sources, all then checked, mostly but not exclusively, with Cynthia, for accessibility problems.

Use of the pointer/hand was the result of these researches, where the advocator made a strong case for its use. I simply concurred. I wish I'd made a note of where this was, but never envisaged having to write this.

As far as Javascript is concerned, I think that so few people ever turn it off as to render the argument insignificant. I'm reminded of a chap who very recently answered "What's a browser?" when the key question was asked. It's my belief that the recommendation to turn Javascript off was a message put about many years ago, when few people knew what it did, and were being cautious because it _might_ be dangerous.

In the link you provided, the top conclusion was...

Quote:
Label position
— Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.

Looks like I got something right then! The biggest stumbling block I've found with CSS is trying to get the "leading" (CSS padding) to work successfully across most browsers - hence my departure from the semantics and relying on P and BR to do the laying out. It seems that there's a strong argument for not styling form elements too. Before you think, "Hey, you're trying to be clever", all I'm actually trying to do is find that elusive balance...

1) What to use as a standard
2) What to use sparingly
3) What to avoid

Anyway, having established that I'm by no means an expert, like you I welcome the feedback - all part of the learning exercise. For example, I take the point about the punctuation.

However, as you can probably see, I'm still not entirely convinced about the semantics argument. Clearly there are two schools of thought, those who insist that a form _has_ to look exactly the same everywhere you go, and those who don't. I'm in the latter camp; my form isn't part of job application, it's an invitation for feedback.

My feedback form is but one page out of over 650, and as long as it works reliably and is not too intimidating, then I'm happy enough. What I do know is that I have spent a disproportionate amount of time in trying to get it somewhere near right, and no doubt the PHP validation will take hours and hours more of testing - but I guess I'll get there, eventually.

Regards,
Steve (Peter S.)
Caronia II Timeline Webmaster

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 7 years 17 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

A couple of points. -

A couple of points.

- putting descriptive/example text inside the input control. It shouldn't be a problem. Tabbing into the input control should highlight the complete contents, meaning the first keystroke will wipe the descriptive text. Triple clicking also highlights all the contents. If forms were commonly prefilled with descriptive text I am sure people would come to expect to triple click or browser manufacturers would treat the on focus click in the same way as tabbing.

I have always wondered about using descriptive text and instinctively I think its a good idea (I have no idea how non-visual browsers handle it).

- another reason not to use left/right alignment of prompts/input controls is font size and multi-linguality (if that's not a word it should be !). Label above control will be immune to the problems those two things can cause.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Browsers do indeed cope

Browsers do indeed cope quite happily with text values so that really is not a problem, wiping out text with first key press.

I like a simple bit of descriptive text and a few times it's been required along the lines "your username" or somesuch, I think screen readers will just read the control and then the value as written at least fangs labels the textfield "Edit" then follows with the pre-entered text, so seems fairly clear that one is going to edit or replace that field.

Have to admit left to my own devices I instinctively have always placed labels above their inputs at least with text inputs.

and as for multi-linguality please it's enough coping with Gary's surreal vocabulary 'odosity', 'octothorpe' I ask you!

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

lowiepete wrote:As far as

lowiepete wrote:
As far as Javascript is concerned, I think that so few people ever turn it off as to render the argument insignificant. I'm reminded of a chap who very recently answered "What's a browser?" when the key question was asked. It's my belief that the recommendation to turn Javascript off was a message put about many years ago, when few people knew what it did, and were being cautious because it _might_ be dangerous.

I think you'll find it's more prevalent than that. In fact, some resources put the figure as high as 10% and certainly the practice is more common on office networks where network administrators are trying to keep a lid on anything malicious getting in.
In fact, an article posted on 456 Berea Street just yesterday highlights that javascript being disabled is still a major concern.

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

lowiepete
Offline
newbie
Lowestoft, Suffolk, UK
Last seen: 8 years 10 weeks ago
Lowestoft, Suffolk, UK
Joined: 2006-11-08
Posts: 7
Points: 0

Some CSS Tips

Hello Folks,

So, it appears that we have a consensus that labels go just above their input / selection elements. Getting back to the CSS aspects, is it possible to style these and keep the semantics?

The biggest problem that I have found is in adjusting the leading between the label and its select box below it, without resorting to using paragraphs and breaks. They resolutely stick together, and for some reason IE doesn't seem to want to pick up any styling of the select box either. I'm probably overlooking something obvious to everyone else Smile

As an aside, it appears that there maybe some required "default" styling attributes for each html element. The area of forms is but one aspect. For example, when should { display: block } be used, and when should it be avoided? Does a kind of stock list of recommendations of attributes to use exist for each HTML element?

Regards,
Steve (Peter S.)
Caronia II Timeline Webmaster

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

It should be possible to

It should be possible to just style the respective labels and inputs without resorting to extra markup floats and clear properties should do the trick and you will be able to margin labels from the inputs.

Styling any form controls is a very frustrating experience as all browsers have different defaults and many aspects of controls are actually rendered by the UA rather than via CSS.

Not sure what you mean in your last paragraph but most elements have proscribed default styling, however generally you can overide any set styling , forms being one case where it's more frustrating than it's worth at times.

One subject not touched upon in all this talk of CSS styling is how the marked up forms appear when styles are disabled, it's always worth checking this aspect as sometimes they can look a mess and one hankers after slipping in the odd <br /> here and there Smile

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

mute20
Offline
newbie
Last seen: 13 years 2 weeks ago
Joined: 2006-11-29
Posts: 6
Points: 0

Hi, The demo form I have

Hi,

The demo form I have put forward is supposed to be versatile and portable. To achieve positioning the label above the input, it's a simple case of commenting out or removing 4 lines of the css:

http://www.urmood.com/urmood_css_tableless_forms/urmood_css_tableless_form_label_above.asp

When I get a chance I'll write up a full tutorial on my form. I've also managed to get opera 5 and opera 6 working again while maintaining accessibility which is good, just need to sort a couple of things in Safari and I'll upload the revised version. Can't think of any reasons not to use it after that, 100% pure css, accessible, semantically correct, and Xbrowser compatible Smile

A lot of good points have been brought up in this thread so I'm going to check them out. Would be good to have a perfect form!

Cheers,

s Smile

Ashdude2000
Offline
Regular
Last seen: 12 years 40 weeks ago
Joined: 2006-10-25
Posts: 46
Points: 0

hey

yeh dude, i looked at the link above and it still has problems in safari with the tick box and radio button sections!! the text goes under the buttons, and cant read the text. then it will look awesome. but yer as u sed above it would be worth spending a bit of time having a look at that! especially as safari is becoming a more popular option nowadays!!

cheers

thepineapplehead
thepineapplehead's picture
Offline
Guru
Last seen: 1 week 4 days ago
Joined: 2004-06-30
Posts: 9668
Points: 801

Tyssen wrote:mute20

Tyssen wrote:
mute20 wrote:
Wrapping the input in a label should be avoided, this generally causes there to be no explicit association which isn't good. WCAG 2.0 also recommends against implicit association: http://www.w3.org/TR/WCAG20-TECHS/#H44

I generally do both: wrap the input with the label and provide a for attribute.

Is this a good idea? I've always used something like:

First Name

/thread stickied

Verschwindende wrote:
  • CSS doesn't make pies

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 14 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

That's the way the W3C

That's the way the W3C recommends you do it which is explicit association. They recommend against implicit association which is like this:

First name because some assistive technologies don't handle the labels properly.

What I've been doing is actually a combination of both:

First name because I set the display of label to block rather than wrapping the label in another block level element. The trade-off is that I need to use an additional span inside the label for the text. Looking at mute20's example though, it's something that you don't need to do if you use negative positioning on the inputs.

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 2 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Both are correct TPH the

Both are correct TPH the wrapping is more to do with problems that screen readers have. Usual story; browser faults, and we have to provide the solutions! too much too hope that screen readers might actually improve their browsers or even support the aural media, can't think who else it was really intended for.

Roll on Web Forms 2.0 loads of nice features/attributes shame they couldn't have been thought of originally.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me