IE8 Standards mode: onclick handler on div does not fire - internet-explorer-8

In my application I have a row of buttons (for BBcode) that is included in various places. Each button is an empty div with fixed dimensions, a background image and an onclick handler. This has worked very well in all browsers - so far.
Now I have added one more instance of this row, but this time it is inside an absolutely positioned pop-up div. (At least that's the one notable difference that I can think of, because otherwise it's the exact same code.) This also works in all browsers except for IE8, where clicking the buttons does not do anything. Unless I switch on compatibility mode, in which case it works pretty much fine.
Isn't there any other way to make Internet Explorer behave like it should?

I had the same problem in IE8. The transparent areas in the DIVs were not clickable. An easy solution is to set the background-image to a transparent .gif.
My solution in CSS:
background-image: url("images/pixel.gif");
...where pixel.gif is a 1x1 transparent image.

I've found the solution. It was the "float:left" attribute on the buttons that made it fail.
Which is rather strange because in all the other places where this code was included, it also had the float - and it worked. Even in IE8.
Anyway, removing it and using "display:inline-block" for the placement did the trick.

Related

Button image not showing in IE7 with bootstrap

I have this problem in many places. Here is one:
<button type="button" name="remove_subnmc" class="btn"><img src="/static/img/delete.png"/></button>
The button simply appears as empty in IE7. It looks fine in all other browsers.
Without the class="btn" it looks even worse.
I'm using Django, but I don't think that's relevant so I haven't tagged it.
Setting the width of the button manually can fix this, even if you pick the exact width the button was already displayed at.
Interestingly, setting a min-width of at least the image size, on either the image or the button, while not changing the button at all, will fix this as well. Any smaller than that and the image is shrunken accordingly. In this case all of my buttons have 16px images and all of my buttons are at least this wide, so a general min-width applied to all of my buttons in IE7 is an acceptable solution.
However, if I wanted to add a wider button image in some cases I would need to make specific exceptions for that just for IE7, so if anyone knows a more elegant solution I would love to hear it.

IE8 Ignoring Background rules for Fancybox 2 ... Black background regardless of Fancybox CSS

I am using Fancybox v2.1.4 throughout a site with no problem, except in ie8 (even ie7 is ok). When I apply fancybox to a div in ie8, all background css is lost.
Here is what it is supposed to look like, and looks great in all browsers but ie8:
http://hallyb.com/images/good.jpg
And here is how it renders in ie8:
http://hallyb.com/images/bad.jpg
Nothing I change with the fancybox.css affects this black background; in fact, the background color is set to #fff first, with a background image added second Nothing about it says "black".
Thanks for any insight to this problem.
SOLVED!
This one was tricky because I am using PIE (http://css3pie.com) to wonderfully render css3 effects in older IE. For some reason, IE8 does not like it when the PIE.htc behavior file is called on nested elements, such as the fancybox 'wrap' code I am using here. IE7 doesn't seem to care. Remove the duplicate behavior attribute from the fancybox css and all is well.

Border-radius on an image with a border is different on Firefox and Chrome

This is best explained with images.
Firefox, right:
Chrome, wrong:
jsfiddle.
That is a (fully green) image with 2px (red) border and a border-radius of 6px. In my design, the border is barely visible, so the image looks completely square in Chrome.
Is it possible to achieve the correct result in Chrome without extra markup nor javascript?
I don't believe you can do this with Chrome. Images will extend over the bounds of border-radius, and I think that's the intended behavior (or else they just didn't notice).
When using a div, for example, you can see that the background behaves as it should. You could consider using a div instead of img, and using your source image as the background (and forcing its width and height).
Plainly said: In Chrome, there does not seem to be a way to force your image to be hidden by the border of itself (or even of its container) unless it is set as a background. In fact, the issue has been asked about before, and blogged about as well (and, in fact, patrickzdb's comment there may help you).
Apparently it is a bug in chrome..
I normally apply box-shadow for chrome instead of border.
so, if you don't mind to apply css hack to workaround it without javascript: http://jsfiddle.net/3cuHU/

How can I create a looping fade-in/out image effect using CSS 3 transitions?

I’m trying to create a looping fade in/out effect for an image. It’s working in Chrome, but it doesn’t work in Firefox.
Here’s the code: http://jsfiddle.net/FTLJA/254/
(I did make it work with jQuery but that made the browser slow and flickery on Android phones, so I’m trying CSS instead.)
Thanks for any help.
Update: fixed.. please check the link again
Well, if ypu're only setting the WebKit properties (only #-webkit-keyframes and only -webkit-animation-...), then of course it will work only in WebKit and not in Firefox - add them with -moz prefix as well. Also remove the quotes around 'blink' to leave it just... blink and it works http://jsfiddle.net/FTLJA/261/
Ah yes — this shows a difference between CSS transitions and CSS animations.
CSS animations run once you’ve applied -webkit-animation-name to an element, i.e. they can run entirely from CSS.
Transitions, on the other hand, only run when you change the CSS property that they apply to. You can either do this via CSS pseudo-classes like :hover, or via JavaScript.
So, in order to make your transition work in browsers that don’t support -webkit-animation, you’ll need to run some JavaScript that changes the opacity of the image once a second — setInterval is your friend here.
(Note that your JavaScript won’t carry out the animation, it’ll just switch opacity straight from 1 to 0 and back again every second. The CSS transition will animate this change for you.)

Safari changing font weights when unrelated animations are running

I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.

Resources