Version: (using Devel) OS: Linux Installed from: Compiled sources Some pages on linuxtoday.com render very poorly. For example: http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-27-015-35-IN-KE Maksim and I were working on this today and he boiled the problem down to an extra "</li>" in their html. The following snippet is what Maskim reduced the problem to: <ul> <li> <a href="http://www.internet.com/it/">IT</a> <ul id="listMenu-id-1"> <li><a href="http://www.internet.com/it">internet.com/IT</a></li> <li><a href="http://www.voipplanet.com/">VoIP Planet</a></li></li> <!-- extra /li closes the ul, too --> <li><a href="http://www.wi-fiplanet.com/">Wi-Fi Planet</a></li> <li><a href="http://www.windrivers.com/">WinDrivers.com</a></li> <li><a href="http://www.internet.com/sections/">Network Map</a></li><ul> <li> <a href="http://www.internet.com/it/">IT</a> <ul id="listMenu-id-1"> <li><a href="http://www.internet.com/it">internet.com/IT</a></li> <li><a href="http://www.voipplanet.com/">VoIP Planet</a></li></li> <!-- extra /li closes the ul, too --> <li><a href="http://www.wi-fiplanet.com/">Wi-Fi Planet</a></li> <li><a href="http://www.windrivers.com/">WinDrivers.com</a></li> <li><a href="http://www.internet.com/sections/">Network Map</a></li> </ul> </li> </ul> </ul> </li> </ul>
sorry. I pasted Maskim's analysis twice. should simply be: <ul> <li> <a href="http://www.internet.com/it/">IT</a> <ul id="listMenu-id-1"> <li><a href="http://www.internet.com/it">internet.com/IT</a></li> <li><a href="http://www.voipplanet.com/">VoIP Planet</a></li></li> <!-- extra /li closes the ul, too --> <li><a href="http://www.wi-fiplanet.com/">Wi-Fi Planet</a></li> <li><a href="http://www.windrivers.com/">WinDrivers.com</a></li> <li><a href="http://www.internet.com/sections/">Network Map</a></li> </ul> </li> </ul>
Allan, this was regressed by your html5-style parsing commit (http://lists.kde.org/?l=kde-commits&m=119227301919656&w=2), which made LI and OL/UL have the same priority, meaning the popBlock for the extra </li> will pop right through the ol; e.g. the following makes it work: --- html/dtd.cpp (revision 913050) +++ html/dtd.cpp (working copy) @@ -105,7 +105,7 @@ 1, // ID_LABEL 1, // ID_LAYER 1, // ID_LEGEND - 5, // ID_LI + 4, // ID_LI 0, // ID_LINK 5, // ID_LISTING 1, // ID_MAP ...Thoughts?
*** Bug 182259 has been marked as a duplicate of this bug. ***
*** Bug 182598 has been marked as a duplicate of this bug. ***
*** Bug 182661 has been marked as a duplicate of this bug. ***
The proposed change is going to regress various cases where </li> needs to close other block elements such as <div> etc.
It seems what iceweasel's htmlparser does is that is forbids <LI> from containing <UL> and <OL> elements (they autoclose unclosed <li>). Secondly where we check levels to see if a close tag is allowed to close unclosed elements, they use the equivalent of "checkChild" in dtd.cpp. If we forbid LI from containing OL and UL, and replace the level-comparison with checkChild, we should match Gecko parsing. Though the current parsing HTML5, and Gecko is not.
Any chance you could do that? It's quite a bit beyond my familiarity/comfort level with the parser.
*** Bug 183501 has been marked as a duplicate of this bug. ***
*** Bug 183157 has been marked as a duplicate of this bug. ***
*** Bug 183931 has been marked as a duplicate of this bug. ***
Bug report #183931 says that the webkit kpart doesn't have this problem. And gives a picture.
Created attachment 32759 [details] My proposed patch Here is a patch that should fix the problem. I has not been regression-tested or compared with other browsers. It adds a similar quirk to <DL> vs </DD> and </dt> which may be wrong, and should be compared with other browsers.
I'll apply it locally and see how it goes. thanks carewolf!
I've been using carewolf's patch for 10 days now and I haven't noticed any problems. seems to help. I think it should be committed.
parser/list_dt.html seems the only regression test affected by this change.
Allan's patch in comment #13 fixes bugs #225247 and #186495 too. Are they duplicates of this?
*** Bug 225247 has been marked as a duplicate of this bug. ***
this is ancient . too ancient. closing