The examples should look like the screen grab. Normally you would add a size value to an input like:
<input id=“name” size=“20” />
When you do not specify a size, a default size is used, which is possibly different in some browsers. It looks exactly right in all the browsers I tested with, but it is obviously different on yours. The thing is, the inputs in your example look way out. Is this the same for all browsers on your machine?
Copy & paste the code below to embed this comment.
Kerri Hicks
I’d be the first person to emphasize that tables should not be used for layout (except with tabular data), but I fail to see how the form presented in this example is not tabular data.
Imagine a form to collect information about your pickup basketball team. You’d have a column of row names, and then five columns with input fields. There’s the name row, followed by five name fields to fill in. Then there’s the position row, followed by five text boxes in which you put each player’s position, etc. The name/value pair relationships are clear, and each field is labeled (“Name – Player one. Name – Player two,” etc.)
How is this not a table? And then if it only has one column of information to fill in, how is this any less a table?
Using tables for simple forms such as the one in this example also has the benefits of lists that were outlined in earlier comments—a screen reader gets to the table, and it reads, “Table with two columns and five rows” (so, just from the structure of the table, you know how many items there are not just down, but across, too), then it reads the summary and/or caption that you’ll have added to your table, “Contact information form,” or something else equally descriptive.
I’m open to being convinced otherwise, but to me, this type of form is clearly tabular data with name/value pairs.
Copy & paste the code below to embed this comment.
Anthony Baker
This works fine on Safari, but the form fields aren’t aligning properly using Flock’s 0.7 beta on the Mac. Same thing when using Firefox 1.5.0.2 on the Mac—the form fields don’t align evenly and are instead simply aligning left following the label for each.
I’m not able to test in Firefox 1.5.0.2, but I just tested in an earlier version (1.0.7) and it works fine. I’ve also tested in Flock 0.7b and again it works fine. I’m using OSX 10.4.6. Do you have JavaScript disabled?
don’t use javascript for styling, unless it’s for the crappy IE browser. Let all other browsers simply use CSS
don’t try and find a use for lists when there is none. Though I must agree without CSS it looks nice. But I think the main issue is that without CSS it should be usable, not nice looking. a simple break will do.
don’t use -moz-inline-box, don’t use inline-block (not yet that is)
For interested readers, I wrote an article in search of all possible float solutions for forms that have no additional markup. Let me know if you have more methods that I could include.
“floating forms article”:http://test5.caribmedia.com/CSS/Secrets/members/michiel/floating-forms.html
Wouldn’t the javascript be “better” (for some values of better, offer not valid in all states, some settling may occur it transit) if it looked for inline-block and replaced it with something better on broken browsers?
I realize that the article isn’t about inline-block, per se. But to me, it’s one of the features I wish worked in FF/IE. :-/
Copy & paste the code below to embed this comment.
Kevin Dougherty
I appreciate the article, Nick. Nice work. Compelling discussions as well.
I would like to get your – or anyone’s – thoughts about setting the size of input fields. While it is not addressed specifically in your article, I think it has relevance given that we are attempting to make forms “prettier” and more “accessible”.
My question concerns setting the input size to be the same length in all cases (except for input types “radio” and “checkbox”). I grant that – when all the same size – the inputs do make a prettier form. Your form does this, and it indeed looks great. Yet, what about considering the input in relation to the data it expects – and adjusting the input’s size attribute accordingly?
A specific example is an input for Zip Code for a US address. I feel it presents a usability issue to the user when the width of a Zip input is as long as the input for Street or City. A US Zip is necessarily shorter and it makes sense – and is fair to the user – to indicate that visually, even at the expense of creating a “jagged right line” of inputs on the form. Thoughts?
This may be a bit off-topic, but what is so wrong with tables? Why is a table in a form such a “semantic faux pas?” I could draw up that form in a fraction of the time, and do it using less bytes if I use tables. All I hear now-a-days is how horrible it is to use a table. Why use a simple table when you can create a huge stylesheet file and mess with divs that never show up correctly in all browsers?
Back on topic, nice example though.
Back off topic, I can feel the heat from the flames already.
Yet, what about considering the input in relation to the data it expects — and adjusting the input’s size attribute accordingly?
That is sometimes appropriate, but in many cases you won’t know the length of the input. If you’re asking for name, or town, or email address, you have no idea how long it’s likely to be – so set a size that will be big enough for most people and others can scroll if they have to.
A specific example is an input for Zip Code for a US address. A US Zip is necessarily shorter and it makes sense — and is fair to the user — to indicate that visually, even at the expense of creating a “jagged right line”? of inputs on the form.
I know this is slightly off your point, but consider the possibility that people from other countries will be entering their address in your form – might it be better to have a textbox so they can enter the address in whatever format is most appropriate rather than be constrained by one that is designed specifically for US addresses?
In answer to your question, I think it would look fine either way, whether the postcode box is the right size for the input, or lined up with the other fields. Part of it will depend on the rest of your form, and how many fields there are of the standard length.
In the case of input fields with an expected specific length there is only one way to have the length of the field match the length of the data across browser-platform combinations:
do not use CSS to set a width
set the attributes maxlength and size to be equal
set the font-family to a monospace font
I have experimented with this and it was the only way, for example with a five-digit zip, to guarantee that the data input exactly matches the length of the input element. This was tested with Opera, IE (from 5 to 7 on Mac and Windows), Firefox, Safari and Netscape 6.
As I was reading your last comment (#52) it dawned on me where the problem lies, and likely explains the similar reports you have had regarding Flock and FF on Linux.
In your example, you are not explicitly setting the width of text input and textarea elements in the CSS, but instead leaving it to the “default” size, or, in the case of the textarea, using the cols attribute in the textarea tag to set cols=“25”. If not explicitly set by CSS, the width of such elements will be affected in Firefox and other browsers by the user’s settings for default font and font size. It appears that my (and other people’s) default settings are larger than yours, hence the observed differences.
We have no way of knowing a user’s browser settings, so it is risky either to leave the field widths unspecified, or to use the size/cols attributes in the HTML tags. To be safe (well, as safe as we ever can be, in this game) we need to set widths in the CSS to make sure labels and inputs don’t bump into each other, or knock each other out of the way.
Of course, every individual form will demand its own styling, including input and textarea field widths—but maybe that needs to be made clear.
Thanks to Christian Tietze in comment #3 for linking to my Awesome Form. I just wanted to note that I’ve updated “Awesome Form”:http://paularmstrongdesigns.com/examples/css/awesome-form.html
Awesome Form is complete cross-browser compatible CSS for displaying forms using only its most bare elements. No lists, no tables, no guff. I hope others find it useful!
I appreciate that the article you wrote does allow developers to create accessible forms, however the need for Javascript seems to be crazy in my opinion. Although the Javascript is unobtrusive, it still creates more work for the developer. It is possible to create the same form using <dl><dt>&<dd> tags for Markup and only CSS to style it. It’s still very accessible, has more semantic meaning and no need for Javascript. What would happen if the user had Javascript turned off? Answer: It would no longer be a “Prettier Accessible Form”. I really don’t want to sound like I’m moaning, as it is a step in the right direction, but I urge you all to check out Dan Cederholm’s technique for forms.
Copy & paste the code below to embed this comment.
Patrick Gates
Firstly let me say that I enjoyed seeing a form layout that took a stab at semantics and didn’t use floats, which have been plagued me quite a few times in designing over the years. There’s certainly no God-sent CSS template that addresses the form (and there may never be), but please keep exploring these new ideas as they’re always welcomed and enriching.
In trying variations on this CSS, I discovered that if you set text-align: right; on the <li> and use padding-right to shift the inputs/labels to your liking, then you can obviate the need for js/proprietary tags. This also minimizes the need for CSS hacks. Granted, you have to be willing to deal with right-aligned label text, but the result is very clean/crisp. Here’s a very short “example”:http://www.geocities.com/pgates18/Content3.htm for your perusal.
Of course, as often occurs in the Web Design world, solving one problem reveals at least one new problem. Inputs and TextAreas can generally be made to render equally across many browsers. The select element misbehaves in this regard, however (I’ve only tested in IE6, FF1.5, Op8.54/9). Opera is the only one of the three browsers I’ve tested (assuming the widths are equal in the CSS) that naturally renders the select the same width as the other form elements. IE and FF both render 2px shorter in the case of my experiment.
Maybe I didn’t solve anything—just trying to follow the tradition of sharing ideas!
I just posted another alternative solution “on my website”:http://bajooter.com/node/22 that may be viable. It uses the method mentioned on “Quirksmode”:http://www.quirksmode.org/css/forms.html plus there isn’t any javascript and only I only used one hack.
Copy & paste the code below to embed this comment.
Matthew Orlando
@ Kevin
I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.
I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:
*************
*************
**********
**
*****
It’s pretty obvious that the last two fields are State & Zip
Copy & paste the code below to embed this comment.
Matthew Orlando
@ Kevin
I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.
I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:
*************
*************
**********
**
*****
It’s pretty obvious that the last two fields are State & Zip
For me the tabular data issue is moot because I prefer against using tables because of the hell involved with javascript inserting and manipulating them (which, I suppose, evokes a whole new set of complaints, but on my current particular project I’m working on an internal website which requires JavaScript anyway for remote scripting purposes).
Shoot. Should have mentioned that I’m really digging the use of lists.
Think beyond address forms, people—ordered or unordered lists are perfect for things like questionaire’s or any extensive forms. This little approaches being what prototype.js is for js, for css. Obviously, compliancy is an issue but in the current world of CSS compliance, it almost always is anyway.
I echo many people’s feelings here, as soon as I saw the JS to ‘fix the layout’, it was never going to be a popular solution. The idea isn’t to bloat the code and slow down browsing running functions.
Stick with the floats or use tables for the forms. I’ve noticed no problems with the form on my site using floats, which has been checked on many browsers Four Shapes contact form. However, that form isn’t too complicated.
Your form is nicely designed, but I don’t think it will be used too often.
Someone once demonstrated to me what a screenreader actually does when presented with a list element. It spoke at length about the list item at each element, before describing the contents.
No further demonstration/explanation was necessary, and since then I’ve refrained from using lists inappropriately for nav menus (when div/span sets will do*) and never inside forms.
*div/span groups will straight swap in CSS (with less default style removal) and can also work better on unstyled (mobile?) pages.
Copy & paste the code below to embed this comment.
Ross Clutterbuck
I do apologise in advance because I’m normally very open-minded and listen to many different sides of a discussion, but in rare occassions like this one I get really annoyed.
In a nutshell: will all you standards-Nazis get over yourselves!
Where ANYWHERE in this articles does it say “this process is 100% reliant on JS and CSS and it’ll all break and look rubbish without it – to hell with standards!!”.
I’d strongly suggest you go back and read it again – this process works perfectly well without JS. The only reason JS is in there is to fix the continuing rift between CSS implementations in browsers – and here I was thinking 1997 was almost 10 years ago.
So instead of ranting and raving about how using JS to style is the work of Satan (and the process doesn’t style through JS the code simply fixes browser errors) why not focus that energy into bullying the browser manufacturers to get their act together and implement the established, 1,000 year old specs completely and accurately.
Only THEN when we have 100% of browsers 100% compliant can you all go off and complain about hacks, fixes and workarounds if a process or piece of code deviates from standards.
But of course this is never going to happen because new technologies are invented and maturing all the time.
Sheesh if you don’t like it, don’t use it!
Personally I’m going to rectify the erratic behaviour of long labels but making sure I don’t actually have any, but I’m not going to jump down the author’s throat just because he’s said “I’m going to fix omissions in a browser through script”.
Copy & paste the code below to embed this comment.
Bernd Klenk
I was fascinated by the article and tried to implement all into a current project and it all worked well… except in the new Opera 9.
The word “null” is inserted before all label contents.
I am not a DOM-specialist, so there isn’t much that I can say or do about it…
What does: this[removed] = null; in the script really do?
?
Copy & paste the code below to embed this comment.
James Byers
Forgive me if this has been discussed earlier in the threads…
I’ve seen a host of single column form solutions but they all service very small forms. What if you have a large amount of fields that need to be collected? Are there any two column css form solutions?
By the way…now that form behavior is being completely rewrittren by Ajax and other dynamic technologies, don’t we need a new set of rules for styling them? For instance, we’ll need the styles for error and confirm messages that appear within the form. Here’s an example Ajax powered newsletter signup form.
Copy & paste the code below to embed this comment.
David Osbourn
Can someone explain how the stretched gradient is acheived please? I’ve tried copying the background: url(….) CSS but I just get the 1×2 pixel image repeated across the bottom of my fieldsets. I can’t figure out how to stretch the image to 100% of the height of the fieldset.
Copy & paste the code below to embed this comment.
Christian Tietze
Well, “David”:http://www.alistapart.com/comments/prettyaccessibleforms?page=9#86, why don’t you look at the CSS source, copy the image URL and view the image?
> !http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/images/cmxform-fieldset.gif!
It’s a high gradient image. No CSS magic, just images.
Maybe this was not the point of the article, but if word “Accessible” is used in the title, I can’t understand why clicking the labels of the radio buttons doesn’t (isn’t designed to) work!? For me, connecting labels with input fields using FOR and ID attributes is a must. Unfortunately not all the web designers use this rule – see checkbox under the “Search ALA” input ;) Laziness? Unawarness?
I really like the way it displays in Firefox but I have to say that using JavaScript for the form makes it not quite accessible in my books. I like the architecture of the form as far as the code but using JavaScript just made me go “ugh!”?. Why are tables so bad when using forms? I think forms is a good use to put a good old table”¦
Copy & paste the code below to embed this comment.
Jordan Gray
I’m intrigued by the fuss Nick has caused by using an ordered list, because I’ve seen them being used to structure forms for years. Almost all the paper forms I need to fill in for my government, my university or my workplace—in fact, even surveys—have been represented as an ordered list of fields. This structure is especially useful because it is allows one to instruct the reader to “skip” a range of fields if they are not required.
Given that it is an established standard, how precisely is this not legitimate? The only convincing argument I can see for not using them is presented by Pid Ster, who explains that the form becomes less accessible for screen readers; and then, the impractical purist in me cries that this is surely a fault of the software, not the structure. (Incidentally, can any more experienced readers tell me if this is the case for all speech readers?)
Definition lists I find particularly challenging, mainly because I’m not totally sure about their semantic intent. What is a definition list meant to imply? Is it really legitimate to use them merely for association? Aren’t labels and fieldsets sufficient—for forms, at least? In fact, isn’t that their explicit purpose? Tables, in my opinion, are preferable for data presentation, not data entry. I know that they often mean less markup, less complex CSS and less cross-browser hassle, but (in my opinion) they are also less semantically appropriate.
Not that I consider definition lists or even tables to be a complete semantic faux pas, but they don’t immediately strike me as the best structures.
As for using ECMAscript to amend browser CSS support: the form degrades gracefully and is reasonably attractive without the fix, which itself is relatively unobtrusive. Admittedly, a perfectly workable solution could be created using floats, but the author’s stated aim was to develop a solution which could be “dropped” into place, and float-based layouts are often very brittle (an issue I’ve experienced first-hand).
I mainly use paragraphs to markup forms, and in future I may well use a few lists. Excellent work, Nick!
Thanks Nick, I appreciate there is no magic solution to this problem. Personally, using the javascript or ol element doesn’t grieve me as much as others here, and I still think this is better than tables.
I’m only mentioning this because nobody else has brought it up – but using the external library is a bit of a worry – it’s 10kb of extra data that needs to be downloaded. I’m sure the library does all kinds of good stuff, but only if you use it.
I’m struggling to keep my pages looking good, functional, and less than 100kb before compression, so an extra 10kb for the form is a bit expensive.
Is there a way you can extract what you need into a standalone piece of script? I’‘m sure you could achieve what you need with a page or so of script, rather than requiring the library with all it’s other features.
Copy & paste the code below to embed this comment.
Eric Brown
How can anyone argue against that a form is a list of questions and answers? US residents: have you never filled out a tax form, or a DMV form, or any other kind of form? Even your W2’s are numbered!
I number fields for everything. It makes support calls so much easier, too. “I don’t understand question 6.” I’m glad to see other developers starting to do the same. DL/DT/DD lists are good, too. As a website that supports a large number of impaired users, we get many compliments over our use of numbered lists.
The earlier solution linked ( “Paul Armstrong”:http://paularmstrongdesigns.com/examples/css/awesome-form.html ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.
I have a feeling most people that are against the JS didn’t even look at the example with JS disabled in Mozilla—it may look a little “off” but it is still usable.
I am excited to see your use of ol to mark up form items. I think this markup is just right. I actually disagree strongly with the use of tables and definition lists to mark up form controls.
The semantic realationship between the text and its input exists already, it is created by the label tag and the input tag (with appropriate attributes, of course). I think your use of OL is perfect for establishing the semantic relationship between the different input/label couples which compose the form.
I had previously used a more minimal markup :
<label><input>text text text</label>
The problems with my method were : 1. inverted order of text and input, and 2. with CSS turned off the form was still technically useable but turned into a soup of form controls and text.
Javascript for layout makes me very hesitant… I don’t like the idea that it might be used to shortcut actual thoughtful CSS development. On the other hand I’ve inherited divML projects, where more than 40 divs were used to create three boxes of equal height in a row.
When one has tried to do CMS development on a bloated project like that it starts to be easier to see the value of using Javascript to add extras that aren’t necessary for the page to function especially when it means we can keep the markup clean.
Excellent article Nick, thanks for taking the time to write up your method.
My only concern about relying on JS workarounds for style is unforeseen collisions with Prototype or Script.aculo.us (or any other Ajax library). Have you tested this method with Rails form helpers, or other server-side solutions that dynamically generate forms and form interactions?
Not busting your chops, just asking. This article helped me see forms in a new light.
Copy & paste the code below to embed this comment.
Sam Thomas
I’m having a different problem using this on my own page with firefox, but it doesn’t affect the examples. I did try not including any of my normal styles (using just the example instead). Basically firefox ignores the width’s for the labels and the form itself. Anyone know why?
the snag is … you can’t do them with the current css :-(
I realise now why Nick’s demo shows all radio and checkboxes on single lines in their own fieldsets – I’ve just tried doing multi-column radio/checkboxes and sure enough, the
breaks the line and wraps to the start of the next line, under the label left-aligned :-(
I am very much anti-JavaScript, but face it, it’s use here is unimportant towards accessibility, nohng breaks if it is turned off.
I did live in Germany till recently, my wife is German and all my three girls are Half German. I do not appreciate Ross Clutterbuck’s comment (78) about “Standards-Nazis”. It is very inapropriate when “Zealots” or “Crusaders” would have worked nicely. It is time to get over yourself, the war ended 50 years ago and not even my wifes parents and kids grandparents were involved in it.
My one important input here is less JavaScript as the use of innerHTML as mentioned in comment 26. Best of my knowledge innerHTML is not supported by XHTML when correctly served as XML, only if served as Tag Soup. Hence this would not work in my personal sites. So any XHTML conscious designers should keep that in mind when using application/Xhtml+xml MimeType.
@ Eric Brown and further readers:
“The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”
Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com
@ Eric Brown and further readers:
“The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”
Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com
Hello. Opera 9.01 is inserting ‘Null’ in front of the label values for me, with the intended label then dropping down a line. Anyone got a fix for that?
I know I’m awfully late to the party, but I was wondering about the statement in the article that, “forms don’t constitute tabular data.”
I’ve heard other people say this, and I really don’t get why. Especially given the concept of label/data pairs. In fact, I would suspect that when most forms are submitted to a database the data is submitted in a near identical format (e.g. The first column being an identifying label, and the next column being the data (although, I still think it would be semantic, even if the order was reversed… just kind of whacky in L to R reading languages)).
Copy & paste the code below to embed this comment.
arn ie
Here is a poor attempt at re-implementing this using Prototype.js since JQuery clashes. This requires that the form has an id=“cmxform”, I’m sure people out there that actually know what they’re doing could improve upon this.
Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above.
I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.
This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.
Someone above was asking about a
“tableless two column css layout”:http://www.yeago.net/work/2006/09/two-column-css-layout.html
Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above.
I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.
This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.
ps: severe apologies for the double-post. forgot to Textile.
Let me first say that this article has become a great resource for me and has changed the way I think about and create forms. But I’ve found a problem that I’m surprised that no one has mentioned here. I’m developing on a Mac, and everything looks perfect on Safari! But in the rest of the browsers I’ve seen, there are inconsitencies. I’ve done a little modification to the CSS for my own purposes, naturally, and set the label width to 33%, as I’m using them in some varying CSS column layouts and this causes the labels to collapse so that the inputs are right along the right side of them. This happens everywhere bu Mac Safari and MSIE. The only other inconsistency is that MSIE seems to give a left margin to fieldsets. I set up my Submit button like so:
Copy & paste the code below to embed this comment.
Mark Wraith
Firstly, I think this article does provide a nice insight and a perfectly valid method for form layouts. I think whilst the use of Javascript to fix style hacks is far from ideal, it is a solution which should work for the vast majority of people and thus is not a big usability issue. The downside is simply the untidiness of having extra “˜hack fix’ code.
I would, personally, disagree with your assertion that it is wrong to represent form data in a tabular form. I believe that it is perfectly acceptable to represent any data however you like providing the semantics are easy to understand, mathematically solid, and do not contravene existing standards unless there is a specific reason for doing so. In the case of forms, I would say that it’s as easy to understand the semantics of a table form layout vs. a list based layout. Because there aren’t any fixed standards in place for form semantics I can’t see why using tables can be considered a poorer solution to using lists.
For most situations you can classify a form as a set of related fields with undefined size, and classify a field as a typical (key, value) pair. To give an example, taking the first three, fields of your form (Name, Address, City) using set notation you could mathematically represent a typical record of data as ((Name, “˜Homer Simpson’), (Address, “˜742 Evergreen Terrace’), (City, “˜Springfield’)). As the set contains pair based items only, you can consider a 2-column table where the first column represents the head of the pairs and the second represents the tail of the pairs. Clearly, it is a direct mapping between two representations and the related XHTML code would be pretty self explanatory.
I think there is a certain hesitation to use tables in the designer world for fear of being ridiculed for being out-of-touch. I think in this case a table solution would be perfectly understandable and increase the clarity of the page’s stylesheet.
The alternative javascript (in comment #106) for use with Prototype.js only works with one form on the page and with it’s ID being ‘cmxform’, not the class. This alternative works pretty much the same as the original script, only using prototype.js instead of jquery.
function cmxform(){
// Hide forms
$$(‘form.cmxform’).each(Element.hide);
Copy & paste the code below to embed this comment.
Eric Higgins
I checked the CSS and it doesnt validate.
“See for yourself”:http://jigsaw.w3.org/css-validator/validator?uri=http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/css/_library/cmxform.css&usermedium=all
Just something to keep in mind if you plan to do this.
I think overall it has a nice end result without using floats, but it’s sort of a toss up between floats and javascript.
i like the approach and want to try it in my next applications. especially the way that you use a list to define the form rows. interesting. need to check how you managed the gradient.. looks nice ;)
you can pass by my blog http://webdevbros.grafix.at i am sure its interesting for you.
Nice article Nick, one of the best examples I’ve seen.
I’ve been looking for a good css alternative to table based forms for a while now. I found this article along with a few other articles, all with different implementations. However, the majority of them used div, span, lists, p, br etc, which personally I don’t think is semantically correct. Javascript/css combinations like Nick’s seem to be a favourite too, which I’m not a fan of, sorry.
Most of the examples I’ve seen don’t validate to XHTML 1.0 Strict, and fall apart in different browsers. They also didn’t cater for radio buttons, check boxes etc, so I’m glad to see Nick’s article includes these.
ANYWAYS, as nothing else I have seen suited me 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
Having read the previous posts, this is a different solution that might suit some of you better. Thought I’d share it and see what you think:
<a href=”?http://www.urmood.com/urmood_css_tableless_forms/”>
118 Reader Comments
Back to the ArticleNick Rigby
Keith,
The examples should look like the screen grab. Normally you would add a size value to an input like:
<input id=“name” size=“20” />
When you do not specify a size, a default size is used, which is possibly different in some browsers. It looks exactly right in all the browsers I tested with, but it is obviously different on yours. The thing is, the inputs in your example look way out. Is this the same for all browsers on your machine?
Thanks.
Kerri Hicks
I’d be the first person to emphasize that tables should not be used for layout (except with tabular data), but I fail to see how the form presented in this example is not tabular data.
Imagine a form to collect information about your pickup basketball team. You’d have a column of row names, and then five columns with input fields. There’s the name row, followed by five name fields to fill in. Then there’s the position row, followed by five text boxes in which you put each player’s position, etc. The name/value pair relationships are clear, and each field is labeled (“Name – Player one. Name – Player two,” etc.)
How is this not a table? And then if it only has one column of information to fill in, how is this any less a table?
Using tables for simple forms such as the one in this example also has the benefits of lists that were outlined in earlier comments—a screen reader gets to the table, and it reads, “Table with two columns and five rows” (so, just from the structure of the table, you know how many items there are not just down, but across, too), then it reads the summary and/or caption that you’ll have added to your table, “Contact information form,” or something else equally descriptive.
I’m open to being convinced otherwise, but to me, this type of form is clearly tabular data with name/value pairs.
Anthony Baker
This works fine on Safari, but the form fields aren’t aligning properly using Flock’s 0.7 beta on the Mac. Same thing when using Firefox 1.5.0.2 on the Mac—the form fields don’t align evenly and are instead simply aligning left following the label for each.
The rest of the fields, however, display fine.
Nick Rigby
Anthony,
I’m not able to test in Firefox 1.5.0.2, but I just tested in an earlier version (1.0.7) and it works fine. I’ve also tested in Flock 0.7b and again it works fine. I’m using OSX 10.4.6. Do you have JavaScript disabled?
Thanks.
Brian Cray
I haven’t done much testing on the topic, but I wonder if styling the label element as display: compact has been given serious consideration?
Michiel van der Blonk
I agree with almost all comments on this article
For interested readers, I wrote an article in search of all possible float solutions for forms that have no additional markup. Let me know if you have more methods that I could include.
“floating forms article”:http://test5.caribmedia.com/CSS/Secrets/members/michiel/floating-forms.html
Christian Holtje
Wouldn’t the javascript be “better” (for some values of better, offer not valid in all states, some settling may occur it transit) if it looked for inline-block and replaced it with something better on broken browsers?
I realize that the article isn’t about inline-block, per se. But to me, it’s one of the features I wish worked in FF/IE. :-/
Ciao!
Kevin Dougherty
I appreciate the article, Nick. Nice work. Compelling discussions as well.
I would like to get your – or anyone’s – thoughts about setting the size of input fields. While it is not addressed specifically in your article, I think it has relevance given that we are attempting to make forms “prettier” and more “accessible”.
My question concerns setting the input size to be the same length in all cases (except for input types “radio” and “checkbox”). I grant that – when all the same size – the inputs do make a prettier form. Your form does this, and it indeed looks great. Yet, what about considering the input in relation to the data it expects – and adjusting the input’s size attribute accordingly?
A specific example is an input for Zip Code for a US address. I feel it presents a usability issue to the user when the width of a Zip input is as long as the input for Street or City. A US Zip is necessarily shorter and it makes sense – and is fair to the user – to indicate that visually, even at the expense of creating a “jagged right line” of inputs on the form. Thoughts?
Will Pall
This may be a bit off-topic, but what is so wrong with tables? Why is a table in a form such a “semantic faux pas?” I could draw up that form in a fraction of the time, and do it using less bytes if I use tables. All I hear now-a-days is how horrible it is to use a table. Why use a simple table when you can create a huge stylesheet file and mess with divs that never show up correctly in all browsers?
Back on topic, nice example though.
Back off topic, I can feel the heat from the flames already.
Stephen Down
That is sometimes appropriate, but in many cases you won’t know the length of the input. If you’re asking for name, or town, or email address, you have no idea how long it’s likely to be – so set a size that will be big enough for most people and others can scroll if they have to.
I know this is slightly off your point, but consider the possibility that people from other countries will be entering their address in your form – might it be better to have a textbox so they can enter the address in whatever format is most appropriate rather than be constrained by one that is designed specifically for US addresses?
In answer to your question, I think it would look fine either way, whether the postcode box is the right size for the input, or lined up with the other fields. Part of it will depend on the rest of your form, and how many fields there are of the standard length.
John Lascurettes
In the case of input fields with an expected specific length there is only one way to have the length of the field match the length of the data across browser-platform combinations:
I have experimented with this and it was the only way, for example with a five-digit zip, to guarantee that the data input exactly matches the length of the input element. This was tested with Opera, IE (from 5 to 7 on Mac and Windows), Firefox, Safari and Netscape 6.
John Lascurettes
Excuse the atrocious spelling errors in my previous post. I haven’t had my coffee yet.
Keith Bell
Nick
[Ref comments 48, 50, 51, 52]
As I was reading your last comment (#52) it dawned on me where the problem lies, and likely explains the similar reports you have had regarding Flock and FF on Linux.
In your example, you are not explicitly setting the width of text input and textarea elements in the CSS, but instead leaving it to the “default” size, or, in the case of the textarea, using the cols attribute in the textarea tag to set cols=“25”. If not explicitly set by CSS, the width of such elements will be affected in Firefox and other browsers by the user’s settings for default font and font size. It appears that my (and other people’s) default settings are larger than yours, hence the observed differences.
We have no way of knowing a user’s browser settings, so it is risky either to leave the field widths unspecified, or to use the size/cols attributes in the HTML tags. To be safe (well, as safe as we ever can be, in this game) we need to set widths in the CSS to make sure labels and inputs don’t bump into each other, or knock each other out of the way.
Of course, every individual form will demand its own styling, including input and textarea field widths—but maybe that needs to be made clear.
I hope this is helpful.
Paul Armstrong
Thanks to Christian Tietze in comment #3 for linking to my Awesome Form. I just wanted to note that I’ve updated “Awesome Form”:http://paularmstrongdesigns.com/examples/css/awesome-form.html
Awesome Form is complete cross-browser compatible CSS for displaying forms using only its most bare elements. No lists, no tables, no guff. I hope others find it useful!
Lee Daubney
I appreciate that the article you wrote does allow developers to create accessible forms, however the need for Javascript seems to be crazy in my opinion. Although the Javascript is unobtrusive, it still creates more work for the developer. It is possible to create the same form using <dl><dt>&<dd> tags for Markup and only CSS to style it. It’s still very accessible, has more semantic meaning and no need for Javascript. What would happen if the user had Javascript turned off? Answer: It would no longer be a “Prettier Accessible Form”. I really don’t want to sound like I’m moaning, as it is a step in the right direction, but I urge you all to check out Dan Cederholm’s technique for forms.
Patrick Gates
Firstly let me say that I enjoyed seeing a form layout that took a stab at semantics and didn’t use floats, which have been plagued me quite a few times in designing over the years. There’s certainly no God-sent CSS template that addresses the form (and there may never be), but please keep exploring these new ideas as they’re always welcomed and enriching.
In trying variations on this CSS, I discovered that if you set text-align: right; on the <li> and use padding-right to shift the inputs/labels to your liking, then you can obviate the need for js/proprietary tags. This also minimizes the need for CSS hacks. Granted, you have to be willing to deal with right-aligned label text, but the result is very clean/crisp. Here’s a very short “example”:http://www.geocities.com/pgates18/Content3.htm for your perusal.
Of course, as often occurs in the Web Design world, solving one problem reveals at least one new problem. Inputs and TextAreas can generally be made to render equally across many browsers. The select element misbehaves in this regard, however (I’ve only tested in IE6, FF1.5, Op8.54/9). Opera is the only one of the three browsers I’ve tested (assuming the widths are equal in the CSS) that naturally renders the select the same width as the other form elements. IE and FF both render 2px shorter in the case of my experiment.
Maybe I didn’t solve anything—just trying to follow the tradition of sharing ideas!
Dustin Boston
I just posted another alternative solution “on my website”:http://bajooter.com/node/22 that may be viable. It uses the method mentioned on “Quirksmode”:http://www.quirksmode.org/css/forms.html plus there isn’t any javascript and only I only used one hack.
matt plummer
Thanks for the great article!
Matthew Orlando
@ Kevin
I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.
I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:
*************
*************
**********
**
*****
It’s pretty obvious that the last two fields are State & Zip
Matthew Orlando
@ Kevin
I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.
I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:
*************
*************
**********
**
*****
It’s pretty obvious that the last two fields are State & Zip
Matthew Orlando
It’s my first time posting here.
Looks like my fields turned into HRs also. Here’s what I meant (i hope):
OOOOOOOOOOOO
OOOOOOOOOOOO
OOOOOOOOOO
OO
OOOOO
Stephen Yeago
For me the tabular data issue is moot because I prefer against using tables because of the hell involved with javascript inserting and manipulating them (which, I suppose, evokes a whole new set of complaints, but on my current particular project I’m working on an internal website which requires JavaScript anyway for remote scripting purposes).
Stephen Yeago
Shoot. Should have mentioned that I’m really digging the use of lists.
Think beyond address forms, people—ordered or unordered lists are perfect for things like questionaire’s or any extensive forms. This little approaches being what prototype.js is for js, for css. Obviously, compliancy is an issue but in the current world of CSS compliance, it almost always is anyway.
Adam Craven
I echo many people’s feelings here, as soon as I saw the JS to ‘fix the layout’, it was never going to be a popular solution. The idea isn’t to bloat the code and slow down browsing running functions.
Stick with the floats or use tables for the forms. I’ve noticed no problems with the form on my site using floats, which has been checked on many browsers Four Shapes contact form. However, that form isn’t too complicated.
Your form is nicely designed, but I don’t think it will be used too often.
Pid Ster
Someone once demonstrated to me what a screenreader actually does when presented with a list element. It spoke at length about the list item at each element, before describing the contents.
No further demonstration/explanation was necessary, and since then I’ve refrained from using lists inappropriately for nav menus (when div/span sets will do*) and never inside forms.
*div/span groups will straight swap in CSS (with less default style removal) and can also work better on unstyled (mobile?) pages.
Manzell Blakeley
I like the use of -moz-inline-block; I dislike all the javascript. That’s alot of work to fix what in all liklihood is a non-issue.
Ross Clutterbuck
I do apologise in advance because I’m normally very open-minded and listen to many different sides of a discussion, but in rare occassions like this one I get really annoyed.
In a nutshell: will all you standards-Nazis get over yourselves!
Where ANYWHERE in this articles does it say “this process is 100% reliant on JS and CSS and it’ll all break and look rubbish without it – to hell with standards!!”.
I’d strongly suggest you go back and read it again – this process works perfectly well without JS. The only reason JS is in there is to fix the continuing rift between CSS implementations in browsers – and here I was thinking 1997 was almost 10 years ago.
So instead of ranting and raving about how using JS to style is the work of Satan (and the process doesn’t style through JS the code simply fixes browser errors) why not focus that energy into bullying the browser manufacturers to get their act together and implement the established, 1,000 year old specs completely and accurately.
Only THEN when we have 100% of browsers 100% compliant can you all go off and complain about hacks, fixes and workarounds if a process or piece of code deviates from standards.
But of course this is never going to happen because new technologies are invented and maturing all the time.
Sheesh if you don’t like it, don’t use it!
Personally I’m going to rectify the erratic behaviour of long labels but making sure I don’t actually have any, but I’m not going to jump down the author’s throat just because he’s said “I’m going to fix omissions in a browser through script”.
</rant>
Bernd Klenk
I was fascinated by the article and tried to implement all into a current project and it all worked well… except in the new Opera 9.
The word “null” is inserted before all label contents.
I am not a DOM-specialist, so there isn’t much that I can say or do about it…
What does: this[removed] = null; in the script really do?
?
Bernd Klenk
The same behaviour with the example form of the article.
“null” before each label element.
James Byers
Forgive me if this has been discussed earlier in the threads…
I’ve seen a host of single column form solutions but they all service very small forms. What if you have a large amount of fields that need to be collected? Are there any two column css form solutions?
Sholom Sandalow
By the way…now that form behavior is being completely rewrittren by Ajax and other dynamic technologies, don’t we need a new set of rules for styling them? For instance, we’ll need the styles for error and confirm messages that appear within the form.
Here’s an example Ajax powered newsletter signup form.
Nick Rigby
Hi Bernd,
I described a fix for Opera 9 earlier in the comments. Here’s the link directly to it:
“Opera 9 Fix”:http://www.alistapart.com/comments/prettyaccessibleforms?page=3#26
Thanks,
Nick.
sam greene
I normally leave my forms pretty plain – I’m hooked on pretty forms now! Thanks.
sam
Michael Newton
Never assume your audience has a white background on thier browser. I’ve got old-school grey, and it looks terrible!
As an aside, anyone else having trouble typing in this box, or is my keyboard suddenly broken?
David Osbourn
Can someone explain how the stretched gradient is acheived please? I’ve tried copying the background: url(….) CSS but I just get the 1×2 pixel image repeated across the bottom of my fieldsets. I can’t figure out how to stretch the image to 100% of the height of the fieldset.
Christian Tietze
Well, “David”:http://www.alistapart.com/comments/prettyaccessibleforms?page=9#86, why don’t you look at the CSS source, copy the image URL and view the image?
> !http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/images/cmxform-fieldset.gif!
It’s a high gradient image. No CSS magic, just images.
David Osbourn
Oops – my mistake. I missed the inclusion of the larger image completely.
Tomasz Zoltowski
Maybe this was not the point of the article, but if word “Accessible” is used in the title, I can’t understand why clicking the labels of the radio buttons doesn’t (isn’t designed to) work!? For me, connecting labels with input fields using FOR and ID attributes is a must. Unfortunately not all the web designers use this rule – see checkbox under the “Search ALA” input ;) Laziness? Unawarness?
Victor Palma
I really like the way it displays in Firefox but I have to say that using JavaScript for the form makes it not quite accessible in my books. I like the architecture of the form as far as the code but using JavaScript just made me go “ugh!”?. Why are tables so bad when using forms? I think forms is a good use to put a good old table”¦
Jordan Gray
I’m intrigued by the fuss Nick has caused by using an ordered list, because I’ve seen them being used to structure forms for years. Almost all the paper forms I need to fill in for my government, my university or my workplace—in fact, even surveys—have been represented as an ordered list of fields. This structure is especially useful because it is allows one to instruct the reader to “skip” a range of fields if they are not required.
Given that it is an established standard, how precisely is this not legitimate? The only convincing argument I can see for not using them is presented by Pid Ster, who explains that the form becomes less accessible for screen readers; and then, the impractical purist in me cries that this is surely a fault of the software, not the structure. (Incidentally, can any more experienced readers tell me if this is the case for all speech readers?)
Definition lists I find particularly challenging, mainly because I’m not totally sure about their semantic intent. What is a definition list meant to imply? Is it really legitimate to use them merely for association? Aren’t labels and fieldsets sufficient—for forms, at least? In fact, isn’t that their explicit purpose? Tables, in my opinion, are preferable for data presentation, not data entry. I know that they often mean less markup, less complex CSS and less cross-browser hassle, but (in my opinion) they are also less semantically appropriate.
Not that I consider definition lists or even tables to be a complete semantic faux pas, but they don’t immediately strike me as the best structures.
As for using ECMAscript to amend browser CSS support: the form degrades gracefully and is reasonably attractive without the fix, which itself is relatively unobtrusive. Admittedly, a perfectly workable solution could be created using floats, but the author’s stated aim was to develop a solution which could be “dropped” into place, and float-based layouts are often very brittle (an issue I’ve experienced first-hand).
I mainly use paragraphs to markup forms, and in future I may well use a few lists. Excellent work, Nick!
Harvey Kane
Thanks Nick, I appreciate there is no magic solution to this problem. Personally, using the javascript or ol element doesn’t grieve me as much as others here, and I still think this is better than tables.
I’m only mentioning this because nobody else has brought it up – but using the external library is a bit of a worry – it’s 10kb of extra data that needs to be downloaded. I’m sure the library does all kinds of good stuff, but only if you use it.
I’m struggling to keep my pages looking good, functional, and less than 100kb before compression, so an extra 10kb for the form is a bit expensive.
Is there a way you can extract what you need into a standalone piece of script? I’‘m sure you could achieve what you need with a page or so of script, rather than requiring the library with all it’s other features.
Eric Brown
How can anyone argue against that a form is a list of questions and answers? US residents: have you never filled out a tax form, or a DMV form, or any other kind of form? Even your W2’s are numbered!
I number fields for everything. It makes support calls so much easier, too. “I don’t understand question 6.” I’m glad to see other developers starting to do the same. DL/DT/DD lists are good, too. As a website that supports a large number of impaired users, we get many compliments over our use of numbered lists.
The earlier solution linked ( “Paul Armstrong”:http://paularmstrongdesigns.com/examples/css/awesome-form.html ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.
I have a feeling most people that are against the JS didn’t even look at the example with JS disabled in Mozilla—it may look a little “off” but it is still usable.
Nicole Sullivan
I am excited to see your use of ol to mark up form items. I think this markup is just right. I actually disagree strongly with the use of tables and definition lists to mark up form controls.
The semantic realationship between the text and its input exists already, it is created by the label tag and the input tag (with appropriate attributes, of course). I think your use of OL is perfect for establishing the semantic relationship between the different input/label couples which compose the form.
I had previously used a more minimal markup :
<label><input>text text text</label>
The problems with my method were : 1. inverted order of text and input, and 2. with CSS turned off the form was still technically useable but turned into a soup of form controls and text.
Javascript for layout makes me very hesitant… I don’t like the idea that it might be used to shortcut actual thoughtful CSS development. On the other hand I’ve inherited divML projects, where more than 40 divs were used to create three boxes of equal height in a row.
When one has tried to do CMS development on a bloated project like that it starts to be easier to see the value of using Javascript to add extras that aren’t necessary for the page to function especially when it means we can keep the markup clean.
Nicole
Marc Garrett
Excellent article Nick, thanks for taking the time to write up your method.
My only concern about relying on JS workarounds for style is unforeseen collisions with Prototype or Script.aculo.us (or any other Ajax library). Have you tested this method with Rails form helpers, or other server-side solutions that dynamically generate forms and form interactions?
Not busting your chops, just asking. This article helped me see forms in a new light.
Sam Thomas
I’m having a different problem using this on my own page with firefox, but it doesn’t affect the examples. I did try not including any of my normal styles (using just the example instead). Basically firefox ignores the width’s for the labels and the form itself. Anyone know why?
mark haller
Hi all,
I’m trying to apply Nick’s great example into a current website … and got a really good looking/working EDITABLE form cross-browser …
What happens when you’re not editing and want to VIEW THE FORM later?
Currently using label and input css markup is cool … but nothing’s available for the text later when viewing only.
What do people propose to that? The DL/DT solution would solve that … but I wouldn’t mind getting Nick’s solution working!
mark haller
the snag is … you can’t do them with the current css :-(
I realise now why Nick’s demo shows all radio and checkboxes on single lines in their own fieldsets – I’ve just tried doing multi-column radio/checkboxes and sure enough, the
breaks the line and wraps to the start of the next line, under the label left-aligned :-(
Any ideas anyone?
Kyle Lamson
I am very much anti-JavaScript, but face it, it’s use here is unimportant towards accessibility, nohng breaks if it is turned off.
I did live in Germany till recently, my wife is German and all my three girls are Half German. I do not appreciate Ross Clutterbuck’s comment (78) about “Standards-Nazis”. It is very inapropriate when “Zealots” or “Crusaders” would have worked nicely. It is time to get over yourself, the war ended 50 years ago and not even my wifes parents and kids grandparents were involved in it.
My one important input here is less JavaScript as the use of innerHTML as mentioned in comment 26. Best of my knowledge innerHTML is not supported by XHTML when correctly served as XML, only if served as Tag Soup. Hence this would not work in my personal sites. So any XHTML conscious designers should keep that in mind when using application/Xhtml+xml MimeType.
Kyle Lamson
@ Eric Brown and further readers:
“The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”
Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com
Kyle Lamson
@ Eric Brown and further readers:
“The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”
Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com
Stephen Stewart
Hello. Opera 9.01 is inserting ‘Null’ in front of the label values for me, with the intended label then dropping down a line. Anyone got a fix for that?
Stephen Stewart
I was sure I didn’t already read an answer to my question on Opera 9.01 and Null, but it’s there on page 3.
andy standfield
I know I’m awfully late to the party, but I was wondering about the statement in the article that, “forms don’t constitute tabular data.”
I’ve heard other people say this, and I really don’t get why. Especially given the concept of label/data pairs. In fact, I would suspect that when most forms are submitted to a database the data is submitted in a near identical format (e.g. The first column being an identifying label, and the next column being the data (although, I still think it would be semantic, even if the order was reversed… just kind of whacky in L to R reading languages)).
I’m wondering if I’m missing something.
Rizky Syajuli
I dont have anything to add to the discussion. I just wanna say that the idea of using lists for structuring is very…ummm…unique.
I won’t argue about semantics or anything. coz as long as it works, it’s totally fine by me :D
arn ie
Here is a poor attempt at re-implementing this using Prototype.js since JQuery clashes. This requires that the form has an id=“cmxform”, I’m sure people out there that actually know what they’re doing could improve upon this.
if( document.addEventListener ) document.addEventListener( ‘DOMContentLoaded’, cmxform, false );
function cmxform(){ // Hide forms $( ‘cmxform’ ).hide();
// Processing var someNodeList = $(‘cmxform’).getElementsByTagName(‘label’); var nodes = $A(someNodeList); nodes.each( function( i ){ var labelContent = i[removed]; var labelWidth = document.defaultView.getComputedStyle( i, ‘’ ).getPropertyValue( ‘width’ ); var labelSpan = document.createElement( ‘span’ ); labelSpan.style.display = ‘block’; labelSpan.style.width = labelWidth; labelSpan[removed] = labelContent; i.style.display = ‘-moz-inline-box’; i[removed] = null; i.appendChild( labelSpan ); } ); //.end(); // Show forms $( ‘cmxform’ ).show(); }Stephen Yeago
Someone above was asking about a tableless two column css layout.
Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above.
I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.
This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.
Stephen Yeago
Someone above was asking about a
“tableless two column css layout”:http://www.yeago.net/work/2006/09/two-column-css-layout.html
Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above.
I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.
This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.
ps: severe apologies for the double-post. forgot to Textile.
Chris Forrette
Let me first say that this article has become a great resource for me and has changed the way I think about and create forms. But I’ve found a problem that I’m surprised that no one has mentioned here. I’m developing on a Mac, and everything looks perfect on Safari! But in the rest of the browsers I’ve seen, there are inconsitencies. I’ve done a little modification to the CSS for my own purposes, naturally, and set the label width to 33%, as I’m using them in some varying CSS column layouts and this causes the labels to collapse so that the inputs are right along the right side of them. This happens everywhere bu Mac Safari and MSIE. The only other inconsistency is that MSIE seems to give a left margin to fieldsets. I set up my Submit button like so:
<li>
<fieldset>
<label><input type=‘submit’ value=‘Submit’ /></label>
</fieldset>
</li>
So that it would line up with my checkboxes and other inputs, but it shift a good inch to the right. Any ideas on how to fix this situation?
Dirk-Jan de Groot
As a comment to the 2 column tableless design remark;
you can now validate your tableless design at: http://w3tableless.com
check if you’ve done it the right way.
Jérémy Lecour
Hi,
Both on IE 6 and Firefox on Win2k, when a legend has more than 1 line, it’s not broke but continues on a single line.
It’s at the exact position of “Is this address also your invoice address ?” but longer.
Even if I force the width property of the legend, it’s not working, evenwith ” !important”.
If you have any idea “¦
Cheers.
Mark Wraith
Firstly, I think this article does provide a nice insight and a perfectly valid method for form layouts. I think whilst the use of Javascript to fix style hacks is far from ideal, it is a solution which should work for the vast majority of people and thus is not a big usability issue. The downside is simply the untidiness of having extra “˜hack fix’ code.
I would, personally, disagree with your assertion that it is wrong to represent form data in a tabular form. I believe that it is perfectly acceptable to represent any data however you like providing the semantics are easy to understand, mathematically solid, and do not contravene existing standards unless there is a specific reason for doing so. In the case of forms, I would say that it’s as easy to understand the semantics of a table form layout vs. a list based layout. Because there aren’t any fixed standards in place for form semantics I can’t see why using tables can be considered a poorer solution to using lists.
For most situations you can classify a form as a set of related fields with undefined size, and classify a field as a typical (key, value) pair. To give an example, taking the first three, fields of your form (Name, Address, City) using set notation you could mathematically represent a typical record of data as ((Name, “˜Homer Simpson’), (Address, “˜742 Evergreen Terrace’), (City, “˜Springfield’)). As the set contains pair based items only, you can consider a 2-column table where the first column represents the head of the pairs and the second represents the tail of the pairs. Clearly, it is a direct mapping between two representations and the related XHTML code would be pretty self explanatory.
I think there is a certain hesitation to use tables in the designer world for fear of being ridiculed for being out-of-touch. I think in this case a table solution would be perfectly understandable and increase the clarity of the page’s stylesheet.
Mark Mitchenall
The alternative javascript (in comment #106) for use with Prototype.js only works with one form on the page and with it’s ID being ‘cmxform’, not the class. This alternative works pretty much the same as the original script, only using prototype.js instead of jquery.
function cmxform(){
// Hide forms$$(‘form.cmxform’).each(Element.hide);
// Processing
$$(‘form.cmxform li label’).each( function( label ){
if (label.classNames() != ‘nocmx’) {
var labelContent = label[removed];
var labelWidth = document.defaultView.getComputedStyle( label, ‘’ ).getPropertyValue( ‘width’ );
var labelSpan = document.createElement( ‘span’ );
labelSpan.style.display = ‘block’;
labelSpan.style.width = labelWidth;
labelSpan[removed] = labelContent;
label.style.display = ‘-moz-inline-box’;
label[removed] = ‘’ ;
label.appendChild( labelSpan );
}
} ) ;
// Show forms
$$(‘form.cmxform’).each(Element.show);
}
if( document.addEventListener ) document.addEventListener( ‘DOMContentLoaded’, cmxform, false );
John N
Why are submit buttons never included in fieldsets?
Since submit buttons can have meaning themselves, it would seem appropriate to me. I’ve never understood this.
Andre Brück
Hi,
bin gerade duch zufall auf den Artikel gestosen, finde den Artikel echt toll, hat mir sehr weiter geholfen.
Danke
:-)
Eric Higgins
I checked the CSS and it doesnt validate.
“See for yourself”:http://jigsaw.w3.org/css-validator/validator?uri=http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/css/_library/cmxform.css&usermedium=all
Just something to keep in mind if you plan to do this.
I think overall it has a nice end result without using floats, but it’s sort of a toss up between floats and javascript.
michal gabrukiewicz
i like the approach and want to try it in my next applications. especially the way that you use a list to define the form rows. interesting. need to check how you managed the gradient.. looks nice ;)
you can pass by my blog http://webdevbros.grafix.at i am sure its interesting for you.
Stephen Sinclair
<a href=”?http://www.urmood.com/urmood_css_tableless_forms/”>
Nice article Nick, one of the best examples I’ve seen. I’ve been looking for a good css alternative to table based forms for a while now. I found this article along with a few other articles, all with different implementations. However, the majority of them used div, span, lists, p, br etc, which personally I don’t think is semantically correct. Javascript/css combinations like Nick’s seem to be a favourite too, which I’m not a fan of, sorry. Most of the examples I’ve seen don’t validate to XHTML 1.0 Strict, and fall apart in different browsers. They also didn’t cater for radio buttons, check boxes etc, so I’m glad to see Nick’s article includes these. ANYWAYS, as nothing else I have seen suited me 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 Having read the previous posts, this is a different solution that might suit some of you better. Thought I’d share it and see what you think: <a href=”?http://www.urmood.com/urmood_css_tableless_forms/”>Roger Tinch
I used your above tutorial, but my the list is messing with my page background (only on PCs though). Here’s the link:
http://www.cinevegas.com/survey/non.html
Please I need help!