W3C home > Mailing lists > Public > www-validator@w3.org > September 2011

Re: Validator error messages

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Wed, 21 Sep 2011 10:39:49 +0300
Message-ID: <4E7994C5.4020802@cs.tut.fi>
To: msanderz <msanderz@att.net>, www-validator@w3.org
21.9.2011 8:40, msanderz wrote:

> To All

As this seems to have been meant for the list, though it was sent to me 
only, I'm exceptionally fullquoting it in my reply.

> Thank you for your assistance. Since I am new to using the Validator I may
> have not given enough information.

You still haven't given enough information - such as URLs of pages. And 
you have given conflicting information, as the first error message that 
you reported has clearly been issued by the validator when in HTML mode, 
and now you're saying that you use XHTML.

 > Here is my header:

It's not a header. It's the start of a document.

> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
> <title>msanderz.com home page</title>

This suggests that your URL is http://www.sanderz.com - but it must be a 
different page as it gives 35 Errors, 6 warning(s) - including errors 
that occur before issues of the type under discussion here. (Normally, 
errors should be fixed in the order they appear, as an error may well 
have impact later in the document, causing spurious errors etc.)

> Unfortunately Jukka's method did not work

It works for the exact code snippet you posted when wrapped in a minimal 
HTML 4.01 document:

> and generated more errors messages

I don't think it did. You probably did something else, like changed an 
HTML document into an XHTML document, that cause new errors.

> including:
> NET-enabling start-tag not immediately followed by null end-tag and
> document type does not allow element "p" here; missing one of "object",
> "ins", "del", "map", "button" start-tag

Those are apparently causes by using XHTML, in which even start tags 
(not just end tags) a recognized within <script> elements. It cannot 
possibly relate to the modification I suggested (it removes an end tag 
and does not add any tags, with "tag" meaning a character sequence 
recognized as a tag).

> Etienne, my javascript is in a separate file, I merely moved the code
> snipped into an html file to test it with the validator.

What might be the point? Did you expect the validator to check your 
JavaScript code. It does nothing of the kind. JavaScript is just noise 
to it - character data, in which only some tags are recognized. When 
JavaScript is a separate file, there is no such problem as recognizing 
tags, and there is no reason to create such problems by embedding 
JavaScript into HTML if it's now separate.

There are completely different tools (not hosted by the W3C) for 
checking JavaScript code. Opinions on them vary greatly, but try 
googling for "jshint" or "jslint".

> And as you can see
> my header is for XHTML because if I am going to learn something I do not
> want to learn the soon to be depricated method.

As you have seen, XHTML has traps, pitfalls, and oddities of its own, 
and nobody really knows the future. Everyone's talking about HTML5 these 
days, and it makes the difference between HTML and XHTML almost a 
triviality (just a matter of "serialization"). There's really no hurry 
to learn XHTML.

 > Thus I face the errors.
> Pending further enlightenment my solution, which displayed correctly but
> gave warnings and error messages was to replace "<" and">" with variable
> strings thus:
> var lt = '<'; var gt ='>';
> var linkNew = new splash("splash_new", "images/splash_new.gif",
> "openPage('whatsnew.html')",
> lt+"p"+gt+"What is new?"+gt+lt+"p /"+gt, "whatsnew.html" );

That's close to one way of avoiding the problem, both in HTML and in 
XHTML, based on the same idea as my suggestion but going farther. You 
are splitting constructs to avoid having them as tags in (X)HTML source.

> As I said there were error messages and warnings but all associated with the
> variable declarations and not the object elements:
> WARNING: character "<" is the first character of a delimiter but occurred as
> data
> ERROR: StartTag: invalid element name

You didnšt go far enough. If you really wanted to use the "tag 
splitting" technique in a manner that works even with XHTML, you must 
not use the character "<" at all inside a <script> element.

 From the viewpoint of HTML parsing, and hence the validator, the 
<script> element content is just character data - no statements, 
variables, operators, or other scripting language constructs are 
recognized there (in browsers, they are to be interpreted by the 
JavaScript interpreter part of the browser, _after_ the browser's HTML 
parser has parsed it and thrown it at the interpreter).

What matters is the appearance of "<". To get rid of it in JavaScript, 
when it appears inside a string literal as here, just use JavaScript 
character escape, changing '<' to '\x3c' (3c is the hex code of "<").

But there is no need for any of this if you have the JavaScript code in 
a separate file or can conveniently put it there.

> Since I am still learning the alphabet (pun, I mean HTML, XHTML, JavaScript,
> CSS etc.) I may be in over my head but at least the warnings and error
> messages do not cause silent closing of elements and are clearly associated
> with simple declarations of characters as variables. And since I have used
> this method of document.write extensively (much more than the included
> snippet) I can now limit my errors to these variable declarations, rather
> than most of my multiple document.write statements.
> Again Thank you all for your help, sorry if I stirred up a hornets nest.

The document.write() method is messy and often unreliable, _especially_ 
when used with XHTML:

"   This method has very idiosyncratic behavior. In some cases, this 
method can affect the state of the HTML parser while the parser is 
running, resulting in a DOM that does not correspond to the source of 
the document. In other cases, the call can clear the current page first, 
as if document.open() had been called. In yet more cases, the method is 
simply ignored, or throws an exception. To make matters worse, the exact 
behavior of this method can in some cases be dependent on network 
latency, which can lead to failures that are very hard to debug. For all 
these reasons, use of this method is strongly discouraged.
     This method throws an INVALID_STATE_ERR exception when invoked on 
XML documents."

(work in progress)

Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Wednesday, 21 September 2011 07:40:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:18:04 UTC