82829 - [RFE] Enable XHTML Transitional text/xml scripts inside <!-- --> comments

Status: RESOLVED WONTFIX

(Core :: XML, enhancement)

Description

[Alex Vincent [:WeirdAl]]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
BuildID:    

Bug #27403 is related.

The above link possesses a script which a JavaScript developer new to XHTML 
expects to run correctly.  The script is:

<script type="text/javascript">
<!--
alert("Hello World")
-->
</script>

The W3C XHTML 1.0 specification recommends against this particular formatting, 
favoring CDATA sections instead.  

-- quote --

Note that XML parsers are permitted to silently remove the contents of 
comments. Therefore, the historical practice of "hiding" scripts and style 
sheets within comments to make the documents backward compatible is likely to 
not work as expected in XML-based implementations.

-- quote --

http://www.w3.org/TR/xhtml1/ Section C.4

The reason I classify this as an RFE is the word "permitted".  Mozilla does 
silently remove the commented-out sections.  Unfortunately, when an XHTML page 
includes an event handler, you can forget about that event handler accessing 
any such commented scripts.  The result is an exception in XHTML served as 
text/xml which we do not see in XHTML served as text/html.

Have not tested this as application/xhtml+xml yet.

If we could re-enable the interior of these commented-out sections for 
<script>...</script> and <style>...</style> elements only, that would solve 
this problem.

I recommend this only for the Transitional implementation, because it is a 
transition from HTML 4 to XHTML 1 Strict.  (But I wouldn't be disappointed if 
this quirk was fixed for XHTML 1 Strict as well.)

Reproducible: Always
Steps to Reproduce:
1.  Open the link in the description.


Actual Results:  No alert windows, just a text breakdown of the supposed 
problem.

Expected Results:  An alert window and the text breakdown of the supposed 
problem.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: Same testcase as above, but as application/xhtml+xml

Comment 2

[Karl Ove Hufthammer]

I *strongly* recommend 'wontfixing' this.

If it's "fixed", people will begin to depend on this behaviour.

And they mustn't do this, since the UA (or XML parser) *is* free to remove
comments. It's better with a clean break now.

This isn't really much of a problem, since

1 Very few people are using XHTML, and even fewer are using XHTML
  with commented inline scripts
2 Very few browser have a problem not-commented scripts and CSS
  (Actually, I can't name one which have any problems, and if such a
   does exist, it will surely have problems with other XHTML features,
   like the XML declaration.)

Comment 3

[Alex Vincent [:WeirdAl]]

I respectfully disagree with all your points except the first two sentences.

XHTML 1.0 is the latest official W3C standard.  True, few people are using it, 
but XML is only now starting to be a major force, given MSIE and NN6/Moz's 
implementations to date.  I believe XSLT, a piece which succeeds CSS for 
styling XML, has just landed in Moz0.9.  Right now, HTML 4 is the preferred 
standard.

Regarding commented inline scripts:  This is the current practice in HTML 4.  
As we see developers migrating from HTML 4 to XHTML 1, using commenting does 
cause a break.  We JavaScripters have been trained to think in terms of <!-- --
>; what is this <![CDATA[...]]> anyway?!? (rhetorical question)  The W3C 
validator validates my testcase as XHTML 1.0 Transitional, using the <!-- --> 
practice... which means a JSer not watching carefully will become thoroughly 
annoyed when they fire an event and get an exception.

Regarding commenting them out at all:  A valid point considering the browser 
market share.  However, I always try to push people to be prepared for that 
0.1% which doesn't watch for it.

I posted this bug to distinguish it from bug #27403 as a separate issue.  
WONTFIX might be a good idea -- or it might not.  I actually don't know which 
way to recommend on that resolution point.  As I said before, I feel a "middle 
course" may be appropriate -- enabling for Transitional, leaving dead for 
Strict.  Frameset, I don't know whether that's closer to a transitional state 
or a strict state (lowercase intended).

Comment 4

[Karl Ove Hufthammer]

> but XML is only now starting to be a major force,
> given MSIE and NN6/Moz's implementations to date.
> I believe XSLT, a piece which succeeds CSS for 
> styling XML,

XSLT is for transforming XML, not styling it. XSLT will never succeed CSS, as 
it's designed for doing something completely different. See <URL: 
http://www.w3.org/Style/ >, heading 'Why two Style Sheet languages?'.

> has just landed in Moz0.9.

It's a very early "beta", and not at all conforming to the XSLT rec.

Anyway, several XSLT processors ignore comments (this, of course, is depending 
on which XML parser they use). If people use XSLT to transform XML to (X)HTML, 
they may loose their commented JavaScript. If people believe they can use 
commented elements, they *will* loose their scripts/styles in one 
implementation or another.

> Right now, HTML 4 is the preferred 
> standard.

?

> Regarding commenting them out at all:  A valid point
> considering the browser market share.  However, I
> always try to push people to be prepared for that 
> 0.1% which doesn't watch for it.

Of course. But if you *really* want to be compatible with these UAs, you can't 
use XHTML, anyway (because of the XML declaration).

> As I said before, I feel a "middle 
> course" may be appropriate -- enabling for
> Transitional, leaving dead for 
> Strict.

This won't be easy. The XML parser have to parse the document in two ways, 
depending on the DOCTYPE (and finding the DOCTYPE in the first place requires 
the document to be parsed).

Also, I think this will only be very confusing for Web developers. (Why should 
it accept commented scripts in Transitional and ignore them in Strict? And what 
about XHTML 1.1?)

> Frameset, I don't know whether that's closer
> to a transitional state 
> or a strict state (lowercase intended).

I feel it's better to think of HTML 4.x as transitional, and XHTML as strict.

Comment 5

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

Reassigning to XML component.

Comment 6

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

I am resolving this as WONTFIX.

Previous comments discussed why, but I'll just summarize and explain things in
my words...

1. XHTML is new, and different from HTML. Developers should not expect
everything to work as they did in HTML.

2. XHTML is XML. XML world is much more strict than HTML. This clarifies things
for all parties, and incidentally makes it much easier to develop both the web
content and browsers. Everybody just needs to learn a few new things.

3. Also because XHTML is XML, and because of the things that XML processors are
allowed to do, there are no guanrantees that comments will be available in every
application. If we started supporting commented out scripts and styles it would
additionally bring interoperability problems.

In short, we do what the spec recommends to do to avoid surpising people, make
it easier to develop things, and promote good practices and interoperability.

If we learn that developers are beginning to widely use commented out script and
style code and it appears to work in other products, we can reconsider. But lets
not lead the way to wrongness ;)