Drop Down Menu to link??

[Elementax]

Hey guys, basically, I know how to create a drop down menu, as well as a submit button, but I'm not sure how I would go about linking them to pages?

What I mean is...say there is 2 drop down menus. If I choose an option from both menus and click submit, it will bring me to a page on my site. I could also do a combination of Option 1 on the first drop down, but option 2 on the second.

Does anyone know how I would go about doing this? Or could provide me with the code I'm fairly certain it's mainly html based, but I could be wrong, and it could use php, if it does, please let me know and I could create a thread in that forum

Here is my current code, with no link. Let me know

                <div id="type">
                Drop down one:
                    <select id="typefield">
  					<option>Option 1</option>
 					<option>Option 2</option>
  					<option>Option 3</option>
  					<option>Option 4</option>
					</select>
                </div>
                <div id="style">
                Drop down two:
                    <select id="stylefield">
  					<option>Option 1</option>
 					<option>Option 2</option>
  					<option>Option 3</option>
  					<option>Option 4</option>
					</select>
                </div>
                <div id="search">
                	<input type="submit" name="submitsearch" value="Search"/>
                </div>

[C. Ankerstjerne]

You can only add such functionality by using Javascript. I don't see why you'd want to, though. These types of menus are poor for accessibility. A much better option is to make a CSS-based drop-down menu.

[Stomme poes]

Users are just going to a page? You want hyperlinks then.

<ul role="navigation">
  <li><a href="somewhere">Option1</a></li>
  <li><a href="somewhereelse">Option2</a></li>
  <li><a href="anothersomewhere">Option3</a></li>
  <li><a href="lastsomewhere">Option4</a></li>
</ul>

Dropdowns are nested versions of this. Hyperlinks already automagically send users' browsers to another page. You can set variables in the URLs if needed.

If you really, really, really want/need people to be able to make two selections at once, then you want a form, but as C. Ankerstjerne mentioned, using a dropdown for them makes life more unnecessarily difficult than you'd want to bother for most people.

But you can have a form somewhere near the top of the page, with two dropdowns and a submit. This means you could do a GET with the values of the options added to the action URL as params, tho as mentioned above you need Javascript for that. Otherwise, you can do a Post to a backend script that processes the selections and sends a redirect back to the browser (the PRG pattern) with params in the URL. I like this one if you choose a form because it doesn't rely on client-side scripting being available (so doesn't need JS) AND the back button still works.

Think long and hard about what people are supposed to do, what they expect to do, and what most other websites do. For usability reasons this dropdown method you propose has mostly been abandoned, but maybe this is a demand that you can't turn down... in which case, if you build such a thing, you'll have to be aware of the pitfalls.

If you choose the form and the Post-request-get method then the PHP section could help you on what that script would need to do, and we can guide your HTML.

[Elementax]

Thanks for the help so far, but I think you guys have my plans mixed up (Sorry I didn't clarify more in original post :P). Basically, I don't want this to be apart of the navbar in any way. I basically want a drop down so users can search different parts of the content on my soon-to-be website.

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.

[Stomme poes]

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?

[Elementax]

Wow thanks for all the info, I'm still learning, but slowly improving and this helped a lot

The only other issue I've come across now is that once my form is setup...and everything is looking great...the images don't align the same when checking on other browsers such as Safari or IE (I edited CSS in firefox). Is this another noobie mistake? D:

[C. Ankerstjerne]

Stomme's example is fine, but I would like to suggest using GET in stead of POST. By using GET, you will allow users to link to the results. POST should be reserved for forms that adds, updates or deletes data in your database, or sends an e-mail or something else that should only be done once. For all other cases, use GET.

[Stomme poes]

Christian I agree with the basic sentiment, except how does this work with the back button if the back-end script is creating URLs? Without Javascript making them in the front (updating the form action URL, which then is just a regular get), the script has to build it and then send it back...?

[C. Ankerstjerne]

It can be done either as a URL with variables, or as a 301 redirect. Neither give any problems with the back button, as you can see from this example.