This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In most regards, the <input> element treats an empty name the same as the lack of a name. This is true for example during form submission, and weather the element shows up in the form.elements collection. However, the one exception appears to be that for radio buttons, <input> with an empty name attribute belong to the same radio group. However elements with no name attribute belong to no group. Firefox 3.6 does what the spec currently prescribes. Firefox 4 puts empty-named radio buttons in no group. (Disclosure, this change was made by me, though I don't remember if it was an intentional change or not. It could have been a side effect of some code cleanup). Webkit puts empty-named radio buttons in no group. Don't have Opera or IE at hand to try, but [1] indicates that Opera and IE6 behave like Firefox 3.6 whereas IE9 behave like Firefox 4 and webkit. If this is true the only recent browser that follows the currently specced behavior is Opera. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=639378 To make name handling more consistent I propose that we treat empty-named radio buttons like nameless radio buttons and make them not belong to a group.
(In reply to comment #0) > In most regards, the <input> element treats an empty name the same as the lack > of a name. > > This is true for example during form submission, and weather the element shows > up in the form.elements collection. I disagree. It seems that, in general, attributes in HTML are not ignored when they are equals to the empty string. For example, "<a href=''>foo</a>" is far different from "<a>foo</a>" and "<input pattern=''>" from "<input>". The two examples you took are two exceptions because we *need* the string to not be empty. It doesn't really make sense to submit something if there is no name to identify it and the empty string isn't a real identifier. For the form.elements, elements with the empty string are in that collection but you can't access them with this form: form.elements.name given that "form.elements." would make no sense. Even, according to the specs, form.elements.namedItem("") should return element(s) with name="". > Firefox 3.6 does what the spec currently prescribes. > Firefox 4 puts empty-named radio buttons in no group. (Disclosure, this change > was made by me, though I don't remember if it was an intentional change or not. > It could have been a side effect of some code cleanup). > Webkit puts empty-named radio buttons in no group. > > Don't have Opera or IE at hand to try, but [1] indicates that Opera and IE6 > behave like Firefox 3.6 whereas IE9 behave like Firefox 4 and webkit. Given that IE6, Firefox prior to 4 and Opera are accepting name='' as a group, we do agree that there is no compat issue here? If that is the case, assuming there is no consistency to keep with name='', I think it would be better to keep what the specs currently say just for the ease of implementation: it seems easier to check if a radio button is in a group by checking if it has a name attribute than checking if the name attribute is different from the empty string. In addition, it's a simple way to let authors create a non-submittable radio group (though, I guess no one does that).
I'm not convinced that having pattern="" actually apply a pattern is a good idea. As an author I likely would have assumed otherwise. We have had problems in the past with authors thinking that src="" meaning that nothing should get loaded, for example for <img>s. The fact that it did cause images to load was both a surprise, and a hassle to fix for them (even after learning how things behaved) since they could not do: <img src="<%$icon_url%>"> In for example PHP. This was enough of a hassle that for a bunch of elements we defined that empty src means no load happens. Additionally, not allowing empty-nam-means-no-name means that authors can't do elem.name = ""; In order to remove a radio from a group. Same applies to pattern and src.
Looks like Opera is the only outlier here now. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Compat with more browsers.
Checked in as WHATWG revision r6109. Check-in comment: Change have radio button groups are defined to more closely match contemporary browsers. http://html5.org/tools/web-apps-tracker?from=6108&to=6109
mass-moved component to LC1