I suspected as much, and that really is a shame because it cripples the
declaration based behavior. The parser could of course declare any property it
does not know at the time of parsing as needed to be looked up. Ultimately I
cannot move the colorschemes into a separate file, so they are reusable by all
gauges,, because the import must preceed any declarations.
All classes in the CSS are below .SimpleMetroArcGauge, I will prefix them. What
I really want to do is reuse the -fxx-needle-color for each gauge, that is:
multiple instances of the same control, but also different gauges, so I can
have a universal set of colorscheme's applicable to every gauge.
Maybe I should have a look at placeholders and let Gradle / Maven resolve them.
On 9-4-2015 17:59, David Grieve wrote:
Take -fxx-needle-color (from SimpleMetroArcGauge.css) as an example. Its
declaration appears in the .SimpleMetroArcGauge rule and is then used in the
-fx-fill declaration of the .needle rule. The CSS parser is pretty dumb. It
collects up the property names as it parses and if any of those property names
appears a a property value, it marks the property value as needing to be looked
up. Then, at run time, if a property has a value that needs to be looked up,
the CSS engine goes from the node up to the root looking for a declaration that
resolves the property to a real value. Anyway, the point is, you can't have
forward references for these lookup values.
Note also that the .needle node has to be a .SimpleMetroArcGauge or a child of
a .SimpleMetroArcGauge for the lookup to work. In modena.css, for example, all
of the lookup properties are declared in the .root rule so this isn't an issue.
You could do the same or be more explicit in your rules by saying, e.g.,
.needle { -fx-fill: orange; }
.SimpleMetroArcGauge .needle { -fx-fill: -fxx-needle-color; }
In this way, a needle that is a child of .SimpleMetroArcGauge will pick up
-fxx-needle-color, but a .needle that is not will be orange.
On 4/9/15 11:11 AM, Tom Eugelink wrote:
Hm. That would mean this should work, but it does not. So instead of moving the
lines 216 and up to a separate file, I moved them to the front, but the
colorschemes are not working then. The lines must be after the first
(.SimpleMetroArcGauge) block. I don't understand why this matters, if it is
declaration based.
https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css
On 9-4-2015 13:34, David Grieve wrote:
Yes. The details are in http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here
is the excerpt that matters: " if two declarations have the same weight, origin and
specificity, the latter specified wins. Declarations in imported style sheets are
considered to be before any declarations in the style sheet itself."
On 4/9/15 1:42 AM, Tom Eugelink wrote:
Does the order in which things appear in a CSS have influence on the behavior?
Tom
On 8-4-2015 23:22, David Grieve wrote:
The spec says that if there is an @import it has to appear first before any
rule, except @charset, if present.
On 4/8/15 5:12 PM, Tom Eugelink wrote:
I'm currently porting and reworking some gauges from Enzo to JFXtras. One of
things that gets reworked involves that all gauges will have custom colored
segments. These segments can be preset using colorschemes (e.g. green to red in
10 steps), so the CSS for these colors are shared over all gauges. I tried
using @import, but since it is required to be the first lines in a CSS, I'm
suspecting that is the reason it is not working as expected.
Is there any intention to allow these imports to occur half way in a file?
Placeholder-and-replace alike (#include), so to speak.
Tom
