Feb 192009

As I look over my to-do lists for Firefox 3.1 documentation, I see no action items remaining.  That means we’ve reached that point I like to call “essentially complete.”

What that means, to me, is that as far as I can tell, we now have documentation for all of the new developer-facing topics in Firefox 3.1.

Now it’s up to you, my intrepid friends in Mozilladom, to tell me where our documentation has holes.  Please go through the content linked from the Firefox 3.1 for developers page and tell me where we have gaps, or if you find articles that seem particularly “stubby” to you.

There’s almost certainly still work to be done.  Just because everything is covered, doesn’t necessarily mean it’s covered as well as it needs to be.  But I’m awfully close to most of this material now, so I may or may not be able to see the flaws.  That’s where you come in.

Despite knowing that there’s almost certainly more to be done, this is always an exciting moment in the documentation work for any project.  Knowing that everything is covered — at least to some extent — is always a thrill.

 Posted by at 11:22 AM

  12 Responses to “Mission accomplished?”

  1. I can’t see anything on support for external references (https://bugzilla.mozilla.org/show_bug.cgi?id=433616) See also http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-struct-use-05-b.html

    The practical effect is that you don’t have to stick all your SVG in a single file. You can create libraries of things like patterns, gradients, filters etc and use them by reference.

  2. There’s also https://developer.mozilla.org/web-tech/2008/10/10/svg-external-document-references/ and a reference in roc’s blog post today.

  3. Oops, turns out the section I have on using external references was sitting in a text file on my desktop for some reason, instead of in the wiki. It’s in position now, thanks!

  4. When I worked on a new tree-based download manager UI for SeaMonkey based on the Firefox 3.1 backend, I realized we are missing a number of core XUL articles on MDC that are only available in sometimes somewhat outdated version on xulplanet, like e.g. nsITreeBoxObject as well as a number of other nsITree* ones. Closing gaps like that would be quite helpful, esp. as things like trees aren’t exactly easy to deal with in the first place.

  5. Robert — I agree entirely, we have a lot of XUL and XPCOM reference material that’s missing. Progress on that tends to be slow while I’m dealing with stuff specific to impending releases. I keep trying to encourage volunteers to work on articles like those. It’s slow going, not a lot of people like to volunteer to work on reference stuff like that. :)

  6. By the way, I propose that if there are specific interfaces or sets of interfaces that most urgently need to be documented, file a bug in the Mozilla Developer Center product against Documentation Requests and they’ll get prioritized.

  7. It would be great if you could also document the API added in bug 468877 as well. This is the API which allows plugin developers to make their plugin aware of the private browsing mode. Thanks!

  8. I have been wondering why Workers are called ‘DOM Workers’. The DOM is precisely what these workers can not touch. They can not even create elements or use DOMParser, XMLSerializer, XSLTProcessor etc. You can not even create a document fragment in a worker, as far as I know.

    I would think that ‘JavaScript Workers’ would be more precise, since that is what is available: Pure JavaScript.

    Just my 0.02€.

  9. I think the name is actually Web Workers now. I need to revise the docs based on that.

  10. I notice on the documentation page for appendChild the following addition:

    Note: Starting in Firefox 3.1, you can no longer use this method to append script elements that retrieve their code from anything other than chrome: URLs.

    It is a bit confusing to me. I started a couple threads in some forums to drum up discussion on the appendChild changes by Firefox, but to no avail.

    Why restrict the ability to appendChild elements? It seems odd that we can still use other methods such as insert or replace without this limitation.

    Sheppy, can you share a resource/link as to why the documentation is reflecting this change?

  11. It’s a fix for bug 425153, “It’s unsafe to use non-chrome scripts, overlays, and bindings”.