Does styling opacities conflict with animation opacities?

[Richard Bair]

Hi Randahl,

> This means our tool tips are just enough transparent that you can vaguely see the content behind it. To make the tool tips look nicer, we decided to animate then, so now when showing the tool tip, we fade it in by gradually changing its opacity from 0.0 to 1.0 using a FadeTransition. So up pops the question: What will the opacity be, once the fade transition ends? Will it be the 0.8 from the CSS, or the 1.0 from the FadeTransition?

The problem here is that whenever you set a property both from CSS and from code, code not only will always win, but will disable that property from being set from CSS henceforth. We used to have the rule that "last applied wins" or "CSS always wins", and this led to very unsettling behavior to developers. The current behavior appears to be much more intuitive. However it means that until CSS animation support is added, you won't be able to both style from CSS and animate the styled property :-(.

The CSS engine though is completely in the open source, and at least at one time we had a fairly simple idea as to how to go about doing the animations. Perhaps you could work with David and contribute some code for CSS Animations for FX 8?

In the meantime, your application will either have to set the opacity exclusively from code, or from CSS. Alternatively you could do some hack, for example having an empty Group in your app with the same style class as the tooltip. Then the Group will have whatever opacity you set from CSS for your Tooltip. Then when you animate you can animate from the current value to whatever value the Group says it should be (but animating the tooltip of course).

Thanks
Richard