Can you feel the tension is the air? I sure can. It's the point when Mozilla starts collapsing. There's a growing number of people wanting to support and maintain Seamonkey, instead of Firefox and Thunderbird. After all, if you don't like the way things are going, why not branch off and do things the way you do like? It's the open source way! It also happens to be the best way to kill off a project.

Take a look at the list of Seamonkey supporters. Lots of QA people there. Lots of non-programmers. A small handful of people who would do much of the real development work, all of which already work on Gecko. But no management. Nobody with strong leadership, nobody with the time to coordinate development and testing, nobody with the project management skills needed. Oh, and I'll bet no user interface designers either.

Can you guess who will be expected to fill this void? I'll bet you can! Why, it's the overburdened Mozilla Foundation! Surely, the cost and efforts required to maintain two products that do the same thing would be negligible? After all, they've been doing it for a while, right? Sadly, they have. Of course, there were reasons for this since the brand spanking new Firefox wasn't ready until last November. But now there isn't.

One issue is that Firefox has been marketed as a separate product, "built from the ground up" as they say. Of course, it wasn't really built from the ground up, since much of the code, including the UI code, is actually the same. But it is heavily marketed that way. And guess what? A brand new name, some great logos and a concentrated effort on pushing the strengths of Firefox went a long way. Firefox is a great brand name which may one day become one of the best, like Apple, or Google or the Olsen Twins.

However, the new image has a downside. Firefox still has it's older brother, Seamonkey, still a separate product. So guess what? People still think it's a separate product and that it should still be updated. Well, what did you think would happen when you make two similar products? In this regard, it would have made more sense to change the name from Firefox to Mozilla 1.8 and promote it as the actual upgrade from Mozilla 1.7. Would people upgrade? Sure, it's the next version. Would some people complain about the UI changes? Sure, but they'd upgrade anyway, at least eventually. Why? Because the old version is no longer maintained.

Let's look at Netscape. They've released some browsers over the last ten years too. In the latter half of that time, they've been criticized because they created bizarre colourful UI, added strange bits of UI, stuck in all kinds of links to their web site, put stuff on the toolbars that many don't desire to be there, added millions of preference panels, and popped up all kinds of dialogs and ads. But if there's one thing Netscape has managed to do right, it's getting the name of the browser right. The first version was generally referred to as Netscape 1. Then came Netscape 2, then Netscape 3, Netscape 4, Netscape 6 and then Netscape 7. See a pattern? Apart from the glitch with version 5, things seem quite sensible. Netscape has recently announced a new version of their browser. Can you guess what it's called? Get this: Netscape 8. I'm even going to go out on a limb and predict the future: If Netscape releases another version of their browser, it will be called -- are you ready for it -- Netscape 9.

Easy to tell which version to upgrade to, right? There's only one to choose from. Your only choice is upgrade, or don't. And, guess what? The UI changed significantly between most versions, much more so that the UI changes between Mozilla 1.7 and Firefox. Yet people either upgraded or didn't. No one really expects Netscape or anyone to work on the long lost Netscape 5.

Now, some will be saying they like the integrated products rather than the separate browser and mail, much like how people complained to Netscape they didn't like integrated products. Oh well, you can't please everyone. But wouldn't it be easier to construct a Firefox/Thunderbird suite? I'm no build expert, but I'd imagine that would be easier and cheaper than maintaining two separate products.

What about all those missing features in Firefox that the suite has? Well, I looked, and, ironically, I couldn't find the missing features. People keep saying that Firefox has reduced features, but don't seem to ever mention what they are. OK, let's say there are some. Wouldn't it be easier to port these "missing features" to Firefox and then have a build option to include them?
Mozilla's overlay system is quite powerful. There's no need to require the user to install extensions for these things. Let's make a standard set and include them as part of a Firefox/Thunderbird suite package. This means too that the QA people should stop scaring people away by marking enhancement bugs invalid because they think the feature would be better as an extension. Sure some things might be, but I'll bet there are tons of great ideas out there that just need a better design and a bit of work and they would make great built-in features. After all, imagine what Firefox would be like if it didn't have tabbed browsing. I'd imagine someone would mark a request for it as invalid.

Those other little things you don't like about Firefox? Personal taste mostly. Don't like the Options command being on the Tools menu? Like the traditional location on the Edit menu instead? Yeah, whatever. Maybe we should put preferences in several dialogs on the Options menu for those that started out using Netscape 3. Really no reason to support two products for this kind of thing.

There's also the issues with the Firefox review and management process, which is, I suspect, the main reason the key developers on the Seamonkey supporters list are against Firefox. You see, Firefox has different reivew process than the rest of Mozilla code. Is that a good thing? Could be, but probably not. Considering one of the Firefox developer's thoughts on these kinds of things, that the Firefox module owner doesn't really do any reviews, and that the Firefox poster boy hasn't done much at all recently,
I'd imagine some changes are needed.

For one, I'm quite interested in the XUL toolkit, but it seems to be intertwined with the Firefox toolkit. Would it be wrong to suggest that there be an app toolkit maintained by the application front end developers, and an underlying XUL toolkit maintained by XUL developers? The app toolkit needs good UI designers. But the XUL toolkit needs good API designers. These are different people. Let's get people good at each task onto each piece.

We need to ensure that both front end UI and back end Gecko developers are communicating with each other. Sure, the front end UI is where all the action is. This is where your work gets noticed. You might even be famous for it. But if fame is what you're after, you've come to the wrong place. But if you are a front end UI developer, you've got to let the Gecko folks do their work. Each group has its place. If you do UI, you leave the other stuff alone. There are better experts for that. But if you don't do UI, leave UI work to those who can. And, no matter how much you think you can do good UI, you're almost guaranteed to be wrong.

Firefox is targeted at normal people as opposed to developers. If you know how to create a makefile, you aren't a normal person. But you can use Firefox too. I wonder who the Seamonkey supporters are trying to target? Can't be normal people - it doesn't make sense to create two products that do the same thing for the same set of people. Corporate users? They can upgrade to a Firefox/Thunderbird suite with extras for those mysterious "missing features" all built-in, or they can stick with Mozilla 1.7. Or are they targeting themselves, all programmers and hackers? Surely not. But I bet that's the answer. It's just, well, there just aren't enough of you to really get anywhere. In fact, it's why most free and open software doesn't go anywhere. It's target audience is too small. Unless, of course, you're writing a C compiler. But don't write a C compiler! We have lots already!

One thing is clear though is that the Mozilla Foundation does need to show some leadership in this. Make some decisons, let people know what those decisons are, sit down and figure out what needs to be fixed, and work out how to fix it. Some people will be disappointed. But if people can't accept that they aren't always going to get their way, they won't get very far.

To summarize, resurrecting Seamonkey is absolutely the wrong thing to do. Instead, let's not be a burden on the Mozilla Foundation and let's build on top of one product, a product we can all get behind. I recently upgraded to this, the new version of the browser from Mozilla, and that browser is Firefox.

In case you haven't seen it yet, it's my plan for XUL templates going forward. It should fix a number of issues (such as bugs) and add lots of new functionality. Oh, and I've already implemented much of step one.

OK, I think it's time to finally improve XUL templates. There have been numerous proposals out there about how to to do it, but no one can really agree on what the best approach is. There is generally consensus that there needs to be support for XML data as well as RDF, and/or other data formats. What there isn't consensus on is what the templates will look like and whether to use a different template mechanism for different kinds of data. Unfortunately, like most of Mozilla, no one is in charge of things, so while lots of ideas float around, nothing actually gets done.

There have been a number of suggestions to use XSLT for XML data. Sean McMurray has proposed and implemented a simple scheme for this, that is to transform XML using XSLT for display in a XUL interface. It's so simple in fact, that it could just be used as is, after a bit of work to clean up the design and code. There are some advantages of using XSLT over other proposals, but after much thinking I don't believe it will turn out to be very feasible solution. Despite being a "standard" and having sufficient documentation available, I'd imagine XSLT wouldn't be any easier to understand than the existing XUL template mechanism, apart from learning RDF, which wouldn't apply to a XML data template anyway. Perhaps it's just the namespaces and the XPath that make it look complicated. However, adding a simple and automatic XSLT feature as Sean proposed would be useful to have available in addition to a proper template system.

So what am I planning on doing? Well, first I'm working on Yet Another Template Proposal. Why might this proposal be better than all the others? For one, this one is primarily based on the other proposals, namely those made by the Mozilla template and RDF regulars on the
Mozilla wiki. Also, instead of some grandiose plan to rewrite the templating system to do everything anyone would want, it will instead involve incremental changes to the existing template system. The idea is to change small bits at a time, adding features as necessary. If we find that one idea didn't work out too well we can change it without much fuss.

The eventual goal and syntax I have in mind would have some things in common with the existing syntax -- in fact, for RDF it should be completely backwards compatible. But for other types of data, or indeed even for RDF if desired, the syntax is similar to be easier to understand and allow more shared implementation, yet different enough that, for example, it shouldn't bog down the XML handling with some requirement for the RDF handling. Just as important, it should be relatively simple to implement in the existing template builder code without drastic rearchitecting.

Do I think my new proposal will be perfect? Of course not. But one big advantage is that I plan to actually implement it, as opposed to most of the other proposals which won't be. I'm hoping that by implementing it incremently we can see better templates sooner rather than later. In fact, I've already implemented one new feature for RDF based generation which will appear in the Linspire version of Nvu.

One thing people don't seem to be able to understand is the difference between attributes and properties of a DOM element. An attribute is a value set in the HTML/XML source using the form: width="60". In script, you can retrieve the value of an attribute using the getAttribute function. A property can be retrieved using the dot syntax such as element.style to get the style property of an element.

For various architectural reasons, in IE both attributes and properties are the same thing. There, you can retrieve a attribute using either the getAttribute or dot syntax, as there is no distinction made between them.

In Mozilla, this is (correctly) not the case. An attribute and property are distinct entities and may have different values. Also, an element may have a specific attribute such as 'width', but not have a corresponding 'width' property. However, it is often the case that such a property will exist and will just return the corresponding attribute's value. For instance, the XUL width property just translates to a call to getAttribute("width") to retrieve the width.

When retrieving the value of an attribute, Mozilla just returns the string that is stored on the element. When retrieving the value of a property, its value is usually calculated dynamically. In many cases, properties don't use any memory for the storage of values. For example, since the XUL width property just retrieves the value from the attribute, it doesn't store any value of its own.

Moreover, it is possible for an attribute to have one value, and a property with the same name to have a different value. There are several reasons. First, is that attributes are always strings, as they need to be serialized into source form. Properties may have any type, and frequently do. For instance, if the XUL hidden attribute returned the string "true" the hidden property will return the boolean value true.

In some situations, the values will differ. For instance, given an anchor in an HTML document (an A tag), someanchor.getAttribute("href") might return "nmain.css", whereas someanchor.href would return the absolute path "http://www.xulplanet.com/ndeakin/nmain.css".

But many people seem to assume that both attributes and properties are one and the same. Perhaps they are used to IE. The most common confusion lies in the textbox value (<input value="xyz">). The value attribute only specifies the default value of the textbox. The value property can be used to retrieve the current value in the textbox. Even if the user enters text into the textbox, the value attribute will remain the same as it was before.

If the value attribute needed to be changed every time the user typed something, this would likely cause a performance hit, as the code would have to copy the current value onto the attribute each time. This doesn't necessarily cause a problem for all implementations, but some may have issues with this requirement.

Jan and I just added MySQL support to Mozilla's database component. It isn't part of the default Mozilla build, but you can compile it yourself, or use one of the XPI's, although they haven't been updated yet and seem to be broken links anyway.

I plan on writing some documentation on the component, but basically, it allows you to connect directly to a database. The component also supports a datasource for displaying results in a template or tree. Currently, the sql component supports PostgreSQL, MySQL and SQLite.