correct way to include javascript and CSS in XHTML document

[sweenster]

I have this javascript to spam-protect my email address:


<script language="javascript">
var name = "brian";
var domain = "sweenster.co.uk";
document.write('<a href=\"mailto:' + name + '@' + domain + '\">');
document.write(name + '@' + domain + '</a>');
</script>


this works fine, but whenever I try to validate my code it fails - because of the language attribute and the fact that i'm printing HTML tags.

How would I fix this??

I have tried removing, changing & manipultaing both but with no success.

[liorean]

First of all, language attribute is deprecated. Use type="text/javascript" instead. Likewise, don't wrap your script in a comment as xml compliant browsers shouldn't parse comments even though they doesn't have to discard them.

As for the real problem, you can take multiple approaches to this:
- Use an external file instead.
- Escape &<>" with &amp;&lt;&gt;&quot; in the script (and suffer the browser incompatibilities this leads to).
- Use <![CDATA[ ...script contents... ]]> to allow any characters inside the script element

[sweenster]

Originally posted by liorean

As for the real problem, you can take multiple approaches to this:
- Use <[CDATA[ ...script contents... ]]> to allow any characters inside the script element

i'm intregued by this CDATA command. can you explain it??

as for using &lt; and &gt; etc - they wont work, it has to be < or > or it wont recognise it as a HTML tag.

[liorean]

The CDATA command tells the xml browser that the contents are of the form Character DATA, not of the default form Parsed Character DATA. This means that you can use the &<>" characters safely within the CDATA block.

As for the escaping of the characters &<>", I said the browser support was lousy (or rather that you had to suffer the browser incompatibilities, which essentially means thesame thing). By that I meant browser support is pretty much non-existant for any HTML browser. An XML only browser might be able to manage, however..

[liorean]

Hmm, considering the reason for the script, why don't you simply place the tag in the html again and replace the @ with @ to protect the email addy from getting caught by spam targets collectors?

[sweenster]

Originally posted by liorean
Hmm, replace the @ with &amp;#0064; to protect the email addy from getting caught by spam targets collectors?

good thinking, batman!

[Alex Vincent]

Originally posted by liorean
First of all, language attribute is deprecated. Use type="text/javascript" instead.


Netscape also supports an application/x-javascript content-type for JavaScripts. It's technically more correct, as text/javascript has not been registered as an official content-type.

As for the deprecated language attribute -- if you're using XHTML 1.0 Transitional, why not use both? Particularly if you're serving as text/html (though XHTML as text/html isn't generally a recommended practice -- don't ask me why...)

As for the real problem, you can take multiple approaches to this:
- Use an external file instead.


This is the most cross-browser solution there is. Because of irregularities in Internet Explorer, I recommend you use the open and close tags, instead of a self-closing tag:


<script language="JavaScript" type="application/x-javascript" src="myscript.js"></script>


Great question, automatic sticky.

[liorean]

Just correcting an error above <[CDATA[ ... ]]> should have been <![CDATA[ ... ]]>.

[WA]

To the question of how to include a CSS file in a XML file, please see this thread: http://www.codingforums.com/showthread.php?s=&threadid=18963

[Zvona]

I've managed with "comment" marks:


<script type="text/javascript">
<!--
var name = "brian";
var domain = "sweenster.co.uk";
document.write('<a href=\"mailto:' + name + '@' + domain + '\">');
document.write(name + '@' + domain + '</a>');
// -->
</script>

<style type="text/css">
<!--
mySelector {property:value;...}
-->

[Alex Vincent]

The main problem with that, Zvona, is that in "standards" mode (as opposed to quirks mode) a browser may decide to completely omit the contents of the comment. Mozilla is particularly good at that.

Not only that, but the -- characters will trigger an XML well-formedness error.

[Tails]

When was the <![CDATA[ ]]> introduced? I'm seeing it used more and more today, but I don't know how many browsers will recognize it. Is it safe to say that this can substitute the <!-- --> comment tags? Or should we put the <![CDATA[ ]]> inside them?

[liorean]

The CDATA blocks were introduced in the XML spec.

They are safe to use today, if you make sure browsers that don't handle them ignore them. This can be donoe through the following:<script type="text/javascript">
// <![CDATA[
...
// ]]>
</script>
And for CSS:
<style type="text/css">
/* <![CDATA[ */
...
/* ]]> */
</style>



The reason for using the CDATA block in XHTML pages:
XHTML is XML, and in XML elements cannot default to CDATA content. Content of elements is ALWAYS parsed, and if it is not well formed, it will cause an error (well, not when sent as 'text/html', but you really shouldn't do that unless the client lacks support for 'application/xhtml+xml'). Since the contents of script and style elements in HTML4.01 was of CDATA type instead of PCDATA type, you could use the characters < and & in it freely. That is not the case in XHTML where the contents model is PCDATA. The CDATA block allows you to write any character sequence except ]]> in the contents of the block, without it being parsed as XML. This allows you to use the same characters as you could in the HTML4.01 contents model.

Why you should not use SGML comments:
- XHTML is XML. In XML the content of comments shouldn't be parsed, thus, the script shouldn't run.
- You may not use the -- character sequence inside a comment in XML.


Browser support:
- If you use the CSS or JavaScript comments like I provided above, the CDATA block can safely be inserted into the document even for browsers that don't support them.
- The browsers that don't handle the CDATA block will choke on the </ sequence inside a script like they did in HTML4.01, which browsers that support the CDATA block will not.
- Browsers only support the CDATA block in XML ('text/xml' or 'application/xml') or XHTML ('application/xhtml+xml') modes, not in HTML ('text/html') mode.
- All browsers that support XML and/or XHTML mode support the CDATA block.

[brothercake]

All of which implies then that using CDATA to replace the old comment-hack is not generally a good idea - it's only okay for pages in XHTML mode. Yes?

[Alex Vincent]

It's only okay if the user-agent knows how to recognize it. Unless you can guarantee that only user-agents you know about will look at the page, it's better for you to assume it won't work.

This thread, being a sticky, will have some comments removed for brevity. (Liorean, if you want to do this first, be my guest -- and delete this comment while you're at it.)

[ReadMe.txt]

so which browsers will actually render XHTML documents served as text/xml, application/xml and/or application/xhtml+xml?

[gsnedders]

Safari, and I think FireFox and Opera 7 will as well.

[jkd]

Opera only started supporting the <script> tag in 7.5 when served as application/xhtml+xml and the like. Commands like document.write() don't work in Gecko either, when it is served as an XML mime-type, because the root document is XMLDocument and not HTMLDocument. I don't know anything about how Safari handles an XML mime-type, other than it does.

[Tails]

What does it mean to be "served as"? I've never heard of a server treating XHTML any different than HTML. Does this new file type mean anything when rendering? Is XHTML supposed to have it's own unique file extension if we want to distinguish it from the ordinary htm files? Was it a mistake that I used an XHTML 1.1 DTD on my pages instead of XHTML 1.0 Strict? What's going on with this?

[gsnedders]

XHTML 1.1 must be served as application/xhtml+xml, however, XHTML 1.0 can be served as text/html. As for the extension, you can use .xhtml, however I would advice against it, and use .html

[J&J]

Personally, I use unicode to display my email address & prevent spam. Web pages display it correctly, but spambots don't understand it. If you don't know how to convert it to unicode -- here's a website that does it for you, free:

http://andrew.hedges.name/experiments/obfuscator/


Just enter your email address on the left, & the unicode version will be shown on the right.

[Tails]

Personally, I use unicode to display my email address & prevent spam. Web pages display it correctly, but spambots don't understand it. If you don't know how to convert it to unicode -- here's a website that does it for you, free:

http://andrew.hedges.name/experiments/obfuscator/


Just enter your email address on the left, & the unicode version will be shown on the right.

So that's what unicode is? I thought it was ASCII (when the numbers are converted to hex, they match the numbers a hex editor will display for ascii text). I've always used only #64 to encode the @ sign since it's the most important part. Without that, the rest is insignifigant to the rest of the contant that may appear on the page. It's a nice link though.

[AaronW]

Isn't it highly likely that someone will write a spambot that looks for @ and its unicode equivelant? Wouldn't seem like something terribly hard to do...

I think it'd be clever to just encode the surrounding parts of the @. What're the odds of one looking for &xxx;@&xxx;&xxx;&xxx; ?

I just don't show my email anywhere and force visitors to use my contact <form> :P Those spammers will clue in eventually I betcha.

[ReadMe.txt]

Opera seems to ignore the CDATA dec when it's ecnased in /* */ CSS comments, anybody know what a good fix would be?

[brothercake]

Opera seems to ignore the CDATA dec when it's ecnased in /* */ CSS comments, anybody know what a good fix would be?
A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.

There's no correct way to do that trick. Just put the styles in an external file.

[liorean]

A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.

What? XML parsing precedes XML "rendering" (for lack of a better word for it) precedes parsing of any embedded content in another language, such as CSS or JavaScript. Thus, there would be no such requirement. Let's illustrate it:

Source<head>
<style attributes>
selector {
property : value; /* <![CDATA[ <a & comment> ]]> */
}
</style>
</head>
XML Parsing01. Start Element head
02. Text "\u000a"
03. Start Element style
04. Attributes attributes
05. Text "selector {\u000a property : value; /* "
06. Start CDATA
07. Text " <a & comment> "
08. End CDATA
09. Text " */\u000a }\u000a"
10. End Element style
11. Text "\u000a"
12. End Element head
XML "rendering"Element head
> Text "\u000a"
> Element style
> > Attributes attributes
> > Text "selector {\u000a property : value; /* <a & comment> */\u000a }\u000a"
> Text "\u000a"

Which means that the content sent to the CSS parser will be as follows:selector {
property : value; /* <a & comment> */
}

[ReadMe.txt]

A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.

There's no correct way to do that trick. Just put the styles in an external file.

well i needed it to be inline to hide from NS4, so since i was using an accept sniffer to server up different doctypes i served up uncommented cdata blocks with the xml mimetype and regualr old style html comments for the old doctype.

[devosc]

A current observation using CDATA as opposed to <!-- is that babelfish (the page translator) currently seems to only recognize the latter.

[Tails]

For validation, this has never let me down:


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

/*For loops and other things using the less than and greater than sign won't throw you errors now */

//]]>


But for pure XHTML (served as application/xhtml+xml), would it be more preferable for the script type to be application/x-javascript instead?

[brothercake]

But for pure XHTML (served as application/xhtml+xml), would it be more preferable for the script type to be application/x-javascript instead?
Surely "text/ecmascript" is technically most correct?

[jkd]

If you're using just ECMAscript, then yeah. But extensions like Array.prototype.map or Gecko's getters and setters, that's Javascript (1.5+).

text/javascript isn't official, so you're supposed to use application/x-javascript (but only Mozilla recognizes that mime-type as actual Javascript). So really, you can't be correct. Just go for text/javascript.