IMO the current CSS priorities are wrong. A value set from code should be
adjacent to an in-line style in terms of precedence. They are both ways of
saying saying “this particular instance should have this value”
Scott
> On Jan 30, 2024, at 8:31 AM, John Hendrikx <john.hendr...@gmail.com> wrote:
>
> Hi Michael,
>
> I think we first need to decide what the correct behavior is for CSS
> properties, as the "bind" solution IMHO is a bug.
>
> The StyleOrigin enum encodes the relative priorities of styles and user set
> values, but it is incomplete and not fully enforced. There is (currently)
> actually a 5th level (next to USER_AGENT, USER, AUTHOR and INLINE) where it
> checks the binding state (it has no choice, as it will get an exception
> otherwise, or has to call `unbind` first). Whether that's a bug or should
> more formally be accepted as the correct behavior remains to be seen. Also
> the AUTHOR and INLINE levels are only best effort, as setting a value in code
> (USER level) will override AUTHOR and INLINE values **temporarily** until the
> next CSS pass...
>
> So first questions to answer IMHO are:
>
> 1) Does it make sense to treat values set in code (which IMHO should always
> be the last word on anything) as less important than values from AUTHOR and
> INLINE styles? This is specified in the CSS document, but not fully enforced.
>
> 2) Should bound values (which IMHO fall under "values set from code") be able
> to override AUTHOR and INLINE styles? Why are they being treated differently
> at all? Which StyleOrigin level do they fall under? "USER"? A 5th level
> with higher priority than "INLINE"?
>
> 3) Should properties which hold an AUTHOR or INLINE value reject calls to
> `setValue` (to make it clear they are temporary and that your code is
> probably wrong)? This currently is not in line with the CSS document. Note
> that this will be slightly annoying for the CSS engine as it may not be able
> to "reset" such values as easily as before (which is probably the reason it
> currently works the way it does, but that's no excuse IMHO).
>
> As for your potential solution, if you introduce a constant binding system
> (to solve a CSS problem), does that make sense for properties as a whole?
> What can be achieved with `bindConstant` that can't be done with `setValue`?
> `bindConstant` will become the "setter" that always works (never throws an
> exception...), but probably at a higher cost than using `setValue`. Would it
> not make more sense to only have such methods on the Styleable properties
> (which can then also signal this by using an even higher precedence
> StyleOrigin instead of relying on bound/unbound) once there is agreement on
> the above questions?
>
> In other words, I'd look more in the direction of providing users with a
> better "setter" only for CSS properties, that also uses a different
> StyleOrigin, and to bring both binding and setting in line with the CSS
> document's specification (or alternatively, to change that specification).
> This means that the normal setter provided next to the property method (ie.
> setXXX) would have to default to some standard behavior, while a more
> specific setter provided on the property itself can have an overriding
> behavior, something like:
>
> setX() -> calls cssProperty.setValue()
> cssProperty.setValue() -> sets values if not originated from an AUTHOR or
> INLINE stylesheet, otherwise throws exception (as if bound)
> cssProperty.forceValue() -> sets value unconditionally, setting
> StyleOrigin to some new to introduce 5th level
> (StyleOrigin.FORCED/DEVELOPER/DEBUG/CONSTANT/FINAL)
>
> Binding can then either be categorized as the StyleOrigin.FORCED or if it is
> StyleOrigin.USER, the CSS engine is free to **unbind** if the need arises.
>
> --John
>
>
>> On 30/01/2024 09:25, Michael Strauß wrote:
>> Hi everyone,
>>
>> I'm interested in hearing your thoughts on the following proposal,
>> which could increase the expressiveness of the JavaFX Property API:
>>
>> Problem
>> -------
>> The JavaFX CSS system applies the following order of precedence to
>> determine the value of a styleable property (in ascending
>> specificity):
>> 1. user-agent stylesheets
>> 2. values set from code
>> 3. Scene stylesheets
>> 4. Parent stylesheets
>> 5. inline styles
>>
>> While this system works quite well in general, applications sometimes
>> need to override individual property values from code. However, this
>> doesn't work reliably in the presence of Scene or Parent stylesheets.
>> There are two usual workarounds to solve this problem:
>>
>> A) Use an inline style instead of setting the property value directly.
>>
>> This is obviously not a good solution, as you'll lose the strong
>> typing afforded by the Java language. Additionally, the value must be
>> a true constant, it can't be an expression or the result of a
>> computation.
>>
>> B) Create an `ObservableValue` instance that holds the desired value,
>> and bind the property to it.
>>
>> This is a much better solution. However, what we really want is just
>> the binding semantics: the bound property becomes unmodifiable and has
>> the highest precedence in the CSS cascade. But the API only gives us
>> binding semantics if we give it an `ObservableValue`.
>>
>>
>> Solution
>> --------
>> I'm proposing to separate the toggles "binding semantics" and
>> "observability". While observability requires you to provide an
>> `ObservableValue`, binding semantics should work with both observable
>> and regular values.
>>
>> This is a powerful addition to the Property API, since it increases
>> the expressiveness of the API in a natural way:
>>
>> // instead of:
>> rect.setStyle("-fx-fill: red; -fx-width: 200");
>>
>> // you can use strongly-typed Java code:
>> rect.fillProperty().bindConstant(Color.RED);
>> rect.widthProperty().bindConstant(200);
>>
>> Since the `bindConstant` method accepts a value of the property type,
>> all features of the Java language can be used to fill in the value.
>>
>>
>> Implementation
>> --------------
>> The following method will be added to the `Property` interface:
>>
>> default void bindConstant(T value) {
>> bind(ObjectConstant.valueOf(value));
>> }
>>
>> Specialized methods will be added to `BooleanProperty`,
>> `DoubleProperty`, `FloatProperty`, `IntegerProperty`, and
>> `LongProperty`, each with one of the preexisting constant wrappers
>> that are already in the framework.
>> Some wrappers can be deduplicated (we only ever need two wrapper
>> instances for boolean values).
