Closed
Bug 319959
Opened 19 years ago
Closed 19 years ago
CDATA section represented as comment
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
People
(Reporter: KlausRusch, Unassigned)
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050727
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050727
A CDATA section in an XHTML document when accessed using DOM methods is represented as an HTML comment.
With this XML fragment
<xml id="demo">
<attr><![CDATA[123456789]]>
</xml>
accessing the value of the attr element returns a comment (innerHTML) or the contents of a comment (data).
Reproducible: Always
Steps to Reproduce:
|
Reporter | |
Comment 1•19 years ago
|
||
|
||
Comment 2•19 years ago
|
||
Your example isn't actually a valid XHTML document (missing doctype, unclosed ATTR element, content type text/html), which causes Mozilla to treat it as an HTML document instead.
*** This bug has been marked as a duplicate of 228288 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
|
|
Reporter | |
Comment 3•19 years ago
|
||
Comment on attachment 205615 [details]
Sample file
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Sample page</title>
<style type="text/css">
input { position: absolute; left: 200px; };
</style>
</head>
<body>
<p>This page contains HTML and an XML data island:</p>
<pre>
<xml id="demo">
<attr><![CDATA[123456789]]></attr>
</xml>
</pre>
<p>
The CDATA section is represented as an HTML comment in the DOM tree:
</p>
<form id="form">
<p>innerHTML: <input type="text" id="innerHTML" name="innnerHTML" size="100"/></p>
<p>data: <input type="text" id="data" name="data" size="100"/></p>
</form>
<xml id="demo">
<attr><![CDATA[123456789]]></attr>
</xml>
<script type="text/javascript">
//<![CDATA[
var attrs = document.getElementsByTagName("attr");
var attr = attrs[0];
document.getElementById("innerHTML").value = attr.innerHTML;
document.getElementById("data").value = attr.firstChild.data;
//]]>
</script>
</body>
</html>
|
|
Reporter | |
Comment 4•19 years ago
|
||
|
|
Reporter | |
Comment 5•19 years ago
|
||
> missing doctype
Agreed. Adding an XHTML doctype does not change the behaviour though.
> unclosed ATTR element
Agreed. This is a typo in the testcase, the problem shows with a closed ATTR element as well though.
> content type text/html
XHTML documents may be served with a doctype of text/html: http://www.w3.org/MarkUp/2004/xhtml-faq#texthtml
|
|
Reporter | |
Comment 6•19 years ago
|
||
The problem is not limited to CDATA sections in XML islands.
Accessing the contents of
<textarea><![CDATA[123456789]]></textarea>
shows similar behaviour.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: CDATA section represented as commend → CDATA section represented as comment
|
|
Reporter | |
Comment 7•19 years ago
|
||
|
|
||
Comment 8•19 years ago
|
||
> XHTML documents may be served with a doctype of text/html:
True, but in this case you can only use the HTML DOM, which does _not_ include CDATA, see http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-E067D597
So, if you want CDATA to be supported by the DOM, you need to send your document as application/xhtml+xml or application/xml, not text/html. See bug 27403.
*** This bug has been marked as a duplicate of 27403 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 9•19 years ago
|
||
See also section C.11 in the XHTML spec (http://www.w3.org/TR/xhtml1/#C_11):
"User agents that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM."
"User agents that access XHTML documents served as Internet media types text/xml, application/xml, or application/xhtml+xml can also use the XML DOM."
|
|
Reporter | |
Comment 10•19 years ago
|
||
The XML DOM access does not work with
<meta http-equiv="Content-Type" content="application/xml; charset=utf-8" />
either.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
|
|
||
Comment 11•19 years ago
|
||
same testcase, sent by server as application/xml
|
|
||
Comment 12•19 years ago
|
||
> The XML DOM access does not work with [...] either.
Did you actually _test_ this? It sure does work for me.
|
|
Reporter | |
Comment 13•19 years ago
|
||
This works if the server sets the content type to application/xml, but fails if the content type is set differently by the server (or not provided for file:/// URLs) and overriden in a meta tag:
<meta http-equiv="Content-Type" content="application/xml; charset=utf-8" />
|
|
||
Comment 14•19 years ago
|
||
This is getting slightly off-topic now, but you cannot "override" what the server sends with a META tag. See bug 214952, in particular bug 214952 comment 5. Content type for file:// URIs is determined by the file extension, if you rename the document to "foo.xhtml" it will work.
So this is a dup of bug 27403. Don't reopen this bug unless you have a very good reason to do so.
*** This bug has been marked as a duplicate of 214952 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
|
|
||
Updated•19 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
|
|
||
Comment 15•19 years ago
|
||
Oops, that was the wrong bug number...
*** This bug has been marked as a duplicate of 27403 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•