Bug in IE8: Overlay tiles are not transparent in IE8. Works fine in Chrome, Firefox and IE9.

[Nghi Nguyen]

Dear all,

Insert an ImageMapType to the map, its does not transparent in IE8 since April 27 2001.  (Don't use IE9 with IE8 comparable mode)



Please help investigate it.

Cheers,
Andy Nghi

[Nghi Nguyen]

See this url: http://phamnguyen.org/googlemap/IE8TransaparentNotWork.html

[James]

a couple of tests I did indecates:

 

1. IE8 does support the transparency of the png file

2.it does not seem to have 'isPng' parameter;

 

3. png file I generated seems to work fine:

 

[Nghi Nguyen]

Thanks James! Some comments inline:

1. IE8 does support the transparency of the png file

=> Agree, but when I use function map.overlayMapTypes.insertAt(0, myImageMapType); to add my image to the map, seem the api changed my image alpha value to 255.  

2. it does not seem to have 'isPng' parameter;
=> Yes, thanks. But it still not work if I remove this param.

 
3. png file I generated seems to work fine:

=> Its hard to check. Could you create an image with alpha value low enough. Its color should not be black or white also.

Thanks,
AndyNghi

[Nghi Nguyen]

Someone has the same problem with me: http://code.google.com/p/gmaps-api-issues/issues/detail?can=2&q=3275&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Stars%20ApiType%20Internal&id=3275 

[Kesuke]

I'm very glad this subject has come up again. From what I can see
there are TWO types of opacity and confusion is arising from what we
are all calling opacity;

1.) There is the files own opacity (alpha channel).
2.) There is the browsers opacity rendering.

In v3.3 google said they fixed IE opacity issues - but in my opinion
they actually broke it. They made it so the browsers opacity (2) works
but in doing so broke the files own alpha channel opacity (1). So now
if you have a PNG with alpha on it, you will get a dirty black noise
around the transparency. HOWEVER, you are able to set the image to
20/30/40% opacity etc. Personally I think thats a waste of time
because the images look so incredibly bad its pointless displaying
them at anything other than 0% opacity.

Try reverting your test document to v3.2 of the API and see if that
fixes the problem?

At any rate, its very irritating to keep seeings google response that
the problem is fixed when it clearly isn't.


On May 3, 1:18 pm, Nghi Nguyen <andyn...@gmail.com> wrote:
> Someone has the same problem with me:http://code.google.com/p/gmaps-api-issues/issues/detail?can=2&q=3275&...

[Chris Broadfoot]

Please file a bug on the issue tracker, and share the link.

http://code.google.com/p/gmaps-api-issues/issues/entry?template=Maps%20API%20v3%20-%20Bug

As always, the nightly version of the API should not be used in production sites. Specify v=3.3 when loading the API to get the stable version:

http://code.google.com/apis/maps/documentation/javascript/basics.html#Versioning

--
http://twitter.com/broady

[Nghi Nguyen]

Great advice, thank Kesuke and Chris! Stick to v=3.3 work fine.

[Kesuke]

I was playing around with opacity today and noticed there have been
some changes so my earlier post is incorrect for the current nightly
build version at least. It seems Google have actually addressed this
issue quite elegantly.

The problem they were having was, I suspect, that in IE7/8 you can't
have BOTH image (alpha channel) opacity AND browser level opacity
(e.g. 20%/30% opacity) applied to the same image. So they seem to have
adjusted it so now PNG files with alpha will appear properly provided
they are at 100% browser opacity. However, if you apply a browser
level opacity (e.g. 85%) to the tiles you will get artefacts around
the alpha parts of the image - which isn't googles fault, it's the
best that can be done with those versions of IE.

I take it all back, google have taken care of this nicely.

[Abed Islam]

I am getting this problem for IE7/8 albeit in IETester. I'm on Windows 7 with IE9. Once Google Maps loads any semi-transparent PNG-24 that was used as a repeating background all of the sudden became... strange, as if they were made almost completely transparent with a gradient slapped on them. Locking in on version 3.3 did not do it for me. I had to explicitly set the background to a PNG-24 whose dimensions were at least the size of the footer/header. This seems to have prevented the bug from triggering to begin with... Just posting here in case anyone else comes across the issue and that, well, this is still an issue.