The XHTML 1.0 spec recommends using CDATA sections to escape markup characters in JavaScript code - < is the biggest offender. (See http://www.w3.org/TR/2000/REC-xhtml1-20000126/#h-4.8 for details.) In the page entered as the URL the script fails to compile because of the use of a CDATA section. Adding the capacity to ignore these sections within a script would make Mozilla much closer to being XHTML compliant as well as HTML. (Other than this failing, it looks about perfect!)

It might make more sense for our HTML parser to learn about CDATA sections. Since the file is delivered as text/html, we're treating it as html. I'd rather see CDATA section handling in the HTML parser than our script engine - the comment hack should be as far as we should go with script parsing tweaks.

Vidur, who should this go to?

Kicking this to Parser.

this can wait. Marking FUTURE.

Does this work for documents sent as text/xml? If it does, then perhaps fixing bug 48351 will fix this.

Vidur: this bud's for you.

updated qa contact.

If you serve the document as text/xml it should work in Mozilla. In any case, I think Harish is the right owner for this bug. Reassigning. We should also re-evaluate the decision of futuring this. Nominating for nsbeta1.

I did some testing, and the script in the URL does not work in any browser I have installed on my NT: * Netscape 6.01 * IE 5.5 * Opera 5.01 * Netscape Communicator 4.7 There is also a well-formedness error in the document, duplicated name attribute in an anchor. When I saved the document locally with .xml extension, and fixed the duplicate attribute, it worked fine in Netscape 6. IE 5.5 opened the "view source" view, and Opera 5.01 didn't seem to understand it either. Based on these observations I am going to minus this. Whether or not to future I leave to Harish.

Based on Heikki's analysis I am futuring the bug ( will look into it when I've time ).

This is pretty important for another reason. If you comment out a script using standard comments (&lt;!-- and --&gt;) and try to reach it as an XML file, NN6/Moz will act as if the script's contents do not exist. Technically, this is permissible according to the XHTML 1.0 specification. So we have three options: (1) Use CDATA tags and have it break under text/html, (2) Use commenting tags and have the script not exist under text/xml (breaks if you have an event handler) (3) Use no CDATA, no commenting tags and hope nobody with a non-JS-enabled browser comes along. (4) Hope everybody in the world *quickly* adopts the W3C recommended XHTML mime- type (does Moz support it?) 'application/xhtml+xml'. (1) and (2) are undesirable in the extreme. (3) is undesirable but less so, in that it breaks one of the fundamental rules about scripting every JS developer is taught. (4) is going to take a while... I would strongly request we "unfuture" this bug and figure out a way to fix it. I see this not as an enhancement, but because it breaks in one mimetype one way and breaks in the other mimetype the other way, as a ***major*** bug.

Setting target to m1.0.

Mozilla supports application/xhtml+xml.

Filed bug #82829 for the text/xml commenting-out issue.

Thanks (genuine, not sarcastic) for the resolution wontfix on bug #82829. I appreciate getting that out of the way and being reassured of the *correct* path.

Can we make sure that when we fix this bug it doesn't conflict with bug # 9741? CDATA sections should not be available to the DOM for HTML, but they should for XHTML.

Personally, I think we should allow creation of CDATA sections in HTML, regardless of what DOM1 says. HTML docs with CDATA sections in them will, unless I'm grossly mistaken, validate; most browsers just don't support them. As it happens, the HTML tokenizer can handle and parse them just fine; modifying the content sink to support creating them as real CDATA sections (rather than comment nodes, as we do now) strikes me as being an acceptable change, and much cleaner and better than trying to rope down the implementation with doctype- and mode-sniffing.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

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

Passing along jst's keywords/nom from duplicate bug.

harish targetted 1.0, jst nominated 1.0 and in between asa shifted. resetting TM

In FUTURE.

According to the HTML WG, XHTML sent as text/html should be treated as straight HTML by user agents. Furthermore XHTML is not, per the spec, allowed to have CDATA blocks if it is sent as text/html. thus WONTFIX.

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

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

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

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