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

Re: [VE][108] Add Subject Here

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Wed, 20 Apr 2011 16:49:16 +0300
Message-ID: <E3599607BC174520ACF555644E19F1A7@JukanPC>
To: "Osama Othman" <osama.uthman@cubic-art.com>, <www-validator@w3.org>
Osama Othman wrote:

> Validating http://75.125.45.250/pages/SearchResults.aspx?Text=a
> <http://75.125.45.250/pages/SearchResults.aspx?Text=a&key=all%7C10%7Ca%7Csam
> e%7Casc> &key=all%7C10%7Ca%7Csame%7Casc
> Error [108]: "there is no attribute X"

The page declares the XHTML 1.0 Transitional document type. This explains 
the error messages about "&" characters inside script elements, since by 
XHTML rules, "&" as data character must be escaped (e.g. as &amp;). The 
safest way is to put the scripts in an external file.

The error message 'there is no attribute "disabled"' is caused by the 
presence of the attribute in an <a> tag, where XHTML 1.0 does not allow it. 
You might consider moving to HTML5 (possibly in the XHTML serialization 
XHTML5), though it is a moving target and "validation" for it means 
performing heuristic checks using an experimental feature of the W3C 
Validator.

Alternatively, or additionally, you might consider not using that attribute 
at all in markup. Instead, you can assign a value to the corresponding 
property, or "IDL attribute", of an element, in JavaScript, e.g. with 
assignments like document.getElementById("foobar").disabled = true in code 
that gets executed via an onload="..." attribute in <body>. This avoids the 
validity issue, and, more importantly, it is safer: you make an element 
disabled only when script execution is allowed in a browser, because only in 
that case can you ever turn off the disabled property.

There are two issues with the onPaste attribute. First, in XHTML 1.0, which 
is case-sensitive, all event attribute names must be written in all 
lowercase - _not_ in "camel style". Second, no onpaste attribute is defined 
in XHTML 1.0, or in any other HTML specification, or even the HTML5 drafts. 
Here, too, scripting comes to rescue. Instead of having, say,

<input id="xyz" ... onpaste="return doFoo(...)">

(which works, on browsers that support the onpaste attribute, but does not 
validate)
you can omit the onpaste attribute and include code like

document.getElementById("xyz").onpaste = function () { return doFoo(); };

in the code that gets executed once the page has loaded.

That is, you assign an event handler to an element dynamically, instead of 
an attribute in HTML markup. This implies no limitations, because when 
scripting is disabled, the attribute will be meaningless anyway.

Similar considerations apply to onDrop (except that it belongs to HTML5 
drafts).

For onKeyPress, it should suffice to change the spelling to lowercase.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/ 
Received on Wednesday, 20 April 2011 13:50:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:14:46 GMT