The roads I take...

I've just watched Alex Faaborg's video about Tabs On Top for Firefox 4, and as I have been thinking about that topic for years now, I think it's time I put down my thoughts as a "SeaMonkey guy".

Now, some people would assume, that being a "SeaMonkey guy" must mean I'm totally opposed to this as we're widely considered to be the completely conservative kind of folks.

But then, my thoughts base on the fact that we've been talking about running browser, mail, HTML editor, chat, preferences, and whatever else all as tabs that can live in a single window (see our long-term vision) - and I actually can't imagine getting that right without placing tabs on top ultimately (think of toolbars needing to change between different kinds of tabs, for example).

So, I think that for an application suite that allows mixing tabs, it's ultimately a must to do that, and that makes me think in favor of this idea in general. Even now, having SeaMonkey's Site Navigation bar to be only displayed when needed makes my tabs bar jump around, which is nasty. Also, adding find bar on top of the web content should still place it under the tab bar and not make it jump, as it will do in our first implementation.

What I'm still unsure about, though, is how to deal with things like the bookmarks bar or the menu bar, if one has shown them, and unfortunately, Alex also left those out. Also, things like additional app toolbars added by add-ons are something we still need to figure out completely.

I know some users will be upset, and it must be a preference in the beginning, but for SeaMonkey purposes, I don't see how we should ever get mail tabs and browser tabs into a single window if we don't move tabs to the top.

Still, I'd love some ideas about the problems I pointed to. Any thoughts?

(Oh, and, of course, we still need someone to implement/port the actual code to even enable this in SeaMonkey - help would be appreciated!)

I just read this blog post on extensibility of Safari, Chrome, and Firefox - and it hits a very important point.

Chrome is winning an interesting share of users, Safari wants to do the same, Firefox recently goes out of its way for improvements that make it more alike to the "cool child in the block" that Chrome currently represents. Now, many of the improvements the teams are making are worth to be made by themselves, with our without having competition in that field - I'm not sure all of them are, but that's a topic for other discussions.

What's important is that we look into what makes a difference between Chrome, Safari and Firefox. Now, as I recently posted, the mission is the main philosophical difference. On the side of the product, there is a real difference as well though - even if we'd match Firefox to look, feel and function almost or completely like Chrome (which I'm sure the team are not really targetting, even if they're going a lot of the way in that direction), that would persist - and if it wouldn't, I'd not feel like it would still be right to be called a Mozilla product.

And that difference, the one thing that sets our technology apart from any competition, is the Mozilla platform.

The core of that platform goes back to a decision of a few probably visionary Netscape engineers back in 1998 who found out that the new web renderer they designed for "Netscape 5" in the newly founded Mozilla project was so fast in rendering basic web pages and even form elements that they decided it would make sense to use it even for rendering the browser UI with that renderer - using the same code and definitions on all supported platforms. As HTML didn't have support for all a UI needs and the HTML box model was made for scientific documents and not on-screen design, they created XUL as the markup language the web renderer (Gecko) would use for that UI - but the key was that it was extensible in many ways with very web-like technologies that were - and are - quite easy to learn and use (and IMHO, much of it is even easier than HTML itself, as e.g. <input> has strange syntax there).

The extensibility of that platform and making UI work with web-like technologies made it a no-brainer to support additional modules that could be installed, later called "extensions", nowdays a part of the refined "add-ons" system. As the UI itself is built with the same technologies, that also means those extensions or add-ons can do anything the UI can do or that the application can do - I just recently converted what I previously ran as a full-blown application into a Firefox (and SeaMonkey) add-on (KaiRo.at Mandelbrot), for example.

With the tremendous success of Firefox over the last years, a rather large add-ons ecosystem has formed around exactly that platform that allows any extension the same flexibility as the application itself - and even though generic packaging and installing isn't very well-supported, whole applications are powered by the Mozilla platform or based on Mozilla technologies.

And that is the real strength of Mozilla technology-wise. We have a very powerful platform that allows building extensions to our applications or whole products by themselves (using XULRunner), and all those use "web" or very "web-like" (but IMHO to some part even cleaner) technologies and work on all platform that platform can be compiled on, recently that even can include mobile devices.

The real technology difference of Firefox, Thunderbird, and SeaMonkey to any competition is that extensible and powerful platform. If we want to "win" over any competitor, this is one thing we really need to focus on, this is the ace we need to play. Other might try to match us there, but we have put 10 years of the work of great minds into developing that strength, others won't match that easily.

So, let's put this difference to work. Our mission for a better and open Internet and this great platform technology ought to be a game-changer. We need to build on those to succeed. But we can do it. So let's get to work, and let's tell people about it.