Hi John, If the issues with StyleOrigin are not as problematic as I presented, it comes out to the behavioral flexibility we have. Can we change the precedence order at this point? Do users rely on it or are surprised by it (I see the latter, but those who think it works correctly are not going to say that)? Perhaps Kevin can weigh in.
The question of how to do it is simpler, and can be done with or without breaking changes to StyleOrigin. On Thu, Feb 1, 2024 at 2:27 AM John Hendrikx <john.hendr...@gmail.com> wrote: > Hi Nir, > > On 31/01/2024 22:36, Nir Lisker wrote: > > > > I would wait with the ramifications of setting competing values from > > different origins until the question of precedence is answered. > > Perhaps emitting warnings is better, though I can see some scenarios > > in which they will be annoying. > > > > The way I see the order: > > 1. Setting from code should always take precedence (including the > > current bindings over setter order of course). > > 2. INLINE origin (via setStyle). > > 3. Stylesheets according to their StyleOrigin as specified by the > > non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see > > below for INLINE). > > > > 2 and 3 are already (more or less) specified in JavaFX's css as far as > > I can see. However, 1 is not css, hence I don't think StyleOrigin > > should be applicable here even. Even more, 2 isn't really css either, > > it mimics html tags and shouldn't count as a css StyleOrigin in my > > opinion. > StyleOrigin is more of an internal thing that got exposed, so I wouldn't > worry too much about what is CSS and what isn't. I agree that the above > order would make more sense. I suspect the reasoning why it wasn't done > is that setters are getting called to set up defaults, which if they by > default override all, would conflict with style sheets set by the user. > > Note also that a Stylesheet can set its origin [4], even to INLINE, so > > it takes precedence over java property setters and conflicts with > > 'setStyle' "real" INLINE. I'm not sure if this is a bug because the > > javafx css specs say that "Inline styles are specified via the Node > > setStyle AP". > > The CSS API is weird. It has many seemingly useful and public bits, but > they are isolated from the rest of FX. > > Take StyleSheet for example. You can convert them (using File to File) > from regular to binary, then load a binary file and get a StyleSheet > reference with a public API. You can then change its origin. However, > it stops there. You can't feed such a modified StyleSheet to FX via any > public API. > > It almost looks like a lot of the CSS public API is there for a possibly > previously integrated Scene Builder type application, which was later > split off. > > > > > So, if I were to able to do anything I wanted, I would have restricted > > Stylesheets to the options in 3, remove INLINE from a public > > perspective and apply it only behind the scenes to 'setStyle' calls, > > and stop treating java settings in the css hierarchy (which means > > removing the USER StyleOrigin from them). Obviously that breaks a lot > > of code, but this behavior would be my general goal. As for how to > > represent it, maybe a constant can be added to StyleOrigin to > > represent java code settings, but that's not a real css origin. I > > guess we could call INLINE and the hypothetical JAVA constants > > "pseudo-origins", because they don't apply to stylesheets, and are > > only used internally. Or just don't check StyleOrigin when the value > > is set from java. There are probably more ways. > > StyleOrigin really is only there for the CSS engine to distinguish if it > can replace a value or not with something else depending on precedence. > It probably shouldn't have been public at all, aside from the fact that > StyleableProperty being an interface forced it to be public. > > Oddly enough, the StyleableProperty interface is public, but it is again > never returned anywhere (didn't check extensively). So you can't > actually do "label.textAlignment().applyStyle( ... )" even though text > alignment is a styleable property. > > If `textAlignment()` did return a StyleableProperty, then you could do > `label.textAlignment().applyStyle(StyleOrigin.CODE, value)` for a > permanent override of the value which the CSS engine will respect. > > > > > I also wonder if StyleOrigin should implement Comparable for > > the precedence calculations of stylesheets. > > It sort of already does, they are defined in the order of least to > highest precedence, so an integer comparator on its ordinal can be used. > > --John > >
