Closed Bug 108802 Opened 24 years ago Closed 24 years ago

DOM should treat <input id> like <input name> when no name attribute present

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
NetBSD
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: epg, Assigned: jst)

References

(
URL
)

Details

Attachments

(1 file)

Reporter's testcase using document.getElementById()
601 bytes, text/html
Details
HTML 4 and XHTML 1.0 (Strict flavors) do not have a "name" attribute. It has been removed in favor of "id". However, Mozilla will not use id for Javascript document.NAME or in form submission. I have made this small test page to demonstrate both problems. If you replace id with name in the form and input elements, the entry is automatically focussed on load, and clicking the Submit button does what you'd expect with the text in the entry. Mozilla should do the same thing with id, but does not. This bug makes it impossible to develop form-based CGIs with Strict XHTML. The id attribute is described in Section 7.5.2 of the HTML 4 spec (http://www.w3.org/TR/REC-html40/struct/global.html): The id attribute has several roles in HTML: * As a style sheet selector. * As a target anchor for hypertext links. * As a means to reference a particular element from a script. * As the name of a declared OBJECT element. * For general purpose processing by user agents (e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.).
Such a well written bug report, yet you failed to include your build ID or any hint of a Mozilla version. I'll reference the bug writing guidelines: http://www.mozilla.org/quality/bug-writing-guidelines.html ->DOM HTML and resummarizing for somewhat of a clarification.
Component: Parser → DOM HTML
Summary: id vs. name attributes → DOM should treat <input id> like <input name> when no name attribute present
.
Assignee: harishd → jst
QA Contact: moied → stummala
Doh! I originally had my build info there, but i reorganized the text a few times and i must have deleted it by mistake; sorry. I have no Build ID (it's all zeroes), but i have the 0.9.5 source release from the NetBSD package collection.
John, what are your thoughts on this?
It *is* in the current specs: http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT I think that NAME has a different intent from ID. ID is intended to reference the element by a script. NAME is the name of the value that will be submitted. ID is not suitable as a synonym for NAME for the following reasons: - ID is supposed to be unique per document and NAME is supposed to be unique per form. If you had multiple forms with the same NAME - Radio buttons and other controls that may have the same name as other controls in the same form. If ID was the name used for submission instead of NAME, you could not reference the radio buttons by ID because they would have to have the same ID to submit with the same name. - You might want to be able to reference an element in a form by ID but not submit it. In that case you'd want to use ID instead of NAME, but if ID was used as the name for submission, this would be impossible. I think XHTML is making a mistake by removing NAME. I was not aware of this. In short: - ID should be used to reference elements in script (this should probably include form.elements[], that's a much better question) - NAME should be used as the name to submit with
Oops, didn't finish. "If you had multiple forms containing controls with the same NAME, you could not reference these elements uniquely using ID."
Don't you just *love* HTML :-)
Just for clarification: name is not removed completely from XHTML. It is removed where name was being used as identifiers, for example an anchor fragment identifier. <a name="foo"></a> is now invalid, whereas <a id="foo"></a> is correct in XHTML. <form name> is now <form id>. However those were specifically changed because the purpose of those form attributes were to identify an element. Form controls use name not for identification, but for submission and as far as I can tell it is still within the spec and required to use name. From the XHTML 1.0 Strict DTD: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd <!ENTITY % InputType "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)" > <!-- the name attribute is required for all but submit & reset --> <!ELEMENT input EMPTY> <!-- form control --> <!ATTLIST input %attrs; type %InputType; "text" name CDATA #IMPLIED value CDATA #IMPLIED checked (checked) #IMPLIED disabled (disabled) #IMPLIED readonly (readonly) #IMPLIED size CDATA #IMPLIED maxlength %Number; #IMPLIED src %URI; #IMPLIED alt CDATA #IMPLIED usemap %URI; #IMPLIED tabindex %Number; #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED onselect %Script; #IMPLIED onchange %Script; #IMPLIED accept %ContentTypes; #IMPLIED > Reading the rest of the DTD reveals that it is also valid for other input controls. And from http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes (which outlines the changes from XHTML 1.0 -> 1.1) The differences can be summarized as follows: 1. On every element, the lang attribute has been removed in favor of the xml:lang attribute (as defined in [XHTMLMOD]). 2. On the a and map elements, the name attribute has been removed in favor of the id attribute (as defined in [XHTMLMOD]). 3. The "ruby" collection of elements has been added (as defined in [RUBY]). There is no mention of removing the attribute from any form input controls I'm not sure this is a bug we should fix which is why I initially left it unconfirmed.
Ah, you're right about using name for submission. In my testing i always added or removed name from form and input simultaneously, so i didn't realize it was still valid for input. How sloppy of me. However, there is still a problem with scripting. I have updated my id-test.html page to add name to input, so submission now works correctly, but as you can see, the entry is not focussed like it should be.
Not seeing anything I'd consider. What are you expecting vs. what are you getting? I am not seeing the textfield focus when going to the page ... At any rate, I think all agree this bug is wontfix. Text focus issues are far, far from the realm of this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Uh, come again? Mozilla's current scripting implementation only lets me access a form object via the name attribute (i.e. i do <form name="foo"> and then refer to document.foo). This is incorrect. All elements under the strict DTD are to be referred to by the id attribute; the only elements which have name attributes are form input elements, and then name is only used for submission purposes. Earlier i was slightly confused about that, and i apologize for that. As it stands, i can't refer to the form element in a strict document. This is evidenced by my focus function not being activated. I hope it makes more sense now.
Hmm, I'm unclear on the problem. What *specifically* should happen here that is not happening? When you do document.getElementById() is it not giving you the form element? I wasn't aware that document.<id> was supposed to actually give you the ID'd element in the document, that's a pretty useful feature if true, but I wonder why people have been advocating document.getElementById() if it is.
Error: document.getElementById("f.address") has no properties OK. Error: document.getElementById("f") has no properties Hmm. I'm not the best Javascript programmer in the world; i've never seen the get ElementById() function. Maybe i'm using it wrong. However, i am familiar with document.foo, which i have used for years. Until HTML 4 Strict (I think), foo was the element which had name="foo"; now name is gone for most elements (kept only for submission of input elements), so i assumed i was supposed to use id now. I didn't make that assumption out of nowhere. The original text i quoted from the spec says it is to be used for scripting, and there is a passage in the compatability appendix that implies this as well.
document.getElementById("f") works for me. I'll upload the testcase. From the HTML spec (http://www.w3.org/TR/REC-html40/interact/scripts.html#htmlrefs): "Each scripting language has its own conventions for referring to HTML objects from within a script. This specification does not define a standard mechanism for referring to HTML objects." (i.e. ID is defined to be accessed from scripts, but it is not specified how in HTML strict.) In the DOM spec for document (http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#i-Document) there is no mention made of being able to access anything at all using document.<id>. From the DOM spec (http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-getElBId): "getElementById introduced in DOM Level 2 - Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID." This is the function to use. I've checked around, and document.<name> was supported in Mozilla for backwards compatibility only. document.<id> was not enough of a problem in existing pages to implement apparently (most people who didn't fix their pages to meet specs were using NAME and not ID :). Plus the more stuff we put into document, the more polluted that namespace gets. I see no reason going forward to implement it, especially since it's not in the spec.
Oh god, this turned out to be nothing more than a free Javascript lesson for me. >sigh< Thanks!
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: