#680 tween('opacity', 0) shouldn't be adding visibility: hidden - mootools.core

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#680 ✓resolved

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”
You flagged this item as spam.
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'.
You flagged this item as spam.
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
You flagged this item as spam.
Ryan Mitchell March 11th, 2011 @ 11:02 AM
Suggested patch for this bug is attached.
- 0001-suggested-fix-for-lh-bug-6.patch 1.9 KB
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
You flagged this item as spam.
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.