The Imager Fader javascript seen at the URL above is working properly with IE6 AND NS6.22 but unfortunately not with Mozilla 1.0 RC2! :( Short description of this javascript: "When you mouse over an image, the image fades from partial transparency to fully opaque (solid)." (source: http://javascript-fx.com/navigation/index.html) It would be great to have it working in Mozilla 1.0 final version. Thank you!

Confirming with Mozilla trunk build 2002051408 WinNT, Linux OS: Win ---> All. It's strange: the mouseovers work the first time you load the site, but after that, they stop working. No errors in the JavaScript Console. Here is a sample of the code: http://www.javascript-fx.com/navigation/imagefader/javascript/JSFX_ImageFader.js JSFX.fadeUp = function(img, step) { if(img) { if(!step) step=JSFX.FadeImageAutoUp; if(img.fade == null) { img.fade = new Object(); img.fade.state = "OFF"; img.fade.upStep = step; img.fade.downStep = step; if(img.filters) img.fade.minOpacity = img.filters.alpha.opacity; else img.fade.minOpacity = JSFX.FadeImageMinOpacity; //img.fade.minOpacity = parseInt(img.style.MozOpacity); //Why doesn't this work? <---(COMMENT FROM SITE AUTHOR) img.fade.index = img.fade.minOpacity; } if(img.fade.state == "OFF") { img.fade.upStep = step; img.fade.state = "FADE_UP"; JSFX.startImageFading(); } else if( img.fade.state == "FADE_UP_DOWN" || img.fade.state == "FADE_DOWN") { img.fade.upStep = step; img.fade.state = "FADE_UP"; } } }

Note: when I say they "work" the first time: one can see a change in highlighting, but it is far inferior to what happens in IE6, where you get a gradual illumination that is much more impressive.

phil, why is this working in NS6.22 as intended and not in Mozilla. Does NS6 use a different JavaScript engine than Mozilla 1.0 RC2?

csab3063@uibk.ac.at: I'm not sure why the different versions behave differently. NS6.22 and Mozilla use the same JavaScript Engine. But this is not actually a bug in JavaScript Engine. JavaScript Engine deals with the abstract JavaScript programming language. Specifically, the low-level objects such as String(), Number(), and Date(). The JS Engine is not itself aware of browser or DOM objects like window, document, sockets, CSS, etc.

Note the key line below: JSFX.FadeImageAnimation = function() { JSFX.FadeImageRunning = false; for(i=0 ; i<document.images.length ; i++) { var img = document.images[i]; if(img.fade) { if(img.fade.state == "FADE_UP") { if(img.fade.index < 100) img.fade.index+=img.fade.upStep; else img.fade.index = 100; if(img.filters) img.filters.alpha.opacity = img.fade.index; else img.style.MozOpacity = img.fade.index + "%"; <<<<<<<<<<<<<<<<<<<<<< etc. In Mozilla, using Tools > Web Development > JavaScript Debugger, we can see that the indicated line gets set to values like these: img.style.MozOpacity = "50%"; img.style.MozOpacity = "60%"; img.style.MozOpacity = "70%"; However, only the first one seems to have any visual effect. The assignments to 60%,..., 100% look no different than 50%. Reassigning to DOM Style component -

This is probably related to bug 127435.

Possibly also related to bug 144832.

cc'ing folks from bug 144832 -

Yeah... %-opacity has some interesting issues. For one thing, it does not mean what the author of this JS thinks it means (and does not mean the same thing as the IE opacity values). The author _really_ wants the "number"-valued opacity, rather than percentage valued. For another, it's very slow (this is the main problem in this testcase and I'll be attaching a patch for that in a second)nly part of it). For a third, something has broken since NS 6.2 (and bug 144832 is certainly part of it).

Robert? David? What do you think? It feels hackish, but it helps enormously by preventing all those reframes (which are broken). This can still generate reframes where none are needed (eg a parent has opacity:0.5, a child has opacity:0.5 and then switches to opacity:100%; this will generate a reframe). But the incidence of these should be pretty low compared to what we have now.

http://www.w3.org/TR/2001/WD-css3-color-20010305 According to the W3C CSS3 working draft, percentage values will not be valid for opacity. We should ignore them. The Javascript given here is just wrong and should have no effect. The issues with transparent containers are complicated because we currently implement the wrong compositing model. Once this is fixed we WILL need a reframe for children going from 50% to 100% opacity.

@Robert O'Callahan might be that the given javascript is not 100% standard conform but it does work with IE6.x, NS6.x and even with the current NS 4.7x(!) So it would be nice to see it working in Moz 1.0 also. Btw I dont believe that Moz should be a browser for academic purpose only. Thanks a lot

It works in IE6 because it is coded to IE's proprietary opacity stuff. The code Mozilla and IE execute is completely different. It works in NS6 because it's using what is arguably a bug in the NS6 implementation of CSS3 opacity (possibly the draft had opacity defined differently when it was first implemented). Since IE6 and Mozilla don't run the same code here, the only two things that could guide any sort of decision here are backwards compatibility with NS6 and forward compatibility with the "opacity" property of CSS3.

I think that You should leave percent values of opacity. First reason is backward opacity. It would be horrible for all ppl who creates cross-browser libraries to add next possiblity for opacitying. Second reason is that, we dont loose anything leaving opacity. Why not? Mozilla uses other DOM than IE, shure, but why cannot hold the same values? I think that problem with conversing percent to float is academic. It's easy, fast and stable. We should fix other bugs with opacity which about i wroted in bug 144832 . And according to #13 . No, it's impossible that NS4 works with image fades. NS4 doesn't have any possiblity (excluding frame animation) to show image fade. Greets

lol. I mean "backward compability". Sorry...

It would be technically easy for us to support percentage values for opacity, but that would encourage people to write incorrect CSS which might not work in other browsers. We're not Microsoft and we want to encourage people to write correct CSS. That is why it is good to NOT support percentages. As for backwards compatibility --- hardly anyone is using Mozilla's opacity property (because it's broken in lots of ways) so I don't think we have to worry about being backward compatible with such code. IE's opacity mechanism is already totally different, we're not compatible with it, so I don't see any backward compatibility issue there either.

Humm... at all Your're right. If we're shure that every Mozilla's build supports float values, we can resign from '%'.

Mass-reassigning bugs to dom_bugs@netscape.com

WFM with Mozilla 20030321