So the cold war between KHTML and WebKit heated up a little again, this time the enemy isn't Apple, but former KHTML developers, and KDE personas. I will spare you the links, since it is all too embarrassing.

As someone with a leg in both camps, I will try and explain what is the real issues are and suggest a road map for peace.

As some might have noticed GMail was updated this morning. As usual this broke the standard view Konqueror, but only if you use the recommended method of spoofing as Firefox.

Fortunately I traced it down and fixed it in no time at all

Here is the patch for your convenience (apply in kdelibs/khtml):

Well, at least according to css3.info . It is nice to when the changes you make, make a splash

Though seriously the most unique CSS 3 support we have are the CSS 3 Selectors I have meddled with for two years, the rest is mainly imported from WebKit in some form (such as text-overflow:ellipsis and CSS 3 Background and Borders), sometimes the imports has been easy sometimes painfull.

Some might have seen the summary before, because I posted this blog last week, but pulled it again because I wanted to double check that my recommendation is sane in MSIE. Turns out my assumption was right so here it is again:

Let me start with a rant. I see more and more websites using strict DOCTYPES, apparently webdevelopers have some misguided notion that this is most correct thing to do and guaranties the most consistent result. Nothing could be more wrong!

Let us examine the theory. Strict more is a mode for the browser to implement correct standard behavior. The browser will implement 'transitional' and 'quirks' mode to handle every broken site it gets delivered and provide 'strict' mode as a tool for webdevelopers to check if their design works when interpreted as strict as the browser is capable of. This means in theory that when strictness bugs are detected in the browser implementation, they are always fixed in strict mode, but only fixed in transitional and quirks if no important websites depend on the bug. This means for a website that uses strict DOCTYPE that the website can be rendered differently for each new browser version and suddenly end up looking broken, because it actually relied on a bug. For this simple reason, websites should never be published with strict DOCTYPE. Strict doctype is only a development tool.

Now for the facts: There are many websites everywhere that uses strict doctypes. Even nerdy technical minded ones like slashdot makes this stupid mistake. This of course means that browsers cannot fix bugs in strict mode without breaking websites (and breaking websites is the last thing a browser developer want), and with so many important websites relying on bugs in strict mode, strict becomes more and more quirky.

For Konqueror this basically means:
In quirks mode we implement IE5- bugs.
In transitional mode we try to act as sane and accepting as possible.
and in strict mode we implement Mozilla bugs (under the assumption that webdevelopers that use strict at least test in both MSIE and Firefox).

The next thing that comes up when I tell people this is: "But, this is all fixed with XHTML right?"... Nope, XHTML is much much worse! Since XHTML doesn't really work in MSIE when served correctly 99% of all XHTML sites out there doesn't follow the XHTML standard in even the most basic ways (delivered with text/xhtml+xml and starts with tag). As a result all the browsers treat sites with XHTML doctype in either a special XML-quirky transitional mode or simply as HTML4 transitional, and thus bugs are not detected and thus websites depend on being treated quirky.

So... What's to make of this: I don't really know. Except that the idea of making new strict types doesn't really work in practice, and just results in more and more weird modes in the browsers; all with their own set of quirks. The only clear lesson is for web developers: Just use HTML4 transitional.

As some of you know: When I implemented text-shadow for KHTML back in 2004, I added the ability to draw multiple shadows, because it was just a minor addition in my implementation, but one that meant we followed the entire spec. unlike Safari.

Ever since I've been trying to find a practical use cases for it though, and let's just say: It's not easy. Multiple shadows are just not all that usefull; but I think I've finally found one.

The basic premise is that text-shadows can be used to draw outline by keeping the shadow offset (0,0) from the text and add a small blur like 2px. Well, with multiple shadows I can draw an outlined text and its shadow, and the best thing is that it regress poorly and will be unreadable in all other browsers (invisible in Firefox and MSIE, and blurry in Safari)!!! Finally a secret kode for Konqui lovers.

It's done like this:

Ok, so multiple shadows is not all that usefull. Fortunately it was only a one liner addition, so if it gets removed from CSS3 Text I won't cry.

Yay I got my SoC project accepted!

So what is it: avKode - A Phonon backend for FFMPEG

It is basically killing a horrible interface and an error-source called xinelib, and going directly to the source. This also enables more powerfull features in the long run such as capture and encoding.

avKode will be a Qt/C++ implementation of libavformat which uses the universal decoder libavcodec as a backend.

At the same time I will attack a number of problems the other Phonon backends are running into. Basically fixing KIO in KDE4 to be much more usefull (adding seeking, cleaning interface, etc.)

The order of attack is something like:

• Update/implement the aKode phonon backend; to have a base for step 2.
• Clean-up and implement needed streaming/file-abstraction functionality in KIO
• Start porting libavformat to some sane Qt/C++
• Make playback work
• Make synchronization perfect.

Sometime post SoC I hope to be able to add encoding and other features provided by FFMPEG.

--
Right now I am sitting K3M - The KDE MultiMedia Meeting. It's a great opportunity to found out what everybody thinks we need, and get a good multimedia friendly start for KDE4 KIO.

Last year I completed the Google SoC with an entry about CSS 2.1 in KHTML printing. The project was a great succes despite low visability. (You can see the result by printing documents in Konqueror and notice that headers usually follows their bodies and text is rarely broken so one line is left alone a page).

Well, because I such a lazy student, I still havent finished my master thesis, so I am technically still allowed to do a SoC-project this year. So should I SoC?

I haven't had much time this fall to do much actual KDE development. So the number of tasks is starting to accumulate. I might have time to do one or two the next couple of months so I would like to give you the opportunity to give feed-back on what you feel is most important.

Seems Linus has started a new little flamewar

Among KDE developers we have always stated that anti-GNOME flamewars are only among users, and while it is technically true. It doesn't prevent users who also developers in other projects to join them. I will just comment here and hopefully not contribute to the fire.

As some bugs.kde.org votes might have noticed I've fixed GMail (standard view) again in Konqueror. Although it is an odd sort of fix, because I really just improved our Mozilla emulation so we change one more bit from our usual KHTML/MSIE behavior to that of Mozilla when spoofing as a Mozilla based browser. This means that GMail only works when you use UserAgent spoofing and set it to Firefox.