Javascript mouseover function has been around for at least eight years now, from somewhere around 1996/7 on. I see a lot of sites (including some of my own) that use Javascript for mouseover functions and decided to try and strip out as much code as I could to try and reduce the redundancy and unnecessary code used to perform such a simple procedure… swapping out an image for another one. Dreamweaver (as an example) is notorious for producing more code than you need.
Be sure to follow the instructions in the iFrame below:
A co-worker was having problems getting a JavaScript to work, attempting to reveal a given hidden div tag based on a select field form selection. He was going about it in a more complicated manner, and I stepped in and offered a much more simplified approach to revealing a div tag based on a form selection.
First, the source code:
<script language="javascript">
<!–
function showField(hiddenField) {
var swapWithThis = document.getElementById(hiddenField).innerHTML;
document.getElementById(”targetField”).innerHTML = swapWithThis;
}
//–>
</script>
<form action=”">
<select id=”selectField” onChange=”showField(this.value);”>
<option value=”">select an option</option>
<option value=”divOne”>Show div one</option>
<option value=”divTwo”>Show div two</option>
<option value=”divThree”>Show div three</option>
</select>
</form>
<div id=”targetField”></div>
<div id=”divOne” style=”display: none;”>This is Div 1</div>
<div id=”divTwo” style=”display: none;”>This is Div 2</div>
<div id=”divThree” style=”display: none;”>This is Div 3</div>
In this example, we’ve got some hidden div tags with content and a select field with values that correspond with the given hidden div tags. We’re simply running a function I created called “showField” with every onChange event that occurs with that form field. On that event, we’re sending the value (this.value) of the selection field “selectField” to the function. The function then grabs the innerHTML (all that is contained within the DIV tag—HTML included) of the corresponding div tag—that is, the div tag that has an ID value that matches the selection value.
We then take that innerHTML and slap it into the blank target div tag (id=”targetField”). It’s really simple, actually, and works like a charm. Test the demo here.
Parting Thought…
If you’re using this method to reveal more select fields or modify values in other target form fields, it would be wise to make use of a target HIDDEN form field to capture the final data value that you’re after. Why? Depending upon how you’re using this, you might run the risk of losing your form data/attributes in those hidden/revealed states. What I suggest is having hidden form elements to receive the final selection values—this way they remain unaffected by the selection event.
UPDATE 4/19/2006: When I originally posted this entry, I had “visiblity: none;” as the attribute in the DIV tags. The PROPER attribute is to have “display: none;” instead. This will ensure that nothing in that layer displays whatsoever.
I’ve got an addition to my Christmas wishlist for the W3C pertaining to the tag optgroup, which is part of the select tag. Presently, you can only specify a label for the opt group.
Stellar idea/proposal: How about truly making this select tag have true groupings, so that you could actually retrieve both the value of the option selected, but the optgroup to which it belongs!?! This would mean adding a value or groupvalue attribute to the optgroup tag:
… if you could not only grab the option value (e.g., “Package 1″, “Package 2″, etc.), but also grab it’s group value, think of how this would improve server-side scripting abilities!! You could add more dimension to the select form and be able to direct the posting of that form data.
For example: if I had two different invoicing tables (one for people who have hosting packages, and one for those who are receiving other services), I could direct the data to the appropriate table based on my selection. If I were creating an invoicing page, this could save me real estate on the page by condensing numerous form elements into one select field with numerous optgroups to choose from.
But until such a solution comes about, the optgroup tag is mearly an esthetic thing and of little value or power to the developer. Perhaps the W3C can make some great form innovations and come up with a great solution for this.
With a project I’ve been working on, I’ve been using a great DHTML script called HVMenu found at Dynamic Drive. If you’re using it for a regularly formatted site (i.e. no frames) it works GREAT. But once you introduce frames (at least with the version on DD), it gets a bit ugly—specifically when you’re also linking to pages outside your domain and HAVE to keep that page within your site.
When you’re trying to do that, HVMenu version 5.whatever breaks and has a hissy fit. The menu fly-out doesn’t occur and if you try to force a refresh event in the javascript file, the menu doesn’t show up. You actually have to physically reload the page with the reload/refresh button. Unacceptable.
Because I work much faster than the speed of bureaucracy (particularly definition #3) and can’t seem to slow down at that pace, I find myself challenging myself to do new things that I’ve never done before—one, because I have the time to, and two, because I might as well learn something new, right?
So one of my most recent projects I decided that I was going to format the entire page with style sheets without the usage of tables, blank .gifs to act as spacers, etc. Now keep in mind that I’m from the old school of HTML (a raw coder to the core) and know all the tricks of creating complex layouts with nested tables, transparent images, etc—in the very least, moving to a stylesheet-driven layout will have a bit of a learning curve for me. And it has been.
As if there wasn’t enough out there for me to get caught up on—XML, XHTML, AJAX, SOAP, etc. Now there is a new way of handling and presenting forms coming down the pipe called XForms. According to Wikipedia,
“XForms was designed to be the next generation of HTML / XHTML forms, but is generic enough that it can also be used in a standalone manner to describe any user interface, and even perform simple and common data manipulation tasks.”
So that implies universal form support for any application that supports XML—the ability to create forms and use them universally.
W3 has an overview on some of the parameters and the basic usage of XForms, but by no means is a comprehensive tutorial. What this means, is that down the road us old-school HTML developers are going to have to learn a whole new way of doing HTML and form handling in general.
Supposedly Mozilla will be supporting XForms sometime in August with some sort of patch or new base installation. I’m curious as to how long it’ll take Microsoft to catch on and add support in Internet Explorer for XForms. Unlikely, I’m sure. Our luck we’ll have to create multiple variations to accommodate browser differences.
This certainly looks like a viable way to go with form handling—universal forms that can be formatted with stylesheets (of course, which can be easily varied depending upon the outputting application). Seems like it won’t be long before HTML becomes a veritable thing of the past and the dominant method of formatting becomes a combination of stylesheets and some XHTML tags here and there.
Filed under: HTML, JavaScript
3 Comments 
