Re: [External] : Re: CSS Lookups and their origins (possible regression)
penjfx-dev
*Subject: *Re: [External] : Re: CSS Lookups and their origins
(possible regression)
Well, it is coming as a surprise to many. With the fix for the CSS
caching bug since JavaFX 21, this "normal" behavior is becoming much
more obvious.
Let me repeat one more time:
If I have a Label, and I manually set its text fill with a setter to
YELLOW. In JavaFX 17, when I now add a stylesheet that is empty
aside from `-fx-base: WHITE`, the label's text fill stays YELLOW.
Now do this in JavaFX 21. As soon as you add the stylesheet with
`-fx-base: WHITE` in it, the set value to YELLOW is overridden, even
though technically this value for -fx-text-fill is defined by Modena
(which should not be overriding set values). Nowhere did we
**actualy** override -fx-text-fill, yet the CSS subsystem now sees
**all** values defined by Modena that are somehow linked to -fx-base
as defined directly by the developer...
The reason this didn't happen in JavaFX prior to 21 is because there
was a bug where a CSS value was not fully calculated if the property
it encountered was overridden via a set value. That was a bug
however as cache entries are shared amongst similar styled nodes,
and so not calculating it fully could have effects on other nodes
that shared that cache entry but did NOT have a property set
directly. Now that this bug is fixed, this problem is odd behavior
is popping up where simply specifying -fx-base in an empty
stylesheet is somehow overriding a programmatically set text fill.
Users are confused by this, as nowhere in their stylesheet do they
themselves override text fill.
This entire mechanism is not specified by CSS, but is unique to FX.
The most similar mechanism in CSS (see Michael's answer) says the
priority of a style should not be changed when it is using a reference.
--John
On 09/07/2024 17:43, Andy Goryachev wrote:
> all styles used in Modena that rely on -fx-base directly or
indirectly suddenly have a higher priority
I think it works as designed (and as expected).
-andy
*From: *John Hendrikx
<mailto:john.hendr...@gmail.com>
*Date: *Tuesday, July 9, 2024 at 08:25
*To: *Andy Goryachev
<mailto:andy.goryac...@oracle.com>, openjfx-dev
<mailto:openjfx-dev@openjdk.org>
*Subject: *[External] : Re: CSS Lookups and their origins
(possible regression)
It's not that you can't use -fx-base, but that as it is
currently that all styles used in Modena that rely on -fx-base
directly or indirectly suddenly have a higher priority (above
setters) even though you didn't specifically specify them in
your own stylesheet. All such styles are being elevated from
USER_AGENT to AUTHOR level (which is above USER level which is
used for setters).
--John
On 09/07/2024 17:03, Andy Goryachev wrote:
I've used this feature in the past to change the colors in
all the controls, so to me this is the expected behavior.
So in your case (if I got it right), you need to set the
direct style on the label
(.setStyle("-fx-text-fill:yellow")) instead of setting the
text fill programmatically. Right?
-andy
*From: *openjfx-dev
<mailto:openjfx-dev-r...@openjdk.org> on behalf of John
Hendrikx
<mailto:john.hendr...@gmail.com>
*Date: *Monday, July 8, 2024 at 17:11
*To: *openjfx-dev
<mailto:openjfx-dev@openjdk.org>
*Subject: *Re: CSS Lookups and their origins (possible
regression)
I realized I worded the TLDR poorly.
Let me try again:
TLDR; should styles which use references (like -fx-base used
in Modena) become AUTHOR level styles if -fx-base is
specified in an AUTHOR stylesheet? The act of simply
specifying -fx-base in your own AUTHOR stylesheet elevates
hundreds of styles from Modena to AUTHOR level, as if you
specified them directly...
--John
On 09/07/2024 02:07, John Hendrikx wrote:
Hi List,
TLDR; should a CSS reference like -fx-base convert all
styles that use this value (or derive from it) become
AUTHOR level styles (higher priority than setters) ?
Long version:
In JavaFX 21, I did a fix (see #1072) to solve a problem
where a CSS value could be reset on an unrelated control.
This happened when the CSS engine encountered a stylable
that is overridden by the user (with a setter), and
decided NOT to proceed with the full CSS value
calculation (as it could not override the user setting
if that CSS value had lower priority). However, not
proceeding with the calculation meant that a "SKIP" was
stored in a shared cache which was incorrect. This is
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Yes, you're right. Need to find time to file those issues. Though I want to finish the theme conversion to user agent stylesheets and then be sure it is a javafx bug. On Tue, Jul 9, 2024 at 8:34 PM Andy Goryachev wrote: > Thank you for clarification! > > > > Glad you were able to do what you wanted. But really, if there are bugs, > I would rather have them filed and fixed. > > > > -andy > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:26 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Perhaps I should have been clearer. I mentioned that example merely to > make a point on how having a stylesheet set as an AUTHOR stylesheet can be > a problem (Modena or a custom theme library like JMetro) :-) . > It wasn't actually to create a new separate discussion. > > > > As for the other discussion not exactly related to the one in this thread > (having custom themes be user agent stylesheets) I think I have found a way > to make multiple stylesheets be a user agent stylesheet. > > That was my main problem as JMetro is composed of more than 1 stylesheet. > I'm also doing it while still just using the javafx standard API. Thus far > it's working except for some minor bugs (which I'm inclined to think are > bugs in JavaFX itself). > > > > Thanks! > > > > On Tue, Jul 9, 2024 at 8:17 PM Andy Goryachev > wrote: > > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > <https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java*L31__;Iw!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskcKgEqM8$> > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > <https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java__;!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskOaoBCDc$> > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started)
Re: [External] : Re: CSS Lookups and their origins (possible regression)
My reading of this is that the fix for the caching bug, JDK-8245919 [1] via PR #1072 [2], has inadvertently exposed previously hidden behavior that is at best an undesirable feature and at worst a bug (I'd call it a bug). It seems quite unexpected to me that overriding a variable defined in a user agent stylesheet in an AUTHOR stylesheet would elevate all properties derived from that variable to AUTHOR stylesheet status. Assuming I'm not missing something, we ought to consider fixing this. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8245919 [2] https://github.com/openjdk/jfx/pull/1072 On 7/9/2024 11:21 AM, John Hendrikx wrote: Hi Andy, I'm confused, nowhere do I propose to remove or otherwise make the CSS reference system implemented by FX unusable. I'm first trying to ascertain if this would be expected behavior (it is indeed unspecified, and the default currently seems to have been chosen for implementation ease, not for user friendliness). **IF** we're considering this worth changing, the change would simply be that when you override a variable (like -fx-base) that this is done WITHOUT elevating all styles that use it to the level of an AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're specified by Modena). This is not a bad view, because in a sense, we're not really specifying a style, we're only overriding a variable. The actual style is still specified in Modena, which is a USER_AGENT level stylesheet. As for the bug fix, please read up a bit more on what was fixed, and what this is now exposing. The fix is almost completely unrelated (it fixed accidental changes to unrelated controls at the same level (ie. siblings) due to cache sharing where one has had a programmatic change, and the other didn't). This was caused by a CSS calculation bug (calculation was skipped for all styleable properties that already had a setter change, if they were encountered first by the CSS system). Now that this isn't the case anymore, set values are overwritten with CSS styles more aggressively. Normally those however are only styles that originate from an AUTHOR stylesheet, so this can be seen as expected by the user (after all, they WROTE that stylesheet). But because all styles that use a variable are being promoted to AUTHOR level, this also includes all unseen styles in Modena if you specify the variable in your AUTHOR stylesheet. > Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. That really depends on your view point. Is overriding a variable the same as defining all styles (in your AUTHOR stylesheet) that use that variable? If it was a pre-processor, that created a fully resolved Modena.css, then this would not be the case. But it is not implemented as such. > And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. To be clear, I'm not proposing to change that at all. --John On 09/07/2024 20:00, Andy Goryachev wrote: 1) a buggy implementation coupled with lack of specification creates a certain expectation 2) bug gets fixed 3) people complain because the feature now works as it should? I think (and this is my personal opinion, in the absence of a formal specification) that this works as expected now. The statement " Nowhere did we **actualy** override -fx-text-fill" is not technically correct since this color depends on -fx-base. And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. -andy *From: *John Hendrikx *Date: *Tuesday, July 9, 2024 at 10:45 *To: *Andy Goryachev , openjfx-dev *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible regression) Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even though technically this value for -fx-text-fill is defined by Modena (which should not be overriding set values). Nowhere did we **actualy** override -fx-text-fill, yet the CSS subsystem now sees **all** values defined by Modena that are somehow linked to -fx-base as defined directly by the developer... The reas
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Thank you for clarification! Glad you were able to do what you wanted. But really, if there are bugs, I would rather have them filed and fixed. -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 12:26 To: Andy Goryachev Cc: openjfx-dev@openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Perhaps I should have been clearer. I mentioned that example merely to make a point on how having a stylesheet set as an AUTHOR stylesheet can be a problem (Modena or a custom theme library like JMetro) :-) . It wasn't actually to create a new separate discussion. As for the other discussion not exactly related to the one in this thread (having custom themes be user agent stylesheets) I think I have found a way to make multiple stylesheets be a user agent stylesheet. That was my main problem as JMetro is composed of more than 1 stylesheet. I'm also doing it while still just using the javafx standard API. Thus far it's working except for some minor bugs (which I'm inclined to think are bugs in JavaFX itself). Thanks! On Tue, Jul 9, 2024 at 8:17 PM Andy Goryachev mailto:andy.goryac...@oracle.com>> wrote: If your stylesheet defines the necessary variables, the "users" should be able to redefine them, correct? Or maybe allow for programmatic control of the stylesheet, similar to https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31<https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java*L31__;Iw!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskcKgEqM8$> https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java<https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java__;!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskOaoBCDc$> Alternatively, we would need a new public API to allow you to do what you want how you want. Perhaps if you could tell us about the problem you are trying to solve, exactly, and the APIs that are missing. -andy From: Pedro Duque Vieira mailto:pedro.duquevie...@gmail.com>> Date: Tuesday, July 9, 2024 at 12:00 To: Andy Goryachev mailto:andy.goryac...@oracle.com>> Cc: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> mailto:openjfx-dev@openjdk.org>> Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) >> That's why now in the new theme I'm creating I'm setting everything to be >> an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev mailto:andy.goryac...@oracle.com>> wrote: > That's why now in the new theme I'm creating I'm setting everything to be an > user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev mailto:openjfx-dev-r...@openjdk.org>> on behalf of Pedro Duque Vieira mailto:pedro.duquevie...@gmail.com>> Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> mailto:openjfx-dev@openjdk.org>> Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com<https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Perhaps I should have been clearer. I mentioned that example merely to make a point on how having a stylesheet set as an AUTHOR stylesheet can be a problem (Modena or a custom theme library like JMetro) :-) . It wasn't actually to create a new separate discussion. As for the other discussion not exactly related to the one in this thread (having custom themes be user agent stylesheets) I think I have found a way to make multiple stylesheets be a user agent stylesheet. That was my main problem as JMetro is composed of more than 1 stylesheet. I'm also doing it while still just using the javafx standard API. Thus far it's working except for some minor bugs (which I'm inclined to think are bugs in JavaFX itself). Thanks! On Tue, Jul 9, 2024 at 8:17 PM Andy Goryachev wrote: > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$> > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$> > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
If your stylesheet defines the necessary variables, the "users" should be able to redefine them, correct? Or maybe allow for programmatic control of the stylesheet, similar to https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java Alternatively, we would need a new public API to allow you to do what you want how you want. Perhaps if you could tell us about the problem you are trying to solve, exactly, and the APIs that are missing. -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 12:00 To: Andy Goryachev Cc: openjfx-dev@openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) >> That's why now in the new theme I'm creating I'm setting everything to be >> an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev mailto:andy.goryac...@oracle.com>> wrote: > That's why now in the new theme I'm creating I'm setting everything to be an > user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev mailto:openjfx-dev-r...@openjdk.org>> on behalf of Pedro Duque Vieira mailto:pedro.duquevie...@gmail.com>> Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> mailto:openjfx-dev@openjdk.org>> Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com<https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$> -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com<https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$>
Re: [External] : Re: CSS Lookups and their origins (possible regression)
>> That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev wrote: > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
> That's why now in the new theme I'm creating I'm setting everything to be an > user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev on behalf of Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev@openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Yes, sorry, I read it as if you were proposing to change the behavior. My mistake. I still think this is a good discussion to have. Perhaps we ought to clarify the behavior somewhere? My understanding of CSS is that it does not work as a pre-processor. Rather, it's a single set of global things where everyone can change everything at run time, using the simple set of rules to determine whose changes are on top. I think (guessing here) it works the same in WWW CSS (there is no well-defined standard there either, but that is a different story, ). I wish there was a public API to create stylesheets programmatically, bypassing the parser altogether. But this is unlikely to happen. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 11:21 To: Andy Goryachev , openjfx-dev Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi Andy, I'm confused, nowhere do I propose to remove or otherwise make the CSS reference system implemented by FX unusable. I'm first trying to ascertain if this would be expected behavior (it is indeed unspecified, and the default currently seems to have been chosen for implementation ease, not for user friendliness). **IF** we're considering this worth changing, the change would simply be that when you override a variable (like -fx-base) that this is done WITHOUT elevating all styles that use it to the level of an AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're specified by Modena). This is not a bad view, because in a sense, we're not really specifying a style, we're only overriding a variable. The actual style is still specified in Modena, which is a USER_AGENT level stylesheet. As for the bug fix, please read up a bit more on what was fixed, and what this is now exposing. The fix is almost completely unrelated (it fixed accidental changes to unrelated controls at the same level (ie. siblings) due to cache sharing where one has had a programmatic change, and the other didn't). This was caused by a CSS calculation bug (calculation was skipped for all styleable properties that already had a setter change, if they were encountered first by the CSS system). Now that this isn't the case anymore, set values are overwritten with CSS styles more aggressively. Normally those however are only styles that originate from an AUTHOR stylesheet, so this can be seen as expected by the user (after all, they WROTE that stylesheet). But because all styles that use a variable are being promoted to AUTHOR level, this also includes all unseen styles in Modena if you specify the variable in your AUTHOR stylesheet. > Nowhere did we **actualy** override -fx-text-fill " is not technically > correct since this color depends on -fx-base. That really depends on your view point. Is overriding a variable the same as defining all styles (in your AUTHOR stylesheet) that use that variable? If it was a pre-processor, that created a fully resolved Modena.css, then this would not be the case. But it is not implemented as such. > And I would not want to change how it works currently because this is the > only way (short of overwriting the whole modena.css styleshseet) for an > application to effect a system-wide change like reacting to changes in the > user preferences or the platform theme. To be clear, I'm not proposing to change that at all. --John On 09/07/2024 20:00, Andy Goryachev wrote: 1) a buggy implementation coupled with lack of specification creates a certain expectation 2) bug gets fixed 3) people complain because the feature now works as it should? I think (and this is my personal opinion, in the absence of a formal specification) that this works as expected now. The statement " Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. -andy From: John Hendrikx <mailto:john.hendr...@gmail.com> Date: Tuesday, July 9, 2024 at 10:45 To: Andy Goryachev <mailto:andy.goryac...@oracle.com>, openjfx-dev <mailto:openjfx-dev@openjdk.org> Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELL
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Hi Andy, I'm confused, nowhere do I propose to remove or otherwise make the CSS reference system implemented by FX unusable. I'm first trying to ascertain if this would be expected behavior (it is indeed unspecified, and the default currently seems to have been chosen for implementation ease, not for user friendliness). **IF** we're considering this worth changing, the change would simply be that when you override a variable (like -fx-base) that this is done WITHOUT elevating all styles that use it to the level of an AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're specified by Modena). This is not a bad view, because in a sense, we're not really specifying a style, we're only overriding a variable. The actual style is still specified in Modena, which is a USER_AGENT level stylesheet. As for the bug fix, please read up a bit more on what was fixed, and what this is now exposing. The fix is almost completely unrelated (it fixed accidental changes to unrelated controls at the same level (ie. siblings) due to cache sharing where one has had a programmatic change, and the other didn't). This was caused by a CSS calculation bug (calculation was skipped for all styleable properties that already had a setter change, if they were encountered first by the CSS system). Now that this isn't the case anymore, set values are overwritten with CSS styles more aggressively. Normally those however are only styles that originate from an AUTHOR stylesheet, so this can be seen as expected by the user (after all, they WROTE that stylesheet). But because all styles that use a variable are being promoted to AUTHOR level, this also includes all unseen styles in Modena if you specify the variable in your AUTHOR stylesheet. > Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. That really depends on your view point. Is overriding a variable the same as defining all styles (in your AUTHOR stylesheet) that use that variable? If it was a pre-processor, that created a fully resolved Modena.css, then this would not be the case. But it is not implemented as such. > And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. To be clear, I'm not proposing to change that at all. --John On 09/07/2024 20:00, Andy Goryachev wrote: 1) a buggy implementation coupled with lack of specification creates a certain expectation 2) bug gets fixed 3) people complain because the feature now works as it should? I think (and this is my personal opinion, in the absence of a formal specification) that this works as expected now. The statement " Nowhere did we **actualy** override -fx-text-fill" is not technically correct since this color depends on -fx-base. And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. -andy *From: *John Hendrikx *Date: *Tuesday, July 9, 2024 at 10:45 *To: *Andy Goryachev , openjfx-dev *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible regression) Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even though technically this value for -fx-text-fill is defined by Modena (which should not be overriding set values). Nowhere did we **actualy** override -fx-text-fill, yet the CSS subsystem now sees **all** values defined by Modena that are somehow linked to -fx-base as defined directly by the developer... The reason this didn't happen in JavaFX prior to 21 is because there was a bug where a CSS value was not fully calculated if the property it encountered was overridden via a set value. That was a bug however as cache entries are shared amongst similar styled nodes, and so not calculating it fully could have effects on other nodes that shared that cache entry but did NOT have a property set directly. Now that this bug is fixed, this problem is odd behavior is popping up where simply specifying -fx-base in an empty stylesheet is somehow overriding a programmatically set text fill. Users are confused by this, as nowhere in their stylesheet do they
Re: [External] : Re: CSS Lookups and their origins (possible regression)
1) a buggy implementation coupled with lack of specification creates a certain
expectation
2) bug gets fixed
3) people complain because the feature now works as it should?
I think (and this is my personal opinion, in the absence of a formal
specification) that this works as expected now. The statement " Nowhere did we
**actualy** override -fx-text-fill " is not technically correct since this
color depends on -fx-base.
And I would not want to change how it works currently because this is the only
way (short of overwriting the whole modena.css styleshseet) for an application
to effect a system-wide change like reacting to changes in the user preferences
or the platform theme.
-andy
From: John Hendrikx
Date: Tuesday, July 9, 2024 at 10:45
To: Andy Goryachev , openjfx-dev
Subject: Re: [External] : Re: CSS Lookups and their origins (possible
regression)
Well, it is coming as a surprise to many. With the fix for the CSS caching bug
since JavaFX 21, this "normal" behavior is becoming much more obvious.
Let me repeat one more time:
If I have a Label, and I manually set its text fill with a setter to YELLOW. In
JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base:
WHITE`, the label's text fill stays YELLOW.
Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base:
WHITE` in it, the set value to YELLOW is overridden, even though technically
this value for -fx-text-fill is defined by Modena (which should not be
overriding set values). Nowhere did we **actualy** override -fx-text-fill, yet
the CSS subsystem now sees **all** values defined by Modena that are somehow
linked to -fx-base as defined directly by the developer...
The reason this didn't happen in JavaFX prior to 21 is because there was a bug
where a CSS value was not fully calculated if the property it encountered was
overridden via a set value. That was a bug however as cache entries are shared
amongst similar styled nodes, and so not calculating it fully could have
effects on other nodes that shared that cache entry but did NOT have a property
set directly. Now that this bug is fixed, this problem is odd behavior is
popping up where simply specifying -fx-base in an empty stylesheet is somehow
overriding a programmatically set text fill. Users are confused by this, as
nowhere in their stylesheet do they themselves override text fill.
This entire mechanism is not specified by CSS, but is unique to FX. The most
similar mechanism in CSS (see Michael's answer) says the priority of a style
should not be changed when it is using a reference.
--John
On 09/07/2024 17:43, Andy Goryachev wrote:
> all styles used in Modena that rely on -fx-base directly or indirectly
> suddenly have a higher priority
I think it works as designed (and as expected).
-andy
From: John Hendrikx <mailto:john.hendr...@gmail.com>
Date: Tuesday, July 9, 2024 at 08:25
To: Andy Goryachev
<mailto:andy.goryac...@oracle.com>, openjfx-dev
<mailto:openjfx-dev@openjdk.org>
Subject: [External] : Re: CSS Lookups and their origins (possible regression)
It's not that you can't use -fx-base, but that as it is currently that all
styles used in Modena that rely on -fx-base directly or indirectly suddenly
have a higher priority (above setters) even though you didn't specifically
specify them in your own stylesheet. All such styles are being elevated from
USER_AGENT to AUTHOR level (which is above USER level which is used for
setters).
--John
On 09/07/2024 17:03, Andy Goryachev wrote:
I've used this feature in the past to change the colors in all the controls, so
to me this is the expected behavior.
So in your case (if I got it right), you need to set the direct style on the
label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill
programmatically. Right?
-andy
From: openjfx-dev
<mailto:openjfx-dev-r...@openjdk.org> on behalf
of John Hendrikx <mailto:john.hendr...@gmail.com>
Date: Monday, July 8, 2024 at 17:11
To: openjfx-dev <mailto:openjfx-dev@openjdk.org>
Subject: Re: CSS Lookups and their origins (possible regression)
I realized I worded the TLDR poorly.
Let me try again:
TLDR; should styles which use references (like -fx-base used in Modena) become
AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act
of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds
of styles from Modena to AUTHOR level, as if you specified them directly...
--John
On 09/07/2024 02:07, John Hendrikx wrote:
Hi List,
TLDR; should a CSS reference like -fx-base convert all styles that use this
value (or derive from it) become AUTHOR level styles (higher priority than
setters) ?
Long version:
In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value
could be reset on an unrelated control.
This happened when the CSS engine encountered a stylable tha
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Well, it is coming as a surprise to many. With the fix for the CSS
caching bug since JavaFX 21, this "normal" behavior is becoming much
more obvious.
Let me repeat one more time:
If I have a Label, and I manually set its text fill with a setter to
YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside
from `-fx-base: WHITE`, the label's text fill stays YELLOW.
Now do this in JavaFX 21. As soon as you add the stylesheet with
`-fx-base: WHITE` in it, the set value to YELLOW is overridden, even
though technically this value for -fx-text-fill is defined by Modena
(which should not be overriding set values). Nowhere did we **actualy**
override -fx-text-fill, yet the CSS subsystem now sees **all** values
defined by Modena that are somehow linked to -fx-base as defined
directly by the developer...
The reason this didn't happen in JavaFX prior to 21 is because there was
a bug where a CSS value was not fully calculated if the property it
encountered was overridden via a set value. That was a bug however as
cache entries are shared amongst similar styled nodes, and so not
calculating it fully could have effects on other nodes that shared that
cache entry but did NOT have a property set directly. Now that this bug
is fixed, this problem is odd behavior is popping up where simply
specifying -fx-base in an empty stylesheet is somehow overriding a
programmatically set text fill. Users are confused by this, as nowhere
in their stylesheet do they themselves override text fill.
This entire mechanism is not specified by CSS, but is unique to FX. The
most similar mechanism in CSS (see Michael's answer) says the priority
of a style should not be changed when it is using a reference.
--John
On 09/07/2024 17:43, Andy Goryachev wrote:
> all styles used in Modena that rely on -fx-base directly or indirectly
suddenly have a higher priority
I think it works as designed (and as expected).
-andy
*From: *John Hendrikx
*Date: *Tuesday, July 9, 2024 at 08:25
*To: *Andy Goryachev , openjfx-dev
*Subject: *[External] : Re: CSS Lookups and their origins (possible
regression)
It's not that you can't use -fx-base, but that as it is currently that
all styles used in Modena that rely on -fx-base directly or indirectly
suddenly have a higher priority (above setters) even though you didn't
specifically specify them in your own stylesheet. All such styles are
being elevated from USER_AGENT to AUTHOR level (which is above USER
level which is used for setters).
--John
On 09/07/2024 17:03, Andy Goryachev wrote:
I've used this feature in the past to change the colors in all the
controls, so to me this is the expected behavior.
So in your case (if I got it right), you need to set the direct
style on the label (.setStyle("-fx-text-fill:yellow")) instead of
setting the text fill programmatically. Right?
-andy
*From: *openjfx-dev
<mailto:openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx
<mailto:john.hendr...@gmail.com>
*Date: *Monday, July 8, 2024 at 17:11
*To: *openjfx-dev
<mailto:openjfx-dev@openjdk.org>
*Subject: *Re: CSS Lookups and their origins (possible regression)
I realized I worded the TLDR poorly.
Let me try again:
TLDR; should styles which use references (like -fx-base used in
Modena) become AUTHOR level styles if -fx-base is specified in an
AUTHOR stylesheet? The act of simply specifying -fx-base in your
own AUTHOR stylesheet elevates hundreds of styles from Modena to
AUTHOR level, as if you specified them directly...
--John
On 09/07/2024 02:07, John Hendrikx wrote:
Hi List,
TLDR; should a CSS reference like -fx-base convert all styles
that use this value (or derive from it) become AUTHOR level
styles (higher priority than setters) ?
Long version:
In JavaFX 21, I did a fix (see #1072) to solve a problem where
a CSS value could be reset on an unrelated control.
This happened when the CSS engine encountered a stylable that
is overridden by the user (with a setter), and decided NOT to
proceed with the full CSS value calculation (as it could not
override the user setting if that CSS value had lower
priority). However, not proceeding with the calculation meant
that a "SKIP" was stored in a shared cache which was
incorrect. This is because when this "SKIP" is later
encountered for an unrelated control (the cache entries are
shared for controls with the same styles at the same level),
they could get their values reset because they were assumed to
be unstyled.
However, this fix has exposed what seems to be a deeper bug or
perhaps an unfortunate default:
JavaFX has a special feature where you can refer to certain
other styles
Re: [External] : Re: CSS Lookups and their origins (possible regression)
> all styles used in Modena that rely on -fx-base directly or indirectly
> suddenly have a higher priority
I think it works as designed (and as expected).
-andy
From: John Hendrikx
Date: Tuesday, July 9, 2024 at 08:25
To: Andy Goryachev , openjfx-dev
Subject: [External] : Re: CSS Lookups and their origins (possible regression)
It's not that you can't use -fx-base, but that as it is currently that all
styles used in Modena that rely on -fx-base directly or indirectly suddenly
have a higher priority (above setters) even though you didn't specifically
specify them in your own stylesheet. All such styles are being elevated from
USER_AGENT to AUTHOR level (which is above USER level which is used for
setters).
--John
On 09/07/2024 17:03, Andy Goryachev wrote:
I've used this feature in the past to change the colors in all the controls, so
to me this is the expected behavior.
So in your case (if I got it right), you need to set the direct style on the
label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill
programmatically. Right?
-andy
From: openjfx-dev
<mailto:openjfx-dev-r...@openjdk.org> on behalf
of John Hendrikx <mailto:john.hendr...@gmail.com>
Date: Monday, July 8, 2024 at 17:11
To: openjfx-dev <mailto:openjfx-dev@openjdk.org>
Subject: Re: CSS Lookups and their origins (possible regression)
I realized I worded the TLDR poorly.
Let me try again:
TLDR; should styles which use references (like -fx-base used in Modena) become
AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act
of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds
of styles from Modena to AUTHOR level, as if you specified them directly...
--John
On 09/07/2024 02:07, John Hendrikx wrote:
Hi List,
TLDR; should a CSS reference like -fx-base convert all styles that use this
value (or derive from it) become AUTHOR level styles (higher priority than
setters) ?
Long version:
In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value
could be reset on an unrelated control.
This happened when the CSS engine encountered a stylable that is overridden by
the user (with a setter), and decided NOT to proceed with the full CSS value
calculation (as it could not override the user setting if that CSS value had
lower priority). However, not proceeding with the calculation meant that a
"SKIP" was stored in a shared cache which was incorrect. This is because when
this "SKIP" is later encountered for an unrelated control (the cache entries
are shared for controls with the same styles at the same level), they could get
their values reset because they were assumed to be unstyled.
However, this fix has exposed what seems to be a deeper bug or perhaps an
unfortunate default:
JavaFX has a special feature where you can refer to certain other styles by
using a reference (which is resolved, recursively, to a final value). This
does not seem to be a CSS standard, but is a feature only FX has.
It works by saying something like:
-fx-base: RED;
And then using it like this:
-fx-text-fill: -fx-base;
This feature works accross stylesheets of different origins, so an AUTHOR
stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the
value comes from the AUTHOR stylesheet.
JavaFX then changes the origin of the style to the highest priority encountered
while resolving the reference. This means that Modena can specify
"-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style
sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level
styles, as per this comment:
// The origin of this parsed value is the greatest of
// any of the resolved reference. If a resolved reference
// comes from an inline style, for example, then the value
// calculated from the resolved lookup should have inline
// as its origin. Otherwise, an inline style could be
// stored in shared cache.
I feel that this is a really unfortunate choice. The style after all was
specified by Modena, only its value came from another (higher priority) style
sheet. I think a more logical choice would have been to not change the
priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR
stylesheet.
A consequence of this (and which is much more visible after the fix) is that
creating a Label with a setTextFill(Color.YELLOW) in its constructor will only
result in a yellow text fill if the AUTHOR stylesheet did not override any of
the Modena colors involved in calculating the Modena -fx-text-fill default.
Overriding -fx-base in any way will result in the text fill of the label to be
overridden (as the reference came from an AUTHOR stylesheet, which trumps a
setter which is of a lower style origin).
The comment also alludes to a potential problem. If an inline style would
s
