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.

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

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

> 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.

Reassigning to XML component.

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