Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.


Seems like summer's almost gone now.

The students returned to Madison last week and treated the city to a very special kind of pademonium. Apparently everybody's leases end on August 14th and none of the new leases start until the 15th. As a result there are a couple of days where it's possible to decorate one's house/apartment/cardboard box by simply driving down the street and picking up the best of the discarded furniture (nestled among piles of various trash, rubbish, and junk piled on the curbs about knee deep). Every U-Haul, Ryder truck, and pickup in 20 miles must have been rented months in advance. The whole thing was totally surreal.

But that's all over now. School at UW started last week (as it did likewise at Purdue), and the visible signs of the students are all much more subtle: more supid drivers, more competition for parking spaces, etc...

I'm not sure if I'm excited about my first Wisconsin winter in 7 (8?) years or if I'm frightened that I've become so acclimated to warmer weather that I'll hate it. Goodness knows that I think Madison is a wonderful place, I'm just hoping I still think that when I'm fighting 2 feet of snow on my way to work.

I'm going to the Madison Blues Fest tomorrow, mainly to see Buddy Guy. I guess Lyle Lovett is headlining, but I just can't get into him. There's a local funk band that I'd kinda like to catch in person, but they're playing intermissions and I'm not sure if I want to get there at 6 when Buddy Guy isn't playing until 8. Either way, expect a full report soon = )

Dot Org

As noted on /., ICANN want's to give .org to these wankers. There was a time when the net wasn't being slowly eaten by corporate interests...I vaguely remember it, and I remember it being full of wonder and excitement.

But that's all gone now.

Weblogging has given voice to the little person again, but bloggers are only talking into their little corners. The net's core institutions are all being bought. Whole generations won't even have to worry about being disenfrachised; they won't have ever had a voice to start with. I can see it now:

Welcome to the internet!

please leave any preconceptions of self rule, democracy, fairness, and basic human decency at the door. Oh, and be sure to bring your wallet.

Thank you.

-- the management.

Split Pane Fixes

the split pane widget is fixed in IE 6. IE 5.0 is known to be broken, and IE 5.5 is unknown (but assumed to be working).


Victory is mine! (at least in mozilla).

getComputedStyle (on moz) and offsetHeight (proprietary MS bs) saved the day, allowing me to grab calculated height values for the main split-pane widget and use those to set a height value for the bottom pane in the horizontal configuration.

I have no idea how (or even if) the linked sample page is working on IE, so if you find that it's borked please let me know, providing browser version, your email address, and a general description (or screenshot) of the problem.

Now about that data table widget...

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.

Older Posts

Newer Posts