Forms in 4 Dimensions

This article is for all those developers still stuck in the 20^th century with 2-dimensional, table-based layouts. A web page is 4-dimensional. Creating flat print media-like pages does a disservice to the users; under-utilizes modern browsers; and swindles whomever is paying for the development.

The motivation for this mini-tutorial comes from my experiences as an expert on a number of sites where I have encountered some backward Luddites who think CSS is too hard to learn; the work of the devil; just layout with DIV and SPAN; or some other ridiculous mis-conception. For some example pages linked off of this article there are a series of buttons and textareas at the bottom of the page for viewing and saving the code for the CSS, HTML, and scripting.

So let's get the table nonsense out of the way. Tables are for the presentation of tabular data. PERIOD! Using tables for layout is like trying to build a skyscraper with wooden beams and two by fours... it's going to come apart.

I cannot count the number of times I have heard: "The best way to layout forms is with tables"; okay do this simple form layout with a table: Simple Form As sidelight you might wonder why IE gets the background of the fieldset wrong

So, what's with the code in that page?

• There is a strict DOCTYPE. That helps IE to behave a little better by forcing it into standards compliant mode.
• Instead of using divs as newcomers to CSS might expect we are using fieldset tags. They are much better for managing form layout because they were designed specifically to do that.
• You may note that the styling looks better on Mozilla based browsers. When it comes to CSS, Mozilla has no peer for standards support. IE is weak and buggy, but each new release and patch improves the quality a little. The bottom line is that Mozilla is committed to CSS support and Microsoft only does what it has to do to stay in the game.
• The biggest thing you should notice when you look at the source is how little of it there is. A lot less code than if you try that page with a table.

Okay, its a simple layout. The same thing can be done a number of ways (if you want to write the code). Fair enough, let's go to something a little more challenging and use multiple fieldsets with a cascaded presentation. Try this with a table layout: Something a little more complex

There is not much additional code. Of course the two new fieldsets had to be added, but other than that it is pretty light weight. A couple of more entries in the stylesheet. The legend tags now have an onclick event to fire the transitions. A small amount of scripting for the transitions. All in all not much code for what we have. How much code to do it with a table? Do you even want to try it with a table? Hmmm... a pretty useful and practical layout; but tough without CSS.

The third dimension of the page is now obvious, and the first hint of dimension 4. There is now a dynamic to the form; the page is not the same all the time. The user can change the page at will.

The legend tags now have a distinctive cursor... a few key strokes in the stylesheet. The click event brings the selected set of inputs right out to the user with one click, and all it took was a simple swap of className. I hope you noticed the cute little trick of using unique classNames that match ids to make resetting default values a no-brainer.

Now look at how simple the code is. A single argument is passed from the event. The action is on the container and using this.parentNode passes all the properties of the container into the function. The legend does not need to know who the parent is, or anything about it. The DOM node collection and CSS are made for each other.

The CSS sets the default rendering for the fieldsets, legends and inputs within the fieldsets, and manages the positioning with a handful of coded lines. The required scripting is dead simple, but does a lot. First the script tests to see if the clicked element is already on top. When it is it returns it to its default position with a classname swap using its own id; otherwise... the script grabs all the fieldset nodes using the DOM method getElementById() and a quick loop resets all fieldsets to defaults. Then the target gets put on top with a classname swap.

Simple. Clean. Very little coding.

This is a design for the user; not the developers ego. The user has some control of the layout. Now let's give the user a lot more control. Let's really go 4 dimensional by adding multiple transitions that respond to the user. Let's give the user a choice of what layout they want.

If you are still stuck with tables or table-like div based grid layouts; you might as well leave. You have no chance with the rest of this unless you are ready to do a lot of coding to make your tables do this: User's Choice

One click by the user changes presentation. These are just positional changes. Any attribute can be modified this way. Every user can have their own unique setup. They can get the content the way THEY want it. Setups can be saved to cookies or in user profiles on the server, so the user has their own version of a site customized for them, by them..... Did you notice the text gets covered over and treated as unimportant? Explanation

Let's look at how little code we had to add to get that dynamic customizable effect:

• The event handler for the cascade is now in its own function
• A couple of very simple new functions get added
• Of course we had to add the code to put in the control buttons
• HTML changes: An IE quirk forces us to stick in a dummy span between the fieldsets so that we can stick in the line break that IE need to go to the stacked layout. This means the page does not validate; but you pay that price sometimes if you have to support IE. We also moved the filler text to an easier to manage location after the fieldsets.

Wait a minute; we have a page with three dynamically selectable layouts and we don't have to do major surgery on either the HTML or the CSS... Hmmm maybe this CSS stuff might have some merit. Could get to the pub or golf course a little earlier :^) What can be offered to the user as options is virtually unlimited.

BUT... the developer loses control, don't they?

Of course they do. Whose browser is it?

Web sites must have traffic to survive. Users do not come to a site to be impressed by 400k of graphics. They don't come to marvel at the impeccable layout, that the developer spent weeks getting every pixel in place. They don't care about code quality, layout, or technical issues. If they return it will not be for any of those things.

Visitors come for content. Visitors return when they find what they want; it is easy to access and use; and it does not mess up the browser. If the page is slow loading; they do not find what they want right away; or what they find is not the quality they want... then they are gone, and not likely to ever be back. It does not matter how much time you put in on layout; if you do not give the user what they want...bye bye.

Make the site hard to use; lose traffic. Make it rigid and force your ego onto the page; lose traffic. Cross-browser issues? Accessibility issues? Cross-resolution issues? Overuse of graphics? They all lose traffic.

The browser belongs to the user. They know what they are comfortable with. They know what looks GOOD to them. It does not matter what you think is great looking or ugly. The users will decide your success; not the handful of fellow developers who compliment the color scheme. Your site may look great but a pound of graphics, borders and special effects for every ounce of content, does not a thing for the users.

The practical reality is that web sites sell product, promote ideas or positions, provide recreation, or present content. They generate revenue with some form of content presentation.

I can hear the noise out there right now. "Letting users change the layout, and letting stuff just float around ruins my layout, covers stuff up, and moves things to the wrong place. My great layout gets messed up if I don't lock everything down." SO WHAT! The user decides what they want to look at. They put it where it is easiest for them to work with it. They change font sizes to what is easy for them. They change colors to what is pleasing to them. They are not looking at anything but the content they are working with. Everything else is just clutter.

There are thousands of sites designed so that the message they send is: "We are a magazine page and the site only has a small amount of content". At the top is a banner using 30% of the canvas, another 10-15% goes for a nav bar. Then on the left side is a menu with 5 or 6 entries that uses 25% of width all the way to the bottom, and over on the right another 25% width column that may or may not contain anything useful. The net result is that above the fold there is only 30% or less of the canvas available for the content, and even below the fold there is only 50% available.

Question that typical 3-column layout (most 2-column are almost as bad) and what you hear is total utter nonsense about all this bloat and clutter being necessary so the site is easy to navigate. For the home page; maybe. For content pages; visitors are NOT THERE TO NAVIGATE. Why does the page layout say "the primary purpose of this page is navigation"? Get rid of the garbage. They don't need nav while they are looking at content. All they need is a simple link or button that says "show menu". Let the nav sit in a hidden layer and when they need it throw it up over the content, because if they are navigating it does not matter what gets covered up or moved around. Give them content pages that are mostly content like this: In Your Face Menu

If there is a bunch small pieces put them in layers on one page instead of hammering the server loading tiny pages with small but important bits of content. It can be done like this

And if you want to get a little slick you can go straight to a target layer just like it is an anchor Like this

Cd&

Search ERT on the Tools Page