None of It
I've spent roughly 12 of the last 24 hours attempting to coax the split-pane widget into doing my bidding, but it's apparently having none of it.
The problem:
Friday morning as I showered, I realized that I could replace a large chunk of the code in the data table widget by using a horizontal split-pane with a fixed size top pane. The only problem with this plan was that upon further examination, I realized that the CSS formatting of the split-pane widget was, um, not working right.
This in mind, I had at least 2 problems (up from one and change). I'd feel like quite a pud shipping a broken split-pane widget, espically after the 13p article. Resolved to fix the split-pane widget, I attempted several iterations using relative and absolute positioning, tables, and just about everything in between. The primary problem is that the widget attempts to fill it's container without knowing anything about the dimensions it is supposed to fill. While this isn't a problem when splitting in the vertical direction, it becomes an issue when splitting in the horizontal.
Using divs with their "float" attribute set to "top" and "width" set at "100%", it's possible to create an arbitrary set of horizontal blocks that will fill their container both vertically and horzontally. To split in the vertical, set float to "left" and "height" to "100%" instead.
The split-pane widget uses this technique to create 3 divs: one for each of the "panes" and one for the draggable bar in the center. The first pane (either leftmost or topmost) will have it's primary dimension (the dimension not set to 100%) set to some value in pixels, while the bar will have an appropriate width or height specified. The other pane div should then fill in the rest, allowing us to resize both of the panes by simply changing the primary dimension on the first pane. None of the panes have to know how big their container element is. In fact, the container may not have explicit dimensions set, and it's this scenario that occurs frequently in netWindows, as that's how the internal space of the window widget is constructed. "windows" are simply tables with their middle row's height set to "*", therefore there is no pixel value to consult for height.
This layout approach works like a charm when the pane set is constructed to vertically split a space, but when splitting in the horizontal, content longer than the height of the bottom pane (the top pane is fine) spills out of the bottom of the panes, irregardless of how the "overflow" property is set. The only way correct this is to set a "height" value for the bottom pane, but this requires knowledge we don't want to need to know: the height of the container (and the continued height of the container of it changes).
Several solutions exist to this problem, but I like none of them, as they require that the pane set know it's container and that the container have an explicit height value set. Mozilla's getComputedStyle seems to provide an "out" to the 2nd condition, but the first still nags a bit, not to mention that getComputedStyle isn't available for IE.
Looks like I'm going to have to add a bit of hackery to the pyMail app after all. Oh how I wish it could have been avoided.