Radio INPUT IDs and NAMEs don't share same namespace

VERIFIED INVALID

Status

()

Core
HTML: Form Submission
P2
normal
VERIFIED INVALID
19 years ago
19 years ago

People

(Reporter: Angus Davis, Assigned: Eric Pollmann)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Assignee: karnaze → pollmann
Status: ASSIGNED → NEW

Comment 1

19 years ago
Setting all current Open/Normal to M4.

Comment 2

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

Updated

19 years ago
QA Contact: 4110 → 4137

Comment 3

19 years ago
Reassigning qa contact to cpratt@netscape.com

Comment 4

19 years ago
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?

Comment 5

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 8

19 years ago
Marking verified invalid (deferring to pollmann) on this one.
You need to log in before you can comment on or make changes to this bug.