467,915 Members | 1,682 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,915 developers. It's quick & easy.

Has the name attribute deprecated?

Has the name attribute deprecated?

I ask this because ASP.NET 2 warns me against using it, says that it has
been deprecated and doesn't use it (on the client) when creating a radio
button list.

I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?

What's going on here?
Nov 24 '06 #1
  • viewed: 5561
Share:
11 Replies
Jasbird wrote:
Has the name attribute deprecated?
The name attribute has a long and complicated history. It has existed
for various different elements in various different versions of HTML.

HTML 4.01 adds the name attribute to some elements which didn't have it
in HTML 4.0.

XHTML 1.0 deprecates the name attribute for a, applet, form, frame,
iframe, img, and map elements. But not for button, textarea, select,
input, object, param and meta elements.

XHTML 1.1 removes it entirely from a and map elements.
I ask this because ASP.NET 2 warns me against using it, says that it has
been deprecated and doesn't use it (on the client) when creating a radio
button list.
What version of (X)HTML is your code trying to produce?
I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?
Nearly. Same name, different values. IDs are not required for radio
buttons.

Steve

Nov 24 '06 #2
..oO(Steve Pugh)
>Jasbird wrote:
>I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?

Nearly. Same name, different values. IDs are not required for radio
buttons.
You need them if you use label elements.

Micha
Nov 24 '06 #3
Michael Fesser wrote:
.oO(Steve Pugh)
Jasbird wrote:
I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?
Nearly. Same name, different values. IDs are not required for radio
buttons.

You need them if you use label elements.
<label>Is that so? <input name="so" type="radio" value="no" /></label>

You need them if you use explicitly associated label elements (the only
sort that IE6 understands). For implicitly associated labels they are
not needed.

Steve

Nov 24 '06 #4
..oO(Steve Pugh)
>Michael Fesser wrote:
>You need them if you use label elements.

<label>Is that so? <input name="so" type="radio" value="no" /></label>

You need them if you use explicitly associated label elements (the only
sort that IE6 understands).
Correct, I should have mentioned that.
>For implicitly associated labels they are
not needed.
Yep. BTW: Does IE7 support this? I can't test it.

Micha
Nov 24 '06 #5
Michael Fesser wrote:
.oO(Steve Pugh)
For implicitly associated labels [...]

Yep. BTW: Does IE7 support this? I can't test it.
According to a recent thread in alt.html, yes they are.

Steve

Nov 24 '06 #6
On 24 Nov 2006 01:58:55 -0800, "Steve Pugh" <st**********@gmail.com>
wrote:
>Jasbird wrote:
>Has the name attribute deprecated?

The name attribute has a long and complicated history. It has existed
for various different elements in various different versions of HTML.

HTML 4.01 adds the name attribute to some elements which didn't have it
in HTML 4.0.

XHTML 1.0 deprecates the name attribute for a, applet, form, frame,
iframe, img, and map elements. But not for button, textarea, select,
input, object, param and meta elements.

XHTML 1.1 removes it entirely from a and map elements.
>I ask this because ASP.NET 2 warns me against using it, says that it has
been deprecated and doesn't use it (on the client) when creating a radio
button list.

What version of (X)HTML is your code trying to produce?
XHTML 1.0 Transitonal
>I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?

Nearly. Same name, different values. IDs are not required for radio
buttons.
Unfortunately, ASP.NET is not giving the radio buttons any name at all,
but actually allocated the name (I gave the servers-side controls) to a
table (on the client), then gives the client-side radio buttons IDs of:
rad1_0, rad1_1, etc. (when the server-side name is rad1)

I can give the radio button list a event (programmed on the server) -
and ASP.NET then allocates that event to the bloody table - not the
actual buttons (which it places in the table).

Nevertheless, once I figured out what was going on I was able to do my
javascript validation so it's no longer a problem - just a puzzle.

I may try changing the default page spec to validate for HTML 4 in
future, as this attribute-cide I get from constant compiler warnings is
annoying me. As if anyone expects browsers to actually deprecate these
attributes - I bet they'll still be there in 50 years time.
Steve
Nov 25 '06 #7
On Sat, 25 Nov 2006 11:40:28 GMT, Jasbird <Ja*****@houdini.comwrote:
>On 24 Nov 2006 01:58:55 -0800, "Steve Pugh" <st**********@gmail.com>
wrote:
>>Jasbird wrote:
>>Has the name attribute deprecated?

The name attribute has a long and complicated history. It has existed
for various different elements in various different versions of HTML.

HTML 4.01 adds the name attribute to some elements which didn't have it
in HTML 4.0.

XHTML 1.0 deprecates the name attribute for a, applet, form, frame,
iframe, img, and map elements. But not for button, textarea, select,
input, object, param and meta elements.

XHTML 1.1 removes it entirely from a and map elements.
>>I ask this because ASP.NET 2 warns me against using it, says that it has
been deprecated and doesn't use it (on the client) when creating a radio
button list.

What version of (X)HTML is your code trying to produce?

XHTML 1.0 Transitonal
>>I always thought that a HTML radio button list was made by giving all
the buttons the same name but different IDs?

Nearly. Same name, different values. IDs are not required for radio
buttons.

Unfortunately, ASP.NET is not giving the radio buttons any name at all,
but actually allocated the name (I gave the servers-side controls) to a
table (on the client), then gives the client-side radio buttons IDs of:
rad1_0, rad1_1, etc. (when the server-side name is rad1)
Sorry my mistake. It does give the radio buttons a name (rad1), but
gives the same ID to the table they're nested in.
>I can give the radio button list a event (programmed on the server) -
and ASP.NET then allocates that event to the bloody table - not the
actual buttons (which it places in the table).

Nevertheless, once I figured out what was going on I was able to do my
javascript validation so it's no longer a problem - just a puzzle.

I may try changing the default page spec to validate for HTML 4 in
future, as this attribute-cide I get from constant compiler warnings is
annoying me. As if anyone expects browsers to actually deprecate these
attributes - I bet they'll still be there in 50 years time.
> Steve
Nov 25 '06 #8
Scripsit Jasbird:
Sorry my mistake. It does give the radio buttons a name (rad1), but
gives the same ID to the table they're nested in.
Did you really have to quote your entire previous message just to insert
that two-liner?

Have you mentioned the URL of a sample page yet? It might tell us what you
are really talking about.

There is nothing wrong with assigning id="rad1" to a <tableelement, or any
element whatsoever, while still using name="rad1" for a group of radio
buttons. Well, it might not be pragmatically wise, since it makes people ask
strange questions, but there is no technical problem with it.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Nov 25 '06 #9
Steve Pugh wrote:
>XHTML 1.1 removes it entirely from a and map elements.
So... what are you supposed to use instead of <a name="...">, for
anchors in your page where you link to? The kind of links like this:
pageurl#TOP

--
Bart.
Nov 28 '06 #10
..oO(Bart Lateur)
>Steve Pugh wrote:
>>XHTML 1.1 removes it entirely from a and map elements.

So... what are you supposed to use instead of <a name="...">, for
anchors in your page where you link to? The kind of links like this:
pageurl#TOP
12.2.3 Anchors with the id attribute
http://www.w3.org/TR/html401/struct/links.html#h-12.2.3

Micha
Nov 28 '06 #11

Jukka K. Korpela wrote:
[...]
There is nothing wrong with assigning id="rad1" to a <tableelement, or any
element whatsoever, while still using name="rad1" for a group of radio
buttons. Well, it might not be pragmatically wise, since it makes people ask
strange questions, but there is no technical problem with it.
"No technical problem" is somewhat vague. It is standards compliant,
but since IE doesn't make any distinction between name and id
attributes when using script and document.getElementById, there is
certainly a good reason to keeps names independent of IDs.

Try this in IE:

<input name="foo" value="foo input">
<p id="foo">foo paragraph</p>
<button onclick="alert(document.getElementById('foo').tagN ame);">
Show foo's tagName
</button>
--
Fred

Nov 30 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by TheKeith | last post: by
4 posts views Thread by Stan Brown | last post: by
24 posts views Thread by Chameleon | last post: by
6 posts views Thread by Dick Watson | last post: by
10 posts views Thread by Man-wai Chang | last post: by
4 posts views Thread by andrew | last post: by
16 posts views Thread by Eric Lindsay | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.