[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    kdom and khtml integration
From:       Rob Buis <rwlbuis () xs4all ! nl>
Date:       2006-02-26 23:21:59
Message-ID: 20060226232159.GA50130 () xs4all ! nl
[Download RAW message or body]

Good evening khtml hackers :-)

As some of you may know we have been working the last
year(s) on kdom/ksvg2/kcanvas - three seperated projects. The initial
aim was to decouple the whole DOM from the HTML stuff, which is contrary
compared to khtml itself. We've now reached a state where we actually need
integration of at least ksvg & khtml to support fancy things like CDF
(ie. xhtml in svg or the other way round). WebKit+SVG has already done
that by creating SVG RenderObjects and coupling the projects.

We haven't been convinced of this coupling so far, hence we introduced
a lot of things (CDFInterface, EcmaInterface, etc..) in the ecma & css
areas to be able to make kdom a "base" for ksvg and khtml which results in a
lot of 'virtual' usage, and more other things (don't want to describe all in
detail) which makes it impossible that our stuff will ever be as fast as
an integrated environment.

In addition to the speed problem, a protype has shown that seperating
kdom from khtml+ksvg gives problems with the design of things like
css and rendering. For instance, would kdom need a css parser? If so,
what css properties should it support? Even besides that, kdom's NodeImpl
would need to have rendering "hooks", that would need to be implemented
by the layers on top. It would be awkward to have to add new rendering
hooks later on.

Hence we think for the future it makes more sense to go the "integrated"
way, aka. kdom & ksvg & khtml all in one library. As khtml is de-facto
way more tested then our stuff we think that it's a good time now to merge
the "good things from kdom" into khtml trunk, while ensuring no regressions
are being introduced (of course :-). The next step would be merging
ksvg(2) into khtml, and renaming khtml to sth. like "kxml".

kxml's dir structure could be assembled similar to WebKit:
kxml/html, kxml/svg, kxml/rendering, kxml/core etc..

Here is an unordered list of the "good things from kdom":
* One-Class-One-File policy aka. having kxml/core/NodeImpl.cpp AttrImpl.cpp etc..
* Multiple parsing backends (ie. libxml2)
* Standalone XML processing facilities (KDOMParser / KDOMDocumentBuilder & friends)
* XPath 2.0 support
* XPointer support
* XInclude support
* OASIS Catalog support
* DOM3 Load/Save support
* quite some DOM3 core stuff
* full xmllint replacement: kxmllint
[ * XQuery/XSL-T support (in progress) ]
[ * Auto-generated cpp/js bindings (this needs discussion) ]

Please note that Webkit+SVG clearly shows that integrating svg with (x)html
can be done. Also our prototype, which groups ksvg2 and khtml2 and makes
use of SVG render objects in the same way as in Webkit, can handle xhtml+svg
fine, see for instance http://www.xs4all.nl/~rwlbuis/simpleCDF2.png

So, here is our proposal:
1. Split up to more files, like kdom/ksvg & WebCore does,
   for example dom_nodeimpl.h -> NodeImpl.h.

2. Consider merging webkit datastructures like AtomicString/QualifiedName and
   ElementFactory. This is optional ofcourse, however we have good experiences
   with this functionality in kdom.

3. Merge in "best of kdom"
3a Merge nice APIs like KDOMParser/KDOMDocumentBuilder.
3b Merge core dom functionality like DOM3 Load/Save.
3c Import XInclude, XPointer, Catalog projects which make use of kdom APIs.
3d Discuss XPath future at a later stage of porting.

4. Merge in ksvg2 code.

5. Merge in a subset of kcanvas into khtml/rendering.

6. Nice to have: do autogeneration of cpp/js bindings?

7. Consider renaming khtml to kxml, to reflect the improved xml capabilities.

Finally note that we are here proposing a possible process of integrating
more tightly in order to improve xml technologies support of Konqueror. We
are open to suggestions on how to go about doing this :)

Rob Buis <buis@kde.org>
Nikolas Zimmermann <wildfox@kde.org>
[prev in list] [next in list] [prev in thread] [next in thread]