I'm using fastclick with my bootstrap 3 responsive web site to speed up the responsive time on mobile devices. Generally this works fine with no issues.
However after much testing I have found this breaks the bootstrap radio buttons on an iphone.
The buttons do work initially but if you change the selected option only the first selected options is passed when the form is submitted.
Removing fastclick stops this behavior.
Or more to the point on my minimal testing page adding fastclick will make the behavior occur.
This happens both in safari and chrome on iphone.
I have found articles saying that adding jquery-mobile and adjusting the markup of the radio buttons will also improve responsive times.
However I have using jquery-ui slider quite a bit in the site and adding in jquery mobile conflicts.
My aim was to disable fastclick on the radio buttons (via the 'needsclicks' class) and let jqmobile take care of it.
Much work as been gone into customising the slider for the site and to make it work and look nice on mobiles devices. I do not want to re engineer the entire site on the hope that adding in jqmobile will help. Nor do we have the time.
How can I solve this. I surprised that I cannot find any other data on using fastclick with bootstrap radio buttons. Sure I can disable the fastclick on the radio buttons but it makes them terrible to use and this is not acceptable for this application.
There is some way I can manually fix these radio buttons to work with iphone.
This is not an issues on Android.
Is there a fix I've not found?
Reproduced this issue also on ipad.
Problem: Fastclick triggers two click events: one for the label and one (bubbling) for the input:radio.
Solution: use 'needsclick' class on input:radio field. More info: https://github.com/ftlabs/fastclick#use-case-2-twitter-bootstrap-222-dropdowns
After some serious brain bending work I discovered that the cause of the issue would only happen after the radio was already selected. This was both by initially setting the radio button IE showing a form again with values pre selected. And when when an initial value is selected and the option is changed (another option selected that is different). This lead me to believe that the process that actually sets the value in the radio button is conflicting with fastclick.
What I did noticed is when no option is selected it would work perfectly. So after must testing with the iphone and added the following code on the touch event for each label. Basically this completely clears the radio buttons each time it is touched. Then it acts like each click of the radio button is pressed it like it first initial selection.
$( "#radio_button_label_id").bind( "touchend", function( e ){
resetRadio_radioid( );
})
function resetRadio_radioid( ){
var ids = array('radio_option_1_id', 'radio_option_2_id', 'radio_option_3_id');
for(i=0; i<ids.length;i++){
//clear all checked data
$('#'+ids[i]).prop('checked', false);
$('#'+ids[i]).removeAttr('checked');
}
return true;
}
This totally solved the issue.
Hope it helps.
Related
I'm part of a team building a mobile web app using AppGyver Steroids (PhoneGap). We are having an issue with the iOS7 keyboard displaying a very faint "Done" button on the keyboard when the user is operating in a text area or an input select. I suspect this is a problem that is actually global in our app, but these are the instances where I have observed them.
I've searched and searched for a solution or how to "customize" the keyboard in order to make this "Done" button more obvious, but I haven't found any solutions yet. Can anyone point me in the direction of how to adjust the "Done" button or any other keyboard/input controls?
Attached are two screenshots showing the issue.
http://i.stack.imgur.com/KeFYM.png
http://i.stack.imgur.com/h11IH.png
Have you seen the issue on github? It's now fixed. They'll be including the option for custom colours in the near future.
I been trying to debug a problem with some odd behaviour inside a UIWebView. My app uses a UIWebView to display a custom form to collect certain information. When the form is first loaded, filled and submitted, everything behaves as it should. After the first submit, when the form is reloaded, the keypad will not display (but the content scrolls as though it is).
The only solution I have come across is here, but this does not seem like the solution to my problem since that line is already in my app delegate.
Is this a known issue? I don't even know where to start looking to debug this issues.
After much searching SO and Apple forums, it was the view hierarchy that was getting rearranged. In my particular case, a progress indicator was being added as new window (by a coworker, so I can blame someone else for this). The trick was not set this new as the key window and only manipulate the the hidden properties
This is just a quick fix because it was only one line of code that was causing this major problem.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/
I'm experimenting with ways to have tooltips work across a variety of mobile devices. Unfortunately, the span of devices I need to support ranges from Nokias to iPhones.
Unfortunately, some of the browsers I'm dealing with don't support the use of the title attribute for tooltips on focus. As such, I need to come up with a different solution.
For starters, I'm playing with pure-css tooltips: http://psacake.com/web/jl.asp
This method uses the :hover pseudo class to position and set the z-index of a SPAN to create the tooltip.
On an iPhone, this produced an odd side effect. Tapping the link once exposes the tooltip require a second tap to actually activate the link.
However, applying a simple style to a different link's :hover pseudo-class (changing the background color) does not have the same effect. One tap triggers both the style and the link (you see the :hover style briefly before the next page loads).
I've solved this issue for mobile devices by switching to using the :focus pseudo-class which appears to not be triggered by the iPhone (and the Nokia touch device I am using). Of course, that's not ideal if this app were to be used on a desktop browser as well.
So...the question: Is there documented logic as to when the iPhone Safari browser decides to interrupt a click event on a link to expose the :hover pseudo-class vs. not interrupting and letting the link be triggered on the first tap?
I was trying to find you a link in Apple's documentation, but the most specific I could find about :hover was that it is emulated and can cause unexpected results. I did find one place that said it is only shown if the user taps and holds the object. That page (near the bottom, "Don't Use Unsupported iOS Technologies") also says that normal tooltips (using the title attribute) would be shown when that happens also.
If you will accept an assumption as to why the behavior is different for changing the style and displaying a tooltip, I would guess that it is similar to the way mousemove events are handled. This Handling Events page says that, if the contents of the page change during a mousemove event, the rest of the events in the chain (including mouseup) are not sent. I am assuming that this behavior also applies to :hover. If you are using display: none to hide the tooltip, you could try using visibility: hidden instead as it is interpretted as "the object is still here, but you can't see it."
I have a view with a toolbar - each button on the toolbar represents a new message the user is composing. It took me several work days to figure out how to handle the view switching, etc.. but now that I have that all figured out, I have run into a bit of a UI-snafu.
When I have over 11 buttons (I know, a user should really SEND the first 10 before creating an 11th, but I am trying to be thorough) the buttons run off the end of the screen. There is no indicator (aside from the half-button you can see), that there are additional button(s) that can be pressed.
Has anyone run into a situation like this before, and how have you handled it?
My initial thought is when there are more than (lets say) 8 buttons, I programmatically make the first and last buttons "<" and ">" buttons that will slide the buttons down, by removing and adding buttons to my [toolbar items].
Any thoughts?
Instead of creating a new type of UI for the iPhone (which Apple may or may not accept) it would probably be best if you just told the user that he/she has reached the limit and will have to send a message before they can create a new one. Like Safari does when you try to open a 10th webpage.
I think Kane is probably correct, but what you're trying to do sounds a lot like a scrollable tab bar. Three20 offers a class that handles this, or you could implement it yourself. There's no provision for this in the OS (I think the UI guys would probably strongly object if you said you were trying to put 10 buttons down there, let alone MORE than 10.)