Supporting internet explorer 6 is still a reality. According to Upsdell.com's multi-source stats IE6 still has a 29% market share. Currently there is no universal PNG fix solution in Drupal. Leaving module/theme devs to find methods separately. This may possibly stipend the use of theming/implementing images with alpha-transparent PNG's.

Today, themes and modules which utilizes (or want to) images with PNG alpha transparency have to include there own. Drupal contributer Rob Loach's pngfix has been used by me a lot w/ good results.

Application's range from theme logo's to the icon module.

I think it's feasible to attach a javascript like pngfix and create a system-wide class for transparent PNG's. Is there any caveats with including a tiny PNGfix along w/ Drupal? In /misc for instance?

Comments

dvessel’s picture

dvessel commented

Although we try to account for quirks in IE6, I draw the line on this one. The png fix has issues of it's own like cropping vs. scale for bg png's and it's inability to position them. Links going dead when they are layered on top of processed png's. Also, the general slowness if they are not targeting correctly. There are more issues I can't think of off the top of my head.

If the PNG fixes were more reliable, I'd want the fix but the potential problems and considering how old it is, it's not worth it. IE8 will be out pretty soon. Time to move on. PNG fixes are documented and out there. If someone needs them, they can research and get a clear understanding of the shortcomings and apply them.

Getting them for free may cause more problems then it solves.

tonyn’s picture

tonyn commented

Hi, I kind of want to keep this going a bit more because I may have some good reasons. I am proposing this because this is big enough of a compatibility issue to be givin as a choice the themer's and webmaster's on a standard drupal installation/distribution.

I believe the convenience of having pngfix available easily, there, and for use by themer's saves headaches of including it seperately. Themer's would know when to use it, as they're likely familiar with it (they could have the choice to wrap their theme $logo in a pngfix class), and webmaster's can opt-out/opt-in through a theme setting (something that could be toggled).

Can you please go into some detail on the cropping/scale issue? How could it conflict with pngfix when used for it's common purpose (in a theme's logo or icon for instance).

If we can get 95% of the png / alpha transparencies covered, we did people a favor. As in all cases, more complicated instances will require people to use customized code.

As you said, pngfix is well-documented and available. A theme-maker or module coder would likely know if their PNGFix would have those conflicts. Correct? If his theme were to have the link bug, he would find a way to handle it without using pngfix at all.

I'm not suggesting a scattershot approach -- but perhaps a class in Drupal that's available when an IE6 user loads the page.

Almost every theme I know uses a logo image. An excellent examples would be wrapping the pngfix around theme logo's. We're creating compatibility.

Why not have a part of Drupal's site configuration on whether to apply the pngfix? It's application is important to every webmaster + themer. Or, Why not have an option available on a per-theme basis on whether to include pngfix?

It does not have to be used in 27 times in a single page -- but having a small fix like pngfix available for modest, universal, common use by themer's in things like logos, is that simple enough? It's supposed to be a tiny patch that can pack an extra punch if someone chooses to.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Status: Active » Closed (won't fix)

It looks like there are lots of issues sitting in pngfix's queue: http://drupal.org/project/issues/pngfix. Including one that says “even the demo page crashes my IE6”. I would not want to move those issues to core's queue if we added a pngfix to core. :-p

I use a pngfix script (not the jquery one) all the time. And you have to be really careful when apply one of these to a page. It has severe limitations of usage and can very easily screw things up; we should not be devoting resources to explaining to everyone how to use it properly.

Sorry, Tony. This should remain in contrib.

mrjeeves’s picture

mrjeeves commented
Status: Closed (won't fix) » Postponed (maintainer needs more info)

I've recently released a module that addresses the issues listed here, please review and let me know if this is more along the lines of what you are looking for. PNG Behave!

As far as targeting goes, I've been working on an idea to provide a set of php, css, js, and admin/settings based 'hooks' to allow for modules/themes/users to request specific image fixing at any level of the processing. As I do not think it should be the responsibility of the module/theme developer to include compatibility, I have been working on solutions that allow for more of a registry of selectors. something that could easily be filtered based on displayed elements. if that makes any sense. (also, if i'm hijacking this thread, please point me in the right direction.)

naheemsays’s picture

naheemsays commented
Title: PNG Fix » PNG Fix (and other [IE6] compatibility fixes?)
Status: Postponed (maintainer needs more info) » Active

from #377204: new forum icons display in IE6:

I wrote:

Could an alternative would be to get an iefix (ie from either pngfix or pngbehave module) file into core which forced the proper transparencies to work?

I would consider it a core infrastructure issue to provide a path to fix ALL pngs instead of just fixing a few of them.

to which webchick replied:

@nbz: We should probably look into that. Want to start another issue if one doesn't already exist?

I think this needs a larger discussion on the overall landscape and not just to fix transparent pngs.

In my opinion it is the job of the CMS framework to provide as level a playing field as possible and to provide compatibility fixes for lesser browsers where possible.

Another issue we may want to add compatibility for is the css hover properties - they are incomplete/broken in IE6. There are a few csshover.htc files online - http://www.xs4all.nl/~peterned/csshover.html being one that seems to be complete and with a compatble licence (LGPL 2.1 so it can be taken as GPL 2 only if need be)

naheemsays’s picture

naheemsays commented
Title: PNG Fix (and other [IE6] compatibility fixes?) » Fix PNG transparencies for IE6 (and other compatibility fixes too?)
naheemsays’s picture

naheemsays commented

Just as a matter of noting it down, I have release the css :hover module with the above mentioned file in it: http://drupal.org/project/csshover

robloach’s picture

robloach
he/him
commented
Status: Active » Closed (works as designed)

This shouldn't be part of core. If you want PNG transparencies for IE6 then I suggest you look at some other contributed module like http://www.drupal.org/project/pngbehave .

naheemsays’s picture

naheemsays commented

I disagree witht that as core IMO should be helping users/developers cover the bases - make sure the framework is there to build on.

pngfix (and the other module I created - for css hovers) allow that and stop theme developers having to worry about what modules are installed. A theme should not have to care about what modules are installed.

I would argue that the current way is not "by design" even if it might be a wont fix. Drupal is a CMS and a framework to let people build sites. Asking all themes to fix teh same bugs in not efficient when it can be done centrally.

Further, this is not only about themes - people can embed content inside nodes and that is not always the domain of the theme layer. The whole point behind drupal is to make people's lives easier when building websites.

naheemsays’s picture

naheemsays commented

I must add here that this is not just about contributed modules - even drupal core itself has had to work around the problem of transparencies not working well in IE6 and having a proper fix in core will give more freedom to drupal core too.

(yes, I am really unhappy about the idea that core will not provide compatibility quick fixes which fit there instead of contrib.)