After successfully using KHTML and KJS as cornerstone technologies to build their much praised Safari web browser, Apple engineers have now made the first steps to adopt the next generation of KDE's web technology into their WebCore rendering engine. Apple developer Eric Seidel was proud to announce the introduction of experimental SVG support into WebCore: "Over the last few months I ported KDE's new DOM architecture 'KDOM' as well as their Scaleable Vector Graphics (SVG) implementation 'KSVG2' and render tree library 'KCanvas' to WebCore."
There is no SVG support in Safari itself yet, but the chances of KDE 4's SVG technology being used by Safari and Mac OS X have been greatly increased by this move. There is now a special section devoted to SVG on the WebCore site.
KDOM and KSVG2 are slated to be moved into the core of KDE 4. With Apple including the technology into WebCore, this means that several Safari engineers will be now be working full-time with KDOM/KSVG2/KCanvas. Eric Seidel's KSVG2 contributions can already be found directly committed to the KDE Subversion repository. Given that Apple has recently improved the accessibility of WebCore development to KDE hackers by moving it to an open bug tracking system and a publicly viewable CVS server, this is good news for KHTML hackers.
KDE core developers Nicolas Zimmermann ("WildFox") and Rob Buis ("rwlbuis") have been working rather silently, but hard on a new DOM implementation for nearly 2 years. KDOM is intended to be much more extendable than the current DOM technology used by Konqueror (extending to MathML comes to mind), and will make it easy to build in any future W3C standard. A sketched out design document for interested developers can be found in KDOM's repository.
It looks like KDE 4 is already well on track to establish itself as the leading implementation and development platform for current and future web technologies.
Comments
Sure this is hard, but also I'm sure it's easyer dealing with the long time KDE hackers vision have. The first time I saw the Qt/KDE API I fall in love with the flexible and simple interface it has. When I saw the code I said myself "These guys know what they are doing, and they are doing it seeing the coming years". But it would be sad if it's the only one supporting it, no webmaster mass will put svg until IE, or at least mozilla/firefox, can handle it. Someone knows if there is some plan for these browsers about svg or mathml?
BTW I'll say I think these things are related to OO programing, slow at start, but when the framework is done, the speed increases geometrically. I'm seeing something like this with KOffice, many time building the bricks, without seeing the house is not the best frame for hackers to work on it. But now seems there are very solid walls, attracting good bricklayers, draughtsmans and architects :)
AFAIK Firefox already supports SVG experimental. You'll just have to activate it in the about:config.
Mozilla has had support for MathML for years (5?) and some basic support for SVG also for many years (3?), although far from complete. But since no one is using these standards, they are not enabled in default builds. This reduces bloat due to unused features. They did the same for MNG. It used to be included, and they removed it.
http://www.mozilla.org/projects/mathml/
http://www.mozilla.org/projects/svg/
the nightly build have had svg enabled for quite some time now and firefox 1.1 will ship, with svg switched on by default, soon.
kudos to the KDE Hackers, i've taken a look at the sources in svn repository and was impressed ! Can't wait to see KDE4 going Alpha.
best regards
MaxxCorp
Are Nicolas Zimmermann and Rob Buis employed by someone to do this work?
Derek
Hi Derek,
Unfortunately not :} Its all (rare) spare time programming.
I would love to hack on it fulltime, but there you go...
Cheers,
Rob.
Not yet :-)
Rob and me would be interessted to work
full-time on our babies, given the fact
we have so much more stuff "in the pipeline".
Think about XPath, XSLT, MathML, (XQuery/XForms)
and most important: Compound Document Format.
(for instance inline SVG in xhtml etc..)
We'll keep on hacking, just like the last four
years, though bein' hired would surely push it even more.
So if anyone feels like helping KDE's future,
you know our mail adresses :-)
Yupp, couldn't agree more :)
While a large part of XPath 2.0 is currently implemented, the complete support of XPath/XSL-T 2.0 in KHTML would arrive more predictably, if it was economically stabilized.
Cheers,
Frans
Woldnt it be cheaper for Apple to use Rob and Nikolas for the job???? Does anyone knows somebody from HR in Apple?
Go Apple! It's nice to see the technology being pushed forward.
Anyone know if a QT4 backend is planned?
Hi,
You must mean for linux, since currently the OS X backend
uses the native toolkits and that will probably be most efficient.
Yes, a qt4 backend is likely to be created.
Cheers,
Rob.
"You must mean for linux, since currently the OS X backend
uses the native toolkits and that will probably be most efficient."
Not really. I would want a backend that will work on any platform that supports QT 4. :) I am not interested in adding platform specific code to x-platform QT app.
Keep up the good work.