A New Antipodean Free Software Outpost

Yesterday a Telecom engineer managed to connect some wires in the new office to a live phone line, so today we moved into 8 Kent St. I'm really excited about this. It gives us a lot more space and the location is great. We celebrated the move with lunch at the fabulous Hansan Vietnamese restaurant in Nuffield St. (I can't recommend that place enough --- cheap, tasty, filling, and great milkshakes!)

As you can see from the photos below, we still have quite a bit of unpacking to do, plus we need to buy some items and clean things up a bit. We also need to settle the all-important question of where to put our "Fathead" four-foot Firefox logo sticker.

Michael Ventnor arrived on Saturday from Brisbane to work full time with us for the summer, probably focused on Linux chrome. He certainly picked an interesting week to arrive!

In the picture below, our office is on the second floor from above the "8 Kent St" sign to the rightmost end of the building. Yes, we could open those doors but we haven't figured out a use for them yet! There is not a ten-pin bowling alley above the office, that's another building and I think the bowling alley has been replaced by a car park.

Here's the main room of the interior. Clockwise from left are Michael Ventnor, Karl Tomlinson, Chris Pearce and Matthew Gregan. Chris Double was out; I'll try to get a better group shot tomorrow when he's around. There's a meeting room behind the partition on the left and there's additional space where I'm standing, beside the high-altitude doors in the first photo. Looking out from those doors (to the right of this photo) you can see in the distance the summit of Mt Eden and also the towers of the main Auckland Grammar School building (my old high school!). I'll get a photo of that.

Gripping Reality

Just watched Normal Again --- brilliant television. It made me wonder, if I was faced with two competing realities each claiming that the other is my delusion, how could I determine which one is real?

Here's an idea. Make up a very large number and ask one's friends in each world to factorize it in a reasonably short amount of time. You can check the answers manually via simple arithmetic. The inhabitants of the real world have access to computers and will be able to give a correct answer. The inhabitants of the imaginary world will not. (I'm making some reasonable assumptions, e.g. that my mental illness does not grant superhuman cognitive abilities or force me to cheat on multiplication!)

This probably would have worked for John Nash too. Who would have suspected that cryptographic primitives would be useful for psychotherapy and metaphysics!

Pegs, Holes And Reflow

I already blogged about Gecko's frame continuations being a mistake. It's time to rant about another big layout design error: the uniformity of the Reflow() API.

During layout, frames (i.e. CSS boxes) call Reflow to lay out their children and then position those children in some manner. The core problem is that Reflow's signature is the same for every frame type. That means that in theory, table frames have to interact with their row(group) frames in exactly the same way that inline frames have to interact with their inline children, or XUL boxes have to interact with their box children, etc. But this is nonsense, since the invariants, dependencies and data that need to cross the parent/child boundary are entirely different in each of these cases.

So in practice we have various kinds of magic probing and/or magic fields of structures that are only used in certain cases. This inevitably leads to breakage and overcomplex code. Problems are particularly acute in line layout, where we really would like to work with a flattened list of inline leaf items, but thanks to Reflow we can't. The textrun work has moved us to a situation where we construct a flattened representation of at least the text of a paragraph for line breaking and text shaping, and then we pull data from that in a hokey way as we Reflow text frames. It's somewhat painful as the two traversal models fight each other in nsLineLayout. Of course the aforementioned frame continuations crash the party too.

What we really should do is admit that parent-child frame type pairs are actually tightly constrained, i.e. an inline frame can only have an inline parent or a block parent, a table row frame can only have a table rowgroup parent which can only have a table parent, etc. (These invariants already exist actually, although the code sometimes doesn't want to admit it.) Then we should toss Reflow over the side and give each frame type its own specialized layout interface. Only a few frame types (e.g. blocks and tables) would be able to occur in "unknown" contexts and offer a generic layout interface.

In fact, we could go further and specialize further the types of child frames or even get rid of a uniform nsIFrame tree altogether. There's no particular reason why it makes sense to have tables, table rowgroups, table rows and table cells all be the same kind of object as text frames or SVG frames. Sure, we want to be able to iterate over CSS box tree geometry and style somehow, but there's a whole lot of generality exposed in nsIFrame that doesn't really make sense everywhere.

As an aside, the conflict between textrun layout and inline layout is an example of a general problem I've seen with cleaning up code. You rework module A to make it nice and clean, but because modules B and C are quirky, you have to add complexity to module A to keep things working and shippable. Eventually you rework B and C too but A's already been contaminated, so B and C inherit some of the sins of their fathers. You can reduce the effect by enlarging the scope of rework, but that adds risk and schedule issues of course --- in the limit you rewrite everything and sink your entire project.

8 Kent St

As I mentioned recently, our team is growing to six people over the summer, so we need new space. After trials and tribulations reported previously on this blog, we finally have a lease on new office space at 8 Kent St, Newmarket.

This is a pretty cool area. There are lots of great food options in Newmarket. On the very block of the office there's O'Callahan family favourite Crazy Noodle Bar plus two yum cha (dim sum) restaurants (Sunnytown and Sun World) and a Mongolian BBQ place Gengy's. Nearby there's Happy Valley, Hansan, T-Mark, three food courts, a Chinese bakery, and lots of other places I don't know well ... yet. The office is actually above Lone Star, a big American-style place.

Given that, it's fortunate that I'll be able to walk to and from work. It's about 30 minutes each way at a fast pace. For people who live further away, there are great bus and train connections.

I'll be able to go for a walk in the Domain when I need to get away from my computer and actually think.

The Rialto movie theatre is about a block away from the office. Maybe interns will have enough time to use it.

My old high school, Auckland Grammar, is only about a kilometer away. It feels like after 20 years I haven't come all that far :-).

Intranet Explorer

I'm fascinated by the silence surrounding IE8. It suggests two possibilities: they're silent because there's nothing happening at all, or they're silent because they're cooking up something astounding. Both seem improbable; the latter, because Microsoft likes to advertise broadly and early to developers, and the former, because what was the point of waking up to do IE7 and then going back to sleep again?

Either way, they're showing little interest in implementing new Web standards such as ES4 or the WHATWG APIs (nor old ones such as CSS2.1 or DOM Events). Since ES4 is backwards compatible with ES3, the argument that it would break compatibility is bogus, but nevertheless that's their line. We heard the same thing during the IE team's three-year holiday between IE6 and IE7, interestingly enough --- the "compatibility matrix" made it too hard to do anything. Sometimes they seem to argue that they were right the first time, IE7 was a mistake and it actually was too hard.

Attitudes to compatibility are actually very interesting. Microsoft seems to take the position that any change that negatively affects a Web site is bad. Mozilla --- and our friends at Apple, Opera and elsewhere, I think --- insist that when sites rely on a bug that clearly violates a standard, we will fix the bug even if it hurts sites. (In some cases, we might push to change the standard instead, but only if the "bug" is at least tolerably sensible behaviour.) So for every major release we fix a lot of bugs, and we risk breaking sites.

I always expect Web developers to grumble about this, and every time I meet some, I ask them whether our relaxed compatibility causes them problems. The answer is invariably "no"! Or at least, the developers I meet prefer us to fix the bugs because although it may break things here or there, overall our more consistent behaviour makes it a lot easier to develop Web apps for Firefox than for IE. Almost everyone tells me they develop their sites first in Firefox, and when everything's working, they backport it to IE. (For some reason I always feel shy when I hear this.) I guess if you're going to iterate your site design, you want to do that with the browser that's easiest to work with.

Actually I think both attitudes are right, because we're addressing different sets of users. I suspect when Microsoft talks about compatibility they're largely talking about intranet sites inside corporations, which are often maintained poorly or not at all, so anything that's broken by a browser change will remain broken forever. And it's easy to see how the needs of large corporate customers can come to dominate the thinking of a software organization --- they're large accounts with focused contact and are used to getting what they want. (Hey, I worked at IBM!) As another example, we've seen how Microsoft's slow security update cycle trades off the security of home users against the convenience of large customers.

Maybe the time has come for Microsoft to split (at least at the engine level) the "intranet" browser from the "Internet" browser. Otherwise they actually risk painting themselves into a corner, where more and more Internet sites are optimized for Firefox or anything but IE. It sucks to be late to the party and having to be the third or fourth implementor of a bunch of new APIs; you've lost your say in how those APIs are designed and may be compelled to reverse engineer the behaviour of other browsers (although thanks to Ian I hope the latter is less of a problem than it used to be!).

Of course, there's a whole other perspective on this: Silverlight and .NET. "Compatibility constraints" in IE make a handy brake on the evolution of the open Web, very useful when pushing a competitor to the Web*. (Many have pointed out the big joke about Microsoft's ES4 objections, namely that C# has gone through two huge revisions in the last few years.) Shiny new platforms like Silverlight and WPF don't have to worry about compatibility now, but it will be interesting to see how they handle compatibility going forward. We're in a marathon, not a sprint, it will be a few releases before they get traction, and if they have to ship side-by-side Silverlight assemblies, one for each version they've released, it's not going to be a small download or a mobile-friendly footprint.

* It's uncouth to speculate that Microsoft's representatives might act in bad faith. Unfortunately, history shows it's a real possibility. I want to be polite, but not naive.

Finding The Core

A little while ago the New York Times had an interesting article about Christians and politics in the USA. It has its own predictable slant, and quotes broadly and therefore pulls in a lot of loons. It perpetuates confusing use of the noun "conservative" to mean either "theologically conservative" or "politically conservative" when these are very different things --- whose divergence the article is supposed to be analyzing. There are some quotes I really like, though.

But many younger evangelicals — and some old-timers — take a less fatalistic view. For them, the born-again experience of accepting Jesus is just the beginning. What follows is a long-term process of “spiritual formation” that involves applying his teachings in the here and now. They do not see society as a moribund vessel. They talk more about a biblical imperative to fix up the ship by contributing to the betterment of their communities and the world. They support traditional charities but also public policies that address health care, race, poverty and the environment.

Amen --- though there is nothing new or radical about that in the history of the church.

If more Christians worked to alleviate needs in their local communities, he [Rick Warren] suggests in the church’s promotional materials, “the church would become known more for the love it shows than for what it is against” a thinly veiled dig at the conservative Christian “culture war."

...

On the Sunday before the referendum on a state constitutional amendment banning same-sex marriage, Carlson reminded his congregation that homosexuality was hardly the only form of sex the Bible condemned. Any extramarital sex is a sin, he told his congregation, so they should not point fingers.

...

"I think they are going to have a hard time going out into the pews and saying tax policy is what Jesus is about, that he said, ‘Come unto me all you who are overtaxed and I will give you rest.’ ”

The article mentions "the Gospel" many times without actually saying what that is, except that it has political and social dimensions and evangelicals struggle over the emphasis placed on them. That gives the impression that evangelicals are more divided than they really are, because the core of the gospel is more important than anything mentioned there.

That core is, roughly --- acknowledging that each of us is guilty before God; recognizing that God has provided for our forgiveness by having Jesus take punishment that we deserve; and claiming that forgiveness by committing ourselves to Jesus as Lord.

That's really what we're all about. Of course that has huge social, political and other implications. But to me, that article and most others like it feel hollow. They pick at the fringes and try to understand what's going on (cue the "blind men and the elephant" analogy). I wonder whether the author actually know what "the Gospel" means themselves. I wonder who out there does. I didn't myself, for twenty years.

Status

Lately at work I've been focused on driving down the layout blocker-bug list, the bugs that we want fixed in Firefox 3/Gecko 1.9. These bugs are mostly regressions due to work done during the 1.9 cycle. At this point most of the bugs that are "obviously" mine, such as regressions from my text work, have been fixed, or have fixes waiting for review or landing, or depend on other such fixes. Now I'm picking off unowned layout blockers to work on. That unowned bug list is down to 46 bugs and falling quickly, which I think is very good news. The bad news is that some of those unowned bugs have been shunned for a reason...

One reason is that it seems in just the last couple of weeks, the usually-constant flow of obscure crashers and regressions detected by our demonic duo Martijn and Jesse has shrunk to almost nothing. Apparently they're still alive and working, so maybe this means we're over the hump? I hope so!

As regular readers will know, I've also been spending time looking for new office space to accommodate our growing team. This has been frustrating. We've expanded our search to Newmarket and have a couple of promising opportunities there. Hopefully I'll have good news to report soon.

Speaking of the team, here's what the other guys have been doing:

• Karl Tomlinson has accepted the challenge of getting MathML on its feet again for the Firefox 3 release, after a severe lack of maintenance. Good luck Karl!
  
• Chris Double has continued working on video. He has a patch which is almost ready to land (disabled!) on trunk.
  
• New guy Chris Pearce has been working on blocker bugs, mainly text and editor bugs so far.
  
• Even newer guy Matthew Gregan fixed a bad old Linux bug, worked on a crashtest harness, and is now working on layout bugs.
  
• Michael Ventnor is currently still studying (I think) but he's planning to join us in Auckland for a summer internship! He'll probably be working on GTK themes and Firefox front-end issues.
  

And we're still looking for more people!

A word about Chris's video work... The WHATWG video spec changed a lot --- actually, grew considerably --- over the last few months. We don't want to make developers' lives hard by shipping a half-baked implementation of that spec so it will probably be necessary to delay enabling video support until after Firefox 3. We'll see how it goes.

We're in a similar situation with offline apps. There is a WHATWG spec now and it's somewhat different to what we've implemented. We definitely aren't interested in pushing a sole agenda so we're working out what we can ship in Firefox 3 that's aligned with the WHATWG spec.

These are tough calls, but our commitment to Web standards trumps checking boxes in the Firefox 3 feature list.