I am running an application where users can select categories for a selected field:
example: user-selected field = 'country' then the user can select 'country names'(India, China, America etc.) in the dropdown.
This works well when categories have unique values less than 15(this may vary). But when users need to select more than 15 categories it becomes very difficult for the user. I wanted to know what are the best possible solutions to ease this process?
example: user-selected field 'city' now users want to select 200 city names from the dropdown.
It can be a box where user can paste comma sepearated category values and we can auto fill these in dropdowns, or a simple file upload.
Please let me know your thoughts.
maybe not make a dropdown but a input field and validate it via options list (like in dropdown but type-to-select) small example:
<input list="id"></input>
<datalist id="id">
<option value="USA"></option>
<option value="GERMANY"></option>
<option value="RUSSIA"></option>
<option value="CHINA"></option>
<option value="FRANCE"></option>
<option value="INDIA"></option>
<option value="UK"></option>
</datalist>
hope this helps =] if you dont know how it works - copy it to any html file to tag and just use on custom page to understand =]
I think the best solution will be to give the user a text box, where the user can paste comma-separated values and we can extract and auto-select the defined values.
I am in the process of converting an old client/server app to a web browser-based application, and have an issue with the standard HTML SELECT element. Users of this app enter search term/operator pairs to construct a search on a large database (see sample markup below).
<input type="text" id="txtTerm1" />
<select id="selOp1">
<option value=""></option>
<option value="or">Or</option>
<option value="near">Near (any)</option>
<option value="near2">Near (within 2 words)</option>
<option value="near4">Near (within 4 words)</option>
<option value="before">Before (any distance)</option>
<option value="before2">Before (within 2 words)</option>
<option value="before4">Before (within 4 words)</option>
</select>
A search term is entered into txtTerm1, and then TAB or ENTER is pressed to move to selOp1. The users like to use the keyboard exclusively to choose an operator from selOp1. When they quickly press "n", the select control iterates through the "near" options perfectly. But if the user then decides they want to switch to "Or" and types "o," the control does not select the "Or" option.
Test: Type n,n,n,n,n,o in rapid succession
It seems that if you type quickly and then change characters, the SELECT element groups the two characters together, "no" in this case, and does not find an OPTION with that text. If I wait a few seconds after typing the n's and then press o, it works. But this slows the users down and is confusing. This behavior seems to be the same in Chrome, Firefox and IE.
The question:
Is there a way to force a SELECT to only use the first character of the OPTION text when trying to locate an OPTION with the keyboard? Or does anyone have any other clever solutions? Any advice is greatly appreciated.
I'm experiencing quite an odd issue with <select> menus. When I go back to a page containing a <select> after I have clicked out of it (or minimized it) the <select> sometimes collapses and becomes unresponsive. I have checked all of my code, and it is 100% valid, further I have seen this happen on other sites as well.
I have experienced <select> menus collapsing in the latest version of Safari (available for OSX 10.6.8) as well as the latest versions of Chrome and Firefox (tested both on Windows Vista and OSX 10.6.8). Oddly enough I have not been able to reproduce the <select> collapse in Chrome running on Windows 8... One last tidbit: it seems that the length of the <select> element affects the probability of the menu collapsing (that is to say, the more <option> elements in a <select>, the more likely it is to collapse. Sometimes a <select> menu will collapse after being selected and clicked out of once, sometimes it can take 5 or 6 attempts.
My question is: What causes this <select> collapse issue, and is there a known work around? Please see the example code below, it's very simple, but the <select> menu has nonetheless collapsed in the browsers/operating systems I mentioned earlier. Thanks in advance!
<!doctype html>
<html>
<head>
<title>Select Test</title>
</head>
<body>
<select name ="Test">
<option value = "0">0</option>
<option value = "1">1</option>
<option value = "2">2</option>
<option value = "3">3</option>
<option value = "4">4</option>
<option value = "5">5</option>
<option value = "6">6</option>
<option value = "7">7</option>
<option value = "8">8</option>
<option value = "9">9</option>
<option value = "10">10</option>
<option value = "11">11</option>
<option value = "12">12</option>
<option value = "13">13</option>
<option value = "14">14</option>
<option value = "15">15</option>
<option value = "16">16</option>
<option value = "17">17</option>
<option value = "18">18</option>
<option value = "19">19</option>
<option value = "20">20</option>
<option value = "21">21</option>
<option value = "22">22</option>
<option value = "23">23</option>
<option value = "24">24</option>
<option value = "25">25</option>
<option value = "26">26</option>
<option value = "27">27</option>
<option value = "28">28</option>
<option value = "29">29</option>
<option value = "30">30</option>
<option value = "31">31</option>
<option value = "32">32</option>
<option value = "33">33</option>
<option value = "34">34</option>
<option value = "35">35</option>
<option value = "36">36</option>
<option value = "37">37</option>
<option value = "38">38</option>
<option value = "39">39</option>
<option value = "40">40</option>
<option value = "41">41</option>
<option value = "42">42</option>
<option value = "43">43</option>
<option value = "44">44</option>
<option value = "45">45</option>
<option value = "46">46</option>
<option value = "47">47</option>
<option value = "48">48</option>
<option value = "49">49</option>
<option value = "50">50</option>
<option value = "51">51</option>
<option value = "52">52</option>
<option value = "53">53</option>
<option value = "54">54</option>
<option value = "55">55</option>
<option value = "56">56</option>
<option value = "57">57</option>
<option value = "58">58</option>
<option value = "59">59</option>
<option value = "60">60</option>
<option value = "61">61</option>
<option value = "62">62</option>
<option value = "63">63</option>
<option value = "64">64</option>
<option value = "65">65</option>
<option value = "66">66</option>
<option value = "67">67</option>
<option value = "68">68</option>
<option value = "69">69</option>
<option value = "70">70</option>
<option value = "71">71</option>
<option value = "72">72</option>
<option value = "73">73</option>
<option value = "74">74</option>
<option value = "75">75</option>
</select>
</body>
</html>
Update:
Here is a screenshot of a collapsed/unresponsive <select> menu in Safari 5.1.9 running on OSX 10.6.8 (this is a different mac than the one I was using earlier). It became unresponsive after 3 attempts (selecting an option, then clicking out of the browser). It does not reveal the option list when clicked, and is completely unresponsive until the page is reloaded. I'll be downloading chrome on the mac shortly.
Update 2:
According to #webdad3, this issue is also present in IE9
Update 3:
Here is a link to the source code I posted above, but in JSbin. Courtesy of #starbeamrainbowlabs.
http://jsbin.com/eXOMeRI/1/edit
Update 4:
According to #Zarazthuztra, this issue is also present in OSX 10.8.
Update 5:
I'm taking #cloudcoder2000's advice and posting this link in the question itself. I believe it shows that a <select> should not collapse (like many of us are experiencing) regardless of the number of <option>s it contains.
Is there a max number of options (values) in HTML drop down control?
I would like to also thank everyone for their help thus far.
Update 6:
I fear this question is beginning to stagnate... If anyone has any theories as to what is causing this issue (regardless of how "off-the-wall" it may seem) let me know and I'll test it asap.
Update 7:
Just confirm: I've experienced this collapse issue on several pages that do not use Javascript. Further, the example code I posted above (which does not contain any Javascript) has collapsed for me and a few other stackoverflow users (across different operating systems and browsers).
Update 8:
#Capile was able to reproduce the collapse issue in Safari 7.0.1 running on Mac OS X 10.9.1.
Update 9:
By using #Capile's code, I was able to get the <select> to "uncollapse" in Safari 5.1.10 (running on OSX 10.6.8). Please read his answer for the full details. I will be testing his code in Chrome and Firefox later today, or tomorrow. This is really promising, I think we're getting close to solving this. I would just like to thank everyone again for their help thus far, you guys are great!
Update 10:
I finally got a chance to test #Capile's code in Chrome on one of my Snow Leopard (10.6.9) machines. I had quite a bit of trouble getting the <select> to collapse this time, but after a few minutes of trying, it finally did. After pasting his code into the console the <select> "uncollapsed" (to put it as inelegantly as possible). This is quite curious, because if this "collapse" issue is related to system-level garbage collection, then one would think that the a <select> would "collapse" fairly consistently across browsers, but this isn't the case. I've tested a myriad of browsers (across multiple operating systems) and <select> "collapse" seems exceedingly common in certain browsers (such as Safari)... I'm admittedly not an expert programmer so I may be wrong, but in any case, I just wanted to update this question so that greater minds could mull over the new information.
Update 11:
I just added a bounty to this question in an attempt to generate more interest (I hope it helps). Anyway, I was able to get the <select> to collapse in the latest version Firefox (running on OSX 10.6.9) last night. I unfortunately did not get a chance to test #Capile's code in Firefox, but I will try to do so today.
Since the <select> element UI is handled by the OS in several browsers (which makes their complete styling much more complicated, or impossible), I would guess that's it is a bug on OS level, or a bug at the browser that relates to some OS UI functionality — definitely not a problem of the source HTML, which is plain simple and according to specs).
For the browser, the <select> element is completely normal: you can see it at DOM, even manipulate it (it also listens to events as well). If you detach and reattach it to the DOM, it works normally again (open up and enable selecting). If you just run the code below at the console window, you'll get it working again:
var s=document.getElementsByTagName('select'),
i=s.length,
a=document.createElement('div'),
b;
while(i-->0) {
s[i].parentNode.insertBefore(a, s[i]);
b=s[i].parentNode.removeChild(s[i]);
a.parentNode.insertBefore(b,a);
a.parentNode.removeChild(a);
b=null;
}
My guess is that when the browser is blurred, the UI elements might get caught by some sort of OS garbage collector, and when you get back at the browser, it just expects the OS to display it again (but it can't find it). But it's just a guess — I'd need to profile Safari memory in order to really get to it.
I could replicate it on Safari 7.0.1 running on Mac OS X 10.9.1, but couldn't replicate it on Firefox 28.0a2 (Aurora) or Chrome 34 (Canary).
You have an issue not related to <select>.
Some if not most DHTML web-application logic not work well with "back" and "forward" buttons, these are almost are history.
The source code you provided is OK.
Update the browser or change it for another that is capable of the task.
in your browser has any problem with plain select about 75 items - contact your browser provider.
The limitation for an amount of elements in select does exist as for everything. We are limited by amount of memory per app - depends on platform and amount of memory left.
The browser has some internal collections of elements and these collections are limited to some quantities. The same goes for every application. Though these limits are far from barely hundred of items, the select may contain a lot more but it's an another pain to render them.
In some intranet applications ppl use thousands of options per select and multiple selection of 75.
Check your JS instead, it's possible you have a script working on the select element that is causes it to misbehave.
UPD: might be a problem with
<!doctype html>
it's ver 5 non-standard so far. 03.2014
(for more info take a look at http://www.w3.org/html/wg/drafts/html/master/)
try
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
to prevent a browser from trying to parse HTML ver 5.
As mentioned in the comments, this seems like lag. Whether it is caused by the specs of your computer, the browser, plugins/extensions, or something else on the page, you can't put 75 options in a select and expect Safari and IE to keep up. I'm not sure if lag could cause a page to freeze and force the user to reload it, but I honestly don't know what else could have caused it.
I'm not really sure where you would need a select with 75 options, but if you do really need it, I'd recommend a simple text input where you limit what the user can input to 1-75. Yes, it's not exactly as simple and elegant as a dropdown select, but it will get the job done, and you shouldn't have to worry about glitches.
Aaaahhhh, this is a longshot, but...
Try removing the spaces in your HTML attributes (not inside quotes), so value = "0" becomes value="0".
I've seen similar behaviour with the select element but it was usually not the cause of the problem. If the basic browser components are lagging then it's usually because there is a long running script in the background that is consuming all of the browser resources. Is the page you pasted above the entire page or is there also significant javascript being run on the page?
Find the browser which works for you while waiting for an update/patch. Whenever I encounter a browser issue I usually switch between Firefox, Google Chrome, and IE.
As for your code, I suggest looking into JavaScript, which should make your life easier by turning all those hard-coded <option> into something dynamic. Something like:
// Starting from index 0,
// create an <option> with the value of the current index
// keep creating <option> until you hit index 75.
here your problem solution use javascript for print values in select tags like:
for(i=1969;i<=2014;i++)
{
document.write(''+i+''); }
I'm using an adaptation of PHPBB to create a drop-down list.
<select name="destination_path">
<!-- BEGIN path -->
<option value="{path.DESCRIPTION}">{path.DESCRIPTION}</option>
<!-- END path -->
</select>
The list is generated from a MySQL query, so it is dynamic. This list is within a form and when the form is fired I want to retain (and return) it's state in session variables. My first thought was to place something in the <select> statement.
I know you can use:
selected="option_selected"
in the relevant <option>, but it seems like a messy way to do this and would require an if statement to compare each tag as the tag is created.
Is there a way to declare the default option in the select tag, or a better defined method to achieve the same result?
Short answer: No.
The select tag defines the selected option in its option elements. What you could do if you want to achieve it differently, is putting the selected option on top without specifying a selected attribute. Most browsers select the first option as default if there is no selected attribute present.
Ex :
<select>
<option value="Hi"> Hi </option>
<option value="Hello" selected> Hello </option>
</select>
You may be able to select the option you need after compiling the list by adding a little jQuery.
A similar question has been asked on the jQuery Forums.
Using the example of:
<select name="options">
<option value="1">Red</option>
<option value="2">Green</option>
<option value="3">Blue</option>
</select>
You can set the selected option by value:
$('[name=options]').val( 3 ); // To select Blue
Or you can set the selected option using the text:
$('[name=options] option').filter(function() {
return ($(this).text() == 'Blue'); //To select Blue
}).prop('selected', true);
Links to jsFiddle can be found in this post.
Credit to: Godsbest on the jQuery Forums.
Yes.... there is a way to declare the default option in the select tag
Try this...
To set a default value first you have to mention the name of the select tag and in the find() function just pass the value you have to set as default value.
$('select[name="destination_path"]').find('option:contains("default")')
.attr("selected",true);
I have a <select> tag with various options, and I would like to know what determines what happens when the user starts typing.
Say I have a list like the following:
<select id="userlist">
<option value="nothing" selected="selected"></option>
<option value="AdamT">Adam T</option>
<option value="AidanC">Aidan C</option>
<option value="IanQ">Ian Q</option>
<option value="JamesR">James R</option>
</select>
Sometimes if I type A followed by I, I end up with Aidan C selected.
Other times, if I type just fractionally slower, I end up with Ian Q selected.
What determines what ends up being selected, and at what speed of typing? Is it browser-specific, or is it set in the HTML spec?
That is browser or OS specific, depending if the browser uses native or custom widgets, I think.
There is certainly nothing in the HTML spec about it.
The < select > is setup so that it performs a new autocomplete in about 1000 milisecond intervals between key presses. If you keep typing before the timer is up, it will continue the autocomplete with your current prefix. However, if you wait a second between key presses, it will start a new prefix, forgetting what you previously typed.