Using id or name?

[John Salerno]

If you're writing strict HTML 4.01, should you still use both the id and
name attribute, or is name good enough? I know name is deprecated in
XHTML, but is it still used in HTML, or did id replace it there as well?

 

[Jukka K. Korpela]

If you're writing strict HTML 4.01, should you still use both the
id and name attribute, or is name good enough?

The id and name attributes each have their own jobs, and the job varies
especially as regards to the name attribute.

You use id to assign a unique (within a document) identifier to an
element. You use name to assign a name to a form field for the
purposes of form submission (id won't do that), and maybe for some
other purposes as well, for some elements.

I know name is deprecated in XHTML,

It isn't. For form fields in particular, it is a necessity. It is
deprecated in _some_ contexts, see
http://www.w3.org/TR/html/#h-4.10
(The heading there is misleading and part of the confusion:
"The elements with 'id' and 'name' attributes". Surely an <input>
element may have such attributes, and the name attribute is _not_
deprecated there, and the use of id does _not_ replace name there.)

In setting up a link destination, it is rather safe nowadays to use
just the id attribute, in a suitable element. Browsers that only
recognize <a name="..."> destinations have become rare.

 

[John Salerno]

The id and name attributes each have their own jobs, and the job varies
especially as regards to the name attribute.

You use id to assign a unique (within a document) identifier to an
element. You use name to assign a name to a form field for the
purposes of form submission (id won't do that), and maybe for some
other purposes as well, for some elements.


It isn't. For form fields in particular, it is a necessity. It is
deprecated in _some_ contexts, see
http://www.w3.org/TR/html/#h-4.10
(The heading there is misleading and part of the confusion:
"The elements with 'id' and 'name' attributes". Surely an <input>
element may have such attributes, and the name attribute is _not_
deprecated there, and the use of id does _not_ replace name there.)

In setting up a link destination, it is rather safe nowadays to use
just the id attribute, in a suitable element. Browsers that only
recognize <a name="..."> destinations have become rare.

Ok, so in the case of creating an image map, using just id is okay?

 

[Troy Piggins]

The id and name attributes each have their own jobs, and the job varies
especially as regards to the name attribute.

You use id to assign a unique (within a document) identifier to an
element. You use name to assign a name to a form field for the
purposes of form submission (id won't do that), and maybe for some
other purposes as well, for some elements.


It isn't. For form fields in particular, it is a necessity. It is
deprecated in _some_ contexts, see
http://www.w3.org/TR/html/#h-4.10
(The heading there is misleading and part of the confusion:
"The elements with 'id' and 'name' attributes". Surely an <input>
element may have such attributes, and the name attribute is _not_
deprecated there, and the use of id does _not_ replace name there.)

In setting up a link destination, it is rather safe nowadays to use
just the id attribute, in a suitable element. Browsers that only
recognize <a name="..."> destinations have become rare.

I'm having a problem because of this - I have a form that is not working
correctly when I try to conform with strict xhtml by using "id" instead
of "name", but works fine but doesn't conform (according to the
w3c validator) if I use "name".

What's the solution to that? Adopt "Transitional" instead of "strict"?

 

[Jukka K. Korpela]

Ok, so in the case of creating an image map, using just id is okay?

Oh, that belongs to the tricky part. Using just name is okay.

I must admit that I don't know the details of the current browser
situation in support to using just id in <map>. But support to name is
surely at least as good, so you win nothing by using id. The situation
is different in normal linking, since you _can_ win in conciseness:
compare <h2 id="foo">...</h2> with <h2><a name="foo">...</a></h2>.

(XHTML 1.1 is particularly absurd here, disallowing name, making id
required, and requiring <map> elements to identifiers without "#",
thereby making the page fail on existing browsers.)

 

[Jukka K. Korpela]

I'm having a problem because of this

It's hard to see what "this" is here. You quoted my entire message, but
your question does not seem to relate to anything in it.

- I have a form that is not
working correctly when I try to conform with strict xhtml by using
"id" instead of "name", but works fine but doesn't conform
(according to the w3c validator) if I use "name".

You didn't post the URL, and you didn't say _where_ you use "name" and
why. The odds are that you are using scripting and use "name" in <form>
element in order to be able to refer to a form in JavaScript. The
modern way is document.getElementById("foo"), for <form ... id="foo">.
Besides, for a page containing a single form, the very old way
document.forms[0] works in practice, and doesn't need "name".

 

[John Salerno]

compare <h2 id="foo">...</h2>

You can do that? The book I just read did it this way:

<h2><a id="foo">...</a></h2>

That's similar to your second example with 'name', but they still use id
with the <a> tag. Is it safe to leave out the <a> altogether?

 

[Barbara de Zoete]

You can do that?

Yes, you can do that. How else would you use the id attribute with an
element?

The book I just read did it this way:

<h2><a id="foo">...</a></h2>

Throw away that book. Use
<URL:http://www.w3.org/TR/html401/index/elements.html>
<URL:http://www.w3.org/TR/html401/index/attributes.html>
for quick reference to the correct use of elements and attributes with
HTML4.01 (preferrably Strict).

 

[Troy Piggins]

It's hard to see what "this" is here. You quoted my entire message, but
your question does not seem to relate to anything in it.

Sorry - "this" being the issue of name vs id in forms with xhtml. The
subject of the OP.

You didn't post the URL,

I don't have it uploaded yet for public viewing. I was trying to keep
it a general question.

and you didn't say _where_ you use "name" and why. The odds are that
you are using scripting and use "name" in <form> element in order to
be able to refer to a form in JavaScript.

Correct - well guessed )
Trying to set focus on an input field. Since my post I found this :

http://www.w3schools.com/js/tryit.asp?filename=tryjs_focus

which complies with Strict xhtml validation, does set the focus
correctly, but does not pass the entered text with the action command in
this implementation:

<form action="http://www.google.com.au/search" method="get">
<table>
<tr>
<td>
<input type="text" id="q" size="25" maxlength="255" value="" />
<input type="submit" id="btnG" value="Google Search" />
</td>
</tr>
</table>
</form>

To get it to work I had to change these lines:

<input type="text" id="q" name="q" size="25" maxlength="255" value="" />

The modern way is document.getElementById("foo"), for <form ...
id="foo">. Besides, for a page containing a single form, the very old
way document.forms[0] works in practice, and doesn't need "name".

Yes, that is what they did in the above example.

Thanks.

 

[Andy Dingley]

There has never been any point in using <a> as a parent tag for an id
attribute used as a fragment identifier.

Although there were browsers back in the Dark Ages that demanded <a
name="..." > rather than <h2 id="..." >, I'm unaware of any that
supported fragments by id, yet required the <a> tag too.

 

[Jukka K. Korpela]

Trying to set focus on an input field.

Just stop trying that. Problem solved.

Even if you did it in the technically correct way, it would disturb
people. For example, people would start typing in the field _before_
your code sets the focus. Guess what happens then?

(Right. The cursor is inserted at the start of the field.)

 

[Troy Piggins]

Just stop trying that. Problem solved.

s/solved/avoided ;-)

Even if you did it in the technically correct way, it would disturb
people. For example, people would start typing in the field _before_
your code sets the focus. Guess what happens then?

(Right. The cursor is inserted at the start of the field.)

Imagine how inconvenient it would be if Google didn't set the focus to
the search input field.