Version: (using KDE Devel) Installed from: Compiled sources OS: Linux In the following example, simply beginning a cell with a <p> tag makes the subsequent <font> tag apply to only the first paragraph, instead of to all of the text until its closing </font> tag. If the cell is not begun with a <p> tag, the <font> tag applies to all of the text until its matching closing </font> tag, as expected. <table> <tr><td width=200> <!-- the following tag is the only difference between the two columns --> <p> <font face="Arial"> This text appears in Arial. <p> This doesn't, and it should. Instead, this text is in the "Standard font" from Konqueror's font configuration dialog. </font> </td><td width=200> <!-- here, there's no paragraph tag like we had above --> <font face="Arial"> This text appears in Arial. <p> This text appears in Arial as well, as expected. </font> </tr></td> </table> Mozilla and Opera display all text in the above example in Arial. This bug affects many popular websites, and while some might not be bothered by it, a shame it would be if it wasn't fixed for 3.2. This bug is not present in 3.1.4.
Created attachment 3198 [details] test case
but you're aware that this is invalid HTML?
> but you're aware that this is invalid HTML? I see now that the HTML is invalid. However, I do think it's important for Konqueror to handle buggy HTML in the same manner that the currently leading browsers do. To the end user, who is relatively unconcerned with HTML validity, this would look like a bug. But yes, maybe "erroneously" is not warranted in the summary title of the bug, and (on the subject of the title) I also regret the misspelling of "affecting".
If you start to "do this like the others" you will end in another war of bug-for-bug-compatibility. This will make the engine bigger and slower and will also break valid html pages where this behaviour may be exactly the way the author wanted it. And for that case there is a standard which describes how we should behave. We can't follow every bug a user might procude. My opinion: => wontfix
*** Bug 72587 has been marked as a duplicate of this bug. ***
I agree that bug compatibility races are bad, but the fact remains that lots of pages are broken in this way. I don't want to start up the big bloat of mozilla just to look at those pages. Would it be feasible to add configuration options to let the user select which bugs to work around? This particular case can never be valid HTML, so IMHO it's better to treat it as the most likely intended case, rather than the closest valid HTML. Perhaps a little icon indicating broken HTML, similar to the one for broken javascript, would be a good idea.
it's a bug and we know about it. We have tons of such work arounds
*** Bug 73587 has been marked as a duplicate of this bug. ***
I have to agree with David Chester.
David is the reporter afaik :)
OSNews story pages have the same problem. Each long article we got from third party writers don't close the P tag and so the fonts are all get screwed up. While this is not valid HTML, the non-closing of the P is the most done error on the web. Also, please note that Apple had the SAME bug on Safari last March 2003 and they fixed it. Now, it is 2004 and we get the same bug on Konqueror, while the previous Konqueror didn't have the problem. I believe that this should be fixed and allow Konqueror go around this buggy HTML people tend to write.
Actually, the end tag is optional in HTML 4.01. http://www.w3.org/TR/html401/struct/text.html#h-9.3.1
If you continue reading you'll find the following: "FONT and BASEFONT are deprecated." Yes, we will fix the problem and it's even quite high on our list, but repeating the same argument won't help here.
Yup, they are deprecated. Problem is, OSNews targets readers from a lot of cr*pped up OSes, like Amiga, BeOS, Risc OS, PDA browsers, mobile phone html browsers etc etc. These devices and OSes don't have new browsers, so it is imperative for us to offer HTML 3.2 and sometimes we go as low as HTML 2 (e.g. with the CENTER tag) just to be able to browse in these browsers... New CSS stuff are great, but backwards compatibility is very important too.
*** Bug 75272 has been marked as a duplicate of this bug. ***
The residual styles from #20976 fixes some of these cases, but not all of them.
Fixed by residual style update today.