Re: [xml] HTML input element and IDness

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 ]
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)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]