cdata and javascript

J

Jeff

I have a bit of javascript that I'd like to hide from the validator.

I thought I could do this:

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

// ]]>
</script>

But that doesn't work.

Should I be using XHTML to do this?

Jeff
 
J

Jeff

Travis said:


Nice how you snipped the question.

Why not? If I want to validate the page as I'm working on it I won't
have to wade through the 47 errors the validator thinks it sees in the
javascript where I'm assembling bits of html.

Did you think your response was going to be helpful?

Jeff
 
I

I V

Why not? If I want to validate the page as I'm working on it I won't
have to wade through the 47 errors the validator thinks it sees in the
javascript where I'm assembling bits of html.

What validator are you using? In HTML (but not XHTML), the content of a
script element is already considered CDATA, so the validator shouldn't
complain about HTML fragments in the script. I've just checked the W3C's
validator and it thinks this is valid, for instance:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>I AM YOUR DOCUMENT TITLE REPLACE ME</title>
<script type="text/javascript">
document.write('<foobar>');
</script>
</head>
<body>
<p>
Something in the body.
</p>
</body>
</html>
 
C

cwdjrxyz

I have a bit of javascript that I'd like to hide from the validator.

I thought I could do this:

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

// ]]>
</script>

But that doesn't work.

Should I be using XHTML to do this?

You are using at least some xhtml if you are using the CDATA comments.
CDATA is part of xml that may be used in xhtml. you would be allowed
to use it only if your page has an xhtml Doctype. If you get a lot of
errors at the W3C validator in the script that are xml errors in
xhtml, but not errors in html, you may use CDATA comments to hide the
script from an xhtml page, and a page then will validate at the W3C
with the proper xhtml Doctype. You can avoid this whole problem by
using an external script rather than one on the main page. There are a
few things in script on even an html page that must be avoided to
prevent validation errors. These are discussed at the w3c, and if you
make such an error, the validator in the most complete mode often will
tell you where to find information about the error. Some such errors
cause no harm and mainly are formal errors. However some such errors
may cause problems on some browsers and should be avoided.

The only way that anyone can help you in detail is if you post a url
for a page having the problem. Script can be a bit tricky unless you
use it a lot.
 
J

Jeff

I said:
What validator are you using? In HTML (but not XHTML), the content of a
script element is already considered CDATA, so the validator shouldn't
complain about HTML fragments in the script. I've just checked the W3C's
validator and it thinks this is valid, for instance:

The W3C's.

What happens is that I'm concatenating strings (content += ...) and
it's complaining about closing tags that aren't open (the are opened on
another line). I didn't expect that, I validated it because of the
problem in the next thread and I was surprised to see all that. I've
never used CDATA so I though it was time to learn. I was wrong!

I think I'll just take cwdjrxyz'z advice and ignore them for now. It
will of course wind up in an external file when I get done with writing it.

Thanks,
Jeff
 
J

Jeff

cwdjrxyz said:
I have a bit of javascript that I'd like to hide from the validator.

I thought I could do this:

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

// ]]>
</script>

But that doesn't work.

Should I be using XHTML to do this?

You are using at least some xhtml if you are using the CDATA comments.
CDATA is part of xml that may be used in xhtml. you would be allowed
to use it only if your page has an xhtml Doctype. If you get a lot of
errors at the W3C validator in the script that are xml errors in
xhtml, but not errors in html, you may use CDATA comments to hide the
script from an xhtml page, and a page then will validate at the W3C
with the proper xhtml Doctype.

Thanks. I understand this now. I've never used either xhtml doctypes and
cdata. I thought it may have been time to learn them. Or not!

You can avoid this whole problem by
using an external script rather than one on the main page.

I'll do that later. I think that's a good plan anyways!

There are a
few things in script on even an html page that must be avoided to
prevent validation errors. These are discussed at the w3c, and if you
make such an error,

You know, I read through that already and they just took me around in a
circle!

the validator in the most complete mode often will
tell you where to find information about the error. Some such errors
cause no harm and mainly are formal errors. However some such errors
may cause problems on some browsers and should be avoided.

The only way that anyone can help you in detail is if you post a url
for a page having the problem. Script can be a bit tricky unless you
use it a lot.

It's an odd thing, but here you are:

<URL: http://websiterepairguru.com/colorpicker_2.htm>

I don't expect you to hack through that, but if you have issues
figuring out color schemes like I do, it may be interesting... There's
some bugs (see next thread) when I added the strict doctype.

I wrote the left part of that back in '99 and I'm just trying to get
it up to date.

Thanks,
Jeff
 
T

Travis Newbury

Nice how you snipped the question.
Why not? If I want to validate the page as I'm working on it I won't
have to wade through the 47 errors the validator thinks it sees in the
javascript where I'm assembling bits of html.
Did you think your response was going to be helpful

Well since validation is a tool rather than a goal, I think my answer
was completely helpful.
 
C

cwdjrxyz

The W3C's.

What happens is that I'm concatenating strings (content += ...) and
it's complaining about closing tags that aren't open (the are opened on
another line). I didn't expect that, I validated it because of the
problem in the next thread and I was surprised to see all that. I've
never used CDATA so I though it was time to learn. I was wrong!

I think I'll just take cwdjrxyz'z advice and ignore them for now. It
will of course wind up in an external file when I get done with writing it.

See http://www.htmlhelp.com/tools/validator/problems.html and read the
section in it concerning javascript errors. One of the most common
validation errors is not backslashing when using a document.write
within a javascript. This reference discusses why this is required.
However the script will work on many, if not most, browsers in current
use if you neglect to do so.

 
J

Jeff

cwdjrxyz said:
See http://www.htmlhelp.com/tools/validator/problems.html and read the
section in it concerning javascript errors. One of the most common
validation errors is not backslashing when using a document.write
within a javascript.

Thanks, that explains that exactly.


This reference discusses why this is required.
However the script will work on many, if not most, browsers in current
use if you neglect to do so.


I find that interesting. Do you know of any specific examples where
the browser and not the validator would complain? It's always nice to
catch problems rather than vice versa.

Jeff
 
J

Jukka K. Korpela

Scripsit Jeff:
I have a bit of javascript that I'd like to hide from the validator.

Consider learning what a validator is before trying to fool it.

Then read the validator's FAQ list when you run into problems.

And if you use JavaScript, just put any bulky code into an external
file, and any validation issues with it vanish in a puff of logic.
Should I be using XHTML [...]?

No, especially since you asked.
 
A

A-OK-SITE

Scripsit Jeff:
I have a bit of javascript that I'd like to hide from the validator.

Consider learning what a validator is before trying to fool it.

Then read the validator's FAQ list when you run into problems.

And if you use JavaScript, just put any bulky code into an external
file, and any validation issues with it vanish in a puff of logic.
Should I be using XHTML [...]?

No, especially since you asked.

Jeff,

Everybody seems to have a preference as to which doc type they prefer
html or xhtml and most of it has no basis in reality. It is like the
old Ford vs Chevy argument in which both are good but for some reason
people just seem to like one more than the other.

XHTML is a cleaner code with features like self-closing tags (et al).
The XHTML is almost always served and interpreted as HTML with the
main difference being the syntax only. The new HTML 5.0 and XHTML 2.0
that is soon to be released is bringing the two types even closer
together based on preliminary information. It is also somewhat like
the difference between strict and transitional and both will render
the page the same with only minute differences in the way the page is
coded.

So in summary pick the language you feel the most comfortable with and
use it. They are both valid and fully functional, and all modern
browsers will render the code just fine. It is just my humble opinion
but I prefer XHTML, but I always preferred a Chevy and a Budweiser
too.

Daniel

http://a-ok-site.com
 
C

cwdjrxyz

Scripsit Jeff:
Consider learning what a validator is before trying to fool it.
Then read the validator's FAQ list when you run into problems.
And if you use JavaScript, just put any bulky code into an external
file, and any validation issues with it vanish in a puff of logic.
Should I be using XHTML [...]?
No, especially since you asked.

Jeff,

Everybody seems to have a preference as to which doc type they prefer
html or xhtml and most of it has no basis in reality. It is like the
old Ford vs Chevy argument in which both are good but for some reason
people just seem to like one more than the other.

XHTML is a cleaner code with features like self-closing tags (et al).
The XHTML is almost always served and interpreted as HTML with the
main difference being the syntax only. The new HTML 5.0 and XHTML 2.0
that is soon to be released is bringing the two types even closer
together based on preliminary information. It is also somewhat like
the difference between strict and transitional and both will render
the page the same with only minute differences in the way the page is
coded.

So in summary pick the language you feel the most comfortable with and
use it. They are both valid and fully functional, and all modern
browsers will render the code just fine. It is just my humble opinion
but I prefer XHTML, but I always preferred a Chevy and a Budweiser
too.

Unfortunately no IE browser, including IE7, can render any xhtml if it
is served properly as mime type application/xhtml+xml. All you get is
an error message. Many mis-serve xhtml as text/html and use an
extension .html. Although this often works for IE browsers, there is
no point in writing xhtml code in the first place if you are not going
to serve it as xhtml. Since the extension .html usually is associated
with the mime type for text/html on the server, you have to use
another extension, such as .xhtml, and assign it to the xhtml mime
type application/xhtml+xml on the server. Then when you serve xhtml
properly, in addition to IE browsers not working, other modern
browsers such as Firefox, Opera, Seamonkey, and Safari for Windows
will handle true xhtml. However then the code is parsed as xml. A xml
parser must be much more strict than a html parser. The least little
mistake, such as a single unclosed tag, gives a fatal parse error that
results in an error message rather than a view of the page, which
often works with little problem in html.

If you want to serve true xhtml, you have to provide IE html by using
separate pages, header/browser exchange and rewriting the page for
html for browsers that do not indicate they can handle the mime type
for xhtml, etc. The main reason for all of this trouble is that
Microsoft can not or will not write their browsers to handle modern
xhtml properly. Hopefully, now that Vista is out after much delay,
Microsoft will have time to bring their browser up to date. IE7 was
just a minor change from IE6. It did correct some bugs and might be a
bit more secure. However it was outmoded at the moment it was
released.

The important thing to remember is that you have xhtml only if both
the code is written in xhtml and it is served as application/xhtml+xml
- not text/html. The W3C validator only validates the code as html or
xhtml. It does not validate that the code is being served properly.
However, in the most detailed setting of the validator, it will tell
you if the page is being served as text/html or application/xhtml+xml.
You will find very few pages being served properly as xhtml when you
check them.
 
J

Jeff

cwdjrxyz said:
Scripsit Jeff:
I have a bit of javascript that I'd like to hide from the validator.
Consider learning what a validator is before trying to fool it.
Then read the validator's FAQ list when you run into problems.
And if you use JavaScript, just put any bulky code into an external
file, and any validation issues with it vanish in a puff of logic.
Should I be using XHTML [...]?
No, especially since you asked.
Jeff,

Everybody seems to have a preference as to which doc type they prefer
html or xhtml and most of it has no basis in reality. It is like the
old Ford vs Chevy argument in which both are good but for some reason
people just seem to like one more than the other.

XHTML is a cleaner code with features like self-closing tags (et al).
The XHTML is almost always served and interpreted as HTML with the
main difference being the syntax only. The new HTML 5.0 and XHTML 2.0
that is soon to be released is bringing the two types even closer
together based on preliminary information. It is also somewhat like
the difference between strict and transitional and both will render
the page the same with only minute differences in the way the page is
coded.

So in summary pick the language you feel the most comfortable with and
use it. They are both valid and fully functional, and all modern
browsers will render the code just fine. It is just my humble opinion
but I prefer XHTML, but I always preferred a Chevy and a Budweiser
too.

Unfortunately no IE browser, including IE7, can render any xhtml if it
is served properly as mime type application/xhtml+xml. All you get is
an error message. Many mis-serve xhtml as text/html and use an
extension .html. Although this often works for IE browsers, there is
no point in writing xhtml code in the first place if you are not going
to serve it as xhtml.

Just what is the advantage of serving xhtml+xml? The only thing I see is
something about being able to write objects differently. Or is this
about being able to add xml with an xslt stylesheet? If so, I do not see
that anywhere. The only "trick" I see is the object media thing: <p
src="some_image">something else</a>.

Actually from a quick look through the w3C and some other googling all
I see is syntax examples. And the syntax is not complicated! Perhaps a
working xhtml example that does something new.

Otherwise it seems like nothing but trouble. With much of the web
being driven by CMS if the parser doesn't grok the crap the author puts
in you wind up with a page more broken than it should be.

I don't have a problem with writing HTML XHTMLish, I even like the much
maligned <br />.

Jeff


Since the extension .html usually is associated
 
A

Andy Dingley

Just what is the advantage of serving xhtml+xml?

Compared to what? Compared to serving XHTML 1.0 as text//html, it is
a positive disadvantage for IE (it fails) and is a server-side
nuisance for doing it "properly" with other browsers, yet still has no
concrete advantage.

Compared to HTML (i.e. switching between "best practice" HTML and
"best practice" XHTML), again it's some complexity for no discernible
purpose.

There just isn't any _point_ to XHTML on the web.
 
A

A-OK-SITE

cwdjrxyz said:
Scripsit Jeff:
I have a bit of javascript that I'd like to hide from the validator.
Consider learning what a validator is before trying to fool it.
Then read the validator's FAQ list when you run into problems.
And if you use JavaScript, just put any bulky code into an external
file, and any validation issues with it vanish in a puff of logic.
Should I be using XHTML [...]?
No, especially since you asked.
--
Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/
Jeff,
Everybody seems to have a preference as to which doc type they prefer
html or xhtml and most of it has no basis in reality. It is like the
old Ford vs Chevy argument in which both are good but for some reason
people just seem to like one more than the other.
XHTML is a cleaner code with features like self-closing tags (et al).
The XHTML is almost always served and interpreted as HTML with the
main difference being the syntax only. The new HTML 5.0 and XHTML 2.0
that is soon to be released is bringing the two types even closer
together based on preliminary information. It is also somewhat like
the difference between strict and transitional and both will render
the page the same with only minute differences in the way the page is
coded.
So in summary pick the language you feel the most comfortable with and
use it. They are both valid and fully functional, and all modern
browsers will render the code just fine. It is just my humble opinion
but I prefer XHTML, but I always preferred a Chevy and a Budweiser
too.
Unfortunately no IE browser, including IE7, can render any xhtml if it
is served properly as mime type application/xhtml+xml. All you get is
an error message. Many mis-serve xhtml as text/html and use an
extension .html. Although this often works for IE browsers, there is
no point in writing xhtml code in the first place if you are not going
to serve it as xhtml.

Just what is the advantage of serving xhtml+xml? The only thing I see is
something about being able to write objects differently. Or is this
about being able to add xml with an xslt stylesheet? If so, I do not see
that anywhere. The only "trick" I see is the object media thing: <p
src="some_image">something else</a>.

Actually from a quick look through the w3C and some other googling all
I see is syntax examples. And the syntax is not complicated! Perhaps a
working xhtml example that does something new.

Otherwise it seems like nothing but trouble. With much of the web
being driven by CMS if the parser doesn't grok the crap the author puts
in you wind up with a page more broken than it should be.

I don't have a problem with writing HTML XHTMLish, I even like the much
maligned <br />.

Jeff

Since the extension .html usually is associated
with the mime type for text/html on the server, you have to use
another extension, such as .xhtml, and assign it to the xhtml mime
type application/xhtml+xml on the server. Then when you serve xhtml
properly, in addition to IE browsers not working, other modern
browsers such as Firefox, Opera, Seamonkey, and Safari for Windows
will handle true xhtml. However then the code is parsed as xml. A xml
parser must be much more strict than a html parser. The least little
mistake, such as a single unclosed tag, gives a fatal parse error that
results in an error message rather than a view of the page, which
often works with little problem in html.
If you want to serve true xhtml, you have to provide IE html by using
separate pages, header/browser exchange and rewriting the page for
html for browsers that do not indicate they can handle the mime type
for xhtml, etc. The main reason for all of this trouble is that
Microsoft can not or will not write their browsers to handle modern
xhtml properly. Hopefully, now that Vista is out after much delay,
Microsoft will have time to bring their browser up to date. IE7 was
just a minor change from IE6. It did correct some bugs and might be a
bit more secure. However it was outmoded at the moment it was
released.
The important thing to remember is that you have xhtml only if both
the code is written in xhtml and it is served as application/xhtml+xml
- not text/html. The W3C validator only validates the code as html or
xhtml. It does not validate that the code is being served properly.
However, in the most detailed setting of the validator, it will tell
you if the page is being served as text/html or application/xhtml+xml.
You will find very few pages being served properly as xhtml when you
check them.

Jeff,

See what I was talking about it is the same old arguments with no
basis in reality (see previous post). A large percent of
knowledgeable web designers use XHTML and serve it as HTML with no
problems. I find that most of the people who object to XHTML don't
want to spend the time learning a new process for coding pages. XHTML
uses modern practices like external style sheets and box design for
layouts instead of tables and inline formatting. There is absolutely
no doubt that XHTML provides a much cleaner and uncluttered page.
However, to each their own.

Daniel

http://a-ok-site.com
 
A

A-OK-SITE

Why? It's a self closing tag and it works in every browser. The trend
is toward closing every tag you open.

Jeff

It's not wrong they just don't like it, and you are right that is the
trend.

Daniel
 
A

Andy Dingley

Why? It's a self closing tag and it works in every browser.

Under HTML (i.e. SGML) <br> is defined as EMPTY in the DTD, so it's
always a "self-closing" element from a single start tag, no matter
what.

The trend is toward closing every tag you open.

You mean "element", not tag. Secondly, although this observation might
be correct, it's not necessary behaviour outside of SGML. For elements
with content (e.g. <p>) then it's commendable, albeit largely
unnecessary (it can make things clearer to the humans though). However
for <br> it's simply wrong. It's not _harmful_ (this is what permits
Appendix C to work), but it's not something to recommend.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top