> > > Why does TablePane override the preferred size of the Border element? > > Because you gave the first column and row an explicit size. Try removing > width="100" and height="80" (or replace them with width="-1" and > height="-1"). That will tell the column and row to use their default sizes.
But that's exactly my point. TablePane has an implicit "fill" behavior in each of its cells. True, it figures out the size of a "-1" row or column by taking the maximum of the preferred sizes of its elements. But once it's determined the row/column size, either that way or by using the TablePane size declarations, it forces *everything* in the row/column to "fill" the orthogonal dimension, totally ignoring any preferred sizes given. Hence, my question, "Would it make sense for an explicit preferred width/height on a component to trump fill?" I used TablePane as an example, because it has that implicit fill behavior I mentioned, not controllable by the user. But it's not the most compelling usage case, since if I wanted a cell's content not to fill, I would most likely also want to specify how the content should be aligned within the cell, something I can only do today by wrapping it in a BoxPane. And since you think of alignment as a style property, I can't even propose having an attached property to handle that. A vertical BoxPane with fill=true is perhaps a more compelling usage case. It would be nice if I could have such a pane fill, so that my paragraphs of text could wrap, but still be able to not have other components stretched to the full width of the pane, as I was trying to achieve in my original example but was forced to wrap in a BoxPane to kill the fill. Another variation on that can be found if you try to extend the Forms tutorial a bit. Form does not by default fill horizontally. But if I wanted to intersperse explanatory paragraphs of (wrapped) text, or have a free-form TextArea, I would have to put fill:true on the Form. And yet I might still want some of the form fields to remain at a shorter width lest they look ridiculous (e.g., if zip code got its own line). This case is a little more complicated, because the width of (many of) the TextInput fields is given by a textSize property, rather than a preferredWidth. But TextInput must be using textSize internally to infer a preferredWidth when combined with the style's font size.
