I don't know that Scroll Wheel is the right name for what I want, but I'll try to explain it.
On my I phone there are text boxes I can click on. Once you click on that box, you are presented with a scrollable list of items, for example numbers 1-10.
When you choose the number 1-10, either that value is placed in the text box and the list view is closed or you can "submit" that choice.
Is it possible to replicate this scrolling list of preset values in bootstrap? Ideally I want to have a list of times to choose from (1:00-1:30, 1:30-2:00) that an end user can scroll through on their phone and make a decision.
The answer to your question
Like others have mentioned in the comments, this is just how iOS renders <select> elements. Different browsers will render this differently, i.e. Android browsers come up with a slightly more conventional list, and desktop browsers will render it as a standard drop down list (albeit styled to fit with their UI, which can be frustrating).
Other things to be aware of
Bear in mind that if you try and override the default select elements with a plugin such as Chosen you will lose the various browsers default rendering of these elements, which can be one hell of a headache. There is also currently no easy way to detect whether your browser will render a select in a special way (such as the iOS style spinner) or use a dropdown, so its not like you can use something like Modernizr to apply your select plugin only when you're not using iOS/Android. If you want to do that you're in the murky world of user agent sniffing. (If anyone wants to correct me on this please do!)
Further reading
As a bit of an aside make sure you check out the new HTML5 input types. These provide things like native datepickers with no need for plugins (if the browser supports it) and many other types that have varying degrees of usefulness. For example, the type="tel" input is a nice one, that will render a normal text box in most desktop browsers, but on most phones/tablets/devices with virtual keyboards it will bring up a dial pad style keyboard, making it much easier for the suer to type in a phone number and giving them a strong indication of what you want. Just something that is very much worth thinking about if you are making forms for mobile and desktop, as it can make the mobile experience much more fluid. Browsers that don't support these elements will continue to render as they normally do as well, which is doubly nice. You can also use the likes of Modernizr to detect whether any of these input types are available to you, and do things differently. For example we have used Modernizr to detect if there is a native datepicker available, if there is, we just leave our <input type="datepicker/> alone, but if there is no datapicker we load in the jQuery datepicker, therefore making sure everyone has a datepicker.
This might be all obvious stuff to some of you but since this question had been pretty much answered in the comments I thought it would be useful to include some extra information about input types and different browsers rendering. If anyone wants to expand on my answer or correct anything (I'll be the first to admit to not being a complete expert on these things) please feel free.
Related
Sorry, this question might not be the best worded question, please feel free to advice if i should change (if i can change).
Background:
Different browsers/OS's render html differently, we all know this. One of the significant things is, how certain form tags work.
Eg.
<select>
<option>option 1</option>
</select>
In desktop browsers, we see a dropdown, but in ios/android, we see a OS level modal/popup.
Other obvious tags are, multiselect, and input type "date" (nice date selector pops up on ios/android as opposed to the desktop simple text field).
Question:
So as a html/js developer, is there any way to detect if the current browser renders these tags differently?
Eg. its in good practice to let users select date using the most native thing you can, however, its not nice to tell them to type it out. So if the os/browser has a pre-made modal for date, i want to show the native implementation, and if no such implementation exists, then display a custom date picker.
Sure i can use a library to differentiate ios/android/pc, but thats not exactly what im looking for. is there a way to actually check if the browser supports custom behaviour for these tags?
Recently I have received a project to make a webpage comply with WCAG 2.0 Level A. The part that I am running into a problem at the moment is the datepicker component. The datepicker component allows the user to select the date in two ways. One way is to manually type in a date, for example, 04/06/2014. The other way is to select the small image beside it and a calendar would basically pop-up and the user can select the date from there.
While researching over the web, some people have suggested that we do not have to make the image part of the datepicker component accessible since the text-field itself provides an alternative for accessibility. Is this acceptable (First Question)?
If this is the right way to go, how do I make it so that accessibility technology like screen reader would ignore the image icon (Second Question)? I have also tried to research for this issue. Basically, if it was just an image, we could set the "alt" attribute to null. But this image is actually embedded inside an "anchor" tag (which makes the image click-able) therefore this practice is invalid (verified by achecker.ca).
Update: HTML5 Accessibility: aria-hidden and role=”presentation” answers the second question
Any thoughts would be helpful. Thank you
The answer to the first question depends on what the usability reason is for showing a visual calendar? If you are showing it so that users can select a date based on use cases like "first Friday in Month X" or something similar, then simply providing a text input, while making the page at least usable, does not make the page functionally equivalent for screen reader and keyboard-only users and therefore does not pass WCAG 2.
Your answer to the second question that you posted, works for screen readers (in terms of removing the aforementioned functionality) but it now presents a problem to sighted keyboard-only users. You are therefore still not WCAG 2 compliant.
Making date pickers accessible, while difficult, is possible. Are you using the jQuery UI datepicker?
I've been looking around for a good back-end independent HTML/CSS/JS widget for many-to-many/has_many relations with XHR filtering and I can't seem to find any.
I find hard to believe people are constantly re-inventing this wheel.
What am I missing?
EDIT: Ok, from the number of people that didn't understand it, this was a crappy question.
I believe that regular web interactions should come at minimal cost (it should either already be in HTML or a package install away).
That's true for most cases. However, I'm having a hard time finding something for picking up an item from a collection (Not autocomplete, something more elaborate than merely a string. If you want an example, assume you want to pick users and have their avatar displayed while picking.).
Picture this:
When you want the user to provide
a short string in a form, you give them an input box
a long text in a form, you give them a text area
a piece of HTML (for a blog post's body, for example), you give them a text area with CKEditor or TinyMCE
pick something from a short list, you give them a drop down menu (like a select box)
a string based on a wide range of known alternatives, you give them an input box with autocomplete (jQuery UI Autocomplete, YUI Autocomplete, etc..)
a set of items from a wide range of options, you give them... drumroll...
I don't know! And that's my question. I've searched a bit and could only come up with jquery-tokeninput as a credible option.
Essentially the length of the HTML Select drop down is exceeding the screen on notebooks, I've checked and different browsers allow different amounts of options to be displayed before it turns it into a scrollbox. Is there any way of putting in a browser css hack or javascript action to stop it at 3 options? Failing that is there any way to limit the height of the drop down for the same effect?
I've googled up on this but with no such luck, no one seems to have had a problem with notebooks before. I know it's possible as on the Lloyds TSB personal login screen there is a select element which limits to about 3/4 options. As I say I don't mind using JS or even browser specific solutions as I've developed a notebook friendly way of doing it which is less intuitive and clunky looking but can be used as a default.
Any help would be greatly appreciated.
Rupert S.
Sadly, you can't change the item's that the dropdownlist displays, it is decided by the browser, with the size option it will loose its 'dropdownlist' form, and turn more into a list.
You could try finding some Jquery dropdown list, they are usually editable to whatever you want.
Hi I know its not a good idea but due to one use case I am populating a combo box with more 10000 items. Its behaving very weired in IE7 in all other browsers its working fine in IE7 its taking too much time for downloading the page. Sometime IE7 also hangs up
Is there any known bug with IE7 for this issue.
Thanks,
Amit
Not sure whether anything can be done to speed this up. One thing to look into would be loading the options dynamically through Ajax, and adding them as DOM nodes to the existing select element. That would at least allow the whole page to load before the rest of the data is fetched.
There are ready-made JS/jQuery-based Ajax combo boxes as well. One with a good loading strategy might yield better results.
I have no experience with them so I can't tell which one is suitable for you, but these seem worth checking out:
DHTMLXCombo (not free)
More in this question
I would suggest abandoning any attempt at having 10k entries in a single select box -- as others have said, it's a user interface nightmare, even if you can solve the problem with it killing the browser (which I don't think you can).
What to do instead?
Break the selection into categories. Then have one <select> box for the category, and have a second <select> get populated according to the category that is picked. This second <select> could be populated via Ajax or a page reload; both techniques are common. Given the quantity of options you want to provide, you may even want to break it down into category and sub-category.
The other alternative (which may be better, given the number of options you're providing) is to implement a Google-style auto-complete. There are a number of easy-to-use Javascript and JQuery scripts out there which allow you to implement this sort of thing without having to write it from scratch - it's almost as easy as writing the select box.
Here's one for you to try: http://docs.jquery.com/Plugins/autocomplete (but there are plenty of others if you google)
Hope that helps.