Fancybox uses AlphaImageLoader for IE. AlphaImageLoader expects image paths to be relative to the HTML document, while CSS expects image paths to be relative to style sheet files. This causes a problem in certain environments (e.g. when a framework being used reroutes requests) -- the close button and gallery navigation buttons aren't displayed in IE. I've solved this problem by URL rewriting in .htaccess file, but I wish I didn't have to do this.
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 seen http://drupal.org/node/185866 but 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?
The most simple solution would be to set full path as ... AlphaImageLoader(src='http://yourdomain.com/js/fancybox/ fancy_loading.png' ....
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?
I've read that some people experienced problems with png fixes (I think they complained about performance problem in IE... and maybe layout or clicking on links problems... I don't remember exactly). Is there a version that is problem-free?
On Mar 11, 7:33 am, Janis <janis.skarne...@gmail.com> wrote:
> The most simple solution would be to set full path as ... > AlphaImageLoader(src='http://yourdomain.com/js/fancybox/ > fancy_loading.png' ....
> 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).
> I had the same problem and solved it by adjusting paths in the > section /* IE */ which is in the most bottom of the > jquery.fancybox-1.3.1.css file.
Janis: thanks for your answer. Updating to absolute path is actually the temporary fix I use. I second Roman's request for a reference to a *good* png fix script.
On Mar 11, 1:33 pm, Janis <janis.skarne...@gmail.com> wrote:
> The most simple solution would be to set full path as ... > AlphaImageLoader(src='http://yourdomain.com/js/fancybox/ > fancy_loading.png' ....
> 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?
I just ran into this issue as well. I noticed what was going on after seeing 404's in Fiddler.
I'm using Fancybox 1.3.1 in Drupal using the Fancybox module.
Anyway, I've updated the CSS and everything is great.
My only concern, from a Drupal module perspective, is that a user can not just install a module, unpack Fancybox into /sites/all/libraries and off they go. They will always have to make a change.
Ugh, IE6!!!
-- Jason
On Mar 15, 7:03 am, ";Op" <olivier.potonn...@gmail.com> wrote:
> Janis: thanks for your answer. Updating to absolute path is actually > the temporary fix I use. I second Roman's request for a reference to a > *good* png fix script.
> On Mar 11, 1:33 pm, Janis <janis.skarne...@gmail.com> wrote:
> > The most simple solution would be to set full path as ... > > AlphaImageLoader(src='http://yourdomain.com/js/fancybox/ > > fancy_loading.png' ....
> > 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?
Since IE filters use page as a reference in SRC and the plugin/file (in WordPress & Drupal) can be in different folders, we need to extract base url from the CSS file (jquery.fancybox-1.3.1.css). A bit tricky, but IE behavior solves this problem.
It will loop all link tags until it finds jquery.fancybox-1.3.1.css and ignores '?foo=bar' from that css file and then returns the proper path to that css file. In my example I'm keeping my css files in css - folder and all the images in images/fancybox -folder.
Hope this helps to solve WordPress & Drupal problems.
I tried using Fancybox 1.3.1 in Magento and had the same problems.
Jani's behaviour fix didn't work for me. So I downgraded to 1.2.6 and it worked straight away. It seems the PNG AlphaImageLoader for IE is a waste of time.
I think the reason why it didn't work for you was due to those dots in the filename. Use "jquery\\.fancybox-1\\.3\\.1\\.css" instead of "jquery.fancybox-1.3.1\\.css".
-Jani
On Mar 23, 7:58 pm, Ade <adriandh...@googlemail.com> wrote:
> I tried using Fancybox 1.3.1 in Magento and had the same problems.
> Jani's behaviour fix didn't work for me. So I downgraded to 1.2.6 and > it worked straight away. It seems the PNG AlphaImageLoader for IE is a > waste of time.
> Fancybox uses AlphaImageLoader for IE. AlphaImageLoader expects image > paths to be relative to the HTML document, while CSS expects image > paths to be relative to style sheet files. This causes a problem in > certain environments (e.g. when a framework being used reroutes > requests) -- the close button and gallery navigation buttons aren't > displayed in IE. I've solved this problem by URL rewriting > in .htaccess file, but I wish I didn't have to do this.
The solution that I finally adopted is to move the AlphaImageLoader CSS definitions from the static CSS file to a dynamically generated part of the page, where the images' absolute path is computed on each request according to the context.
-- You received this message because you are subscribed to the Google Groups "fancybox" group.
To post to this group, send email to fancybox@googlegroups.com.
To unsubscribe from this group, send email to fancybox+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fancybox?hl=en.
My fancybox folder is within a folder called "js". I've tried changing
the CSS file to contain both correct relative and absolute paths, but
it doesn't seem to have any effect - the buttons still don't work in
IE. Not only are the images gone, but there's no clickable areas at
all, which I thought was odd. Would really AlphaImageLoader make the
entire <a>s disappear?
> --
> You received this message because you are subscribed to the Google Groups "fancybox" group.
> To post to this group, send email to fancybox@googlegroups.com.
> To unsubscribe from this group, send email to fancybox+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/fancybox?hl=en.
Why does this alphaloader stuff count for all IE versions? I never had
transparency problems in IE8 and even in IE7.
I guess the CSS should be splitted into 2 css files: 1 regular without
the alphaloader stuff and additional stuff for old IE. Put it on the
list for the next release.
In my case it works like this:
1) I use TYPO3 CMS, in which I have a file server and setup options to
define file.css calls in the header
2) I use the Fancybox files, put them on the fileserver (but unpacking
a Fancybox module would also be possible if your CMS works that way)
3) in TYPO3 setup, I can define a condition for IE6 and add the
additional css stuff
Bingo!
On Jul 5, 5:03 pm, Stefan KRUGER <rds.workm...@gmail.com> wrote:
> Why does this alphaloader stuff count for all IE versions? I never had
> transparency problems in IE8 and even in IE7.
> I guess the CSS should be splitted into 2 css files: 1 regular without
> the alphaloader stuff and additional stuff for old IE. Put it on the
> list for the next release.
> In my case it works like this:
> 1) I use TYPO3 CMS, in which I have a file server and setup options to
> define file.css calls in the header
> 2) I use the Fancybox files, put them on the fileserver (but unpacking
> a Fancybox module would also be possible if your CMS works that way)
> 3) in TYPO3 setup, I can define a condition for IE6 and add the
> additional css stuff
> Bingo!
> On Jul 5, 5:03 pm, Stefan KRUGER <rds.workm...@gmail.com> wrote:
> > have you checked ZiTAL's post ?
> > I had the problem and this was the best solution.
> > On 30 juin, 17:00, Aaron <purebl...@gmail.com> wrote:
I tried to use fancybox within an oxid eshop.
All Paths i specified for ie didnt work out - i guess due to the
htaccess rewrite.
The loading image was displayed, but the close and the arrow images
didnt appear.
I did some testings with the IE Developer Toolbar and came to the
strange conclusion,
that after removing "background: transparent;" for the "/* IE */" css
definitions all icons displayed correctly in ie 6 -8.
Here is a little jQuery fix a colleague and I whipped up. It will
dynamically change the PNG path to the current host at runtime. You
may need to change the value of "needle" for your setup.
// UTILITY FUNCTION
function getFullHost() {
var full = window.location.toString();
return full.substring(0, full.lastIndexOf("/"));
}
// FIX
$document.ready(function(){
// IE CLOSE PNG PATH FIX
var needle = "/js/fancybox/fancy_close.png";
var curFilter = $(".fancybox-ie #fancybox-close").css("filter");
