is there any reason why Internet Explorer (IE7 in my case) gets sluggish and eats up lots of CPU time when using the CSS :hover command or using onmouseover/onmouseout?
I'm really not doing anything complex, nor is my page particularly large.
When I move my mouse anywhere else on the page (where nothing is changing) iexplore.exe stays at 0%, but once I start moving across any element that has onmouseover/onmouseout or a CSS hover class attached to it, things get really slow and sluggish and CPU usage gets high.
The page works perfectly fine in Firefox, Chrome and Safari with not speed issues/sluggishness whatsoever.
Hints/Ideas?
Edit: The onmouseover/onmouseout is on <tr> tags (highlighting a row in a grid); the CSS:hover is used on <a> tags swapping a background-image url.
You need a non-flicker CSS rollover (which doesn't trigger continual 'hover' signals with every tiny mouse movement). Swapping images on hover generally doesn't work too well, especially in IE.
The best way to do this without a Javascript library is to have the desired 'hover' image as a background to the element beneath the one you're hovering over, and the non-hover image as a background to the element in front.
Then for the CSS :hover state of the element in front, set background-image: none; background-color: transparent; so that the desired 'hover' image in the underlying element is revealed.
Check the source code for this example non-flicker CSS rollover.
Depending on your markup, you may need to adjust the z-index value to get the top element 'in front' of the underlying one.
not doing anything complex
Well, what are you doing? I've seen this just from changing the background tr color. IE doesn't seem to be good at this.
Related
I've been unable to solve stuttering in Chrome/Opera when using transitions - e.g. opacity, transform, filter etc.
For simplicity, I will focus on opacity.
Live example here:
http://www.lydkontoret.dk/index.php?pgId=20&pgName=Lyd+%26+lys
When you click on one of the pictures below the banner, a large version is displayed. I do this by adding a fullscreen div on top of page to prevent access to page elements. The div is faded in via transition on opacity. On top of this div is added further divs that holds the image.
Notice the opacity transition for the fullscreen element when clicking on a picture. On a 24" monitor with browser window maximized, chrome/opera stutters like crazy, while firefox/msie/msedge is reasonably smooth.
To complicate matters, Chrome/Opera performs ok when browser window is smaller - as rendering engine apparently is able to cope.
I've tried using will-change and translateZ(0) on the various elements involved, but chrome just doesn't care (removing the banner helps a lot - as expected, because the rendering engine then has less to deal with).
Also it's mostly the fade in that stutters. When closing the image display, transition on fullscreen element back to fully transparent often looks acceptable.
I figure my coding is ok, as Firefox etc. do the various transitions nicely. So why the problem with the blink engine used by chrome and opera?
Any thoughts??
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 have a issue that text is pixelated when 2D scale of CSS transform is applied. (I only tested in Chrome. I'll do cross-browsing later, so you don't need to test it on different browsers.)
CSS
.versus_block_hover
{
-webkit-transform: scale(1.2,1.2)!important;
-webkit-transition: 50ms 0ms!important;
z-index:1100!important;
border-width:1px;
border-color:#000;
border-style:solid;
}
Javascript Code
$('.versus_block').hover(function() {
$(this).addClass('versus_block_hover');
$(this).parent().css('z-index','1100');
}, function() {
$(this).removeClass('versus_block_hover');
$(this).parent().css('z-index','0');
});
I know that Chrome uses bitmap operation during CSS transform for 3D acceleration.
However, when I tested it in jsfiddle, it wasn't pixelated. In face, it seems that Chrome re-draws a text when the transition is done.
See this working example. Hover over a box. (I put all CSS elements from my actual site.)
http://jsfiddle.net/eCkdE/11/
And, this is an actual site that has an issue. (Hover any of blocks, then you can see pixelated fonts when it's expanded)
http://jsfiddle.net/GJ7BM
Anyone has an idea how to fix it? It's okay that you can fix it on my jsfiddle directly.
The problem seems similar to this: http://code.google.com/p/chromium/issues/detail?id=119470
So what actually triggers the problem, is when the element is rendered as a comsposited layer on uneven coordinates. If you enable the Composited render layer borders option in chrome://flags you can see that in your first jsfiddle example the div becomes a composited layer while the transition is in progress, the text becomes blurry, once the transition is complete it's no longer composited, and the text becomes clear (see this modified fiddle where it's easier to spot the border: http://jsfiddle.net/kF2Q5/).
In your second jsfiddle example the text stays blurry even after the transition is complete because it's still an composited layer (on uneven coordinates presumably), this is caused by these lots of nested and underlayed transforms (an element that lies above a composited layer, becomes a composited layer too). See this modified fiddle: http://jsfiddle.net/PqPSU/ All transforms are being disabled using:
* {
-webkit-transform: translateX(0) !important;
}
So only the transform on the hovered element is left. If you have enabled the Composited render layer borders option, you should see that all the red/brown borders around the tiles, indicating composited layers should be gone. And you should see that the text becomes clear once the transition is complete, just like in your first example.
Unfortunately I have no solution for the underlying problem, ie the blurry rendering of composited layers, I guess it's something that cannot be solved on this end, but can only be fixed in the rendering engine and/or the graphics card driver, depending on where exactly the problem is caused.
You can adjust the text-rendering css property.
https://developer.mozilla.org/fr/docs/CSS/text-rendering
But your example works fine for me, check on another computer.
You should update your browser, or your graphic card drivers.
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)
I have a site where the background-image jumps up on hover state and I can't for the life of me find the specific css that does this.
I'm able to get to the "offending" link and give it a border and change the padding and margin. The problem is that firebug and chrome inspect does not show me what happens on the hover state.
So I want a way to see what additions to the normal css state happens on :hover.
Any pointers?
(P.S. IE 8 doesn't have this issue - ie no jumping of background image)
Try using the Inspect function in FireBug to focus in on the element in question. It will show you all related CSS, including any CSS that is related to :hover. You can also see in this way what changes happen to the elements CSS (and any other DOM attribute) when you hover your mouse.
In case the changes are coming from some JavaScript, try out the Visual Event bookmarklet. Activating it on the page will let you see all events that are tied to the element in question.