!9 is a age of Ideas

Fancy Form Design Using CSS :

Forms. Is there any other word that strikes as much fear into the hearts of grown web designers?

I think that the reputation of forms as an untamable, ugly necessity has arisen for two reasons:

· Form elements are derived from native operating system widgets, which makes them particularly difficult to style.
· Forms are often critical to the function of a web site -- they're most often employed as search boxes, inquiry forms, or shopping cart checkouts -- and need to function as smoothly as possible in order to meet user expectations.

However, it's still possible to incorporate both these points into designing a form tailored to the style of the rest of your site. This article, which is fresh from The Art and Science of CSS, will explore the ways in which you can design a great-looking form, and provide you with the necessary code, which we'll work through together. You can also download this article as a PDF.

Accessible Form Markup

Before we can begin to look at form layout, we need to craft some really solid markup that will provide us with a framework to which we can add some style.

Forms represent the one area of your web site where you absolutely must commit time and energy to ensure user accessibility. Even though forms represent some of the most complex interactions that can occur on a web page, in many cases these interactions are only represented visually -- via the proximity of a form element to its label, or grouping by borders and background colors. Users of assistive technology such as screen readers may not be able to see these visual clues, so it's vital that you support these users by ensuring accessibility. The key concept behind providing an accessible form is to have descriptive labeling of all its sections and input elements.

In particular, this means the proper usage of two elements: label and legend.

There's also an improperly held belief that the only way you can guarantee that a form displays properly is by using tables. All of the code reproduced here for forms is standards-based, semantic markup, so you've got no excuse for relying on tables now!

Labeling Form Elements

No matter how you style a form element and its label, it generally conforms to a certain pattern:

· the form element itself

· a text label for the element

· a connection between the element and its textual description

This connection is made either through visual alignment, visual grouping, or some other visual indicator. In Figure 1, you can see that the form on the left makes a connection between the field element and its label purely through alignment, whereas the form on the right indicates a more explicit connection via the use of color.

When accommodating users of assistive technology in the creation of your forms, there's one main question to consider. How can a user who's unable to see a web page create the connection between a form element and its text label, without the visual cues of proximity or grouping?

The answer is the label element. label is a special element applied to a form element to allow its textual description to be semantically linked to the element itself, so any assistive technology such as a screenreader can read out that text when it encounters its partner form element.

In order to use a label, wrap the textual description in a pair of label tags, then add a for attribute to the label. The value of the for attribute should be the id of the form element with which you want to create a connection:

<label for="firstName">First name</label>
<input id="firstName" name="firstName" type="text" />

Now, when a screenreader encounters the firstName field, it'll also read out the text "First name" to the user, so he or she will know what to type into that field. The label doesn't have to be near the form element and neither of them have to be in any particular order -- as long as the label's for attribute contains a valid reference, the relationship will be understood. However, having the label right before the form element in the source order generally makes the most semantic sense.

A label should be applied to any form element that doesn't automatically include descriptive text, such as:

· checkboxes

· radio buttons

· textareas

· text fields

· select boxes

Submit buttons and submit images don't require label elements, because their descriptions are contained, respectively, in their value and alt attributes.

Of course, you can easily style the text inside the label using CSS, so you can format the label text in your forms in the same way as if you were using a span, p, or div, but using a label has the benefit of being much more accessible than any of those elements.

Grouping Related Elements

legend goes hand in hand with fieldset. In fact, the only element of which a legend can be a child is a fieldset. A fieldset groups a series of related form elements. For instance, "street address," "suburb," "state," and "zip code" could all be grouped under "postal address." You could create a fieldset that groups all of those elements, and give it an appropriate legend to describe that group:

<form action="example.php">
<legend>Postal Address</legend>
<label for="street">Street address</label>
<input id="street" name="street" type="text" />
<label for=" suburb">Suburb</label>
<input id="suburb" name="suburb" type="text" />
<label for="state">State</label>
<input id="state" name="state" type="text" />
<label for="postcode">Postcode</label>
<input id="postcode" name="postcode" type="text" />

Now that legend is associated with all those form elements inside the fieldset, when a person using a screenreader focuses on one of the form elements, the screenreader will also read out the legend text: "Postal Address; Suburb."

The benefit of the screenreader specifying both legend and fieldset becomes apparent when you have two groups of elements that are very similar, except for their group type:

<form action="example.php">
<legend>Postal Address</legend>
<label for="street">Street address</label>
<input id="street" name="street" type="text" />
<label for=" suburb">Suburb</label>
<input id="suburb" name="suburb" type="text" />
<label for="state">State</label>
<input id="state" name="state" type="text" />
<label for="postcode">Postcode</label>
<input id="postcode" name="postcode" type="text" />
<legend>Delivery Address</legend>
<label for="deliveryStreet">Street address</label>
<input id="deliveryStreet" name="deliveryStreet"
type="text" />
<label for="deliverySuburb">Suburb</label>
<input id="deliverySuburb" name="deliverySuburb"
type="text" />
<label for="deliveryState">State</label>
<input id="deliveryState" name="deliveryState"
type="text" />
<label for="deliveryPostcode">Postcode</label>
<input id="deliveryPostcode" name="deliveryPostcode"
type="text" />

As Figure 2 shows, with the fieldset's legend elements in place it's quite easy to determine visually which fields fall under which group, even on an unstyled form.

But, you ask, couldn't the same visual effect be achieved using h1 elements instead of legend elements?

Yes. However, the point of using legend is that without proper semantic grouping and labeling, a screenreader user would become confused as to why he or she was required to enter "Address 1" twice. With the legend included, the user will know that the second "Address 1" actually belongs to another group -- the group for the delivery address.

So, by combining label and legend, we give visually impaired users the ability to navigate and fill in our forms much more easily. By using this combination as the basic structure for your forms, you'll ensure that not only will they look fantastic, but they'll be accessible as well!

Form Layout

There are several different ways in which you can lay out a form. The method you choose depends upon how long the form is, its purpose, how often it will be used by each person who has to fill it out, and, of course, the general aesthetics of the web page.

It's generally considered most efficient to have one form element per line, with the lines stacked sequentially one on top of the other, as most Western-language web pages are designed to scroll vertically rather than horizontally. This allows users to follow the path to completion easily and focus their attention on entering one piece of data at a time.

For each form element in a left-to-right reading system, it's logical to position the corresponding label in one of three ways:

· directly above the form element

· in a separate left column, left-aligned

· in a separate left column, right-aligned

Each of these approaches has its own advantages and its own look, so consider these options when you're deciding how to lay out a form for a particular page.

Labels that are positioned directly above a form element have been shown to be processed most quickly by users. The compact grouping between label and element reduces eye movement by allowing the user to observe both simultaneously -- here's an excellent article published by UXmatters. However, this type of positioning is rather utilitarian, and isn't the most aesthetically pleasing layout. It also has the disadvantage of occupying the most vertical space of the three layouts, which will make a long form even longer. Generally, top-positioned labels work well for short forms that are familiar to the user -- see the comment form in Figure 3, which is from a previous incarnation of the Dress For Dialogue web site.

Labels that are positioned in a column to the left of the elements look much more organized and neat, but the way in which the text in those labels is aligned also affects the usability of the form.

Right-aligning the text creates a much stronger grouping between the label and the element. However, the ragged left edge of the labels can make the form look messy and reduces the ability of users to scan the labels by themselves, as Luke Wroblewski argues in his article on the subject. In a left-aligned column, the labels instantly become easier to scan, but their grouping with the associated form elements becomes weaker. Users have to spend a little more time correlating the labels with their elements, resulting in slower form completion. An example of left-aligned labels can be seen in Figure 4.

The right-aligned column layout shown in Figure 5 allows for quicker association between label and element, so again it's more appropriate for forms that will be visited repeatedly by the user. Both layouts have the advantage of occupying a minimal amount of vertical space.

Rock-solid CSS Layouts:

This article is excerpted from SitePoint's HTML Utopia: Designing Without Tables Using CSS, Second Edition, which provides a complete introduction to CSS and shows you how to build rock-solid CSS-based web sites from scratch. By the end of the article's 12 articles, you'll understand the ins and outs of CSS, and you'll be able to create robust, standards-compliant site designs that degrade gracefully in older browsers and are easy to maintain.

You can download this article in PDF format, along with the first three articles of the article, if you'd prefer to read it offline. Now, let's get started building your CSS-based page layout!

We now have some sound theory under our belts. The rest of this article will concentrate on how you can put CSS into practice when developing your own sites. Along the way, we'll be learning how to lay out pages using CSS—moving from simple layouts to more complex ones—and how you can combine some of the concepts you've already read about to create great-looking sites.

This article will start with the creation of a simple two-column layout. Along the way, we'll discover how to use absolute and relative positioning, and see how margins, padding, and borders work together. Then, we'll get an understanding of how all these tools can be used together in practice by creating a two-column layout that uses many of the techniques we have discussed already in this article.

While the layout we'll create in this article is a relatively simple one, it's a structure that's used by many web sites; the layout we'll develop here could easily form the basis for a production site.

The Layout

Many web site designs start life as mock-ups in a graphics program. Our first example site is no exception: we have an example layout or "design comp" created in Fireworks as a starting point.

Figure 8.1. Creating the layout as an image file

Starting out with a visual like this enables us to think about the way we're going to build the site before we start to write any XHTML or CSS. It gives us the opportunity to decide how best to approach this particular layout before we code a single line.

This layout divides the page into three main sections: a header, which contains the site logo and some main navigation; a main content area comprising a large image above a list of news stories; and a sidebar, which presents some additional items.

This layout could be described as a two-column layout with a header area. Being able to visualize a design as being a combination of its main sections eases the process of deciding how to approach the page layout.

Creating the Document

Having decided what the basic components of our page will be, we can start work. The first thing we'll do is create an XHTML document that contains all of the text elements we can see in our layout image, marked up using the correct XHTML elements.

Working this way might seem a little strange at first, particularly if you have been used to working in a visual environment, such as Dreamweaver, and simply concentrating on how the design looks. However, one of the advantages of using CSS for layout is that we're able to separate the structure of the page from its appearance. This allows us to concentrate on building a good solid document as the basis of our site, before adding the design using CSS.

We start out with the basic requirements for an XHTML Strict document. As we're going to use CSS for all of the presentational information on this site, there's no reason not to use a Strict DOCTYPE. The Transitional DOCTYPEs (for both XHTML and HTML 4.01) allow you to use attributes and elements that are now deprecated in the W3C Recommendations. The deprecated elements and attributes are mainly used for presentation, and as we're going to use CSS—not XHTML—for presentation, we won't need to use these anyway.

Example 8.1. index.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml">
<title>Footbag Freaks</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1" />

Declaring the Character Set

In our pages, we've used the meta element with the http-equiv="Content-Type" attribute to declare our document's character set. This makes it easy for browsers (and the W3C validator) to determine which character set is being used in the document. If this information was missing, a browser could misinterpret the characters in your page, which could see your pages rendered as unintelligible garbage.

All of the examples in this article use ISO-8859-1 encoding, which is the default for most popular text editors and programs such as Dreamweaver. If you're dealing with a different character set, such as Unicode, you'll need to change the meta elements accordingly.

The Header

Let's start to add the content of this page to our document. As we do so, we'll split it up into the various sections identified above, containing each page section between <div> and </div> tags. We'll give each div an id to identify that section; we'll use these ids to address each section and style it using CSS.

After the <body> tag, add the following markup:

Example 8.2. index.html (excerpt)

<div id="header">
<p>The Home of the Hack</p>
<li><a href="">Contact Us</a></li>
<li><a href="">About Us</a></li>
<li><a href="">Privacy Policy</a></li>
<li><a href="">Sitemap</a></li>
</div> <!-- header -->


19 DEV is a Company of Young Developers. Our aim is to give and implement Fresh Ideas.


copyright © 2008-09 by 19DEV.com - all rights are reserved
Designed by 19DEV.com. www.19dev.com, www.expertsitsolutions.com, Domain and Hosting Expert . Updated: 2:36 PM 7/12/2010