Version: (using KDE KDE 3.5.6) Installed from: Gentoo Packages When a HTML source contains a line like <style type="text/css" /> konqueror acts as it was without /> at the end and wants to treat the whole file as a style definition. Minimal Testcase: http://www.schokokeks.org/~bernd/bugreport/konqueror-style.html Valid XHTML 1.0 Strict but incorrectly displayed by konqueror
*** Bug 143476 has been marked as a duplicate of this bug. ***
There is no such thing as <anything /> syntax in pure HTML(*). To make it work you need to serve the document as real XML-parsed XHTML. * Actually if browsers had implemented true SGML-parsed HTML, this would actually mean short cut-notation: <div /> </div> would be equivalent to <div>> <</div> SO DONT USE <anything /> IN HTML!
What does that have to do with this bug-report? The example provided is xhtml and even if it weren't - not displaying the whole document because of this markup error just does not make sense.
The example is NOT XHTML --- you're serving it as text/html. What your bug really means is that we don't handle some broken HTML right.
Ok, sorry, my fault. Please use http://www.schokokeks.org/~bernd/bugreport/konqueror-style.xhtml instead. Same file, transmitted as application/xhtml+xml.
Correct me if i'm wrong but RFC 2854 (http://www.rfc-editor.org/rfc/rfc2854.txt) says: > In addition, [XHTML1] defines a profile of use of XHTML > which is compatible with HTML 4.01 and which may also > be labeled as text/html. And according to http://www.w3.org/TR/xhtml1/#guidelines an empty element, which includes a space before the trailing '/>' is considered compatible. While text/html may not be parsed as XML and therefore some parsing errors should *not* occur, I don't think there should be any visible difference between a *valid* XHTML document rendered in either mode.
That's not what they mean in C.2, they just recommend including a space. We actually had handling of '/>' in one test release, and it caused severe problems because no other browser does. Seriously NO browsers parses '/>' in HTML mode. What happens here in Firefox, is that it realize that the <style> is not terminated before the end of the file, and then reparses with the <style> element closed. Try the following as a demonstration: <html> <head> <style> </head> <body> <p>This is visible in Firefox, hidden in Konqueror </body> </html> This is one of several dangerous parsing hacks in Firefox. We generally do not to implement broken stuff like that.
Let me rephrase the last comment: Actually we handle something similar with unclosed scripts, but we ignore many other unclosed things such as strings that firefox handles. Handling unclosed styles is a lot easier than unclosed strings, and be worthwhile if we really need it; but I would really prefer if we didn't have to implement such ugly hacks.
Handling such things also requires the parser to be quadratic in complexity, which is quite undesirable (try opening a file I'll just attach, with a bunch of style tags in firefox!) As for comment #5 -- there is a general bug with xhtml mimetype using HTML parsing, which is well known and will hopefully get fixed once I figure out some things about namespaces..
Created attachment 20851 [details] A little big-O demo
Oh, and as the warning: don't open that file in any firefox/mozilla instances you want to use soon.
.. On further thought, I think I take the quadratic thing back, as I think one can remember there is no </style> until some point, and treat any subsequent <style>'s as self-closing, but that would make the lexer even more horrendous..
Still present in 3.5.9 and trunk r798768 using the file served with the correct xml content-type.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.