Slashdot Mirror

http://www.twinhelix.com/css/iepngfix/demo/ - but really, in most all cases the time for IE6 hacks is nearing an end.

I use PNGs quite frequently. I'd them for all my images if it weren't for the fact that JPEG is quite simply a better format for almost any time you don't need robust alpha-channel support.

The marginally reduced quality is more than made up for in greatly reduced file size.

There are perfectly functional methods for implementing PNG alpha channel support in IE6.

It's a shame that we have to use them, but they're there, and with IE's support for conditional comments, they don't hurt real browsers at all.

And just how many websites use transparent PNGs (let alone PNGs in general)?

Well, to start off, this website uses PNGs.

Transparent PNGs are AWESOME. They're they only way to overlay alpha graphics in web pages. They allow you to save time both in writing the page and loading it if you want to have a neat looking page.

Say you have a website with a repeating pattern for a background and you want a foreground image to perfectly blend in with that background. Without transparent PNGS, you can use GIFs--whose pixels can either be "opaque" or "transparent", no translucency allowed--or you can make a huge image with both the background pattern and the overlay image combined, which would take forever to load.

Not many websites use transparent PNGs as a direct result of IE6 not directly supporting them. There is no reason, other than IE6, that transparent PNGs are not more common.

On some of the pages I've made, I've gone through great lengths to make alpha PNGs work in IE6 because they are just that useful. Ironically, it was Apple who discovered the best way to fix PNGs in IE (using CSS and a .htc file), here is something based on that, which I use on most of my sites.

I haven't read the book myself, but well done on a coherent review that covers the resurgence of unobtrusive scripting. The author is quite well respected in the community, and I can only hope books like these begin to replace the "omg dhtml netscape 4!!11one" fare usually found on shelves.

I think AJAX et. al. could be a bit of a diversion though from the ideals of "unobtrusive scripting" though. Many sites using XMLHttpRequest and similar techniques aren't easy to degrade in older, non-JS-supporting browsers. GMail, for instance, had to write another whole separate version using plain HTML for legacy useragents; this seems a little beyond the "progressive enhancement" ideals in which JavaScript adds to, rather than replaces, essential page functionality. I'm putting together my own LGPL'd AJAX library that operates via plain HTML links and forms (and yes, those IFRAME hacks you speak of are really hard to get right!). So in theory it should degrade well.

And what the heck, while I'm self promoting, here's my free event manager script that works around IE memory leaks, as well as making the whole cross-browser-event-handling stuff easier (which is still the main annoyance when writing cross-browser code -- hurry up and implement DOM Events, MS!). Hope any other JS coders here find it useful.

I haven't read the book myself, but well done on a coherent review that covers the resurgence of unobtrusive scripting. The author is quite well respected in the community, and I can only hope books like these begin to replace the "omg dhtml netscape 4!!11one" fare usually found on shelves.

I think AJAX et. al. could be a bit of a diversion though from the ideals of "unobtrusive scripting" though. Many sites using XMLHttpRequest and similar techniques aren't easy to degrade in older, non-JS-supporting browsers. GMail, for instance, had to write another whole separate version using plain HTML for legacy useragents; this seems a little beyond the "progressive enhancement" ideals in which JavaScript adds to, rather than replaces, essential page functionality. I'm putting together my own LGPL'd AJAX library that operates via plain HTML links and forms (and yes, those IFRAME hacks you speak of are really hard to get right!). So in theory it should degrade well.

And what the heck, while I'm self promoting, here's my free event manager script that works around IE memory leaks, as well as making the whole cross-browser-event-handling stuff easier (which is still the main annoyance when writing cross-browser code -- hurry up and implement DOM Events, MS!). Hope any other JS coders here find it useful.

OK, so as sort of a meta-reply to all the posters asking about IE and PNG support, here's 2 interesting hacks you can use to get your PNG magic rolling in MSIE.

MSIE (as of v6) doesn't support 32 bit transparent PNGs natively, but there is a cool hack where you can dither them down to 8 bits, retaining translucenct for browsers that support it, and using 1-bit transparency in MSIE, so it still looks OK.

Alternatively, you can use the AlphaImageLoader() filter for near native IE PNG support -- that's a link to my own free CSS behavior that automatically adds IMG and background-image support for PNGs to MSIE 5.5+.

Either way, PNGs rock, except for the lack of a cross-platform gamma standard -- if you need to match other colours on your site, just use JPEGs/GIFs.

here's something that helped me with this recently:

Exactly.

I'm amazed that this even made Slashdot; Google often takes care to reduce the bandwidth usage of its pages (view source on google.com sometime....)

I do a fair amount of JS coding, and I've taken to distributing the majority of my scripts in two separate "commented" and "compressed" JS files for exactly that reason. My guess is that Google in fact has a fully commented and readable copy of their JavaScript code that they run through a preprocessor/compressor; I use my compressor (basically a hacked up bunch of Regexes) in that form. There are numerous other script processors out there too.

So in conclusion, this isn't really obfuscation (or at least not primarily obfuscation), just bandwidth saving. I'd be very suprised indeed to learn that they were dynamically generating JavaScript via Python (where did the submitter get that idea?). Writing a JS parser and compressor though is pretty simple regex work, and if you couple it together with a table of variable name replacements, you can easily autogenerate slimmed down script for the web.

Exactly.

I'm amazed that this even made Slashdot; Google often takes care to reduce the bandwidth usage of its pages (view source on google.com sometime....)

I do a fair amount of JS coding, and I've taken to distributing the majority of my scripts in two separate "commented" and "compressed" JS files for exactly that reason. My guess is that Google in fact has a fully commented and readable copy of their JavaScript code that they run through a preprocessor/compressor; I use my compressor (basically a hacked up bunch of Regexes) in that form. There are numerous other script processors out there too.

So in conclusion, this isn't really obfuscation (or at least not primarily obfuscation), just bandwidth saving. I'd be very suprised indeed to learn that they were dynamically generating JavaScript via Python (where did the submitter get that idea?). Writing a JS parser and compressor though is pretty simple regex work, and if you couple it together with a table of variable name replacements, you can easily autogenerate slimmed down script for the web.

Try this. I'm sure yahoo could change it into something more effective.

Dynamic HTML support.

Mozilla and IE offer a reasonably full DOM model of every loaded page. Every tag is represented in there, and essentially all atributes are categorised and changeable. Done in realtime, too -- have a look at the JavaScript Object Browser script on my homepage.

Opera's JS documentation, meanwhile, can be browsed in about 10 minutes. It has light JS 1.1 support -- not all properties implemented, compared to Mozilla's full JS 1.5. Its DOM is inferior in places to Netscape 4 -- as of v6, you cannot yet dynamically create positioned elements, clip content, or replace content of elements. It can't even run the above script I linked -- it doesn't even index its DOM properties correctly, so you can't say "tell me all properties of the 'window' object" like you can in every other browser.

Don't even get me started on how Opera Lies, pretending to be IE and making it an incredible pain to code in workarounds for its shortcomings.

So yes, Opera has blazingly fast HTML+CSS support, but it has sacrified good JavaScript and DHTML abilities to get it -- it's about 5 years behind the 8-ball, depending on how you want to count it.

I'd recommend Mozilla for the moment for most sites, hopefully Opera 7 will improve on this situation sometime -- the Opera developers have said DOM support is part of their eventual plans.

Yep, the two browsers are very much different between platforms. It's an incredible pain actually debugging DHTML scripts between the two, especially if you consider IE4/Mac which has more bugs than your average ant colony.

IE5 on the Mac runs its own rendering engine called "Tasman". In fact, IE5/Mac was the first commerical browser to introduce full CSS1 compliance, meaning things like first-line or -letter psuedo classes and full support for 'float' etc.

IE5.5 and IE6 on Windows are pretty similar. The big advance on Windows was from IE5->5.5 which included the new CSS filter syntax (for fancy transitions and fades, the "whizz-bang Windows features" that never made the Mac version), more CSS compliance and importantly not having to start a new copy of the rendering engine for every frame. That means you can float divs over IFrames, something that Mozilla can do as well. (Like I said, they like playing catchup :). IE6 doesn't have a lot that's too new underneath the UI, just a few more DOM properties here and there (like 'backCompat' and implementation details), about the only major new feature is the "Media Bar". A supply of bug fixes in the future is the main reason why I upgraded :).

If you're really interested load up the "JS Object Browser" script from my homepage in each of the various browsers to inspect the DOMs.

I have written a Hierarchial Menu script. And it took me quite a lot longer than 5 to 10 minutes.

Let me assure all the posters saying "I can do it in 30 seconds flat, it's just hiding DIVs" that menus like mine and HierMenus are quite a bit more than that. Yes, it's true that you *CAN* make a single-level popup where the triggers overlap the divs work in IE5+ and NS6 in a few minutes. But if you want multiple levels of autogenerating, correctly highlighting cascading menus working in as many browsers as possible, it's a decent coding effort.

You have to do everything 3 different ways for a start:

document.layers for NS4
document.all for IE4+
document.getElementById for IE5+ or NS6, Opera etc.

And that's just for getting references to page elements -- modifying them is another story entirely. Working around browser bugs takes anywhere from weeks to years -- I started the first version around Nov 2000, and am currently hacking away at the v5.1 script. Netscape 4 behaves differently with every different version, the platform of your computer, and it seems even the phase of the moon. Don't think about getting me started on IE on the Macintosh.

Check my homepage, and navigate in, it's called "Cascading Popup Menus". It works in Moz, NS4, IE4+ and Opera 5/6, Ihaven't tested Konq but I'd appreciate feedback. (End Shameless Promotion :)

For their price, it's probably pretty reasonable. Their menu is ~50k of JavaScript, mine is 12k but highly condensed. They used to give it away for free, as it was developed as a tutorial-like series of columns -- have a read through all the revisions before criticising Peter Belesis (the author).

- Angus.

My site opens external links in new windows. That's mostly because it uses DHTML pretty heavily as a presentation system, and standard navigation rules don't apply well... check it out, I'm giving away the scripts used.

But anyway, at least on my system, why not try dragging the link in question onto the browser address bar? That opens it up in the current window, no problems, no matter what collection of TARGETs or ONCLICKs the author has added to the A tag itself.