Does styling opacities conflict with animation opacities?

[David Grieve]

The inner workings of CSS may need to know about animations, but animations shouldn't know anything about CSS. Just my $.02

On Aug 31, 2012, at 5:52 AM, Randahl Fink Isaksen wrote:

> I think I have a sound solution to this problem: What about simply letting the KeyValue pairs of KeyFrame specify if the KeyFrame *overrides* the CSS or if the KeyFrame *factors in* the CSS, so we will both have the original KeyValue constructor
> 
> new KeyValue(someNode.opacityProperty(), 1.0); //absolute end value as we know it
> 
> which means we end at an absolute value of 1.0, and a new KeyValue constructor
> 
> new KeyValue(someNode.opacityProperty(), 1.0, true);
> 
> where 'true' means this KeyValue is true to (i.e. relative to) the value specified by CSS, so if CSS specifies 0.8 we end at 1.0 x 0.8 = 0.8.
> 
> Could this be it? If so, I will file an RFE – I do not presently have the available hours to put into this feature myself, but I do think this would be very powerful and useful.
> 
> Randahl
> 
> 
> 
> 
> 
> On Aug 31, 2012, at 0:50 , Jim Graham <james.graham at oracle.com> wrote:
> 
>> Shouldn't the animation be from 0 to "whatever the node got styled with"?  Otherwise you have a tooltip that fades in - overshoots - and then drops back to .8.  It sort of smacks you in the face and then hangs back nonchalantly.  ;)
>> 
>> So, whether or not the program is fixed to retrigger the CSS styling after the animation, the animation itself is probably not "what you'd want" anyway.
>> 
>> It's easy to animate "from a current value to another value" by using a timeline with no initial value, but it would be nice to have support to create a timeline that animates "from this concrete value to whatever the current value is".  Perhaps that could be achieved with a bit of work with an auto-reverse timeline?
>> 
>> 	KeyFrame kf = (node.opacity = 0 at 1s)
>> 	Timeline tl = new Timeline(kf);
>> 	tl.setCycleCount(2);
>> 	tl.setAutoReverse(true);
>> 	tl.jumpTo(1s or whatever the time stamp of the KeyFrame is);
>> 	tl.play();
>> 
>> (Caveat - I'm not a particularly knowledgable CSS/antimation expert so I'm not sure if that sequence will properly capture the initial value or not...)
>> 
>> 			...jim
>> 
>> On 8/30/12 8:41 AM, David Grieve wrote:
>>> 
>>> On Aug 30, 2012, at 10:36 AM, Richard Bair wrote:
>>> 
>>>> 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 :-(.
>>> 
>>> This is not entirely correct. If I have
>>> 
>>> Rectangle rect = new Rectangle(10,10);
>>> rect.getStyleClass().add("rect");
>>> rect.setOpacity(.5);
>>> 
>>> And this CSS in an inline style or an author stylesheet:
>>> 
>>> .rect { -fx-opacity: .8; }
>>> 
>>> Then the opacity will be set to 80% since an inline or author style overrides a user set style. If the same style was in a user agent stylesheet, then the user agent style would be overridden by the call to setOpacity (more correctly, the style will not override the call to setOpacity).
>>> 
>>> The reason the Tooltip doesn't end up at .8 is because CSS is not applied to it after the tooltip is shown. It is styled once, but there is no reason to style it again. You can test this by adding a style for the tooltip's hover pseudo-class, for example,
>>> 
>>> .tooltip:hover { -fx-fill: red; }
>>> 
>>> Hover over the tooltip and back out again and the opacity will be reset to 80%.
>>> 
>>> As a hack, you can add an onFinished event handler to the transition that forces CSS to be updated by calling impl_processCSS(false) on the skin.
>>> 
>>>    final FadeTransition ft = new FadeTransition(Duration.millis(1000), tooltip.getSkin().getNode());
>>>    ft.setFromValue(.0);
>>>    ft.setToValue(1.0);
>>>    ft.setOnFinished(new EventHandler<ActionEvent>() {
>>>        @Override
>>>        public void handle(ActionEvent t) {
>>>            tooltip.getSkin().getNode().impl_processCSS(false);
>>>        }
>>>    });
>>>    ft.play();
>>> 
>>>> 
>>>> 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
>>> 
>>> 
>>> David Grieve | Principal Member of Technical Staff
>>> Mobile: +16033121013
>>> Oracle Java Client UI and Tools
>>> Durham, NH 03824
>>> Oracle is committed to developing practices and products that help protect the environment
>>> 
> 


David Grieve | Principal Member of Technical Staff
Mobile: +16033121013 
Oracle Java Client UI and Tools
Durham, NH 03824 
 Oracle is committed to developing practices and products that help protect the environment