On Thu, 15 Jan 2026 19:24:53 GMT, John Hendrikx <[email protected]> wrote:
> Are you referring to media queries for the window size when you say that > sizing can influence styling? The others can be resolved similar to how > `ScrollPane` does this (see below). Yes, but also in a more general sense. Applications might also manually add or remove style classes depending on the size of controls. > I would say that there's also two passes in FX, although less obvious. The > first pass is basically the calling of the compute methods. These cascade > down all the way down to the leaf level as each compute will call child > compute methods (but can use cached results) before any layout methods are > called (apart from the root one). I'm not sure what that pass should be > called, but it does sound a lot like what WPF is doing. Only after this does > the layout pass cascade down again via the layout calls. That's true, but it's also less powerful than a dedicated two-pass approach. The main difference is that WPF/Android communicate down constraints to children during this first pass, asking: "given my available size, how large would you like to be?" The compute methods of JavaFX don't communicate any information from parents to their children, which is why children can't change their answer depending on the constraints imposed by their parents. > `ScrollPane` handles that in one pass. Basically it computes the size of the > children, and if it determines there is need of a scroll bar, it does those > calculations again (which can result in the appearance of the 2nd scrollbar, > and the calculations are repeated one more time; this is quite visible in > `ScrollPaneSkin`). In effect, it solves this problem internally without > waiting for another layout pass, as compute methods can be called as often as > desired. > I think doing a loop of layout passes up to a limit is fine, although I'm not > sure if CSS needs to take part in that. One should not be changing styles > during layout, that's a pre-layout concern (which is before CSS runs) and not > something to do in the `compute` chain of methods nor the `layoutChildren` > methods. Let's assume a control where the number of children depend on its size. Maybe it arranges a set of nodes that it was provided with in some way, and fills the remaining "unused" slots in its layout with placeholder nodes. This implies that the control only knows how many placeholder nodes it needs after it was laid out. Adding those nodes after the layout pass is done means that they now don't have CSS styling. I think a case like this is already accounted for in the existing layout system, but solving this correctly in an iterative system probably means that CSS needs to be part of the loop. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3756800084
