I've developed a plugin that makes characters jump and bounce when moused over in any element that contains text.
Here is an example.
It works great in Firefox 3.5, Chrome, Safari 3.1 and IE7 (oddly, but in compatibility mode) but in IE8 it seems the characters disappear as they rise. I've added top padding to the p element, because it looked like they were being hidden from something like overflow: hidden, but they appear to rise a bit and then completely disappear, only to reappear on their way down.
Does anyone know what may be causing this?
Thank you very much Stackers!
Setting a line-height should fix it.
Related
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I made a infinite carousel from scratch into a plugin with jquery. It works fine in Firefox but it works partially in Chrome, i.e. elements disappear as I slide the carousel.
Please view my codes here (it was too long to paste it): http://jsfiddle.net/HkTks/2/
Compare the carousel with Firefox and Chrome.
Why is Chrome behaving like that?
Many thanks​
Well, this may be a webkit bug. Looks like somehow the anchor element accidentally inherited absolute positioning rather than relative.
Seeing the style of .iconList a to include position: relative; and removing top:0 seemed to fix it for me.
Here's the updated fiddle: http://jsfiddle.net/HkTks/4/
I'm attempting to animate the slide-out of a menu with script. To do this, I need to animate the marginTop property of an element and increment it from -30px to 0px.
However, in IE8, the animation simply does nothing. I've traced this down to the fact that setting marginTop in script seems to have no effect. In Chrome and Firefox, this works fine.
Here's an example that will work with Chrome/Firefox, but not IE:
http://jsfiddle.net/rm58T/2/
Is this an IE bug, and if so, are there any workarounds for this behavior? Thanks!
Update:
Here's some screen shots of the bug.
In Chrome, my Fiddle looks like this (You can see the "Name of new menu" text, since we changed the margin with script)
In IE8/Vista, it looks like this. I can confirm in Developer Tools that topMargin is actually 0px as expected, however the elements were not re-drawn:
Another Update:
This bug repros (at least for me) on IE8 running on Windows 7, and also IE8 running on Windows 2008 Server. It does NOT repro for me on IE7 running on WinXP. I do not have any IE9 machines to test it.
Yet Another Update:
I found one potential work-around. If I set p.newmenu to position: absolute; instead of position: relative; then it works. However, in my case I'm hosting this entire thing in a popup menu and need this control to push out the bottom of the modal dialog, so absolutely positioning it is not an option. However, perhaps this knowledge can help in finding a workable solution. An example of this work around can be found here.
Would You Believe Another Update?:
I did find a workaround for now. If I use top: -30px; instead of a negative top margin, then everything works. top behaves a bit differently than a margin, though, and makes the UI not look quite as nice. In particular, when you use top: -30px, then you'll have 30px of whitespace under your element since relative positioning doesn't affect other page flow.
I'd greatly like to figure out why I can't use a negative top margin on IE like I can with other browsers, so I'm still hoping someone can provide an answer that will provide all the benefits of a negative top margin but also work with IE8.
The trigger for this behaviour is how IE8 handles the fieldset element.
You can work around it by setting the display for fieldset to inline (or inline-block).
div.modal.addmenu fieldset {
display: inline;
}
This isn't exactly a bug; it is just based on the fact that (to keep up in performance comparisons) IE was built since version 5.5 with a minimized preset of static definitions;
That means: Instead of spending any Element the whole and correct definition (depending on which god of specifications you hail out for ...) for the type it is, IE is using less.
TODO:
Give back what should be credited for acting as a top-model paragraph relatively positioned; DISPLAY it accordingly to its talents; any super-paragraph should do the catwalk inline, even if it is a block-head, you might try using sugar and whiplashes to remember your nasty P of its origin as a inline-block. It's a frenzy P, give some respect to its talents…
DOJO:
In fact, you as a rune-reading script-javalchemist be the one who has to have to take control over the brew the browser serves. Or it makes boom, silently ...
GODO:
Necessary things to do if you want to use negative-margins in browsers which don't play legally:
remember the elements you want to use of their display's origin; don't believe in browser-vendors that they would have done that already for you
IF you are just out for IE 7+ use display:inline-block;
IF you want to get negative-margins to effect on all notable browsers, but can forget about NS4, then use display:inline; or display:block;
Do not forget to build the foundation for your negative-margins: set position:relative;
MOJO:
If IE-Betas and older ones like 5.5 or 6 are in your point of interest, you have to ensure that your relative-positioned negative-margin paragraph has values for width and height; Depending on what you are trying to achieve, sometimes a height:auto; helps out.
Not even sure where to start with this one, but im hoping someone else has had this issue.
When using IE7 (not IE7 mode in IE9), all the styles seems to be dropped except for the background and all the text is shrunk to around 2px. So its just a page with all the images, text and inputs barfed into the page.
Here is an image:
Any Ideas as to what would cause this?
figured it out: for some reason I had zoom:1px; in my css reset.
Fixed!
If you take a look at this site
the site is displayed fine in IE, FF, Chrome, however, if you look at it with Safari, it hides the site? Can't quite seem to figure out what's tricking this?
Change the z-index of <div id="bg-box"></div> to negative value;Now it is z-index: 1; Turned it to z-index: -1.I think it may work.
Doesn't in my Safari (up-to-date, SL)
It does show for a split second. All the elements in your divs are still there. Play around with your sizing and positioning. I have a good feeling that is messing it up.
your bg-box class has a z-index of 1. Your other classes have no z-index. In Safari no z-index is less than a z-index of 1 (sometimes). Set your other top level divs to have a z-index of 2 and it all looks fine.