The depreciated name attribute

[James Glasheen]

If I'm using name to pass field entries in a form to a script at the moment and id as an identifier for the <label></label> tag, what do I do when name goes?

Here's some example code:

<input type="radio" name="status" id="status1" value="Current"><label for="status1">Current</label>
<input type="radio" name="status" id="status2" value="Prospect"><label for="status2">Prospect</label>

Firstly, why does the form decide to take the name value and not the id value?

Secondly, if I've taken out name and am relying on id as in:

<input type="radio id="status" value="Prospect"><label for="status2">Prospect</label>

How do I differenciate between two radio buttons if I still want to keep the funcationality <label></label> gives me?

Hope this makes sense!

James G

[David]

Hmm...

I don't have a good answer to this question. From the research I've done it looks as though this is a bit of a grey area. In her book, Elizabeth Castro uses the name attribute freely. Jennifer Niederst says it should now be replaced by id or used with id for backwards compatibility. Here's the chapter and verse from W3C (http://www.w3.org/TR/xhtml1/#C_8) on name depreciation.

Just about every reference I have come across assumes name and id to be synonymous and therefore the transition from one to the other to be not problematic.

In cases where name is used to pass data to a script, the advice seems to be "leave the name attribute in for now".

So, not clear but I'll let you know if I come across anything else.

[francis]

Heh - you beat me to a reply. I've had a quick mooch around the PHP.net, Google and the W3C, and came to the same conclusion.

To be honest, I really wouldn't beat yourself up over this. There's plenty of depreciated attributes out there that, if you want to get hardcore with yourself, you could tackle. For example, the width attribute on table elements (headers, cells etc). The preferered method is now via CSS or just let the table flow around the data. Now, that, is more "fun"! For a full list of depreciated HTML4.01 elements check here: http://www.w3.org/TR/html401/index/attributes.html and look down the "Depr" column.

There seems to be too many things that still use "name" as an attribute. I vaguely remember reading a comment from the W3C about this and admitting it maybe needed a bit more thought. However, it's completly removed from XHTML1.1, so maybe they didn't bother. Maybe there's a scripting thing or some other way, but I'd rather pull my hair out over something like CSS implementation (no, really...) than worry about this. I'll do a bit more digging.

[francis]

If you want an answer, ask a mailing list! The answer is as follows (I should've picked up this myself last night, am slightly annoyed that I didn't). Name is depreciated but not on form elements. Here are some W3C notables:The XHTML1.0 spec (http://www.w3.org/TR/xhtml1/#h-4.10) for elements with "name". If you look at the list at the top of this section, you'll see a, applet, form, iframe, img and map, but not input. Here are the relavent XHTML DTDs (these are what you reference at the top of a well written X/HTML document), and aren't particularly easy to read. However, here is the one for XHTML1.0 strict (http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict), which is far more, er, strict than Transitional. If you can understand it, search for this: <!ENTITY % InputType. A few lines down from that is the list of allowable attributes, and this includes name.

So, you're alright!

[David]

Thanks for clearing that up for us Francis. I couldn't quite believe that it had been overlooked.

[francis]

It's annoying that the W3C haven't produced a proper table of elements and attributes for XHTML as they have for HTML4.01. Instead of just looking down a table, you've got to go through an entire document. It's an annoying inconsistency that makes this kind of thing harder. Oh well, there's always the DTDs to read...