I love KHTML
Diego is wrong. KHTML is actively maintained and I want to stress that there are no plans to replace it with WebKit and I want to ask to stop spreading these kind of rumors. I love KHTML.
- Toma's blog - My Blogs.
My microblogs
- tomalbers: @aseigo Yep.In any case failure to communicate, wether on our side or theirs.Past=past.I gave them my akonadi business card & i'll mail him. July 28, 2010
- tomalbers: @gstarwind Defenitely. And we made a bit of a fuss about it, so they could not have missed it easily. July 28, 2010
- tomalbers: @aseigo I know we have been in contact with them, but he claimed he talked to everyone and noone was contacted and called it a myth. July 28, 2010
- tomalbers: Jake Edge from lwn, talks about promoting os projects... July 28, 2010
- tomalbers: Presentation about some software which makes bugzillas ui a bit better. Interesting... July 28, 2010
- tomalbers: Gnome state of the union starts anytime now.... July 28, 2010
- tomalbers: But it misses some finish and consistency according to a co-worker. July 28, 2010
- tomalbers: Gnome 3 shell looks nice and elegant... July 28, 2010
- tomalbers: Evolution: talked to them privately. They are interested in akonadi, but claim never to have been contacted. Fail. July 28, 2010
- tomalbers: Evolution: no sign of akonadi... You know, collaraboration would go a long way here... July 28, 2010
Go KHTML, GO!
I would love to use _every_ advanced WWW page without problems in KDE-based browser. And this is the reason why I will chose Momesana Browser, which is using WebKit, when it arrives
Screenshot of M borser:
http://liquidat.files.wordpress.com/2007/10/momesana-google.png
http://liquidat.files.wordpress.com/2007/10/momesana-overview.png
khtml is a good html rendering system, as webkit is also a good one.
and since OSS is about choices, the best one is to let the users decide what’s the best for them,
currently khtlm is broken (i try to use khtml in the form of konqueror, in 3.5.8 and in 4.0 svn, and i’m lucky if a page is rendered right. (things like Gmail, Meebo and Orkut are mostly, bot not quite, completely wrong. )
but, on WebKit, i also have those problems, (well, not on gmail, but Hotmail and Orkut are completely broken on WebKit) (tested on Safari).
the best thing shuld be the 2 teams co-operate and colaborate a little bit more. Webkit is a son of KHtml, we dont need another holy war. the gnome vs kde is enought.
I nearly exclusively use Konqeror – Firefox only for some special purposes.
If a site doesn’t work with “my” Konqui, I just don’t use it (and of course tell my frends to don’t use it either)
So, Go KHTML :-)
Almost no-one tests KHTML compatability. Almost everyone tests WebKit compatability. I don’t understand how you can prefer KHTML over WebKit when WebKit 99.99% of the time will render the page as the author intended but KHTML won’t.
You need to accept that not everyone is going to use CSS and (X)HTML standards, they are just going to test in the main rendering engines and if it works then ship it. Most of Google’s AJAX stuff requires a forced UA-string change and even then is more buggy than on Firefox or Safari.
I love Konqueror. I do not love KHTML. Technically there is nothing wrong with it but it simply doesn’t have the support WebKit does.
if fewer pages would complain that I’m using a non-supported browser and/or rendering engine. Yes, I know that this is technically speaking not KHTML’s fault but the fault of lazy/stupid/ignorant website designers. Google, are you listening?
Now, most sites work as intended in KHTML in my experience. For me, the main culprits are gmail (not a big problem since I access my mail through pop anyway) and my Internet bank. The latter’s login page look really odd but works and looks fine once I’m logged in. I really have no idea if it would work better with webkit but I would hazard a guess that it’s more likely the flawed sites will be fixed to work with webkit than fixed for KHTML.
Hi Tom,
I would like to quote myself from http://elcuco.blogli.co.il/archives/134:
(real life knocked our doors, and WebKit/Qt4 is much more maintained then KHTML4.0)
I would like to point you to an (really old) page of mine, here: http://dgi_il.tripod.com/linux/hebwww.html. Please look at the date at the top left corner of that page.
Lets start with the facts:
I was using Konqueror until 2 months ago. The reason why I stopped using it was because some id10ts decided to create plugins which are not compatible with Konqueror (and I do see it that way, they decided to make plugins which cannot be loaded by Konqueror, IMHO it’s not a Konqueror bug). Yes, this is the Flash plugin beta. They decided to code is in such way that it’s not compatible with Konqeuror’s out of process handling. I decided to ignore it for several weeks, but then I decided that I do want to watch YouTube videos in full screen. I had to move to Firefox.
In 2003 there was a huge period of time, in which http://www.google.co.il/ig?hl=iw (the Hebrew version) and http://il.kde.org (back then it was http://kde.org/il) were not rendered properly under KHTML 3.2 (I think, or was it 3.3?). Only in aKademy I was able to reach you guys (the KHTML developers) and ask you to fix those things. The problem with kde.org happened on Justified and dir=RTL text elements which was fixed a week or so later, and the Google bug was a triggered by putting a centered table on an dir=RTL element (and was fixed by a Nokia merge, remember those?)
What I am trying to say, is that with all the respect I have for you guys (and I do, I was using your browser/engine for 7-8 years, I know how good it is, and how hard it is to make it), you have too much work and you are too few people. The WebKit engine will be integrated into Qt4.4, it will be available “free” for you. It’s based on code that your once wrote, and it had much more people then KHTML to review code and fix my bugs (yes, the BiDi/HTML bugs are much more rare and hard to fix, since very few of you guys do test for those issues or use them). I know that WebKit will have much more developers then KHTML, and I think this is a good reason to use it (I think Zak said it first a few weeks ago).
Once more, I will quote myself:
(real life knocked our doors, and WebKit/Qt4 is much more maintained then KHTML4.0)
I never said that there are no developers for KHTML. I never said KHTML stinks (he he… me not trashing something… you should print this page and frame it!), it actually kicks ass.
I am just saying that the WebKit code base is bigger, has more developers and will eventually be much more supported. Right now it’s an idea, an Engine. I hope to see a full web browser based on it. Just because I think (think, not know) that it will be easier for those stupid ms-html web masters to get a browser based on that technology on Windows and they can start coding site which are compatible with what I use. Currently, Konqueror is a real minority, I hope that WebKit with the Safari front end, the Epiphany/WebKit (http://live.gnome.org/Epiphany/WebKit) and the (yet to be released Qt4 based web browser) will get higher numbers on their charts, so I can demand for support.
If WebKit will not be used by Konqueror, I think it will be a great lost to a great product. Sometimes you need to look at your pet code, see how good is it and tar it in a good place. Not because better code has come, but because a library which has more developers is mature enough (like we did with dcop, which has not aged and is faster then dbus). I hope you make the best decition for me, but I don’t worry too much. Whatever you decide, I am sure you will do the best you can with it.
The only page complaining about Konq is my bank and it works after changing usage agent.
Is there any good reasons why KHTML and WebKit cannot merge? I can only see benefits and no drawbacks and it would give users best of both worlds.
Actually, there were discussions in Drupal (or jQuery? don’t know exactly) to drop support for KHTML because its JavaScript doesn’t do a lot of stuff that other engines do. I find it working ok mostly, but the always-looming threat of essential stuff not working in Konqueror is something that I really don’t like.
I gather KHTML is just as great as any other engine, but we won’t win a battle of one against thousands, no matter how hard the amazing KHTML devs try. As long as Konqueror has a market share below 3%, we’ll always fall behind the larger engines. And what I’d really hate to see is pages that don’t work in Konqueror while Epiphany uses WebKit-Gtk and gets them right.
Instead of just saying “KHTML is teh bestzorz”, why not mention some of the reasons KHTML is superior to WebKit?
I was under the impression that the plan was to merge the stuff that KHTML supports but WebKit doesn’t (Wikipedia has a good list) into WebKit, then kill off KHTML once all it supports is a subset of WebKit features.
Frankly, even if this isn’t the plan, it sounds good to me. I’ve seen some reasons why KHTML is better than Gecko (I disagree, but the individual points are valid) but few reasons why a separate KHTML and WebKit would be better than both sets of developers working on WebKit. If they did that, I see the possibility of WebKit becoming the most standards-compliant FOSS layout engine, finally dethroning Gecko and even giving Presto a run for its money, and shouldn’t that be considered a good thing for all?
I’ve used Konqueror for about 2 years now as my single browser. I’m also a web developer and my argument is the same as with others that its better supported and has more developers. But WebKit is also gonna be part of QT which seems a shame to ignore it. From my understanding Webkit is just KHTML with some kde/qt stuff ripped out and maybe a few mac things thrown in. If the code differs on certain parts that are important to you, couldn’t you just commit them to the webkit project? A sorta merge like the compiz and beryl camps did, for the greater good? I do know that theres a Webkit kpart so really whatever one is picked, is gonna be decided by the end user or distros in the end. I think both of them is the best answer for the time being…
As far as I see it, Apple have taken KHTML and added improvements to create Webkit.
Then surely KHTML is relative to Webkit as Debian is to Ubuntu?
There isn’t an argument here :)
I’m using Konqueror for 80% of my daily browser work. I have to use Firefox for the other 20% because Konqueror simply doesn’t work there. So far, I’ve no Webkit based browser installed.
Instead of seeing developers flame each other I’d rather have a feature in Konqueror which allows me to switch the rendering engine for a page on the fly. Give me KHTML *and* Webkit *and* Gecko. I’ll quickly find out which one suites my needs best and I’ll use a replacement where necessary.
Currently the startup of firefox when needed makes me tired. Having to startup a Webkit based browser besides Konqueror from time to time will make me tired.
So, as a user, I’d like to have the easy choice. Then I can tell you easily which one works best for me.
Until then, I will have to work with different browsers for different pages :-( which eats my time – time in which the devels can fight each other. Sometimes I’ll look at the damage and shake my head…
I’ve been using konqueror + KHTML for more than 3 years, and Konqueror + KHTML is getting better and more stable each release. I’d be pretty sad if it’s going to be replaced by QtWebkit, but if it’s the best for KDE, it gets my full support. But as long KHTML is still supported + developed by the developers, I’ll use it for my daily use ;)
But IIRC the decision is: shipping both engine for KDE 4.1?
Keeping KHTML is critical. It is one of only 2 open source and open source controlled HTML rendering engines. WebKit is in the claws of Apple, which is not a very nice company (sorry Apple fans). As long as commit access isn’t freely available to the KDE community, WebKit will remain the inferior option — even if it is marginally more useful today due to engine-specific coding by a few web authors. The only way to make WebKit a serious contender would be to fork it, and then comb it for flaws and backdoors introduced by the apple crowd. Personally, I’d think it easier to add the few features WebKit might have than perform this combing.
For the record, I only use KHTML except for a very few purposes (where I use Gecko), and I have not detected any problems. And frankly, if KTHML renders the pages nicely instead of how the authors intended, I do not regards this as a flaw :)