modified prototype js that respects your opacity settings

hi guys,

now, I’m a prototype guy, I can do jquery, but I find it easier to build apps and OOP structures using prototype, but one of the things that annoys me about it is that sometimes it doesnt respect my authority!

say you have an element in your page you want to fade in and out with opacity settings, normally, in my code, I set display: none, then I set opacity: 0 and when I want to fade it in, I have a little reusable function that uses prototypes setOpacity() method to abstract the differences between how IE and firefox do things.

but the problem with setOpacity is that when opacity reaches 1, or 100 in IE, the method removes the opacity attribute by setting opacity:”” which basically removes the attribute, the reason this is done is because in IE, the cleartype font rendering hates opacity settings and when you fade in an element using a interval based animation, the font type screws up and looks ugly. in all the other browsers it’s fine, just IE.

so whilst your transition fade is happening, you’re fonts look ugly, the answer therefore is to not use the attribute, but well, not much choice if you want to fade something in, so their answer at prototype was to remove the attribute when the element was faded into view, because they view opacity:”” as the same as opacity:1 but opacity:1 has font rendering issues, but opacity:”” basically removes the opacity settings and then that means the element is displayed perfectly opaquely.

The problem with this, is that if you have in your stylesheet opacity:0 for example, in firefox, when you reach opacity:1, your element disappears, because setOpacity then does opacity:”” which mean it’ll default back to your stylesheet, opacity:0

Their answer was kinda obvious dont put opacit settings in the stylesheet.  So basically I have to find another way of doing things just because of what happens when they handle setOpacity(1), which to me, is stupid.

The answer that I came up with was an extra parameter which when set to a true value, would mean that setOpacity(1) would result in opacity:1 and not opacity:”” and false would do the status quo.

setOpacity(1) -> opacity:””

setOpacity(1,true) -> opacity: 1

to me, it’s my decision wheteher I want to live with crappy font rendering or not, I prefer to let IE users have crappy fonts than cramp my development style working around bugs in prototype.

So I created a patch and uploaded it onto their lighthouse development system, it got rejected, or forgotten about, or whatever.

But if you, like me, want that setOpacity(1) means opacity:1, then you can download the file I have attached below because it is a modified version of prototype 1.6.1 with the modifications I made against for the new force attribute.

Enjoy and please let me know if you think this is a good idea or a bad idea!

prototype.js 1.6.1 w/setOpacity modifications

UPDATE (2/8/2010): I had a better idea, rather than modify the prototype source code, I realised that I was being a bit stupid, I could use prototypes addMethods to overwrite the base methods with versions which I think are better and easier to use, and solve some common programming problems that prototype causes with it’s “policy invasion”


2 thoughts on “modified prototype js that respects your opacity settings”

  1. Chris,

    Thanks for posting this…worked great for the versions of IE that have this issue, but also discovered the new version of IE (that fixes the disappearing element problem) no longer works with the patch (prototype.fix.js)

  2. You mean the latest versions of IE don’t have the problem? Hmmm well interesting that we no longer need it, but weird that the fix just stops working….but that’s IE for you… thanks for your tip!

Leave a Reply

Your email address will not be published. Required fields are marked *