> Another approach - remove AlphaImageLoader filters from CSS, like so-
> #fancybox-loading.fancybox-ie div { background:
> url('fancy_loading.png') top left no-repeat; } and than apply any
> pngFix that uses AlphaImageLoader (you could even take pngFix script
> from older versions of fancybox).

> Janis

> On Mar 11, 1:14 pm, ";Op" <olivier.potonn...@gmail.com> wrote:

> > This is a *BLOCKING ISSUE* for me: I want to use fancybox in different
> > pages, at different directory levels. Of course I want to have a
> > single copy of fancybox installed, so I would like to refer its images
> > either relative to the fancybox installation (ie relative to the CSS
> > or JS files), or with an absolute path. But I work on different web
> > sites, and the root directory for static resources is different on
> > each of these sites. Furthermore, this root is different on
> > development and production servers. I'm doing the dev, but I don't
> > control production servers: I can't even know "a priori" the absolute
> > path on them...

> > As I understand it, there are 4 alternatives to solve the
> > AlphaImageLoader.src path issue:

> > 1. put fancybox images within the directory (or directory tree) of
> > each HTML page that uses it. But there are many (actually ALL pages!),
> > and this is very intrusive: I'll have fancybox files copied (or
> > linked) many times. This is both cumbersome to install and update.

> > 2. edit css to replace the relative path by absolute image path. But
> > this path will be different for all my different servers, and also for
> > dev and prod modes... And I don't know (and don't want to care about)
> > the absolute path on production servers.

> > 3. URL rewriting in .htaccess. I did not experience this method
> > mentionned by Roman, but I think it has the same defects as solution
> > 2, plus it is "apache" specific.

> > 4. Javascript in CSS: I've seenhttp://drupal.org/node/185866but
> > still did not experience it. It seems possible to provide
> > programatically (in javascript) the URL. This sounds interesting, and
> > could probably be included in fancybox itself: the path to look these
> > images into could be relative ("fancybox/" as it is today) by default,
> > but could be overridden with a configuration dependent path prefix
> > (usually an absolute one), which could itself by computed by another
> > mean (not a fancybox matter).

> > Does anyone have another solution to propose? Has anyone experimented
> > solution 4? Would fancybox team consider doing it?

> > Thanks for this nice library anyway