[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: CSS Transitions
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2023-07-26 11:09:53
Message-ID: f323fdc1-986a-f8a1-dfe5-0a98b6bee958 () oracle ! com
[Download RAW message or body]

inline

On 7/24/2023 5:09 PM, Michael Strauß wrote:
> My comments below:
>
> On Tue, Jul 25, 2023 at 1:18 AM Kevin Rushforth
> <kevin.rushforth@oracle.com> wrote:
>> This seems like it might be a useful feature, if enough applications
>> would want to take advantage of it.
>>
>> If we proceed, I have a couple comments:
>>
>> * All of our existing CSS attributes use "-fx-" as a prefix. My
>> preference would be to do that for transitions as well, absent a
>> compelling reason to do otherwise. I note that you say in your design
>> doc that transition "...is special and distinct from all other CSS
>> properties". Is that the reason you didn't prefix it with "-fx-"? Is it
>> a sufficient reason?
> The vendor prefix indicates a nonstandard/proprietary CSS property (see
> also https://www.w3.org/TR/CSS/#proprietary). That's the case for almost
> all JavaFX CSS properties (with one notable exception: "visibility").
> However, "transition" is an exact implementation of the CSS standard, so
> there's no need to use a vendor prefix. I think that would be setting a wrong
> expectation, as CSS developers might think that "-fx-transition" works
> differently than a standard-conforming "transition" property, when in reality
> it's the same.

OK, that seems like a good enough reason.

>> * Initially, I wondered about your providing the CSS attributes without
>> corresponding API on the scene graph objects in question, but I think
>> that's a very good idea.
> Note that if there's ever a compelling need to have an API on SG objects,
> this can be retrofitted. But I doubt that such an API would be useful.

You're probably right.

-- Kevin

>> * This will need a lot of testing since it touches the CSS attribute
>> resolution mechanism.
> Agreed.

[prev in list] [next in list] [prev in thread] [next in thread]