Has the name attribute deprecated?

[Jasbird]

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?

[Steve Pugh]

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

[Michael Fesser]

..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

[Steve Pugh]

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

[Michael Fesser]

..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

[Steve Pugh]

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

[Jasbird]

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

[Jasbird]

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

[Jukka K. Korpela]

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/

[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

--
Bart.

[Michael Fesser]

..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

[Fred]

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