← Back to 4. UI Navigation Design
Continue to 2 - 4. Polishing the Layout →
← ← Jump back to Design Demo: Medieval Scroll Index

Main Points

Mostly we just have the form left. *sigh* I expect this is going to be the worst part of the initial layout. I've learned a lot since first building this website, especially about CSS. However, forms design is a nightmare. I know professional designers, but I don't know anyone who doesn't cringe at the mere mention of CSS forms. They are by far the most "individualized" elements from browser to browser, completely sabotaging many valiant attempts at cross-browser compatibility. Users also have the most rigid expectations of form elements from table based layouts which handle forms beautifully. CSS is not really ready to cope with forms that demand this kind of rigid, highly organized display. So I'm going to approach this wisely... by starting with something completely different...

We've already wrapped up most of the navigation, so part wasn't too difficult. I really like the current look of the page links and their excellent universal design principles that ensure usability and accessibility. While this is a little hard to read, I know that once I play with the typography I can apply something similar to the current look. That will help a lot, and while page links are a secondary issue, I like having them large enough to read. So far, here's what I've got to produce the current layout which we'll refine as we go.

/* Navigation: Accessible Links */

#pageLinks {
text-align: center;
}

#pageLinks ul {
list-style-type: none;
margin: 0;
}

#pageLinks li {
display: inline;
padding: 0.05em 0.2em;
}

First I center everything in the containing div, pageLinks. Then I remove the bullet points which just get in the way and remove the default margin I've applied to my lists. You'll notice that most every list in the layout that I've produced so far, I've undone my default styling. The XHTML tag redefinition style rules I've created are done with standard content in mind. While I'm creating a lot of special structures for the page layout, I have to keep this in mind and redo them as appropriate. This does make for a little extra work, but during the design phase when I'm in the thick of it, it's no big deal. Once the design phase is finished, however, it would be a royal pain to remember every detail of the stylesheet in perpetuity when you only interact with it occasionally. Therefore the stylesheet is written so that initial design is a bit of a pain, but writing and maintaining page content - the lion share of the XHTML effort - will be streamlined. This is a key principle of object oriented CSS, establishing structures that can simply be used now or later without additional CSS work. CSS is a pain, while XHTML is straightforward. Anything we can do during design to cover the CSS so that maintenance is shifted from the stylesheets to the XHTML of the webpages is a major maintenance bonus.

Finally, I set the list items to display: inline; so that each of the links falls on the same line. I'm having a small problem with gaps between the lines in Firefox; I suspect that unlike IE and Opera it's "saving" a spot for the top level list items even though there's no actual text in them. Nor are those list items responding to the same CSS commands that make the nested lists work.

Skip to Main Points

Accessible Form Development

OK, it wasn't That bad. Just a lot of hard work. Experience is definitely paying off, just knowing what to look for and where to watch out helped me speed up development of the form significantly. That resulted not only in more speed, but everything was fresh in my mind and I think this is a lot cleaner looking form that anything I've had before. It also changes much more gracefully to accomodate different platforms, resolutions, and browsers. I expected to be taking advantage of the fact that there are only a few elements here, but this is not only clean, but pretty reusable for a much larger form if I need to build one. A nice bonus. CSS form design is not particularly pleasant, but the usability and accessibility just is not there in a table based layout.

/* ////////////////////////////////// */
/*
/* Form Structure
/*
/* ////////////////////////////////// */



#contactForm img, #contactForm h2, #contactForm h4, #contactForm fieldset {
float: left;
}

#contactForm h2, #contactForm h4 {
margin-top: 1em;
width: 60%;
}

#contactForm fieldset {
width: 90%;
}

My section heading begins the CSS for the form. I experimented with a number of different positioning options prior to this, none of which were particularly successful. I got furthest applying a 200px left margin to the entire div, contactForm; then I used a -200px left margin to draw the image back. In IE6 this shoved the image completely off the page, and I'd decided to handle this in the IE6 stylesheet, at least until other complications blew this up. I decided to try this float method, and floating everything left actually displayed pretty appropriate behavior for the fluid layout so that's the guts of what I'm using here. I applied a width: 60%; to prevent the headings from being able to sit side by side.

Unlike my very first attempt to style this contact form two years ago, I decided that the fieldset itself would never sit alongside the image. Once I started getting used to the float: left; behavior, I realized that this was very close to what I wanted and as close as I would ever get; but even that just didn't look good enough. I therefore defined the fieldset to have a 90% width which permanently pushed it underneath the image. It still scales well enough in narrow browsers to minimize fieldset borders running off screen. I then had a problem with the headings not aligning well vertically next to the image. After trying several different more advanced techniques, the one that looked best was simply applying a 1em top margin on both headings. That was a happy but unexpected result. Keeping this group of "top level" elements well behaved was one challenge in designing the form. The other was positioning the elements inside the fieldset.

#contactForm input, #contactForm textarea {
margin: 0.1em 0 0.1em 6em;
width: 70%;
padding: 0.2em;
}

#contactForm textarea {
height: 9em;
}

#contactForm label {
position: absolute;
width: 4em;
}

I tried floating these items too, but I really wanted to try to get the form elements to line up crisply like a table based layout. Floated layouts just weren't cutting it. I wanted the form elements lined up one above the other, with labels aligned to the left of their elements. What worked best was applying a 6em left margin to push the form elements over and defining a 4em width on the labels. Once I applied a position: absolute; declaration to the labels, the form elements fell nicely into a stack. Their positioning and lengths are not perfect cross-browser, but well enough at this point that I can move on with the design. I can work out the details chatting with other developers and hitting the forums for ideas. The lengths of the form elements was also titchy. Like most of the other elements in the form (e.g. fieldset and headings) I found that defining their widths as a percentage worked best, except the 6em left margin on the form elements and the 4em widths on the labels.

Finally, I adjusted the interiors of the form elements. To provide more viewable area, I placed a height: 9em; declaration on the text area. For many people this may not be important, but it will support people entering more detailed comments if they desire. I also applied my trademark 0.2em padding so that the text cursor is visible when any form element receives focus. I hate it when you can't tell if the form element has a cursor or not because the cursor is slammed against (or under) the border, so that's a declaration I always include for form UI. I found these selectors to be very interesting and they were chosen after a great deal of experimentation. Grabbing the form id and specifying the tag name forced the form elements into the behavior I wanted. Grabbing the element ids was not particularly successful nor was targeting their classes. This makes it difficult to specify a different width for the submit button and the textbox since they are both <input> elements. So while this is reliable, I can't shorten the button by any means. On the one hand, I think the long button is growing on me, but if there's anything I want to change down the road, that's probably it.

#contactForm ol {
list-style-type: none;
}

#contactForm span {
display: block;
}

Finally, the first and last style rules I wrote. The first style rule I wrote for the form was to remove the numbering of the ordered list. After everything else in the form was completed, the .NET label (which is written to XHTML as a <span> element) would wrap oddly depending on the width the browser and even lose the initial "A" in "Ask" under the submit button. Applying the display: block; declaration forced the entire span onto a separate line so it was always clear and readable.

Skip to Main Points
← Back to 4. UI Navigation Design
Continue to 2 - 4. Polishing the Layout →
← ← Jump back to Design Demo: Medieval Scroll Index