Version: (using KDE KDE 3.3.2) Installed from: Gentoo Packages Compiler: gcc 3.4.3 OS: Linux http://www.zytrax.com/tech/web/browser_ids.htm If I leave the konqueror browser ID as default, then the navigation links on this page are misplaced. The top banner is also the wrong colour (should be a blue bar across the top of the page). The same occurs if I change the konqueror browser ID to mozilla. If I change the konqueror browser ID to IE6.0XP, then the page renders as it does in IE. If I view the site in mozilla or IE, everything looks correct. Note that the page has different colours in IE and mozilla - in IE the page is all white and the navlinks are blue. In mozilla, the page has a solid blue bar at the top and the navlinks are white.
The default Konqueror ID seems to make the page show its Mozilla format, which Konqueror is apparently misrendering. Either because of bugs, or because of unimplemented features -- remember that Gecko supports more CSS nifty things thank Konqueror. Konqueror renders the IE version of the site better than IE. So don't compare to it. Changing the identification changes the site, so it's no point doing that.
It would be nice then to find out exactly what in the Mozilla version is rendered wrong. Please save the Mozilla-version and simplify it to a test case.
The problem appears to be that Konqueror (and Safari) don't calculate the value of the 'right' property correctly for the absolutely positioned .l-b div element. Simplified testcase coming up shortly.
Created attachment 13286 [details] Testcase
Created attachment 13287 [details] Manually specified 'right' property This shows that specifying the 'right' property explicitly fixes the bug.
Opera renders this like Konqueror and Safari too, but amazingly, Netscape 4 gets it right! I've emailed the site owners so that they can work around the problem.
This is the relevant part of the CSS 2.1 specification: http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
and as you can see by yourself there, we and Opera are doing it right, using shrink-to-fit as specified.
Right you are. Firefox 1.5 RC 1 exhibits the same problem, so I've filed a bug with them: https://bugzilla.mozilla.org/show_bug.cgi?id=315334