W3C home > Mailing lists > Public > www-validator@w3.org > August 2006

RE: Error Message Feedback

From: Neil Smith <Neil_Smith@hargreaveslansdown.co.uk>
Date: Tue, 8 Aug 2006 09:47:02 +0100
Message-ID: <F8003EC770ECF341A39411089ED06E3455F0FD@hlemail01.hargreaveslansdown.co.uk>
To: <www-validator@w3.org>
Cc: <dave@williamz.net>

> 1. At one place, I am using JavaScript to place some HTML in 
> the document. 
> However, the validator ignores the fact that the quotes need 
> to be escaped 
> or that I am not placing HTML inside a script tag as such, 
> but rather into a 
> variable...

This was discussed last week - technically it's incorrect to have the
closing angle bracket inside your javascript string. You could
reasonably use the decimal character entity &#60; instead. Many people
now enclose script blocks in CDATA sections, i.e.

<script language="javascript" type="text/javascript">
function foo() {


> 2. The code I have written has &amp; in all links and this is 
> what displays 
> in view page source.  However, the validator somehow picks up 
> an additional 
> hidden pass through with a PHP session id.  As this is not 

PHP will auto append session IDs to URLs (also form actions and other
elements) if no cookie is sent by the user agent, I expect the validator
doesn't accept or return session cookies sent in the HTTP header. 

You may wish turn off session.use_trans_sid in your php.ini or in an
.htaccess file or your core page generation script if this is important
to you. 

A better solution is to tell PHP to use XHTML compatible argmuent
separators (it's actually a bug in PHP's default setting on some
versions). To do that, arg_separator.output  needs to be set to &amp;
not the default & character.

http://uk.php.net/session contains details of the config available to
control PHP's transparent session handling, in particular
url_rewriter.tags will be of interest to you.

See this doc for a discussion of this behaviour :

> visible under 
> view source and the code writer has no control over how php 
> places its 
> session variables in links, is it right for a document to 
> fail validation on 
> these grounds?

If what the validator sees is invalid, then yes, of course. 

You're not sending it what "normal" user agents would see, so the
problem really is yours not the validator. It can't be expected to
determine "OK this is PHP and has appended session IDs to the HTML
links, so I'll ignore that". It's required to be *strict* or it wouldn't
be of use to anybody ;-)

Cheers - Neil

For more information on Hargreaves Lansdown, visit our web site http://www.hargreaveslansdown.co.uk
This email is intended solely for the recipient and is confidential and not for third party unauthorised distribution. If an addressing, or transmission, error has misdirected this email, please notify the author by replying to this email or notifying the system manager (internal.security@hargreaveslansdown.co.uk) if you are not the intended recipient you must not disclose, distribute, copy, print or rely on this email. 
Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of Hargreaves Lansdown. In addition, staff are not authorised to enter into any contract through email and therefore nothing contained herein should be construed as such. This email has been prepared using information believed by the author to be reliable and accurate but Hargreaves Lansdown makes no warranty as to the accuracy or completeness. In particular, Hargreaves Lansdown does not accept responsibility for any changes made to this email after it was sent. 
Hargreaves Lansdown Asset Management, Hargreaves Lansdown Fund Managers, Hargreaves Lansdown Pensions Direct and Hargreaves Lansdown Stockbrokers are authorised and regulated by the Financial Services Authority and registered in England and the registered office is Kendal House, 4 Brighton Mews, Clifton, Bristol, BS8 2NX. Telephone: 0117 9889880

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
Received on Tuesday, 8 August 2006 08:53:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:49 UTC