Clicking directly under or above the text on this button fails to register as a click in Chrome/Safari (might take a couple tries to find the sweet spot, but it's consistent enough to be irritating). The :active CSS gets applied, so it's clearly a bug. Anyone have a workaround for this??
http://jsfiddle.net/BpR76/
This guy seems to have had the same problem but I don't agree with the answer - it's not a dragging issue.
Related
I have an html form in an iframe. In mobile safari, it's unbelievably fragile. Just focusing on an input will cause the whole frame to vanish. It seemed to be related to the automatic scrolling on entering an input, but I disabled this with a viewport tag, and I still have the problem. I've seen it come and go when a style had a height:100% rule, but now it's back to its bad old ways without the problem rule. The content is still there. Touching an invisible input will bring focus and the cursor, or pop the datepicker, but still invisible. Quick, someone, before I go nuts !
If this can be useful, I eventually traced this back to a loading animation implemented in css. Just the presence of the <div id="ajaxLoader"> in the page was enough to cause the instablility. Moral of the story: develop your mobile web apps with an iphone, because going back afterwards and making them work in safari may cost you your sanity.
I am creating a simple mobile app with Cordova. For good user experience I would like there to be instant feedback whenever a user presses a button. This should be accomplished with the :active pseudoclass. It mostly works, but it's not quite 'instant'.
See the jsbin here.
With desktop Chrome, clicking the button produces absolutely instant feedback, no question.
With Chrome for Android, tapping the button quickly feels pretty quick, but a slow tap or holding on the button causes a delay (it might be hard to notice, but it is there and it's bugging me).
I think this is something to do with scrolling. If you go to the Android settings, there is a scrolling list of options. These options seem to highlight with a similar delay. However, any native Android buttons which are not within a scrolling list are absolutely instant (for example, the back button in the top right, or save/cancel on a popup dialog).
Is there some way I can convince Chrome that these buttons are not on any kind of scrolling pane and should just be highlighted instantly?
This is probably unrelated, but I have also noticed that holding on an html button highlights it, but then moving your finger (still within the button) causes the highlight to disappear. This does not match the behaviour of native Android buttons, which would stay highlighted so long as you stay within the button.
Edit: I should add that -webkit-tap-highlight-color (which only works with cursor: pointer) is a bit faster than :active, but it's not an acceptable solution, for a few reasons:
The highlight disappears if you hold on the button for more than one second
It clashes with :active - to get sensible results with -webkit-tap-highlight-color you would have to remove :active, which makes no sense
There is no way to control the size/shape of the highlight, which might not match the actual button (sometimes it bleeds around the edge, or has mismatching rounded corners)
The correct HTML way of solving this is :active, and I would like to use that if at all possible.
It seems the best way to solve this is to listen for touch events and set a class:
$('button').on('touchstart', function(e){
$(this).addClass('active');
});
$('button').on('touchend', function(e){
$(this).removeClass('active');
});
To keep this as closely related to the :active pseudoclass, I opted to use a class of active and add styles for both like this:
button:active, button.active {
// active style
}
For more information, see: http://samcroft.co.uk/2012/alternative-to-webkit-tap-highlight-color-in-phonegap-apps/
In one application, called "scheduler", the user shall click on some buttons.
In chrome the rotation is executed as desired, but on Firefox, the button will rotate if the user moves the cursor at the center of the button.
The bad thing is that, the rotation starts and shall not be completed, if the user puts the cursor somewhere else in the button.
You can see it in action here.
It seems that the behaviour is affected heavily by which version of firefox one uses.
However, this "bug" of Firefox, in my opinion, made me remove the feature. If anything alternative has been found after so much time, it would be highly welcomed.
As NorthPole stated:
in firefox 26 it rotates whenever the cursor goes inside the button, same in chrome 30.
Demo
However, many users (included me) are using a version of firefox that suffer from this behaviour, so I just removed the feature.
Also, some mobile users were complaining heavily about that.
I have a bit of a IE8 problem (sound familiar?)
I have a button. when you hover over the button the hover state produces a larger box that has html inside. in this particular case, it's a small music player.
so it goes like this, when you hover over the button it produces a small music player with clickable links and some text. you can move your mouse anywhere inside this box, but as soon as you leave the box/music player, the hover state goes away again.
sorry but I don't know how else to explain it.
this all works a treat except for IE8.
in IE8, the hover state disappears as soon as the mouse leaves the original small button. so navigating around the music player becomes impossible.
now I have noticed that when there is no html in the hover box, it works fine, but when there is html (in this case an iframe) it loses the hover as soon as I touch any html inside the hovering box. so it looks like the problem is not the hover box, but the code inside the box that makes it lose focus
what I would like to know is, is this a known issue in IE8, or could it just be bad coding from my side. in which case i can post the css.
I've had problems with :HOVER states in IE8 too and I noticed that the same CSS (even pointing to the same external CSS file) worked on some pages but not others. The solution for me was to consistently add a DOCTYPE to the top of all pages (above the starting HTML tag).
It seems obvious now, but sometimes (especially when editing old sites) the DOCTYPE is not always specified.
I hope this helps!
Your problem doesn't seem to lie in hover itself. Firstly you assume some window height and your project just look weird if the height is different. Assuming you did some very exact calculations on such assumptions your problem is probably the box model problem. box-sizing:border-box might help, but you would have to recalculate everything.
Also you can use timeout before the elements gets hidden/drop down so that micro mouse movements don't shake elements and maybe allow to "catch" them.
Having both things in mind all hovering problems should be fixable.
EDIT: For iframe hover have a look at: Iframe hover not working in IE (all versions).
I'm trying to learn CSS. I've taken great pains to get everything right. My pages all validate and they look correct on Firefox and mostly correct on Chrome. However IE is all over the place. In relation to Firefox, the following is wrong in IE (in order of importance):
the main body box is pushed below where the left boxes end
the upper-right drop-down stuff (mouse over "Settings") is totally off in the weeds (it's off in Chrome also but in a different way)
"Recipes" tab is supposed to have no visible bottom border
search button is askew in relation to search box
logged out version: the upper-right login elements are askew
Logged in,
Logged out,
CSS,
Links, functionality, etc. are not guaranteed to work on these pages. It's just static snapshots to show layout.
Can anyone point me in the right direction for whatever I'm doing wrong?
You need to Reset your CSS (Dean, above recommends Eric Meyer's Reset CSS). I prefer Yui Reset CSS (I actually like their own Reset / Fonts / Grids CSS). As part of doing this you also need to use Standards Mode.
Finally, you need to be aware that some things will differ in browsers no matter what. So if you run into this situation, it's either work around it, or live with it.
What version of IE are you running? Sounds like most of your issues may be caused by the IE Box Model Bug.
I never start a new website design in css without putting Eric Meyer's Reset CSS in first.
It resets all the differences in all the browsers, so that you've got a even playing field to start from.
From there-out, everything should be the same in all browsers.