91 Markup, style, ECMAscript and purity

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!

posted at 10:31 pm on July 8, 2006 by Jordan Gray

92 Lighter option?

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.

posted at 01:34 pm on July 12, 2006 by Harvey Kane

93 List of fields

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 ) 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.

posted at 07:58 pm on July 12, 2006 by Eric Brown

94 semantics are right

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

posted at 02:33 pm on July 15, 2006 by Nicole Sullivan

95 Does it risk colliding with Prototype or Script.ac

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.

posted at 06:02 pm on July 19, 2006 by Marc Garrett

96 Firefox 1.5.0.4

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?

posted at 07:49 pm on July 21, 2006 by Sam Thomas

97 OK for entry ... but what about viewing later?

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!

posted at 07:46 pm on July 30, 2006 by mark haller

98 a snag with multi-column radio/check boxes

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?

posted at 02:21 am on August 1, 2006 by mark haller

99 InnerHTML

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.

posted at 10:46 pm on August 5, 2006 by Kyle Lamson

100 Untitled

@ 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 at Accessify.com

posted at 11:59 pm on August 5, 2006 by Kyle Lamson