We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

Extension etiquette


I would argue this point, Firefox's motif is "Keep it simple stupid" (KISS); And as such, extensions, unless specifically targetted for more advanced users, should try and keep their range of choices "simpler". Or at least obfuscate them to about:config only, rather than offer preference panes. My grandmother may like an extension which allows her a quick and easy way to not only save a picture she see's online, but also set it as her desktop. But she wouldnt necessarily want (or even like an extension which offers her) too many choices. While the extensions web-page may easily allow and accomodate for an explanation on these prefs --Callek 00:46, 9 October 2005 (PDT)

I'm with Callek on this one. I'm not sure if this kind of documents (something that describes personal preferences of its author(s)) is suitable for devmo. --Nickolay 14:09, 9 October 2005 (PDT)
While you could call this an opinion piece, I would argue that extensions do need more consistency, and many of the points I make are universal and do represent good practices. I will admit that the Options section is arguable, but points like "document your extension well" are (or at least should be) common sense. Why shouldn't this be on Devmo? --MarbleheadMan 17:58, 9 October 2005 (PDT)
Okay, I removed it for now. Should this point be left open, or are there guidelines that everyone should agree on? --MarbleheadMan 06:27, 10 October 2005 (PDT)


I would also add a section regarding "Where to place/how to name" extension prefs, such as for example Chatzilla's "extensions.irc.*" --Callek 00:46, 9 October 2005 (PDT)

Done. --MarbleheadMan 06:10, 10 October 2005 (PDT)


I could see an "Extensions: Best Practices" article for Devmo, but only if those practices are widely agreed upon by a relatively large core group of veteran extension developers. "Etiquette" isn't really a great name for this sort of article. I'm going to delink this from the primary Extensions page for now, and would like to see more discussion happen about the contents of this article. Please feel free to discuss this article further here or on the devmo-general@ mailing list. I do think it's a valuable idea for an article, I just want to make sure that the content is actually more than the opinion of a single developer. Thanks :) -- dria 21:31, 9 October 2005 (PDT)

There's a similar 'document' on kb.mozillazine.org: http://kb.mozillazine.org/Extension_guidelines --Nickolay 05:13, 10 October 2005 (PDT)
Agreed. In many cases, I tried to think of "what's best for Firefox" as opposed to "what I think developers should do," but I realize that there would be discussion on some points. I do welcome all feedback :) --MarbleheadMan 06:14, 10 October 2005 (PDT)


Entity names should include the extension name.

Why? The entities (unlike JavaScript identifiers in an overlay script) are processed before the overlay is merged into the base file, aren't they? --Nickolay 05:13, 10 October 2005 (PDT)

Well, internal preferences don't technically need to be named extensions.extensionname.prefname either to work properly. This is just a way to keep things organized behind the scenes -- a "best practice." --MarbleheadMan 06:12, 10 October 2005 (PDT)
There is reasoning behind naming prefs 'extensions.name.pref'. First, it's visible to user. Second, if two extensions used the same pref, they would not work correctly.
On the other hand, there's no (obvious to me) reason to include extension's name in DTD entities. It looks to me that it's just redundant. --Nickolay 07:45, 10 October 2005 (PDT)
You have a point...At least we can agree that extensions should use entities and locales, yes? --MarbleheadMan 08:18, 10 October 2005 (PDT)
Sure :) --Nickolay 08:25, 10 October 2005 (PDT)
What about entities loaded into overlays? Can't they conflict with existing entity names?--Np 12:58, 23 May 2007 (PDT)
Define "loaded into overlays"? --Nickolay 21:22, 23 May 2007 (PDT)
An entity in a DTD that an overlay references.--Np 07:31, 24 May 2007 (PDT)
Those are resolved at the overlay parse time, so they shouldn't affect the master document, nor conflict with any other entities. --Nickolay 09:34, 24 May 2007 (PDT)

Document Tags and Contributors

Contributors to this page: Nickolay, Np, MarbleheadMan, Dria, Callek
Last updated by: Nickolay,