What’s Missing in Deer Park

The Mozilla Foundatio…er…Corporation has released Alpha 2 of the next release of Firefox, and there’s a lot of good stuff in it. On the whole, it feels faster, and tons of exciting stuff has already landed in this release.

Aside from E4X, it’s hard to see how Deer Park is going to make my life much better as a DHTML developer, though. The story on rich-text editing is still grim. <canvas> is a disaster whose impact is only lessened by the inclusion of a minimal SVG subset. The platform is overall improving, but XUL apps still require enduring an RDF mind-fuck in order to get off the ground. Overall, you get the feeling that Deer Park is 2 steps sideways, one step forward.

But it wouldn’t take much to change that from the perspective of the DHTML, nee, “Ajax” developer. Here are a couple of simple-ish things that would make our lives immeasurably better:

  1. Local string caching from script

    This is a strange name for a very very powerful capability: caching. Webdevs today need a coherent, simple, and workable local cache which can be accessed form script like any other object/hash and which stores only strings. Such a cache needs only a couple of properties to be wildly successful. Firstly, use the exact same-domain policy as cookies currently are subject to. Secondly, tell me (from script) how big the cache is and how much space is still free. Thirdly, let us specify expiry and flushing policies for it from script (not via HTTP headers). But please, whatever you do, do NOT over-think this problem.

  2. Event-transparency in the z-order and positioned event generation

    Allow developers to specify that a particular DOM node is “transparent” to DOM events. Which is to say, it passes them “down” the z-index stack without triggering a dispatch or bubble sequence in any way. This should probably be handled by a “-moz-” prefixed CSS attribute. Related to this, let us generate DOM events at a set of coordinates without knowing ahead of time what the node we want to route the event to happens to be. Both of these capabilities are amazingly important for a whole set of graphical apps that Deer Park is about to make available.

  3. Improve Venkman’s profiling output

    Venkman is the most powerful tool in the professional DHTML developer’s toolkit today, but it’s crippled when it comes to outputting useful data from it’s profiling tool. Either try harder to assign names to anonymous functions or at least make the output something that can be loaded by gprof. The current situation is amazingly painful, but since it’s the only game in town, we live with it.

I know they don’t sound like big features, but they’re tremendously important to the kinds of rich applications that Deer Park is supposed to be enabling. The big push now is to keep Microsoft from breaking the web with XAML, and I think we all know it. Small, obviously beneficial changes like these go a long way toward maintaining and improving the viability of the open web as a platform.


  1. Posted August 16, 2005 at 2:24 pm | Permalink

    I’m not sure what #2’s “transparency” argument makes. It’s totally anti-the DOM eventing model in that you’re asking to bypass the routing model. Do you have a scenario that could help justify it?

    FWIW, Avalon’s routed events API follows the exact same model.

  2. Posted August 16, 2005 at 10:52 pm | Permalink

    So say you click on a transparent div… as things are today, the event would bubble up to its parent, not to the thing below it in z-index, which to me isn’t very useful in a language like svg which relies mostly on a positioning layout mechanism.

  3. Posted August 17, 2005 at 2:08 pm | Permalink

    We discussed the #1 (Local string caching from script) on the Greasemonkey mailinglist a couple of times.
    Greasemonkey now supports script-specific data stores, but this feature would totally be useful more generally.
    Why not just use the same store as cookies, but mark these cookies as “do not send over the wire”?


  4. Posted August 20, 2005 at 7:34 am | Permalink

    A good example where event-transparency is needed is for tool tips. In native Win32 apps tool tips are transparant to mouse events. Not so in XUL.