38

The KHTML-Render-Engine is very fast (just KJS is slow). I think it could be even faster, when XML would be supported. There is good Qt XML/XSLT support. XHTML-pages could be rendered faster. Things like MathML could also be supported. (there is a Qt MathML-renderer)

The User wrote:The KHTML-Render-Engine is very fast (just KJS is slow). I think it could be even faster, when XML would be supported. There is good Qt XML/XSLT support. XHTML-pages could be rendered faster. Things like MathML could also be supported. (there is a Qt MathML-renderer)

What is the benefit to KDE of having their own, KDE only (X)HTML engine?

It should be integrated into KHTML.

svg could be supported...

The User wrote:It should be integrated into KHTML.

svg could be supported...

What are you talking about?

When KDE 2/3/4 were created there was no Qt intergrated browsing engine available so KDE created their own one, KHTML. Due to the binary/source compatibility requirements of KDE major releases, KHTML will have to be shipped for the remainder of the 4.x period so it will be maintained until then.

At this point QtWebkit does not offer the needed access KDE requires to make it fully integrate with KDE ( Such as DOM access in order for KWallet integration or form autofilling )

QtWebkit does not offer XML.
XHTML could be rendered like HTML. Maybe an easy solution is found to distinguish between parsing and rendering in KHTML. I don't know anything about the KHTML-layout.

I'm talking about:
http://en.wikipedia.org/wiki/XHTML
http://en.wikipedia.org/wiki/XML
http://en.wikipedia.org/wiki/XSLT (parsable with standard-Qt)
http://www.w3.org/TR/xslt
http://www.w3.org/TR/MathML/ (parsable with an additional Qt-lib)
http://en.wikipedia.org/wiki/SVG (widely used in KDE)

SVG and MathML are integratable into XHTML.

With SVG support we will got animation support on pages. But already we have also css-animation specification.

These aren't very important features. But I think they would be useful for future and for any application using KHTML. (e.g. help-pages)
There is good support for the underlying technologies and the rendering-concept is the same like with HTML.

bcooksley wrote:At this point QtWebkit does not offer the needed access KDE requires to make it fully integrate with KDE ( Such as DOM access in order for KWallet integration or form autofilling )

I understand all that. I also am in no position to advise KDE devs on what should be done.

However, I do not understand why the general KDE opinion that KHTML is more valuable than WebKit purely because of KDE integration. Is there not more value in maining the unix of small, reusable parts -- adding and maintaining the required WebKit/KDE integration required while leaving all the other work to the growing WebKit community?

The thing with KHTML is multi fold, this is a few of the problems:

1: Due to KDELibs BC policies, KDE is committed to maintaining KHTML until KDE 5 as it is part of KDE Libs in KDE 4. WebKit was not available for Qt at the time.

2: Due to short comings in the QtWebKit interface, it is not possible to access the DOM structure, so features such as Form autofilling and remembering passwords cannot work.

3: QtWebKit cannot use KIO natively I believe. This has already been fixed in the KDEWebKit project I think ( well at least the part about using KDE proxy settings, etc has... )

This should be a discussion about XML-support...

second biggest polish sommunity portal, fotka.pl (which is also in top10 of most popular sites in poland) is completly unusable both with Khtml and Webkit.

fotka.pl - 171 validator-errors. I don\'t think that this page could be rendered using strict XML.

The user: main page and login page are in HTML, check user profiles - they are in XSLT propably. Firefox, and even Ie dont have any problems rendering it, but in all current Kde webbrowsers, i have xml source on page only.

bcooksley wrote:3: QtWebKit cannot use KIO natively I believe. This has already been fixed in the KDEWebKit project I think ( well at least the part about using KDE proxy settings, etc has... )

QtWebkit allows you to give a network access manager. Qt comes with its own default network access manager built on top of QtNetwork, and KIO already provides a network access manager based on KIO jobs, so this problem is fully fixed. (In a similar way, KDE's cookie jar can be used.)