@import in CSS

[Tom Eugelink]

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
>>>>>
>>>>
>>>
>>
>