What's the semantic difference between using a <select> element containing <option> children and, using an <input type="radio"> elements within a <fieldset> parent? Both methods offer the user to select at most one option. The only differences are visual and user-experience-related: the first method shows the user a drop-down menu while the other option shows radio buttons.
Equivalently, what's the difference between <select multiple=""> with <option> children (a select-multiple drop-down) and using <input type="checkbox"> (check boxes)? Again, I don't see any difference in function; only presentation.
I'm just wondering why the HTML spec has both methods for developers to use. If the only difference is in the presentation and in the user experience, shouldn't we only be using one method?
In general terminology there is no such particular difference between Radio Button and a Select List(Dropdown) but, since the screen space used is proportional to the number of options, if the number of options are between two to seven a web designer goes for using radio buttons, for eight or more options, he/she uses a drop-down list or single-selection list.
Another thing to keep in mind while designing is: If the default option is recommended for most users in most situations, radio buttons might draw more attention to the options than necessary.
Consider using a drop-down list if you don't want to draw attention to the options, or you don't want to encourage users to make changes. A drop-down list focuses on the current selection, whereas radio buttons emphasize all options equally.
The same follows for the checkbox and multiselect dropdown.
Related
I have 2 different form engines that share a common over-driven "Question" directive with different input types (select, calendar, multi-line, etc) based on a question type and then I want to display it in one engine like:
QuestionName InputField
and another
QuestionName
InputField
The goal is to share code with minimum duplication. Is there a good way to setup the html so it can switch back and forth or do I just move the InputField into it's own directive that can be placed twice in the question directive and show/hide as appropriate.
Thanks,
Scott
I decided on just creating an inner directive for the field portion displayed twice on the question directive using ng-if based on if it should be vertical or horizontal set at the form level.
<tr><td>questionname <span ng-if="direction==='vertical'><br /><field-directive /></span></td>
I have a tree of data organized like so (but with many many more options) in a dropdown list:
pizza
pizza.mediterranean
pizza.veggie
pizza.meatlover
drinks
drinks.soda
drinks.soda.pepsi
drinks.soda.coke
drinks.beer
drinks.water
I want the larger categories (pizza,drinks) to show up as optgroups but I want to be able to select an optgroup as an option in the drop down list. What I have read multiple places is that optgroups are only for grouping and can not be selected.
Since I also want more than one level of indentation to allow the dropdown to look as close to the above example as possible -- perhaps optgroups aren't the way to go but rather a css solution. In firefox I can do what I want by adding styles to the options and making them bold and/or have a left padding but it seems like in webkit the only attibute I can change on options in a dropdown is their color.
Does anyone know how I can achieve this effect in webkit (chrome/safari) and firefox --- (I don't really care about IE at the moment) using optgroups, css, or anything else?
You may just want to go low-tech:
<select>
<option>Root</option>
<option> Second level</option>
<option> Third level</option>
</select>
You are hitting the limits of what you can do with a real select. Conceptually, these select widgets are drawn by the OS (although some browsers - firefox - have their own implementations), so the styling options are limited.
There are many nice select replacements. The one I'm most familiar with is jqueryui's autocomplete. It is fast and flexible and you can style the options however you like. One can imagine other home-grown solutions using jquery or another toolkit - or plain 'ol javascript.
Using a set of radio buttons (or checkboxes, if several choices are to be allowed) instead of a select element, you can organize and style them like any other content, e.g. with indentation and bolding. It won’t act as a dropdown menu, though, but this can actually be a usability and accessibility improvement.
I have several Radio Button lists on my page, each lists items under different categories, so they are listed under different headings.
I only want one item to be selected across all the lists however.
Is it possible to "group" the lists so that the affectively behave as one RadioButton Lists?
I want to avoid using jQuery/Javascript if possible
Not using the standard ASP.Net radio button list control I believe. The best thing to do would be to render out your radio buttons one-by-one in their individual lists and of course, set the "name" property so they all belong to the same group.
You could also (depending on the structure of your data) just render all options in one radio button list control and then use the css nth child selectors to insert divs/line breaks/etc. But you would probably need jQuery for this unless your targeting only browsers that supports CSS3.
I'm talking about your standard:
<select>
<option>blah blah</option>
<option>blah bl</option>
</select>
my problem is, for the dataset I must include in this dropdown, I've got a few outliers:
That's a distribution graph of the total occurrences (y-axis) of all character counts (x-axis) for the strings in the dropdown.
The average is only ~18.5 characters, but accommodating the 101 char string forces me to use a really small font.
Is there a way to wrap text inside a <option></option> ? I tried just dropping a <br /> inside the middle of the string and that didn't validate.
In general, native <select> and <option> form controls offer very little control over how they can be styled, especially if cross-browser compatibility is a concern. If you want to be able to control things much better, your best bet is to have everything in a normal <select> box (for accessibility) and then to override it with a fake select box using JavaScript. I've had to do this in the past and the jQuery UI library worked well for me.
In your case, one possible UI that might would (if you go the JavaScript replace route) would be to use an ellipsis on the long elements, but then show their full text on mouseover and focus (it's early, so these might not be the correct events, but you get the idea).
Once you have JavaScript controlling a fake select box, there's really no end to what you can do for the UI behavior, but ultimately, if you need control, native form controls usually don't cut it.
Well, I curious as to the nature of Radio groups and dropdown lists in HTML. I have found that radio buttons are difficult to style but I would like to style my elements for required fields. I asked a previous question regarding styling radio buttons and giving a border color like you can do with text boxes, example:
<input type="text" style="border-color:#FF0000">
<input type="radio" style="border-color:#FF0000">
applying style to a radio button to change the border color does not work.
My Question is there any reason why I shouldnt use a drop down list insead of a radio group?
Drop down lists require more work (on the part of the user) to find out what options are available … and are as twiddly to style as radio buttons anyway.
You might try setting the border colour on the fieldset containing the radio group instead. Remember to also use some other method for indicating required fields though.
A radio group will take more room on your form than a drop down list, and of course the controls look different in appearance. My rule of thumb is if there are more than three or four choices, use a drop down list.
Majority of the users (includes mostly people with no computer background and elderly people) are really very familiar with radio buttons to answer questions of the type yes/no , male/female etc. For the convenience of the users use a radio button for such questions.
With Drop down lists the available options are not visible to the user until they interact (click it). With radio buttons all of the available options are in front of the user. While both allow you to limit the selection choices to just one option, I find that users can decide which option they want quicker with radio buttons. If it is more than 5 options though, I would reconsider.
Related question on ux.stackexchange.
Use a drop-down list for when one choice is regarded as "more important" and the alternatives are okay as being hidden from the user, for example, selecting a state in the U.S. A user lives in one state, and the alternative choices don't matter. When the user comes to the form item, they know exactly what to choose without looking at the alternatives.
On the other hand, use radio buttons for when the choices are all equally important, or the user needs to see all of them before making a selection, for example, rating on a scale from 1 to 5, or choosing an answer choice on a multiple-choice problem.
Another factor to take into account is screen real-estate: you wouldn't want radio buttons for selecting one of 50 states, and you probably wouldn't want a drop-down list for selecting a sex (Male or Female). Depending on your design and philosophy, this factor may or may not trump the factors stated above.