Bug 95146

Summary:	Formatting problems with page header (CSS?)
Product:	[Applications] konqueror	Reporter:	Andrew de Quincey <adq_dvb>
Component:	khtml	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	jim
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	Testcase Manually specified 'right' property

Description Andrew de Quincey 2004-12-14 14:48:40 UTC

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.

Comment 1 Thiago Macieira 2004-12-14 18:24:41 UTC

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.

Comment 2 Allan Sandfeld 2004-12-15 10:16:24 UTC

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.

Comment 3 Jim Dabell 2005-11-05 03:52:34 UTC

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.

Comment 4 Jim Dabell 2005-11-05 04:14:36 UTC

Created attachment 13286 [details]
Testcase

Comment 5 Jim Dabell 2005-11-05 04:17:43 UTC

Created attachment 13287 [details]
Manually specified 'right' property

This shows that specifying the 'right' property explicitly fixes the bug.

Comment 6 Jim Dabell 2005-11-05 04:27:12 UTC

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.

Comment 7 Jim Dabell 2005-11-05 19:07:33 UTC

This is the relevant part of the CSS 2.1 specification:

http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

Comment 8 Germain Garand 2005-11-05 23:37:13 UTC

and as you can see by yourself there, we and Opera are doing it right, using shrink-to-fit as specified.

Comment 9 Jim Dabell 2005-11-07 01:58:53 UTC

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