javascript in xhtml files: avoid errors with characters > < & ' " ??

[mark4asp]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

Does it depent upon the type of xhtml?

So for each of xhtml 1.0 transitional, xhtml 1.0 strict, xhtml 1.1
strict. How should I tell the browser that the special xml characters

< & " ' (for which xml mandates the use of entity values when they

appear as values) are to treated literally?

For instance is this (below) correct for all of xhtml 1.0 transitional,
xhtml 1.0 strict, xhtml 1.1 strict, or is it correct for only some of
them?

<script type="text/javascript">
// <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]>
</script>

When I use an external javascript file:
<script type="text/javascript" src="js/browser.js"></script>,
presumably I can dispense with the <![CDATA[ ... ]]> ?

PS: Sometimes I'm not able to use an external javascript file.

 

[Martin Honnen]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

If you want to embed JavaScript code in an XHTML document then use a
CDATA section to wrap the script code e.g.
<script type="text/javascript"><![CDATA[
JavaScript code goes here
]]></script>

If you want to use XHTML but send it as text/html to browsers like IE
then you need to use a construct like you have below:

<script type="text/javascript">
// <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]>
</script>

It does not depend on the version of XHTML at all as the need to use a
CDATA section results from XML rules which are the same for all XHTML
versions.

When I use an external javascript file:
<script type="text/javascript" src="js/browser.js"></script>,
presumably I can dispense with the <![CDATA[ ... ]]> ?

Sure.

 

[David Dorward]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

Does it depent upon the type of xhtml?

Not really.

So for each of xhtml 1.0 transitional, xhtml 1.0 strict, xhtml 1.1
strict.  How should I tell the browser that the special xml characters> < & " ' (for which xml mandates the use of entity values when they

appear as values) are to treated literally?

For XHTML 1.0 served as text/html, the spec says:

Use external style sheets if your style sheet uses < or & or ]]> or
--.

This may or may not be a requirement as the spec is badly written.
Postal's Law says to treat it as a requirement if you are authoring
XHTML.

For instance is this (below) correct for all of xhtml 1.0 transitional,
xhtml 1.0 strict, xhtml 1.1 strict, or is it correct for only some of
them?

<script type="text/javascript">
// <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]>
</script>

The JavaScript comments there are pointless and a waste of bytes, but
that is otherwise fine for any type of XHTML that is not served as
text/html.

You could also use &amp; et al, but that reduces readability.

When I use an external javascript file:
<script type="text/javascript" src="js/browser.js"></script>,
presumably I can dispense with the <![CDATA[ ... ]]> ?

More than that, you must dispense with it. It is meaningless in JS.

 

[mark4asp]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

If you want to embed JavaScript code in an XHTML document then use a
CDATA section to wrap the script code e.g. <script
type="text/javascript"><![CDATA[ JavaScript code goes here
]]></script>

If you want to use XHTML but send it as text/html to browsers like IE
then you need to use a construct like you have below:

<script type="text/javascript">
// <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]>
</script>

It does not depend on the version of XHTML at all as the need to use
a CDATA section results from XML rules which are the same for all
XHTML versions.

Thanks for clarifying this. I interpret your reply to mean that I only
ever need

// <![CDATA[
...
// ]]>


for IE. At least 50% of my users are still using IE6.

I'm still a little bit puzzled that this distiction:
'send it as text/html to browsers like IE' vs. your first sentence.

Currently my files have a DOCTYPE specifying xhtml 1.0 transitional and
I have wrapped my javascript in
// <![CDATA[
...
// ]]>

99% of my users are using IE in a ie6:7 ratio of 60:40. All my file
extentions are either .aspx or .html

So is there any reason ever why I should NOT use the // comments
preceding the CDATA markers? Perhaps in a perfect world where all
users have up-to-date browers? The // is just there to stop the legacy
browsers seeing an error?

 

[Martin Honnen]

Thanks for clarifying this. I interpret your reply to mean that I only
ever need

// <![CDATA[
...
// ]]>


for IE. At least 50% of my users are still using IE6.

I'm still a little bit puzzled that this distiction:
'send it as text/html to browsers like IE' vs. your first sentence.

You need to use the JavaScript comment and CDATA wrapper as long as you
are delivering your XHTML documents as text/html as HTML parsers don't
understand XML CDATA sections. IE does not understand
application/xhtml+xml, the MIME type for XHTML documents, so most XHTML
contents is send as text/html, even for browsers like Mozilla or Opera
which understand application/xhtml+xml.

99% of my users are using IE in a ie6:7 ratio of 60:40. All my file
extentions are either .aspx or .html

It does not depend on the file extension but rather on the HTTP
Content-Type header the server sends for a document. As long as your
..html document or your .aspx pages are served as text/html you need to
use the double wrapper of JavaScript comment and CDATA section.

 

[David Dorward]

So is there any reason ever why I should NOT use the // comments
preceding the CDATA markers?  Perhaps in a perfect world where all
users have up-to-date browers?  The // is just there to stop the legacy
browsers seeing an error?

Browsers are only going to see an error on CDATA markers if you claim
the XHTML is HTML (so why not use real HTML?), but the spec says that
if you do that then you should use an external file, so you wouldn't
be using CDATA markers at all.

 

[Jeremy J Starcher]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

The best solution might be to not use xhtml but use html 4.01 strict.

(IE 6 nor 7 recognize xhtml, rendering it as malformed html anyways and
will revert to operating in Quirks mode.)

 

[David Mark]

The best solution might be to not use xhtml but use html 4.01 strict.
Definitely.


(IE 6 nor 7 recognize xhtml, rendering it as malformed html anyways and
will revert to operating in Quirks mode.)

They revert to quirks mode only if the optional XML preamble is used.
This is because some brain-dead programmer at MS decided that the
doctype can only be found in the very first line of the markup.

 

[VK]

What is the best way to avoid errors with characters > < & " ' using
javascript in xhtml files?

Besides other helpful responses you may look at my post of 2006:

http://groups.google.com/group/comp.lang.javascript/msg/3bc6c90a43d9910f

 

[Thomas 'PointedEars' Lahn]

[...]
If you want to use XHTML but send it as text/html to browsers like IE
then you need to use a construct like you have below:

<script type="text/javascript">
// <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]>
</script>

It does not depend on the version of XHTML at all as the need to use
a CDATA section results from XML rules which are the same for all
XHTML versions.

Thanks for clarifying this. I interpret your reply to mean that I only
ever need

// <![CDATA[
...
// ]]>

for IE.

You misunderstood; "like IE" quite correctly means "IE and others". XHTML
is not yet universally supported on the Web. In fact, there are more user
agents that don't support it than user agents that support it, Gecko-based
UAs being one of the latter.

That said, those six bytes more won't do any harm but will do some good.

At least 50% of my users are still using IE6.

How would you even know?

http://PointedEars.de/scripts/test/whatami

I'm still a little bit puzzled that this distiction:
'send it as text/html to browsers like IE' vs. your first sentence.
http://www.hixie.ch/advocacy/xhtml
http://hsivonen.iki.fi/xhtml-the-point/

Currently my files have a DOCTYPE specifying xhtml 1.0 transitional and
I have wrapped my javascript in
// <![CDATA[
...
// ]]>

99% of my users are using IE in a ie6:7 ratio of 60:40.

Again, how would you even know? And more, what about the *future*? Even if
your numbers would be anywhere near correct, they don't allow a projection
about what will be tomorrow. Plus, interpreting those so-called
"statistics" that way creates a self-fulfilling prophecy: if you only code
for IE, you are unlikely to attract users that don't use IE, and you can
easily deceive yourself as being right in the first place when looking at
the resulting "statistics". (You may replace IE with any other UAs here.)

So, on the Web, you better hope for the best but are prepared for the worst
(however, IE suddenly vanishing would eventually be a Good Thing ;-)).


PointedEars

 

[Thomas 'PointedEars' Lahn]

Not really.

Yes, it does.

So for each of xhtml 1.0 transitional, xhtml 1.0 strict, xhtml 1.1
strict. How should I tell the browser that the special xml characters>
< & " ' (for which xml mandates the use of entity values when they

appear as values) are to treated literally?

For XHTML 1.0 served as text/html, the spec says:

Use external style sheets if your style sheet uses < or & or ]]> or --.

Quotations from third-party resources (that are not source code) should be
marked with more than an indentation. It is common to use a leading `|'
character or to use single or double quotes.

This may or may not be a requirement as the spec is badly written.

It is not a requirement as that would be indicated by the verb `MUST'
(which may be written in capital letters).

Postal's Law says to treat it as a requirement if you are authoring
XHTML.

Whatever that is, it does not apply here.

For instance is this (below) correct for all of xhtml 1.0 transitional,
xhtml 1.0 strict, xhtml 1.1 strict, or is it correct for only some of
them? [...]
<script type="text/javascript"> // <![CDATA[

var x = (z>0 && z<10) ? "blah" : "blah blah"

// ]]> </script>

The JavaScript comments there are pointless and a waste of bytes, but
that is otherwise fine for any type of XHTML that is not served as
text/html.

Whereas the latter would apply to XHTML 1.0 that is not written (seemingly)
HTML-compatible according to XHTML 1.0 Appendix C and to XHTML 1.1 (Basic);
those SHOULD NOT be served as text/html:

http://www.w3.org/TR/xhtml-media-types/#summary

So they are _not_ pointless at all.

You could also use &amp; et al, but that reduces readability.
True.

When I use an external javascript file:
<script type="text/javascript"
src="js/browser.js"></script>, presumably I can dispense with the
<![CDATA[ ... ]]> ?

More than that, you must dispense with it. It is meaningless in JS.

To be precise, it actually *means* a syntax error there.


Your signature delimiter is broken which is because of a bug in Google
Groups; I suggest not to use your usual signature when using GG.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Besides other helpful responses you may look at my post of 2006:

http://groups.google.com/group/comp.lang.javascript/msg/3bc6c90a43d9910f

As your posting is merely displaying your own misconceptions about the
matter, your posting would not be helpful at all but deepen the OPs
confusion about the matter instead. Please leave those postings disproved
and buried in old threads where they belong.


PointedEars

 

[David Dorward]

As will any other browser when the XHTML is served as text/html

They revert to quirks mode only if the optional XML preamble is used.

IE6 will. IE7 can go into standards mode when an XML prolog is
present.

 

[David Dorward]

Yes, it does.

Not in the sense that the OP appeared to be using the term "type",
although it does in other senses.

Whatever that is, it does not apply here.

Postel's Law (I misspelt the name the first time around) is the
Robustness Principle.

"Be conservative in what you do; be liberal in what you accept from
others."

In this case, "If you are writing a user agent, have it cope with the
more liberal interpretation of the specification, if you are writing
XHTML, have it conform to the more conservative interpretation".

When you hit specs which only bless Appendix C conformant markup to be
served as text/html while Appendix C is an *informative* section of
the spec, you are running into very wooly territory and Postel's Law
is the best stick we have if we're forced to deal with those specs.

For instance is this (below) correct for all of xhtml 1.0 transitional,
 xhtml 1.0 strict, xhtml 1.1 strict, or is it correct for only some of
them? [...]
<script type="text/javascript"> // <![CDATA[
var x = (z>0 && z<10) ? "blah" : "blah blah"
// ]]> </script>

The JavaScript comments there are pointless and a waste of bytes, but
that is otherwise fine for any type of XHTML that is not served as
text/html.

Whereas the latter

What is the latter in this case? I can't see distinct entities there.

If the XHTML conforms to Appendix C, then there will be no characters
that require the presence of CDATA markers.

If the XHTML doesn't conform to Appendix C, then tag soup slurpers
shouldn't be presented with the code, so they won't pass the contents
of the script block (CDATA markers and all) to the JavaScript
interpreter. (So the CDATA markers don't need JS comments to hide them
from said interpreter).

The comments are pointless in both cases.

 

[Thomas 'PointedEars' Lahn]

Yes, it does.

Not in the sense that the OP appeared to be using the term "type", [...]

Yes, it does, because there is a strong recommendation in favor and against
serving the markup with a certain MIME media type that depends on what the
OP apparently understood as "type":

| Does it depent upon the type of xhtml?
|
| So for each of xhtml 1.0 transitional, xhtml 1.0 strict, xhtml 1.1
| strict. [...]

And that media type plays an important part in defining the parser that is
eventually used to parse the markup.

[Postel's Law]

(May he R.I.P.)

When you hit specs which only bless Appendix C conformant markup to be
served as text/html while Appendix C is an *informative* section of
the spec, you are running into very wooly territory and Postel's Law
is the best stick we have if we're forced to deal with those specs.

The point you are raising is generally a good one (in fact, it is exactly
one of mine on other occasions), but it does not apply here. Yes, Appendix
C *is* informative, but that does not matter: iff XHTML is used, it does
exactly *no* harm to add those four to six bytes, and it will do some good.

So I really don't see why you would recommend against the script-commented
declaration, in favor of an additional script resource and therefore an
additional request when that would not be *necessary*.

For instance is this (below) correct for all of xhtml 1.0 transitional,
xhtml 1.0 strict, xhtml 1.1 strict, or is it correct for only some of
them? [...]
<script type="text/javascript"> // <![CDATA[
var x = (z>0 && z<10) ? "blah" : "blah blah"
// ]]> </script>
The JavaScript comments there are pointless and a waste of bytes, but
that is otherwise fine for any type of XHTML that is not served as
text/html.

Whereas the latter

What is the latter in this case? I can't see distinct entities there.

Any "type" of XHTML that is not served as text/html.

If the XHTML conforms to Appendix C, then there will be no characters
that require the presence of CDATA markers.

If the XHTML doesn't conform to Appendix C, then tag soup slurpers
shouldn't be presented with the code, so they won't pass the contents
of the script block (CDATA markers and all) to the JavaScript
interpreter. (So the CDATA markers don't need JS comments to hide them
from said interpreter).

The comments are pointless in both cases.

Yes, but Appendix C does not enter into it. Unfortunately, the W3C made it
no *requirement* to serve XHTML, "HTML-compatible" or not, with the proper
media type; it is not even forbidden to serve XHTML Basic/1.1 as text/html,
there is only a strong recommendation against it ("SHOULD NOT"). It is not
conformance or non-conformance to XHTML 1.0 Appendix C that determines which
parser is used, but the Content-Type header, and in some cases even the
resource name suffix.


PointedEars