JavaFX beware of spaces in style classes

So here’s a trap I got caught out by today.

When adding a style class to a JavaFX Node you would do the following:

myNode.getStyleClass ().add ("mystyle");

However, JavaFX, when it is looking to apply styles, treats each entry in the style class list as being its own style class.

In short,

myNode.getStyleClass ().add ("mystyle myotherstyle");

will produce different results to:

myNode.getStyleClass ().addAll ("mystyle", "myotherstyle");

JavaFX treats “mystyle myotherstyle” in the first example as the style class id, the second example has two style classes “mystyle” AND “myotherstyle”.

In the first example this means that:

.mystyle.myotherstyle { -fx-padding: 1em; }

would not be matched, even though if you’ve experience with HTML, it intuitively should.

Of course this is NOT how CSS style matching is supposed to work and is a fault with how JavaFX applies its styles. You can’t mimic HTML CSS and not apply it the same way guys!

Since this style could never be applied there should be a guard on the style class that will throw an error if you try and add a style class that contains spaces.

Addendum

I tried out some other cases,

myNode.getStyleClass ().add ("mystyle.myotherstyle");
myNode.getStyleClass ().add (".mystyle.myotherstyle");

neither will match (although I wouldn’t expect them to, well maybe the 2nd should) but again there should be a guard in place to tell you that you’re using an invalid style class.

In fact it would be nice to have a:

public void setStyleClass (String v);

convenience method that allows you to pass a single string for the style class, this would then allow you to more closely match what is in your stylesheet.

3 thoughts on “JavaFX beware of spaces in style classes

  1. alucardnoir

    To be fair, the way JavaFX does it is how it should be done.

  2. Sort of, but it irks me because it’s not enforcing any rules. Style classes are a bridge between the text stylesheet and the code, as such there needs to rules enforced on the developer to ensure that they don’t make these types of mistakes. XML/JSON parsers do this by default, compilers do the same. I’d be happy for JavaFX to take this approach but it can’t put all the responsibility on the developer, there needs to be some enforcement of its rules. Consider that the getStyleClass returns a List but the actual order of the style classes is irrelevant, this alone breaks normal code conventions where a List indicates that ordering does matter (compared to a Set where ordering is implementation specific). The List was used for convenience of the API developer not the API consumer.

    The more I use JavaFX the more I get the feeling that a number of areas were rushed and half-baked and no one has returned to sort it out (a not uncommon thing with code). The whole CSS styling is one such area, the way JavaFX defines styles is mindbogglingly, needlessly, complex. Also the way it applies styles is simplistic and hasn’t been optimized, I’m currently chasing down a number of performance issues related to styles. Grr…

    1. alucardnoir

      I mean… that first paragraph is more an argument against CSS then it is one for it’s correct implementation. As for the second paragraph… it’s JAVA, people have been complaining of JAVA’s poor performance for a quarter century now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: