Structuring CSS Stylesheets

Kevin Rushforth kevin.rushforth at
Mon Aug 15 16:02:27 UTC 2016

One slight correction on how to contribute below.

David Grieve wrote:
> On 8/15/16 10:52 AM, Daniel Glöckner wrote:
>>>> We found the culprits by patching the JRE, adding some statistics to
>>>> SimpleSelector and CompoundSelector. I was wondering whether there are
>>>> easier ways but anyway, it works ;)
>>> This sounds like some code that would be good to share with the 
>>> community. :)
>> [DG] Sure thing. It's not too complicated and doesn't use external 
>> libs. Any hint where I could post it / paste it?
> See for how to 
> contribute

That page is just a placeholder, and finding what you need in the 
sub-pages a bit tricky. See the following page for how to contribute:

-- Kevin

>> need them, for example our UI component factory would add table.css to a
>> TableView's list of stylesheets (tv. 
>> getStylesheets().add("/path/to/table.css").
>> The global theme.css would be minimal and only define colors and fonts.
>>>> What do you think about this approach? Will this work nicely with 
>>>> caching of
>>> CSS styles in JavaFX?
>>> I think if you are going to go this route, you might want to use
>>> Region#getUserAgentStylesheets() which adds the styles as user-agent 
>>> styles.
>>> But I don't think it will buy you much in terms of CSS performance.
>> [DG] We also want to control / override the CSS of standard JavaFX 
>> controls like TreeTableView. Ideally we don't need to sub class them 
>> so we would need to use parent. getStylesheets().add(), right?
> I doubt that getUserAgentStylesheets() or getStylesheets() is going to 
> have much impact. My guess is that having the stylesheets added to the 
> scene is going to be your best bet. I say this because the code that 
> does the style matching has to combine styles together from 
> Region#getUserAgentStylesheets() and Parent#getStylesheets(), whereas 
> the styles from scene stylesheets are already combined. You have to 
> think of these different sources of styles as sets of styles. When you 
> have Region or Parent stylesheets, you have to create a union of those 
> styles with the default user-agent stylesheets (e.g., caspian.css). 
> With just scene stylesheets, you have just one set (this isn't 100% 
> accurate, but close enough for this discussion).
>>> If you the biggest bang for your buck relative to JavaFX CSS 
>>> performance, avoid
>>> style lookup and relative font sizes.
>> [DG] Could you explain what you mean by "avoid style lookups"?
> You know about styles like '-fx-base' used in caspian.css. You change 
> the color for -fx-base and the basic colors of the UI change. This 
> magic happens at runtime. So if I have a label in a cell in a table, 
> and it has a style "-fx-border-color: -fx-base", JavaFX will - at 
> runtime - try to resolve -fx-base into an actual color. It starts at 
> the leaf and looks tries to resolve -fx-base. If it can't resolve it, 
> it looks for a style in the parent node, and so on up the parent-chain 
> all the way to the root node. The worst case scenario, then, is that 
> there are no styles that resolve the value until you get to .root.
> This is what I mean by 'style lookups'.
> Its great stuff (the brainchild of Jasper Potts) because I can change 
> the look of my UI just by setting '-fx-base'. But if I were developing 
> a UI and I didn't care to let the users of my UI make such changes, 
> I'd go through and remove all the lookups in caspian.css (not trivial 
> because there are many many lookups - not just -fx-base). Or use a 
> pre-processor such as SASS or LESS.
> The same sort of lookup happens when you have an em (or other relative 
> size) because you need a font or a font-size to complete the 
> calculation. In most cases, the lookup for a font or font-size goes 
> all the way to .root, where it fails and falls back on 
> Font.getDefault(). But its a trade off since em sizes let your UI more 
> easily scale to different displays.

More information about the openjfx-dev mailing list