Adblock Plus and (a little) more
EU MozCamp, theme development, add-on localization with adofex · 2011-11-13 18:17 by Wladimir Palant
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.
Comment [7]
Commenting is closed for this article.
Dao · 2011-11-13 21:04 · #
Applying add-on themes on top of the default theme has at least one significant downside: It makes major customizations of the UI a PITA as you need to override three differently behaving default themes. Just look at how the tab and toolbar button styling is implemented on Windows vs. OS X.
Neil Rashbrook · 2011-11-14 12:39 · #
Modern certainly wouldn’t want to apply on top of any default theme. Perhaps the easiest way to go is to have chrome://package/skin/file.css automatically redirect to (say) chrome://package/content/skin/file.css (which would be the default theme) if the skin version doesn’t exist. This way when a new file is added, you get to fall back to the default theme, and you can then decide whether you want to override it, and if so whether to import the default anyway.
Reply from Wladimir Palant:
The case where styles for a new UI element were added to an existing file would still be problematic then. But when we discussed the skin:// protocol we talked about a keyword added to the theme file to make it completely replace the original file. I don’t remember however whether we actually implemented it.
Dave Townsend · 2011-11-16 04:08 · #
Might be worth skimming over some of the comments of the bug already filed to do something very similar to this: https://bugzilla.mozilla.org/show_bug.cgi?id=305746
There are no new ideas these days I guess ;)
Reply from Wladimir Palant:
Yes, that’s the bug I meant, thank you. The comments don’t really explain why this work was abandoned though, they mostly stress the need to allow file-based overrides (something that Neil already mentioned above).
Pardal Freudenthal · 2011-11-20 15:37 · #
Having all the default styles “built-in” (moving them to the content provider or whatever) would make implementation of more complex themes practically impossible.
Notice that we already have the possibility to make a theme that “overrides” just desired rules. I’ve described this approach in this article: http://www.tudobom.de/articles/yatt/#light_weight
This approach were discussed at MozillaZine here: http://forums.mozillazine.org/viewtopic.php?f=18&t=1472225
Of course this approach could be improved on the Mozilla side, removing, e.g., the necessity of the hackish registration of a “nonexistent” provider.
So, in fact, we already have the choice to make simple themes with the override approach and more complex themes using the substitution approach.
patrickjdempsey · 2011-11-30 08:18 · #
I do have an alternative idea that would allow current themes to continue to function, make building new basic themes easy as pie, keep un-updated themes from breaking new features, keep themes from breaking “security” features, allow for a basic automated compatibility test, and generally make almost everyone happy. It’s actually pretty simple and I don’t think it would even be that difficult to implement.
All Mozilla needs to do is to create another skin specifically for basic themes. All that it would contain are the support files for the basic main window elements: main toolbars, main toolbarbuttons, urlbar, searchbar, tabs, main menu (top level), and bookmarks toolbar. Everything else would stay in /browser/ and /global/ like they are now. The main stylesheet in the new skin (let’s call it /theme/) could be @imported from /browser/browser.css so that old themes that don’t include that line wouldn’t load those files. To be even more user-friendly the /theme/ skin could split up parts of browser.css into their components: searchbar.css, tabbrowser.css, toolbar.css, toolbarbutton.css, and urlbar.css. If security-related parts of the urlbar are left in /browser/ then these themes would be less likely to break Firefox’s security “standards”.
Under that scheme it would be pretty easy to monitor these handful of files in bugzilla to create a compatibility flag for these kinds of themes, so that it may actually be possible to create a basic automated compatibility test on AMO. If there are no new elements added to the parts of the UI styled by these few files then these themes would be automatically compatible.
patrickjdempsey · 2011-11-30 08:26 · #
Oh, and by theming only the /theme/ skin it would basically completely eliminate the problem of cross-platform-compatible themes. Currently most of the problems with cross-platform compatibility happen in places like wizards.css, scrollbars.css, the arrowpanel popup stuff, the themed titlebar etc. By not including those elements in the skin, there’s little chance of a novice themer borking them.
Magento Designer · 2011-12-02 07:50 · #
Thanks for taking the time to discuss about this, I feel strongly about it and love learning more on this topic. If possible, would you mind updating your blog with more information? It is extremely helpful for me.