- Create Account

IEPNGFix v2.0 Alpha

Forums > IEPNGFix > IEPNGFix v2.0 Alpha > Page 1
Pages: 1 , 2 , 3 , 4 , 5 - Next > >
Author
Message

1) Angus Turnbull Group: Moderators
Posts: 4342 Joined: 7 Dec 2003 Location: New Zealand IP: 118.92.--.--
Alongside v1.0 Final, I've launched a complete rewrite of the script as v2.0 Alpha. See the project page:

http://www.twinhelix.com/css/iepngfix/ <-  Please link/bookmark here

for  details and a download. The main feature is a very popular request: CSS1 compatible background position and repeat!

UPDATE (17  July, 2008): v2.0 Alpha 2 uploaded with some fixes for simple errors.

Cheers - Angus.

2) Jean Group: Guests
IP: 84.30.--.--
How convenient that I was looking for exactly this fix just 5 minutes ago. Great work Angus, the web thanks you! :)

However...

I've got everything working with the v2.0 version when i'm NOT loading the js file. Of course the repeat BG's don't repeat, but that comes with the js. As soon as I activate the JS however, IE 6 just hangs. I see it loading a few images, it hangs again, when I RMB in the explorer bar I see another few being loaded right before it hangs again, and after that, nothing... It just hangs. I guess it has something to do with a neverending loop or something like that.

3) Jean Group: Guests
IP: 84.30.--.--
I just did some further testing and found a workaround, but no real solution:

The page works (altho I have to say it loads a bit slower now that the javascript kicks in) when NOT processing a 1x1 50% transperancy PNG image. I resized the image to 340x50 (the width of the div) and set the repeat to no-repeat and that did the trick. This gives you an image which would potentially be 100x the size so a fix would of course still be the best solution to this problem :)

4) Angus Turnbull Group: Moderators
Posts: 4342 Joined: 7 Dec 2003 Location: New Zealand IP: 202.137.--.--
Oh yes, of course! The v2.0 script will repeat the PNG image as many separate times as necessary to cover a background when in tiling mode (the .JS file is included, in other words). So a 1x1px IMG will be very slow indeed and there's no realy way around that :). There's 2 solutions, you have implemented both it appears:

1) If you specify "background: no-repeat", tiling will be disabled for that element.
2) Make the PNG bigger. Since PNGs are compressed there's not a large penalty here.

- Angus.

5) Jean Group: Guests
IP: 84.30.--.--
Thanks for the explanation, Angus.

I've gone with an acceptable middle way. I'm now using a conditional comment to only load the js and a seperate CSS file in IE 5.5 & 6.0. In the new CSS I added the htc inclusion and also changed big tiling bg's to load the full bg without a repeat.

This way the bigger bg's don't get processed by ths js while the small icons still are and people using FF/IE7 will never load the big backgrounds. Saves bandwidth but still ensures people get fast loading times in IE5.5/6.

Thanks again for this great tool, it saved me a lot of time :)

6) Ian Group: Guests
IP: 203.22.--.--
First off, nice work Angus! This is just what so many of us need.

I was having a look at this version for the background position support but ran into a bit of a snag. It seems for my site, background position wasn't supported with "no-repeat". It looks like the tileBG function takes care of both things, however this wasn't being called if repeat was set to "no-repeat". To get around this, I modified iepngfix.htc slightly.

This  works for me but may break in other circumstances.

Versions:
IE5.5+ PNG Alpha Fix v2.0beta1
IE5.5+ PNG Alpha Fix v2.0beta1: Background Tiling Support

From about line 125:

if (bgPNG)  {
if (
eCS.backgroundRepeat  != 'no-repeat' &&
this.tileBG &&  elm.firstChild
) {
this.tileBG(elm,  bgPNG[1]);
this.fix(elm, '', 1);
} else {
if  (data.tiles && data.tiles.src) {
this.tileBG(elm, '');
}
// Added the following 2 lines
this.tileBG(elm, bgPNG[1]);
this.fix(elm, '', 1);
// Following line commented out
//this.fix(elm, bgPNG[1], 1);
this.childFix(elm);
}
} else  {
if (data.tiles &&  data.tiles.src) {
this.tileBG(elm, '');
}
this.fix(elm, '');
}


7) Angus Turnbull Group: Moderators
Posts: 4342 Joined: 7 Dec 2003 Location: New Zealand IP: 118.92.--.--
Ah yeah, obvious problem there :). Forgot to test a non-repeating background with the final version of the HTC! The tiling code will obviously do single backgrounds. A simple fix would be to simply remove the line:

eCS.backgroundRepeat != 'no-repeat'  &&

from the conditional.

- Angus.

8) kerwin Group: Guests
IP: 87.212.--.--
Because this is an IE5/6 fix, can i simply use conditional statements in my <head> so only they will load the css and js?

9) Angus Turnbull Group: Moderators
Posts: 4342 Joined: 7 Dec 2003 Location: New Zealand IP: 118.92.--.--
You certainly can, and I recommend that you do! Other browsers won't download the HTC, but it'd speed things up to hide the .JS from them.

v2.0 Alpha 2 is now live with the fix posted above and a few other simple fixes too.

- Angus.

10) Schmoo Group: Guests
IP: 77.76.--.--
Fantastic work Angus, works a charm! Thanks!

Jean: Tiling a 1x1 image is one of those things you happily do for years before you realise it's a bad idea (I did too) - you'll always get a performance hit client-side, even if you don't notice it by itself. This fix was only amplifying the hit that's already there, as many other things can do also (hence avoiding small tiles even if by itself it's not a problem).

Tile a 1x1 image over an entire background, dump out a few pages worth of text on top and you'll get the jerky scrolling thing on any of the slower machines it's viewed on (same goes for too much embedded flash - blogs that embed YouTube videos in every post for instance). It would appear that browsers don't comp repeated graphics in memory, and each call is more overhead. If that's correct (and it may well be wrong, it's a working theory that fits the symptoms), then even using 10x10 would reduce the overhead 100-fold. At 340*50, you're making the browser display the 1x1 image 17,000 times - a 10x10 image would only need to be called 170 times. Those numbers seem to agree with my (very rough and fairly unobjective) testing.

I generally use around 100x100 which seems to do the trick nicely, leaves plenty of space for extra things that might slow a browser down (like this fix for example, or flash, embeds, heavy javascript, etc), and the extra bandwidth/download time is negligable in the bigger picture, IMHO.

11) Jasper Group: Guests
IP: 82.168.--.--
I love you guys :) No really, I do.

This is fabulous, perfect, brilliant and long awaited. VERY well done mates, thank you very much.

12) guest Group: Guests
IP: 87.167.--.--
Hi,

great work.

1x1 images: I remember i had massive performance problems some years ago when i tried to use a 2x2 gif as a background, where 2 pixels where coloured, 2 pixels transparent. The performance was awful. I think the reason is the same as with those small pngs. BTW: Only the IE had that massive problem, Firefox f.ex. not.

I remember i read somewhere that for tiling the optimal image size should pe a power of 2. So indeed using a 128x128 gif with 50% transparency did the trick. I'm not really sure that for the IE image sizes as power of 2 is necessary, maybe this was the solution for similar problems on other software, i don't remember. But it could not hurt to use either 128x128 or 256x256.

13) Rodrigo Cardoso Group: Guests
IP: 200.246.--.--
Well...

I think that 1x1 px pngs could be "repeated" using the "scale" method of AlphaImageLoader with no slows :D. Maybe the script could detect 1px images and do this "fix".

this  will also work for 1px width/height with fixed vertical/horizontal arbitrary size. I use this to simulate a vertical/horizontal gradient-repeat.


what  do you think?

PS:sorry for my poor english :P

14) guest Group: Guests
IP: 216.27.--.--
Are there any issues with IE6 requesting the htc file over and over because it fails to cache it?

15) Andy Matthews Group: Guests
IP: 209.194.--.--
The reason older browsers had problems with tiling smaller images was one of memory. The image itself might only be 4 pixels square, but it had to be drawn to the page thousands of times, versus a larger single image (say 100px square) which might only have to tile 30 or 40 times. I recall my first research into this back in '99, and with the smaller image you could literally see it drawing to the background line by line.

The difference in file size between the 2 images is negligible (1-2k), but the difference in performance is tremendous.
Pages: 1 , 2 , 3 , 4 , 5 - Next > >