Re: gtkhtml2 vs. gtkhtml1

[Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>]

> Jeffrey Stedfast <fejj ximian com> writes:
> > Why do that when GtkHTML2 is already superior to KHTML? It is isn't
> > it?
> 
> No, I don't think it is.
> 
> But I'd guess neither one is really competitive with gecko... I think
> there's a big difference between handling 95% of pages and handling
> 99% of pages, and being prepared to handle upcoming standards...
> 
I agree that 99% is better than 95%, since it is the last 5% which is
always the most difficult. Using Gecko is perfectly acceptable if you're
writing a browser or any tool which is expected to browse the net.
However, we are not talking about that here - IMO we need a
*light-weight* and *fast* component with tolerable rendering for things
like help browsers, presentation software and many other tools which
need to render simple HTML and maybe CSS. And about Gecko:

1) Whatever Havoc says, 13 MB to display about:blank is still way too
much. Think about Yelp, Evolution (which is bloated enough as it is),
MrProject, Bluefish, all using this - the numbers add up quickly.
Startup time, too, is pretty bad.
2) To render help pages and show HTML mail, we do not need:
	a) Full HTML 4.0.1
	b) Full CSS1/2 support
	c) Full DOM1/2 support
	d) Full JS1.5 support
	e) CSS-themable form widgets (which IMO is *the* major source of bloat
and make the UI look inconsistent)
	f) Lots of hacks to support every broken web page on earth in quirks
mode
	g) Marquee tag
	h) Continued bloat as more and more features are added to the engine
(MathML/SVG, etc)
	i) A widget which prevents you from even using the native scrollbars.
(However, for some strange reason, the form dropdown list, etc. use
native scrollbars. For a UI nightmare, use the Crux theme and open the
bugzilla page in Mozilla - you'll see what I mean.)
3) Embedding API is very fluid for non-display - so using Gecko for
editing is out in the near future (I don't know the progress here - my
info might be a bit outdated - maybe some Mozilla guy can correct me).
4) Yes, there is MRE (or GRE or whatever they decide to call it
ultimately) - but that is still a whooping 2MB bzipped tarball the last
time I checked).
5) Porting effort for KHTML might be less than the waiting effort for
Mozilla API to stabilize and be ported to GTK2 (as the default widget
set). As I understand it, there is not much chance of that happening
before GTK2.2 at least.
6) KHTML is actually pretty good - it's clean (and has a relatively
small codebase) and the rendering is good enough - at least much better
than GTKHTML 1 or 2. It has decent CSS and JS support and it uses native
widgets - what more do you need for
Evolution/Yelp/MrProject/Bluefish/Nautilus HTML view ?

Don't get me wrong - Gecko is all well and fine, but IMHO it is not
suitable for the kind of stuff we have been using GTKHTML for.

Rgds,
Biswa.