27403 - CDATA sections not supported for XHTML served as text/html

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect, P3)

Description

[simonstl]

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!)

Comment 1

[vidur (gone)]

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.

Comment 2

[Mike McCabe]

Vidur, who should this go to?

Comment 3

[Mike McCabe]

Kicking this to Parser.

Comment 4

[harishd]

this can wait. Marking FUTURE.

Comment 5

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

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

Comment 6

[rickg]

Vidur: this bud's for you.

Comment 7

[bsharma]

updated qa contact.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 10

[harishd]

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

Comment 11

[Alex Vincent [:WeirdAl]]

Attachment: XHTML test document using script tags and commenting (Yes, I know it's not recommended)

Comment 12

[Alex Vincent [:WeirdAl]]

This is pretty important for another reason.  If you comment out a script using 
standard comments (<!-- and -->) 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.

Comment 13

[harishd]

Setting target to m1.0.

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Mozilla supports application/xhtml+xml.

Comment 15

[Alex Vincent [:WeirdAl]]

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

Comment 16

[Alex Vincent [:WeirdAl]]

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.

Comment 17

[Alex Vincent [:WeirdAl]]

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.

Comment 18

[Christopher Hoess (gone)]

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.

Comment 19

[Asa Dotzler [:asa]]

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)

Comment 20

[Christopher Hoess (gone)]

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

Comment 21

[Christopher Hoess (gone)]

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

Comment 22

[timeless]

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

Comment 23

[harishd]

In FUTURE.

Comment 24

[Hixie (not reading bugmail)]

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.

Comment 25

[James William Pye]

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

Comment 26

[Elmar Ludwig]

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

Comment 27

[Elmar Ludwig]

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

Comment 28

[Elmar Ludwig]

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