Re: [xml] HTML input element and IDness

[Rob Richards <rrichards ctindustries net>]

Geir Aalberg wrote:
> on 03/01/2006 07:02 PM Rob Richards said the following:
> > I am not 100% sure of the correct behavior here as this is from a bug 
> > report I received, but reading the CVS log for version 1.174 of valid.c
> > * valid.c: in HTML, a name in an input is not an ID
> > it looks like the behavior is wrong. It appears to never indicate an 
> > ID if an input element is passed in regardless of the attribute name.
> >
> > My eyes are a bit buggy from all the parenthesis, but I believe this 
> > patch correctly fixes the behavior:
> > - if att name is "id" then its an ID
> > - if att name is "name" then its an ID if no element passed in or the 
> > element name is not "input".
>
> By what logic is the "name" attribute used as an ID? There is nothing 
> in the HTML DTD indicating this, and the HTML 4.01 spec only specifies 
> that "name" must be unique for the A element. For other elements it is 
> perfectly reasonable to expect multiple "name" attrs with the same 
> value - not only INPUT, but also SELECT, TEXTAREA and PARAM 
> (presumably in different FORMs or OBJECTs). Sure, it would be a bad 
> idea to use several FORM or MAP elements with the same name, but AFAIK 
> it's not illegal.
>
> [This must not be confused with the SGML basic type NAME, which is 
> used in the HTML DTD for several attributes (e.g. "http-equiv"). Also, 
> some "name" attrs are defined as NAME while others as CDATA, see 
> http://www.w3.org/TR/REC-html40/types.html#type-name ]
That was the reason I wasn't 100% sure this behavior. Have done a bit of 
searching trying to find out why "name" was ever considered an ID and 
was actually going to ask the same thing, as I have yet to find an answer.

Right now the only reason I could see keeping it would be for BC reasons 
(looks like this has been the behavior since 2.0.0)

Rob