Re: name="" deprecated in XHTML

On 1 Jul 2008, at 07:16, Sebastian Mendel wrote:
> Johannes Koch schrieb:
>> David Woolley schrieb:
>>> (strictly speaking you could probably have both ID and NAME, with  
>>> different values)
>> For a element, this is questionable.
>> <http://www.w3.org/TR/html4/struct/links.html#adef-name-A>:
>>> Note that this attribute shares the same name space as the id  
>>> attribute
>> I read this as: name and id attributes for the same a element must  
>> have the same values.
>
>
> isn't it common to use
>
> <input type="radio" name="color" value="red" />
> <input type="radio" name="color" value="blue" />

Yes.

> so isn't it confusing to say on other elements ID and NAME share  
> same space and name has to be unique?

A little.

> and following the above example isn't it incidental to use the name  
> attribute if you need to do something with all <input  
> name="color[]" ...>?

It does make things easier, because an author will have already given  
the controls names for the purposes of making them successful  
controls, but isn't essential since you can use class. There are  
plenty of libraries which implement getElementsByClassName and I  
believe work is under way to add it to the standard DOM.

> and following the above example isn't it incidental to use name  
> attribute the same way on other elements?

All else being equal, perhaps, but it isn't.

@name has a long history, and already has a defined meaning for use on  
some other elements. You would have to redefine it, and this would  
break <a name="foo">...</a>.

> i would go even the opposite and make name a global attribute

Eliminating it where deprecated strikes me as a better approach.  
Having an attribute that does very different things depending on what  
element it is attached to seems confusing at best.

> and i still think class and name should not be mixed up.


@class is a generic way to make elements as being part of a group, and  
one which allows an element to be part of multiple groups.

@name defines the name of an anchor for the purposes of fragment  
identifiers, or the name of a control for the purposes of identifying  
it when submitting to the server (and grouping radio buttons), or  
identifies a frame / image map / image, etc.

Most of those cases would, IMO, be better handled by @id, with @class  
for identifying groups. The named anchor issue is already handled by  
@id, and better then @name since it is not limited to anchors. That  
only case that needs special attention is form controls, since the  
need a name for their data to be submitted to the server with, that  
needs to be non-unique (so not @id) and non-multiple (so not @class).

-- 
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/

Received on Tuesday, 1 July 2008 07:01:50 UTC