This project is archived and is in readonly mode.

tween('opacity', 0) shouldn't be adding visibility: hidden
Reported by Oskar Krawczyk | May 31st, 2009 @ 07:03 PM | in 1.4.0 (closed)
Currently when setting opacity to 0 (both, via tween() or setStyle()), a visibility: hidden is added, which logically shouldn't be the case.
I know for sure that fade('in'/'out') was manipulating the visibility property, this is fine as that was what I was expecting when using the shortcut. But in case of morphing a single property, only ONE should be altered.
Comments and changes to this ticket
-
Scott Kyle September 4th, 2009 @ 03:44 AM
- Assigned user changed from Aaron Newton to Scott Kyle
- State changed from new to open
-
planetG January 28th, 2011 @ 09:51 PM
- Milestone order changed from 0 to 0
I'd like to add my vote for making a change to this also. Here's an example I put together that demonstrates a problem I ran across when trying to trigger a 'mouseenter' event on elements I had faded out to opacity 0, ie el.fade(0);
http://jsfiddle.net/planetG/vHPyj/15/
The Mootools 1.3 documentation "Element Method: fade()" makes no mention of the fact that once the opacity attribute becomes '0' that the Element.Properties.opacity#set method also changes the 'visibility' attribute to 'hidden'. This had me scratching my head for a while until I saw the changes going on to the 'visibility' setting while analyzing with Firebug.
Once the 'visibility' attribute is in a 'hidden' state it appears the 'mouseenter' event no longer sees the element, so doesn't fire.
I'm uncertain if there was a reason for having Element.Properties.opacity#set modifying anything other then the 'opacity' setting. However at the very least it would be helpful as a note in the documentation so a developer can compensate for the effect, knowing they need to add some oncomplete code to alter 'visibility' back to what they need. If there is no definite reason for the 'visibility' attribute being changed in that method it would have saved me a bit of debugging if it hadn't been in there at all and only affected 'opacity'.
-
Jacob March 3rd, 2011 @ 02:32 AM
Just encountered this issue as well. Same as planetG, I'm relying on the element being visible to receive events.
To counteract this I have used setOpacity as suggested by Christoph is #1163
-
-
Arian August 18th, 2011 @ 01:12 AM
- State changed from open to resolved
- Milestone changed from 2.0 to 1.4.0
- Milestone order changed from 643 to 0
Should be fixed now: https://github.com/mootools/mootools-core/commit/041141377
-
Olivier Laviale September 20th, 2011 @ 07:57 PM
I think this change is a bad idea disguised as a good one. I understand that setStyle() should only alter the property it is supposed to alter, but now if we fade our controls out they are still "active", so a user can click by mistake on an invisible "delete" button, or a menu can pop out of nowhere from an invisible "select", so we have to manually set the visibility before and after to fade, and I think it's really annoying.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Attachments
Referenced by
-
754 setting opacity makes elements visible duplicate of #680
-
1163 Fade/Tween issue with IE By coincidence somebody has just commented on an older ti...