I've got a safari-specific problem with a hover effect:
When the user moves over a circle, another circle should appear over it (offset).
This works, but when the user moves his cursor off the circles, parts of the hover-circle still remain until the browser redraws the site (not sure if "redraw" is the right term) . You can do this with Cmd+A to select all text, for example. The hover--leftovers will disappear then.
I think an example shows it the best:
http://jsfiddle.net/L81h9hjr/3/
<div class="wrap">
<h1><span>Reply<span>Our services</span></span></h1>
</div>
The example works flawlessly in other browser I tested, so you need a Mac Safari (I tried 8.0.6).
This is a repaint/redraw issue with Safari / webkit (not sure why it's only on Safari and not Chrome).
I worked around this issue by attaching a jQuery event to the hover element that forced it's surrounding/parent elements to redraw (in my case, a hide() and then a show(0)).
$('.hover-element').on('mouseleave',function(){
$(this).parents(".containing-element").hide().show(0);
});
Make sure you use show(0) not just show(), for some reason plain old show() doesn't get fired without an animation argument.
Related
I am using bootstrap to develop a responsive website. I have tested it in Firefox, Chrome and IE where everything seems to be working, but the dropdown menu (in main menu) adds a offset to it self in Safari.
I checked the Safari inspector to see what went wrong, but the inspector seems to think that the dropdown menu is displayed correctly - even though it is not.
See http://birdatwork.com/stackoverflow/safari-bug.html for an example of what I am talking about.
The site can be seen at http://kik.vejnoe.orvad.net/en.
Hope you can help find out why it happens.
I have not found out why it happens, but I have found a solution. The solution is that I wrote some JavaScript that listens for clicks on menues and window resize events (only in Safari). Whenever one of these events happens the code will position the menu to the left by using the jQuery offset function.
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).
Recently I encountered a rendering issue in Webkit which I suspect to be a bug with the Webkit engine. But I am not confident enough to say so. So I would like ask here and see what you think.
It'd be a bit difficult for me to describe the case in plain text, so I prepared a snippet here:
http://jsfiddle.net/2eQXa/1/
First you can see a yellow background with red border. This is not a background of the <body> tag but a <div> with id "backdrop" which has 100% width and height. By default it links to the "backdrop-no-problem" class. Also there is a horizontal list with some images. The list is surrounded by a green border. Inside the list there are some Wikipedia logos wrapped with a dotted red border.
I tested the page with the following 3 devices:
1. Chrome 21 on Windows 7
2. Mobile safari on the first generation iPad (running iOS4, I'll call it iPad1)
3. Mobile safari on the "new" iPad (running iOS5, I'll call it iPad3)
Try clicking "right" or "left" to scroll the list. Pretty good.
To reproduce the my problem, first click on "Issue #1". This will change the backdrop div from "position:absolute" to "position:fixed". Then click "Issue #2". This will add "-webkit-backface-visibility: hidden;" to the element (The reason for adding this style is to ensure smooth animation on the iPad).
Now click "left/right" to scroll the list. You should see a strange behavior in all three browsers:
The green div is scrolling properly and smoothly, but not its child elements. The child elements simply "out-sync" with the position of the scrolling parent. The movement not only looks laggy, it sometimes even stuck. And the child elements will stop at a wrong position when the scrolling animation finishes. You have to move your mouse over the picture (or tap on it in a tablet) to trigger an update to have the element re-drawn at the right place. Even Chrome shows this weirdness makes me feel that it is a Webkit issue.
Things gone worse in iPad3. In iPad3 you don't need to add "-webkit-backface-visibility: hidden;" (Issue #2) to see this weird behavior. Just add "position:fixed" (Issue #1) will do. The strange thing is that this doesn't happen when you view the snippet in jsFiddle. In case you are interested I have put the source in a single file at pastebin:
http://pastebin.com/i4ARX4mD
When writing this question I saw quite a number of questions regarding backface visibility. I've checked some but none of them matches my problem.
Ideas or suggestions are welcome. Thanks!
(Post updated to fix many typos)
Please take a look at this code: http://jsfiddle.net/6JnJb/1/
My problem is that in chrome, the divs doesn't change their color if the mouse is over them, when scrolling. If I move the mouse over a div 'manually' (not when scrolling) than it changes it's color to red.
In Firefox it works perfect, but not in Chrome.
Can I solve this problem or simply this how Chrome works?
Chrome does not propagate mouseover events right away when scrolling. There really isn't any way around this issue, since it is giving priority to the scrolling event rather than the hover event on a particular element.
The behavior I see is that the hover effect doesn't move with the still mouse on scroll but catches up when the scroll speed is sufficiently low.