246932 - style of empty elements misses short closing form

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, enhancement)

Description

[Bryan Mills]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+

Empty elements terminated inside the opening tag (via />) are not seen by the
stylesheet parser as having been closed.  (see attached testcase)


Reproducible: Always
Steps to Reproduce:

Comment 1

[Bryan Mills]

Attachment: markup (valid XHTML, strict mode) showing buggy behaviour

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That would be the HTML parser, and it's not a bug, since HTML sent as text/html
should be parsed by the traditional HTML parser.  See:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_3
  (which says your document is wrong)

http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html
  (which says we're right, although it was undefined by the spec -- which means
  the spec was vague enough that it should never have gotten anywhere close
  to W3C recommendation)

Comment 3

[Bryan Mills]

Attachment: same (validated) attachment with correct MIME type

Comment 4

[Bryan Mills]

Attachment: same attachment again with xml declaration put back in

Comment 5

[Bryan Mills]

http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_3
Explains how one makes a page compatible with old (pre-XHTML) user agents.  It 
doesn't say anything normative about well-formed XHTML documents.

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/
Is the more-or-less official version of
http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html
It says "XHTML documents served as 'text/html' will not be processed as XML 
[XML10], e.g. well-formedness errors may not be detected by user agents."  This 
makes fairly explicit that the only major parsing difference they had in mind 
is that user-agents are allowed to accept ill-formed XHTML served as text/html, 
but not as any of the other possible types.  Because user-agents are not 
required to reject ill-formed HTML, why not accept the (ill-formed) minimized 
form in the HTML parser?

Mozilla accepts a lot of invalid HTML as it is, and renders it "correctly" 
anyway -- what's wrong with accepting valid XHTML with invalid MIME types and 
rendering it "correctly"?  I know that the DOCTYPE in the example causes some 
doctype switching to happen anyway -- if Mozilla is already doing the detection 
(and therefore gaining knowledge of the document type), why not go ahead and 
have the HTML parser deal with the minimized tags?  HTML documents aren't 
allowed to have XHTML DTDs, so it's not as though we'd be misinterpreting valid 
HTML.  The number of documents with a trailing empty "/" property and an XHTML 
DTD that would break because of this change is likely to be 0.

As one final note, I'd like to point out that the well-formed document with 
correct MIME type in the third attachment also breaks Mozilla's parser -- so 
saying "it should have a different MIME type to be parsed correctly" isn't a 
viable solution.

Comment 6

[Hixie (not reading bugmail)]

Because significant numbers of HTML pages expect <foo/> to be treated as <foo>.

Comment 7

[Bryan Mills]

The number of such pages that trigger standards mode is probably quite small.

The number of such pages that trigger standards mode and carry and XHTML doctype
declaration is probably even smaller.

Moreover, there is a big difference between <br/> being treated as <br> and <p
/> being treated as <p>.  The number of users that both expect <p/></p> to work
and create pages that trigger standards mode is likely to be smaller than the
number of users that both expect <p /> to work and create pages that trigger
standards mode.  The number of users that expect pages with <p /> to render as
though the paragraph element were closed is likely to be extremely high, since
legacy pages with unclosed paragraphs that have been converted to XHTML and then
run through the w3's validator are going to change those tags to <p /> and
probably continue to serve them from the same location, with the same MIME type.

Comment 8

[Bryan Mills]

Attachment: test case more similar to pages likely to exist (intentionally incorrect MIME type)