Many new J2EE developers get caught up in focusing on the
details and nuances of servlets and JSPs and, as a result, may not
much hassle, given cross-browser compatibility issues.
For both audiences there's still value in learning at least a
minimal amount about client-side scripting. Even learning about just
one feature - setting the cursor on the first form field you may have
- can bring measurable benefit to your site visitors.
In this month's Journeyman J2EE, we depart from pure J2EE
topics to address this subject, which should be understood by any Web
provide more than enough to get started.
Where's Your Focus?
Here's the motivation for the problem I want to solve: you
visit a Web site that offers a form inviting you to enter some input.
No big deal - we see them all the time, right? Now, how do you get to
the point of entering data into that first field?
Do you use your mouse to move the cursor to that first data
entry area? Or are you a keyboard maven, like me, in which case you
prefer to tab to such a field? The problem is you may have to hit the
tab key several times before you can enter data.
Indeed, it's typical to visit sites with navigational
toolbars across the top and/or left side of the form, forcing you to
tab dozens and dozens of times. It's an annoyance, especially if
visitors to your site know the site designer could have easily
prevented the problem.
If you think that's being pedantic, consider a simpler
example. If you show users a page that clearly is expecting them to
enter some data (perhaps a user ID or a search argument, etc.) before
proceeding, why not put the cursor right on the data entry field
rather than forcing them to use the mouse or keyboard to get there.
It's a usability issue.
There's an incredibly simple solution. Just the tiniest bit
shows how to use it and also lays the most basic foundation for using
Laying the Foundation
The technique we're talking about involves putting the
"keyboard focus" on whatever form input field - a text, password, or
textarea box or even a radio, checkbox, or select field - you want
on nearly all Web browsers. (Microsoft calls its version of the
language JScript. They're nearly the same, especially for the
purposes of this article.) It's a scripting language that can be used
to add features to your Web page that aren't otherwise provided by
This article shows you the simplest application of this focus
method. It's pretty straightforward and should work fine in most
this particular feature is supported identically in both Netscape's
and Microsoft's versions of the language, so there's no need to worry
about it breaking on different browsers.
Gimme the Goods
several ways to do this. You can embed the code in a pair of <SCRIPT>
tags (and even then you have choices about where those tags are
placed) or you can place it in special attributes of HTML tags (such
as ONLOAD within a <BODY> tag).
Let's take a simple example in the first of those two forms.
displayed to the user in a popup box. To do that, we could use the
Put that code almost anywhere in an HTML page and when you
view that page in a browser, you'll see a message pop up: "Hello
code to indicate that we want to place the focus on a particular
field. We're almost there.
Focus on Forms
The focus() method operates on form fields. One of the many
all the elements of our page (all the forms, form fields, indeed
every tag and its contents and attributes), we can manipulate them as
How do we specify that we intend to work with some part of
our page, such as a particular form field? Most of you know that you
can give a name to a form field, and in JSP/servlets that will become
the name of an attribute in the request scope on the form's action
form field to give it focus. If we have an input field for a "UserId"
that should be entered, the HTML would be:
Enter Userid: <INPUT TYPE="text" Name="UserId">
Of course, the <FORM> tag would be specified completely and
other form field information would be provided both before and after
this input field. However, it's important to know that this does
indeed (and must) occur within a <FORM> tag.
One reason it's important (besides being the way HTML is
coded!) is that when we want to refer to a particular element within
of its relationship to the entire page. This input form field,
"UserId", occurs inside of a form. On a simple level we might refer
to it as form.UserId.
This isn't technically correct, however, since it's possible
to have more than one form in a page. Indeed, there are rules that
called the Document Object Model (DOM). In any case, we need to
indicate the specific form in which the field occurs.
What's in a Name?
There are two ways to do this: we can refer to the form by
name or by indicating the relative location of the form on the page.
Which is appropriate for you depends on your situation. If you've
specified a NAME attribute on the <FORM> tag, you'd use that name.
If we had specified NAME="Login" on the <FORM> tag, we would
refer to the form field as Login.Userid. But we're not done yet. The
form itself occurs within the Web page, and while it might not seem
necessary, the contents of the page are considered to be within the
"document" on the page (again, recall the "Document" Object Model).
We finally have the complete means by which to refer to the field:
Before leaving this subject, let's clarify that if you
haven't named your form, you can still refer to it by indicating the
relative location of the form within the document. There's a special
"forms" array in every Web page document, so if you have only one
form in yours, you would indicate it as the first form.
Unfortunately, even this can trip you up because in
rather than 1. So the way to refer to your form field (assuming it's
within the first or only form on the page) would be:
Notice that this isn't used as "form" but as "forms".
It's a subtle point, but if it's not specified correctly, you'll
receive an error.
We're on the Case
Indeed, it's also critically important to remember that
something must be the case you use when referring to it later with
If we were to refer to our form field as
expects us to refer to both the "document" and "forms" elements as
Similarly, since we named the form field UserId, we must
refer to it exactly that way. If we referred to it as
document.forms.userid, or even document.forms.Userid, we'd
receive an error either way.
Forcing the Focus()
To set the focus we use the focus method just like a
reference to an object's method in Java. To set the focus for our
form field called "UserId", we might specify it as:
That's about it. There's nothing to be specified within the
parentheses. (Notice that the word focus is also all lowercase.) This
statement, when executed, will cause the named field in the named
form to receive the focus when the page is displayed to the user. In
other words, the cursor will be resting on that field when the page
Our final challenge is to decide where and how to specify
be executed as such. We mentioned earlier that this could be done by
way of the <SCRIPT> tag. The following code will cause the focus to
be placed on our UserId field:
If only it were this easy. Well, it is - almost! You just
need to make sure the statement is executed after the form has been
form field, as it were) before it's been defined. In this case, with
this approach to executing the statement, we need to be sure not to
put this code on our page prior to the form itself.
Besides the <SCRIPT> tag, we can also use the event-handler
attributes of other tags. For instance, we could also force the
know that there's an attribute for the BODY tag called ONLOAD that
does just what we need, causing whatever statements it executes to be
run only after the page has loaded. Since the form is within the
page, this is indeed another solution to our problem.
(the statement itself, not the <SCRIPT> tags) by placing it in the
BODY tag's ONLOAD attribute, as in:
statement is not usually required, but it's the formal method of
Experienced developers may prefer yet another approach:
creating a function instead and calling that function in the ONLOAD.
But Will It Fail?
You should have no trouble if you:
There are a couple of other edge cases to be aware of,
however. First, some folks use a single page to serve as both the
form and action page (loaded from within the same JSP template, for
instance). That's fine and can be a powerful way to reuse lots of
form field on the page, but the output of the action page (POST)
processing doesn't show the form (because you're showing the results
of processing the form, not the form), you'll get an error. This is
particularly risky when using the ONLOAD approach, because you may
not think of it as serving both the form and action page when coding
- Refer to the form field using the naming references indicated.
- Remember to specify the proper case for the naming reference.
- Ensure that the statement occurs only after the form has been loaded.
In a similar vein, and equally tricky in some situations, you
form field to which it's referring isn't included in the page. With
dynamically built pages as in JSP and servlets, this isn't as strange
as it might seem. Forewarned is forearmed.
There's very good news.
With the <SCRIPT> tag approach described earlier, you may
notice that just inside the opening and closing <SCRIPT> tags are
guarantees that if the browser doesn't support the <SCRIPT> tag
statements inside the script and comment tags. However, browsers that
With the ONLOAD approach as well, browsers that ignore
the second approach) is also ignored.
Should you go ahead and add the focus method for the first
input field of the forms in all your pages? Well, first it may not be
appropriate to the interface. On some pages the form and its input
fields may not really be the focus of the page. Consider a page that
happens to have a search field on it, such as
http://industry.java.sun.com/solutions/ (see Figure 1).
If you look closely at the top right corner, there is indeed
a "form" on this page for searching the site, but it's definitely not
the focus of the page. There's also a search field to "Find a
Solution" on the right-hand side. Should we put the focus in the
first form field? The second? Either? Maybe neither. If you put it on
the second, which may seem a focus of the page, keyboard users would
find that tabbing once wouldn't take them to the top nav bar but
instead to the links under that search field. That's not good
Another reason not to blindly set the focus on any first form
on the page is if the form doesn't appear at the top of the page. If
we did that, an unintended result would be that the screen would be
scrolled down when displayed, so that the field with focus (that form
input field) was visible. This may cause the top of the page to be
hidden from the user. Remember, too, that users often have different
(and lower resolution) monitors than developers, increasing the
chances of this problem developing. It can also happen if the users
don't maximize their screen when displaying your page.
When would it be appropriate to put the focus on a field?
When the form is clearly the focus of the page. Going back to the
previous example at Sun's Solutions Marketplace, consider the link
under that "Find a Solution" button, labeled "Enroll Your Company."
On the page that will be shown, it prompts for Company Name. That's
clearly the focus of the page, so putting the focus on that field
would make sense (sadly, they're not setting the focus using this
approach as of this writing).
If you visit www.altavista.com, a popular search engine,
you'll see that searching is clearly the focus of the page, and they
do indeed use the focus method so that you can start typing search
criteria as soon as the page appears.
Another natural example, and one that nearly all developers
end up dealing with, is a login page that's presented to enter a site
or access secured areas. If the user can't proceed without entering a
user ID/password and the prompt for this is the only reason the page
is being presented, there's little reason not to set the focus on the
Afterword: Using SCRIPTJ in JRun Studio
There's one last useful trick that will be of interest to
users of JRun Studio (a similar feature may exist in other IDEs). It
also works in its sister Macromedia products, ColdFusion Studio and
Remember <SCRIPT> tags offered earlier with the HTML
comment characters specified within them - I mentioned that these are
page (other than that entered within other tag attributes like
You could hope to remember to enter that properly formatted
set of basic tags:
or you could take advantage of a nifty shortcut in Studio: simply
type SCRIPTJ, press CTRL-J (the control key and J), and watch as
Studio converts that into the set of tags offered above. The cursor
is even sitting there within the paired tags waiting for you to type
Using the focus method is a win-win that should be used in
even in Netscape 2 and IE 3. Plus, it really is just a single
I find it so frustrating when a site doesn't use it? I hope newcomers
Charles Arehart is a 20-year IT veteran with experience
spanning a range of technologies, including large scale database
systems. For the past four years he's been an active trainer, writer,
and consultant in enterprise Web application
development. He contributes to several resources, provides
on-site coaching and consultation, and is a frequent speaker at user groups
throughout the country.