What does GNOME really need in terms of an HTML component? My first question for that would be to ask what one means by HTML component. Does that mean strictly displaying HTML? Does that include CSS? Javascript? Flash? Support for other scripting languages? Does it also need to handle XML/XSLT natively? What about networking? Do we leave that up to the application, or do we build in all the URI handling, and support for different transports, such as HTTP, FTP, SMB, SSH, and others? Some things to note about existing APIS are:

• GtkHTML (3.x): Supports HTML fairly well, but doesn't handle CSS, JS, or networking. Does provide editing.
• GtkHTML2: Supports HTML and CSS ok. Has the ability to support JS and other things fairly easily. It's been (very) slowly getting better. The API is a horrible mess of spaghetti though. Large API/ABI breakage is needed to take this project to any real heights.
• GtkMozEmbed/xulrunner: Easy to embed any mozilla/xul app within your app. Hard to maintain compatibility between releases. Provides networking and a lot of things. Written in C++ so not ideal for the platform.
• GtkWebCore: Very unstable. Nokia seems to have dropped the ball on this. Also written in C++, so not ideal for the platform.
• KHTML: C++ and KDE. Definitely not an ideal dependency for the platform, as it would require pulling in much of the KDE libraries.

So, where does that leave us? Evolution uses GtkHTML 3.x, so moving it to a different widget/framework is likely to only add overhead, given the current state of things. Liferea, Web (Chris Lord's little embedded web browser), and Sylpheed-claws all use GtkHTML2. Epiphany, Yelp, Democracy, Galeon, and others use GtkMozEmbed/xulrunner. I don't think any apps use GtkWebCore, and KHTML is of course used by a bunch of KDE apps. GtkHTML2 could definitely satisfy our needs here, but it needs a lot of love. Some things it definitely needs are:

• Re-architecting to not expose every piece of API it has, publically.
• Printing support, which should be more feasible now with GTK+ 2.10.
• Stable, documented API and ABI. This goes along with the first point above. We need to do a lot of API/ABI breakage to clean things up unfortunately.
• Better integration by re-using other libraries, such as libcroco.
• Internal handling of all the network stuff, so we can have a WebKit.

These are just a few things I thought of off the top of my head. There are plenty more I'm sure. But, with the right people helping out, we could easily turn it into a native GTK+ web framework.

If you're interested in making this happen, please feel free to send me a mail, or ping me on IRC or IM.