User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 In the file check-error.html, line #9 looks like this: <p><b/></p> Firefox will render the text "Line 1" correctly non-bold, but "Line 2" will be rendered bold, even if the the <b/> in line #9 is closed. If line #9 however looks like in the file check-ok.html (which is after my understanding of XML equivalent to the example above) <p><b></b></p> everything is rendered correctly. When I look at the two files with the DOM inspector, they seem to look identically. I will attach the two files mentioned plus a screen shot showing the wrong rendered file. Reproducible: Always Steps to Reproduce: 1. 2. 3.

I just discovered, that the same misbehviour occurs as well with the <i> tag instead of <b>.

serving xhtml as text/html is not a bright idea

This should be marked as WONTFIX. The page is being served as text/html and is therefore being treated as HTML. The testcase is invalid HTML, is not a common occurence, and therefore should be ignored. The testcase, when served with the application/xhtml+xml content type is treated as XML (thus XHTML) and is rendered correctly. See http://www.interactiveleigh.co.uk/moz-test/bug1/index.htm for an example. (Also see modified testcase as submitted by Bernd)

I think you miss the point. Both files are valid XHTML files (which even are semantically identical!) and this is confirmed by the W3C validator (http://validator.w3.org/), so both should be renderered correctly when I open them with File/Open File... I however noticed just now that the the two test files I submitted have been attributed with different types (text/html and text/xml), despite the fact that I have both uploaded with Content-type set to auto-detect. No idea, why they get different types...

(In reply to comment #7) > I think you miss the point. > > Both files are valid XHTML files (which even are semantically identical!) and > this is confirmed by the W3C validator (http://validator.w3.org/), so both > should be renderered correctly when I open them with File/Open File... > > I however noticed just now that the the two test files I submitted have been > attributed with different types (text/html and text/xml), despite the fact that > I have both uploaded with Content-type set to auto-detect. No idea, why they get > different types... > > I beleive Bernd changes the content-type. As I stated in my post, XHTML files served with the text/html content-type are treated as HTML. Your testcase was invalid HTML. If it is served as application/xhtml+xml then it is treated as XHTML (XML) and is rendered correctly. I still beleive that this is a WONTFIX bug. It is a bug, but it really is worth fixing - it isn't valid HTML (which is what the parser should be treating it as) and it isn't a common occurence so we don't need to fix this for backwards compatibility, add that to the fact that this does work when parsed as XML and I don't think we have a problem that needs fixing. WONTFIX?

I think got the point now why you're talking about the mime type all the time. The file I uploaded had the name check-error.html - and is rendered wrong! When I change the file fame to check-error.xhtml it is rendered correctly! Nevertheless I think this bug must be fixed. Even Windows XP does not recognize the .xhtml ending by default, so this why many people (like me) add a .ending to XHTML files. I made the switch to Firefox yesterday, so I would except that everything works as before - make the transition as smooth as possible or people will go back to IE!

(In reply to comment #9) > I think got the point now why you're talking about the mime type all the time. > The file I uploaded had the name check-error.html - and is rendered wrong! > When I change the file fame to check-error.xhtml it is rendered correctly! > > Nevertheless I think this bug must be fixed. Even Windows XP does not recognize > the .xhtml ending by default, so this why many people (like me) add a .ending to > XHTML files. I made the switch to Firefox yesterday, so I would except that > everything works as before - make the transition as smooth as possible or people > will go back to IE! > Firefox must parse the code either as XML or HTML and must make a choice. It currently does that by using the content-type. If HTML or poorly coded XHMTL was rendered as XML then it would the majority of web sites would not render. So if Firefox is sent a text/html content type then it treats it as HTML. The test case was invalid html so it broke. If Firefox receives an application/xhtml+xml content type then it knows it has xml and thus renders the test case as intended. This is a bug, but shouldn't be fixed because there are no scenarios where inline elements such as b and i should be empty, nor do any legacy web sites tend to use any such technique to achieve layouts. This bug may take a lot of effort to fix and it would be time wasted because Firefox is behaving as it should in all reasonable scenarios. The testcase demonstrates an XML file with a malformed content type header trying to achieve what amounts to nothing.

read the description of the issue at http://www.hixie.ch/advocacy/xhtml

There are a zillion bugs like this already filed. They're all invalid or dups of each other. If you're going to use XML closing syntax, the page must be XML. If isn't not, then it's parsed as text/html and must be coded accordingly. Period. Picking a bug to dup it to of the many candidates. *** This bug has been marked as a duplicate of 268477 ***

Also see http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_3 , which says you shouldn't do this in XHTML sent as text/html.