Infrequently Noted

So the product I work on (Jot), is a fine peice of engineering. Like many excellent engineering projects, Jot builds on a the tools that are available today and extends the state of the art significantly. In this case, the foundation is Java.

Now, I've ranted about Java before, and I probably will again, but my experiences of the past couple of days are particularly memorable.

Firstly, let me say that I love SuSE 9.3. It's wonderful. Like most SuSE releases, it comes on DVD which makes installation a snap, and with each new version of KDE, my Linux UI experience keeps steadily improving. It's not OS X, but that's what the PowerBook (from which I am now inseparable) is for. For servers and Linux desktop use, this is the distro I want to be toting around and passing off to friends. It just freaking works.

Ok, nicities out of the way, who in the hell let Java ship on ANY platform with this bug?

In trying to get my CVS environment set up on my brand-new SuSE 9.3 install, Eclipse (don't ask) kept crashing. Changing the (opaque) JVM options didn't help (-server is always a good place to start for HotSpot SNAFU's), and specifying interpreted instead of JIT mode had no effect. Let the googling comence!

Turns out that there are no non-Sun-provided RPMs for a fixed JVM and that the only fix available is to upgrade to 1.5/5.0. Deeply sub-optimal.

90meg and a ton of manual symlink foo-baring later, Eclipse no longer craters on me, but the question still remains: how did this get out the door and why isn't it fixed everywhere already? Sun? SuSE? Anyone?

I think I've just stopped reading blogs entirely at this point. After getting back from a week on vacation, I've been absolutely buried in work since then and it's funny and strange to me how quickly I can stop caring about reading blogs, even ones I really really like.

Seems they're just not that important.

After having suffered without spam filtering due to various misconfigurations, I finally upgraded to SpamAssassin 3.0, and I'm freaking overjoyed every time I look at my inbox.

Knowing that you have mail that's relevant is an amazing feeling once you've gone without it for any period of time.

WTF were they smoking over at the CSS 2 working group, anyway?

I wish I were more than half kidding, but every time I consider what the recommendations for DOCTYPE are going to be for application authors using Dojo, I wince a bit and mutter something vaguely obscene about crack-smoking monkeys.

The problem oddly enough starts out with good news: browser manufacturers have finally (largely) been cowed into implementing the most broadly useful portions of the W3C's CSS 2 spec. For the most part, there is much rejoycing.

For the most part.

Once upon a time (as I was graduating from high school), the W3C CSS working group published the CSS 2 box model, which the WinIE team blithely ignored. Whatever the reason, the fact that MSIE calculated boxes one way while better browsers followed the spec to the letter caused web developers no end of sleepless nights. The answer seeemd easy: just get Microsoft to change their errant ways, and then the problem would be solved for good!

What no one bothered to mention at the time was that the box model that MSIE had been implementing was vastly simpler to use, required less head-tiling and forhead-to-desk banging. It was, in a word, better. But instead of pushing to get the spec changed, the web standards community pushed to get the browsers changed, and mostly succeeded. The mountain had been moved, but the new location wasn't much better than the old one. IE 6.0 (PC) finally included an implementation of the W3C box model, but in Microsoft's infinite wisdom, decided that the way to enable it would be for a page author to declare that their document in all other ways adhered to W3C standards by sending a "standards mode" DOCTYPE. This would be all well and good had things continued to improve in the specs and the browsers, but it wasn't to be. With the release of IE 6.0 for the PC, Microsoft had killed off the competition and considered the world safe once again for onerous licensing fees on bug-ridden dekstop software. The IE team was disbanded.

Meanwhile, the W3C stopped doing anything useful too. Distractions like XForms, XHTML 2.0, and other "wouldn't it be great if we could make web developers disappear!?" specifications creaked slowly out of an organization that lived on like so many figurehead monarchs in european democracies. And life might have been OK in this state as well, had XHTML not turned out ot be incredibly useful. You see, it's not that humans shouldn't be involved in designing and wiring together the bits and peices of web UIs, it's just that users in the next "generation" of the web have turned out to be the most important source of content, which means that the tools they use need to be more automated. XML had finally found a calling for which it wasn't a solution in search of a problem. Systems that process XML in arbitrary dialects can transform them to XHTML with XSLT or other processors and automatically generate web content from input formats that users are better accustomed to. Better yet, XML turns out to be a great way to aggregate and re-disseminate that content, and XHTML is the most straightforward resulting format since the same tools can be reused to generate and manipulate both the source and the destination formats. So where's the problem?

Sadly, MSIE 6.0 treats well-formed XHTML documents as "strict mode" documents without exception, thereby imposing the broken W3C box model without providing an escape hatch. In the interem 4 years, the CSS working group has recognized their blunder and proposed a fix which every other browser manufacturer implemented faster than you can say "oh thank Hyatt!". But we're not in the clear yet. Thanks to IE's "all or nothing" standards compliance approach, DHTML toolkits like Dojo are left high and dry. We can either recommend to end users that they build widgets which do not rely heavily on claculated formatting (a non-starter), "fake it" on IE and suffer severly degraded performance (the norm), "snif" browser on the server side and send a "quirks mode" DTD to IE, or simply serve up HTML 4.0 content to everyone and employ "border-box" sizing on the browsers that provide the explicit switch to do so. Nary a good choice in the bunch.

As a result, we're going to be recommending the use of a broken DTD for pages serving up the stock Dojo widgets, and I don't envisage a future that doesn't include this kind of outright hackery (at least not in the next half decade). IE 7 is the punchline to a running joke, and it's not even into Beta yet, meanwhile IE 6.0 controls 90+% of the browser market. The only thing that's going to change that is Microsoft's draconian licensing and time. Lots of time.

At least CPUs will keep getting faster so our IE 6.0 box-model contortions might run acceptably fast by 2008. I hope.

Now that it's finally been mentioned on NG-DHTML, I guess I should publicly rescind my vehement opposition to the term "AJAX". Frankly, it's a better name than anything I've come up with, and it's got traction. If it helps people forget "DHTML", so much the better.