why update add-ons now?

With Firefox 3 still a couple of months away, it would seem reasonable to wonder why we’re encouraging add-on developers to get their add-ons updated for Firefox 3 already. For most add-on developers, it will indeed be a pretty quick process to update to the new chrome layout, a new API or two, and test it out, but we want people to start on that process now nonetheless. There are two reasons for this, in my mind:

  • The kinds of people who test our betas and give us great feedback are the kinds of people who have a bunch of extensions installed, and not having their favourite extensions work makes it much less pleasant for them to do in-depth testing.
  • If there is a hard problem found when updating an add-on, we want to know about things we can do on the Firefox side to make it easier, in time for those changes to safely get into the release stream. Waiting until the Firefox RCs are out would mean that we have a lot, lot less room to maneuver when it comes to resolving any problems found.

So please, take a moment to start updating your add-on this weekend, and let us know if you need help. Operators, in the Special Forces sense, are standing by.

X-IE-Version-Freeze

There are a lot of good posts describing problems with IE8′s version selector feature, so I’ll just leave you to read those for some insight into problems that it creates (and how it pushes the IE-compatibility burden off Microsoft and onto other competing browsers in a very impressive way).

They’ve announced what they’re doing in IE8, and as we know from previous conversations with Chris Wilson, they don’t announce until they’re sure:

[W]e have to be very, very careful to be 100% confident when we announce things like “that’s exactly what we’re doing,” or “that’s the date that we are aiming for.” When we don’t, we tend to get a lot of people upset with us, of course, but it’s not just them being upset with us; it’s actually, it can be damaging their business model if they bet on us releasing something in a given timeframe, or bet on us releasing a given feature, and we don’t ship it

So we’re going to see X-UA-Compatible in IE8, with very high likelihood. It’s positioned as something that other browsers could use — if they wanted to ship multiple rendering engines to make download size a further impediment to competing with Microsoft, say, or totally lock themselves out of the mobile market — and the introductory document has examples like “FF=3″ in it.

And we know from the ES4 discussions that Chris believes in different groups working out proposals together, which is why they didn’t make a specific counter-proposal to the one put forward by TG1, after all:

It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together. “Open to input” should be the way of the web, should it not?

So that makes me wonder: why were no other browser developers involved in this discussion? I guess that would ruin the protective cloak of secrecy, though I don’t know how else people would work things out together. (If Microsoft knows, they’re not telling, but I guess that shouldn’t be surprising?)

The naming of the header is sort of generic, but unless the next big announcement on the IEBlog is the release of IE8′s source code, “render this like IE8 would” really only helps Microsoft, and I think it works against the promising trend of convergence on open standards.