Okay, maybe this is a search form.
If they come to the site for Option A…they may choose that on the drop down and it will send them to a page with <Option A>. Hope that clears it up, but I believe I would still need java.
If Option A is a URL, then it’s still a hyperlink. Most web sites are broken up into different pages representing different sections.
s/java/javascript/g but generally that should never be necessary for basic site functionality… HTTP and HTML do everything necessary except dynamic page updates, which themselves are nothing more than an enhancement you could add to an already-working HTTP-HTML setup anyway (Hijax, the layering of ajax/Javascript on top of a working form).
Anyway, assuming this is a search form:
I personally like PRG, because it keeps back button functionality.
Your form is a POST to your back-end script, and sends two values. The backend script’s job might not really be to build a URL out of param/values if this is search… it might have to feed these values to your search function, I dunno what you have set up. BTW I don’t see a “nothing” option in your selects. Meaning people will always be sending two options. If one should be a default, give it the selected=“selected” attribute. Otherwise, create another option, set it first, and give it whatever your script knows as a null value.
Anyway eventually whatever your script is supposed to do, it will send back a URL to the browser as a response as if the browser had done a GET. This means, if the user hits the back button, then end up on the original page (and if you aren’t using sessions to store what they’ve selected, then it will depend on the browser whether or not the selected values remain selected in the form).
Here would be an example of your HTML
<form id="someid" action="path/to/yourscript" method="post">
<fieldset>
<legend>What This Form Does</legend>
(optional div here for styling)
<label for="typefield">Drop down one: </label>
<select id="typefield" name="typefield">
<option value="value1">Option 1</option>
<option value="value2">Option 2</option>
<option value="value3">Option 3</option>
<option value="value4">Option 4</option>
</select>
(close optional div)
(optional div here for styling)
<label for="stylefield">Drop down two: </label>
<select id="stylefield" name="stylefield">
<option value="value1">Option 1</option>
<option value="value2">Option 2</option>
<option value="value3">Option 3</option>
<option value="value4">Option 4</option>
</select>
(close optional div)
<input type="submit" value="Search"/>
</fieldset>
</form>
Whether or not you want a name attribute on the submit I believe depends on whether you want the submit itself to be a part of what you send to the script. Usually people don’t need it but the PHP guys could tell you for sure if you explained what exactly you needed.
The legend is required if you use fieldset with HTML4. It is not required if you are using XHTML1, though it is strongly recommended. If you already have a header tag before the form explaining what it does, you can wrap a span around the text inside the legend and pull it offscreen with absolutely positioning.
<legend><span>What This Form Does</span></legend>
The labels are Good Ideas in forms, even if you feel the function of the dropdowns is obvious. Test on a grandma before making that assumption. If she knows, great: hide the labels offscreen using same abso-po technique, and use the for attribute on the labels to match the id of the selects.
The name attributes on the selects should send the value attribute’s value of the options on submit.
That default HTML is fairly ugly on its own, but CSS can make it look however you want (including taking off-screen what you don’t want to appear visually). Divs wrapped around each label-select pair might make styling easier, since divs are blocks and labels and selects are inlines (or, in some browsers, selects and other inputs are inline-blocks).
How’s your CSS?