Bug 192783 - [testcase] list items <li> not correctly rendered based on doctype
Summary: [testcase] list items <li> not correctly rendered based on doctype
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.6.3
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-15 16:49 UTC by Andrea Iacovitti
Modified: 2011-05-21 13:57 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
online testcase (152 bytes, text/html)
2009-11-30 14:48 UTC, Andrea Iacovitti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea Iacovitti 2009-05-15 16:49:36 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Debian testing/unstable Packages

In the following example Konqueror displays the list items in one row.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML //EN">
<html>
<body>
   <li>item 1</li>
   <li>item 2</li>
   <li>item 3</li>
   <li>item 4</li>
</body>
</html>

WebKit 4.5.1 and konq 3.5 works well, ff3 displays items in columns without bullets.
Removing DOCTYPE declaration solves the problem.
I think that's the cause of the glitch in http://lists.debian.org/debian-kernel/2009/05/threads.html

thanks.
Comment 1 Frank Reininghaus 2009-05-16 18:19:39 UTC
Thanks for the bug report. I can confirm this in trunk (968518). On the one hand, the HTML code is invalid, so one should maybe not consider the unexpected rendering as a bug, but on the other hand, it might be desirable to be consistent with other browsers.

Note that the DOCTYPE declaration is a bit strange because it contains neither "strict" nor "transitional" - it also works if you replace it by

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

I assume that Konqueror interprets the DOCTYPE of your test case as "strict", that's why it doesn't treat the invalid HTML code as expected.

Might be a duplicate of bug 171435 (another issue where an invalid page claiming to be "strict" HTML is not rendered as expected).
Comment 2 Maksim Orlovich 2009-05-16 18:30:39 UTC
Gecko renders it in strict mode as well... I think it's more strict mode HTML5-style parsing related silliness.
Comment 3 Andrea Iacovitti 2009-11-30 14:48:27 UTC
Created attachment 38712 [details]
online testcase
Comment 4 Samuel Brack 2011-01-07 17:51:34 UTC
Confirmed in 4.5.4, updating version.
Comment 5 Andrea Iacovitti 2011-05-21 13:57:42 UTC
Reproducible in 4.6.3 as well