These two examples should work the same way (only one button selected at a time) since NAME and ID share the same namespace: <form> <input type="radio" id="sorting">Author <input type="radio" id="sorting">Title <input type="radio" id="sorting">ISBN </form> <form> <input type="radio" name="sorting">Author <input type="radio" name="sorting">Title <input type="radio" name="sorting">ISBN </form> In the first example, more than one radio can be checked at the same time. 11-16-98 12pm optimized build.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Reassigning qa contact to cpratt@netscape.com

Hmmm... Section 7.5.2 of the HTML 4 spec makes this assertion for Anchor names only. This example would also violate the requirement that ids be unique for a document. If there was a label associated with the radio buttons, this would also violate the requirement in 17.9.1 that a Label element be associated with exactly one form control. Implementing a label for such a control could be counter-intuitive, eg. should the label switch the selection from one radiobutton to another each time it's pressed? In which order?

Also, 17.2.1 states that mutually exclusive behaviour occurs when radio buttons share the same control name. 17.2 only specifies a control name as being defined by it's Name attribute. In other words, Mozilla's current behaviour looks to be correct.

I agree with the last two comments on this bug. First, it should be noted that the included HTML snipped would not be valid inside an HTML 4 document. There are three input elements each assigned the same id. From 7.5.2: 'The id attribute assigns a unique identifier to an element (which may be verified by an SGML parser).' Since each radio input is a unique element, this is invalid HTML. Second, the only contraint on the group operation of radio input elements is the name attribute. From 17.2.1: 'radio buttons Radio buttons are like checkboxes except that when several share the same *control name*, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off". The INPUT element is used to create a radio button control.' and from 17.2 Controls: 'A control's "control name" is given by its name attribute. The scope of the name attribute for a control within a FORM element is the FORM element.' The confusion may have been arising, as was pointed out, from the exceptional case of an anchor: From HTML 4 spec 12.2.1 Syntax of anchor names: 'An anchor name is the value of either the name or id attribute when used in the context of anchors. Anchor names must observe the following rules: Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document. String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.' Since names of anchor elements must also be unique, the "id and name both working as anchor name" exception was allowed for convenience. Marking this bug invalid.

I agree with the last two comments on this bug. First, it should be noted that the included HTML snipped would not be valid inside an HTML 4 document. There are three input elements each assigned the same id. From 7.5.2: 'The id attribute assigns a unique identifier to an element (which may be verified by an SGML parser).' Since each radio input is a unique element, this is invalid HTML. Second, the only contraint on the group operation of radio input elements is the name attribute. From 17.2.1: 'radio buttons Radio buttons are like checkboxes except that when several share the same *control name*, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off". The INPUT element is used to create a radio button control.' and from 17.2 Controls: 'A control's "control name" is given by its name attribute. The scope of the name attribute for a control within a FORM element is the FORM element.' The confusion may have been arising, as was pointed out, from the exceptional case of an anchor: From HTML 4 spec 12.2.1 Syntax of anchor names: 'An anchor name is the value of either the name or id attribute when used in the context of anchors. Anchor names must observe the following rules: Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document. String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.' Since names of anchor elements must also be unique, the "id and name both working as anchor name" exception was allowed for convenience. Marking this bug invalid.

Marking verified invalid (deferring to pollmann) on this one.