One of the major advantages of firefox are all the extensions that gecko makes possible, you would need to retrofit the other engines to make something similar possible, but all existing extensions would have to be dumped and restarted (unless work was done to support the apis).

Basically gecko probably was at a decentish state at about the time firefox arrived on the scene from the mozilla project.

It would probably take about the same amount of time to get a new firefox to the state the existing one is at.

As for problems like speed of rendering, resource usage etc… these are getting looked at but it seems like some things in open source take a long time.

FF has the potential to go fast with the Cairo rendering engine their using in FF3 as it can use OpenGL to accelerate the drawing. However I think it’ll take more time for optimizations to go into Cairo and for FF to take advantage of that.

One good thing in FF3 is it should finally have the new rendering engine, which parses the document structure less + allows cool things like using svg effects on html.

All good things come, but it takes a while.

Other good things coming which have taken ages and may happen in the next year or two.
The Gimp moving to GEGL (was supposed to be around the year 2000)
Wine reaching 1.0 (it’s been going 15 years at least!)

You misunderstand what Dave is saying. First of all, most critical compatibility issues tend to be with scripting APIs, not markup, so XHTML/XForms vs. HTML would make absolutely no difference. The problem is that many critical APIs (like editing) are not in any formal spec and not very interoperable. This is something that HTML5 is fixing, so that browsers can converge on common behavior. Working on XForms or XHTML instead will do nothing to fix current pages.

Second, Dave isn’t talking about sites that happen to work in Gecko because it has a “more advanced quirks mode”. He’s talking about sites that are only tested in IE and Firefox, and use dual code paths, so they end up depending on bugs and quirks of both IE and Firefox. We often get bug reports even about strict mode sites where we match the standard better than Firefox but the site depends on Firefox bugs. That’s not to say we are necessarily better across the board.

The conclusion here is that the best way for WebKit to improve compatibility is to promote pragmatic standards like HTML5 and to grow the market share of WebKit-based browsers.

that is what i call compatibility, there always will be bad code on the web, and in my personal opinion, browser vendors pushing more HTML5 instead of XHTML, XForms, etc… will not help to reduce bad code from the net, so I think for much you want people to fix their sites to work with WebKit, it will never happen until you reach a critical mass of users, much the same thing that has happened with Gecko. but how Gecko has reached it? partly because it has a more advanced quirks mode

This is a bit off topic but I just love it how crApple rapes the earth for oil, turns it into the landfill tomorrow’s landfill, retrofits it with fake chrome and you all think it’s ok to be a monopoly. If Microsoft did a similar deal, locking the unit to one provider, they would never hear the end of it.

Schrep briefly mentioned this in your last blog post, but I’ll repeat it again because it seems you missed it.

You can already have a rather nice Gecko-rendered web-in-your-pocket with the Nokia N800 (not to mention other mobile devices that can run Minimo). Both platforms have 128MB of memory, both use ARM CPUs (although the iPhone is 620Mhz, and the N800 is 330Mhz).

From what I’ve seen from using both devices, both engines are in the same ballpark. I didn’t notice a significant subjective difference between Opera and MicroB (Gecko) on the N800. Of course, the iPhone’s UI is far better than the N800, but I don’t think the choice of rendering engine has much to do with that.

There’s a webkit port for the N800 now, and I’ve been meaning to try it out.

It really doesn’t. More errors at this point (in Safari 3 at least) are caused by Web site bugs from not paying attention to WebKit than by actual bugs in the engine itself.