aKademy 2006: State of KHTML

This talk was held by George Staikos.

The history of KHTML


The Safari fork was very popular (as you see on the forks)
Merging back into KHTMLr2 was not very good (big patches dumped from them)

Unity was the experiment to bring WebKit back to KDE

Why KHTML is important
KHTML is _critical_ to the success of KDE!

• Provides a fast, light web browser and
• component that tightly integrates with KDE
• Gives us higher visibility as a procject: "the web" is much larger than linux
• great test environment

What we have: (He shows a slide with all the standards KHTML implements and says:)

The web in general

What we dont have

• internal SVG support
• Latest NSPlugin API support
• XBL
• Content Editable
• DOM bindings to non-C++/non-JS
• Opacity (Qt4 should help)
• Lightweight widgets (lots of widgets on a page can really slow down KHTML)

KHTML - From the industry
Great alternative to Cecko and Opera - small, fast, easy to understand, standards compliant. In use in many embedded platforms as well as dekstop browsers, Safari, Nokia, Omni. But: Forking is a problem.
Currently gaining respect from tother browser vendors, could become a major player with enough "unity" >= 10% market share.
KHTMl is also gaining industry respect (Microsoft regularly contacting KHTML developers, also Firefox developers, Google etc.)

Can we complete the "merge"?

• "Merging" is not really feasible at this point
• Unity - a port of WebKit to Qt4:
  • Kpart, KIO development is underway
  • Can co-exist with KHTML from KDE
  • Works "now"
  • Abstraction layer in WebKit makes it relativley easy to port
  • Open questions: How do we avaoid re-forking? How do we merge our own work?

If we go Unity, What do we gain?

• Support for many of the functions we lack as described earlier - XBL content editable, etc
• Bub for bug compatibility with many major browsers (This is important for industry acceptance, because they do not want to test their applications for gazillions of different browsers)
• More developer resources
• larger user base for testing and bug reporting (they have some great people which just create test cases for all forms of bugs)
• easier embedding in Qt-only apps
• Portability - the best win32 port?

What do we lose?

• Some possible trade offs in bug fixes and performance (work recently done by Maksim, Germain, Allan)
• Some flexibility in development model (we need to work as a team with nokia, apple, etc)
• Complete authority over the codebase
• Some functionality needs rewrite (form widgets, java applets, nsplugins, wallet, KDE integration)

He also wants to embrace us working more with the working groups:

Working with working groups

• W3C-Security (George has taken part of it)
• The W3C is constantyl approaching him and want that we be more part of it
• WhatWG - HTML5 (this is really great and we should be activly taking part of it!)
• KHTML/WebKit meetings (he takes part there all 3-4 months)
• Plugin Features (new plugin API, very important, George has no time for it)
• SVG
• Browser testing organization (Mozilla is forming this right now, we could participate, we would benefit from it greatly)
• JavaScript as standard programming language (is more and more used in MacOSX, we have KJSEmbed and are also embracing it, Plasma will use it as standard language for plasmoids for example)

Discussion

• Do we want to pursue WebKit/Unity? (if so, how do we approach it? what will the impact be on our community?)
• How do we avoid losing our own work
• How do we ensure that we are equal players in a joint effort with Apple, Nokai and others?
• How can we grow developer-interest without cannibalizing our existing developer base?

Question: What was it with the performance patches done? (which are not in WebKit/Unity)
Answer: CSS optimizations by Allen, New caching done by maxim


Personal comment: I think Unity is a great idea and i think we would all benefit from going this route in the long run, although we would loose some features of the current KHTML.