135425 - empty elements (eg: <em/>) not closed in XHTML documents

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Mike Gratton]

Given an XHTML document served as text/html, empty elements which normally
contain character data (eg: <em/>) are not getting closed when the document is
served as text/html. If the document is served as text/xml, it works fine.
Putting a space before the slash: <em /> does not help, and this problem also
exists for HTML documents.

Not that this behaviour is also apparent for an identical HTML (i.e., non-XHTML)
document, but that's probably fine as (AFAIK) HTML does not support empty elements.

This is a regression, it works fine in 0.9.9, not working in builds at least
from 2002-04-03.

Two test cases to come.

Comment 1

[Mike Gratton]

Attachment: XHTML (served as text/html) testcase

Minimal test case, served as text/html.

Comment 2

[Mike Gratton]

Attachment: XHTML (served as text/xml), identical to first attachment

This testcase is identical to the first, but is served as text/xml and so does
not exhibit the same behaviour.

Comment 3

[Christopher Hoess (gone)]

XHTML served as text/html is parsed by SGML (well, tag-soup, anyway) rules 
rather than XML rules, a practice endorsed by the HTML WG.  This is probably 
INVALID.

Comment 4

[Mike Gratton]

Ahh, right, Section C.3 of the XHTML 1.0 spec suggests avoiding this sort of
minimised element, so I guess this could be marked INVALID.

My $0.02: It would be nice to fix the regression so Moz does not appear to be
one of those legacy browsers that Appendic C is trying to cover for, I also
think it could make transitioning to XHTML easier for web developers - this bug
certainly broke the UI of two XML based web applications I'm working on.

Comment 5

[Christopher Hoess (gone)]

Resolving INVALID.  To cut a long story short, remember that if you're serving 
this kind of markup as text/html, it will be accepted by older user-agents and 
probably throw a monkey wrench into their parsing.  If you don't care about 
these user-agents, you should just switch to text/xml or application/xml to 
deliver your content :)  We uphold this (and the W3C Markup Working Group 
agrees) so that people aren't tempted to try to throw XML constructs at these 
old user agents.  (Incidentally, if you've been having problems with IE 
displaying "raw" XML when you give it XHTML with an XML content-type, I 
understand an "identity" XSLT stylesheet--that is, one that invokes XSLT 
processing but doesn't actually transform any of the document--applied to such 
documents will make IE work fine with them.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 146084 has been marked as a duplicate of this bug. ***

Comment 7

[Bill Mason]

*** Bug 266447 has been marked as a duplicate of this bug. ***

Comment 8

[Ali Ebrahim]

*** Bug 286497 has been marked as a duplicate of this bug. ***

Comment 9

[PikeUK]

*** Bug 293692 has been marked as a duplicate of this bug. ***

Comment 10

[Uri Bernstein]

*** Bug 327637 has been marked as a duplicate of this bug. ***

Comment 11

[Tal Cohen]

I've added 
<meta http-equiv="Content-Type" CONTENT="text/xml; charset=UTF-8" />
to the test case from Bug 327637, but this does not solve the problem. (Tried other charsets as well.)

The file is being loaded from the local filesystem (FireFox 1.5.0.1, Win2K), so there is no different way to configure the content type and no conflicting setting in HTTP headers.

I suppose this could be a bug in the parsing of HTTP-EQUIV that affects this bug, too.