Name attribute not XHTML valid

[piraticman]

Hi. I have some code for a javascript jump menu... It validated with
HTML 4.0 but now does not validate with XHTML strict 1.0.

I have used name atributes in my code which aparantly are not allowed
now. I have spent all day trying to figure out a solution with no
luck. I have tried document.forms[0] and various other things but
havent known exactly what to do with them and couldn't get them to
work. Below I will show you my current code and what the w3c.org
validator comes up with. If someone could change this code for me to
be XHTML valid I would be very grateful.

-------------------------
My HTML

<form name="jump" action ="">
<script type="text/javascript">
function jumpMenu(){
location=document.jump.menu.options[document.jump.menu.selectedIndex].value;
}
</script>
<select name="menu"
style="font-family:'Verdana';color:#000000;background-color:#99CCFF;font-size:10pt;">
<option value="index.html">HOME</option>
<option value="about.html">About Us</option>
<option value="#">-----------------</option>
<option value="showroom.html">Show Room</option>
<option value="dining.html">-Dining</option>
<option value="prints.html">-Prints</option>
<option value="mirrors.html">-Mirrors</option>
<option value="accessories.html">-Accessories</option>
<option value="lighting.html">-Lighting</option>
<option value="#">-----------------</option>
<option value="glazing.html">Glazing &amp; Boarding</option>
<option value="laminated.html">Laminated Glass</option>
<option value="processing.html">Processing</option>
<option value="design.html">Design</option>
<option value="stained.html">Stained &amp; Leaded</option>
<option value="#">-----------------</option>
<option value="contact.html">Contact Us</option>
</select>
<a href="javascript:jumpMenu();"><img src="go.jpg" alt="Go!"
/></a>
</form>

------------------

w3c validator results
Line 51, column 13: there is no attribute "name"

<form name="jump" action ="">

You have used the attribute named above in your document, but the
document type you are using does not support that attribute for this
element. This error is often caused by incorrect use of the "Strict"
document type with a document that uses frames (e.g. you must use the
"Transitional" document type to get the "target" attribute), or by
using vendor proprietary extensions such as "marginheight" (this is
usually fixed by using CSS to achieve the desired effect instead).

This error may also result if the element itself is not supported in
the document type you are using, as an undefined element will have no
supported attributes; in this case, see the element-undefined error
message for further information.

How to fix: check the spelling and case of the element and attribute,
(Remember XHTML is all lower-case) and/or check that they are both
allowed in the chosen document type, and/or use CSS instead of this
attribute.

Line 57, column 108: document type does not allow element "select"
here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div",
"pre", "address", "fieldset", "ins", "del" start-tag

....ground-color:#99CCFF;font-size:10pt;">

The mentioned element is not allowed to appear in the context in which
you've placed it; the other mentioned elements are the only ones that
are both allowed there and can contain the element mentioned. This
might mean that you need a containing element, or possibly that you've
forgotten to close a previous element.

One possible cause for this message is that you have attempted to put
a block-level element (such as "<p>" or "<table>") inside an inline
element (such as "<a>", "<span>", or "<font>").
Line 76, column 36: document type does not allow element "a" here;
missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre",
"address", "fieldset", "ins", "del" start-tag

<a href="javascript:jumpMenu();"><img src="go.jpg" alt="Go!" /></a>

---------------------------------------------

Thanks in advance

Daniel Callus

[David Dorward]

pi********@gmail.com wrote:

Hi. I have some code for a javascript jump menu...
Leaving aside the problems with the concept of a jump menu; most scripts
aren't very good.
It validated with HTML 4.0
That was obsoleted in, IIRC, 1996 with the 4.01 bug fix release.
I have used name atributes in my code which aparantly are not allowed
now.

Name is for form controls and specifies stuff for server side handling. You
should be looking at the id attribute for client side stuff.

I suggest you go and read http://www.cs.tut.fi/~jkorpela/forms/navmenu.html
which has working code for you.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Andy Dingley]

On 7 Apr 2005 13:48:35 -0700, pi********@gmail.com wrote:

Hi. I have some code for a javascript jump menu... It validated with
HTML 4.0 but now does not validate with XHTML strict 1.0.

So use the fecking Transitional DTD, that's what it's there for.

Or go and read the enormous great note the W3C provide on precisely
this issue.
http://www.w3.org/TR/xhtml1/diffs.html#h-4.10
People who don't know the TR "well" (if not inside-out) have no
business trying to author to the Strict DTD.

[Jukka K. Korpela]

David Dorward <do*****@yahoo.com> wrote:

pi********@gmail.com wrote:

Hi. I have some code for a javascript jump menu...
Leaving aside the problems with the concept of a jump menu; most
scripts aren't very good.

The snippet that was posted illustrates many of the fundamental flaws
in the idea of using a pulldown menu instead of a link list in HTML,
the snippet even exhibits flaws that I didn't think of, such as
<option value="#">-----------------</option>
which is really awful to listen to, if you can use the "menu" on a
speech-based user agent at all.

It validated with HTML 4.0

That was obsoleted in, IIRC, 1996 with the 4.01 bug fix release.

No, it was the other way round: HTML 4.01 added the NAME attribute,
which wasn't present in HTML 4.0, and then XHTML took it away again.
The OP probably meant that the page validated under HTML 4.01.
Name is for form controls and specifies stuff for server side
handling. You should be looking at the id attribute for client side
stuff.

There are different ways of referring to a FORM element in client-side
code, including document.forms[0] (assuming it's the only form on a
page), which is legacy JavaScript, and document.getElementById(...),
which is modern code (and does not work on ancient browsers).
People use the NAME attribute in FORM mostly out of habit they learned
from somewhere, and that's fairly harmless if you have a page with lots
of old style code anyway - but it's pointless to try to convert such a
page into XHTML, except perhaps in a complete redesign (and even
complete redesign is better done in HTML 4.01 Strict, which can be
later converted to XHTML mechanically if needed).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[piraticman]

Stop being so god damn rude Andy. I can do as I please and I choose to
rewrite my page in XHTML strict 1.0. Because I want to learn how to do
this so I can do it again in the future. You can't just NOT do
something cos you don't know exactly how to do it. Why do you think I
am asking for help?

My page was originally all tables for layout. I have just completely
rewritten my page using valid CSS for layout, no HTML at all is used
for layout. I also am trying to get my page to be strict xhtml 1.0 and
after that I am going to try and follow all of the w3AI-AAA guidlines.

Jukka, thanks for the tip about not using -------, I had never thought
of that, I will change it to a blank space instead. My page is
intended to be text-reader friendly. I will also include alternative
noscripts for all javascript elements such as drop down menu. A site
map can be used as an alternative. Also the drop down menu is NOT the
main navigational tool on the site. There are several different ways
to access each page. Links at the left AND bottom. I also have a menu
at the top right to have a compact list of all links in the site,
which I believe is the best way to use a menu.

Also, thankyou for the suggestion document.forms[0], but as I have
said I couldn't get this to work properly. If I could get a hint of
exactly how to use it in MY code, I would be greatful.

and finally, David, thankyou for the link but unfortunately these jump
menus are NOT XHTML valid...

Thanks

Daniel

[piraticman]

Ok. So I got rid of the bottom two errors about the "select menu" by
adding a <div> </div> at the start and end of the menu.

But I still haven't fixed the 'name' problem.

I know it has to be changed to ID and then adding the
document.forms[0], but I don't know exactly how to implement this.

Thanks

Daniel

[Michael Winter]

On 08/04/2005 07:05, Jukka K. Korpela wrote:

[snip]

There are different ways of referring to a FORM element in client-side
code, including document.forms[0] (assuming it's the only form on a
page), which is legacy JavaScript,
I wouldn't exactly say the forms collection is a legacy property. In
fact, the DOM HTML module has brought it quite up-to-date with regard
to accessing FORM elements by id.

Personally, I find

var form = document.forms['aFormID'];

far more appealing than

var form = document.getElementById('aFormID');

Certainly, if real legacy code was required (to support NN4, for
example) one would simply need to add a name attribute to the FORM
with the same value and the first statement would work without issue.

By the way, I think that perhaps a better combined example than that
shown in <URL:http://www.cs.tut.fi/~jkorpela/forms/navmenu.html> would be:

function jump(form) {
var url = form.elements['url'],
sI = url.selectedIndex;

if(0 < sI) {location.href = url.options[sI].value;}
return false;
}

<form action="http://www.cgiforme.com/jumporama/cgi/jumporama.cgi"
method="post" onsubmit="return jump(this);">
<div><select name="url">
<option value="http://www.cs.tut.fi/~jkorpela/forms/jsnav.html"
selected>Please select an item:</option>
<option value="http://www.cs.tut.fi/~jkorpela/forms/"Main page on HTML forms</option> <option value="http://www.cs.tut.fi/~jkorpela/forms/choices.html"Choices in HTML forms</option> <option value="http://www.cs.tut.fi/~jkorpela/forms/tables.html"Tables and forms</option> <option value="http://www.cs.tut.fi/~jkorpela/forms/methods.html"Form submission methods (GET and POST)</option>

</select>
<input type="submit" value="Go!"></div>
</form>

This avoids any need for form identification, and gets rid of the
auto-selection. If the latter was really desired, the onchange
attribute could still use the jump function, with a small modification:

function jump(url) {
var sI = url.selectedIndex;

if(0 < sI) {location.href = url.options[sI].value;}
}

<select name="url" onchange="jump(this);">

Of course, I do agree that normal links are better.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Andy Dingley]

On 8 Apr 2005 04:02:06 -0700, pi********@gmail.com wrote:

I can do as I please

You're posting from Google, where search on this topic is only a click
away. Also you clearly haven't read the XHTML spec on precisely this
issue.

I don;t know what you're trying to achieve here. If it's "take an
existing page and make it validate", then Strict is the wrong way to
go. If learning Strict is you (laudable) goal, then it's incumbent
upon you to read the spec and the history before posting.

There are no stupid questions. But there are old and tired ones.

[Del Ferguson]

Andy Dingley wrote:

On 8 Apr 2005 04:02:06 -0700, pi********@gmail.com wrote:

I can do as I please

I don;t know what you're trying to achieve here. If it's "take an
existing page and make it validate", then Strict is the wrong way to
go. If learning Strict is you (laudable) goal, then it's incumbent
upon you to read the spec and the history before posting.

Why is XHTML Strict the wrong way to go? With tools such as Tidy, it is
just a matter of cleaning up the errors. Wouldn't it be nice if all
coders strived for 0 errors and 0 warnings?

[Andy Dingley]

On Fri, 08 Apr 2005 15:17:54 -0700, Del Ferguson
<de*********@charter.net> wrote:

Why is XHTML Strict the wrong way to go? Wouldn't it be nice if all
coders strived for 0 errors and 0 warnings?
The fallacy here is to equate the Strict DTD with zero errors.

"Zero errors" is a good aspirational goal. It's not _very_ good - so
much of the web is tag soup that being better than this still gives no
real benefit. But it's a morally beneficial target to aim for.

Strict is not. A site coded according to Strict is in no possible way
"better" than one coded according to Transitional. In fact, it may
actually be better to use the Transitional DTD -- there are many
possible sites that are valid Trasitional (validity is good) whilst
not being valid Strict. In those cases, stick with Transitional.

The benefit is in being _valid_, not in the choice of aspirational
target.

There are also arguments in favour of writing semantically-relevant
well-structured code. But Strict adds little to aid this - you can
still nest <blockquote> to create an indent, or to chain <a> links
rather than coding an obvious list or menu structure.

if Strict has any advantages, they're to the aid of DTD and UA
authors, not to content authors.
With tools such as Tidy, it is
just a matter of cleaning up the errors.

"Clearing up errors from Tidy" is not in itself sufficient to remove
all the inconsistencies from a switch to Strict. I refer you to the OP
in this thread.

--
Smert' spamionam

[Jan Roland Eriksson]

On Fri, 08 Apr 2005 15:17:54 -0700, Del Ferguson
<de*********@charter.net> wrote:
[...]

Why is XHTML Strict the wrong way to go?

Because all variants of XHTML 1.0 are designed to ride on lots of old
browser bugs to get rendered, bugs that was already there long before
XHTML came along.

--
Rex

[Del Ferguson]

Andy Dingley wrote:

A site coded according to Strict is in no possible way
"better" than one coded according to Transitional. In fact, it may
actually be better to use the Transitional DTD -- there are many
possible sites that are valid Trasitional (validity is good) whilst
not being valid Strict. The benefit is in being _valid_, not in the choice of aspirational
target.
I agree that validity is as you stated, but my concern is that some
coders use Transitional as a means to "bang" out a page and get it over
with.
There are also arguments in favour of writing semantically-relevant
well-structured code. But Strict adds little to aid this - you can
still nest <blockquote> to create an indent, or to chain <a> links
rather than coding an obvious list or menu structure.
I guess I'm not the "purist" that I should be. I'm pragmatic about what
works in a page. If my pages (all Strict XHTML) pass the several
validity checks I do and look OK with FF and IE, that should be enough.
"Clearing up errors from Tidy" is not in itself sufficient to remove
all the inconsistencies from a switch to Strict.

I didn't mean to give the idea that a coder would only use Tidy;
although, using the "correct" DOC TYPE goes a long way towards that end.

[Del Ferguson]

Jan Roland Eriksson wrote:

On Fri, 08 Apr 2005 15:17:54 -0700, Del Ferguson
<de*********@charter.net> wrote:

Why is XHTML Strict the wrong way to go?

Because all variants of XHTML 1.0 are designed to ride on lots of old
browser bugs to get rendered, bugs that was already there long before
XHTML came along.

I agree and HTML might be an easier way to go; however, that is why I
use a VisiBone chart to find code most compatible with the greater
percentage of browers out there.

[Andy Dingley]

On Fri, 08 Apr 2005 19:44:45 -0700, Del Ferguson
<de*********@charter.net> wrote:

some coders use Transitional as a means to "bang" out a page
and get it over with.
What's wrong with that?

If you "bang it out", and as a result it validates, then you've hit
the target

A valid Transitional page is still valid. It's no less valid, and no
less "right" than a valid Strict page..

I'm pragmatic about what
works in a page. If my pages (all Strict XHTML) pass the several
validity checks I do and look OK with FF and IE, that should be enough.

These tests meet certain goals, but they fail others.

Take a look at csszengarden - you can only do that sort of
dynamically-switched CSS if the page structure beneath is sound. The
structure must not only be amenable to having one specific CSS applied
to it to give one specific look, but it should permit generalised CSS
to be applied, hooking in through a sensible class structure.

There are as yet few benefits to doing this. But there are identified
reasons, mainly in machine-processing of the page, where sensible
semantic structure of the HTML becomes important.

As yet the minimal benefits are in considering a linear CSS-stripped
version of the site, such as encountered by screen readers. 2d tables
etc. should linearise in the sensible order, not the "cross reading"
order. We recently had a page posted with a directory of shops at
Pigeon Forge. The HTML for that linearised as {name, name, name} {
phone, phone, phone} when clearly it would have been improved as
{name, phone}{name,phone}{name,phone}

[Del Ferguson]

Andy Dingley wrote:

On Fri, 08 Apr 2005 19:44:45 -0700, Del Ferguson
<de*********@charter.net> wrote:

some coders use Transitional as a means to "bang" out a page
and get it over with. What's wrong with that? If you "bang it out", and as a result it validates, then you've hit
the target A valid Transitional page is still valid. It's no less valid, and no
less "right" than a valid Strict page..
Other than the fact that Transitional doesn't completely meet the
Standards Mode, you are right.
I'm pragmatic about what
works in a page. If my pages (all Strict XHTML) pass the several
validity checks I do and look OK with FF and IE, that should be enough.

These tests meet certain goals, but they fail others.
That is the reason I do multiple tests such as those listed in Firefox's
Checky. I rely on multiple tests to keep me within the Standards Mode.
Take a look at csszengarden - you can only do that sort of
dynamically-switched CSS if the page structure beneath is sound.
If I could even come close to being on the level of a css Zen Garden
coder, I'd consider myself a real coder, not a hobbyist.
As yet the minimal benefits are in considering a linear CSS-stripped
version of the site, such as encountered by screen readers. 2d tables
etc. should linearise in the sensible order, not the "cross reading"
order.

I agree. We should all look at our pages stripped of style to see if
they make sense.

[Mellow Crow]

pi********@gmail.com wrote:

But I still haven't fixed the 'name' problem.

I know it has to be changed to ID and then adding the
document.forms[0], but I don't know exactly how to implement this.

<head>
<script type="text/javascript">
<!--
window.onload = function () {
// The form has an id but no name attribute
// under XHTML 1.1
// So we provide a handy global reference.
// Use Pascal case to:
// 1. Designate it is a Global Variable; and
// 2. So it doesn't conflict with the IE 6 global form variable eg
"frmMain".
FrmMain = document.forms["frmMain"];
//-->
</script>
</head>
<body>
<form id="frmMain" onsubmit="return false;" action="" method="post">
....

[Martin Honnen]

Mellow Crow wrote:

<head>
<script type="text/javascript">
<!--
window.onload = function () {
// The form has an id but no name attribute
// under XHTML 1.1

Is this supposed to be script in XHTML? Then get rid of the <!-- //-->
wrapping the script as that way the script is commented out
(<http://www.w3.org/TR/xhtml1/#C_4>).
You might need other wrappers like
//<![CDATA[
script code
//]]>
then.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Mellow Crow]

Mellow Crow wrote:

<head>
<script type="text/javascript">
<!--
window.onload = function () {
// The form has an id but no name attribute
// under XHTML 1.1

Martin Honnen wrote: Is this supposed to be script in XHTML? Then get rid of the <!-- //-->
wrapping the script as that way the script is commented out
(<http://www.w3.org/TR/xhtml1/#C_4>).
You might need other wrappers like
//<![CDATA[
script code
//]]>
then.

Thanks Martin. An issue worthy of it's own thread. Researching this now. I
might post this as
"Which comment wrappers for JavaScript in XHTML?" in comp.lang.javascript
when I get the time (in 5 days??).