Version:            (using KDE KDE 3.2.3)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) 
OS:                Linux

When using CSS and Javascript to create dynamic webpages, it's often required to use computed CSS, which is (as far as I understand it) the final value for an attribute after all sources that can possibly affect this attribute have been parsed. Without this, it is not possible (to the best of my Knowledge at least) to determine the width of an object using the W3C DOM-Model 2, if the width is set in CSS only and not in the Javascript code.

Now, while creating a popup script using standard DOM and Javascript, I ran into the following issue: When using

/* popup is a DIV, previously fetched by document.getElementById() */
document.defaultView.getComputedStyle(popup,'').width

to retrieve the computed value for the CSS attribute "width" of popup, Konqueror returns the CSS Syntax to set this value, and not the value itself: 
"width: 102px".

Mozilla, on the other hand, will return "100px". This behavior is correct (at least to the best of my knowledge), because both, Mozilla and Konqueror, will report "100px" in case the attribue is accessible directly via popup.style.width - it is also the correct string to set the value.

I haven't thoroughly tested this with other CSS attributes, but I suspect it's similar - I hope this bug will get fixed in the next version of KHTML.

Workaround:
The bug is annoying because when using parseInt() on a string that doesn't start with a number, it will return NaN (not a number), making it impossible to use that value for calculation. Here's a quick workaround:

function tolerantParseInt(s) {
    while( isNaN(parseInt(s)) && s.length > 0 ) { 
        s = s.substring(1,s.length);
    }
    
    return parseInt(s);
}

This function will erase the first character of the string until a number is found, meaning the first number in the string will be used. This workaround doesn't break it in other browser, but still enables it to work in konqueror, without having to resort to browser detection. The function might be optimized by stepping through the string first instead of using substring everytime, but I think the performance loss is negligable, unless one needs to do a lot of tolerant String parsing.

As a sidenote, you'll notice a difference of 2 pixels in the returned values. In my case, width was set to 100px, I suspect the other 2 px are from the 1px border (left and right). This might be another bug in KHTML, but I'm not 100% sure, so I'll not open a bugreport for that one.