"When creating custom DTDs like the one below, all browsers except Opera see the end of the ATTLIST as the end of the DOCTYPE. The result is that they print "]>" on the screen.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<!ATTLIST p behavior CDATA #IMPLIED>
Test page. http://www.quirksmode.org/oddsandends/dtd.html
Workaround is not included
Reported by ppk."
Moving this into component XML, though i'm not quite sure it's the correct one..
Changing to correct component.
Created attachment 9274 [details]
html test case
The original test case is served as text/html, but has a DTD based on XHTML 1.0 Transitional, which has caused some concerns about its correctness (see the comments at quirksmode.org). The attached test case has a DTD based on HTML 4.01 Strict; it exposes the same behavior - the validator accepts it (and parses as expected, which can be seen in its outline view), while major browsers don't.
I am not sure whether this document really is valid HTML - its DTD is not HTML 4.01 Strict, since it has an internal subset. HTML 4.01 explicitly lists the three DTDs used in HTML documents, and this is not one of them.
I have found discussions of this issue from as early as 1995 <http://1997.webhistory.org/www.lists/www-html.1995q2/0379.html>, but nothing authoritative enough to ignore the results of the W3C validator. Mozilla documentation seems to imply that they do handle internal subsets in HTML <http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing>, but I'm not seeing this.
*** Bug 23673 has been marked as a duplicate of this bug. ***
This bug is still there. Both HTML and XHTML are affected.
Besides, I think a better summary would be what I wrote in my bug report (before finding this one):
Trailing ]> from internal DTD subset is rendered as body text
Good suggestion, renaming.
We need to check what HTML5 has to say about this issue. Note however that I cannot reproduce this with XHTML (and the document at URL given in bug 23673 is plain HTML, see <http://hixie.ch/advocacy/xhtml> for more detail).
My fault. Sorry about that, should be fixed now.
Actually... I have to admit that the bug indeed does not appear when the page is XHTML.
We're parsing this correct w.r.t. HTML5.
*** Bug 94149 has been marked as a duplicate of this bug. ***