JavaFX Form Validation

Richard Bair richard.bair at
Fri Jun 15 14:53:46 PDT 2012

Presently we have the following impl_ methods for dealing with pseudo classes:

    protected void impl_pseudoClassStateChanged(String pseudoClass)
    public long impl_getPseudoClassState()
    private static final long HOVER_PSEUDOCLASS_STATE = StyleManager.getInstance().getPseudoclassMask("hover"); // and so forth

So what happens is if a class has a custom pseudo class state, it has to fetch a mask for it such as in the HOVER_PSEUDOCLASS_STATE example. Whenever it detects that the pseudo class state has changed (for example, "hover" boolean changes) it invokes the impl_pseudoClassStateChanged method, which asks CSS whether this particular node has a style that depends on that pseudo class, so that it only requests CSS to be reapplied if there is a style change involved (avoids us having to recompute CSS when "hover" changes if no style for the node cares about "hover").

The CSS engine then, when applying CSS, asks the node for impl_getPseudoClassState which returns a long which is the mask of all pseudo class states that this node is in. This allows for a very fast match as to whether a style applies to this node or not.

So the short answer is we cannot have dynamic pseudo classes without sacrificing performance. Either we use a BitSet instead of a long, or we have to go to using set.contains() (which would kill us).

The longer answer is that we sort of need to support custom pseudo-classes at some point, but maybe I'm not sure how to do so without hurting performance.

For those interested, all the CSS code is part of javafx-ui-common in the open source code and the code above is found in Node. Between Node, Parent, Region, and Control you should be able to know as much of how this works as anybody (StyleManager and StyleHelper are the other two guys really worth looking at. It isn't easy to read because of the amount of performance tuning / fast paths / caches that have gone into this).

Now our goal was for Lombard to have public API so that UI control authors could add custom pseudo-classes. SO that basically means the impl_ methods will for sure be changed between now and then, but you can see how the mechanism works and supply patches if you like :-)


On Jun 14, 2012, at 12:45 AM, Daniel Zwolenski wrote:

> Would it be possible to attach our own arbitrary pseudo classes to controls via code?
> Eg. Button.setPseudoClass("highlighted")
> That would then cover the error case and much more. Eg I might have 'error', 'warning', 'required', 'highlighted', etc. 
> I do not know if the CSS engine will be able to handle this. 
> On 14/06/2012, at 5:19 PM, Gerrit Grunwald <han.solo at> wrote:
>> +1
>> Am 14.06.2012 um 08:37 schrieb Claus Luethje:
>>> +1
>>> -----Original Message-----
>>> From: openjfx-dev-bounces at [mailto:openjfx-dev-bounces at] On Behalf Of Werner Lehmann
>>> Sent: Mittwoch, 13. Juni 2012 17:58
>>> To: <openjfx-dev at>
>>> Subject: Re: JavaFX Form Validation
>>> +1
>>> I think it could be useful to have a css pseudoclass for controls with invalid state.
>>> Rgds
>>> Werner
>>> On 13.06.2012 15:23, Daniel Zwolenski wrote:
>>>> My vote is for JFX to provide low level building blocks for developers 
>>>> to hook in to and then for open source tool kits (like
>>>> Jfxtras) to provide the higher level tools. So JFX would have no 
>>>> validation framework but instead would provide ways to, for example, 
>>>> visually highlight nodes, and a community built toolkit would use this 
>>>> to provide a validation framework.

More information about the openjfx-dev mailing list