With all due apologies to Bill Bruford (and the rest of Yes)

Yes, Fragile, 1971Endure it if you dare.

Things were just different back in 1971. And if you don’t believe me, consider this: a very successful rock album from that year was Fragile by Yes.

This album contained not only three tracks near or longer than eight minutes each, but five brief tracks that were the individual creations of each member of the band. Some members were not so enthusiastic about this approach, most notably drummer Bill Bruford, whose contribution was an awkward, 37-second noodlefest for drums, guitar, bass, and organ entitled “Five Per Cent for Nothing” [sic, although apparently that’s how they spell it in Britain].

Only 37 seconds, you say? Or more to the point, only five percent, you say? I have now attempted to rectify that shortcoming.

The piece as it originally appears consists of a complex rhythmic pattern, played through twice by the band. Well, if twice through constitutes five percent, simple arithmetic tells us that 40 times through will yield the full 100%. (It also clocks in at a pleasing 11:11.)

So here you go…

[audio:http://blog.room34.com/wp-content/uploads/underdog/100pct.mp3]

If you like/can tolerate this, I encourage you to consider purchasing the full album. (For what it’s worth, I myself have purchased it in one form or another no less than seven times.) It features some outstanding playing and great songs, including my favorite piece of music in the history of human civilization, “Heart of the Sunrise.”

But if you’re in the market for something a little more current… a little more seasonally-appropriate… a little more ridiculously titled, then I would steer you no further than to Chris Squire’s Swiss Choir, a drunken joke new Christmas album featuring Yes bassist Chris Squire, drummer Jeremy Stacey (formerly of Sheryl Crow’s touring band and more recently of the briefly-reformed-and-now-once-again-defunct lineup of Squire’s pre-Yes band, The Syn), and ’70s-era Genesis guitarist Steve Hackett.

Normally I would look at something like this and think, “Mannheim Steamroller, but somehow, incomprehensibly worse.” And yet, from the samples I checked out online, it’s surprisingly not complete shit! “Complete” being the operative word. When I emailed a friend about this album, with the subject line “Holy crap,” he replied “I think you have just come up with the perfect two word review for this album.”

If by any chance you do choose to purchase it, I would implore you to consider doing so via this link to the iTunes store, so they’ll know who recommended it! (OK, they won’t. But at least I’ll get a tiny piece of the action.)

Thanks, Bill… this is just how I wanted to spend my Saturday

Bill, I really don’t have time for this.

Internet Explorer 6 is incapable of properly rendering CSS applied to a <div> tag when the only child element in the <div> is a table. It sticks arbitrary margins in the document below the table. Here’s an example from a site I’m working on (colors removed to [sort of] protect anonymity). This is how it should look, as rendered by Safari:

Safari screenshot

The concern is the content in the dark title bar. The bar itself is a <div> and the two buttons plus the month/year text is contained in a table. Here’s how it looks in Internet Explorer 6 (note the gap below the header bar):

Internet Explorer screenshot 1

OK. So let’s see, maybe there’s a semi-logical CSS workaround. I already have margin: 0 defined for the class the <div> uses. So I added it to any tables contained within that class as well. No luck. Then I did something really off the wall and added a display: inline property for tables contained in that class. It still didn’t work. So then, appropos of nothing, I added a &nbsp; just so there would be something in the <div> besides the table. And here’s the kicker… I actually added it before the table (retaining the display: inline property of the table:

Internet Explorer screenshot 2

Once again, it’s good that the windows in my office don’t open, or there would be one less PC in this building right now.

Of course the &nbsp; solution is not satisfactory to me. The search goes on. Because, you know Bill, I really have nothing better to do when I’m working on a Saturday morning.

At this point another alternative occurs to me: it’s possible to use the CSS float property to position the buttons and eliminate the table altogether. That fixes the problem in Internet Explorer, but…

Steve, I’ve got a few words for you as well! Look what happens in Safari when I remove the table in the header:

Safari Screenshot 2

Sure, that makes perfect sense. Especially since I have a width="100%" attribute right there in the calendar table. Oh, and did I mention that the width of the panel body is explicitly defined in pixels in the CSS? How is it, how can it be possible, that removing a table from a separate (albeit adjacent) <div> could affect the width of this table?

Now where’s my glass cutter? I think there are one too many PCs and one too many Macs in this office.

After a bit more head scratching, I’ve discovered that the cause of the Safari issue is that I neglected to remove the aforementioned display: inline property I added to my CSS in the midst of the numerous futile experiments I undertook to resolve the initial IE problem. Steve, you’re off the hook.

So, in the end, it turns out that the solution to my problem is to abandon the old-school table-based method of layout and go strictly CSS. I’m sure that’s precisely what Bill wants me to do.