This project is archived and is in readonly mode.

#680 ✓resolved
Oskar Krawczyk

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

    Scott Kyle September 4th, 2009 @ 03:44 AM

    • Assigned user changed from “Aaron Newton” to “Scott Kyle”
    • State changed from “new” to “open”
  • planetG

    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

    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

  • Ryan Mitchell
  • Arian

    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”
  • Olivier Laviale

    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 »

Shared Ticket Bins

Attachments

Referenced by

Pages