I’m still at the EU MozCamp 2011 but Mitchell Baker already gave her closing speech and things are wrapping up. It has been an interesting weekend, a bunch of add-on related sessions among other things. One interesting conclusion that I made from the discussion: the rapid releases aren’t a real issue for extension developers and don’t create more work. Ok, I’ve suspected that much already but it was nice to have other add-on authors confirm this. In the discussion session with extension developers this topic didn’t even come up, as opposed to localization for example which is a significant pain point. AMO’s automated compatibility checks for extensions are working nicely and mark most add-ons as compatible already during the Aurora phase. There are plans that go beyond that as well and it sounds like extension compatibility will mostly become a non-issue for end users in a few Firefox releases (at least as long as binary XPCOM components aren’t used).
But the rapid releases are a huge problem for theme developers and there is no good solution. Theme developers have to track all user interface changes and add corresponding changes to their themes — every 6 weeks, no way around it. So I was wondering what happened to a proposal that was discussed a few years ago: have all the default styles “built-in”, the default theme would simply be empty. Other themes wouldn’t have to duplicate all the rules of the default theme, they would merely override the rules that they want to change. And changes to the user interface wouldn’t cause catastrophic failure: even if the theme fails to adapt, the default rules would still be there. In the best case scenario there wouldn’t be any issue at all, in the worst case the new user interface element would look somewhat out of place.
This is something that we implemented in TomTom HOME 2.7 several years ago and it worked really well. Our implementation was slightly hackish because we didn’t like having two CSS includes everywhere:
<?xml-stylesheet href="chrome://browser/content/default-skin/foo.css" type="text/css"?> <?xml-stylesheet href="chrome://browser/skin/foo.css" type="text/css"?>
Instead we implemented our own protocol that would automatically combine the two files so that the following line would be equivalent to the two lines above:
<?xml-stylesheet href="skin://browser/foo.css" type="text/css"?>
We had to hack XULRunner a little because in some places the
chrome:// protocol is hardcoded but other than that it worked fine. But whether one goes with that solution or takes the verbose one — it makes life much easier for theme developers. Anybody know why Mozilla never got around to implement this?
And since I mentioned add-on localization already: Tim Babych from Mozilla.UA did a presentation on his add-on translation system called adofex (an extended version of Transifex). Babelzilla is planning to move to this system really soon and I think that this is great — while I love Babelzilla and it saves me lots of time, the constant technical issues are no fun and the usability of their system is below average. So it would be great if add-ons developers and localizers would take a look at the adofex test installation and leave their feedback. The source code of adofex is available on github and if you know Python — Tim could use some help improving it.