Dorothy Anna Ardisson, 1917-2009
Second Lieutenant, US Army Nurse Corps, World War II (March 1942-October 1945); service at Camp Patrick Henry, Virginia, and Oran, Algeria

Gerald John Ardisson, 1921-2009
Second Lieutenant, US Army Air Forces, World War II (March 1943-October 1945); service in the skies over France and Germany from Nottingham, England

As I said, though, we’ve been working on all sorts of things so far this year. Dan Weber has been hard at work on patches for some of the most visible issues with the new autocomplete experience, and I landed the fix for the magically-reappearing autocomplete window tonight. Dan is also still working on improving the speed of autocomplete for large histories, though that patch is not yet ready. Chris Lawson has also been working on various and sundry other bugs, including changes to the Flashblock exceptions list so that pasting URLs into the field will work as users expect. Philippe Wittenbergh is hard at work polishing some of our toolbar icons.

Christopher Henderson has been working on a patch that moves our history off of Mork, which is both the sane thing to do and critical for moving forward to the new Mork-less world. As usual, I have been chasing down bugs here and there and wrangling patches to get ready for the upcoming 2.0.2 and 1.6.11 releases. We’ve also seen Alex Jones, who has been working off-and-on on supporting Mobile Me sync, again recently, though it sounds like Sync Services wants to do things in a manner that is not easily compatible with Camino’s bookmarks implementation. All in all, we’ve been fairly productive since the new year began.

Which brings us back to the title of this post and to this weekend’s developments. Late Saturday afternoon, I got a debug version of Camino to build, launch, and run using Gecko 1.9.1, and early Sunday evening I was able to make a static (i.e., distributable) build do the same thing. (Even better, Christopher Henderson was able to replicate my success.) This feat would not have been possible without all the hard work that Christopher put in for the aforementioned history migration, as well as a good bit of debugging and patching he did this weekend as we hit some unexpected code-change-related build failures. After applying those patches, I mostly deleted and added things to the project and waited for the next build failure. At the end of the day, though, Camino launches and runs, plays <audio> and <video> (with Ogg), and displays pages with @font-face (with raw TrueType fonts).

This doesn’t mean that we can turn around and release a version of Camino based on Gecko 1.9.1 (and there’s a very strong possibility we may not); for starters, there are a number of known regressions (including the loss of Find-As-You-Type), as well as possibly hundreds of other serious problems we haven’t discovered in our limited test browsing. Beyond that, the “build system” is not yet a system at all; it involves pulling mozilla-1.9.1 from hg, checking out Camino from cvs into mozilla/camino, and applying a large patch. But if you’re brave or crazy, you can try this at home now (and for those less brave or more sane, there’s an Intel-only build here that you can use to help us find other broken things. N.B. You should treat this build as highly experimental. It might eat all of the cheese in your house. It will eat your profile, so make a backup copy first).

(Update 9 Feb: The patch above now has all of the required parts of the history migration, which had been missing from the earlier patch.)

We also know (thanks to earlier attempts by Philippe Wittenbergh and Kai Rune Mathisen to build mozilla-central) that there are more serious code breakages in newer versions of Gecko, so this is only the beginning. In between other things the last few weeks, I’ve also been working on a new repository and fleshing out issues and solutions for the build system. There’s a long road ahead, and Camino 2.1 might be ready before we’ve gotten to the end of the road; we’ll have to see. However, as Christopher said on Saturday night, “it’s been a great day in Camino Land.”

This news is a bit old now (since it appeared briefly on Planet Mozilla the other day half-buried in a PR round-up, and since reader James reported it in a comment on January 21), but FCKEditor is the winner of the 2010 edition of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest.

If you use FCKEditor on a site and it doesn’t work with Firefox 3.6 or nightly builds of any Gecko browser built since January 1, you’re probably seeing the bug that won FCKEditor this year’s prize with a stunning upset of two-time defending champion Yahoo!

My gut feeling is that this new type of contest winner is much worse than the old “major site is broken” type, since there is no single point of contact for the fix (everyone who uses the affected versions of FCKEditor will have to patch or upgrade their install), since unpatched instances of FCKEditor could break functionality on websites far and wide for years to come, and since in some ways the distributed nature of the problem means there is less visibility than when a major website suddenly ceases to work correctly.

I think this also highlights the importance of web “library” or “component” authors doing things correctly from the beginning—not browser sniffing at all, but instead testing for features—because their code will be used widely and, as I understand it, they have little control over getting consumers to update when there are fixes for broken things like this.

If you’re going to write something for wider consumption, or that you think may one day be useful to large audiences, please take the time to get things right from the beginning, especially if your code doesn’t have a dead-simple upgrade experience. Your users, and their users, and even other unrelated software vendors, will thank you for it later.

(And remember: only you can prevent broken browser sniffing! )

As I noted in January, the “three-peat” is Yahoo!’s to lose, although there was some talk last January of Yahoo! actually doing away with their date checking.

Get your picks in now for both the site/company that will break and the reporter of the Tech Evangelism bug who notices said site/company. (For the record, my picks are Yahoo! and Philippe Wittenbergh.) No actual prizes will be awarded, but both winners will be recognized in a future entry in this journal.

And remember: only you can prevent bad browser-sniffing!

Today the hard work begins.

For the second year in a row, Yahoo! is the winner of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing prize.

Congratulations to everyone who picked Yahoo! in the pool. Congratulations also to everyone who picked Philippe Wittenbergh as the reporter of the bug determining the winning website/company.

For the record, here are the past winners:

• 2008 – Yahoo!
• 2007 – FAA¹
• 2006 – AOL

Do you think Yahoo! will make it three in a row in 2010, or do you think the switch from “09” to “10” will trip up someone else?

¹ Honorable mention for 2007 goes to VersionTracker, who had a November 1 bug rather than a January 1 bug. ↩

In 1919, two Ardisson families gathered (probably on the family farm outside Delmont) to welcome John Ardison (center, between the two flags) home from his service with the American forces in World War I. The families of Steve Ardisson (my great-great-grandfather) and his brother, Tony Ardison, gathered around picnic tables, just as many of us do this day, for good food and family and to celebrate the safe return from war of John Ardison, Tony’s oldest.

I can’t tell you much more about this photo, only that it was probably taken sometime in the summer, as my own grandfather (born the beginning of May that year) looks to be several months old.

So as we sit at our own picnic tables today, let us remember those who have sacrificed for us and earnestly hope for a return like this one of 1919 for everyone still in harm’s way.

As I read the posts from his former co-workers and friends in the Mac community, I began to wonder…had it really been nearly 15 years since I’d started following the Mac web? I remember when MacCentral switched from publishing every-other-day to daily, I remember how MacCentral would always commemorate Remembrance Day (Stan was Canadian; it’s Armistice Day or Veterans Day to the rest of us), and I remember the tiny little icons that MacCentral used in the early days to help differentiate the story type.

In fact, it’s those little icons (part of a bygone era on the web, and perhaps happily so) that are the reason I’m writing this at all. Shortly after a redesign in which they disappeared, I sent a little note to MacCentral’s feedback address politely lamenting their demise. Much to my surprise, I later received a response from none other than Stan Flack, Publisher of MacCentral, himself. The email is lost to the depths of time, but I recall him thanking me for the feedback, explaining why the icons went away, adding that he missed them a bit, too, and he’d look to see if there were other ways to use them (or something to that effect). The top guy responding to inconsequential feedback himself. I can’t claim to have known him, but from reading what others have written, that was the kind of person Stan Flack was.

As for those little icons, maybe it’s just my mind, but I’ve always thought that MacCentral’s post-redesign site logo and, later, its site icon () were reminiscent of those little globe-like icons that made reading only the stories I was interested in so easy. Those days seem so long ago and far away now….

And so, feeling older and with a sadness over the untimely passing of one the Mac web’s pioneers and enduring figures, I offer my happy memories of one of the greatest Mac news sites during the golden age of the Mac web, and of the man behind it, and I offer my condolences to the family and friends of Stan Flack.

Posts from some of Stan Flack’s friends and former co-workers:

• Jim Dalrymple
• Dennis Sellers (the comments section reads like a who’s who of the Mac web of the golden age)
• Peter Cohen
• Ted Landau

Today marks the public release of iCab 4.0, which uses WebKit as its rendering engine. The accompanying notice urging anyone using Mac OS X 10.3.9 or higher to use iCab 4 is a pretty good sign that the iCab 3 rendering engine has reached the end of the line.

iCab 3 made its semi-public debut (to registered iCab users) towards the end of December 2004, with a completely rewritten engine that boasted of CSS 2.x support second-to-none and rendered the web as it was intended in 2004. Given the hype surrounding Safari’s support of the CSS text-shadow property in those days, iCab went one better and supported the property more correctly and completely.

Other things I remember about iCab 3.0’s HTML/CSS support were the inline-block property (not available in Gecko until the forthcoming Gecko 1.9) and proper rendering of the <q> element per-language, with no additional work required by the author (which neither Gecko nor WebKit could do) beyond actually specifying the language of the element. And, unlike in WebKit or Gecko, text content inserted via CSS pseudo-selectors (like properly localized quote marks, necessary for correct display in WebKit and Gecko) was selectable and copyable, so none of the content, which was unfortunately shoehorned into presentation to work around other bugs in those rendering engines, would be lost.

To be sure, iCab 3 had its fair share of bugs, some of which persisted right to the end. Nevertheless, the belated appearance of iCab 3’s first semi-public preview (some two years, I think, after its first announcement as iCab 2’s forthcoming successor) turned a lot of heads. Beyond saying ”you can no longer write iCab off as a ‘not a modern browser,’” iCab 3 ran on versions of the Mac OS as old as 8.5 (yes, that’s the “classic” Mac OS; 8.5 was released in October of 1998), promising modern browsing to all PPC Macs (the first of which were released in April 1994!).

The other notable feat accomplished by the iCab 3 rendering engine was to become the second rendering engine, and the first to release a semi-public or public build (available to all registered users on May 20, 2005), to pass the Acid2 test of various web standards in May 2005.

Having laid out these feats of strength, it is time to remind everyone of the most shocking fact about iCab: all of this was done by one person, Alexander Clauss.¹

In spite of all the obstacles the modern web threw at browser developers, the fact that one man could single-handedly write an entire rendering engine that “kept up with the Jonses” and ran natively on Mac OS 8.5-Mac OS X 10.5 inclusive is nothing short of miraculous.

iCab the browser UI was never a thing of great beauty, but it was functional and included innovative features, many of which, to my knowledge, still have not been copied.

• Most renowned for its powerful if clumsy filter manager, iCab was one of the first to provide configurable ad, script, and pop-up blocking.
• iCab also could detect if a local web page you were working on had changed and would reload it automatically, which shaved hundreds of thousands of keystrokes or clicks off of website development. That, and the built-in HTML checker (behind the famous “smiley”) made iCab an author’s friend.
• iCab also was a pioneer of an “open,” portable web archive format; unlike Gecko, iCab didn’t rewrite pages, forget to include referenced files, or require collecting files and folders before transfer, and unlike Internet Explorer, an iCab web archive was a .zip file that could be carried to any computer, unzipped, and used effectively.
• iCab’s download manager was homely and complex, but it was one of the first web browsers to support resumable downloads (by contrast, the forthcoming Firefox 3 will finally support this feature). You could also choose to “download” all or part of a site, either as individual pages or as a web archive.
• iCab got “don’t load images”/“load images” correctly; it was possible to turn off image loading by default and then load individual images if desired, something modern browsers have forgotten. And iCab’s “offline mode” was actually still functional in the mid-2000s.
• One of iCab’s more recent innovations was the ability to visually indicate the target of an anchor when arriving via a link (e.g., the footnote link above that points to the footnote anchor below). Proposed in the iCab mailing list by user Daniel Beardsmore, this was implemented in iCab 3 as a light blue bar that fades out over the location of the anchor on the page.

All of this while keeping up with the ever-changing world of rendering web pages.

Amazingly, it seems most of these browser features have been tacked on to the new WebKit-based iCab 4, and perhaps freed of the job of writing a rendering engine, Mr. Clauss can continue to innovate more quickly—if fighting the quirks and bugs of three versions of WebKit doesn’t eat up this time.

In the end, the waves of browser sniffing that plague “Web 2.0” and a slow and somewhat buggy Javascript/DOM implementation (technologies on which “Web 2.0” is built) likely proved too much for iCab’s home-grown rendering engine.

Still, it is a day of sadness for the three-year life² of one of the most amazing rendering engines the world has ever seen—and for the end of browser development for the classic Mac OS. Let us raise a glass to the passing of one of the last independent rendering engines, to its successes, and to the good years of browsing it gave us. Adieu….

¹ iCab 3 used the external InScript JavaScript engine, written by Thomas Much. ↩

² The iCab rendering engine is much older, of course, originating in CAB on the Atari (TOS) in the mid-90s and arriving on the Mac in late 1998/early 1999. Similar to how Gecko was an entirely new rendering engine than the engine in Netscape 0.x-4.x, it’s exceedingly likely that the engine in iCab 3 shared nothing with its predecessor, save for the fact it powered the iCab browser. ↩