(*** This bug was imported into bugs.kde.org ***) Package: khtml Version: KDE 2.1.0 CVS/CVSup/Snapshot Severity: wishlist Installed from: Compiled sources Compiler: gcc version 2.95.2 19991024 (release) OS: Linux OS/Compiler notes: Not Specified Various tags do not close if the order of opening and closing differs (eg. <b><u><font>something</b></u></font> does not close any of the three tags). As an example see http://www.cs.hut.fi/Opinnot/Tik-76.011/op01KT3.htm with both Konqueror and Netscape. I know this is not valid HTML but it would be nice to have it renered right. (Submitted via bugs.kde.org) (Called from KBugReport dialog. Fields Application KDE Version OS Compiler E-Mail manually changed)
*** Bug 31535 has been marked as a duplicate of this bug. ***
*** Bug 32852 has been marked as a duplicate of this bug. ***
In KDE 3.1.95, we get the opposite behavior of bug 31535 (marked as duplicate of this one). Rather than implicitly closing the bold tag at <p>, now the text stays bold until the end, despite the presence of a </b> tag. In the following example, the whole text shows up as bold, even the 222 after the closing tag. It's as if after a paragraph, all closing tags corresponding to tags opened before get ignored. <b>test<p> ing</b> 222 ... Tests with <p> </p> pairs show that it does work if paragraph is closed. However, even nowadays, many pages still use <p> as a single tag (not closing), and it might be useful to make khtml take such usage into account, rather than rejecting the </b> because of the "unbalanced" <p> tag. With <br>, for instance, it works as expected.
because <br> is no block element
Created attachment 4304 [details] test case Here is a test case for this problem, which I can confirm is still ocurring as of KDE 3.1.4: my <b><u><font color="red">foo</b></u></font> bar The problem is that the </b> and </u> are ignored because <font> is the last opened tag; only </font> is honoured. Instead, </b> should only be ignored if there is no <b> currently open, but should be closed, and should cause automatic closure of <u> and <font> since <b> *is* open, and since these tags appear after it. Later, </u> and </font> would then be ignored since there would be no such tags open, due to the automatic closure that occured previously.
>because <br> is no block element Would it be possible to have <p> treated as a "non-block" element too for the purpose of tag closing? Or as an optional block element (which may have, or may not have a closing </p>). Indeed unfortunately that is the way how many Web authors (unfortunately) use it for... (seen especially often in slashdot or similar discussion board comments: guy quotes a multiparagraph text, and puts a single <em> </em> pair around his group of unproperly closed paragraphs ===> the whole thing comment now shows up in italics, rather than only the quoted part!)
To handle improper nesting of tags "properly" (i. e. the way mozilla or opera do it), we'd have to add support for residual styles. This is *not* trivial. Therefore, don't expect this bug to be solved soon.
Support for residual styles has already be implemented by Apple. I attempted to merge back the changes, but hit troubles with some combinations of elements. I haven't been able to solve those yet.
*** Bug 97713 has been marked as a duplicate of this bug. ***
This bug is not restricted to situations where tags are placed out of order. The following web page: http://ubersoft.net/template.html Uses cascading stylesheets for all of its formatting, and all text on that page is displayed in bold text in Konqueror... except for italicized text, which is displayed normally.
Created attachment 10239 [details] Quick patch Here is a quick port of the WebCore code. It seems to work just fine. Leo, what problems did you encounter?
*** Bug 59454 has been marked as a duplicate of this bug. ***
*** Bug 86414 has been marked as a duplicate of this bug. ***
*** Bug 75481 has been marked as a duplicate of this bug. ***
*** Bug 59749 has been marked as a duplicate of this bug. ***
the regression ouput looks all fine indeed... I was concerned that the DOM manipulation could lead to crashes in the like of #99480, but so far it resisted all my worst attempts. Go ahead?
CVS commit by carewolf: Merge WebCore handling of residual styles, which improves our handling of various broken HTML. BUG: 20976 M +4 -0 ChangeLog 1.414 M +303 -7 html/htmlparser.cpp 1.357 M +7 -1 html/htmlparser.h 1.67
Works fine in 3.4.91 beta1