Infrequently Noted

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

Safari and KHTML

This does not surprise me in the slightest.

I have been subscribed to the KHTML development mailing list for several years now, and every time a new public WebCore is released, Apple sends along a changelog and a tarball, and that's about it. The first time it happened, the KHTML guys were overjoyed to be getting patches and spent a great deal of effort and time in getting a lot of the changes backported and getting the diff size down, but the second and 3rd times....well, getting help in the form of a shotgun to the head gets old pretty quickly.

This isn't to say that Apple hasn't gotten better. The Apple WebCore guys are now significantly more active on the lists than before, and large changes tend to get discussed more in the open, but huge diffs continue to land and the patch backlog is ever-increasing. I don't think the state of affairs is tenable, and Apple (since they're the offending party here) has two choices as I see it:

  1. suck it up and decide to live on KDE HEAD and submit patches for review like everyone else
  2. fork


I'm mildly in favor of the first, since the second is essentially where Safari is at now, and it's not working. Either way, I think both sides should drop the charade. If Apple is going to do Open Source the right way (which is how they do so many other things), then they need to participate as first-class citizens and drop their private branch for non Apple-specific features.

a small story about Java

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?

blogless

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.

begone, vile spam!

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.

on box models

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.

Older Posts

Newer Posts